Re: Access Log Valve invalid requests

2012-03-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 3/23/12 12:58 PM, André Warnier wrote:
 Find him and shoot him.

Or just firewall him out.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9wkz4ACgkQ9CaO5/Lv0PDFNwCcD5lKJ6NLnGDeU+6PiewMX5AU
ro8An2OfzQaMmfpbb88GlnLIvWV4Wj4d
=ufa/
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Access Log Valve invalid requests

2012-03-23 Thread André Warnier

Leo Donahue - PLANDEVX wrote:

Tomcat 6.0.35

http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Access_Log_Valve

Some requests may be handled by Tomcat before they are passed to a container.  
These include redirects from /foo to /foo/ and the rejection of invalid requests.

What is an invalid request?  If I have a deny set for a Remote Host Filter, is 
that considered an invalid request attempt?

What I'm trying to do is deny a certain requestor from making a POST request to 
a URL that is no longer published, yet retain the attempted request in the 
access log.  If I'm denying the request, should I even care to log the fact 
that there are still attempts at a non-existent webapp?

The requestor makes about 200 POST requests within a few seconds everyday 
around the same time for the past 4 months.  They all result in HTTP 500.


Find him and shoot him.

Seriously, you should be able to log its IP address. From the IP address, you should be 
able to find the domain (WHOIS), and an email address for a domain admin or better someone 
responsible for spam and other nasties.  If it is not in China, send them an email 
indicating the problem, with an excerpt of your logs.
In my experience, in most cases (80%), it works, in the sense that the attempts stop.  In 
1% of cases, you might even get a polite thank you answer. (*)
If it continues, then it is usually better to filter this before it even reaches Tomcat. 
A firewall or iptables (Linux) just blocking any connection from that IP will do fine, and 
will not force your www server to handle that load for nothing.


Most of these things are nasty hacking programs which continuously scan a range of IP 
addresses and try to break in using a range of well-known weak URLs.  Most of those are 
trojan programs that run on hosts that have been broken in, and are not themselves even 
suspecting that they have been broken in.
It can also be a legitimate program which just has the wrong hostname or IP address to 
connect to.  It may be worth 5 minutes of your time to let such normal people know that 
something is amiss, rather than letting them continue to host a trojan or have a 
badly-configured application running.


(*) I would be curious to see the break-down of the other 79%.  They could be nice people 
who realise that one of their servers is doing something it shouldn't; or they could be 
nasty people knowing that their server is doing something it shouldn't, and stopping 
because they've been found out.  But there is no way to know for sure.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Access Log Valve invalid requests

2012-03-23 Thread Leo Donahue - PLANDEVX
 -Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Subject: Re: Access Log Valve invalid requests
 
 Leo Donahue - PLANDEVX wrote:
  Tomcat 6.0.35
 
  http://tomcat.apache.org/tomcat-6.0-
 doc/config/valve.html#Access_Log_V
  alve
 
  Some requests may be handled by Tomcat before they are passed to a
 container.  These include redirects from /foo to /foo/ and the
 rejection of invalid requests.
 
  What is an invalid request?  If I have a deny set for a Remote Host
 Filter, is that considered an invalid request attempt?
 
  What I'm trying to do is deny a certain requestor from making a POST
 request to a URL that is no longer published, yet retain the attempted
 request in the access log.  If I'm denying the request, should I even
 care to log the fact that there are still attempts at a non-existent
 webapp?
 
  The requestor makes about 200 POST requests within a few seconds
 everyday around the same time for the past 4 months.  They all result
 in HTTP 500.
 
 Find him and shoot him.
 
 Seriously, you should be able to log its IP address. From the IP
 address, you should be able to find the domain (WHOIS), 


I log the IP and it comes from a US ISP.  Email has been sent.


 and an email
 address for a domain admin or better someone responsible for spam and
 other nasties.  If it is not in China, send them an email indicating
 the problem, with an excerpt of your logs.
 In my experience, in most cases (80%), it works, in the sense that the
 attempts stop.  In 1% of cases, you might even get a polite thank you
 answer. (*) If it continues, then it is usually better to filter this
 before it even reaches Tomcat.
 A firewall or iptables (Linux) just blocking any connection from that
 IP will do fine, and will not force your www server to handle that load
 for nothing.
 
 Most of these things are nasty hacking programs which continuously scan
 a range of IP addresses and try to break in using a range of well-known
 weak URLs.  Most of those are trojan programs that run on hosts
 that have been broken in, and are not themselves even suspecting that
 they have been broken in.
 It can also be a legitimate program which just has the wrong hostname
 or IP address to connect to.  It may be worth 5 minutes of your time to
 let such normal people know that something is amiss, rather than
 letting them continue to host a trojan or have a badly-configured
 application running.
 
 (*) I would be curious to see the break-down of the other 79%.  They
 could be nice people who realise that one of their servers is doing
 something it shouldn't; or they could be nasty people knowing that
 their server is doing something it shouldn't, and stopping because
 they've been found out.  But there is no way to know for sure.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org