Re: [lwip-users] Security implemented in LWIP

[pweb . ing]

hi all

tomorrow i will do other test using debugger. i have some doubts:

1. i have 3 listener in my code. lwip will use a  TCP PCB for each
listener? if yes,  i need 6  TCP PCBs pbufs in lwipopts for managing 3
simultaneous connections. right?
2. i'm not sure, i have to check again, but it seems that lwip doesn't
free  TCP PCBs pbufs after open/close tcp operation with a pc app (i'm
using 130)
3. i tested lwip with another scan tool, which performs a massive syn
attack, producing half open connections, and after i cannot connect to
listeners. i didn't wait for 10-20 minutes, to see if lwip exit from
stuck.... tomorrow i will try a complete test. could be usefull a
wireshark log during syn attack and after, during stuck?

bye
piero

2009/1/28, Jonathan Larmour <address@hidden>:
> 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
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>