net.inet.ip.random_id possible ASA problems?

Michael Powell nightrecon at hotmail.com
Thu Sep 24 14:07:16 UTC 2009


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






More information about the freebsd-questions mailing list