| |||||||||||||
Linux botnetsLinux botnetsPosted Feb 15, 2007 2:42 UTC (Thu) by smoogen (subscriber, #97)Parent article: Linux botnets
Having cleaned up a share of Linux systems.. the standard infection methods are:
1) ssh scanning. The botnet uses a dictionary attack against accounts to see what people have let open. In most cases, the crack-masters have gone through many broken systems and worked out what the most common account names are, and then used large numbers of broken into systems as a very large john-the-ripper cluster to figure out what passwords they could get. They then use those passwords as most likely because people choose passwords similarly. They then use large herds of bots to scan every open 22 port. Some botnets seem to also scan other 'common' ssh ports (2222 and 23). [I have seen bot 'clusters' scan a network and then whatever port you stuck SSH on other boxes would then start going after.]
2) PHP scanning. Looking at my logs I get about 40 scans a week for every PHP application that has had a vulnerability since 2000.
3) Webmin scanning. This is where popular webmin ports are scanned for and a similar set of tools as the ssh scanning are used. A lot of application vendors like to use this to help troubleshoot their applications from afar.. many of these vendors don't update the software or are aware that the webmin they installed was bad. They also like to choose password like the application vendor name spelt backwards.
4) Xvnc scanning. Same thing as above... the Oracle application Xvnc is rather old.
The big thing that comes up with several of these is that most botnet people are quite happy if they dont get root access. The ability to create a .<space> directory in the person home directory, /tmp or /var/tmp is fine with them. They can still execute their EnergyMech bot to get to some undernet IRC channel and get commands on what spam to send through the world. This doesn't mean that they wont' try to get root access on the system.. but for 99% of what they want to do.. they do not need to be root on a system.. just a normal user.
(Log in to post comments)
SSH scanning Posted Feb 15, 2007 9:11 UTC (Thu) by ldo (subscriber, #40946) [Link] I wrote a script which continually scanned /var/log/messages for "invalid user" entries logged by sshd, and did a iptables --append INPUT --source srcaddr -j DROP which was removed after 10 minutes. Most of the scanners never came back after the 10 minutes.
SSH scanning Posted Feb 15, 2007 9:44 UTC (Thu) by ahoogerhuis (subscriber, #4041) [Link] # Accept trusted hostsiptables -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport ssh -j ACCEPT
# For outsiders, rate-limit and enjoy
i.e. don't meddle in SSH from places we trust, for outsiders that DO need access, give them three attempts, otherwise it's the doghouse for a few minutes. Simple, very effective.
-A
SSH scanning Posted Feb 15, 2007 10:51 UTC (Thu) by bkoz (guest, #4027) [Link]
Thanks for the iptables hackery. This is the #1 issue I see in my logs.
SSH scanning Posted Feb 15, 2007 16:19 UTC (Thu) by nowster (subscriber, #67) [Link] Order is important in these iptables commands. The commands in the parent appear to match on any traffic. Use instead:
# Accept trusted hosts
iptables -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport ssh -j ACCEPT
# For outsiders, rate-limit and enjoy
iptables -A INPUT -p tcp -m tcp --dport ssh \
-m state --state NEW \
-m recent --hitcount 3 --seconds 180 --update -j DROP
iptables -A INPUT -p tcp -m tcp --dport ssh \
-m state --state NEW \
-m recent --set -j ACCEPT
SSH scanning - fail2ban Posted Feb 15, 2007 12:10 UTC (Thu) by DG (subscriber, #16978) [Link] alternatively try fail2ban (on ubuntu/debian)
SSH scanning Posted Feb 15, 2007 15:02 UTC (Thu) by nix (subscriber, #2304) [Link] Why not just turn off password-authentication on your Internet-facing SSHen? Stick to challenge-response and you'll be safe from all these scanners (modulo major holes in sshd itself, which are rare.)
challenge-response on ssh Posted Feb 15, 2007 23:52 UTC (Thu) by ccyoung (guest, #16340) [Link] how? is there a package? or does it require real work?
challenge-response on ssh Posted Feb 20, 2007 20:47 UTC (Tue) by nix (subscriber, #2304) [Link] Well, ChallengeResponseAuthentication == public-key authentication and/oruse of OPIE, RSA SecurID, or some other one-time authentication system (some of which OpenSSH has native support for).
SSH scanning Posted Feb 15, 2007 16:29 UTC (Thu) by stevan (subscriber, #4342) [Link] The blacklist.py python script(http://blinkeye.ch/mediawiki/index.php/SSH_Blocking) works extremely well for manging ssh scans, in our experience. The answer, though, is, of course, keyed-only ssh access.
S
SSH scanning Posted Feb 15, 2007 16:30 UTC (Thu) by kh (subscriber, #19413) [Link] I have been happy with denyhosts
SSH scanning -- solutions Posted Feb 16, 2007 2:28 UTC (Fri) by smoogen (subscriber, #97) [Link] Thanks for everyone putting up various solutions.. they should make interesting grumpy old security admin articles some day.
They will also be handy for the admin who at 2am has to fix this problem and does a google search.
Linux botnets Posted Feb 15, 2007 9:47 UTC (Thu) by wingo (guest, #26929) [Link] Informative comment, thanks.
Single Packet Authentication is a far better solution. Posted May 14, 2008 20:56 UTC (Wed) by shapr (guest, #9077) [Link] I prefer Single Packet Authentication. The great advantage of SPA is that brute force scanners never know there's a service running.The general case is, don't show headers when a user connects, just accept a connection when there's a correct login, and silently drop packets for illegal logins. That approach would dramatically reduce the attack surface for servers.
|
|||||||||||||