Gunther Birznieks writes: > 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.
Agreed. > 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... If you start looking around, you'll find a lot of companies are trusting collocation facilities for large financial transactions. > 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 that's why Exodus went out of business! ;-) I think the problem of software security can be solved without considering physical access. Also, most corporate computer rooms are probably less secure than commercial collocation facilities--at least from my experience. > 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. But they run Wi-Fi without a problem. :-) > 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. You are correct, but I don't think this actually solves a security problem. Otherwise, most companies wouldn't have problems with virii. They do, and that's the type of attack we are most likely to run into. > 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). On one job I had a large medical clinic *email* medical records for test data. These were real people's records. I was shocked, but not for long. I have found that most IT policies are porous, esp. at the top. Consultants come in with their own laptops. I've done this on numerous occasions at large companies. The point is that while some of the IT security policies stop a certain amount of nuisance security problems, they don't normally prevent crackers. Usually, once inside, you can *telnet* from machine to machine. Never mind SMB. > 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. Well, that's where good sysadmin comes in, and why you sandbox apache (run it as a non-root user). > You would need a machine between the web server and the intranet to > block access definitively. This is impossible. > 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. Yes, and Cisco installed IIS in its DSL routers. Can you say Nimda? Cisco is not perfect, and neither is Linux. > 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). This doesn't make sense. If Apache or POE is cracked and can run arbitrary code, then anything can *go* *out* from the inside. This "reverse tunneling" is pretty much what these DDoS do. A FW usually can't prevent opening port 80 on a remote server. That's all you need to spread or attack. > 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. A good idea. However, you also increase your risk when the software runs on a general-purpose machine. I think that's what we're talking about: POE vs Apache on a server. Multi-layered firewalls are fine, but they can't stop a compromised machine from doing things. > 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. Agreed. > That's a good idea. But if your web server has an exploit, then they'll > discover the key, no? Yes. The question is still if we had Apache -> POE -> Oracle, would we be safer? I doubt it. > 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? Only important data is encrypted (credit cards, SSNs, etc.). We don't query on this data, but when it is retrieved it is decrypted. Rob
