View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004114||unreal||ircd||public||2012-06-27 13:16||2015-07-04 15:43|
|Fixed in Version||3.4-beta1|
|Summary||0004114: Matching users' IP addresses against DNSBLs|
|Description||Currently, there are a number of IRCds (Charybdis, InspIRCd) that allow for DNSBL checking on-connect with configurable blacklists; on UnrealIRCd, auxilliary services or bots usually have to do that. That is prone to being a single point of failure, unless each server runs a bot locally, and results in more configuration overhead and more management clutter, aside from the possibility of bots being too slow to remove the bots before they can do harm.|
I therefore propose implementing DNSBL checking. There currently exists a module on http://www.unrealircd.com/modules/view/52 but it was last updated in 2006 and Syzop called it experimental.
|Tags||No tags attached.|
|3rd party modules|
>unless each server runs a bot locally
You can have a single bopm bot monitor globally (all your network's connections).
>bots being too slow to remove the bots
Normally, the only slowing would be the ping between the bot and the ircd (x2). If the bopm has a ping of 0.15sec then the bots will get removed 0.30(+dnsbl response time)sec after they have connected.
Having a the ircd to manage that, the only slowdown would be the dnsbl's response time.
I still have to agree that such a module (or core feature) would really be useful, for example, in the following cases that come to my mind:
* users on systems with limited background processes
* less time to remove the bots
* more user-friendly security setup (don't have to mess up wih bopm at all)
||Agree on everything, most dnsbl bots are gay and retarded (BOPM is the gayest of them all). The only well functioning dnsbl shit I've found is not a very customizable (yet it does its work brilliantly) module. Shipping a dnsbl module with unreal would be a pretty nice feature.|
>You can have a single bopm bot monitor globally (all your network's connections)
Assuming you have a relatively large botnet hammering, a single point of failure is probably a bad idea.
>Having a the ircd to manage that, the only slowdown would be the dnsbl's response time.
You could stall the user's connection (which would go especially unnoticed if you're sending an ident query as well) until you get a response or a lack thereof. It would be pretty much impossible to cause damage.
That said, there is a third-party module (http://www.unrealircd.com/modules/view/52), but it's considered experimental and was last updated in 2006, I don't know how it would hold up. I'd love to see this being in the core instead.
I agree. This functionality should be in a module shipped with UnrealIRCd.
UnrealIRCd has so many security / anti-spam / anti-bot features built-in, yet this one is lacking...
The module you refer to indeed has some serious bugs. I wrote that comment a long time ago (but since then nothing has changed) so I don't fully remember, but it probably has to do with rehashing without canceling DNS requests / read-after-free / race-conditions... that kind of stuff... bugs that can take down your server.
Is it still relevant?
Added in 3.4-alpha5.
Only thing currently left on my list is simple variable support in blacklist::reason. Will probably follow soon.
Maybe some exception block as well. Though I suppose the except ban / except tkl blocks should also suffice for that. (Maybe have it check those bans and don't issue the request at all... just maybe...)
Documentation is here by the way:
|2012-06-27 13:16||CuleX||New Issue|
|2012-08-22 08:45||n0kS||Note Added: 0017100|
|2012-08-22 12:32||Severus_Snape||Note Added: 0017103|
|2012-08-22 12:57||CuleX||Note Added: 0017104|
|2012-09-24 10:26||syzop||Note Added: 0017133|
|2012-09-24 10:26||syzop||Status||new => confirmed|
|2014-09-28 12:45||Zoddo||Note Added: 0018244|
|2014-10-03 20:31||syzop||Note Added: 0018249|
|2015-07-04 15:41||syzop||Note Added: 0018431|
|2015-07-04 15:41||syzop||Status||confirmed => resolved|
|2015-07-04 15:41||syzop||Fixed in Version||=> 3.4-beta1|
|2015-07-04 15:41||syzop||Resolution||open => fixed|
|2015-07-04 15:41||syzop||Assigned To||=> syzop|
|2015-07-04 15:42||syzop||Note Added: 0018432|
|2015-07-04 15:43||syzop||Note Edited: 0018431||View Revisions|