2009/1/28 [email protected] <[email protected]> > 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. > > Simon
Simon, thanks for your reply. So, now i know that lwip can manage a SYN flood attack, using half open state timeout. People who test my board with SYN flood attack generator, said that they waited for 15 minutes, but board didn't accept new connections. So, we need to know how this timeout are set, and if lwIP correctly handles the timeouts of the half-open PCBs and eventually closes them. Waiting Kieran or Jifl.... Thanks Piero > > > > Piero 74 wrote: > >> i tried nessus... >> >> i have 3 listener in my lwip application >> i configured: >> >> /** >> * MEMP_NUM_TCP_PCB: the number of simulatenously active TCP connections. >> * (requires the LWIP_TCP option) >> */ >> #define MEMP_NUM_TCP_PCB (3+0+1) // >> >> >> /** >> * MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections. >> * (requires the LWIP_TCP option) >> */ >> #define MEMP_NUM_TCP_PCB_LISTEN 3 >> >> >> after a scan with nessus, i cannot connect to my board. >> Sniffing with wireshark, i saw that lwip didn't answer to syn packet. >> Debugging the code, i checked: >> - no problem in driver, all pbufs are freed. Infact, the board answers if >> i ping it >> - seeing lwip_stats, i saw this: >> memp[TCP_PCB] >> - avail = 4 >> - used = 4 >> - max = 4 >> - err = 45 >> >> for each attempt to connect to board, err grows. >> >> what's the problem???? >> >> thanks >> Piero >> >> >> 2009/1/28 Piero 74 <[email protected] <mailto:[email protected]>> >> >> >> >> >> > Where? Is it a lwip bug? is it already solved in current >> cvs? (i'm >> > using last 1.3.0 release) >> >> >> Yes it was a bug in LwIP. See: >> http://savannah.nongnu.org/bugs/index.php?24596 >> >> i suppose i have to spent some time to align my code to current >> cvs... or waiting 1.3.1 release! >> >> >> >> > which tool i can use to simulate a flood attack and debug >> the driver >> > and the stack? >> >> A good starting point would be nessus, which already covers a >> huge load of vulnerability tests. >> Other name-droppings would include: >> - metasploit >> - isic, ipload >> - ettercap >> ... lots of others and basically everything from >> http://sectools.org/ :o) <http://sectools.org/> >> >> thanks... i have just downloaded nessus... and thanks for the site! >> >> >> >> > yes... i want to filer in the driver, not in lwip.. and i >> know... it >> > is not a definitive solution, but can mitigate the problem. >> >> Still a SYN-Flood will create a lot of load and starve >> resources. On an embedded device this can make the device >> unusable. Nothing mitigated there. >> >> i agree with you... but i have to try to do something... >> >> >> >> > yes.... i said the same thing to our marketing.... "put the >> device >> > behind a firewall!!".... but the answer was... security >> features >> > inside the device are good marketing arguments.... :O| >> >> Is it? Does marketing and customers care about security >> features or just about the Sticker that says "super-secure >> inside"? >> >> ... the second you said, of course! I think if a customer realy >> care about security, he will use a firewall!! >> >> Thanks, >> Piero >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> lwip-users mailing list >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/lwip-users >> > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
