Pid wrote:
On 15/04/2013 11:36, Esmond Pitt wrote:
When you quote me in refutation, kindly quote *all* and *only* the parts
that are relevant. You have now made both mistakes in succession. I hid the
Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat
listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be
connected to from outside the localhost. That's not 'security by obscurity',
that's security via a well-known feature of TCP.
Kindly don't top post.
I replied to a thread, it's quite normal to use context from prior
messages in the thread. I am clearly replying in the context of the thread.
It is in effect a firewall.
It is not a firewall. It is a reverse proxy.
127.0.0.x for Tomcat protects it completely.
No it doesn't, for a number of reasons, not least of which being that
you're still sending traffic to it from the network.
I believe you are missing my point, or choosing not to address it.
A client makes a connection to a server through a succession of devices,
each of which is forwarding the TCP traffic to the next device. Simply
adding another entry to that pipeline that only performs the same job of
forwarding traffic onto another port (local or otherwise) does not
provide an improvement in security.
So even if Tomcat only listens on a localhost socket, when you provide a
means for other devices to connect to it from the network without
intercepting that traffic to check it is safe, you are entirely negating
the security benefit you postulate.
I think that the attack you referred to would still have occurred even
with your new 'security' if a) the manager app remained visible to the
outside world and b) you left the password as it was.
You fixed your problem by either preventing access to the Manager from
the outside world (perhaps by a mod_jk/mod_proxy_ajp mapping) or by
changing the noddy password you were using; You did not fix it by
'hiding' Tomcat itself or removing traffic from port 8080.
I'm persisting in this point because I don't want other users to
continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD
alone improves their security.
p
EJP
-----Original Message-----
From: Pid [mailto:p...@pidster.com]
Sent: Monday, 15 April 2013 8:25 PM
To: Esmond Pitt
Cc: 'Tomcat Users List'
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
On 15/04/2013 03:51, Esmond Pitt wrote:
I agree with your comment. Adding a second box for Tomcat only means
I also have to configure a firewall between them, whereas using
127.0.0.x for Tomcat protects it completely.
No it doesn't!
Obfuscation or indirection != security.
HTTPD doesn't magically provide you with some extra security capability.
I don't know what you're talking about. I didn't mention HTTPD in the
message you quoted. I mentioned 127.0.0.x, and it does exactly what I
said it does. There is no 'security via obscurity' here, just a
well-known TCP mechanism.
I quote:
We:
- Hid the Tomcat behind an Apache HTTPD on port 80.
You used the word 'hid'.
ob.scure
Adjective
Not discovered or known about; uncertain.
Verb
Keep from being seen; conceal.
Security via obscurity.
- Closed port 8080, indeed removed all the HTTP Connectors from Tomcat
and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on
the same port for simplicity, so there is no zero direct access to
Tomcat from the outside
I am objecting to the above as being an improvement on two counts:
1. the phrase 'direct access' has no meaning here
2. Tomcat still processes the bytes received from the client with no prior
inspection or validation of their safety.
- Configured Apache HTTPD for LDAP authentication via an OpenLDAP
server that in turn is configured via the Password Policy overlay for
finite (5 I
think) password retries before locking out the account
- required a very restricted LDAP group membership for access to
/manager (and the other Tomcat builtins).
So you secured the Manager app, rather than use a password that could be
guessed.
No recurrence, not even an attempt. I think actually closing port 8080
may have played the biggest part in all this.
No it didn't. Using a password that couldn't be guessed did.
Maybe to bridge both interpretations here, and smooth the discussion a bit :
In his original post, Esmond listed 5 points which *together* increased security for the
access to the Manager application. And, as explained, they do.
However, in subsequent comments he also seemed to imply that putting httpd in front of
Tomcat, and restricting Tomcat access so that it could only be accessed through httpd, was
in itself a security feature and a "firewall". That is not the case, and that was what
Pid objected to, as potentially able to confuse naive readers on this list.
Esmond also mentioned that simply changing the port through which Tomcat was being
accessed, also helped.
That is not in itself strictly true, but there is an element of truth in it : many of
those "automatic hacking tools" seem to work as follows :
- try some random (or less random) IP address, to see if it answers a "ping"
- if it does, then they will try to connect to a range of "well-know ports" on that IP
address, and on each of these well-known ports (corresponding to the standard setup of a
range of "well-know servers"), try for a series of "well-known weaknesses".
- if none of that works, they will give up and go look for more promising
targets
So for example,
- port 22 will be tried for an SSH connection, using a range of "well-known
userid/password combinations" (root/root,root/admin,admin/admin,phpadmin/admin,etc..)
- port 23 will be tried similarly for a telnet connection
- port 80 will be tried with a series of HTTP requests to URLs such as /vti_bin/*,
/phpmyadmin, /sqladmin, /cgi-bin/admin, etc.. (about 50 more of those)
- port 8080 (which happens to be the standard port for HTTP in the tomcat
"factory-standard" server.xml) will be tried for the URL /manager.html (because at some
distant moment in the past, there used to be a weakness there in the factory-standard
tomcat distribution)(it was plugged a long time ago, but hey there are probably still lots
of sites running very outdated versions of tomcat, so why not try ?)
(note that generally port 80 will not be tried for the same URL, because usually port 80
is occupied by Apache httpd or IIS, which do not have a "manager" application).
There are millions of IP addresses, and each one has potentially thousands of ports open.
So these scanning programs cannot spend a lot of time on each combination, and they do at
least a first pass on the most promising ones, and if that doesn't work, they give up and
try the next IP address in their list, after putting this one on some "black-list" of
their own, so that they will not spend valuable time scanning it again.
(Unless of course this IP address is particularly attractive for some reason..)
So, in a way, having Tomcat /not/ answering directly on the Internet on port 8080
diminishes the hacking attempts, and /can/ contribute to the server's security, if only by
making these automated hacking programs give up faster.
The above is not a definitive or complete set of guidelines; it is merely some behaviour
that I have observed in my own job as a sysadmin for a few internet servers. None of
these servers is in principle a very attractive hacking target (I mean, I do not run
banking servers or Facebook or anything like it). But nevertheless, each of these servers
is submitted daily to dozens of such "hacking attempts". That's because gaining control
of even a by-itself unattractive server would allow someone to use it afterward to try to
hack into more attractive servers and disguise where the attack comes from.
What I am trying to say with all of that, is
- there is nothing very special about noticing such hacking attempts in your webserver log
files. They are just a fact of life on the Internet.
- you should make sure that you regularly look at your logs, to detect new forms of such
attempts. Remember also that the really dangerous ones are the ones that succeed, not the
ones that fail.
- you should always consider *all* the web applications that you allow access to, in terms
of security. No URL request should ever be considered as "safe" per se. Any of them can be
coming from one of these programs, not just from a standard browser. So whatever things
that a standard browser won't do, one of these programs just will ("invalid" URLs,
weirdly-encoded URLs, extra-long URLs, etc.). In other words : "/manager.html" is
certainly a hacking target, but it is a well-know one, and one that a lot of people have
given careful attention to, to make it secure. But what about your "/myapp" or your "/demo" ?
- there is not only HTTP accesses to worry about. Any port that is open to the Internet
is potentially an entry for these programs. So all that stuff about choosing non-obvious
passwords is annoying, but important. Over time, the "root" account will be tried with
hundreds of different passwords (so do not use root123, qwerty, azerty, secret, etc..
unless you really want to be hacked).
- as soon as someone gains entry into your server in any of the ways above, their first
task will probably be to discretely install another dozen of alternative entry points into
your system, just in case you noticed and plugged this one.
It is all fairly frustrating, particularly when you think that you are ultimately paying
for the bandwidth and CPU cycles consumed by these hacking attempts.
But at the same time, a relatively simple set of measures can greatly diminish these
attempts, and there is certainly no reason to make life easier for them.
I hope that the above already gives someone some ideas about this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
