FastCGI - any security?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

FastCGI - any security?

Bill Schwab-2
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]


Reply | Threaded
Open this post in threaded view
|

Re: FastCGI - any security?

Jerry Bell
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


Reply | Threaded
Open this post in threaded view
|

Re: FastCGI - any security?

Jeffrey Odell-2
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
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


Reply | Threaded
Open this post in threaded view
|

Re: FastCGI - any security?

Steve Alan Waring
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