Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I'm seeing a significant number of non-HTTP requests hitting a site I just launched. They show up in the server (nginx) logs as non-ASCII and get rejected (correctly) with a 400 status. Here are some lines from the log:

95.132.198.189 - - [09/Jan/2011:13:53:30 -0500] "œ$A\x10õœ²É9J" 400 173 "-" "-"
79.100.145.126 - - [09/Jan/2011:13:57:42 -0500] "#§i²¸oYi á¹„\x13VJ—x·—œ\x04N \x1DÔvbÛè½\x10§¬\x1E0œ_^¼+\x09ÜÅ\x08DÌÃiJeT€¿æ]œr\x1EëîyIÐ/ßýúê5Ǹ" 400 173 "-" "-"
79.100.145.126 - - [09/Jan/2011:13:58:33 -0500] "¯Ú%ø=Œ›D@\x12¼\x1C†ÄÀe\x015mˆàd˜Û%pÛÿ" 400 173 "-" "-"

What should I make of this? Is this some sort of scripted attack? Or could these be correct requests that have somehow been garbled?

They're not affecting the performance of the site and I'm not seeing any other signs of attacks (e.g., no strange POSTs) so at this point I'm more curious than afraid.

share|improve this question
add comment

1 Answer

I've worked some pretty large sites (1bn pv/day on the largest), approx 1-2% of their traffic was random exploit probing/spiders/crawlers.

  • Classic path manipulation stuff like ..\..\..\cmd etc.
  • More sophisticated buffer-overruns in POST and/or GET looked similar to those in your logs
  • Plain screwed-up home-rolled crawlers that mis-encoded or omitted key aspects of the HTTP protocol.
  • glitched customer connections garbling transmitted data.

Seems that it's plausible that it could be a buffer overrun attack - do you see other instances of the same request pattern? Quite plausible to see screwed up clients and connections too. Switching on logging for other W3C variables like user agent etc. may also give you more clues. e.g. the absence of regular headers like accepts, method etc.

We generally:

  1. made sure our servers were patched regularly just in case ;-)
  2. used tools like UrlScan (we were on IIS) to throw out malformed requests early in the request pipeline.
  3. capped our POST and GET request sizes to prevent some of the more crazy DDoS attacks.
  4. Pawed through all non-2xx/3xx traffic from the logs on a regular basis watching for new patterns. Believe it or not, Excel is an excellent tool for quickly scanning and slicing and dicing data.

While some actions are IIS specific, I've no doubt that nginx has similar tools. In generally there is now so much noise on the internet from random bots, I've learned to just be vigilant and look for emerging new trends.

share|improve this answer
    
Thanks, good suggestion regarding Excel. However, I'm not seeing any patterns through IP, content, or time. The requests seem to be binary, not ASCII, as indicated by the "garbage" I'm seeing in the log, so there's no suspicious headers. My first thought was that this might be a buffer overflow attack so I'm limiting request size, but if this is an attack there doesn't seem to be any rhyme nor reason to it (other than maybe DoS?). –  Mark Westling Jan 10 '11 at 21:29
    
Mark, what are the headings for the logs? 1st column is client-ip? If so, the clients addresses are Eastern-bloc - Ukraine, and Bulgaria. Couple of thoughts - a) logs are url-encoded ASCII - wonder if the request was Unicode encoded data and getting mishandled. b) neither Ukraine nor Bulgaria have great track records, and at least one IP address sent two garbled requests. –  stephbu Jan 10 '11 at 22:27
1  
I think I've figured it out. I originally tested the setup by mapping a high port number on my router to port 80 on the server. Later, I added port 80 on my router but forgot to remove the other port number. My guess is that those strange characters are coming from probes on that other port. I just removed that mapping from the router to see what happens. BTW, I also thought about encodings but nginx should be able to handle Unicode URLs. Thanks again for the suggestions, much appreciated! –  Mark Westling Jan 11 '11 at 0:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.