On 15/04/2013 16:11, Mark Eggers wrote: > On 4/15/2013 3:19 AM, Pid wrote: >> On 15/04/2013 00:03, Christopher Schultz wrote: >>> Pid, >>> >>> On 4/12/13 1:54 PM, Pïd stèr wrote: >>>> On 11 Apr 2013, at 21:36, Christopher Schultz >>>> <ch...@christopherschultz.net> wrote: >>>>> [...] though I would run Apache httpd and Tomcat on different >>>>> hosts, so localhost-binding is not possible unless you are doing >>>>> something like stunnel (which also might be a good idea if you >>>>> are traversing an untrusted network). >>> >>>> Respectfully, I have to disagree. Unless the Apache HTTPD is >>>> loaded with IDS that can sniff the inbound traffic, you've not >>>> achieved much, and now you have two boxes that have to be >>>> maintained, secured & patched. HTTPD != firewall. >>> >>> While httpd != firewall, it's traditional to allow external-access to >>> your web server but not your app servers (databases, etc.). That means >>> that external threats can only directly-attack the web server. >> >> Respectfully, this is clearly not true if you are just passing traffic >> to the app server. An attack that compromises the application server in >> the way described above would still be effective regardless of the >> presence of HTTPD. >> >> The risk I perceive is that users think that simply installing HTTPD >> somehow improves their security, when it does not. >> > > I guess we first need to agree what is meant by compromised. If you mean > application-level compromise, then absolutely. Simply adding Apache > HTTPD, multiple systems, firewalls with carefully crafted holes to allow > proxying does little (possibly nothing?) to improve security. > > If you mean OS-level compromise (administrative access on a target > machine), then these techniques can improve security.
> Of course, the > security that this provides depends almost entirely on the underlying > architecture and little on the fact that you're fronting Tomcat with HTTPD. > > One possible improvement in security afforded by running Tomcat behind > HTTPD is the use of mod_security. While mod_security impacts performance > and doesn't catch everything (currently JSON support is not at all > good), it will help as a part of a systems security architecture. > > This turns Apache HTTPD into an IDS, which was mentioned a bit ago in > this thread. (By me!) Agreed, adding mod_security could provide a reason to use HTTPD in front. >> The 'traditional' approach in these matters needs close scrutiny IMO. >> People can't afford to rely on received wisdom for security and forget >> more important basics such as regular patching. >> > > Regular patching, regular auditing of logs, regular testing, keep up on > the relevant technology mailing lists. I really do not like the > (prevalent?) attitude of "if it aint broke, don't patch it". > Well-architected systems don't (shouldn't) break when you patch > components. If you find a lot of breakage, then you're looking at > tightly coupled systems - in almost every case this is a Bad Thing (IMHO). > >> I regularly debate this with customers and we usually agree/find a >> better approach. >> >> >>> Obviously, suffering a web server break-in sucks, but at least the >>> attacker then needs to break-into the application server after that. >> >> Why would they bother if they can attack the applications directly >> anyway? >> > > Again, this depends on the target. If by breaking the application you > gain control of the application server or obtain PII (personally > identifiable information), then this may be all that's desired. Look at the typical attack patterns described as being prevalent today, they are mass-produced, automated scripts probing IP after IP. They are not a single guy in a dark room working a keyboard. They are going for the LCD, for which the most part is unpatched systems. The zero-day vulnerabilities are saved for high-value targets and the occasional publicity generating show off. Most frequently they are just probing IP ranges and it's not *you* that's being targeted specifically, the attacker just wants to add another machine for their botnet. > If you desire a beachhead to investigate / crack the target further, > then usually OS-level access (and often, a privileged account) is needed. Yes, (assuming they are attacking you deliberately), to get this they will not attack your website, they will attempt to compromise your employees, starting with someone who is not IT literate & getting them to open an email attachment that looks like it comes from a colleague. p >>> If it's a one-box wonder, you've been owned in a one fell swoop. >> >> A bit like this one, then. >> >> >>> Also, running a heterogeneous environment can thwart attackers who >>> have some kind of zero-day that got them into the web server (e.g. >>> running httpd on Linux). Then they try the app server and surprise! >>> It's NetBSD and they have to stop and find another attack to proceed. >> >> This is of course possible, but in practice quite rare. >> > > Agreed, operations likes same-ol', same-ol'. Running completely > different architectures on different layers is usually not seen, unless > the architecture has grown organically. If the infrastructure > architecture has been grown organically, then there are likely other > systemic problems. > >> >> p >> >> >> >>> -chris > > As mentioned earlier in this thread, I don't see the penchant for making > the manager application internet-accessible. Sooner or later this can > bite you hard. > > Setting up a VPN using OpenVPN is not that difficult. It's a little more > difficult using two-factor authentication (PIN card plus certificate), > but still doable. > > Then, set up a limited second connector HTTP connector (not many > threads) to serve your manager application. > > Now you have a little more security. > > 1. Something you have (certificate) > 2. Something you know (possible PIN, possible password on certificate) > 3. Another something you know (how to access the manager application) > 4. Reasonably secure (depending on how you set up OpenVPN) access > 5. Audit trail (OpenVPN logs, manager logs) > 6. Revocation ability (revoke OpenVPN certs, change manager access) > > Add Apache HTTPD in front with mod_security (or another IDS > environment), and you've probably made life measurably more difficult > for the would-be cracker. > > Would I manage a Tomcat from a coffee shop with this set up? Probably > not. Is this a reasonable approach for the telecommute person? Probably so. > > Please note that I am NOT a security architect (nor do I play one on the > Internet). I'm just a beleaguered systems architect that tries to find a > balance between the security-by-formula people versus ease-of-use versus > operations versus end user functionality. I feel that it's probably a > zero-sum game, but I guess I like hitting my head against brick walls. > > . . . off to go find more brick walls > /mde/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- [key:62590808] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
