Re: web security (was implementing a set of queue-processing servers)

Rob Nagler wrote:

>  
>
>>This isn't because more eyes looked at postfix than sendmail, but that 
>>the "eye" that designed postfix was a security-minded eye and his 
>>friends who are also security minded also likely had a hand in audit.
>>    
>>
>
>Sendmail is a bad example. ;-) I agree that quality does make a
>difference.  I'm speaking about averages.
>  
>
I am not sure it is a bad example. It is an extreme example, so 
therefore biased, but Apache is also a biased project because of 
Apache's role in the Web.

>  
>
>>What I mean is that if this were a secure site, you would never allow 
>>SSH to come in from the outside layers to the progressively internal 
>>layers. Connections should only be allowed from inside out.
>>    
>>
>
>When all I have is a collocation facility, there's no choice.  I've
>got to come in through the front-end.
>  
>
That's true. But if you have a collocation facility, you also don't have 
an intranet on the other side like host based system. I don't really 
consider collocated servers "enterprise" in the sense of having to link 
with real systems like Sabre or Funds Transfer for a bank account, 
medical records lookup, etc...

There really isn't a practical way to host these in a colocated facilty 
and still claim the same level of security you could architect otherwise.

>>So if you have a separate firewall protected zone for the web
>>server,
>>    
>>
>
>Are you saying that the firewall protects your network, and defines
>that as "inside"?
>  
>
Well, not necessarily THE firewall, but a firewall or group of firewalls 
as external entities protecting access to and from various network 
partitions. Sometimes people call these DMZ or multi-DMZ, and others 
will say that the word DMZ is completely incorrect because each network 
segment really has it's own rules.

>  
>
>>The only thing the web server should have access to is the protocol and 
>>port to access the app server.
>>    
>>
>
>You have to be able to login.  I don't see how you would administer it
>otherwise?
>  
>
In an enterprise system, your operators would be on the inside of the 
LAN and be able to go from inside out. You are talking as if you are a 
3rd party vendor or the collocation and therefore you have to go from 
outside in. Outside in is always going to be less secure.

But then it depends on your risk level. Personally, I like allowing VPN 
in (eg SSH) for my own convenience. But I've yet to run into a bank (for 
example) or large corporate with similar types of systems that allow SSH 
in. Some even don't allow SSH out because they fear it as a channel 
through which large amounts of proprietary data can be transferred by 
internal employees.

The norm I think is to find SSH coming in from outside to be verboten 
and SSH coming to the server from inside to be grudgingly "OK" and 
usually only allowed through the firewall from some specific operational 
hosts.

Anyway, again, different hosts have different issues. For myself, just 
as you, I prefer convenience. But very few corporate clients I have 
allow us that convenience. In fact, I've never run into a corporate 
client to allow us that convenience. I've run into many dot.com startups 
that allow us that convenience, but never a larger corporate especially 
if their web services are more complex (eg granting limited access to 
medical records).

>>And many times they are because they are useful. It's pretty rare to 
>>find a bare Apache.
>>    
>>
>
>If we are talking about enterprise systems, they had better be bare,
>or the programmers/admins are not very good at what they do.  There's
>no need to run inetd, popd, etc. on most systems.
>  
>
By not bare I meant the Apache itself. For example, I don't think it's 
uncommon to find mod_proxy, mod_rewrite and mod_ssl on an Apache exposed 
as the front-end at minimum.

>>    
>>
>>In a 3 tier application where the access to the app server and DB server 
>>are also protected by FWs then if a cracker cracks the Apache web 
>>server, they fact that they have to crack the app server which is 
>>running a separate set of code (eg POE) is going to be a major
>>hinderence.
>>    
>>
>
>I like this quote:
>
>    In the early 1990s, firewall pioneer Bill Cheswick described the
>    network perimeter where he worked at Bell Labs as having "a
>    crunchy shell around a soft, chewy center."
>
>We don't have any firewalls.  All machines run ipchains or iptables.
>They run minimal configurations.  We only allow encrypted access
>except for public Web servers.  Firewalls are a crutch for bad
>security.  Your network has to be composed of jawbreakers.
>  
>
I think this is reasonable for a co-location center. But not for an 
enterprise that has it's own webserver. If the only thing protecting the 
webserver from the intranet is iptables on the webserver itself, what 
happens when someone breaks into the webserver? The next thing to go 
would be iptables and then the machine is exposed to the rest of the 
intranet.

You would need a machine between the web server and the intranet to 
block access definitively.

I think iptables/ipchains is one of the coolest things to get free with 
linux compared to other OSes, but also if the machine is a public 
service machine and someone breaks into that public service, they can 
disable security features for sure.

Whereas, if the security rules are on another machine (separate FW) that 
is never directly seen on the network but just acts as the conduit, then 
there is very little logic that a cracker can exploit. to break down 
those FW rules.

If the FW is separate, even if they break into the web server, the 
cracker can't all of a sudden open up a lot of other ports such as 
conveniently allowing the web server to listen to telnet and FTP and 
installing those services. The cracker would have to either disable the 
web server and install FTP to listen on port 80 (thereby obviously 
disrupting service) or install some CGI's that do the equivalent (which 
won't be as convenient).

>  
>
>>However, even if you are thinking a cracker will discover 
>>vulnerabilities from scratch, and you "think" it is easy to do so on 
>>POE, I think you are still majorly hindering the cracker by having POE 
>>exist.
>>    
>>
>
>AKA, security through obscurity.  It works, but I also think it breeds
>bad designs, just like sessions in Web servers lead to laziness and
>bad designs.
>  
>
While there are properties of "security through obscurity" here I don't 
think this is precisely the same as that. This is security through 
design by layers. It is a common security practice to provide several 
*different* layers of access prior to getting to a coveted resource.

There are even those who advocate putting in two different firewalls 
between the layers so if a bug is found in one firewall, the other 
firewall will still hold the rules up. The logic is that the likelihood 
of both firewalls having an exploit discovered at the same time is 
extremely unlikely.

It is extremely likely that an exploit discovered on one firewall would 
allow the determined cracker to take advantage of that small window of 
opportunity. But two commercial firewall brands having an exploit on the 
same day? Rare.

>>In summary, I think it is much more plausible that your DB server (or 
>>mainframe host) is toast if all you have as a layer in front of it is 
>>Apache than if you have an App Server layer between the two.
>>    
>>
>
>Which is why we encrypt all critical data in our DB, and we start our
>Web servers by hand with a long key.
>  
>
That's a good idea. But if your web server has an exploit, then they'll 
discover the key, no?

However, in a way, that is also good "security through obscurity". :) Or 
design by layer...that it is a separate layer that a cracker would have 
to figure out.

However, how does this work in practice? It would seem to be not very 
practical to encrypt the data on the database or you won't be able to 
use SQL to query?

>  
>