[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Security implemented in LWIP
From: |
Jonathan Larmour |
Subject: |
Re: [lwip-users] Security implemented in LWIP |
Date: |
Wed, 28 Jan 2009 17:23:05 +0000 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070530) |
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
- Re: [lwip-users] Security implemented in LWIP, (continued)
- Re: [lwip-users] Security implemented in LWIP, Kieran Mansley, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, fabian . koch, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, Piero 74, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, fabian . koch, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, Piero 74, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, Piero 74, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, address@hidden, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, Piero 74, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, Rejean Groleau, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP, Kieran Mansley, 2009/01/28
- Re: [lwip-users] Security implemented in LWIP,
Jonathan Larmour <=
- Re: [lwip-users] Security implemented in LWIP, pweb . ing, 2009/01/28