• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

Bot problem, part 2

Started by j4jackj, January 28, 2014, 05:22:55 PM

Previous topic - Next topic

j4jackj

So I fixed the shit with the bots so that rather than reconnecting every 15 seconds they reconnect every minute, which means the hammering density is divided by 4. (It was already pretty low to start with, although I do admit the IRC server was wasting cycles, but it was not an attempt at a denial of service attack)

Another thing, I used to run an IRCd's IPv6 access gateway via your service, and now that is down. So if you can't unblock incoming IRC without unblocking outgoing IRC, you need to work on your filtering systems.

Still, I apologise for the hammer incident, and due to the reduced number of bots, can promise it will not happen again.
Thank you for your blocking of IRC while the hammering occured, and if you detect it happening again, delete my account.

broquea

I'd say filtering is working as intended. Kudos to HE for implementing it!

j4jackj

Lul.

What I think should be done is connection rate-limiting: if more than H IRC connections occur in T minutes, block IRC for X minutes.
H and T stand for Hammers and Time. So if more than (say) 20 hammers (short connections) occur within 10 minutes, block IRC for 1440 minutes. That should prevent most hammering issues. (I think it can be done with a simple bash script, or 100 lines of Perl.)

Hello71

#3
Quote from: j4jackj on January 30, 2014, 11:05:57 AM
Lul.

What I think should be done is connection rate-limiting: if more than H IRC connections occur in T minutes, block IRC for X minutes.
H and T stand for Hammers and Time. So if more than (say) 20 hammers (short connections) occur within 10 minutes, block IRC for 1440 minutes. That should prevent most hammering issues. (I think it can be done with a simple bash script, or 100 lines of Perl.)

Uh, no. One, it's not HE's job to filter your traffic. The fact that TCP filters need to be implemented is already bad enough.

It's *your* job to make sure *your* clients do not abuse *other* people's servers.




On a somewhat related note, as you may have guessed, j4jackj is a persistent annoyance in many Freenode channels.

I congratulate HE on blocking this !@#$'s IRC access. For this, I may even consider purchasing services.