2009/5/22, Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>:
> On Fri, 22 May 2009, Anatoly Muliarski wrote:
>
> > The problem consists in that RST-packet with wrong sequence number
> > must be treated as INVALID.
> > IMHO, the conntrack code should be changed in this way.
> >
> > I wrote a fix( sorry, I don't experienced in kernel tcp stack -
> > correct me if I somewhere wrong).
> >
> > *** nf_conntrack_proto_tcp.c 2009-05-22 07:22:43.000000000 +0300
> > --- /usr/src/linux/1/nf_conntrack_proto_tcp.c 2008-09-08
> > 13:20:51.000000000 +0300
> > *************** static int tcp_packet(struct nf_conn *ct
> > *** 969,979 ****
> > problem case, so we can delete the conntrack
> > immediately. --RR */
> > if (th->rst) {
> > ! if (ntohl(th->seq) < ct->proto.tcp.last_seq) {
> > ! ct->proto.tcp.state = old_state;
> > ! return -NF_DROP;
> > ! }
> > ! else if (del_timer(&ct->timeout))
> > ct->timeout.function((unsigned long)ct);
> > return NF_ACCEPT;
> > }
> > --- 969,975 ----
> > problem case, so we can delete the conntrack
> > immediately. --RR */
> > if (th->rst) {
> > ! if (del_timer(&ct->timeout))
> > ct->timeout.function((unsigned long)ct);
> > return NF_ACCEPT;
> > }
>
> That won't work: the packet which sequence number was recorded in last_seq
> may get lost in transit to the destination and we may receive a *valid*
> RST with a sequence number less than the one in last_seq.
>
> This is the main problem: we can never be sure the packets which are seen
> by firewall do really reach the destination or they order is preserved.
>
> Best regards,
> Jozsef
OK.
We could save the LAST sequence number as a current one.
So we keep the connection and mark the current RST as invalid and
correctly react on the following ones. Unfortunately this does not
solve the main problem - unable to know whether the received sequence
number is valid or not. As an vague idea - we could track the ack
number from other direction and so keep the last delivered sequence
number. What can say about it?
I added a line in my patch.
*** nf_conntrack_proto_tcp.c 2009-05-22 11:00:29.000000000 +0300
--- /usr/src/linux/1/nf_conntrack_proto_tcp.c 2008-09-08
13:20:51.000000000 +0300
*************** static int tcp_packet(struct nf_conn *ct
*** 969,980 ****
problem case, so we can delete the conntrack
immediately. --RR */
if (th->rst) {
! if (ntohl(th->seq) < ct->proto.tcp.last_seq) {
! ct->proto.tcp.state = old_state;
! ct->proto.tcp.last_seq = ntohl(th->seq);
! return -NF_DROP;
! }
! else if (del_timer(&ct->timeout))
ct->timeout.function((unsigned long)ct);
return NF_ACCEPT;
}
--- 969,975 ----
problem case, so we can delete the conntrack
immediately. --RR */
if (th->rst) {
! if (del_timer(&ct->timeout))
ct->timeout.function((unsigned long)ct);
return NF_ACCEPT;
}
--
Best regards
Anatoly Muliarski
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
