Gunther Birznieks writes:
> That will surely be easier than figuring our the vulnerabilities for
> myself. Allowing an exploit to be posted will let me be a part-time
> cracker and all I need to do is wait with a skeleton of injection code,
> ready to strike when the exploit is publicized. But in the latter case
> (finding vulnerabilities myself), I will likely have to make it my full
> time job (either that or I would have to be a high school/college
> student :))
I agree, but I think we have digressed into the realm of
"motivation"...
> Whereas, you will much less likely see a security audit on someone's EJB
> or POE server because it is not on the front-line.
I'm sure Arthur Andersen sells such auditing services. :-)
> 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.
> 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.
> 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"?
> 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?
> 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.
> But in any case, I think my first and primary point has also been lost.
Never! I treasure it.
> 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.
> 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.
> 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.
Rob
