Outbound UDP DOS on VPS
It consumed 50-60 Gigs of bandwidth within one hour.
Linode has raised security alert and asked me to do system migration in case it was a compromise.
I have checked system for most intrusion signs but did not find any evidence.
scanned with Chkrootkit and Rkhunter. There was no exploits found on server.
iptables have been configured to block all ports except sshd and 80.
SSH has been locked down and login is only through SSH keys.
RootLogin is disabled with SSH.
Checked /var/log/auth.log and lastlog for brute force attempts
checked files in /tmp directory.
Check running processes for any suspect.
I saw data being communicated with an IP 209.3.33.161, so added this IP to hosts.deny file to be on safe side.
I suspect that it might be a web script/wordpress plugin. I am still searching for it.
I already have other linode ready to move files onto that. But if there is a file in websites, it may also be copied there and this issue may arise in other linode as well. So I want to be fully sure before copying files to new linode.
Can somebody help in identifying the culprit here?
And as I have little experience with managing server, linode being unmanaged service, should I switch to any managed VPS who can help identify this kind of issues and resolve them.
If yes, can community suggest some good managed VPS under 40$ per month.
4 Replies
To answer your second question, you might be able to find a managed provider for $40/mo, but not Xen based like Linode is. To get that price point it must be Virtuozzo based and oversell the host. IMHO should should at least add $100 to that price point to get a fully managed Xen based solution.
This was the script which was uploaded to server due to timthumb.php vulnerability:
And it was placed cache directory and executed by attacker whenever he wanted a UDP DOS attack.
@pankajbatra:
It was timthumb.php vulnerability. Read more for explanation:
http://www.webrevised.com/130-timthumb- … -affected/">http://www.webrevised.com/130-timthumb-php-vulnerability-thousands-of-templates-affected/
Ouch! That is some nasty vulnerability.
I'm curious as to whether the same UA was used when it was injected onto your own system.