* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Thomas Graf @ 2005-06-12 14:44 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612133654.GA8951@alpha.home.local>
* Willy Tarreau <20050612133654.GA8951@alpha.home.local> 2005-06-12 15:36
> > The RST packet is sent by client A using its sequence numbers. Therefore
> > it will pass the sequence number check on server B.
> >
> > 4) server B resets the connection.
>
> No, precisely the RST sent by A will take its SEQ from C's ACK number.
> This is why B will *not* reset the connection (again, tested) if C's ACK
> was not within B's window.
Absolutely but it relies on the other stack being correctly implemented.
The attack would work perfectly fine if there wasn't the rule that a RST
must not be sent in response to another RST. The attack has been
successful and still is because some firewalls are configured to send
RSTs without respecting this rule.
I like your patch and the idea behind it, it can successfully defeat the
most simple method of preventing connections being established.
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 14:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612135018.GA10910@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 11:50:18PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
> >
> > Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
> > so the connection will survive.
>
> Sorry I wasn't thinking straight.
>
> >
> > > My point is that there are many ways to kill TCP connections in ways
> > > similar to what you proposed initially so it isn't that special.
> >
> > No, there are plenty of ways to kill TCP connections when you can guess
> > the window (which is more and more easy thanks to window scaling). But
> > I have yet found no way to kill a TCP session without this info, except
> > by exploiting the simultaneous connect feature.
>
> I still stand by this point though. The most obvious thing I can think
> of right now is to change your attack to simply connect to kernel.org's
> webserver first from source port 10000. That will cause the real SYN
> packet to fail the sequence number check.
This case is interesting, but it will be resolved in two possible ways :
1) no firewall in front of A
- C spoofs A and sends a fake SYN to B
- B responds to A with a SYN-ACK
- A sends an RST to B, which clears the session
- A wants to connect and sends its SYN to B which accepts it.
2) A behind a firewall
- C spoofs A and sends a fake SYN to B
- B responds to A with a SYN-ACK, which does not reach A (firewall, etc...)
- A tries to connect to B and sends its SYN with a different SEQ
- B responds to A with only an ACK (no SYN) indicating the expected SEQ.
- A responds to B's ACK with an RST and B flushes its session too.
- A resends its SYN to B which accepts it.
Cheers,
Willy
^ permalink raw reply
* [PATCH] Ensure to use icmpv6_socket in non-preemptive context.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-06-12 14:03 UTC (permalink / raw)
To: davem; +Cc: yoshfuji, netdev
Hello.
[IPV6] Make sure to use icmpv6_socket in non-preemptive context.
We saw following trace several times:
|BUG: using smp_processor_id() in preemptible [00000001] code: httpd/30137
|caller is icmpv6_send+0x23/0x540
| [<c01ad63b>] smp_processor_id+0x9b/0xb8
| [<c02993e7>] icmpv6_send+0x23/0x540
This is because of icmpv6_socket, which is the only one user of
smp_processor_id() in icmpv6_send(), AFAIK.
Since it should be used in non-preemptive context,
let's defer the dereference after disabling preemption
(by icmpv6_xmit_lock()).
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -277,8 +277,8 @@ void icmpv6_send(struct sk_buff *skb, in
{
struct inet6_dev *idev = NULL;
struct ipv6hdr *hdr = skb->nh.ipv6h;
- struct sock *sk = icmpv6_socket->sk;
- struct ipv6_pinfo *np = inet6_sk(sk);
+ struct sock *sk;
+ struct ipv6_pinfo *np;
struct in6_addr *saddr = NULL;
struct dst_entry *dst;
struct icmp6hdr tmp_hdr;
@@ -358,6 +358,9 @@ void icmpv6_send(struct sk_buff *skb, in
if (icmpv6_xmit_lock())
return;
+ sk = icmpv6_socket->sk;
+ np = inet6_sk(sk);
+
if (!icmpv6_xrlim_allow(sk, type, &fl))
goto out;
@@ -423,9 +426,9 @@ out:
static void icmpv6_echo_reply(struct sk_buff *skb)
{
- struct sock *sk = icmpv6_socket->sk;
+ struct sock *sk;
struct inet6_dev *idev;
- struct ipv6_pinfo *np = inet6_sk(sk);
+ struct ipv6_pinfo *np;
struct in6_addr *saddr = NULL;
struct icmp6hdr *icmph = (struct icmp6hdr *) skb->h.raw;
struct icmp6hdr tmp_hdr;
@@ -454,6 +457,9 @@ static void icmpv6_echo_reply(struct sk_
if (icmpv6_xmit_lock())
return;
+ sk = icmpv6_socket->sk;
+ np = inet6_sk(sk);
+
if (!fl.oif && ipv6_addr_is_multicast(&fl.fl6_dst))
fl.oif = np->mcast_oif;
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 13:50 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612134725.GB8951@alpha.home.local>
On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
>
> Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
> so the connection will survive.
Sorry I wasn't thinking straight.
>
> > My point is that there are many ways to kill TCP connections in ways
> > similar to what you proposed initially so it isn't that special.
>
> No, there are plenty of ways to kill TCP connections when you can guess
> the window (which is more and more easy thanks to window scaling). But
> I have yet found no way to kill a TCP session without this info, except
> by exploiting the simultaneous connect feature.
I still stand by this point though. The most obvious thing I can think
of right now is to change your attack to simply connect to kernel.org's
webserver first from source port 10000. That will cause the real SYN
packet to fail the sequence number check.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 13:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612133349.GA6279@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 11:33:49PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 11:13:23PM +1000, herbert wrote:
> > On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> > >
> > > but it's not the case (although the naming is not clear). So if the remote
> > > end was the one which sent the SYN-ACK, it will clear its session. If it has
> > > been spoofed, it will ignore the RST because in turn, the SEQ will not be
> > > within its window.
> >
> > This is what should happen:
>
> Sorry, you're right. The SEQ check should catch this.
No problem. Fortunately, this part of the code is *very well* documented :-)
> However, a few lines down in that same function there is a th->rst
> check which will kill the connection just as effectively.
Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
so the connection will survive.
> My point is that there are many ways to kill TCP connections in ways
> similar to what you proposed initially so it isn't that special.
No, there are plenty of ways to kill TCP connections when you can guess
the window (which is more and more easy thanks to window scaling). But
I have yet found no way to kill a TCP session without this info, except
by exploiting the simultaneous connect feature.
My point was that it would not be too difficult to remotely prevent an
anti-virus or IDS from downloading its updates when you know the update
site's address and you know that by default it uses source ports
1024-4999 to connect outside. I don't really care for BGP however
because people should use MD5 or they get what they deserve.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 13:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612131323.GA10188@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 11:13:23PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> >
> > but it's not the case (although the naming is not clear). So if the remote
> > end was the one which sent the SYN-ACK, it will clear its session. If it has
> > been spoofed, it will ignore the RST because in turn, the SEQ will not be
> > within its window.
>
> This is what should happen:
>
> 1) client A sends SYN to server B.
> 2) attcker C sends spoofed SYN-ACK to client A purporting to be server B.
> 3) client A sends RST to server B.
Agreed till here.
> The RST packet is sent by client A using its sequence numbers. Therefore
> it will pass the sequence number check on server B.
>
> 4) server B resets the connection.
No, precisely the RST sent by A will take its SEQ from C's ACK number.
This is why B will *not* reset the connection (again, tested) if C's ACK
was not within B's window.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 13:33 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612131323.GA10188@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 11:13:23PM +1000, herbert wrote:
> On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> >
> > but it's not the case (although the naming is not clear). So if the remote
> > end was the one which sent the SYN-ACK, it will clear its session. If it has
> > been spoofed, it will ignore the RST because in turn, the SEQ will not be
> > within its window.
>
> This is what should happen:
Sorry, you're right. The SEQ check should catch this.
However, a few lines down in that same function there is a th->rst
check which will kill the connection just as effectively.
My point is that there are many ways to kill TCP connections in ways
similar to what you proposed initially so it isn't that special.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 13:16 UTC (permalink / raw)
To: Thomas Graf
Cc: Willy Tarreau, davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612122247.GB22463@postel.suug.ch>
On Sun, Jun 12, 2005 at 02:22:47PM +0200, Thomas Graf wrote:
>
> > Look at the first check inside th->ack in tcp_rcv_synsent_state_process.
>
> Usually a continious flow of ACK+RST is used to prevent a connection
> from being established, it's more reliable because even if you hit the
> ISS+rcv_next window the connection attempt will still be reset.
Sure. My point is that there are a hundred and one ways to attack
a TCP connection in a manner similar to the original method that
started this thread. So fixes like this are pretty pointless.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 13:13 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612123253.GK28759@alpha.home.local>
On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
>
> but it's not the case (although the naming is not clear). So if the remote
> end was the one which sent the SYN-ACK, it will clear its session. If it has
> been spoofed, it will ignore the RST because in turn, the SEQ will not be
> within its window.
This is what should happen:
1) client A sends SYN to server B.
2) attcker C sends spoofed SYN-ACK to client A purporting to be server B.
3) client A sends RST to server B.
The RST packet is sent by client A using its sequence numbers. Therefore
it will pass the sequence number check on server B.
4) server B resets the connection.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 12:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612120627.GA5858@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 10:06:27PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 01:40:39PM +0200, Willy Tarreau wrote:
> >
> > Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
> > with this statement. Look: at line 5, A rejects the SYN-ACK because the
> > ACK is wrong during the session setup.
>
> Look at the first check inside th->ack in tcp_rcv_synsent_state_process.
Herbert, I perfectly agree with this check and it's consistent with what I
observe. But as you know, there's a difference between resetting a session
and sending an RST to say that we refuse a segment. This check does not kill
the session, it sends an RST whose SEQ is equal to the SYN-ACK's ACK. It's
possible you though the "reset_and_undo" label was used to kill the session,
but it's not the case (although the naming is not clear). So if the remote
end was the one which sent the SYN-ACK, it will clear its session. If it has
been spoofed, it will ignore the RST because in turn, the SEQ will not be
within its window.
Try it by yourself if you don't believe me. I've done lots of tests with
hping2 and I've never managed to kill a session with both a SEQ and ACK
outside the windows.
Regards,
Willy
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Thomas Graf @ 2005-06-12 12:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: Willy Tarreau, davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612120627.GA5858@gondor.apana.org.au>
* Herbert Xu <20050612120627.GA5858@gondor.apana.org.au> 2005-06-12 22:06
> On Sun, Jun 12, 2005 at 01:40:39PM +0200, Willy Tarreau wrote:
> >
> > Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
> > with this statement. Look: at line 5, A rejects the SYN-ACK because the
> > ACK is wrong during the session setup.
>
> Look at the first check inside th->ack in tcp_rcv_synsent_state_process.
Usually a continious flow of ACK+RST is used to prevent a connection
from being established, it's more reliable because even if you hit the
ISS+rcv_next window the connection attempt will still be reset.
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 12:06 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612114039.GI28759@alpha.home.local>
On Sun, Jun 12, 2005 at 01:40:39PM +0200, Willy Tarreau wrote:
>
> Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
> with this statement. Look: at line 5, A rejects the SYN-ACK because the
> ACK is wrong during the session setup.
Look at the first check inside th->ack in tcp_rcv_synsent_state_process.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 11:40 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612103020.GA25111@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 08:30:20PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 10:34:09AM +0200, Willy Tarreau wrote:
> >
> > > Sorry but this patch is pointless. If I wanted to prevent you from
> > > connecting to www.kernel.org 80 and I knew your source port number
> > > I'd be directly sending you fake SYN-ACK packets which will kill
> > > your connection immediately.
> >
> > Only if your ACK was within my SEQ window, which adds about 20 bits of
> > random when my initial window is 5840. You would then need to send one
> > million times more packets to achieve the same goal.
>
> Nope, no sequence validity check is made on the SYN-ACK.
Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
with this statement. Look: at line 5, A rejects the SYN-ACK because the
ACK is wrong during the session setup.
And if you send the SYN-ACK on an established session, either it's in the
window in which case the other end will send an RST, or it's outside the
window, in which case the other end will resend an ACK to tell you what
it expects. So I maintain my statement that the SYN-ACK must be within the
window to cause a session reset. That's why I considered cisco's approach
a total bullshit, because they mangled the TCP implementation to protect
against in-window RSTs, but they failed to see that SYN-ACK would do exactly
the same.
I fail to find a case where both the SEQ and the ACK are ignored. This
is why I believe that the simultaneous connect mode introduces a weakness.
Cheers,
Willy
^ permalink raw reply
* Re: testing techniques to confirm the effectiveness of changes made to sch_gred.c
From: Thomas Graf @ 2005-06-12 10:46 UTC (permalink / raw)
To: rahul.hari; +Cc: netdev, netdev, lartc-request, diffserv-general, linux.kernel
In-Reply-To: <4532f3170506101739702e31ad@mail.gmail.com>
* Rahul Hari <4532f3170506101739702e31ad@mail.gmail.com> 2005-06-11 06:09
> I have made some changes to the file sch_gred.c to modify the GRED
> queueing discipline to support the following features:
> 1) The first virtual queue should get absolute priority while
> dequeueing (not caring if the others get starved)
> 2) While in equalise mode and with RIO mode enabled, the packets in
> the first virtual queue should not be counted for calculating the
> qave.
You do not need to modify gred to achieve this, use a prio qdisc
with 2 bands, band 1 covers your "first virtual queue" with a single
red attached, band 2 covers the rest and uses a gred.
> 1) Since the process deals with dequeueing, i have to make changes to
> gred_dequeue only. If t->tab[0] != 0 then we dequeue the packet
> otherwise do not dequeue it.
What you describe above is: only dequeue when DP 0 is configured,
probably not what you want. The only way to prioritize within gred
the way you want is to modify dequeue() that it iterates through
sch->q looking for a skb with tcindex==DP0 and use it instead of
the skb at the queue head.
> 2)
> if (t->eqp && t->grio) {
>
> for (i=0;i<t->DPs;i++) {
> if ((!t->tab[i]) || (i==q->DP) || (i==0))
> continue;
>
> if ((t->tab[i] != q) && (PSCHED_IS_PASTPERFECT(t->tab[i]->qidlestart)))
> qave +=t->tab[i]->qave;
> }
You no longer consider the priority so it won't be wred anymore,
also if (i == q->DP) continue makes a check t->tab[i] != q
unnecessary.
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 10:30 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612083409.GA8220@alpha.home.local>
On Sun, Jun 12, 2005 at 10:34:09AM +0200, Willy Tarreau wrote:
>
> > Sorry but this patch is pointless. If I wanted to prevent you from
> > connecting to www.kernel.org 80 and I knew your source port number
> > I'd be directly sending you fake SYN-ACK packets which will kill
> > your connection immediately.
>
> Only if your ACK was within my SEQ window, which adds about 20 bits of
> random when my initial window is 5840. You would then need to send one
> million times more packets to achieve the same goal.
Nope, no sequence validity check is made on the SYN-ACK.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-12 8:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050612081327.GA24384@gondor.apana.org.au>
On Sun, Jun 12, 2005 at 06:13:27PM +1000, Herbert Xu wrote:
> On Sat, Jun 11, 2005 at 09:51:44PM +0200, Willy Tarreau wrote:
> >
> > Please note that if I only called it "small DoS", it's clearly because
> > I don't consider this critical, but I think that most people involved
> > in security will find that DoSes based on port guessing should be
> > addressed when possible.
>
> Sorry but this patch is pointless. If I wanted to prevent you from
> connecting to www.kernel.org 80 and I knew your source port number
> I'd be directly sending you fake SYN-ACK packets which will kill
> your connection immediately.
Only if your ACK was within my SEQ window, which adds about 20 bits of
random when my initial window is 5840. You would then need to send one
million times more packets to achieve the same goal.
> If you want reliability and security you really should be using IPsec.
> There is no other way.
I agree with you on the fact that people who need security must use
secure protocols. I had the same words last year when people discovered
that a TCP RST could kill a BGP session, and the end of the internet was
announced. Hey, if someone needs secure BGP, he must use MD5 sums from
the start.
I'm not meaning to make TCP as secure as IPsec, but I think that when
supporting a feature (simultaneous connect) that nobody uses and many
OSes do not even support introduces a weakness, we could at least make
it optional. It could also rely on a #if CONFIG_TCP_SIMULT which will
slightly reduce kernel size for people who know they don't want it.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-12 8:13 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050611195144.GF28759@alpha.home.local>
On Sat, Jun 11, 2005 at 09:51:44PM +0200, Willy Tarreau wrote:
>
> Please note that if I only called it "small DoS", it's clearly because
> I don't consider this critical, but I think that most people involved
> in security will find that DoSes based on port guessing should be
> addressed when possible.
Sorry but this patch is pointless. If I wanted to prevent you from
connecting to www.kernel.org 80 and I knew your source port number
I'd be directly sending you fake SYN-ACK packets which will kill
your connection immediately.
If you want reliability and security you really should be using IPsec.
There is no other way.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Willy Tarreau @ 2005-06-11 19:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <E1DhBic-0005dp-00@gondolin.me.apana.org.au>
Hi Herbert,
On Sun, Jun 12, 2005 at 05:32:34AM +1000, Herbert Xu wrote:
> Willy Tarreau <willy@w.ods.org> wrote:
> >
> > During this, the client cannot connect to www.kernel.org from this port
> > anymore :
> > wks$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
> > ret=1
>
> What if you let the client connect from a random port which is what it
> should do?
Of course, if the port chosen by the client is not in the range probed by
the attacker, everything's OK. My point is that relying *only* on a port
number is a bit limitative. It is even more when some protocols only bind
to privileged source ports, or always use the same port range at boot (eg:
a router establishing a BGP connection to the ISP's router).
Please note that if I only called it "small DoS", it's clearly because
I don't consider this critical, but I think that most people involved
in security will find that DoSes based on port guessing should be
addressed when possible.
Regards,
Willy
^ permalink raw reply
* Re: e1000 not working using 2.6.11
From: Adrian Bunk @ 2005-06-11 19:37 UTC (permalink / raw)
To: John covici
Cc: linux-kernel, cramerj, john.ronciak, ganesh.venkatesan, netdev
In-Reply-To: <17064.41290.461755.920152@ccs.covici.com>
On Thu, Jun 09, 2005 at 04:06:34PM -0400, John covici wrote:
> Hi. I am not getting good results on a box I have which uses an Intel
> Pro gigabit Ethernet driver for its network connection. What happens
> is that I get messages like watchdog xmit timeout and lots of errors
> out of ifconfig. Here is the listpci entry for that card. It works
> under the other OS, so I imagine the hardware is OK.
>
> 0000:01:0b.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02)
> Subsystem: Intel Corp.: Unknown device 3013
> Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19
> Memory at e7000000 (64-bit, non-prefetchable) [size=128K]
> Memory at e7020000 (64-bit, non-prefetchable) [size=64K]
> I/O ports at b400 [size=64]
> Capabilities: [dc] Power Management version 2
> Capabilities: [e4] PCI-X non-bridge device.
> Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
>
>
> Any assistance would be appreciated.
Does 2.6.12-rc6 work?
If not, the maintainers of this driver (Cc'ed) might be able to help
you.
> John Covici
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)
From: Herbert Xu @ 2005-06-11 19:32 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, xschmi00, alastair, linux-kernel, netdev
In-Reply-To: <20050611074350.GD28759@alpha.home.local>
Willy Tarreau <willy@w.ods.org> wrote:
>
> During this, the client cannot connect to www.kernel.org from this port
> anymore :
> wks$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
> ret=1
What if you let the client connect from a random port which is what it
should do?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: TCP stalls - sack?, 2.6.12pre6
From: Krzysztof Halasa @ 2005-06-11 17:44 UTC (permalink / raw)
To: netdev
In-Reply-To: <m3mzpz87dc.fsf@defiant.localdomain>
Hi,
Another TCP stall (2.6.12pre6 on both ends):
> intrepid is X11-server with ssh connection to defiant (X11-forwarding,
> EPIC100 PCI NIC). defiant is an older notebook machine and it was running
> XEmacs and Firefox with ssh/X11 (cardbus DEC 21143).
> Both on the same Ethernet subnet. Both standard MTU etc.
[DEF] is TCP defiant:ssh
[INT] is TCP intrepid:4782
intrepid:~# netstat -to | grep 4782; tcpdump -w stall -s 1600 -i eth0
Sat Jun 11 15:55:51 CEST 2005
Recv-Q Send-Q
tcp 0 0 [INT] [DEF] ESTABLISHED keepalive (675.46/0/0)
tcpdump file basically shows (TCP already stalled):
15:56:27.1 [INT] > [DEF]: P 569644050:569644162(112) ack 3725119932 win 31164 <nop,nop,timestamp 6388700 274348581,nop,nop,sack sack 1 {1449:14985} >
15:56:27.1 [DEF] > [INT]: . ack 112 win 16022 <nop,nop,timestamp 274631570 6388700>
15:56:27.1 [INT] > [DEF]: P 112:256(144) ack 1 win 31164 <nop,nop,timestamp 6388701 274348581,nop,nop,sack sack 1 {1449:14985} >
15:56:27.1 [DEF] > [INT]: . ack 256 win 16022 <nop,nop,timestamp 274631571 6388701>
15:56:27.1 [INT] > [DEF]: P 256:336(80) ack 1 win 31164 <nop,nop,timestamp 6388710 274348581,nop,nop,sack sack 1 {1449:14985} >
15:56:27.1 [DEF] > [INT]: . ack 336 win 16022 <nop,nop,timestamp 274631579 6388710>
...
16:04:09.6 [DEF] > [INT]: . ack 35536 win 16022 <nop,nop,timestamp 275094166 6851304>
16:04:09.7 [INT] > [DEF]: P 35536:35616(80) ack 1 win 31164 <nop,nop,timestamp 6851394 274348581,nop,nop,sack sack 1 {1449:14985} >
16:04:09.7 [DEF] > [INT]: . ack 35616 win 16022 <nop,nop,timestamp 275094256 6851394>
16:05:12.7 [DEF] > [INT]: . 1:1449(1448) ack 35616 win 16022 <nop,nop,timestamp 275157275 6851394>
16:08:14.3 [INT] > [DEF]: P 35616:35760(144) ack 1 win 31164 <nop,nop,timestamp 7096034 274348581,nop,nop,sack sack 1 {1449:14985} >
16:08:14.3 [DEF] > [INT]: R 3725119932:3725119932(0) win 0
defiant:~# netstat -to | grep 4782
Recv-Q Send-Q
tcp 0 54512 [DEF] [INT] ESTABLISHED on (81.30/10/0)
and Send-Q is constant until TCP reset.
> Ideas?
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH] networking: [IPv6] Don't generate temporary for TUN devices
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-06-11 13:32 UTC (permalink / raw)
To: rdenis, davem; +Cc: davem, pekkas, netdev
In-Reply-To: <200506111512.42592.rdenis@simphalempin.com>
In article <200506111512.42592.rdenis@simphalempin.com> (at Sat, 11 Jun 2005 15:12:40 +0200), Rémi Denis-Courmont <rdenis@simphalempin.com> says:
> Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00):
> cannot get EUI64 identifier; use random bytes.
:
> As far as I could fine, TUN virtual device from TUNTAP is the very only
> sort of device using ARPHRD_NONE as kernel device type.
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--yoshfuji
^ permalink raw reply
* [PATCH] networking: [IPv6] Don't generate temporary for TUN devices
From: Rémi Denis-Courmont @ 2005-06-11 13:12 UTC (permalink / raw)
To: davem, pekkas; +Cc: yoshfuji, netdev
Hello,
Userland layer-2 tunneling devices allocated through the TUNTAP driver
(drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer
address. The kernel complains at regular interval when IPv6 Privacy
extension are enabled because it can't find an hardware address :
Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00):
cannot get EUI64 identifier; use random bytes.
IPv6 Privacy extensions should probably be disabled on that sort of
device. They won't work anyway. If userland wants a more usual
Ethernet-ish interface with usual IPv6 autoconfiguration, it will use a
TAP device with an emulated link-layer and a random hardware address
rather than a TUN device.
As far as I could fine, TUN virtual device from TUNTAP is the very only
sort of device using ARPHRD_NONE as kernel device type.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
--- a/net/ipv6/addrconf.c.orig 2004-12-29 10:50:27.000000000 +0100
+++ b/net/ipv6/addrconf.c 2004-12-29 10:50:41.000000000 +0100
@@ -372,6 +372,7 @@
ndev->regen_timer.data = (unsigned long) ndev;
if ((dev->flags&IFF_LOOPBACK) ||
dev->type == ARPHRD_TUNNEL ||
+ dev->type == ARPHRD_NONE ||
dev->type == ARPHRD_SIT) {
printk(KERN_INFO
"Disabled Privacy Extensions on device %p(%s)\n",
--
Rémi Denis-Courmont
http://www.simphalempin.com/home/
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-11 12:44 UTC (permalink / raw)
To: abonilla, 'Pavel Machek', 'Jeff Garzik',
'Netdev list', 'kernel list',
'James P. Ketrenos'
In-Reply-To: <000f01c56dbf$9b15de90$600cc60a@amer.sykes.com>
On Friday 10 June 2005 16:23, Alejandro Bonilla wrote:
> > Adding kernel level wireless autoconfiguration duplicates the effort.
> > Since I am not going to give up a requirement to be able to stay radio
> > silent at boot (me too wants freedom, not only you), you need to add
> > disable=1 module parameter to each driver, which adds to the mess.
> >
> > ALSA does the Right Thing. Sound is completely muted out at
> > module load.
> > It's a user freedom to set desired volume level after that.
>
> Yeah right. I remember I had to google for 10 minutes to find the answer for
> this one. Why would you install something, for it to not work?
>
> It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
> and enable it. Why would it make you google for more things to do? ALSA mute
> on install is WAY way, not OK.
>
> You *will* have to use a How-To with ALSA, nobody knows that your sound
> would be off because some people decided it.
Well, which sound level shall be set instead? 100%? Maybe too loud for
my 500 watt loudpeakers, eh? 50%? Still too many. 5%? Nah.
My machine at work has a headphone which is anything but loud.
5% is nearly silence for it.
See? It's not a kernel matter at which volume sound must be set.
It is impossible to decide on the 'right' default.
> But this is out of the Topic. I agree with you all, but as I mentioned in a
> more current email, this is a laptop, not a server. Things behave
> differently and you want things faster. (Yes, I could have a script)
Or laptop oriented distro can have a script for you,
just like they already do have for DHCPizing all ifaces.
Not kernel business.
> What I'm saying, is that just as ALSA, you will have to google even more
> just to be able to look for the boot param for the driver for it to ASSOC on
> boot like the Original drive does. Instead, if you simply don't want to
> associate then turn off the Radio.
>
> It's a simple FN+F2 or depends on your laptop.
>
> Let's not make this a bigger thread, just decide and then do it that way.
> I'm looking at this on the side of a supporter, seeing the emails from
> users... "how do I make it behave as it was before" "it won't assoc on boot
> anymore"
Users which can not figure it by themself have not much power in dictating
how kernel drivers are written. Sure we listen to users, but we won't
blidly follow any and all suggestions.
If users want it different nodoby prohibits them from writing their own
drivers, right? Or patching existing ones, for that matter. Send patches to lkml
for discussion.
--
vda
^ permalink raw reply
* Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?
From: Andi Kleen @ 2005-06-11 10:25 UTC (permalink / raw)
To: Skywind; +Cc: davem, casavan, linux-kernel, netdev
In-Reply-To: <75052be705060607106a6c0882@mail.gmail.com>
Skywind <gnuwind@gmail.com> writes:
>
> It seems that kernel don't adjust these value automatic, is this a bug?
>
> I guess the mechanism of tcp.c in 2.6.11 have some changes(between
> 2.6.10), and it conduce to this result,
> Is this guess correctly?
Yes, there were some changes here when it was converted to a common
function for all hash tables (alloc_large_system_hash - the function
with the argument list from hell). Anyways, here's a quick fix.
DaveM for your consideration.
Adjust TCP mem order check to new alloc_large_system_hash
Signed-off-by: Andi Kleen <ak@suse.de>
--- linux-2.6.11-work/net/ipv4/tcp.c~ 2005-03-02 08:37:51.000000000 +0100
+++ linux-2.6.11-work/net/ipv4/tcp.c 2005-06-11 12:16:22.000000000 +0200
@@ -2337,7 +2337,7 @@
(tcp_bhash_size * sizeof(struct tcp_bind_hashbucket));
order++)
;
- if (order > 4) {
+ if (order >= 4) {
sysctl_local_port_range[0] = 32768;
sysctl_local_port_range[1] = 61000;
sysctl_tcp_max_tw_buckets = 180000;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox