On Fri, 8 Sep 2000, Andi Kleen wrote:
:The source address does not matter.
Well from the attacker's point of view I believe it does. For many reasons
starting from the fact that the more ip addresses, the more difficult to
block (per ip-blocking firewall basis) and, if there is a chance fo
Hello!
> Well, it looks like you're getting hit with stream.c or raped.c and what
> I'm passing on is just what I picked up from a CERT guy at Usenix. He
> claimed that stream.c worked by exploiting a long path through the kernel
He just said a crap. All the discussion around stream.c is banal
On Fri, Sep 08, 2000 at 05:49:35PM +0300, George Athanassopoulos wrote:
> 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 t
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 sub
On Fri, Sep 08, 2000 at 03:01:08AM +0300, George Athanassopoulos wrote:
> On Fri, 8 Sep 2000, Andi Kleen wrote:
>
> :If Linux stopped sending ACKs for out of order packets your machine would
> :be pretty much unusable over lossy links (because fast retransmit would
> :not work properly anymore)
> Well, it looks like you're getting hit with stream.c or raped.c and what
> I'm passing on is just what I picked up from a CERT guy at Usenix. He
> claimed that stream.c worked by exploiting a long path through the kernel
> to bring the machine to its knees.
The traces look more like a very pri
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
> Hello!
> > I believe that the DoS is that the path through the kernel turns out to be
> > long and that a lot of these packets will bring a machine to its knees.
>
> It is not longer than path for any other kind of packet.
> In the reported case it is
On Fri, 8 Sep 2000, Andi Kleen wrote:
:If Linux stopped sending ACKs for out of order packets your machine would
:be pretty much unusable over lossy links (because fast retransmit would
:not work properly anymore) But that of course can be used
:to cause your machine to send at least an outgoing
On Fri, Sep 08, 2000 at 02:18:22AM +0300, George Athanassopoulos wrote:
> On Fri, 8 Sep 2000, Andi Kleen wrote:
>
> :I forgot to add: Alexey is of course right in that it doesn't help you
> :at all. You cannot defend against packet floods, and with an active TCP
> :you can be always tricked into
On Fri, 8 Sep 2000, Andi Kleen wrote:
:I forgot to add: Alexey is of course right in that it doesn't help you
:at all. You cannot defend against packet floods, and with an active TCP
:you can be always tricked into bouncing packets without load limit
:(e.g. just by sending out of order packets fo
On Fri, Sep 08, 2000 at 12:21:40AM +0200, Andi Kleen wrote:
> You do not even need patches for it. You can do it as well with a TBF
> filter in the qdisc and a u32 filter that selects RSTs (it is even a
> standard example in iproute2)
>
> Another way that may work is to set the send buffer of t
On Thu, Sep 07, 2000 at 10:51:50PM +0100, Alan Cox wrote:
> static unsigned long last_time;
>
> if(jiffies-last_time < HZ/10)
> return;
> last_time = jiffies;
>
> which will then limit to one RST per 10th sec
You do not even need patches for it. You can do it as
> should we just eat it and shut up (because that's the way TCP works and it
> will not change)?
It is part of the protocol requirement
> I haven't used iptables yet but I think they can handle packets with various
> bits sets (including RST), unlike ipfw. But, is there any way with ipta
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
:By any _formal_ criteria there is no DoS here. You reply with one packet
:to each incoming packet and do not hold any state. Where is DoS?
Maybe I did not make clear where the DoS is. Well my machine DOES NOT
hang. But the NIC is busy replying tho
Hello!
> I believe that the DoS is that the path through the kernel turns out to be
> long and that a lot of these packets will bring a machine to its knees.
It is not longer than path for any other kind of packet.
In the reported case it is much shorter. 8)
Apparently, you try to remind about
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
> Hello!
> > - Could there be some kind of handling for such packets (meaning TCP packets
> > reaching at an unused port with ACK bit set - with no previous SYN etc packet)
> > to avoid such DoS attacks? Is the same happening to newer kernels? If yes
On Thu, 07 Sep 2000, George Athanassopoulos wrote:
Possibly post this message on the netfilter mailing list.
[EMAIL PROTECTED]
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard
Hello!
> - Could there be some kind of handling for such packets (meaning TCP packets
> reaching at an unused port with ACK bit set - with no previous SYN etc packet)
> to avoid such DoS attacks? Is the same happening to newer kernels? If yes,
> should we just eat it and shut up (because th
Hello,
I am not sure if this is the right list to point out some linux TCP
implementation "weakness" but I think that something should be done
first at the kernel level and after with any other way (firewalling etc).
The problem:
I am using 2.0.38 and I am receiving lots of DoS attacks on one of m
19 matches
Mail list logo
