[General] These ISP bans have to stop....

Ask your general or IRC related questions.
rwaldrep
Posts: 2

[General] These ISP bans have to stop....

Post by rwaldrep »

I can't tell you how frustrating it is to try to join my favorite channel(s) only to receive a message about how I cannot join the channel because my "address is banned". #canada, #france, #montreal, and #quebec are all banned to me, and who knows how many other channels that I haven't yet tried to join. Either I can't join the channel at all, or when I join the channel, I'm booted out in a matter of seconds.

I guess since I use roadrunner cable and a few others from roadrunner have abused the system, I am guilty by association.

Why doesn't registering with cservice solve this problem? I've registered, logged in, and even set my mode +x, but the bans continue. Why isn't there some process through which genuine undernet users can get around these bans????

I've been trying to figure out a solution to this problem for weeks and nothing is working. I've called my ISP, and they don't have any suggestions, and they refuse to change my IP address (although I think the entire rr.com ISP is banned anyway, so that's not going to help me). Changing my ISP is a painful, expensive, and ridiculous solution to this problem, which I didn't even cause. And who's to say the new ISP wouldn't be banned, too?

There should be some kind of registration process through which genuine users can pass through a few hurdles and get the access to the channels they have been banned from through no fault of their own. I wouldn't even mind paying a fee, although this is a horrible precedent to set... but if it would solve this problem, I would consider it.

When an entire ISP is blocked, it doesn't bother the spammer, because he can always try another venue... but you seriously hurt the genuine users in the process who are following the rules.

-Randy

gemeau50
Posts: 76
Location: Trois-Rivières, Canada

Post by gemeau50 »

Banning an ISP is done by chanops not the network.
although I think the entire rr.com ISP is banned
Unfortunately, you must be one of a few ligit users from rr.com joining french channels. I am a chanop on another major french channel that you haven't listed. Usually, the type of users we get from rr.com are flooders and spammers.
When an entire ISP is blocked, it doesn't bother the spammer, because he can always try another venue... but you seriously hurt the genuine users in the process who are following the rules.
One of the most difficult part of the job for an admin is to structure a global ban which will hurt the least amount of ligit users possible. Every time we removed our ban on rr.com, we were flooded in matters of days. It's impossible to structure a global ban which doesn't hurt ligit users on the way. That doesn't solve your problem but it may help you understand why this ISP seems to be blocked on major french channels.

rwaldrep
Posts: 2

Post by rwaldrep »

I understand that all chanops have the right to protect their channel from floods and spams, and I don't have a problem with that. But there should be a method for legit users to not end up blocked as well.

Obviously, you must have tried banning individual users first. This wasn't effective enough? From what the people at rr.com told me, the IP addresses are static for a period of anywhere from a few days to 6 months, at the end of which time they are reassigned. So if you were to ban an individual IP, it should keep that particular abuser away for a while, no?

Instead of what the chanops tried, which was to allow the ISP, but ban the individual spammers, why can't the exact opposite be done? That is, ban the overall ISP, but make exceptions to allow the few legit users from that ISP to have access. This could be done, no? If not, it may be necessary to restructure the way global bans are implemented to handle cases like that.

That brings me back to the concept of a special registration step being implemented. Either a message could be sent to the chanop specifying that he/she is a legit user and wants to be allowed access, or some other hurdle that a spambot or flooder bot wouldn't be able to easily bypass.

-Randy

Eenie
Posts: 606
Location: Virginia, USA

Post by Eenie »

For many versions now, mIRC has supported an Exception List to channel bans. (Located in channel central.)
Bans List:
This allows you to view, edit, or remove various types of mode settings, such as bans, exceptions, and invites. Most IRC networks support ban lists, however few support exception and invite lists currently.
This way, a channel op can ban an entire ISP but allow certain users in the channel from that ISP.
Perhaps this would be the answer to your concern if Undernet supported this as well.

Eenie
:)

User avatar
CheckNerd
Posts: 9
Location: Columbus, OH, US

Post by CheckNerd »

This is truly an issue that should be hashed out by chanops of sizeable channels.

Floodbots and spambots are a very common sight now, what with a seemingly unlimited supply of compromised systems using broadband access at the disposal of script kiddies and professional spammers. I realize this sounds a bit alarmist. I have been dealing with this problem in two channels to a limited degree and with some success.

Certain channels on the Undernet network are geared toward serving people of a certain geographic origin. Rwaldrep mentions these channels in his earlier post. For their chanops, it is mighty tempting to blacklist entire ISPs that fall outside their geographic domain. Thus, it is convenient for #France chanops to ban all RoadRunner customers from the US. (This is just an example and I mean no disrespect to the good people of #France.) =)

This approach is not without problems, some of which are obvious:

1. An ISP-wide ban can be unfair, given that some responsibility rests with the ban-makers. They must convince themselves (and others) that the ISP is "predominantly" overrun with infected/compromised hosts and the ISP in question is doing little to deter such problems. With all the ISPs to worry about in the world, this can be a hairy problem.

