netdev - Re: ports beeing reused too fast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A052991.5040009@cosmosbay.com>
Date:	Sat, 09 May 2009 08:58:25 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Octavian Purdila <opurdila@...acom.com>
CC:	netdev@...r.kernel.org
Subject: Re: ports beeing reused too fast

Octavian Purdila a écrit :
> Hi,
> 
> We've been running into an issue where a firewall would drop packets when an 
> moderate (~360) connection rate was going through it. It looks like the 
> firewall is dropping the SYNs that reuse ports "too fast". 
> 
> We have no issues with Linux 2.6.7, so I guess the behavior changed because of 
> this this commit:
> 
> commit 6df716340da3a6fdd33d73d7ed4c6f7590ca1c42
> Author: Stephen Hemminger <shemminger@...l.org>
> Date:   Thu Nov 3 16:33:23 2005 -0800
> 
>     [TCP/DCCP]: Randomize port selection
> 
> 
> Now, I did some tests to confirm my suspicion. Basically, I am simulating a 
> connection rate test (I've attached the .c to this email) by opening up 
> connections and closing them - one at a time, and noting down the ports used, 
> then looking for duplicate ports and printing the distance between the 
> connection no.
> 
> Here is one of the runs, which make 1000 iterations:
> 
> listening (port 1242)
>  port reused: 38203: distance 578 (624,46)
>  port reused: 55693: distance 85 (147,62)
>  port reused: 38269: distance 803 (872,69)
>  port reused: 46239: distance 249 (344,95)
>  port reused: 40981: distance 215 (319,104)
>  port reused: 46246: distance 524 (641,117)
>  port reused: 43990: distance 378 (498,120)
>  port reused: 53766: distance 52 (232,180)
>  port reused: 44199: distance 194 (383,189)
>  port reused: 59464: distance 173 (384,211)
>  port reused: 44417: distance 264 (492,228)
>  port reused: 56989: distance 229 (553,324)
>  port reused: 60117: distance 69 (394,325)
>  port reused: 44549: distance 179 (566,387)
>  port reused: 39213: distance 300 (801,501)
>  port reused: 60166: distance 152 (671,519)
>  port reused: 44178: distance 108 (712,604)
>  port reused: 46516: distance 6 (792,786)
>  port reused: 55754: distance 95 (969,874)
> 19 ports were being reused
> 
> Running the same test on 2.6.7 yields a "0 ports were being reused" on all 
> tests that I've ran (10 or so).
> 
> Isn't it desirable to have the behavior from 2.6.7? 
> 
> I've looked over the  code and it looks right, so maybe net_random() is not 
> random enough? Or maybe there are side effects because of the % port_range?
> 

Random is random :)
Probability a port can be reused pretty fast is not nul.

So yes, behavior you discovered is expected, when we switched port selection
from a sequential one (not very secure btw) to a random one.

Any strong reason why a firewall would drop a SYN because ports were used in a 
previous session ?

Previous mode can be restored by application itself, using a bind() before
connect(), if this application knows it has a very high rate of connections
from a particular host to a particular host. (source ports range being
small anyway, so your firewall could complain again)


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html