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
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
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
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
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
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) But
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, 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
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
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
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
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
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
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
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
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
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
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
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:
: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
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
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 well
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
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
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 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 much
31 matches
Mail list logo
