Опасная зона

Опасная зона

Monday, February 28, 2011

Have I been hacked?

I have this odd feeling that hacking attempts are surging in the recent months. Recently our university server was compromised and sourceforge.net was hacked twice. On my own little home server I have no valuable contents, but still it can be used by botnets for illicit activities. So I ran chkrootkit :
Checking `asp'...         not infected
Checking `bindshell'...   INFECTED (PORTS:  600)
Checking `lkm'...         chkproc: nothing detected
                          chkdirs: nothing detected
Checking `rexedcs'...     not found
Checking `sniffer'...     lo: not promisc and no packet sniffer sockets
                          eth0: not promisc and no packet sniffer sockets

Hmm.... ? UDP port 600 open?

Asking google, led me to this post...


This sounds very strange. My router is only forwarding ssh, http, https requests, and no UDP traffic at all, so even if a malicious demon was listening on UDP 600, outside traffic would never reach it.

What process is listening on port 600?
netstat -pane | grep 600
tells me that my portmapper rpc.statd is running and listening on that port. However, strangely enough port scanning UPD ports with nmap resulted in:

sakkub:/etc# nmap -sU

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-05 22:40 CET
Interesting ports on localhost.localdomain (
Not shown: 994 closed ports
111/udp  open|filtered rpcbind
123/udp  open|filtered ntp
631/udp  open|filtered ipp
1900/udp open|filtered upnp
2049/udp open|filtered nfs
5353/udp open|filtered zeroconf

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

What is going on? Next I copied my rpc.statd to a safe pc, and ran a md5sum on it. It was identical to the file from the uncompromised system.

I found a better explanation here:


which suggests it might be some orphaned port which was temporarily opened by nfs. A fix is to restart nfs:

/etc/init.d/nfs-common restart

and this eventually reassigned that port and the false positive from chkrootkit went away. So far so good.

While I was at it, I took a look at my /var/log/auth file, and was aghast on the many intrusion attempts! My poor little ssh-daemon has to cope with roughly 2000-3000 intrusion attempts per day from multiple IP numbers all over the word. Most of them try to login as root:

If you've got a root server, you're never alone. You'll have plenty of friends, from all over the world!
This calls for some security hardening of my sshd. For that reason I blocked root logins by setting

PermitRootLogin no
AllowUsers xxxxxx
ServerKeyBits 2048

in the /etc/ssh/sshd_config file, and restarted sshd. This link gives some more hints on how to harden sshd to the brutal world beyond the firewall:

In other words, I have not been hacked. But “they” are queuing in long lines, prying the door.


  1. fail2ban my friend.

    sudo apt-get install fail2ban

    It checks your auth log and bans IP's based on criteria you set (e.g. 3 failed attempts).