Re: [lwip-users] Security implemented in LWIP

[Jonathan Larmour]

address@hidden wrote:
> The memp err simply says all TCP PCBs are in use. The expected behaviour
> would be that every SYN leads to allocating a PCB and a SYN+ACK is sent
> back. However, with a SYN flood attack, the originator does not respond
> to that SYN+ACK (as it normally would, with an ACK). Instead, the PCBs
> are left in a half open state and lwIP should retransmit the SYN+ACK
> until a timeout occurs (don't know how long that is). Until that timeout
> has occurred, lwIP will not process any new connection (due to lack of
> resources, i.e. PCBs).
> 
> As far as I know, this is exactly what is supposed to happen under a SYN
> flood attack. The interesting point is whether lwIP correctly handles
> the timeouts of the half-open PCBs and eventually closes them. If so,
> the device should behave normally again. But as I said, unfortunately I
> have no idea of the time span here... I guess Kieran or Jifl could help
> out with that value.

include/lwip/tcp.h has this hard-coded:
#define TCP_SYN_RCVD_TIMEOUT 20000 /* milliseconds */

This is processed in the TCP slow timer.

Hmm, I also see there's code in tcp.c:tcp_kill_prio() to try and kill the
oldest connection (in any state) after an inactivity timeout[1]. One could
suggest this is a bad response to a SYN flood. Although in normal operation
it's a good way to purge inactive connections. Perhaps there should be an
inactivity floor which needs to be exceeded. There is a way to set PCBs to
a higher priority than normal, and so not be killed off, but that's only
really available to raw API users. And it does not discriminate between
which active connections - perhaps pcbs with state SYN_SENT/SYN_RCVD should
be killed off first, before ESTABLISHED (I'm not sure about the other
closing states before ESTABLISHED, except for TIME_WAIT which is already
handled).

I think something could be improved here anyway. Perhaps a task should be
submitted on savannah if no-one wants to look at it immediately.

Jifl
[1] The comment in it does not seem to match the code - it says it kills
the oldest active connection lower than the supplied prio, but it's
actually less than *or equal to* prio.

-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine