Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: Securing PyDoc and CGIHTTPserver (http://www.velocityreviews.com/forums/t319487-re-securing-pydoc-and-cgihttpserver.html)

Peter Hansen 07-10-2003 02:30 PM

Re: Securing PyDoc and CGIHTTPserver
 
Jon Schull wrote:
>
> PyDoc's author Ka-Ping Yee has suggested that PyDoc be patched to
> prevent access from unauthorized IP addresses
> (https://sourceforge.net/tracker/?fun...group_id=5470),
> and that without such a patch, its not " suitable for running on boxes
> that aren't behind firewalls"
>
> It's hard to know how much to worry about such things (Comments?).
>
> However, even with the patch, IP addresses can be spoofed. Here is an
> additional security tactic that might be adopted.
>
> The port number used by pydoc is currently set by the user at the
> command line. Many people probably use the example given in the
> python module documentation : "python -p 1234" However, if the port
> were chosen at random and printed out, then only pydoc and the user
> would know how to access the pydoc server.
>
> I'm considering a similar strategy for a server based on the
> CGIHTTPServer module, so comments would be welcome.


My suggestion: don't attempt to mix security into each individual
application in a piecemeal manner. Use the proper tools for the
job, such as firewalls. Setting up a firewall on Linux or WinXP
is nearly trivial at this point, and the learning experience is
worth the effort for those who are new to this, so there's not
much excuse for doing it properly, IMHO.

-Peter

Harry George 07-10-2003 05:23 PM

Re: Securing PyDoc and CGIHTTPserver
 
Peter Hansen <peter@engcorp.com> writes:

> Jon Schull wrote:
> >
> > PyDoc's author Ka-Ping Yee has suggested that PyDoc be patched to
> > prevent access from unauthorized IP addresses
> > (https://sourceforge.net/tracker/?fun...group_id=5470),
> > and that without such a patch, its not " suitable for running on boxes
> > that aren't behind firewalls"
> >
> > It's hard to know how much to worry about such things (Comments?).
> >
> > However, even with the patch, IP addresses can be spoofed. Here is an
> > additional security tactic that might be adopted.
> >
> > The port number used by pydoc is currently set by the user at the
> > command line. Many people probably use the example given in the
> > python module documentation : "python -p 1234" However, if the port
> > were chosen at random and printed out, then only pydoc and the user
> > would know how to access the pydoc server.
> >
> > I'm considering a similar strategy for a server based on the
> > CGIHTTPServer module, so comments would be welcome.

>
> My suggestion: don't attempt to mix security into each individual
> application in a piecemeal manner. Use the proper tools for the
> job, such as firewalls. Setting up a firewall on Linux or WinXP
> is nearly trivial at this point, and the learning experience is
> worth the effort for those who are new to this, so there's not
> much excuse for doing it properly, IMHO.
>


Here, we have lots of COTS *NIX behind the corporate firewalls, and
want to provide internal security. We do this with SSL'd
communications. I can see how a firewall denies/allows specific IP
addresses (or at least claimed IP addresses), but not how it solves
sniffing, spoofing, man-in-the-middle, etc., where encryption
protocols are needed.

> -Peter


--
harry.g.george@boeing.com
6-6M31 Knowledge Management
Phone: (425) 294-8757

Peter Hansen 07-11-2003 01:31 AM

Re: Securing PyDoc and CGIHTTPserver
 
Harry George wrote:
>
> Peter Hansen <peter@engcorp.com> writes:
>
> > Jon Schull wrote:
> > >
> > > However, even with the patch, IP addresses can be spoofed. Here is an
> > > additional security tactic that might be adopted.
> > >
> > > [...] However, if the port
> > > were chosen at random and printed out, then only pydoc and the user
> > > would know how to access the pydoc server.
> > >

> > My suggestion: don't attempt to mix security into each individual
> > application in a piecemeal manner. Use the proper tools for the
> > job, such as firewalls. Setting up a firewall on Linux or WinXP
> > is nearly trivial at this point, and the learning experience is
> > worth the effort for those who are new to this, so there's not
> > much excuse for doing it properly, IMHO.

>
> Here, we have lots of COTS *NIX behind the corporate firewalls, and
> want to provide internal security. We do this with SSL'd
> communications. I can see how a firewall denies/allows specific IP
> addresses (or at least claimed IP addresses), but not how it solves
> sniffing, spoofing, man-in-the-middle, etc., where encryption
> protocols are needed.


Uh, yeah.... but the OP wasn't asking about sniffing, spoofing, or
main-in-the-middle attacks, near as I can tell, nor about using
encryption. He was suggesting an unusual modification to one or
more applications which would otherwise be decoupled from security,
by adding into them features which are better handled by firewalls.

I'm not saying firewalls handle all security. At least I don't
think I did. I vaguely remember saying "proper tools for the
job, *such as* firewalls" [emphasis added], thus implying there
are other approaches that might be appropriate.

-Peter

Jon Schull 07-14-2003 07:03 PM

Re: Securing PyDoc and CGIHTTPserver
 
Well, for what its worth, I was thinking about "sniffing, spoofing, or
main-in-the-middle attacks", and I was hoping for something I could
stick into a program for unsophisticated users (e.g, those to whom one
might give a notepad-like application, albeit with a local webserver
interface).

Everyone who connects to the internet should have a firewall BUT must
all who import httpserver implement or insist on a firewall for all
their users? Realistically? I don't want to think so.


> Uh, yeah.... but the OP wasn't asking about sniffing, spoofing, or
> main-in-the-middle attacks, near as I can tell, nor about using
> encryption. He was suggesting an unusual modification to one or
> more applications which would otherwise be decoupled from security,
> by adding into them features which are better handled by firewalls.
>


> "Security through Obscurity" (e.g., random ports) is not the way to
> go. Instead, use SSL. This can be done through a CGI on Apache
> through an SSL'd port, or it can be done with stunnel. [Or it might
> even be done with raw python using pyOpenSSL or M2Crypto (which I
> haven't done, so I can't tell you anything that direction).]


Jon Schull 07-14-2003 07:03 PM

Re: Securing PyDoc and CGIHTTPserver
 
Well, for what its worth, I was thinking about "sniffing, spoofing, or
main-in-the-middle attacks", and I was hoping for something I could
stick into a program for unsophisticated users (e.g, those to whom one
might give a notepad-like application, albeit with a local webserver
interface).

Everyone who connects to the internet should have a firewall BUT must
all who import httpserver implement or insist on a firewall for all
their users? Realistically? I don't want to think so.


> Uh, yeah.... but the OP wasn't asking about sniffing, spoofing, or
> main-in-the-middle attacks, near as I can tell, nor about using
> encryption. He was suggesting an unusual modification to one or
> more applications which would otherwise be decoupled from security,
> by adding into them features which are better handled by firewalls.
>


> "Security through Obscurity" (e.g., random ports) is not the way to
> go. Instead, use SSL. This can be done through a CGI on Apache
> through an SSL'd port, or it can be done with stunnel. [Or it might
> even be done with raw python using pyOpenSSL or M2Crypto (which I
> haven't done, so I can't tell you anything that direction).]


Peter Hansen 07-14-2003 07:23 PM

Re: Securing PyDoc and CGIHTTPserver
 
Jon Schull wrote:
>
> Well, for what its worth, I was thinking about "sniffing, spoofing, or
> main-in-the-middle attacks", and I was hoping for something I could
> stick into a program for unsophisticated users (e.g, those to whom one
> might give a notepad-like application, albeit with a local webserver
> interface).
>
> Everyone who connects to the internet should have a firewall BUT must
> all who import httpserver implement or insist on a firewall for all
> their users? Realistically? I don't want to think so.


Yes, provided they are running code that is not considered inherently
safe and provided they have sockets that are listening on all interfaces
as opposed to those which bind solely to localhost/127.0.0.1, then I
believe they *should* have a firewall. Doing anything else is playing
with fire, and a bad habit to get into as well.

If this is merely a "local webserver interface", then it should bind
to localhost only. If it is intended for local use on a network, and
therefore must bind to an external interface, then it's perfectly
safe, provided there is no connection to the Internet on that network,
or there is a firewall on any such connection. End of story. (Said
as black and white to encourage discussion, not necessarily because I
truly believe that...)

-Peter

Jon Schull 07-15-2003 05:30 AM

Re: Securing PyDoc and CGIHTTPserver
 
Peter Hansen <peter@engcorp.com> wrote in message news:<3F13034D.19A4C65@engcorp.com>...
>
> If this is merely a "local webserver interface", then it should bind
> to localhost only.


Well, maybe this is how the question should be phrased. How best to
securely and reliably "bind to localhost only" (spoof-proofly, etc.)?

Peter Hansen 07-15-2003 01:03 PM

Re: Securing PyDoc and CGIHTTPserver
 
Jon Schull wrote:
>
> Peter Hansen <peter@engcorp.com> wrote in message news:<3F13034D.19A4C65@engcorp.com>...
> >
> > If this is merely a "local webserver interface", then it should bind
> > to localhost only.

>
> Well, maybe this is how the question should be phrased. How best to
> securely and reliably "bind to localhost only" (spoof-proofly, etc.)?


Localhost means "localhost" as defined in your /etc/hosts or equivalent
file under Windows, or the address 127.0.0.1. Basically, don't do a bind
to '' which binds to all interfaces, but 'localhost' or '127.0.0.1' and
you won't get external interfaces involved.

-Peter


All times are GMT. The time now is 05:33 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.