Hello Craig [Flashman],
The SYN Flooding is not only the problem on IRC, but the TCP sequencing as
well. Using a TCP sequencer, one of these 13 year olds who has no idea how
or what they are doing, can SYN flood a host without knowing it at all. This
involves hosing a host with SYN floods to keep it from sending out the
correct ACKs so that you can sequence them on your side and "spoof" them.
Well, sadly to say, all these kids want to do is be "eleet" and hide thier
real host names so they can trade pirated software etc.
However, this leads to a bigger problem seeing as how this same code can be
used to do blind rcommands using the same sequencing technique. Fortunately,
the person who wrote the orginal TCP sequencer had only IRC in mind, and
mainly the people that have used it were IRC kiddies, and even they had a
hard time using it because it needs a modification to raw.c in order to
patch the kernel to do the correct raw socket operations under the mask of a
struct tcphdr * fake_tcp;
fake_tcp = ( struct tcphdr *)( packet + offsetTCP );
fake_tcp->th_dport = htons(fromport);
fake_tcp->th_sport = htons(toport);
fake_tcp->th_seq = htonl(sequence);
fake_tcp->th_ack = htonl(acknum);
fake_tcp->th_off = (sizeof(struct tcphdr))/4;
fake_tcp->th_win = 2;
I think you get the point.
I'm not sure what a real feasable solution would be, except to do a tcpdump
or start a sniffer during an attack and try and trace it from there.
However, if the packets are carrying fake headers, there's not much you can do.
P.S. Lets try not to get mad at Emmanuel Goldstein (Editor 2600 Magazine)
for what he puts in his magazine. True, the code can and will be used for
malicious purposes, but if it weren't published, only a select few people
would have the code and very few people would be hearing about SYN floods,
instead, simply being attacked without the slightest clue what was happening.
-LebaNet Inc. C.S.O.