I just got owned, by 1 user vs 17eggs.

[Vinh]

Me and a guy have been testing eggdrops.

( 05:28:01 ) ::: ( ¤ ) Channel Mode: SirVinh set mode ( +o ) to akab in #vinh
( 05:28:05 ) ::: ( ¤ ) Channel Mode: SirVinh set mode ( -o ) to SirVinh in #vinh
( 05:28:09 ) ( achoo ) take over
( 05:28:09 ) ::: ( ¤ ) Channel Mode: akab set mode ( -oooo ) to FlyTime HoldMe JohnSouth JohnWest in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: CestPool set mode ( -o+b ) to akab *!bah@*.client2.attbi.com in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: shesout set mode ( -o ) to akab in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: akab set mode ( -oooo ) to MonkeyNet PuffDad shesout superbad in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: akab set mode ( -oooo ) to westerng catass CestPool cyberbad in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: akab set mode ( -oooo ) to CestPool catass cyberbad DogAss in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: akab set mode ( -oooo ) to dognet easye fishkid FlowerBoy in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: easye set mode ( -o ) to akab in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: cyberbad set mode ( -o ) to akab in #vinh
( 05:28:09 ) ::: ( ¤ ) Channel Mode: JohnWest set mode ( -o ) to akab in #vinh


1 user defaced 17eggs.. 4lines of -oooo in 1 sec.
Now how is this stoppable?

If it was the real thing, would of lost my channel

[shadough]

Cestpool should of kicked akab after setting the +b, make sure +enforcebans is set. Although this may have only caused the channel to be desynched. as for the takeover, massdeops sometimes work, an sometimes they dont, like the roll of the dice. the more bots you add, the more secure you become but is there a specific amount that makes the channel untakoverable??? *shrug* Perhaps some1 else on this forum could answer. My botnet is as large as its ever been, 8; but I don't have a fat wallet to get a bunch of shells. Course I have another net w/ 3. Another factor to consider is the bandwidth the bots have and bandwidth of the massdeop'er.

[Fe|on]

I'm pretty sure netbots already has this feature:
http://www.egghelp.org/netbots/doc_components.htm#mass
If I type .mass deop in my hub, it will deop the lot of them

[Vinh]

I guess im going to get like 4more eggs then I give up :/
My bots are split into 2 groups.

Code: Select all

set nb_group(ooo) "catass,flowerboy,easye,cyberbad,cestpool,dognet,puffdad,shesout,superbad"
set nb_group(ddd) "dogass,johnsouth,fishkid,monkeynet,johnwest,westerng,holdme,flytime"

.control *
.netjoin #vinh
.netchanset #vinh chanmode +tn
.netchanset #vinh revenge-mode 1
.netchanset #vinh -greet
.netchanset #vinh -seen
.netchanset #vinh +dontkickops
.netchanset #vinh +protectops
.netchanset #vinh +protectfriend
.netchanset #vinh -autoop
.netchanset #vinh flood-chan 0:0
.netchanset #vinh +revenge
.netchanset #vinh +revengebot
.netchanset #vinh +bitch
.netchanset #vinh +enforcebans

.control ooo (also +superbitch)
.netchanset #vinh +bitch
.netchanset #vinh -enforcebans
.netchanset #vinh +stopnethack
.netchanset #vinh revenge-mode 1

.control ddd (also repeat + sentinel)
.netchanset #vinh revenge-mode 3
.netchanset #vinh -bitch
.netchanset #vinh +enforcebans
.netchanset #vinh -stopnethack

.control cestpool
.netchanset #vinh +enforcebans

.control superbad
.netchanset #vinh +greet

[strikelight]

Implemented properly, a user can deop ~20 clients guaranteed, before eggdrop (let alone ANY other irc client) could react.

There is nothing eggdrop can do about this simply because by the time the eggdrop sees the mass-deops, the deop commands from the user have already been sent through the server (all at once).

This is an irc protocol issue, not an eggdrop issue.

Edit.. there was another thread like this not long ago.. use the search function.
n/m, found the link for you:
http://forum.egghelp.org/viewtopic.php?t=5397

[ppslim]

As strikelight noted, it is power of the numbers.

Efficient massdeops are hard to come by. I have to admit, I have made scripts that would drop allmost any channel on its knees pretty easily.

Before you all ask, take a hike. Coding it isn't somthing I am proud of, it was more proof of concept.

There are a few things you should note from the about mass-deop.

1: That was the work of one person. The IRC protocol allows for this to happen, as normal flood controls are in place for the messages sent and that it allows more than one mode per line.

2: That was one bot. Add a second and depending on how efficient the bots are, could clean up twice as many, 3 bots = 3 times as many.

3: Eggdrop has never pretended to solve this problem. Infact, the phrase "If somebody is determined enough" applies.

THere are a few things you can do to help minimize the problem.

1: All passwords must be strong. You could even introduce a script to make sure that the password qualifies as strong.

2: Know who your users are.

3: Watch what powers you give your users

4: No manual ops

5: +bitch the channel if necesary. Only one bot need have this setting, this will mean you only need to keep maintainance of one bot specificly well (though you shouldn't niglect your other anyhow).

6: Run bots on seperate systems. You should never have more than 1 bot on any specific provider. This increases the chance that whole protection nets of bots can be brought down under a single attack.

Running more than one bot on a system is only advised if they are for the role of gaming, information and non-essential control.

7: This is the one that is rather touchy. More and more and more bots.

There is a large for and a large against here

For: When there is more than one bot deoping, there are more to remove. Makes things harder for the mass-deop to complete.

Against: Expensie and may get them banned by IRC admins.

[dun_dacil]

There is another possibility to try and slow down the mass deop against a botnet, perhaps.

Suppose one has bots A and B, on two different servers. On server A there is also a bad chap, call C.

C deops A and B: but the B deop commands takes a little time to travel to server B (depending on lag): A sees its deop fairly quickly, and suppose it broadcasts to B via PL what is happening: B might have time to react, yes, sending server B the command to kick C and reop A, correct? I mean, there could be some time while server B sees B as op, and broadcasts to the other servers the commands B is issuing, yes?

So, playing on lag and fast PL communication, perhaps there is some room to make a botnet more robust?

dun_dacil

[ppslim]

You are forgetting there is likely more to the latency issue than you talk of.

If userfiles are shared, then any ban placed by bot A will have allready traversed the PL.

However, you have to remember exactly how many points of latency there are.

To get the mode change from BadPersonC, to BotB, there are two paths.

Path 1:

a: BadPersonC to ServerA
b: ServerA to ServerB
c: ServerC to BotB

Path 2:

a: BadPersonC to ServerA
b: ServerA to BotA
c: BotA to BotB

These paths are the same length, however, there are a small hitch in Path 1.

Once ServerA has told ServerB of the change (2 steps), even of BotB doesn't know yet, the servers know BotB is not +o.

While it may be possible that tha partyline message is notified before the server does, it is very unlikely that BotB could process and send out a request in time.

There would allready be a desynch in place, because, for BotA to know about it, ServerA will allready thing BotB is set -o. Thus ServerA would not accept a kick or -o request on BadPersonC

[dun_dacil]

thanks ppslim. Nono, I am aware of the different path length issues and latency, but thanks for reminding me

Reason I ask, in the first place, is that I "live" on the irc italian network: there are two main ircserver groups serving IT, and they are at the largest possible distance on the IRCnet map: we normally experience lags of a few seconds between ppl on the two different chunks: right now I have a fraction of a second to my own server, and around 4 seconds to a server on the other chunk, and viceversa if I swap server. So, the 4 seconds seem to be a "measure" of the latency between the two chunks (see below, though).

I already have some tcl doing things via partyline - it is an observation that very often I see bots (local to my server) doing things before I see the action they refer to (the bots react to something broadcasted via partyline by bots which are on other servers and which sees the action earlier). Of course, nothing like in the example posted and which started the thread. A thing which was common in the past was, for instance, collisions: I could see bots going into anticollision mode before I could see the collision itself: simply, the collided bot would broadcast a warn etc. And for collisions it would work: on a massive bot collisions, it was an observation that a few bots would escape it - the partyline communication made the most remote bots switch nick before the relinked server loaded with fakes managed to pass all the nicks and collide the whole botnet.

I appreciate that any +b by bot A to the userfile is relayed to B via PL: then B checks the channel and imposes it. However I mentioned a kick because what I have in mind is a command by A to B to kick C, via PL, no matter what happens (it seems to me that this should be a touch faster than imposing a +b via usershare).

But I guess that to talk of kick and bans is somehow marginal: the real problem is desynch, at the end of the day. Let me conclude with a question, related to what the topology of irc as I see it is:
I am currently on server irc.tiscalinet.it
To get to, say, irc.flashnet.it (another large IT server) I need to travel:
ircd.tiscali.it
some hub in *.se
some hub in *.stealth.net
some hub in *.tin.it
finally flashnet.it

Suppose kick C by B (on tiscali, say) manages to travel to *se, while deop B by C (on flashent) travelled to stealth: what happens next? For se, C is no longer on the channel (correct?) while for stealth B cannot kick C. Does everything stop here, with a chan desync?

Thanks,

dun_dacil

[BarkerJr]

Something to keep in mind is that bans are set via putquick, but kicks are via putserv. This is by design, to ensure that the bans are set before the user is kicked. Probably the best thing to do would be to deop the user in the same mode line as you ban him or her.

[Vinh]

05:28:09 ) ::: ( ¤ ) Channel Mode: CestPool set mode ( -o+b ) to akab *!bah@*.client2.attbi.com in #vinh


How do you change banmask the bots use?