Chuck Swiger | 3 Jan 23:04 2011
Picon

Re: Trimming TCP options

Hi, Mihai--

I'd meant to reply to this earlier, but holiday travel interfered.  :-)

On Dec 30, 2010, at 7:06 AM, Mihai Chelaru wrote:
> On 12/30/10 00:45, Greg Troxel wrote:
>> Could you explain
>>  how long you've been running this
> 
> This is my workstation, up since yesterday with normal tasks - browsing,
> mail, radio, torrents, ssh/telnet/rdp client etc.

It's important to note that (most?) TCP stacks will resend SYN packets with fewer TCP options set if the
initial SYN request doesn't get answered in some fashion.  To validate that your changes are working as
expected, you should tcpdump filtering for SYN packets and watch out for duplicate SYNs being sent.

>>  how other implementations behave?  (Specifically, does this make us
>>  like the rest, or different?)
> 
> Bytes requested by each option:
> 
>           SACKP WScale Timestamps Use_EOL
> 
> NetBSD      4      4        12      N
> FreeBSD*    2-3    3-4    10-13     Y     
> Linux-2627  2      4        10      Y  
> Win2003     4      4        12      N(?)
> Cisco IOS   4      4        10      Y
> WinXP       4      4        12      N(?)
> Win7        4      4        ?       N(?)
(Continue reading)

Mihai Chelaru | 4 Jan 10:48 2011
Picon

Re: Trimming TCP options

Pe 04.01.2011 00:04, Chuck Swiger a scris:
> It's important to note that (most?) TCP stacks will resend SYN packets with fewer TCP options set if the
initial SYN request doesn't get answered in some fashion.  To validate that your changes are working as
expected, you should tcpdump filtering for SYN packets and watch out for duplicate SYNs being sent.
>

Hi Chuck !

It's not NetBSD case, where by default all 3 retransmits will use the 
same options.

I modified this morning a little bit that code, and let initial syn and 
first retransmit with full options, the second retransmit with MSS 
option only and the last one with no options at all, and added some 
stats. Until now results look good:

         1072 connection requests
         1654 connection accepts
         2196 connections established (including accepts)
         2721 connections closed (including 47 drops)
         145 embryonic connections dropped
         400 SYN options degraded -> incremented at second syn re-xmit
         2 connected with no options -> connection established after 
second syn re-xmit

I'll keep an eye on the last counter in the following days.

> Hmm, I find it more useful to describe TCP options by strings representing the options in the sequence they
appear, which is the mechanism various OS fingerprinting tools like NMAP, p0f, etc use.
>
(Continue reading)

Chuck Swiger | 4 Jan 19:08 2011
Picon

Re: Trimming TCP options

Hi, Mihai--

On Jan 4, 2011, at 1:48 AM, Mihai Chelaru wrote:
> It's not NetBSD case, where by default all 3 retransmits will use the same options.
> 
> I modified this morning a little bit that code, and let initial syn and first retransmit with full options,
the second retransmit with MSS option only and the last one with no options at all, and added some stats.
Until now results look good:
> 
>        1072 connection requests
>        1654 connection accepts
>        2196 connections established (including accepts)
>        2721 connections closed (including 47 drops)
>        145 embryonic connections dropped
>        400 SYN options degraded -> incremented at second syn re-xmit
>        2 connected with no options -> connection established after second syn re-xmit
> 
> I'll keep an eye on the last counter in the following days.

Excellent.  While TCP stacks are required to implement NOP, EOL, and MSS, and should also be written to
simply pass over options which they do not understand, some don't, and some folks use firewalls which drop
various options, so falling back to M only is a good procedure.

>> Hmm, I find it more useful to describe TCP options by strings representing the options in the sequence
they appear, which is the mechanism various OS fingerprinting tools like NMAP, p0f, etc use.
>> 
>> NetBSD: MNWSNNNT
> 
> It's even MNWSNNNNT (one more N).

(Continue reading)

Thor Lancelot Simon | 4 Jan 20:14 2011
Picon

Accept filter semantics (Re: Handling of DOS attacks in NetBSD 5)

On Tue, Jan 04, 2011 at 09:36:30AM -0700, Sverre Froyen wrote:
> Hi,
> 
> In the past, I have observed DOS attacks where a client connects to port 80 
> and then leaves the connection open indefinitely. Repeating the process can 
> easily tie up all available http processes.
> 
> I recently upgraded several servers to NetBSD 5 and I now observe a slightly 
> modified behavior, presumably because of the accept_filter(9) addtion to the 
> kernel. Instead of http process starvation, I now observe between one and two 
> hundred TCP connections that are in the "ESTABLISHED" state (as reported by 
> netstat -s). Once this happens, the server denies additional HTTP requests.

There is a problem here: a new socket option is probably required to
allow the application to set a timeout for conections being processed
by the accept filter.  But what to do upon timeout?

Changing the behavior of the filter to just allow connections through
is unsafe: it can break applications that expect that once dataready
lets the connection through, some minimal-size read will not block.

Perhaps it can be changed to drop connections; but this too is a change
in the semantics of the existing filter, albeit one less likely to cause
applications to go catatonic or spinny.

Irritatingly, too, we cannot use the existing receive timeout socket
option to control this behavior, since it is (correctly) inherited
from the listen socket to the accepted socket.

So there's some thought and some new code required here.  All I can say
(Continue reading)

Sad Clouds | 5 Jan 00:28 2011

Re: Accept filter semantics (Re: Handling of DOS attacks in NetBSD 5)

On Tue, 4 Jan 2011 14:14:11 -0500
Thor Lancelot Simon <tls <at> panix.com> wrote:

