inspircd / inspircd

A modular C++ IRC server (ircd).
https://www.inspircd.org
1.19k stars 269 forks source link

We need more clever and sneaky ways to combat seasoned troublemakers and ban evaders #478

Open Robby- opened 11 years ago

Robby- commented 11 years ago

Every network most likely has their share of persistent troublemakers and ban evaders.

The seasoned troublemakers already know the ropes and tricks to get around things like bans (much to operators annoyance), so we must act in a more clever and sneaky way, which we already do by for example shunning.

To start, I have an idea to complement the shunning of users: Right now, we can shun them so they can stay and not start evading and we can thus 'contain' them sort to speak. But they still can see chats and private messages, so, the more clever ones know something is up when they type something that is bound to get a reaction and they don't get any from anybody in the channel or in private. A way to make them deaf (not with umode +d, as that mode change is shown to the user as it happens) for either or both channel and private messages/notices would be good, so they can't see who is actively chatting, and about what they're talking (so lurking is ruled out), and they thus will not know who they should expect a reaction from. Of course, there are still ways for them to find out if this has been done to them, but again, that's for the more knowledgeable ones amongst them that know what to look for.

Another idea I was thinking about requires cooperation of services. We have for example a persistent ban evader that always attempts to enter specific channels he is banned from. This user is not registered with NickServ and always changes nicks and everything, except his hostmask, which is always from the same ISP (he doesn't do proxies). A while ago I made a feature request for this which @Shawn-Smith created in the form of a 'U:' extban, it allows to set bans on hostmasks so that unregistered users who match that mask can not enter without registering first. Very nice. But now I was also thinking to complement that with optional account aging. For example, require a nick from a specific mask (or !@* for everyone) to be registered for atleast N days before the user can enter. Of course, for this to work, services must send the nick registration timestamp to the server. This could be done upon identifying and stored as additional metadata maybe? Just thinking out loud here.

Yet another idea is to have gecos banning implemented at the ircd-level. Right now a bot handles this for us by looking at incoming connections. Although it is made to also look at the ident and host mask of users so we can narrow it down to for example specific IP-ranges or hostmasks if needed or desired (for example to reduce false positives).

I'll leave it at this for now.

Any ideas, suggestions or thoughts are welcome.

SadieCat commented 11 years ago

Have you considered using wildcard bans on their hostname? For example, if they are connecting from foo.ptld.qwest.net banning *.ptld.qwest.net.

attilamolnar commented 11 years ago

Yet another idea is to have gecos banning implemented at the ircd-level

@Robby- m_rline makes this possible

Robby- commented 11 years ago

@SaberUK Yes, but we have a couple of legit users coming from that ISP/mask too, which we would for them to still be able to enter.

@attilamolnar Oh, I didn't know it could do that.

SadieCat commented 11 years ago

@Robby- ELine the legitimate users?

Robby- commented 11 years ago

@SaberUK The problem with that is that should they do something that require banning we can't ban them without first needing to check existing E-lines. Also, not all cases need server bans, some cases only have channel bans and are allowed to stay on the network, just not those channels.

killerrabbit commented 11 years ago

cmode +R then R: bans.

Robby- commented 11 years ago

@killerrabbit R: only bans accountnames, that is not enough should the user keep registering new nicknames over and over, also, we are a public chat that still wants to allow unregistered users in too.

killerrabbit commented 11 years ago

So, let me get this straight: You want to allow anonymous connections to your channel, except this one guy who has a dynamic IP, but you won't just ban the isp? If an isp is causing trouble, you either disable anonymous connections(+R), or you ban the entire isp. Requiring users to be registered for X time is only going to make people annoyed.

Robby- commented 11 years ago

Yes, we want to keep allowing unregistered connections to the official channels as this is the most user friendly, we would lose users if we were to require registration for everyone. You'd be surprised how many people can't be bothered. Hence this way is preferred, because we can narrow down the registration requirement to a specific group of people so that it doesn't affect everyone. This kind of customization is just great. And banning the whole ISP is not an option either, we would ban innocent people too, including some of our own operators which are a customer there.