* [patch] tcp connection tracking 2.4.19
@ 2002-10-08 20:50 Martin Renold
2002-10-08 21:06 ` Roberto Nibali
0 siblings, 1 reply; 11+ messages in thread
From: Martin Renold @ 2002-10-08 20:50 UTC (permalink / raw
To: linux-kernel
hi,
There is a bug in the stable 2.4.19 kernel in the ip_conntrack code that
allows the final ACK of a SYN - SYN/ACK - ACK tcp handshake to establish
an ASSURED connection even if it has a wrong sequence number. The current
code only checks the ACK number.
This allows a DoS attack that will make it impossible to establish *real*
connections for some days, once the maximum is reached. Somebody sent me
an exploit:
http://old.homeip.net/martin/cdos.tgz
So I wrote a simple patch against 2.4.19, but I must admit that I do not
really understand the code around it, especially why it does not mark
such a packet as invalid (I'm new to most things here).
diff -urN -X dontdiff kernel-source-2.4.19.origin/include/linux/netfilter_ipv4/ip_conntrack_tcp.h kernel-source-2.4.19.patch/include/linux/netfilter_ipv4/ip_conntrack_tcp.h
--- kernel-source-2.4.19.origin/include/linux/netfilter_ipv4/ip_conntrack_tcp.h Fri Aug 4 22:07:24 2000
+++ kernel-source-2.4.19.patch/include/linux/netfilter_ipv4/ip_conntrack_tcp.h Sat Oct 5 19:07:44 2002
@@ -24,8 +24,9 @@
{
enum tcp_conntrack state;
- /* Poor man's window tracking: sequence number of valid ACK
- handshake completion packet */
+ /* Poor man's window tracking: expected sequence and acknowledge
+ number of valid ACK handshake completion packet */
+ u_int32_t handshake_seq;
u_int32_t handshake_ack;
};
diff -urN -X dontdiff kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Fri Oct 4 08:13:38 2002
+++ kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Oct 5 20:45:49 2002
@@ -180,6 +180,8 @@
if (oldtcpstate == TCP_CONNTRACK_SYN_SENT
&& CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY
&& tcph->syn && tcph->ack)
+ conntrack->proto.tcp.handshake_seq
+ = tcph->ack_seq;
conntrack->proto.tcp.handshake_ack
= htonl(ntohl(tcph->seq) + 1);
WRITE_UNLOCK(&tcp_lock);
@@ -196,6 +198,7 @@
if (oldtcpstate == TCP_CONNTRACK_SYN_RECV
&& CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL
&& tcph->ack && !tcph->syn
+ && tcph->seq == conntrack->proto.tcp.handshake_seq
&& tcph->ack_seq == conntrack->proto.tcp.handshake_ack)
set_bit(IPS_ASSURED_BIT, &conntrack->status);
--
Thunder's just a noise, boys, lightnin' does the work
-- (Chad Brock/John Hadley/Kelly Garrett)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-08 20:50 Martin Renold
@ 2002-10-08 21:06 ` Roberto Nibali
2002-10-09 12:30 ` Gianni Tedesco
0 siblings, 1 reply; 11+ messages in thread
From: Roberto Nibali @ 2002-10-08 21:06 UTC (permalink / raw
To: Martin Renold; +Cc: linux-kernel
Hello Martin,
> There is a bug in the stable 2.4.19 kernel in the ip_conntrack code that
> allows the final ACK of a SYN - SYN/ACK - ACK tcp handshake to establish
> an ASSURED connection even if it has a wrong sequence number. The current
> code only checks the ACK number.
Yes, and more than that. You can remove ESTABLISHED entries in the
conntrack table by sending packets with the RST flag set and matching
the template <srcIP, srcPORT, dstIP, dstPORT>.
> This allows a DoS attack that will make it impossible to establish *real*
> connections for some days, once the maximum is reached. Somebody sent me
> an exploit:
:) You should probably send stuff like that to the netfilter-devel ml.
Besides that it isn't really an exploit.
> http://old.homeip.net/martin/cdos.tgz
>
> So I wrote a simple patch against 2.4.19, but I must admit that I do not
> really understand the code around it, especially why it does not mark
> such a packet as invalid (I'm new to most things here).
You might want to take a look at the TCP window tracking patch which
comes with the latest pom. It's part of the extra patches. This will
solve the problems for you.
> diff -urN -X dontdiff kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
> --- kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Fri Oct 4 08:13:38 2002
> +++ kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Oct 5 20:45:49 2002
> @@ -180,6 +180,8 @@
> if (oldtcpstate == TCP_CONNTRACK_SYN_SENT
> && CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY
> && tcph->syn && tcph->ack)
> + conntrack->proto.tcp.handshake_seq
> + = tcph->ack_seq;
> conntrack->proto.tcp.handshake_ack
> = htonl(ntohl(tcph->seq) + 1);
> WRITE_UNLOCK(&tcp_lock);
> @@ -196,6 +198,7 @@
> if (oldtcpstate == TCP_CONNTRACK_SYN_RECV
> && CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL
> && tcph->ack && !tcph->syn
> + && tcph->seq == conntrack->proto.tcp.handshake_seq
> && tcph->ack_seq == conntrack->proto.tcp.handshake_ack)
> set_bit(IPS_ASSURED_BIT, &conntrack->status);
>
Welcome to the world of almost-stateful packet filtering. Hey, other
than that, the 3wahas 'exploit' is old. Also don't I understand why they
claim that SYN cookies prevent syn flooding. Next time you meet someone
of the guys, tell them about the backlog queue.
Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-08 21:06 ` Roberto Nibali
@ 2002-10-09 12:30 ` Gianni Tedesco
2002-10-09 17:25 ` Roberto Nibali
0 siblings, 1 reply; 11+ messages in thread
From: Gianni Tedesco @ 2002-10-09 12:30 UTC (permalink / raw
To: Roberto Nibali; +Cc: Martin Renold, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 779 bytes --]
On Tue, 2002-10-08 at 22:06, Roberto Nibali wrote:
> Welcome to the world of almost-stateful packet filtering. Hey, other
> than that, the 3wahas 'exploit' is old. Also don't I understand why they
> claim that SYN cookies prevent syn flooding. Next time you meet someone
> of the guys, tell them about the backlog queue.
>
"When syncookies are enabled the packets are still answered and this
value [tcp_max_syn_backlog] is effectively ignored." -- From tcp(7)
manpage.
The whole point of syncookies is to negate the need for a backlog queue.
Or did I miss your point?
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-09 12:30 ` Gianni Tedesco
@ 2002-10-09 17:25 ` Roberto Nibali
2002-10-10 10:38 ` Gianni Tedesco
0 siblings, 1 reply; 11+ messages in thread
From: Roberto Nibali @ 2002-10-09 17:25 UTC (permalink / raw
To: Gianni Tedesco; +Cc: Martin Renold, linux-kernel
Hi,
> "When syncookies are enabled the packets are still answered and this
> value [tcp_max_syn_backlog] is effectively ignored." -- From tcp(7)
> manpage.
Fair enough. I thought that last time I checked with the code the SYN
cookie functionality would only kick in _after_ the backlog queue is full.
> The whole point of syncookies is to negate the need for a backlog queue.
Well, after a successful match of the MSS encoded part or the cookie,
you add it back to the SYN queue. But yes, the backlog queue is indeed
omited.
> Or did I miss your point?
Well, my point should have been stated more clearly. It is simply that
SYN cookies do not prevent you from being SYN flooded. They provide you,
from a user perspective view, a mean to still be able to log in onto
your server under a SYN flood because you will send legitimate ACKs and
because your connection will not be dropped.
It doesn't prevent SYN flooding, although I just checked back with
../Documentation/networking/ip-sysctrl.txt:
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
Send out syncookies when the syn backlog queue of a socket
overflows. This is to prevent against the common 'syn flood attack'
Default: FALSE
Note, that syncookies is fallback facility.
It MUST NOT be used to help highly loaded servers to stand
against legal connection rate. If you see synflood warnings
in your logs, but investigation shows that they occur
because of overload with legal connections, you should tune
another parameters until this warning disappear.
See: tcp_max_syn_backlog, tcp_synack_retries,
tcp_abort_on_overflow.
syncookies seriously violate TCP protocol, do not allow
to use TCP extensions, can result in serious degradation
of some services (f.e. SMTP relaying), visible not by you,
but your clients and relays, contacting you. While you see
synflood warnings in logs not being really flooded, your server
is seriously misconfigured.
The best thing is to go back and check with the actual implementation.
I'm just checking on ../net/ipv4/tcp_ipv4.c:tcp_v4_conn_request():
[...]
if (tcp_synq_is_full(sk) && !isn) {
#ifdef CONFIG_SYN_COOKIES
if (sysctl_tcp_syncookies) {
want_cookie = 1;
} else
#endif
goto drop;
}
/* Accept backlog is full. If we have already queued enough
* of warm entries in syn queue, drop request. It is better than
* clogging syn queue with openreqs with exponentially increasing
* timeout.
*/
if (tcp_acceptq_is_full(sk) && tcp_synq_young(sk) > 1)
goto drop;
[...]
Best regards and sorry for the confusion,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-09 17:25 ` Roberto Nibali
@ 2002-10-10 10:38 ` Gianni Tedesco
2002-10-10 18:06 ` Roberto Nibali
0 siblings, 1 reply; 11+ messages in thread
From: Gianni Tedesco @ 2002-10-10 10:38 UTC (permalink / raw
To: Roberto Nibali; +Cc: Martin Renold, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
On Wed, 2002-10-09 at 18:25, Roberto Nibali wrote:
> Hi,
>
> > "When syncookies are enabled the packets are still answered and this
> > value [tcp_max_syn_backlog] is effectively ignored." -- From tcp(7)
> > manpage.
>
> Fair enough. I thought that last time I checked with the code the SYN
> cookie functionality would only kick in _after_ the backlog queue is full.
It does. When using syn cookies you cant use some of the new advanced
features of tcp. Linux uses the backlog queue when not under attack.
When the queue overflows it just uses cookies - but can still accept
connections.
> > The whole point of syncookies is to negate the need for a backlog queue.
>
> Well, after a successful match of the MSS encoded part or the cookie,
> you add it back to the SYN queue. But yes, the backlog queue is indeed
> omited.
>
> > Or did I miss your point?
>
> Well, my point should have been stated more clearly. It is simply that
> SYN cookies do not prevent you from being SYN flooded. They provide you,
> from a user perspective view, a mean to still be able to log in onto
> your server under a SYN flood because you will send legitimate ACKs and
> because your connection will not be dropped.
>
> It doesn't prevent SYN flooding, although I just checked back with
> ../Documentation/networking/ip-sysctrl.txt:
> [snip]
> tcp_abort_on_overflow.
> syncookies seriously violate TCP protocol, do not allow
> to use TCP extensions, can result in serious degradation
> of some services (f.e. SMTP relaying), visible not by you,
> but your clients and relays, contacting you. While you see
> synflood warnings in logs not being really flooded, your server
> is seriously misconfigured.
I don't think these statements are entirely true. While it is true that
you can't use things like window scaling or SACK - syncookies 100%
successfully stop syn flood attacks.
The attack is that if you fill the syn backlog queue with bogus requests
then legitimate clients can no longer connect. The syn flood attack
isn't "your legitimate connections wont be able to use window scaling".
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-10 10:38 ` Gianni Tedesco
@ 2002-10-10 18:06 ` Roberto Nibali
0 siblings, 0 replies; 11+ messages in thread
From: Roberto Nibali @ 2002-10-10 18:06 UTC (permalink / raw
To: Gianni Tedesco; +Cc: Martin Renold, linux-kernel
>>Fair enough. I thought that last time I checked with the code the SYN
>>cookie functionality would only kick in _after_ the backlog queue is full.
> > It does. When using syn cookies you cant use some of the new advanced
> features of tcp. Linux uses the backlog queue when not under attack.
> When the queue overflows it just uses cookies - but can still accept
> connections.
That was my understanding so far. So then I haven't gone crazy, thank god.
> I don't think these statements are entirely true. While it is true that
> you can't use things like window scaling or SACK - syncookies 100%
> successfully stop syn flood attacks.
Someone needs to adjust the text then.
> The attack is that if you fill the syn backlog queue with bogus requests
> then legitimate clients can no longer connect. The syn flood attack
> isn't "your legitimate connections wont be able to use window scaling".
I completely agree with this definition of SYN flooding and then I will
also say that you can 'stop' SYN flooding, well, at least you give
legitimate clients a real chance to still successfully connect to your
service, while it is under a SYN flood. I think we agree now. It should
only be remarked that the line is still flooded, thus the wording "100
stop SYN flood" is simply inappropriate in my eyes. It's all a matter of
definition.
Regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
^ permalink raw reply [flat|nested] 11+ messages in thread
* [patch] tcp connection tracking 2.4.19
@ 2002-10-16 7:48 Martin Renold
2002-10-16 22:46 ` Harald Welte
2002-10-17 8:26 ` Svenning Sorensen
0 siblings, 2 replies; 11+ messages in thread
From: Martin Renold @ 2002-10-16 7:48 UTC (permalink / raw
To: netfilter-devel
hi,
There is a bug in the stable 2.4.19 kernel in the ip_conntrack code that
allows the final ACK of a SYN - SYN/ACK - ACK tcp handshake to establish
an ASSURED connection even if it has a wrong sequence number. The current
code only checks the ACK number.
This allows a DoS attack:
http://old.homeip.net/martin/cdos.tgz
I already sent this to linux-kernel, and was redirected:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.1/0297.html
I know about the TCP window tracking patch, but I expect from the
unpatched "stable" kernel no such behaviour.
So I wrote a simple patch against 2.4.19, but I must admit that I do not
really understand the code around it, especially why it does not mark
such a packet as invalid (I'm new to most things here). It's running
right now on 3-4 machines.
diff -urN -X dontdiff kernel-source-2.4.19.origin/include/linux/netfilter_ipv4/ip_conntrack_tcp.h kernel-source-2.4.19.patch/include/linux/netfilter_ipv4/ip_conntrack_tcp.h
--- kernel-source-2.4.19.origin/include/linux/netfilter_ipv4/ip_conntrack_tcp.h Fri Aug 4 22:07:24 2000
+++ kernel-source-2.4.19.patch/include/linux/netfilter_ipv4/ip_conntrack_tcp.h Sat Oct 5 19:07:44 2002
@@ -24,8 +24,9 @@
{
enum tcp_conntrack state;
- /* Poor man's window tracking: sequence number of valid ACK
- handshake completion packet */
+ /* Poor man's window tracking: expected sequence and acknowledge
+ number of valid ACK handshake completion packet */
+ u_int32_t handshake_seq;
u_int32_t handshake_ack;
};
diff -urN -X dontdiff kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Fri Oct 4 08:13:38 2002
+++ kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Oct 5 20:45:49 2002
@@ -180,6 +180,8 @@
if (oldtcpstate == TCP_CONNTRACK_SYN_SENT
&& CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY
&& tcph->syn && tcph->ack)
+ conntrack->proto.tcp.handshake_seq
+ = tcph->ack_seq;
conntrack->proto.tcp.handshake_ack
= htonl(ntohl(tcph->seq) + 1);
WRITE_UNLOCK(&tcp_lock);
@@ -196,6 +198,7 @@
if (oldtcpstate == TCP_CONNTRACK_SYN_RECV
&& CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL
&& tcph->ack && !tcph->syn
+ && tcph->seq == conntrack->proto.tcp.handshake_seq
&& tcph->ack_seq == conntrack->proto.tcp.handshake_ack)
set_bit(IPS_ASSURED_BIT, &conntrack->status);
--
Thunder's just a noise, boys, lightnin' does the work
-- (Chad Brock/John Hadley/Kelly Garrett)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-16 7:48 [patch] tcp connection tracking 2.4.19 Martin Renold
@ 2002-10-16 22:46 ` Harald Welte
2002-10-17 20:29 ` Martin Renold
2002-10-17 8:26 ` Svenning Sorensen
1 sibling, 1 reply; 11+ messages in thread
From: Harald Welte @ 2002-10-16 22:46 UTC (permalink / raw
To: Martin Renold; +Cc: netfilter-devel
On Wed, Oct 16, 2002 at 09:48:37AM +0200, Martin Renold wrote:
> hi,
>
> There is a bug in the stable 2.4.19 kernel in the ip_conntrack code that
> allows the final ACK of a SYN - SYN/ACK - ACK tcp handshake to establish
> an ASSURED connection even if it has a wrong sequence number. The current
> code only checks the ACK number.
The question is whether this is really to be called a 'bug'. Netfilter
connection tracking never claimed to do full state tracking, neither did
it claim to do sequence number tracking. It does all it can without
tracking sequence/ack numbers and window sizes.
You can also send FIN flagged packets with a wrong sequence number to
terminate a connection (conntrack entry, that is).
This is not a bug in the code, but an architectural disadvantage of
doing this kind of simplified non-sequence-number-tracking TCP state
tracking.
> --
> Thunder's just a noise, boys, lightnin' does the work
> -- (Chad Brock/John Hadley/Kelly Garrett)
--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-16 7:48 [patch] tcp connection tracking 2.4.19 Martin Renold
2002-10-16 22:46 ` Harald Welte
@ 2002-10-17 8:26 ` Svenning Sorensen
2002-10-17 8:53 ` Martin Renold
1 sibling, 1 reply; 11+ messages in thread
From: Svenning Sorensen @ 2002-10-17 8:26 UTC (permalink / raw
To: Martin Renold, netfilter-devel
At 09:48 16-10-2002, Martin Renold wrote:
>So I wrote a simple patch against 2.4.19, but I must admit that I do not
>really understand the code around it, especially why it does not mark
>such a packet as invalid (I'm new to most things here). It's running
>right now on 3-4 machines.
I can't speak about the merits of this patch, since I haven't tried it, but
I believe there is a bug in it:
>--- kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Fri Oct 4 08:13:38 2002
>+++ kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Oct 5 20:45:49 2002
>@@ -180,6 +180,8 @@
> if (oldtcpstate == TCP_CONNTRACK_SYN_SENT
> && CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY
> && tcph->syn && tcph->ack)
>+ conntrack->proto.tcp.handshake_seq
>+ = tcph->ack_seq;
> conntrack->proto.tcp.handshake_ack
> = htonl(ntohl(tcph->seq) + 1);
> WRITE_UNLOCK(&tcp_lock);
>--
Note that the original statement will now be unconditionally executed.
You need to enclose the statements by brackets.
Svenning
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-17 8:26 ` Svenning Sorensen
@ 2002-10-17 8:53 ` Martin Renold
0 siblings, 0 replies; 11+ messages in thread
From: Martin Renold @ 2002-10-17 8:53 UTC (permalink / raw
To: Svenning Sorensen, Stephane Ouellette, netfilter-devel
On Thu, Oct 17, 2002 at 10:26:48AM +0200, Svenning Sorensen wrote:
> I believe there is a bug in it:
Oops! Stephane Ouelle also just reported, thank you.
> Note that the original statement will now be unconditionally executed.
> You need to enclose the statements by brackets.
So here it is again, corrected (I'm going to test this in a minute):
diff -urN -X dontdiff kernel-source-2.4.19.origin/include/linux/netfilter_ipv4/ip_conntrack_tcp.h kernel-source-2.4.19.patch/include/linux/netfilter_ipv4/ip_conntrack_tcp.h
--- kernel-source-2.4.19.origin/include/linux/netfilter_ipv4/ip_conntrack_tcp.h Fri Aug 4 22:07:24 2000
+++ kernel-source-2.4.19.patch/include/linux/netfilter_ipv4/ip_conntrack_tcp.h Sun Oct 6 12:35:19 2002
@@ -24,8 +24,9 @@
{
enum tcp_conntrack state;
- /* Poor man's window tracking: sequence number of valid ACK
- handshake completion packet */
+ /* Poor man's window tracking: expected sequence and acknowledge
+ number of valid ACK handshake completion packet */
+ u_int32_t handshake_seq;
u_int32_t handshake_ack;
};
diff -urN -X dontdiff kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Aug 3 02:39:46 2002
+++ kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Thu Oct 17 09:41:03 2002
@@ -179,9 +179,12 @@
/* Poor man's window tracking: record SYN/ACK for handshake check */
if (oldtcpstate == TCP_CONNTRACK_SYN_SENT
&& CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY
- && tcph->syn && tcph->ack)
+ && tcph->syn && tcph->ack) {
+ conntrack->proto.tcp.handshake_seq
+ = tcph->ack_seq;
conntrack->proto.tcp.handshake_ack
= htonl(ntohl(tcph->seq) + 1);
+ }
WRITE_UNLOCK(&tcp_lock);
/* If only reply is a RST, we can consider ourselves not to
@@ -196,6 +199,7 @@
if (oldtcpstate == TCP_CONNTRACK_SYN_RECV
&& CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL
&& tcph->ack && !tcph->syn
+ && tcph->seq == conntrack->proto.tcp.handshake_seq
&& tcph->ack_seq == conntrack->proto.tcp.handshake_ack)
set_bit(IPS_ASSURED_BIT, &conntrack->status);
bye,
Martin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch] tcp connection tracking 2.4.19
2002-10-16 22:46 ` Harald Welte
@ 2002-10-17 20:29 ` Martin Renold
0 siblings, 0 replies; 11+ messages in thread
From: Martin Renold @ 2002-10-17 20:29 UTC (permalink / raw
To: Harald Welte; +Cc: netfilter-devel
On Thu, Oct 17, 2002 at 12:46:43AM +0200, Harald Welte wrote:
> On Wed, Oct 16, 2002 at 09:48:37AM +0200, Martin Renold wrote:
> The question is whether this is really to be called a 'bug'. Netfilter
> connection tracking never claimed to do full state tracking, neither did
> it claim to do sequence number tracking. It does all it can without
> tracking sequence/ack numbers and window sizes.
>
> You can also send FIN flagged packets with a wrong sequence number to
> terminate a connection (conntrack entry, that is).
Well, I think the point is that if somebody sends a bad FIN (or RST)
packet, he has to know both used port numbers, and even then I perhaps
wouldn't care, I would still be able to establish a new connection.
I do not want a full state tracking, I just don't like being shut out of
my system for several days. And I called it a bug because one half of the
code to handle this situation was already there.
bye,
Martin
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-10-17 20:29 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-16 7:48 [patch] tcp connection tracking 2.4.19 Martin Renold
2002-10-16 22:46 ` Harald Welte
2002-10-17 20:29 ` Martin Renold
2002-10-17 8:26 ` Svenning Sorensen
2002-10-17 8:53 ` Martin Renold
-- strict thread matches above, loose matches on Subject: below --
2002-10-08 20:50 Martin Renold
2002-10-08 21:06 ` Roberto Nibali
2002-10-09 12:30 ` Gianni Tedesco
2002-10-09 17:25 ` Roberto Nibali
2002-10-10 10:38 ` Gianni Tedesco
2002-10-10 18:06 ` Roberto Nibali
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.