> On Tue, Jan 04, 2011 at 09:36:30AM -0700, Sverre Froyen wrote:
> > Hi,
> > 
> > In the past, I have observed DOS attacks where a client connects to
> > port 80 and then leaves the connection open indefinitely. Repeating
> > the process can easily tie up all available http processes.
> > 
> > I recently upgraded several servers to NetBSD 5 and I now observe a
> > slightly modified behavior, presumably because of the accept_filter
> > (9) addtion to the kernel. Instead of http process starvation, I
> > now observe between one and two hundred TCP connections that are in
> > the "ESTABLISHED" state (as reported by netstat -s). Once this
> > happens, the server denies additional HTTP requests.
> 
> There is a problem here: a new socket option is probably required to
> allow the application to set a timeout for conections being processed
> by the accept filter.  But what to do upon timeout?

Does using accept filters offer a dramatic performance improvement? It
seems to me that using accept filters opens up more avenues for DOS
attacks.

Web servers that handle many connections use kernel event notification,
i.e. kqueue, epoll, etc., which don't really need accept filters, do
they? Apache is probably the only web server that might benefit from
them.

(Continue reading)

Joerg Sonnenberger | 5 Jan 03:11 2011
Picon

Re: Accept filter semantics (Re: Handling of DOS attacks in NetBSD 5)

On Tue, Jan 04, 2011 at 11:28:32PM +0000, Sad Clouds wrote:
> Does using accept filters offer a dramatic performance improvement? It
> seems to me that using accept filters opens up more avenues for DOS
> attacks.

Yes, they do.

> Web servers that handle many connections use kernel event notification,
> i.e. kqueue, epoll, etc., which don't really need accept filters, do
> they? Apache is probably the only web server that might benefit from
> them.

You are mixing up two completely separate issues. Accept filters for
HTTP allow ensuring serving traffic with four syscalls per request
(ignoring keep alive): accept, read, write, close. The accept filter
ensures that the read doesn't have to loop.

Joerg

Patrick Welche | 6 Jan 14:37 2011
Picon
Picon

dhcp classless routes

I can see how to write the equivalent of

  route add -net w.x.y.z/m g.a.t.e

in /etc/dhcpd.conf using the base system's dhcpd and dhcpcd a la
rfc3442. Am I right in thinking that there is no way of doing the
equivalent of

  route add -net w.x.y.z/m g.a.t.e -iface

?

Cheers,

Patrick

Roy Marples | 6 Jan 18:12 2011
Picon

Re: dhcp classless routes

Hi Patrick

On 06/01/2011 13:37, Patrick Welche wrote:
> I can see how to write the equivalent of
>
>    route add -net w.x.y.z/m g.a.t.e
>
> in /etc/dhcpd.conf using the base system's dhcpd and dhcpcd a la
> rfc3442. Am I right in thinking that there is no way of doing the
> equivalent of
>
>    route add -net w.x.y.z/m g.a.t.e -iface

You can do this :)
You need this in dhcpd.conf

option classless-static-routes code 121 = array of unsigned integer 8;

option classless-static-routes m,w,x,y,z,g,a,t,e ... ;

Like so, adding a default route
option classless-static-routes 0,192,168,0,1;

Something more complex
option classless-static-routes 0,10,73,1,1,24,10,73,0,10,73,1,1,24,10,73,2,
10,73,1,1,32,10,0,0,1,10,73,1,1;

Thanks

Roy
(Continue reading)

Mihai Chelaru | 6 Jan 18:26 2011
Picon

Re: Trimming TCP options

On 01/04/11 11:48, Mihai Chelaru wrote:
> I'll keep an eye on the last counter in the following days.

I need to reboot this one so I attached the latest stats and the
sys/netinet diff. I haven't seen anything strange during usage until now.

-- 
Mihai
tcp:
	46317610 packets sent
		36988340 data packets (27717538314 bytes)
		195387 data packets (159339998 bytes) retransmitted
		6355078 ack-only packets (7820889 delayed)
		0 URG only packets
		1396 window probe packets
		2420913 window update packets
		356502 control packets
		0 send attempts resulted in self-quench
	40556719 packets received
		27918469 acks (for 27628909944 bytes)
		0 duplicate acks
		229 acks for unsent data
		11497073 packets (10555150094 bytes) received in-sequence
		677061 completely duplicate packets (36428938 bytes)
		473 old duplicate packets
		33390 packets with some dup. data (22800833 bytes duped)
		673787 out-of-order packets (194682332 bytes)
		3 packets (1 byte) of data after window
(Continue reading)

Patrick Welche | 6 Jan 20:01 2011
Picon
Picon

Re: dhcp classless routes

On Thu, Jan 06, 2011 at 05:12:29PM +0000, Roy Marples wrote:
> Hi Patrick
> 
> On 06/01/2011 13:37, Patrick Welche wrote:
> >I can see how to write the equivalent of
> >
> >   route add -net w.x.y.z/m g.a.t.e
> >
> >in /etc/dhcpd.conf using the base system's dhcpd and dhcpcd a la
> >rfc3442. Am I right in thinking that there is no way of doing the
> >equivalent of
> >
> >   route add -net w.x.y.z/m g.a.t.e -iface
> 
> You can do this :)
> You need this in dhcpd.conf
> 
> option classless-static-routes code 121 = array of unsigned integer 8;
> 
> option classless-static-routes m,w,x,y,z,g,a,t,e ... ;
> 
> Like so, adding a default route
> option classless-static-routes 0,192,168,0,1;
> 
> Something more complex
> option classless-static-routes 0,10,73,1,1,24,10,73,0,10,73,1,1,24,10,73,2,
> 10,73,1,1,32,10,0,0,1,10,73,1,1;

Decoding:
route add default 10.73.1.1
(Continue reading)


Gmane