Hello Dirk,
DB> till a couple of minutes I'm under an attack. I never have seen this
DB> behaviour.
First of all, a free tip ; if you don't want to be put out of
business, just do not run an IRC (ircnet) server.
You're begging for beeing attacked by running one.
You've got to know, and to deal, with that.
IRCNet is dying as many companies are fed up with loosing uptime
because of it. If find this attitude ridiculous as I prefer wasting
uptime for attack targetted at a known host running a completely
unsupported service with no SLA whatsoever, rather than one day
loosing hours of uptime for an attack really targetted at our
entire service an having the company discovering these kind of
attacks for the first time ;)
DB> I have round 'bout 50000 active connections. The Destination for all
DB> of these connections is irc.arnes.si (193.2.1.34). The Source is an
DB> internal IP. The internal IP is not one specific IP it's changing all
DB> over
DB> the whole subnet, even if no machine is assigned to this IP. But not
DB> even the
DB> IP's cycle through all values the ports do also.
If you've got 50000 "connections" it means TCP for me, and then
these connections are not spoofed.
Since an unspoofed connection could hardly come from a non existant
host, there is something wrong with what you're saying.
So these are rather packets, but certainly not connections.
What you're seeing is probably a bunch of spoofed UDP packets combined
with an ACK flood, which is known as a flood network. Could be TFN,
Trinoo, or whatever. It's doesn't matter actually.
IIRC, TFN(2K?) uses spoofed IPs in its neighborhoud by default.
So it send packets from a pseudo "C-class" around the actual source IP.
So it could indeed mean that someone from your own network if
attacking your server. I find this unlikely tough, you could easily
see that in your bandwidth logs.
DB> I'm sure that IP spoofing is correct configured. The all over system
DB> works since 2 years.
Uptime is not a way of measuring quality. Unix systems with years of
uptime make me laugh, as it means they've been unpatched for years.
DB> Any idea how to stop, what to change ??
You did not identify the target. Its not the server, its the pipe.
Whatever your security is, you've got little means of defense against
attack targetted at your bandwidth, which are the most common
ones to unlink an IRC server from the network.
There is nothing to do except routing to null0 the spoofed packets
*before* they reach your network.
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
