unity-src
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Unity-irc3] Banning from the entire network, part two


From: Jan Krueger
Subject: Re: [Unity-irc3] Banning from the entire network, part two
Date: Thu, 10 Apr 2003 02:36:06 +0200

David Westley <address@hidden> wrote on 2003-04-10 00:55:
> yeah ok I see your point but the ircd will eat more memory this way as it 
> could have multiple bans of the same host and/or overlapping bans...
Not really. All ircds will only have the mask of the ban in their memory,
everything else is handled by the blacklist/ban server. The blacklist server
doesn't have to keep all bans in memory all the time, an SQL database or
something alike could be used. I think it doesn't really matter if a new ban
gets active after 1 second or 3 seconds.

-------------------------------------------

Another example to explain the tech stuff.
We have the following servers:
server1, server5 and server10 (level 1, 5, 10 respectively)
plus the blacklist server.
The following opers are online:
- address@hidden (level 2 - I did mention special opers can get higher levels
                           than their server, didn't I? :))
- address@hidden (level 5)

All servers locally activate blacklist entries when they have level 6 or
higher.

Initial situation: no bans set at all.

1. Current time: 10000
   server5 sends a ban to BL. Fictive protocol message:
   FROM address@hidden ADDBAN *.cc(mask) 5(level) 12345(expiration timestamp) \
   {Network abuse and general security risk}(reason)
   (the "\" indicates line wrapping here)

   BL adds the ban into the database and notifies all servers of the new ban:
   ADDBAN *.cc(mask) 5(level) {Network abuse and general security risk}

   The level of the ban is too low, so no reaction.
   The ban list of server1 and server10 stays empty.

2. Current time: 10100
   server1 sends a ban to BL. Fictive protocol message:
   FROM address@hidden ADDBAN *.cc 2 56789 {Flooding}

   BL adds the ban into the database and notifies all servers of the new ban:
   ADDBAN *.cc 7 {<reason>}
   (It's 6 because it was level 5 before and we added level 2 now)

   All servers that haven't already activated the ban locally (since server1
   and server5 probably trust themselves, the ban is already active there)
   activate it now since the level is high enough.
   The ban list of server10 looks like this now:
   - *.cc [ACTIVE]

   // XXX //
   What I'm a little unsure about yet is what reason gets the higher priority.
   I'd say the newest ban should win here, i.e. "Flooding" should get
   displayed in this case.

3. Current time: 12400
   BL notices that the first ban has expired and notifies all servers of the
   new version of the ban:
   ADDBAN *.cc 1

   server5 and server10 will now remove the ban from their lists.

4. Current time: 56800
   BL notices that the second ban has expired and notifies all servers that
   the ban doesn't exist any longer:
   ADDBAN *.cc 0

   server1 removes the ban from its list and *.cc is globally unbanned now.
   The ban database of BL is empty as well.

--------------------------------

As you can see, the memory consumption is minimal for the ircds. Also, the
blacklist server won't have a lot to do. If we limit the granularity of bans
to, say, 10 minutes, it will only have to do a SQL query every 10 minutes and
send messages to some servers. We won't even need caching since we're not in a
hurry.

Jan

Attachment: pgp5pLPkKbi5d.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]