(...) 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...
http://www.linuxquestions.org/questions/linux-security-4/chkrootkit-checking-%60bindshell-infected-ports-600-a-653981/
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 600tells 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 127.0.0.1 -sU Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-05 22:40 CET Interesting ports on localhost.localdomain (127.0.0.1): Not shown: 994 closed ports PORT STATE SERVICE 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:
http://www.webservertalk.com/message163183.html
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:
http://www.rackaid.com/resources/how-to-harden-or-secure-ssh-for-improved-security/
In other words, I have not been hacked. But “they” are queuing in long lines, prying the door.
fail2ban my friend.
ReplyDeletesudo apt-get install fail2ban
It checks your auth log and bans IP's based on criteria you set (e.g. 3 failed attempts).
Great, thanks! :)
ReplyDelete