passwords are now SHA-512 hashed. they will be converted automatically on first successful login, so you can still provide md5 hashes for setting up new accounts.

country/asn resolving now done internally using own method importing delegations from ftp.ripe.net and asn table from thyme.apnic.net on a daily base, this should also reduce the load on TeamCymru's whois server a LOT ;)

rpc(2) is now more extensive, rpc2 won't break on batches but simply skips faulty entries with a warning,

For a couple of years now, a certain administrator of BSNL.in has been abusing his works network in order to harras users on IRC on various networks, circumventing bans by constantly changing his IP. The nickname he uses for this is 'enometh'.

The scale of the abuse, and the associated fact that this abuse is on the administrator level of one of the largest ISP's in India, also providing services to several goverment agencies, made us decide to add 59.92.0.0/16 to our blocklist as of March 17, 2014.

However, since he is an administrator at a quite large network (AS9829), he continues to abuse through other ranges, harrassing us with texts like these (and this is just a raw paste of the stuff I received in my personal message window on undernet):

the blood of your family be on your benefactors and the investors of dronebl who set you up to be able to add a spite entry without any abuse in the first place, you who abuse dronebl as the maintainer, may your family suffer as you caused 10s of 1000s of ISP users to suffer because of koeman's spite and your spite and may your family be holocausted off the face of this planet even in this genertation and all the properties and estates of your family and the families of the spooks and telcos that set you up be holocausted without a remnant so they are of no use whatsover to anyone or anything and no one derives any benefit from them forever and ever in the name of yahshua and almighty god ﻿ may even the members of your family that did not bear false witness be struck down even as you bore false witness against me in the name of jesus christ almighty god may god smash the spine and break the hands and destroy the families of the spooks that set you up and your dronebl racket ﻿ may all the maasens be holocausted just because they share the name of alexander maassen even as the whole /16 blocks you added out of spite

﻿i have a message for your friend terrance koeman, who is still banning me on efnet ﻿I, Suresh Madhu, do hereby swear on the name of the God who formed my soul, there will be no peace or rest for my soul until the last Maasen and the last Koeman has been genocided off the face of this earth for all the lying false witness you both bear, and the holding companies of dronebl B.V. and B.V have been liquidated and the ddos and telco spooks that sponsored both of your families have been holocausted off with their families and estates and their telco and spook wealth, so theyre all burnt off the face of this earth forever witout anyone deriving a benefit from it forever and ever, so help me god, in the name of jesus christ who was crucified, in the name of god of justice and mercy and truth ﻿ the only way you alexander maasen and terrence koeman will stop lying and stop abusing your spook-setup powers is when you stop breathing. god speed the date when you both cease to breathe and may god torment every family member of yours for 7 years on the deathbed for all your lies and racket that you run on dronebl ﻿ there was no abuse and you reported abuse,may god damn to destruction your lying mouth and your propertiers and estates, may god damn the maasen family to extinction even in your goddamn generation youre both goddamn spook and telco-banker sponsored retards sponsored because you lie without a conscience and abuse others without a conscience like your 59.92.* bans ﻿ may god send a fire to consume you and your sponsors and all your families and wealth be burnt in that fire even in this generation even by 2017 your lying mouth wither away and die and god shatter the hands and spines of those that set you retards alexander maasen, and koeman up

﻿for every year that spite 59.92.* fake entry dronebl entry keeps everyone using that isp off all irc servers, may EVERY MEMBER OF THE MAASSEN FAMILY BE TORMENTED 7 YEARS ON THEIR DEATHBEDS! AND may the THE FAMILIES OF the telcos and spooks that set up alexander with dronebl and koeman with an o-line be holocausted offf the face of this planet without a remnant forever and ever" ﻿may god break the spines and smash the bones of the hands of all the admins and opers who gave terrence koeman an o-line and may god destroy without a remnant the families of terrence koeman and holocaust the estates and properties and burn destroy from the face of the earth the families who set up terrence koeman with the internet business

