This question already has an answer here:

So I got an abuse complaint for one of my dedicated servers, running Debian 6.0

Sure enough, sometimes, top shows /usr/bin/host using a lot of CPU for no apparent reason, and netstat shows process host doing a lot of HTTP requests.

After while, my syslog even says nf_conntrack: table full, dropping packet., which i assume has something to do with this matter.

I have verified the executable /usr/bin/host using debsums, and is seems to be fine, too. The server as such is 100% updated, too.

So i am guessing something is somehow calling my host executable and coercing it to do HTTP requests for some DDoS.

I could of course simply hack together a script to killall host as soon as this is happening, but I would really like to know where the problem originates from.

I am checking the Apache logs for interesting entries around the time that host is starting to do its requestst, but haven’t found anything yet.

Anyone have a recommendation on what else to do? How can I see who and what called 'host'? Google didnt show up any examples of /usr/bin/host being abused, at all!

marked as duplicate by David Schwartz, Andrew B, voretaq7 Nov 13 '13 at 21:33

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 4
    Host is for resolving DNS, it shouldn't be making HTTP requests at all. Maybe the binary that's doing the attack is named deceptively. I wouldn't trust any file integrity checks on the local machine, they may lie if the machine was compromised. – Cory J Nov 13 '13 at 18:43
  • i did 'updatedb' and 'locate host', and the only file called 'host' is /usr/bin/host. debsums is freshly installed. apt's signatures seem to be ok, too. – Moritz von Schweinitz Nov 13 '13 at 18:52
  • 1
    locate can be patched. debsums can be patched. A binary can be ran and loaded into memory and then deleted from the filesystem. – Cory J Nov 13 '13 at 18:57
  • 5
    "Keep in mind that if a machine is compromised, anything on that system could have been modified, including the kernel, binaries, datafiles, running processes, and memory. In general, the only way to trust that a machine is free from backdoors and intruder modifications is to reinstall the operating system." -- CERT – David Schwartz Nov 13 '13 at 20:48
  • 1
    It may be late, but I end up in the same situation. Turns out to be the exact same thing as in this post:… (TL;DR: Wordpress compromised). – chilladx Mar 15 '16 at 20:30

ps aux

Should show you the user running the process and the full command line. You might find more info with

lsof | grep pid

This will show you any of the processes open files, including libraries, terminals, etc.

Also check out the files in /proc/pid. (/proc/pid/environ, /proc/pid/cmdline, /proc/pid/status):

man proc

But if you suspect some malicious hanky-panky, you can't really trust any of these things. I'd be backing up important data and verifying its integrity. If you REALLY don't want to wipe the drive then at least take it offline to dd the disk for analysis, or use a liveCD to mount it and check md5s, run scans, etc.

  • so the 'host' process was running as www-data, and the lsof command showed me the wordpress installation that was to blame for the hassle. Updated and cleaned it out, and now everything's back to normal. – Moritz von Schweinitz Nov 14 '13 at 19:45
  • 1
    Here is more detailed explanation… – Marki555 Jul 14 '15 at 6:39

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