Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Services Attack  (Read 5479 times)

0 Members and 1 Guest are viewing this topic.

dragoonkain

  • Guest
Services Attack
« on: March 23, 2006, 01:36:30 AM »

I was wondering, if there isn't already a way of doing this...

Would it be possible to include some attack alerts that go across say /chatops or something when the services are being "attacked"?

For instance, right now I loaded up a client and did /timer 50 0 /cs help. Sure enough CS would have sat there and fed me all of that information. On CR, however, the services would have put me on /ignore for about 20-30 seconds, and also alerted the opers "Services are being flooded by host: (hostname)!" Usually we ignore those messages because services will take care of themselves, but sometimes knowing comes in handy.

So, I guess what I'm getting at, are there any anti-attack features I don't know about in Anope?
Logged

diskman

  • Guest
(No subject)
« Reply #1 on: May 21, 2006, 10:14:14 PM »

sounds good could be usefull
a modul like m_connect_flood for cmds
services ignore everyone for x seconds who trigger a cmd more than x times in y seconds
Logged

dragoonkain

  • Guest
(No subject)
« Reply #2 on: May 23, 2006, 09:52:19 PM »

Ideally the system would be even more advanced than what you suggest. Using a weight system (commands that require more bytes sent will add more weight to the user's flood count). /cs help for instance probably would have more weight than /cs invite.  Another thing to keep in mind is that distributed attacks from one host name (example, bot floods) should also be considered.

Guest1234!moose@127.0.0.1 floods services and gets ignored.
Guest3245!something@127.0.0.1 floods services and gets ignored.

Eventually services should say, "wait one cotton pickin minute..." and eventually ignore @127.0.0.1 as well as send out a message  'Services are being severely attacked by @127.0.0.1'.

Also opers/admins, if not entirely exempt, should have at least less restriction on services load.

Finally, if the flood on services is just too great, services could issue warnings that could suggest administration issue DEFCon.
Logged

Dave Robson

  • Team
  • *
  • Offline Offline
  • Posts: 357
(No subject)
« Reply #3 on: May 24, 2006, 07:22:00 AM »

Most ircd's already provide this, its called a SendQ and reciveQ.... (granted the solution is to /kill instead of ignore tho :)
Logged

katsklaw

  • Guest
(No subject)
« Reply #4 on: May 25, 2006, 02:28:28 AM »

To elaborate a bit on sendQ/recvQ ... these two are designed to control the amount of data namely throughput, that a user can use both in and out (from the ircd's point of view). If one of the 2 are exceeded the ircd names it as a flood and disconnects the offending user. Thus services should never be text flooded. Back in the late 90's Services could be flooded and networks such as DALnet had internal flood detection measures. However, today it's simply not needed by most ircds. Text floods are still possible .. but very very rare .. they can be ranked up there as like  the chance of a WinNuke actually working. As a side note, in my opinion, if a user floods a server, they need to be /killed or worse. Ignoring the flood isn't the answer. Sure Services ignores the user .. but the user is still sending data to the server they are connected to, thus still flooding.

Just my $0.03 (2 cents + tax)

kat

[Edited on 25-5-2006 by katsklaw]
Logged
Pages: [1]   Go Up