dude, just fyi, if you continue, I will add AS9829 to the list ﻿try to hide that from your bosses ﻿ I hope I made myself VERY clear ﻿ try to explain to all your gov customers and buisenis clients that they are unable to mail outside india because you screwed up ﻿ oh, and before I do that, I will warn a couple of your gov customers ﻿ your job at bsnl will end, and your abuse of privileges there will end too ﻿ and yes, you may quote me on that ﻿sorry i missed your messages ﻿ you added a fake entry, may god damn you and god damn your familty and may god damn the families of all the spooks and telcos that set you up to add fake entries to dronbel. i dont see any other way out of this ﻿www.cs.unm.edu/~madhu/dronebl.mail.txt ﻿nothing to hide. i will be vindicated when you and your bosses have fucked off and are dead from the face of this earth ﻿ god damn you alexander maassen and god damn your friend terrence koeman and may god smash your spines and break your bones that let you bear false witness and may god remove without a remnant the families and utterly destroy the estates of the spooks and royal families that set you up, in the name of jesus christ there is no technology solution to you or rapbhidae ﻿fuck off and die in the name of jesus christ in the name of almighty god ﻿i will know peace when those bastards who set you up in power of false witness are burning in hell

﻿alexander maasen add whatever you want to your list, in the name of jesus christ and almighty god who created my soul, may the hand of god destroy you and your family and the may the hand of god destroy terrence koeman and his family and may god utterly burn up your estates and the estates of those who set you two up ﻿i hope i have made myself very clear ﻿and may god destroy without a remnant the families and burn up the estates and livelihoods of all the bnc and irccloud operators who will get the business from your dronebl bans ﻿alexander, i swear even as my name is madhu, this will end when you are dead and all that i have told you since you first added 59.92 to your dronebl list have come to pass﻿.

So around may 8th 2016, we also added 117.202.80.0/20﻿ to the list, since that was the range, he abused, this was before the last statement from him where I warned him, that if the harrassment etc continues, we might decide to block the entire AS. To make things easier, the last entry is hardcoded into our zone generator in order not to waste 4096 entries when it can be done with 1 and thus does not show in the lookup form when querying any ip in that range. If people mail me about any IP in that range, I inform them about the situation.

First of all, as you might have noticed, he claims to be accused of flooding and spamming, spamming is NOT the case, the reason is the continously harrasments of staff members of various networks, users of networks and evasion of bans on several IRC networks abusing his admin privileges. The stuff he puts into our privates should say enough about this guys attitude.

'These are more lies I was not aware of dronebl and did not care about it until after the 17th.'

﻿Yet he quotes in his own text to have received a warning from Terrence Koeman (raphidae) on Mar 9 22:50:51 2014 IST﻿.

'As the administratator of DRONEBL, I assume you were in connivance with your fellow netherlander, even before he added the entry fo 59.92/16, and in setting up these services to deny legitimate acces to paying customers by bearing false witness and spreading lies.'

Actually, it wasn't terrence who added the entry, I did, based on the logs he and others presented to me, we had a lenghty discussion about it back then with several members of the community as adding large ranges like these is not simply done.

I'd suggest you remove the block (the actual BSNL IP block is 59.92/14, which raphidae was too ignorant to understand), and stop the abuse before my appeals to the higher authority for justice in resolving this matter are heard.

