Re: tcp syn cache random reseed

2016-03-29 Thread Martin Pieuchot
On 28/03/16(Mon) 23:56, Alexander Bluhm wrote: > On Mon, Mar 21, 2016 at 12:58:41PM +0100, Alexander Bluhm wrote: > > The attack I see is that you can measure the bucket distribution > > by timing the SYN+ACK response. You can collect samples that end > > in the same bucket. After you have collec

Re: tcp syn cache random reseed

2016-03-28 Thread Alexander Bluhm
On Mon, Mar 21, 2016 at 12:58:41PM +0100, Alexander Bluhm wrote: > The attack I see is that you can measure the bucket distribution > by timing the SYN+ACK response. You can collect samples that end > in the same bucket. After you have collected enough, start your > DoS attack. I think that just

Re: tcp syn cache random reseed

2016-03-28 Thread Alexander Bluhm
On Mon, Mar 21, 2016 at 11:05:25AM +0100, Martin Pieuchot wrote: > I like it. Do you think it could be useful to export the value of the > current active cache set and/or the value of ``tcp_syn_use_limit''? When the active cache set switches, the reseed counter increments. It might be usefull to

Re: tcp syn cache random reseed

2016-03-24 Thread Ted Unangst
Alexander Bluhm wrote: > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > > The drawback is that the the cache lookup has to be done in two syn > > caches when an ACK arrives. > > This can be prevented most of the time. Switch the cache only after > 10 uses. So most of the

Re: tcp syn cache random reseed

2016-03-21 Thread Claudio Jeker
On Sun, Mar 20, 2016 at 07:28:45PM +0100, Alexander Bluhm wrote: > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > > Perhaps the tcps_sc_seedrandom counter with a netstat -s line should > > be commited anyway to show the problem. > > ok? OK claudio@ > bluhm > > Index: sys/ne

Re: tcp syn cache random reseed

2016-03-21 Thread Alexander Bluhm
On Mon, Mar 21, 2016 at 08:25:59PM +1000, David Gwynne wrote: > how can i judge if this is better than just using a single hash with a strong > function? The attack I see is that you can measure the bucket distribution by timing the SYN+ACK response. You can collect samples that end in the same

Re: tcp syn cache random reseed

2016-03-21 Thread David Gwynne
> On 21 Mar 2016, at 4:28 AM, Alexander Bluhm wrote: > > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: >> Perhaps the tcps_sc_seedrandom counter with a netstat -s line should >> be commited anyway to show the problem. > > ok? how can i judge if this is better than just using

Re: tcp syn cache random reseed

2016-03-21 Thread Martin Pieuchot
On 20/03/16(Sun) 19:19, Alexander Bluhm wrote: > On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > > The drawback is that the the cache lookup has to be done in two syn > > caches when an ACK arrives. > > This can be prevented most of the time. Switch the cache only after > 1

Re: tcp syn cache random reseed

2016-03-20 Thread Alexander Bluhm
On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > Perhaps the tcps_sc_seedrandom counter with a netstat -s line should > be commited anyway to show the problem. ok? bluhm Index: sys/netinet/tcp_input.c === RCS file:

Re: tcp syn cache random reseed

2016-03-20 Thread Alexander Bluhm
On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote: > The drawback is that the the cache lookup has to be done in two syn > caches when an ACK arrives. This can be prevented most of the time. Switch the cache only after 10 uses. So most of the time the passive cache is empty and

tcp syn cache random reseed

2016-03-19 Thread Alexander Bluhm
Hi, To prevent attacks on the hash buckets of the syn cache, our TCP stack reseeds the hash function every time the cache is empty. Unfortunatly the attacker can prevent the reseeding by sending unanswered SYN packes periodically. I fix this by having an active syn cache that gets new entries and