Rob Nagler wrote:
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.
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.
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...
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.
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.
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.So if you have a separate firewall protected zone for the webAre you saying that the firewall protects your network, and defines
server,
that as "inside"?
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.
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?
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).
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.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.
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.I like this quote:
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.
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.
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).
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.
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.
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.
That's a good idea. But if your web server has an exploit, then they'll discover the key, no?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.
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?