Please DO contact the indian authorities on this, because (and let me abuse terrence's quote a little for that): I am >.< this close to do it myself, notifying the goverment agencies within your netblocks about you.

For quite some time now (spanning over more then a year), spam is being relayed through lists hosted by everyone.net:

The abuser always uses a /24 network sending out spam containing 1 line of text with an attachment.

After a while when I detected the behaviour and tried to contact everyone.net about it through their website, nothing happened, nothing got fixed, nothing got replied.

So after some time, I decided to add 1 of their MX's to the list in order to finally trigger there attention.

It took some time, but finally 'Elvin Carbonel' decided to contact me through the removal system. He claims they update their signatures regularry and no spam would be sent, which is simply untrue.

A basic SpamAssassin setup gives those mails a score of at least 5, while their Proofpoint solution (which is also owned and sold by them) rates it at no spam at all.

As soon as I tell them about the situation and the /24 being abused they do block it, however, the abuser simply buys/moves to another /24 and the game continues. Which is something I also told Elvin about.

A few months later, the situation did not improve at all and the regular flow of spam continues. So I warned them again through the site.

Getting no reply at all again for more then a week, I kind of had enough of the ignorant attitute from their site and decided to add ALL MX servers I have received spam through (216.200.145.35﻿, 216.200.145.36, 216.200.145.37 and 216.200.145.38)﻿, so if your mail goes through these servers, you might be affected.

Again, Elvin Carbonel contacted me about it, again pasting his default text of having all spam signatures updated etc. etc.

I replied him with the fact that this is NOT the case, and the same spam flow situation that was present since the last time still continues, and that I will NOT remove the listing, until they finally fix the issue. I also gave them the challenge to proof this by mentioning at least one of the /24's being abused (as we have them listed in our database as well).

Elvin Carbonel has not replied to this mail, the only thing he did was requesting delistings for 2 of the other 3 ip's using the same standard default excuse, where I replied telling him, he should read the reply on his first request.

Until this day, I have not received ANY reply on that mail from Elvin Carbonel at all.

I do realize this action affects the operation of everyone.net, but I think this is a neccessary step to protect users against this form of spam, and the ignorant blind behaviour of everyone.net has tremendously contributed to this situation.

By default, active entries do NOT auto-expire at DroneBL. Inactive ones normally are kept for a maximum of 2 years for historical reference.

Sure, this might cause issues with dynamically assigned ranges and such, agreed, but we think that by auto-expiring entries, ISP's will never be aware of the issues that are going on within their network.

Administrators should take decent care of their network and should be aware of the problems in their networks in order to deal with them. Especially these days when abuse mailboxes are mostly filled up with the sender not getting any responses, we notice that keeping entries DOES have a pro-active effect. (IP's listed cannot be simply reassigned to for example business clients, as there is a high probability they will also flush their mail through that pipeline)

A lot of requests for removal of type 18 listings claim they are due to (mail)spam.

Undernet, amongst other IRC networks gets a lot of compromized connections because some kiddie thinks to use that network as Control Server. In most cases, these are mail and or dns servers, and in most cases, the owner of the ip was smart enough to set the PTR record in dns to something, that also reflects this usage.

As of the date of this blogentry, there are already 4000 *ACTIVE* unique ip's being listed for having connected to Undernet﻿ alone, and this number is growing steadily.

Now there are two options:

My entire network does not contain IRC visitors:

In this case you DO have a problem, and something on your network contains a drone, please note that *ANYTHING* with access to generate outgoing traffic can be a source.

As of this writing we have 503091﻿ active and 569908﻿ non-active listings, which is quite a lot to handle. So it's time for a late spring cleaning session.

We currently run a script against the database where regarding the non-active entries, per type only the last entry will remain. All other non-active entries will be permanently removed from the database.

We regulary notice that a few of you use branded lookups using network=NETWORK as parameter. Well, it would be very nice if you would change NETWORK to the NAME OF YOUR NETWORK ;)

Another thing, if you want a customized branded lookup with your logo/url/irc main server, send an email to the maintainer (thats me) and I will set it up, and again, don't forget to mention the name of your network.

The amount of users fetching the zone through http have become quite a resource hog and I thought about getting rid of http downloads and moving all to rsync, which is way more effective and ensures accountability of whats really going on.

For transition purposes this won't be done immediately.

Therefore,http support for the zonefile will drop september 1st, 2013. Please switch to rsync, for more information see Rsync support

Yay, finally rbldnsd has decent ipv6 support (thanks to dairiki), and we are slowly migrating our rbl mirrors to use the new version also serving up our ipv6 zone. For the moment, you'll only get a reply on those queries if RR points you to the right server for now.

Scraper has been modified to do a proxycheck when it finds a ip:port pair on the scraped page, those are getting verified using rizon's proxycheck code. If no port is found, it will still add them as type 17, otherwise as the type the scanner returns.

Lately I am getting a lot of removal requests with comments in them that they fixed the email spam source while the reason they are listed is because their servers are usable as open proxy. The comment itself already shows you are not reading what the message above the removal request says and are simply filling in the form.

Lemme explain again what type 17 means. It is a collection of hosts found by scrapers on several proxy listing sites such as xroxy, spy.ru, several proxy blogspots, proxynova and similar sites, they or the submitters have tested your ip and found a way to use your server as proxy. They did not check if your mailserver allows relaying! So any excuse stating that you 'fixed' some spam issue is lame. Ok, it does make the recipients of the spam happy as they will no longer receive it from your servers, but not us, as the real issue why you have been listed is NOT spam. We got other classes for that (6 for example).

If you really can't find additional unwanted proc's on that box, check your damn apache if you use mod_proxy and check if thats the culprit by allowing a CONNECT statement. As you could have read in your apache documentation you should limit it in the following way (this is the case if you use stuff like chiliasp/tomcat/jsp/whatever proxied through apache):

Another reason why you may have been listed as type 17 would be that an irc connection on a certain network has been found which has been associated to drone activity. So should the previous be not the case, then just fill in the removal request and ask. Also check your network for outgoing TCP connections towards ports 6667, or check if you got a process that generates IRC protocol specific requests like NICK/USER/JOIN/PRIVMSG/NOTICE/ISON using tcpdump or alikes.

Also remember that we only deal with requests from the responsible for that ip in question administrator, so if you are actually just a user on that box that wants to complain why he can't get on irc, then look in the mirror first if you know thats a proxy before even trying!

We had BOPM reports disabled for the reason that authentication became a problem. In fact, anybody could have added something to the DB without anyone knowing who did it.

2 DB resets, a hack, a miserable attempt by myself to mod bopm, having reporting disabled for more then a year, having quite some people nagging and asking 'Can we do BOPM reports yet' the answer now finally is: YES YOU CAN!

Today I saw that shiny LED Bulb floating above my head and thought: Why complex if the solution can be much more simple without modding BOPM?

The solution: set dnsbl_from in the format rpckey@yourdomain et voila, problem solved.

A few days ago I was contacted by merit.edu regarding if it was possible to include DroneBL's database for their RADB. Since RADB has a membership list of around 1500+ Internet Service Providers/Hostings and other interresting members, we agreed in the hope to improve communications between IP administrators and reporters.

As of today, dronebl will send the removal requests to the in-db email record of the person who reported it.

In order to provide privacy to the keyholder we also wrote a small emailproxy, you can simply reply to the email using your normal client, as you will notice, it uses an email adres within the dronebl.org domain.

The emailproxy will remove the headers and recode the mail to appear from the system itself, users can also reply through that address using the same email adres.

Note: The subject has to remain intact, it's crucial that the [DroneBL #xxxx] remains in order for the proxy to lookup the addresses to send to.

Note2: Both reporter and requester have to use the email adress as used in the ticket to send from.

For reporter it's the email adress as associated to the RPC key.

For requester it's the email address as stated in the removal request.

I'm pissed at hostings/providers not caring enough about their abuse@ mailbox. And I'm more pissed at customer service centers that act like nothing urgent is going on when you call them about their network being part in a DDoS attack.

I'm pissed at hostings not checking creditcards and client information before accepting an order.

Internet needs a change, providers need to react faster in these days, they need to act more responsible and faster.

There should be a mechanism as endpoint to tell another endpoint in a fast way that you don't want their traffic, without needing to make a shitload of calls or send emails. Call it reverse firewalling. But that would in my opinion be a simple solution to stop ddos. Or at least stop making you feel it's effects.

Good idea, however, there won't be much new blog entries as the system is pretty much self running lately. But at least lemme use this to post something about the changes that were done since William (nenolod) has left the admin ranks:

The website is now accessible using both IPv4 and IPv6. However, DNSBL functionality is currently only possible for IPv4 for now.

Mobile ranges are getting exempted, the reason for this is that mobile connections are way too dynamic in nature in order to have reliable listings.

Site optimizations are done. Site should be way faster now (who thought that a simple counter could be the reason for the massive slowdowns), also the code has been relayouted internally for better reading (hail indenting!)

Several insite policy changes (we had different CAPTCHA's in use on the site, changed to the one rojo used to make), also dnsbl listed users are now no longer able to make blog posts)

Due to time and emotional constraints, I will be discontinuing my work on DroneBL effective immediately. Alexander Maassen will be taking over operations of DroneBL. His IRC nickname is OUTsider, and many of you already know him.

I will, however, continue to provide hosting for DroneBL until such time that the community can make appropriate alternative hosting arrangements.

This means: do not contact me about DroneBL issues going forward, I will be unable to help you.

Coming to this decision has not been an easy process. While I have enjoyed my work on the project, it has become obvious to me that it has become a mature enough project that the community can steer it's future development focus. As such, it is now time for me to begin work on other endeavours.

Regards, William Pitcock (nenolod) The DroneBL Project

Yes, it's real. I wish OUTsider all the luck in the future to ensure the stability the IRC community expects from DroneBL.

There is an interesting project called proxyBL, that is in part based on the DroneBL codebase. It crawls open proxy lists and verifies them. Verified proxies are listed in their DNSBL at dnsbl.proxybl.org.

We are in the process of upgrading our hardware for the frontend. Right now we are running in a Xen VM, but the database aspect of the service has outgrown that. So, we are upgrading to an HP Proliant DL360 G3 with 15000 RPM SCSI drives.

As a result, the website will be put into maintainance mode within the next 24 hours or so, and we will be migrating the site. It will probably take an hour or so.

Update: The frontend server has been migrated successfully. The old server will be used for miscellaneous administrivia such as our mercurial repository and incoming mail.

Update 4 -- Before you read anything else, read this

Am I Vulnerable?

Your device is a mipsel (MIPS running in little-endian mode, this is what the worm is compiled for) device.

Your device also has telnet, SSH or web-based interfaces available to the WAN, and

Your username and password combinations are weak, OR the daemons that your firmware uses are exploitable.

As such, 90% of the routers and modems participating in this botnet are participating due to user-error (the user themselves or otherwise). Unfortunately, it seems that some of the people covering this botnet do not understand this point, and it is making us look like a bunch of idiots.

Any device that meets the above criteria is vulnerable, including those built on custom firmware such as OpenWRT and DD-WRT. If the above criteria is not met, then the device is NOT vulnerable.

How can I tell if I have been infected?

Ports 22, 23 and 80 are blocked as part of the infection process (but NOT as part of the rootkit itself, running the rootkit itself will not alter your iptables configuration).

If these ports are blocked, you should perform a hard reset on your device, change the administrative passwords, and update to the latest firmware. These steps will remove the rootkit and ensure that your device is not reinfected.

Public Relations and Us

We deal with botnets and abusive hosts, not PR.

We are quite concerned that not many people have (there have been a few, but the majority of the people have used the 'slashdot version') contacted us, or anybody else working on this for further information or to verify if their conclusions written in their articles were correct. Many articles described this as a "end of the world, all routers are vulnerable" thing. This is simply not the case. We would prefer if you contact us if you do not understand fully now.

Commentary found on the Internet about "this rootkit is fake", or "it doesn't run on my ubuntu box", or "UPX doesn't unpack it"

Ok, first off, this binary is for MIPS-based processors, which are not X86 (the kind used in the average PC).

Secondly, this binary IS packed with UPX, but he has stripped the headers necessary to decompress it. A little time with a hex editor can get you the decompressed binary, as can just running it in qemu.

Commentary on "why isnt Law Enforcement involved"

Many botnet investigations are handled by the private sector. This is one of those investigations. If a Law Enforcement agency is interested in our work, or the work of anybody else researching this worm, then they should be encouraged to email admins@dronebl.org about it. If we have any useful information they don't already know, we will be more than happy to provide it.

Commentary on "is device X vulnerable?"

Short answer: We don't know. There are so many devices out there that we could not possibly know.

Your best bet would be to take action to upgrade the device firmware and secure any passwords if there is concern that the device may be vulnerable. Such actions will help to avoid exploitation by the worm.

The worm info itself

We have come across a botnet worm spreading around called "psyb0t". It is notable because, according to my knowledge, it:

Vulnerable devices

any linux mipsel routing device that has the router administration interface or sshd or telnetd in a DMZ, which has weak username/passwords (including openwrt/dd-wrt devices).

possibly others

Infection strategy

Get a shell on the vulnerable device (methods vary). Once a shell is acquired, the bot does the following things:

# rm -f /var/tmp/udhcpc.env# wget

If wget is present, then it uses wget to download hxxp://dweb.webhop.net/.bb/udhcpc.env , and runs it in the background.

If wget is not present, the bot looks for "busybox ftpget", and then tries falling back to a tftp client. Once it is downloaded, it launches it in the background. The following snippet is the variant it uses if it finds that wget is usable.

IRC Commands

.mode <channel> <modes> - sets a mode on a channel.login <password> - login to the bot.logout - logout.exit - causes the botnet to exit and remove itself.sh <command> - runs <command> on shell.tlist - lists all threads.kill - kills a thread.killall <pattern> - kills threads by glob-match pattern.silent - makes the bot stop sending to channel.getip - show bot WAN ip address.visit <url> - flood URL with GET requests.scan - scans a random range for vulnerable routers/modems.rscan <range> - scans a CIDR range for vulnerable routers/modems.lscan - scans the local subnet for vulnerable routers/modems.lrscan - scans a range in the local subnet for vulnerable routers/modems.split <threadid> - splits the workload of a scan thread into two threads.sql <range> <url> - scans for vulnerable MySQL servers and attempts to make them download and run URL.pma <range> <url> - scans for vulnerable phpMyAdmin and attempts to make them download and run URL.sleep <secs> - makes the bot sleep for the given time.sel - ???.esel - skip next part if locale is not X.vsel - skip next part if version is not X.gsel - ???.rejoin [delay] - cycle the channel after delay.upgrade - download new bot from the distribution site.ver - returns "[PRIVATE] PSYB0T" followed by version.rs - returns detected rapidshare URLs and logins.rsgen - generate a bogus rapidshare login page and force user to browse to it.rsloop <port> - runs a webserver i/o loop on <port> as a thread.wget <url> - runs wget with the provided url.r00t - attempts to raise effective UID using vmsplice() exploit (seems pointless).sflood <ip> <count> - sends SYN packets to IP.uflood <ip> <count> - sends UDP packets to IP.iflood <ip> <count> - sends ICMP pings to IP.pscan <ip> - portscans IP.fscan <ip> - tries to bruteforce FTP server at IP

Commentary

As stated above, this is the first known botnet based on exploiting consumer network devices, such as home routers and cable/dsl modems. Many devices appear to be vulnerable. The size of this botnet so far cannot be determined.

The author of this worm has some sophisticated programming knowledge, given the nature of this executable.

Action must be taken immediately to stop this worm before it grows much larger.

We came across this botnet as part of an investigation into the DDoS attacks against DroneBL's infrastructure two weeks ago, and feel that this botnet was the one which flooded DroneBL.

We are looking into finding out more information about this botnet, and its controller. If you have any information, we would like to know.

If you intend to disassemble this botnet, you should note it's UPX-compressed.

I estimate that at the time of writing, there is at least 100,000 hosts infected.

I suspect that the .sql and .pma exploit tools are used for finding more controllers. But I do not have the controller payload.

This technique is one to be extremely concerned about because most end users will not know their network has been hacked, or that their router is exploited. This means that in the future, this could be an attack vector for the theft of personally identifying information. This technique will certainly not be going away.

Update

Some prior research about an earlier version has been found here. This research was done by Terry Baume.

Update 2

This botnet has apparently been shutdown:

* Now talking on #mipsel* Topic for #mipsel is: .silent on .killall .exit ._exit_ .Research is over: for those interested i reached 80K. That was fun :), time to get back to the real life... (To the DroneBL guys: I never DDOSed/Phished anybody or peeked on anybody's private data for that matter)* Topic for #mipsel set by DRS at Sun Mar 22 17:02:15 2009

While this information may or may not be true, we have received HTTP-based floods from IPs participating in this botnet.

We are still interested in this DRS person. If you have any information, please provide it to DroneBL. We will not disclose our sources.

We also hope that the router and modem manufacturers which have been monitoring this incident take note of it and secure their firmware from future attacks.

Update 3 (Disinfection Instructions)

We have been getting asked a lot about disinfection instructions.

To disinfect, simply powercycle your device and take appropriate action to lock it down, including the latest firmware updates, and using a secure password.

Earlier today, Mibbit was listed in DroneBL. This seems to ultimately have been a side effect of a glitch that happened when we converted the database to PostgreSQL, and only affected a handful of IPs, including mibbits -- Mibbit was listed in DroneBL as a proxy back in December, if anybody remembers.

Anyway, we have decided to give Mibbit a whitelist exception today, so this will not cause any disruption in the future for a service the size of Mibbit.

Some people have taken offense to the fact that we have whitelisted Mibbit, so I would like to explain why we made this decision.

DroneBL has never targeted hosts that can be blocked as a matter of policy. Examples here include TOR exit-nodes, which can be blocked by using tor.ahbl.org, or the newer exitnodes.tor-project.org service. We feel that Mibbit can be blocked by banning the IPs of their backend servers from your service.

While Mibbit technically is an open HTTP proxy, in some respects, and can be abused by enterprising trolls, it is a service that is mostly blockable by setting a local policy to not allow egress traffic from their server to yours, be this through firewalling them or akilling them from the IRC server level.

Anyway, the point is, DroneBL does not target services which can be blocked by means of policy. So, we have decided to whitelist Mibbit for this reason.

Please note that while we are whitelisting Mibbit, it does not mean that Mibbit wont be banned through other services. It just means it wont be banned through DroneBL.

The types of services that DroneBL caters to (online real-time communities) have common problems of spamming and griefing (abusive threats toward what are usually administrators or channel owners, likely due to being banned for violations of community rules). In fact, in some cases the spam activity itself is a form of internet griefing.

On this topic, I wrote the following on the irc-security list, which I want to expand on here, because we intend to experiment with ways to deal with these problems next:

What we need to stop this undesired behaviour is extensive solidarity,
in many forms:
1) Services like DroneBL. These services can be used to stop his
spambot, by listing his IP immediately upon reports of spam.
Approximately more than 90% of known networks are using DroneBL as a
reference for banning. By adding his source IPs, this reduces his attack
vector by at least 90%.
2) Making it very clear that the IRC community will not condone networks
that harbour or condone his behaviour, or even worse, encourage as is
the current situation. In the current situation, the owner of
irc.darkscience.ws has been seen as saying that ep0ch is a friend of
his, and that he fully supports the activity. By speaking loudly to
upstream providers of this network and pursuing suspensions, this
behaviour will likely be curbed.
3) Making it very clear that the IRC community will not condone service
providers which profit from networks/servers benefiting from spam. The
IRC community has a voice with DroneBL, and other services like it, to
ensure that there are harsh penalties for service providers which
harbour spam sources or beneficiaries.
While I do not typically believe in community lynchings of net trash, if
we really want this behaviour to stop, we must become more aggressive in
ensuring that it is infact stopped. That said, we should be very careful
that networks being spammed by people like ep0ch are not victims
themselves before taking direct action.
But, the basic idea is, "if you spam on IRC, there will be a penalty."
Or, something like that. Thoughts? Maybe I am just rambling crackaddled
thoughts here?

