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.
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.
If you desire a beachhead to investigate / crack the target further,
then usually OS-level access (and often, a privileged account) is needed.
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
