[3694] in linux-net channel archive
Re: sequence numbers
daemon@ATHENA.MIT.EDU (Zach B.)
Sun Jul 14 22:34:49 1996
Date: Sat, 13 Jul 1996 19:41:11 -0700 (PDT)
From: "Zach B." <zab@teleport.com>
To: Craig Brozefsky <cosmo@ebs.net>
cc: linux-net@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.91.960712191322.30887A-100000@gilligan.ebs.net>
> Out of curiosity how does the linux kernel generate it's initial sequence
> number for a socket connection? Is it like most Berkeley derived ones
> with incriment at 128 microseconds + 64 per connection, or does it follow
> the specifications of RFC 793?
Until recently I beleive it was. Around 2.0.1 (?? someone clue me in..
I'm too lazy to dig through patches :)) Linus incorporated Theodore Ts'o's
secure initial tcp sequence number code.. look in drivers/char/random.c
for
/*
* TCP initial sequence number picking. This uses the random number
* generator to pick an initial secret value. This value is hashed
* along with the TCP endpoint information to provide a unique
* starting point for each pair of TCP endpoints. This defeats
* attacks which rely on guessing the initial TCP sequence number.
* This algorithm was suggested by Steve Bellovin.
*/
__u32 secure_tcp_sequence_number(__u32 saddr, __u32 daddr,
__u16 sport, __u16 dport)
> Also are there any known holes in the ipfirewall.c code that has been
> incorporated into the linux kernel for masquerading and filtering
> purposes? I know they took care of the fragmentation problem, but are
> their other known types of attacks?
Isn't the only way one can get around this by forcing reassembly of the
packets before they pass the firewall? I seem to rememember seeing that
flag somewhere in the kernel sources :).
zach
