Steve,
First, thanks for putting together some nice extensions to Dolphin. I'm in the midst of planning a revision to a long-running web server, and connecting into a persistent Dolphin app is an essential part of it. The current server uses WinCGI, but that's not universally supported, and access to COM from from CGI executables is problematic. FastCGI is an option, but I'm concerned about the socket port that needs to be open to make it work. After loading your packages into a D5 image, I set the port, started the server, and was able to telnet to it from another machine. I got an error message about an incorrect FastCGI version number, but I'm assuming (please correct me if I'm wrong) that any machine anywhere speaking the protocol would be able to strike up a clear-text conversation with it, bypassing any SSL-aware server I would install. Is there a robust way to prevent remote access to the port? Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Hi Bill,
I'd recommend looking at a firewall to handle this for you if you're concerned with security on the server box- you can block access to all incoming traffic (except of course port 80 or whatever your public port will be), while still allowing connections to the other ports from localhost. So, a user wouldn't be able to connect to for example port 12345 from the network, but your application running on the same machine would be able to. Of course if someone breaks into the machine through the open port you're hosed, but I don't know of a good way around that other than keeping those patches up-to-date! :) W2K and above have software firewalls built in that should be able to handle what you need, but I've never used them myself. I favor stand-alone boxes, many are very inexpensive today. Currently I use OpenBSD boxes running on old leftover hardware, but you can find hardware-based units with nice, easy to use web-based GUIs for $150 and up. I'd recommend doing this for your servers if you're concerned about their security whether you use FastCGI or not- most likely there are other dangerous services on the machine as well. A good example is the recent worm attacks- a properly configured firewall would have blocked infection from that worm even if a vulnerable SQL Server install was running on a server. I'd start by blocking everything, and then only allow what you need through. Jerry Bell [hidden email] "Bill Schwab" <[hidden email]> wrote in message news:<b19j14$vqqmr$[hidden email]>... > Steve, > > First, thanks for putting together some nice extensions to Dolphin. > > I'm in the midst of planning a revision to a long-running web server, and > connecting into a persistent Dolphin app is an essential part of it. The > current server uses WinCGI, but that's not universally supported, and access > to COM from from CGI executables is problematic. > > FastCGI is an option, but I'm concerned about the socket port that needs to > be open to make it work. After loading your packages into a D5 image, I set > the port, started the server, and was able to telnet to it from another > machine. I got an error message about an incorrect FastCGI version number, > but I'm assuming (please correct me if I'm wrong) that any machine anywhere > speaking the protocol would be able to strike up a clear-text conversation > with it, bypassing any SSL-aware server I would install. > > Is there a robust way to prevent remote access to the port? > > Have a good one, > > Bill |
As a victim of Slammer on my development machine this week-end (it got to
the MSDE version that comes with VisualStudio.Net) I second Jerry's recommendation. I opened my firewall to the SQL*Server port to try some connectivity experiment, forgot to close it, and my network experienced a DOS attack. Fortunately it is a development network, not production and, once patched, there was no damage done. Hardware firewall solutions are really cost effective these days - I used to run a couple of old P90 servers like Jerry, but have switched over to hardware firewalls. Of course, you have to configure them correctly ;> jlo "Jerry Bell" <[hidden email]> wrote in message news:[hidden email]... > Hi Bill, > > I'd recommend looking at a firewall to handle this for you if you're > concerned with security on the server box- you can block access to all > incoming traffic (except of course port 80 or whatever your public > port will be), while still allowing connections to the other ports > from localhost. So, a user wouldn't be able to connect to for example > port 12345 from the network, but your application running on the same > machine would be able to. Of course if someone breaks into the > machine through the open port you're hosed, but I don't know of a good > way around that other than keeping those patches up-to-date! :) > > W2K and above have software firewalls built in that should be able to > handle what you need, but I've never used them myself. I favor > stand-alone boxes, many are very inexpensive today. Currently I use > OpenBSD boxes running on old leftover hardware, but you can find > hardware-based units with nice, easy to use web-based GUIs for $150 > and up. > > I'd recommend doing this for your servers if you're concerned about > their security whether you use FastCGI or not- most likely there are > other dangerous services on the machine as well. A good example is > the recent worm attacks- a properly configured firewall would have > blocked infection from that worm even if a vulnerable SQL Server > install was running on a server. I'd start by blocking everything, > and then only allow what you need through. > > Jerry Bell > [hidden email] > > > > > "Bill Schwab" <[hidden email]> wrote in message > > Steve, > > > > First, thanks for putting together some nice extensions to Dolphin. > > > > I'm in the midst of planning a revision to a long-running web server, and > > connecting into a persistent Dolphin app is an essential part of it. The > > current server uses WinCGI, but that's not universally supported, and access > > to COM from from CGI executables is problematic. > > > > FastCGI is an option, but I'm concerned about the socket port that needs to > > be open to make it work. After loading your packages into a D5 image, I set > > the port, started the server, and was able to telnet to it from another > > machine. I got an error message about an incorrect FastCGI version number, > > but I'm assuming (please correct me if I'm wrong) that any machine anywhere > > speaking the protocol would be able to strike up a clear-text conversation > > with it, bypassing any SSL-aware server I would install. > > > > Is there a robust way to prevent remote access to the port? > > > > Have a good one, > > > > Bill |
In reply to this post by Jerry Bell
Hi Bill,
I would use Jerry's firewall solutions if I was looking to secure a FastCGI based webserver. There is a section in the FastCGI spec that addresses security, however the Win32 version of mod_fastcgi does not implement it: http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S3.2 Even if it was implemented, I dont think I would trust it. Thanks, Steve -- Steve Waring Email: [hidden email] Journal: http://www.stevewaring.net/blog/home/index.html |
Free forum by Nabble | Edit this page |