egghelp/eggheads community

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-31T10:35:14-04:00

Well this comes back to the fact, "How do you know your channel users can be trusted?"

although the two bot system is an interesating way of doing it. But it still is damn iffy. Only way to prevent it is to find out who is feeding the nicklist, and since that is pratically impossible, all you can do is to ignore the spammers really. Make a script that only accepts pms from people who are on channels you are on. Or something like that.

Only way i see this is to work is by doing something on the server side TBH, and i know most networks wont do that. the spamming sheite is the whole reason why we stay off the big networks. Too much hassle all round

Statistics: Posted by Weirdo — Thu Oct 31, 2002 10:35 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-31T09:53:36-04:00

What he is saying, can't be covered by no-spam.

It's as simple, as me joining your channel, talking normaly, and not doing any spamming.

Yet, while I do this, I am feeding a drone the nicklist of the channel.

This drone isn't on the channel. but is messaging each person in the nicklist.

There is method of detection for this. How can you tell it was me sending the nicklist?

You can't ban them, the drone was not in the channle to begin with.

You can't prevent messages from ourside the channel, because they are being sent directly to the nicknames in the nicklist.

This is a far bigger problem than people think, and it will get worse.

Using a simalar system, to the one no-spam uses (in it's leaf-hub system), you could turn 2 bots into automated spam drones, that are practialy impossible to detect.

Statistics: Posted by ppslim — Thu Oct 31, 2002 9:53 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-31T08:09:09-04:00

Must be a big network to have these sorts of problems. We get spam floods or join floods now or then, which is why we have crowdcontrol script and a spam filter on channel, surprisingly enough, no-spam

Have you thought about contacting the Admins about this problem, or perhaps taking more drastic measures. IE invite only, moderated, or perm banning prone isps?

Statistics: Posted by Weirdo — Thu Oct 31, 2002 8:09 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-30T12:48:13-04:00

ppslim,

Yes that works fine for spammers that are sitting in the channel. The kind of spammer I am talking about is a bit more complex than that.

These spammers have either an eggdrop bot or an mirc bot (not sure yet of which kind) sitting in the channel quietly. Either when a person joins or at random times it will take the nick of the person they want to spam and pass that info onto another bot sitting outside the channel. Again not sure if this bot is eggdrop or mirc either. The bot sitting outside the channel is the one acually spamming the guests/users and not the bot sitting in the channel. It use to be an eggdrop that was sitting in the channel passing nicks/hosts to the spam bot outside the channel. I know this because I used to be able to do a /ctcp #chan ERRMSG Hi and if I got a replay of Hi in return there was a very high probability that it was an eggdrop bot. 95% of the time if I banned that bot the spam would stop. Obviously the bot being banned was not an authorized channel bot. Even if the spam didn't stop (rare) I left the ban stand because there was no reason for an eggdrop that I didn't know about to be sitting in my channel.

Well the times have changed and the coders are getting smarter. I now get private messages from bots outside the channel ALL the time. They private message everything. +o, +v it doesn't matter. Why would they care because the bot is sitting outside of the channel and a +ban is useless. The relay bot sitting in the channel obviously isn't on the same host and I have not found a way to track these loosers down just yet. The spam bots change hosts on a pretty regular basis. I believe using open proxies on port 3128 maybe. Reason I say this is because the bots are almost never IDENT'd and on the network I am on (Undernet). Just about every proxy port I can think of is already banned from the irc servers.

We are having someone now come up with an idle logging script to write to a file rather than kick ilde users over 'x' amount of minutes. This log could be reviewed and we may possibly track down spammers in the channel. It is a shot in the dark but it's a start.

If you have ever come across these kinds of spammers you may have already come up with a solution. If so please let me know. I have a little bit of hair left.

Regards,
ttigger

Statistics: Posted by Guest — Wed Oct 30, 2002 12:48 pm

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-30T11:57:55-04:00

Time to do something real naughty.

no-spam will help detect these drones.

At full functionality, it will detect people sending files (it can be set to ignore certain files), private messages/notices, public messages/notices and invites.

In a hub and leaf style fasion (not eggdrop botnet hubs), the hub will sit in a channel wihout ops and cycle the channel at random times.

The hub will send a OPd leaf (set in the config file), which will then punish the offender.

On top of this, it is entirly up to you, what channels a each detection is done in, and you can set the masks used for detection.

advert mode off

As for detecting drones using CTCP messages.

Most specificaly designed span drones, have the stupid mistake (advantage for us), of replying with certain answers for VERSION and so on. These can be used to ban offenders.

Statistics: Posted by ppslim — Wed Oct 30, 2002 11:57 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-30T10:48:23-04:00

It depends some are just infected with onjoin trojans, other's are the spambots im talking about. The one's im talking about come in and do channel notices, or they pm everyone non op non voiced with a website. After a while if doing that they part and new one's join.

Statistics: Posted by Gothic-Angel — Wed Oct 30, 2002 10:48 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-30T09:50:31-04:00

Gothic-Angel,

What exactly is a spam drone and how do you use ctcp finger to find them? Are these the spam bots that don't sit in any channel yet msg you with spam? I see a lot of this and I thought it was a spammer sitting in the channel relaying users to a spam bot outside the channel. This I have found is hard to track down. If you could shed some light on how you find these spammers I would appreaciate it.

Thanx,
ttigger

Statistics: Posted by Guest — Wed Oct 30, 2002 9:50 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-23T09:42:09-04:00

Yeah I dont care if one of the 5 bots get's flooded off. The 4 others control the flood's very well. Sentinel does a great job at stopping the floods.

I'v had no problems other than this one problem with the finger thing the whole way through, then once I solved the issue another one comes up relating to the same issue.

It's dal.net's fault for not putting any effort fourth to stop the spam drones in the first place.

Statistics: Posted by Gothic-Angel — Wed Oct 23, 2002 9:42 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-22T16:12:02-04:00

I this case then, it's one or the other.

Flood prone and detection or Not floodable with no detection.

Statistics: Posted by ppslim — Tue Oct 22, 2002 4:12 pm

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-22T15:47:30-04:00

Putting the bots mode +R stops SendQ totally. What I did to solve the problem was bring a third eggdrop online for the purpose of one thing, and thats to finger the users to detect the spam drones. Im not much worried if it is flooded off, I have two other's that will do the necessary work who can't be flooded off.

Statistics: Posted by Gothic-Angel — Tue Oct 22, 2002 3:47 pm

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-20T07:04:49-04:00

There is no point flooding the bot, if you know it is gonna SendQ exit.

The SendQ error is generated by the IRC server.

Each connection to the IRC server, has a small buffer, that is populated, when messages are sent to the user. This applies to allmost any netowrk connection in the world.

If no machanism is in place, to halt messages being sent to the buffer, then it overflows. It's this overflow, that causes the error.

Thus, it is the bandwidth and latency between the eggdrop and the IRC server, that is at issue, not eggdrop itself.

Eggdrop will receive the messages it is sent, as fast the connection between the shell and server will allow it, thus, even if the proxy drones are on slow connections, so long as the totaled distributed bandwidth exceeds that of the shell-2-server bandwidth, then a continued burst would eventualy flood the bot off.

My advice would be to use a IRC server, where there is some form of SendQ prevention. This is usualy done by setting a usermode to prevent trafic from reaching you, and send it to /dev/null.

Statistics: Posted by ppslim — Sun Oct 20, 2002 7:04 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-20T00:16:04-04:00

Its not hard to Excess flood or SendQ someone off if you have a large amount of proxies online when you do it. I want my bots to be able to stand up to a large flood so Im not going to test it with like 50 proxies. At the time I flooded it I had 230 proxies online to hit the bot. I want to make sure It can stand up to a massive pm flood if one were to happen.

Its not just Excess Flood it SendQ's as well. What I will probably do it just put another eggdrop online with the sole purpose of using that finger script.

Statistics: Posted by Gothic-Angel — Sun Oct 20, 2002 12:16 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-18T03:17:57-04:00

Using a setting of 1:1 isn't a very good example.

SOmthing like 5:3 woul dbe more suitable.

Statistics: Posted by ppslim — Fri Oct 18, 2002 3:17 am

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-17T18:37:54-04:00

you flooded it because you are user of it, it's rather hard to make someone quit with excess flood msg if you flood him via priv, unless user uses gay scripts, make sure your bot ignores ctcps from nonops, it may also quit with excess flood reason when sends ctcp finger on join, especially during splits (you said it's catching drones)

Statistics: Posted by Nexus6 — Thu Oct 17, 2002 6:37 pm

Figured out why ctcp finger tcl wasnt catching spam drones

2002-10-17T18:25:22-04:00

The bot is on a 300 K/b down 50 K/b Upstream Cable. By crapout and die I mean It will excess flood off the server, I'v set the msg flood protections into sentinel at 1:1, after I did that I flooded the bot and it excess flooded off so I was like hmmm. I tried setting a few other flood settings down low to 1:1 didnt seem to help. So I got sick of trying and just +R'ed the bot. Which stopped me from being able to flood off my bot. This is really the only problem i'v got with my bot's other than that I'v got em working great nice botnet going doing everything I can want. Just this one minor issue.

Statistics: Posted by Gothic-Angel — Thu Oct 17, 2002 6:25 pm