Date: Thu, 24 Sep 2009 10:07:34 -0400 From: Michael Powell <nightrecon@hotmail.com> To: freebsd-questions@freebsd.org Subject: Re: net.inet.ip.random_id possible ASA problems? Message-ID: <h9fudr$u7l$1@ger.gmane.org> References: <4ABB679D.7030604@poughkeepsieschools.org> <4ABB7251.4060004@ibctech.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Bertrand wrote: > B. Cook wrote: > > [ big snip ] > >> So after 6 hours of cisco techs.. all they could come up with is a "... >> possible duplex mis-match.. " >> >> *sigh* >> >> So dropping my pf rules (which contain scrub settings) made no >> difference, I found the above URL which seeme to point to >> net.inet.ip.random_id. >> >> I can not find any 'freebsd.org' documentation pertaining to it >> regarding what it actually does. I do however find it scattered amongst >> tons of 'FreeBSD hardening' docs.. >> >> Can anyone shed some light on what this does? > > IIRC, random_id allows initial TCP sequence numbers to be randomized. > > Some OS sequence TCP packets in an incremental fashion, thereby making > it quite easy for an attacker using a TCP Idle Scan to hijack a session, > and extremely easy while the box is under very light network load. > > https://www.kb.cert.org/vuls/id/498440 In earlier versions this was in the kernel conf and associated with ipfw. This was changed when default firewall was stripped from GENERIC in favor of selecting one of the three available by module for flexibility. It was replace by the sysctl net.inet.ip.random_id MIB. I don't recall if it defaults to on or off, it is easily checked by sysctl net.inet.ip.random_id. If it is "1", you might try setting to "0" in /etc/sysctl.conf. Also pull any scrub rules from pf to eliminate another variable. > I've never seen this setting cause any detriment, but we only use Cisco > routers, not ASA's. AFAIK, random_id is off by default. > > It would be rather handy if they would provide you with some of the > ASA's config snips, and perhaps interface counts and logs. > > You may also want to capture a pcap on the 'problematic' box to see if > you can find anything interesting: > > # tcpdump -n -i em0 -s 0 -w /home/steve/packet-cap.pcap > > Steve This step is going to be needed to develop more info on the problem. You may also want to research these: net.inet.tcp.rfc1323=1 # Enable RFC1323 extensions (TCP window scaling) net.inet.tcp.inflight.enable=0 # Use automatic TCP window-scaling Perhaps the adaptive sliding window scaling algorithms in FreeBSD are incompatible and need to be disabled. A correlation comparison of the tcpdump capture and the Cisco engineers' debug dumps may shed light if this is somehow related. -Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?h9fudr$u7l$1>