On Fri, 8 Sep 2000, Andi Kleen wrote:
:The only way to fix that with TCP is to pull the plug. You probably didn't
:understand it, but the RST is only *one* way where TCP replies, but there
:are lots of other ways too (like ACKs)
I think I know how TCP works but seems like you analyze the subject
without having tested in practise.
In case you want to test it yourself and see:
Well on 4 machines located on different LANs (C class netblocks),
run a program as root which constructs TCP ACK packets (win 65535 as shown
in my previous tcpdump piece), and sends them coming from different
ip addresses (of the same class c netblock though) hitting the same
target ip address on random target ports (try random source ports as well).
While the attack is going on, your machine is netdead.
If not, add 2 more class c netblocks on the attack and it is for sure. And
that's because your machine send so many RST's back.
If you think this is only a "bandwidth" issue with 4 machines against one,
try with source attacker machines located on less bandwidth than the target
or even the "sum" of their bandwidth less (but not much less) than the
target's.
The attackers have studied really carefully TCp protocol and
why they have choosen ACK bit set for the offending packets (well another
reason is because I block non-ACK incoming packets before they enter
my netblock with a firewall). Else, sending just TCP packets with no bits
the same result (of replying RSTs) would have happened. Just notice the
win 65535 in conjuction with the ACK bit set. Ask yourself: can it be
done the same way with other bit sets (like RST), or hitting used ports
(and/or listening ports). I guess the prefered method of ACK-bit-set-
only attack, is the most harmful and gives full impact than any other
TCP attack of similar kind (considering I am already firewalling TCP
at a previous point - as much as I can because of services as FTP...)
and that's because it forces the target machine to reply its worst flood.
:If you think you don't want such "weakness"es you should probably look
:for a different protocol than TCP. I don't know any that would fix it.
:The funny thing is that IPSec et.all. don't help here at all.
We are going way off topic. I am not complaining or looking for
any other ways to "solve my problem". I feel (and insist) that
there is a "weakness" on TCP protocol that can be exploited really
easy and cause problems. I have isolated ANY kind of network attacks all
these years but this one seems to be the only one that cannot be
faced without touching the kernel. That is, everyone knows that
you have to count on the kernel to behave well at some point and later
cooperate with userspace programs etc to carry out your task. I feel
(wether right or wrong I do not know that's why I am asking here) that
the RST reply from incoming TRASH (flood) packets on unused ports, is
too fast or it is not handled as smart.
Afterall, I have an end-user solution about it in case you
are interested: I take FTP service off to another machine and I firewall
(ip-block) all packets except for those coming in listening ports and it is
over.
Since I believe we are wasting reader's time, I made my point and
let the ones who handle linux's kernel ipv4 decide wether or not somethng
should be done at kernel level. For me this email thread is over unless
something else about it comes up as "solution"/better-way-of-handling it.
Better than nothing, is for sure that delay of sending RSTs that Alan
suggested IMHO.
Thanks for your comments.
-- George Athanassopoulos http://www.real.macedonia.gr http://www.egnatia.ee.auth.gr- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:10 EST