I've been slowly compiling a list of known botnets should
anyone care to filter, or check them in your netblocks if someone in your
range is passing off garbage, etc. Information has been passed from others
admins having to deal with these pest. Care to pass on a host that you're
seeing I'll post it for others to see as well. Perhaps when I have
spare time, I may or may not throw up something where admins can check,
add, hosts they're seeing. Don't know if I want my connection getting
toasted for doing so, but it could be something informative, a-la
spamhaus. Bothaus anyone?
Here's a link to a bugtraq post I made a couple of months ago, about what Trojan horses are used in drone armies today, it is not really up-to-date, but should give you a general idea:
http://seclists.org/lists/bugtraq/2004/Jul/0106.html
And now to your post...
I've been slowly compiling a list of known botnets should
anyone care to filter, or check them in your netblocks if someone in your
range is passing off garbage, etc. Information has been passed from others
admins having to deal with these pest. Care to pass on a host that you're
seeing I'll post it for others to see as well. Perhaps when I have
spare time, I may or may not throw up something where admins can check,
add, hosts they're seeing. Don't know if I want my connection getting
toasted for doing so, but it could be something informative, a-la
spamhaus. Bothaus anyone?
Very interesting. However, in my opinion, half-useless for firewall blocking.
These botnets show up daily, with two main factors that never change (I don't know if it will really be two, I just learned to say two/three in the military about everything):
1. The botnets change daily.
2. The drones composing the botnets change daily.
First, there are quite a few of these out there, and changing where they report to or simply getting new ones is extremely easy for people with such big botnets.
Second, the drones change their software (i.e. the Trojan horse) quite often.
Third, blocking servers won't block the DDoS, it will block your users from being able to connect to these servers.
Fourth, most botnets would simply hop a server when they see one is not there. Once they changed servers, the runners would switch their permanent servers list.
Fifth, they never run out of servers.
Sixth, they are used to running and hiding because there are a few of us who hunt them down constantly.
I believe this idea is as good as blocking port 25 on ISP's for customers not paying/asking for static addresses and/or mail server capabilities, but it is not as efficient nor do I predict it a long life.
The reasoning for it being a good idea, despite what I said above is; not all drones would hop. Runners count on the fact that they can hop their botnets to other servers (even though they usually bother with contingency plans).
Doing this can cause many problems from users who want to use IRC, and considering the users themselves are not yet protected, their machines would simply get re-infected and join three other botnets that same day.
Not to mention the fact that the runner would have their IP's saved and ready for re-claiming/uploading new data/malware.
That said, it's a good idea because it would mean making the lives of the runners a lot more difficult, making sure that in many cases your users won't DDoS (just check these IP's to see how many are connected from your places), and finally, perhaps, maybe, make runners have to use different medias to control their botnets - non as efficient or easy as IRC to date.
Maintaining the list you suggest is difficult, but I am more than interested in how you planned on doing it?
Gadi Evron.
A lot of the IP addresses you have listed seem like they would change with some frequency based on the host names. The problem with using such a list is that it can quickly become out of date unless the entries are automatically aged. Think of a dialup zombie assigned a dynamic IP out of the netblock 192.168.0.0/24. Over time, 192.168.0.1 through .255 will become black listed as the user comes and goes. A quick
cat list | sort | uniq | awk '{print "host "$1}' | sh
shows
0.102.218.12.IN-ADDR.ARPA domain name pointer 12-218-102-0.client.mchsi.com
197.26.119.128.IN-ADDR.ARPA domain name pointer jqa-197.res.umass.edu
227.8.119.128.IN-ADDR.ARPA domain name pointer ja2-227.res.umass.edu
Host not found.
76.84.36.128.IN-ADDR.ARPA domain name pointer yale128036084076.student.yale.edu
144.150.2.129.IN-ADDR.ARPA domain name pointer rkraft.student.umd.edu
205.153.64.130.IN-ADDR.ARPA domain name pointer resnet153-205.medford.tufts.edu
154.221.49.137.IN-ADDR.ARPA domain name pointer uhartford221154.hartford.edu
58.229.166.141.IN-ADDR.ARPA domain name pointer smh229058.richmond.edu
57.230.166.141.IN-ADDR.ARPA domain name pointer smh230057.richmond.edu
2.233.166.141.IN-ADDR.ARPA domain name pointer sfa233002.richmond.edu
87.236.166.141.IN-ADDR.ARPA domain name pointer sfa236087.richmond.edu
247.237.166.141.IN-ADDR.ARPA domain name pointer sfa237247.richmond.edu
168.130.216.150.IN-ADDR.ARPA domain name pointer tfk1116.students.ecu.edu
82.187.1.152.IN-ADDR.ARPA domain name pointer fahrmpc32.cvm.ncsu.edu
Host not found.
222.128.112.195.IN-ADDR.ARPA domain name pointer proxy02.ada.net.tr
131.11.66.200.IN-ADDR.ARPA domain name pointer customer-MZT-11-131.megared.net.mx
102.214.253.206.IN-ADDR.ARPA domain name pointer construct.enic.cc
205.147.234.207.IN-ADDR.ARPA domain name pointer 207-234-147-205.ptr.primarydns.com
Host not found.
198.173.54.213.IN-ADDR.ARPA domain name pointer p213.54.173.198.tisdip.tiscali.de
58.114.254.216.IN-ADDR.ARPA domain name pointer dsl254-114-058.nyc1.dsl.speakeasy.net
114.8.195.24.IN-ADDR.ARPA domain name pointer alb-24-195-8-114.nycap.rr.com
Host not found.
163.26.167.62.IN-ADDR.ARPA domain name pointer adsl-62-167-26-163.adslplus.ch
248.180.65.62.IN-ADDR.ARPA domain name pointer irc-out.antik.sk
179.55.23.64.IN-ADDR.ARPA domain name pointer 64-23-55-179.ptr.skynetweb.com
7.156.37.64.IN-ADDR.ARPA domain name pointer patch-virt7.station.sony.com
156.238.110.65.IN-ADDR.ARPA domain name pointer coy.student.iastate.edu
163.75.210.66.IN-ADDR.ARPA domain name pointer wsip-66-210-75-163.lu.dl.cox.net
20.188.250.66.IN-ADDR.ARPA domain name pointer 66.250.188.20.chaincast.com
200.234.45.66.IN-ADDR.ARPA domain name pointer irc.ashenworlds.net
Host not found, try again.
56.87.90.66.IN-ADDR.ARPA domain name pointer .
36.53.149.68.IN-ADDR.ARPA domain name pointer S0106000103a72199.ed.shawcable.net
146.173.41.69.IN-ADDR.ARPA domain name pointer unused.800hosting.com
60.89.42.69.IN-ADDR.ARPA domain name pointer irc.afraid.org
1.212.247.80.IN-ADDR.ARPA domain name pointer servicez.org
Have you sent email to those edu abuse contacts ? Most of the universities I have worked with for abuse resolution are generally responsive.
---Mike
Unfortunately the 'generally responsive' is the best you can hope for.
Recently while investigating a customer system that had been rooted (poorly
chosen root password) I tracked the psybnc and energymech bots down to a
channel on Undernet's IRC network (#The-Hackers), after wiping out about
half their bots (with informaiton gleaned from the exploited system) they
got upset and decided to attack the host I was IRC'ing from.
One provider (Qwest) resolved the issue after 6 hours of ~100mbit coming
from a colo customer (big name game company, SLA complicated things)
One provider (NetNation.com) said they were aware that the system had been
exploited, and was attacking other systems, but that they had not gotten
around to doing anything about it. A phone call to the customer paying for
the ~50-60mbit/s it was spewing got that resolved very quickly.
The third system went offline completely about 5 minutes after it started
attacking, I like to believe that it set off an alarm somewhere and someone
investigated.
Notable points here:
a) Some providers are happy to allow their customers systems to push DDoS
traffic, it increases their revenue
b) IRC is a haven for these people, unfortunately networks like Undernet
take it a step further by providing channel services and host hiding so
that not only the people behind the DDoS are hidden, but so are the bots
themselves. The people running the network fear retaliation too much to
do anything about it.
c) Everyone I've run across while hunting botnets has been from Thailand,
Korea, India, or somewhere nearby. #The-Hackers has their own website
complete with valid phone numbers: www.the-hackers.org
d) There is no easy solution.