With re's permission, I'm going to commit FreeBSD's fix for the RST part of the slipping in the window attack to 4.11 in the next few days. That's not a big deal, we seem to have an acceptable solution there. (See tcp_input.c rev 1.235 for more info.)
The SYN side of the equation, however, is a bit more tricky. The proposed RFC recommends ACKing SYN packets in the window, just like we do to SYN packets to the left of the window right now.
For the life of me, I can't figure out why SYN packets (other than delayed retransmissions of the original SYN) would ever show up once a connection is in the ESTABLISHED state. So, I'm proposing the attached patch, which simply ignores any packet with the SYN flag on it while a connection is in the ESTABLISHED state. This means that SYN packets left of the window will no longer receive an ACK, and SYN packets in the window will no longer reset the connection. In all states other than ESTABLISHED, SYN packets are handled as they were before, in case there's some edge case where that could happen.
What are people's thoughts on this? I'm especially interested how stateful firewalls like IPF or PF would handle such a situation. How do they respond to unexpected SYN packets?
Mike "Silby" Silbersack
diff -u -r /usr/src/sys.old/netinet/tcp_input.c /usr/src/sys/netinet/tcp_input.c
--- /usr/src/sys.old/netinet/tcp_input.c Mon Jan 3 01:11:40 2005
+++ /usr/src/sys/netinet/tcp_input.c Mon Jan 3 01:17:03 2005
@@ -136,6 +136,11 @@
&tcp_insecure_rst, 0,
"Follow the old (insecure) criteria for accepting RST packets.");
+static int tcp_insecure_syn = 0;
+SYSCTL_INT(_net_inet_tcp, OID_AUTO, insecure_syn, CTLFLAG_RW,
+ &tcp_insecure_syn, 0,
+ "Follow the old criteria allowing SYN packets to reset a connection.");
+
SYSCTL_NODE(_net_inet_tcp, OID_AUTO, reass, CTLFLAG_RW, 0,
"TCP Segment Reassembly Queue");
@@ -1560,6 +1565,13 @@
}
}
goto drop;
+ }
+
+ if (thflags & TH_SYN) {
+ if (tp->t_state == TCPS_ESTABLISHED &&
+ tcp_insecure_syn == 0) {
+ goto drop;
+ }
}
/*
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
