You could write a webspeed program that you run from your site as an
admin function that compiles all the source using the compile command.
admin function that compiles all the source using the compile command.
Hit by Hackers
- Thread starter Chris Kelleher
- Start date
Carrie,
Using WebSpeed with a firewall has been a question that has come up several
times in the past. As of about 2 months ago we published a white paper on this
very subject that may help you out with this. Go to:
http://www.progress.com/internet/webspeed/whitep/index.htm
This is a descriptive paper on how to configure your firewall with WebSpeed,
where WebSpeed components should reside, and which common firewall
architectures are not a good idea with WebSpeed.
bob
Using WebSpeed with a firewall has been a question that has come up several
times in the past. As of about 2 months ago we published a white paper on this
very subject that may help you out with this. Go to:
http://www.progress.com/internet/webspeed/whitep/index.htm
This is a descriptive paper on how to configure your firewall with WebSpeed,
where WebSpeed components should reside, and which common firewall
architectures are not a good idea with WebSpeed.
bob
Thanks, this was just what I was looking for. But is this only possible in
IIS v.3 and above? If so, I finally found a reason to upgrade from v.2.
Ronny.
IIS v.3 and above? If so, I finally found a reason to upgrade from v.2.
Ronny.
There has been a lot of discussion lately about security and the web
(wonder why?). Many great suggestions have come from this group on how to
secure your web site and I will try not to repeat them. However, I think
the list below should be used when ever a site is being moved from
development to production (or a production site is being started using the
default Progress values from the webspeed.cnf or ubroker.properties file).
Disable access to the WSMAdmin utility (AllowMsngrCmds=0)
Disable development mode (srvrAppMode=production)
Disable debug mode (srvrDebug=0)
Do not use the default ports for you application for all servers and
brokers
Minimize your PROPATH to not allow access to progress examples or other
non-essential code
Change all you broker and server names, do not use the default names
Hide your cgiip and wsisa messengers (using scripts or IIS methods)
Do not allow execute rights in your file upload directory (make sure it is
not on your PROPATH)
Hope this is good food for thought and/or discussion. Did I miss
something? Please let me know!
Carrie, if you would like to talk off-line about your specific environment
feel free to email me directly.
Roy
/--------------------------------------------------------------------
/ Roy Ellis Progress Software
/ ellis@progress.com (603) 578-6724
/--------------------------------------------------------------------
(wonder why?). Many great suggestions have come from this group on how to
secure your web site and I will try not to repeat them. However, I think
the list below should be used when ever a site is being moved from
development to production (or a production site is being started using the
default Progress values from the webspeed.cnf or ubroker.properties file).
Disable access to the WSMAdmin utility (AllowMsngrCmds=0)
Disable development mode (srvrAppMode=production)
Disable debug mode (srvrDebug=0)
Do not use the default ports for you application for all servers and
brokers
Minimize your PROPATH to not allow access to progress examples or other
non-essential code
Change all you broker and server names, do not use the default names
Hide your cgiip and wsisa messengers (using scripts or IIS methods)
Do not allow execute rights in your file upload directory (make sure it is
not on your PROPATH)
Hope this is good food for thought and/or discussion. Did I miss
something? Please let me know!
Carrie, if you would like to talk off-line about your specific environment
feel free to email me directly.
Roy
/--------------------------------------------------------------------
/ Roy Ellis Progress Software
/ ellis@progress.com (603) 578-6724
/--------------------------------------------------------------------
Wouldn't the first thing to consider be that during development you
turn on Webserver Authentication, and issue real passwords so that no-one
can access your development system without a valid apache userid/password?
--
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (770)- 972-5430
President Lilburn (atlanta) GA 30247 Fax: 978-4741
neal@mnopltd.com
http://www.mnopltd.com/
turn on Webserver Authentication, and issue real passwords so that no-one
can access your development system without a valid apache userid/password?
--
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (770)- 972-5430
President Lilburn (atlanta) GA 30247 Fax: 978-4741
neal@mnopltd.com
http://www.mnopltd.com/
This is the problem with security issues.
There are many interrelated areas to cover:
o WebSpeed config (covered by Roy's post)
o Network config (covered by the Progress WhitePaper)
o Firewall setup/config
o Bastion host hardening
o Firewall selection and configuration
o Tripwire software selection and configuration
o Log analysis software selection and configuration.
o OS config
o OS level user authentication
o Define domain trust relationships
o Define user group rights (least access)
o Daily/Weekly log reviews
o Web Server config
o Web server user authentication (Your post)
o Use SSL?
o Use SecureID?
o Use a PKI infrastructure?
o Lock to ip/domain's for development
o Hareware access
o Limited access server room
o Security policies
o User policies
o Review policies
o Security audits
o IT review of security web sites and maillists
o Outside auditing
This is really an abbreviated list.
The proper implementation of security really requires a pre-defined written
plan of action
with management sign-on. More importantly the will and resources to stick to
that plan.
Just my take on the true complexities of proper security setup.
Regards,
Sean Overby
Sr. Programmer Analyst
Protech Systems Inc.
soverby@protech.com http://www.protech.com
Stulti timent Fortunam, sapientes ferunt
There are many interrelated areas to cover:
o WebSpeed config (covered by Roy's post)
o Network config (covered by the Progress WhitePaper)
o Firewall setup/config
o Bastion host hardening
o Firewall selection and configuration
o Tripwire software selection and configuration
o Log analysis software selection and configuration.
o OS config
o OS level user authentication
o Define domain trust relationships
o Define user group rights (least access)
o Daily/Weekly log reviews
o Web Server config
o Web server user authentication (Your post)
o Use SSL?
o Use SecureID?
o Use a PKI infrastructure?
o Lock to ip/domain's for development
o Hareware access
o Limited access server room
o Security policies
o User policies
o Review policies
o Security audits
o IT review of security web sites and maillists
o Outside auditing
This is really an abbreviated list.
The proper implementation of security really requires a pre-defined written
plan of action
with management sign-on. More importantly the will and resources to stick to
that plan.
Just my take on the true complexities of proper security setup.
Regards,
Sean Overby
Sr. Programmer Analyst
Protech Systems Inc.
soverby@protech.com http://www.protech.com
Stulti timent Fortunam, sapientes ferunt
Well said. I couldn't agree more. WebSpeed is an application on your
internal network. If you have not developed an overall security policy
for your entire internal network, you are at a higher risk for an
intruder to gain access to it.
bob
internal network. If you have not developed an overall security policy
for your entire internal network, you are at a higher risk for an
intruder to gain access to it.
bob
The list Roy posted is great! There is one other thing I'm not sure
everyone is aware of though. The scripting lab (edtscrpt.w) is callable and
runnable from outside the WS environment (WS2.1). This is complete access
to the procedure editor via the web! Rename the .r or replace it ASAP.
There is serious potential for damage there.
BTW- I did check and this procedure is in the V3 source as well. Better
safe .........
_______________________________________
Steven Lichtenberg
Progressive Consultants, Inc.
"Your Progress is Our Business"
E-Mail: mailto:slichten@pci-net.com
Tel: (703) 790-9316
Fax: (703) 790-9248 http://www.pci-net.com
________________________________________
everyone is aware of though. The scripting lab (edtscrpt.w) is callable and
runnable from outside the WS environment (WS2.1). This is complete access
to the procedure editor via the web! Rename the .r or replace it ASAP.
There is serious potential for damage there.
BTW- I did check and this procedure is in the V3 source as well. Better
safe .........
_______________________________________
Steven Lichtenberg
Progressive Consultants, Inc.
"Your Progress is Our Business"
E-Mail: mailto:slichten@pci-net.com
Tel: (703) 790-9316
Fax: (703) 790-9248 http://www.pci-net.com
________________________________________
Curious what environment you're in...
When I try to run it on a WebSpeed 2.1 NT server in production mode, I
get:
Application Error
Unable to run web object file 'webtools/edtscrpt.w'
When I try to run it on a WebSpeed 2.1 NT server in production mode, I
get:
Application Error
Unable to run web object file 'webtools/edtscrpt.w'
I never tried running in production. We made a decision to turn off
scripting lab early on in the Webspeed learning process so I never gave it
another thought. Scripting lab is just plain and simply not available in
our environment. Development or production.
_______________________________________
Steven Lichtenberg
Progressive Consultants, Inc.
"Your Progress is Our Business"
E-Mail: mailto:slichten@pci-net.com
Tel: (703) 790-9316
Fax: (703) 790-9248 http://www.pci-net.com
________________________________________
scripting lab early on in the Webspeed learning process so I never gave it
another thought. Scripting lab is just plain and simply not available in
our environment. Development or production.
_______________________________________
Steven Lichtenberg
Progressive Consultants, Inc.
"Your Progress is Our Business"
E-Mail: mailto:slichten@pci-net.com
Tel: (703) 790-9316
Fax: (703) 790-9248 http://www.pci-net.com
________________________________________
All the webtools (including the Script Lab) will not run
in "production" mode even if they are in the propath.
They only work in development mode.
in "production" mode even if they are in the propath.
They only work in development mode.
We were hit by two hackers in the last week. They came through port 80
hitting Webspeed and IIS.
I'm running NT4, IIS 4, Webspeed 2.1, Progress 8.3b.
I have been talking to Progress about tightening security on Webspeed. They
are not much help. They have suggested that instead of my previous
configuration of running my broker in development mode that I run it in
production mode on the webserver and set up another NT4 machine in
development mode. I have no idea how to do this and even if this is a good
solution. Of course, Progress can not tell me how to do it either.
I have set my webserver broker to production mode and now cannot use
Workshop. All I need is a way to compile my html pages through webspeed. If
there is another way, I would be happy to hear it.
Any suggestions???
Frustrated.... Carrie
hitting Webspeed and IIS.
I'm running NT4, IIS 4, Webspeed 2.1, Progress 8.3b.
I have been talking to Progress about tightening security on Webspeed. They
are not much help. They have suggested that instead of my previous
configuration of running my broker in development mode that I run it in
production mode on the webserver and set up another NT4 machine in
development mode. I have no idea how to do this and even if this is a good
solution. Of course, Progress can not tell me how to do it either.
I have set my webserver broker to production mode and now cannot use
Workshop. All I need is a way to compile my html pages through webspeed. If
there is another way, I would be happy to hear it.
Any suggestions???
Frustrated.... Carrie
For any environment exposed to the web you must run in production mode. In
WS2.x there's
a checkbox on the last tab for mode with values of 'production' and
'development', select
production.
Your development environment should be entirely within your intranet with no
outside
exposure. i.e. on a different server. If that's no possible you could setup
a
second webspeed broker in development mode, with the same root as your
production
environment. Then create a second virtual website in IIS on a different
port, and
use the security settings to restrict access to the class c address of you
internal
network.
Don't use the 'WService=brokername' nomenclature, instead use the IIS
wrapping funcion.
The optimal setup is basically
external firewall - production web server - internal firewall - intranet
production web speed production
db server
development web server
development web speed
When you say you were 'hit' by two hackers, what exactly does that mean?
Hacking webspeed
would require progress knowledge, and most people don't even know what
progress is.
IIS is inherently insecure for starters.
o Remove all the sample programs and directories from the inetpub
directory.
o Apply the latest nt service packs.
o Go to www.sans.org and buy yourself the latest copy of WindowsNT security
step-by-step and
apply the user/domain/registry restrictions they reccommend.
o Subscribe to the MS security maillist (go to www.microsoft.com/security),
I received
something like 56 seperate security alerts in '99, mostly pertaining to
NT and IIS.
Hope that helps.
Regards,
Sean Overby
Sr. Programmer Analyst
Protech Systems Inc.
soverby@protech.com http://www.protech.com
Stulti timent Fortunam, sapientes ferunt
WS2.x there's
a checkbox on the last tab for mode with values of 'production' and
'development', select
production.
Your development environment should be entirely within your intranet with no
outside
exposure. i.e. on a different server. If that's no possible you could setup
a
second webspeed broker in development mode, with the same root as your
production
environment. Then create a second virtual website in IIS on a different
port, and
use the security settings to restrict access to the class c address of you
internal
network.
Don't use the 'WService=brokername' nomenclature, instead use the IIS
wrapping funcion.
The optimal setup is basically
external firewall - production web server - internal firewall - intranet
production web speed production
db server
development web server
development web speed
When you say you were 'hit' by two hackers, what exactly does that mean?
Hacking webspeed
would require progress knowledge, and most people don't even know what
progress is.
IIS is inherently insecure for starters.
o Remove all the sample programs and directories from the inetpub
directory.
o Apply the latest nt service packs.
o Go to www.sans.org and buy yourself the latest copy of WindowsNT security
step-by-step and
apply the user/domain/registry restrictions they reccommend.
o Subscribe to the MS security maillist (go to www.microsoft.com/security),
I received
something like 56 seperate security alerts in '99, mostly pertaining to
NT and IIS.
Hope that helps.
Regards,
Sean Overby
Sr. Programmer Analyst
Protech Systems Inc.
soverby@protech.com http://www.protech.com
Stulti timent Fortunam, sapientes ferunt
Sean Overby gives good advice in his response, so I won't repeat it.
But, this should serve as a wakeup call to the entire WebSpeed
community. Just because Webspeed is relatively unknown, a lot of people
have been lulled into thinking that we are somehow immune from attacks.
It's been my own experience when looking at WebSpeed sites that MOST are
left in development mode exposed to the web. Some are doing this to
exploit the double agent-count feature.
It's time to get serious...
--
Steve Southwell
Web Programmer / Consultant
United Systems, Inc. http://www.usiatl.com
Phone: (214) 488-2239
But, this should serve as a wakeup call to the entire WebSpeed
community. Just because Webspeed is relatively unknown, a lot of people
have been lulled into thinking that we are somehow immune from attacks.
It's been my own experience when looking at WebSpeed sites that MOST are
left in development mode exposed to the web. Some are doing this to
exploit the double agent-count feature.
It's time to get serious...
--
Steve Southwell
Web Programmer / Consultant
United Systems, Inc. http://www.usiatl.com
Phone: (214) 488-2239
I think this might be something I've been looking for, can you explain more
about this "wrapping function"?
What I want is a way to write http://servername/scripts/cgiip.exe/WService=broker/program.html more like
this: http://servername/virtual-directory-name/program .
Ronny Ager-Wick
about this "wrapping function"?
What I want is a way to write http://servername/scripts/cgiip.exe/WService=broker/program.html more like
this: http://servername/virtual-directory-name/program .
Ronny Ager-Wick
The step by step, see the explanation at the bottom.
o Select your w3 virtual server.
o Right click, choose properties.
o Choose the home directories tab.
o Click the configuration button (at the bottom of the screen).
o Choose the add button.
o In the executable field enter:
o If the web speed broker and w3 server on the same machine then:
[path to cgiip c:/inetpub/scripts]/cgiip.exe WSBrokerPort#
o If on different machines then:
[path to cgiip c:/inetpub/scripts]/cgiip.exe remoteHostName
WSBrokerPort#
o In the extention field enter a three letter extention like .mya
I make main application specific, so if the app is called 'Protech', I'll
name my extention .ptc
o Make sure 'script engine' is checked.
o Make sure 'verify file exists' is not checked.
Now you original URL:
> http://servername/scripts/cgiip.exe/WService=broker/program.html more like
> this:
Becomes this:
http://servername/tmp.ptc/program
Basically you've told IIS: if you see this file extention, I want you to
ignore it (and who cares what
the filename itself is, I usually use tmp) and instead replace it with
'executable field'.
This works with the isapi.dll too.
Hope that helps.
Regards,
Sean Overby
Sr. Programmer Analyst
Protech Systems Inc.
soverby@protech.com http://www.protech.com
Stulti timent Fortunam, sapientes ferunt
o Select your w3 virtual server.
o Right click, choose properties.
o Choose the home directories tab.
o Click the configuration button (at the bottom of the screen).
o Choose the add button.
o In the executable field enter:
o If the web speed broker and w3 server on the same machine then:
[path to cgiip c:/inetpub/scripts]/cgiip.exe WSBrokerPort#
o If on different machines then:
[path to cgiip c:/inetpub/scripts]/cgiip.exe remoteHostName
WSBrokerPort#
o In the extention field enter a three letter extention like .mya
I make main application specific, so if the app is called 'Protech', I'll
name my extention .ptc
o Make sure 'script engine' is checked.
o Make sure 'verify file exists' is not checked.
Now you original URL:
> http://servername/scripts/cgiip.exe/WService=broker/program.html more like
> this:
Becomes this:
http://servername/tmp.ptc/program
Basically you've told IIS: if you see this file extention, I want you to
ignore it (and who cares what
the filename itself is, I usually use tmp) and instead replace it with
'executable field'.
This works with the isapi.dll too.
Hope that helps.
Regards,
Sean Overby
Sr. Programmer Analyst
Protech Systems Inc.
soverby@protech.com http://www.protech.com
Stulti timent Fortunam, sapientes ferunt
Similar threads
- Locked
- Jessica Malakian
- Progress Blog