-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David,
On 4/16/14, 7:54 PM, David Wall wrote: > > On 4/16/2014 3:17 PM, Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> >> The access log of course does not give the whole story. It's >> possible that the client sent for example a badly-formed HTTP >> header value. In those cases, the request-line (shown in the >> access log) can be read and the target context determined, but >> the headers can fail. >> >> Can you narrow-down the types of requests that cause this to >> occur at all? If so, you could enable a request dumper and set it >> to match those requests (I think you have to write a Valve to >> sniff the request and place an attribute in the request in order >> to trigger the request dumper to dump the request). I wouldn't >> recommend using the request-dumper on all requests: it would slow >> everything to a crawl and likely represent a privacy problem as >> well). >> >> - -chris > > Chris, > > Thanks for the reply. We're not sure about the status 400s -- > like today, we show 349 of them, but yesterday it was 157, and on > Monday 122. The prior Wednesday, there were 0. > > Some appear to be hack attempts or the like with requests like > this: 62.210.114.138 - - [10/Apr/2014:04:02:28 -0400] "GET > /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 - 0 - 62.210.114.138 - > - [10/Apr/2014:04:02:28 -0400] "GET /w00tw00t.at.ISC.SANS.DFind:) > HTTP/1.1" 400 - 0 - > > But most seem to be a combination of images and JSPs that are on > our system. Even the user agent strings appear to be highly varied > and requests come throughout the day. > > I've never done a request dumper before, but is there a way to > trigger it only if Tomcat is going to issue a 400? I don't think so. You could probably write a 400-error-handler and register it with your web application. It's possible that Tomcat won't dispatch such a request to the error handler for a number of reasons. If it doesn't work in your own webapp, try deploying it to the ROOT webapp. I'll take a look at the code to see if maybe we can conditionally log something somewhere when we get a 400 error. You can probably get information about it by enabling DEBUG logging on the component that throws the 400 error, but you'll likely get a huge amount of output in that log file, which you obviously don't want. > We run the same sort of software on other servers that seem to > have these only rarely, and the access logs make them appear like > they are hacker/sniffers perhaps: > > 107.152.128.226 - - [31/Dec/1969:16:00:00 -0800] "-" 400 - 0 - > 107.152.128.226 - - [31/Dec/1969:16:00:00 -0800] "-" 400 - 0 - > 188.95.234.6 - - [16/Apr/2014:04:59:58 -0700] "HEAD / HTTP/1.1" 400 > - 0 - Requests with "-" as the request are often "internal" requests as reported by Apache httpd. Are you seeing these in your /Tomcat/ logs? Doing a "HEAD /" in and of itself isn't an indication of nefarious activity, but given that it returned a 400 and likely represents a Bad Request (probably due to headers, since "HEAD /" is perfectly legal), then it might be a probing you for some specific vulnerability like HTTP request-splitting or something like that. > But the ones originally mentioned seem to be more likely coming > from regular users. What is odd is we've never had any reports of > users complaining, but you'd think those 400s would cause someone > to grumble. Because they appear to have valid URLs in the access > logs, often containing the unique 20 random characters that are > used by our application to identify a specific resource, it seems > unlikely they are also hacker types. The links otherwise work if > we enter them into our browser and they should be impossible for > others to guess. It could also be possible that a browser is incorrectly-formatting something. Do you make extensive use of cookies> Do you ever store anything in a cookie name or value that isn't in US-ASCII? If so, you might have some edge cases where the overwhelming majority of your users are find but some folks with Greek names or whatever step-over into non-US-ASCII and hit some edge cases with either the browser or Tomcat itself. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTT+ojAAoJEBzwKT+lPKRYblEQAMDDOmd/CeT8GahcgB3thKBE y/NGo3c9P/efJ9aREnmCoKAOdEmpuoGYcfFyUXZwDEB5/t3/9zoRl6LAJ+GYI999 FLMkZjzLn0G5crfOtucUmoY9V/ETjWYtvImEQN6wx3dC4Fb9dzkHbCsZdWWcohBm /lXo8wUO1+T2xHDylpVkkhC/VHjtKt8THSW0FDykXLKBnFFeWhJWuelPhpJ/jkD9 SBBNrpv69ZLrnCJ8Y7w5lhvxrhpM54PkIRX0bbxBes3LCmMHOwS0hpIW0qH1nK8h ja6fcUzXhJqXER6G/6jMr+GV/XLy08fw37NqckBy+m5y+vZoSPnwXvZyJRn8G8Gf 9S5BzFqbnKxsZhcl4mb3DAH6/QzJRlBzmHa8gc/xFzG5NgbJFIapC6dxL1YYCyHt R/freSFYLRRK8KRx6sHLD3CylQ8E/3O6K3uiL5q2tMVMyvwmmC9me3WfXYUAeTNh woZukoLQ5jWxyrOCLUebxKi3ZIAJoJwHknsva91QsX+tdDmTn4qunJM/XhGVUrqC Fc3lAqAzT72KiORm3FQ9xR667MP1LFw3V+RukHIbvhVbuHdCUgXvlRIEMvA0g0ZX BS9YWZHtDt8fA36BxWOi67DoXqrtGeBsia4ncShqCdoSXGrDl2HZ6v+9bSkiDNnz /eYYFSvFOYTgWpdfBrA8 =XPy8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