2. Given the nature of the ircd implementation, a channel ban (such as *!*@*.rr.com) will not allow any RoadRunner customer to enter the channel, whether they're registered (and have enabled a hidden host) or not. Further, it squelches any RoadRunner users already present in the channel. Bans through X are even worse because they "see through" the hidden host and enforce the ISP-wide ban.

There are a few ways to ban ISPs while doing limited (or quick-reversible) damage. The overarching assumption is that false positives are bad.

First goal is to create a mechanism that does not place wide bans. One way to do this is to create a blacklist of ISPs (or hostmasks) you don't want on your channel, and then ban only the host of anyone who matches any of these hostmasks. For example, with eggdrop bots, this is achieved by creating a dummy user (say, IllegalBots) with all blacklisted hostmasks added to it, and then setting flags +dk. A few tweaks to the eggdrop source would place the requisite *!*@domain.host ban (instead of the conventional *!ident@*.host style ban). Furthermore, to protect regular users who are known to be people, you can maintain a whitelist of hostmasks. In our eggdrop example, you could add a dummy user (say, People) and add their usual hostmasks. Set no flags for People, thus ensuring that anyone that matches People does not get banned (but does trigger other events as needed, like normal text-flood, use of color, etc.). This example can be modified to apply to other types of bots as well, I am sure.

The downside: the banlist may get filled quickly during a hot cycle of bots entering, and it is recommended that you use an automated script to flush the channel banlist from time to time.

The upside: none of the authenticated and host-hiding users get banned. Also, you can advertize in the kick message, a way for the user to protect himself/herself from getting banned. I see three ways of doing this: 1. Send a URL to a help site. It may contain registration and host-hiding details. Some users are just lazy to do this, so I do not recommend it. 2. Ask the user to join a help channel. Most people do this, and it is quite popular. Just make sure there's some person in the help channel available. =) 3. Install an automated (but non-ubiquitous) means for the person to unban and protect himself. For instance, an eggdrop script may send the user a friendly message asking him/her to send a passcode to the bot which would unban the user and add him/her to the protected list of hostmasks, i.e., to the user People. To protect the next generation of bots from automatically using an unban strategy, you can vary the language, possibly using the regional language of the channel, to send the passcode.

It may also be beneficial to maintain a script that bans members present in other, questionable channels, that are deemed mutually exclusive from your own. Many drones of this nature flock toward adult channels. If your channel policy does not allow adult content, placing a ban on channels that contain the word "sex" may go a long way. (Again, with no offense intended toward any adult-oriented channels.) Such a script may check if the user matches the People handle, for instance, and choose to ignore that person.

The next goal is to identify spambots. I have noticed that most spambots use a variation of a common name (usual female anglicized names) with possible numerics or punctuation added. Sending a private message such as "hi" usually results in a URL being sent after a few lines (possibly to defeat some schemes introduced before which ban the bot only if the URL appears in the first line, but protects the user if the first line is regular text). I prefer to ban esoteric ISPs outright--there's no point in trying to figure out how many Czech users join a Japanese channel, for example. For a numeric IP or a popular ISP, I prefer to blacklist by a class-C hostmask with the condition that none of the people of the channel match such a wide ban. One way to check is with the help of a "seen" bot.

This analysis of the problem does not take into account a few things:

1. I have not come up for a way to actually measure the success rate. I don't even know what such a success rate would mean, but that's something to think about.

2. This exercise assumes the channel is working on its own without the intervention or assistance of another channel. I know of at least one effort that collects and distributes infected host addresses. I have not worked out how to incorporate that into the whole scheme, but all in all, it should be trivial if such a list could be automatically added to the IllegalBots handle in the example above.

3. Placing channel bans can cause problems where the banned channels are not exclusive from the interests of your channel. I have not worked on how you could resolve this problem.

4. This exercise completely ignores any efforts that an ISP or an IRC network may make to prevent spambots from joining at all.

It is my hope that there are people who are interested in solving this problem and I would be interested to open a dialog on the subject. If you find something objectionable or lacking in the above, let me know. If you know of any inter-channel project working toward this problem, share with us.

-Checkie
``I have nothing to say, and I'm saying it.'' -- John Cage

gemeau50
Posts: 76
Location: Trois-Rivières, Canada

Post by gemeau50 »

CheckNerd, I really enjoyed reading your input in this matter, mainly the part on the eggdrop.
It may also be beneficial to maintain a script that bans members present in other, questionable channels, that are deemed mutually exclusive from your own.
We have such a script. Even though our eggdrops are removing bans after a period of one hour, this script is filling up our channel banlist because it sets a ban on each user. That way, it is very easy to reach the maximum of 45 bans. When the limit is reached, eggdrops become useless. Only bans set in X can exceed the limit of 45 bans. As you know, you can't create a viable banlist in X because the maximum length of time you can set in X is only 14 days.

As for the maintenance of a white list, I believe that I would be impossible to maintain.

User avatar
wensu
Posts: 83
Location: Sydney, Australia

Post by wensu »

Protest to rr.com to either deal with IRC related abuse, or for rr.com to perhaps provide a IRC server themselves, so such abuses can be minimalised and dealt with effectively.

It's up to you legit rr.com clients to use initiative as many other avenues to address the problems have been largely ignored by rr.com

- wensu