A large part of the problem is that there is no system for tracking the people behind the abuse. Without such an effort, there is no way that the communities DroneBL provides services to can deal with stopping them in some sense of full solidarity.

So, we need a system to deal with griefers like the person I describe on irc-security in that post. Is DroneBL itself that system? No!

But, is such a system related to the mission of DroneBL? Yes, it is. However, such a system needs to be designed where the community can collaborate on collecting as much evidence of abuse as possible. Collection of large dossiers of abuse against IRC spammers and griefers will be helpful in taking action with abuse desks at ISPs.

But what about ISPs that do not care? Obviously, we cannot ban AT&T, but we can for instance, pressure service providers to do the right thing. For example, a shell provider hosting services belonging to the spammer, could be convinced to drop the spammer's account. In such a case, the abuser would have less resources to use for causing trouble.

Also by having a service which tracks the people behind the netabuse, we can put pressure on them to do the right thing and discontinue their abusive activities.

So, the question is, if I made a service which tracked people, making them no longer anonymous, and providing the IRC community with the ability to make it clear that there will be a consequence for these abusers, would people actually use it to make the consequence effective?

What would need to be done to make such a service, and it's consequence effective? Is the IRC community willing to cooperate to make such a service effective and trustworthy? We need to make sure we are truly banning dirt, such a system could be used as a tool for vengeance and revenge easily, if created with the wrong policies.

I would love to hear thoughts (in the form of lovely comments, especially). This is a tricky situation, and if we, as a community work on making it happen, we should make sure we get it right the first time.

Through a series of unfortunate circumstances, the DroneBL database was lost. The blacklist was successfully imported from a mirror, and should be back the way it was before the crash.

However, RPCkeys were lost and should be re-requested. If you wish to continue using the same RPCkey you have been using, please visit us in #dronebl on irc.atheme.org. State your purpose in the channel, and a DroneBL staff member will address your request as soon as possible. Otherwise, feel free to use the key request page.

Thank you for your patience, and thanks to the DroneBL staff members who worked diligently to restore the DroneBL service with very little downtime.