I'm building some kind of webapp, and currently the whole thing runs on my machine. I was combing down my logs, and found several "strange" log entries that made me a bit paranoid. Here goes:

***.***.***.** - - [19/Dec/2010:19:47:47 +0100] "\x99\x91g\xca\xa8" 501 1054
**.***.***.** - - [19/Dec/2010:20:14:58 +0100] "<}\xdbe\x86E\x18\xe7\x8b" 501 1054
**.**.***.*** - - [21/Dec/2010:15:28:14 +0100] "J\xaa\x9f\xa3\xdd\x9c\x81\\\xbd\xb3\xbe\xf7\xa6A\x92g'\x039\x97\xac,vC\x8d\x12\xec\x80\x06\x10\x8e\xab7e\xa9\x98\x10\xa7" 501 1054

Bloody hell... what is this?!

  • Oh, and as you can see, IP addresses are masked, so they're not "the odd part". =)
    – aL3xa
    Dec 21, 2010 at 22:21

4 Answers 4


Unless you have noted strange new files, changed system files, or other odd behaviours from from your server, I wouldn't worry much about those strange log entries. Anyone can send malformed HTTP requests to your server if it's open to the internet, and so many people (or bots) do just that.

Why would they do that? Well, some web servers have known vulnerabilities that can be exploited by sending them just the "right" kind of request. So what you're possibly seeing are probes for known (or even unknown) vulnerabilities. If it makes you feel safer, you could take retroactive measures, like blocking/banning IP's that send malformed or unknown requests (using iptables, fail2ban, etc.).

Personally, I take the stance that blacklisting "bad" IPs is not really worth it, since, by the time you see their traces in your logfiles, they've either learned that you're not vulnerable, or you're already hacked. I believe the better approach is to be proactive with security:

  • Keep your server software fully patched and up to date. Always. Fastidiously. Religiously.

  • Keep your attack profile as small as possible: Don't install/run any unnecessary software on the server. And, as William of Ockham once said, "Do not multiply user accounts unnecessarily."

  • Firewall your server. (Or don't, but know what you're doing.)

  • Run an intrusion detection system, like AIDE, OSSEC, or samhain. This will alert you when system files change unexpectedly, often a tip-off that your server has been compromised.

  • Run system monitoring/graphing software, like munin, cacti, collectd or the like. Watch the graphs on a regular basis to get a feel for what normal system loads look like, and what your regular trends look like. Then, when your graphs show something you've never seen before, you have impetus to investigate further.

  • Run a web log analyzer/grapher, like webalizer or awstats. Again, become familiar with what normal operations look like, so you can quickly recognize when things aren't normal.

  • Run a separate log server---preferrably on a minimal, security-hardened system that's running nothing else---and configure your servers to send their logs to it. This makes it much more difficult for an intruder to cover his tracks.

  • The webalizer link is not correct; likely should be with a .net extension as in webalizer.
    – Computable
    May 8, 2023 at 11:29

What kind of server are you running? Apache?

That looks like an IIS exploit....Code Red/NIMDA

  • That's right, Apache on GNU/Linux distro.
    – aL3xa
    Dec 21, 2010 at 22:22
  • If it is Apache then you are fine, just junk collection.
    – Jared
    Dec 21, 2010 at 22:32
  • Junk collection with IPs from Russia, Italy and Germany? Don't think so...
    – aL3xa
    Dec 21, 2010 at 22:48
  • 1
    What means Jared is that the exploit targets iis servers, not apache. So you shouldn't be at risk.
    – Déjà vu
    Dec 21, 2010 at 23:29
  • Haha... I was sleepy, OK! =)
    – aL3xa
    Dec 22, 2010 at 21:02

Every publicly accessible web server receives requests like this all day long. They're just blindly attempting known exploits against your server. What I often do is configure the web server to display a blank page when it receives requests to it's IP (i.e. I only allow the sites to appear when the correct virtual host domain is requested.

See what site appears when you access the web server by IP instead of by domain name. Most of the exploit scripts crawling the netter-tubes aren't performing valid virtual host requests(proper virtual host headers).

You can also look into the various utilities that will automatically block IP addresses that attempt nefarious requests.


Well assuming those IP addresses were your own and not external addresses, then it may simply be your web app logging junk.

That reminds of a situation where I'd seen PHP logging data in UTF8, then it getting encoded / escaped into ASCII afterwards which accounted for very similar looking messages.

  • Nope, those were external IPs from Italy, Russia & Germany, respectively. At least that's what WHOIS said...
    – aL3xa
    Dec 21, 2010 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .