Figured out why ctcp finger tcl wasnt catching spam drones

Gothic-Angel · Post by **Gothic-Angel** » Fri Oct 11, 2002 11:54 pm

Well I had tested my bots vulnerability to floods, locked down channel floods however pm floods would of course flood my bots off. So I set my bots mode to +R, well on dal.net +R wont allow you to recieve finger reply's from non registered users. Of course the spam drones are not registered so no reply, no reply means no kick/ban.

Now the problem comes along as how to remove +R and keep my bots safe from pm floods? Any suggestions?

darko`` · Post by **darko``** » Sat Oct 12, 2002 8:50 am

Um, i don't really see why not use eggdrop's own flood protection. Both msg and ctcp limits can be set.

Gothic-Angel · Post by **Gothic-Angel** » Mon Oct 14, 2002 7:19 pm

Well I did set that and still doesnt seem to do anything other than crap out and die.

Post by **caesar** » Tue Oct 15, 2002 3:45 am

R.I.P.

Well, you can see the bind for flud and make something more eficient. Give it a try.

ppslim · Post by **ppslim** » Tue Oct 15, 2002 5:09 am

WHat does it de when it carps out and dies?

Does it die, or does it disconnect from the server? Each one is different.

What settings are you using in the flood settings?

What connection is the bot on?

Gothic-Angel · Post by **Gothic-Angel** » Thu Oct 17, 2002 6:25 pm

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.

Nexus6 · Post by **Nexus6** » Thu Oct 17, 2002 6:37 pm

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)

ppslim · Post by **ppslim** » Fri Oct 18, 2002 3:17 am

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

SOmthing like 5:3 woul dbe more suitable.

Gothic-Angel · Post by **Gothic-Angel** » Sun Oct 20, 2002 12:16 am

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.

ppslim · Post by **ppslim** » Sun Oct 20, 2002 7:04 am

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.

Gothic-Angel · Post by **Gothic-Angel** » Tue Oct 22, 2002 3:47 pm

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.

ppslim · Post by **ppslim** » Tue Oct 22, 2002 4:12 pm

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

Flood prone and detection or Not floodable with no detection.

Gothic-Angel · Post by **Gothic-Angel** » Wed Oct 23, 2002 9:42 am

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.

ttigger · Post by **ttigger** » Wed Oct 30, 2002 9:50 am

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

Gothic-Angel · Post by **Gothic-Angel** » Wed Oct 30, 2002 10:48 am

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.