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
