This is Bugzilla
Users in the roles selected below can always view this bug: (The assignee and QA contact can always see a bug, and this section does not take effect unless the bug is restricted to at least one group.)
Reporter CC List
View Bug Activity | Format For Printing | XML | Clone This Bug
When you ban an host like *!*@*89-88-158-75* and then !unban the user who have this ip, the bot will remove the ban. Using bruteforce and partial bans (like, for example, *!*@*1??-*-*-*), anybody is able to get IP address of connected users. I wrote a simple Python bot (with the help of Mickael Thomas <mickael9@gmail.com>) which uses this method to get IP address of all members whose IP address belongs to the 3 most famous french ISP, using a simple "!lookup" command. The code is currently there : http://delroth.is-a-geek.org/ipbot.py and should work perfectly on most of the IRC networks which uses Anope. I tested that on two IRC networks using Anope as their service package (irc.epiknet.org and irc.anope.org).
Hi there, I'm not on irc at the minute but I'm interested in your findings... Please reply to this report with my IP address for user 'chaz' on irc.anope.org.
heh, I can indeed confirm this, and as a solution i would suggesting removing bs_fantasy_unban. More longer term, perhaps this module should be moved to a optional module, for networks who are prepared to accept this risk - failing that, maybe remove it all together? opinions? :)
Well to be honest, the best option is to make it optional, but not loaded by default. At least thats my opinion anyway.
Another option is to rewrite all un/ban modules to only ban the currently used host, whether it's a vHost or an encrypted host. This way the script can only discover the banmask used. If the vHost is used then the users real IP is still hidden, if it's an encrypted host, such as what Unreal does by default, the encrypted host is revealed, still hiding the users real IP. ChanServ really doesn't need to know real IP's anyway. real IP's should be exposed to human operators for k/g/zlining. Yes, it's a partial code re-write .. yes, it requires ChanOps to potentially ban the same user 2-3 times to cover their encrypted host and their vHost but most importantly it keeps the users IP hidden. On IRCd's that don't use encrypted hosts, then it's the evading users problem for exposing their real IP on connect, nothing can save them anyway.
re-assigning to devel
I also wanted to mention that my motivation for actually fixing this is because it should be fixed for 1.8, even if that means more testing and more releases prior to RC1.
"Another option is to rewrite all un/ban modules to only ban the currently used host" we can't do this and still have unban functionality work. The problem is the ircd will still check the real ip, as such, our unban needs to do the same thing, if it doesn't then we could end up leaving a user banned after a perfectly valid unban was issued. - I really don't see that changing the way we handle bans so we are not accurate or reliable with them to be of any benefit other than hiding the problem and introducing known bugs (i.e. unban may not always unban you...) As this only effects the fantasy !unban, and not any of the standard unban calls (as they only apply to yourself, not 3rd parties) then I really don't see an issue with dropping this as a core module. We can still provide it, but at the networks own risk after they accept the issue.
I agree with Rob. We should remove it from core modules, and leave a comment about the risks of using the !unban fantasy command.
Alright, we will move bs_fantasy_unban from core to optional modules.
Fixed at revision 1372.