Security implemented in LWIP

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Security implemented in LWIP

Raunak Rungta
Hi All,
I am doing a project to analyze the security requirements in connecting the set of wireless sensors with the Internet. I am totally new to this area. I read about different TCP/IP stack implementations like lwIP, uIP and others. Can any one point me some links where I can find how others implementors have approached this problem? How they have tried to secure their Wireless Sensor Networks from the different possible attacks from Internet? Any links to such implementations will also be helpful.

Thanks in advance,
Raunak Rungta

_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Mike Kleshov-2
That's an interesting subject. There are many different classes of
network attacks. Some of them are protocol-specific (recent DNS
vulnerability, TCP syn flood, ARP spoofing etc.), some target
vulnerabilities in particular implementations (e.g. resource
exhaustion), some are generic (flooding link with traffic.) You cannot
counter all of them. The best you can do is evaluate the risks and try
to bring them down to an acceptable level. That 'acceptable level' is
highly dependent on your application requirements.
I don't think that anyone performed a thorough evaluation of lwip in
terms of vulnerability to network attacks. There will definitely be
bugs. For example, a few months ago a bug has been found where a
malformed TCP header could cause a crash:
https://savannah.nongnu.org/bugs/index.php?24596
So, if possible, try to choose simple protocols, e.g. favour UDP over TCP.

Regards,
- mike

2009/1/28 Raunak Rungta <[hidden email]>:

> Hi All,
> I am doing a project to analyze the security requirements in connecting the
> set of wireless sensors with the Internet. I am totally new to this area. I
> read about different TCP/IP stack implementations like lwIP, uIP and others.
> Can any one point me some links where I can find how others implementors
> have approached this problem? How they have tried to secure their Wireless
> Sensor Networks from the different possible attacks from Internet? Any links
> to such implementations will also be helpful.
> Thanks in advance,
> Raunak Rungta


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Piero 74
Hi

I have similar problem with my ip board. My product is for intrusion market, so, our marketing, asked me if i can protect the board from crash caused by DOS attack.
Yesterday, during tests on my board, a guy tried a SYN flood attack, and after, my board needed a reset (i suppose lwip stack crashed... but i have to investigate)

In my opinion, a solution to reduce risk from DOS attacks, is PACKET FILTERING:
my idea is to give the user the possibility to define some rules for incoming packets, that will be applied in the emac driver context:
- a list of TRUSTED IP, only packets from this ip will be forward to lwip stack
- rules for packet filtering based on protocol (IGMP/UDP/TCP), ports, and IP

Raunak, Mike and other developers... we can discuss about this here.

Bye
Piero.

2009/1/28 Mike Kleshov <[hidden email]>
That's an interesting subject. There are many different classes of
network attacks. Some of them are protocol-specific (recent DNS
vulnerability, TCP syn flood, ARP spoofing etc.), some target
vulnerabilities in particular implementations (e.g. resource
exhaustion), some are generic (flooding link with traffic.) You cannot
counter all of them. The best you can do is evaluate the risks and try
to bring them down to an acceptable level. That 'acceptable level' is
highly dependent on your application requirements.
I don't think that anyone performed a thorough evaluation of lwip in
terms of vulnerability to network attacks. There will definitely be
bugs. For example, a few months ago a bug has been found where a
malformed TCP header could cause a crash:
https://savannah.nongnu.org/bugs/index.php?24596
So, if possible, try to choose simple protocols, e.g. favour UDP over TCP.

Regards,
- mike

2009/1/28 Raunak Rungta <[hidden email]>:
> Hi All,
> I am doing a project to analyze the security requirements in connecting the
> set of wireless sensors with the Internet. I am totally new to this area. I
> read about different TCP/IP stack implementations like lwIP, uIP and others.
> Can any one point me some links where I can find how others implementors
> have approached this problem? How they have tried to secure their Wireless
> Sensor Networks from the different possible attacks from Internet? Any links
> to such implementations will also be helpful.
> Thanks in advance,
> Raunak Rungta


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Kieran Mansley
On Wed, 2009-01-28 at 11:53 +0100, Piero 74 wrote:

> Hi
>
> I have similar problem with my ip board. My product is for intrusion
> market, so, our marketing, asked me if i can protect the board from
> crash caused by DOS attack.
> Yesterday, during tests on my board, a guy tried a SYN flood attack,
> and after, my board needed a reset (i suppose lwip stack crashed...
> but i have to investigate)
>
> In my opinion, a solution to reduce risk from DOS attacks, is PACKET
> FILTERING:
> my idea is to give the user the possibility to define some rules for
> incoming packets, that will be applied in the emac driver context:
> - a list of TRUSTED IP, only packets from this ip will be forward to
> lwip stack
> - rules for packet filtering based on protocol (IGMP/UDP/TCP), ports,
> and IP

In my view a crash is a bug, and by using packet filtering you might
treat the symptom but not the problem.  I would investigate where the
crash happened and fix that first.

However, lwIP is by design very conservative with its resource usage,
and by application likely to be on systems that are constrained in some
way.  Therefore it is always going to be possible, with a suitably well
crafted attack, to overwhelm such a system with traffic and exclude the
packets that should get through.  That said, the system should cope with
being overloaded, and return to functional operation when the extra load
is stopped - if it doesn't (as I said above) it's a bug that should be
fixed.  Packet filtering will just move the load of coping with such
packets to the driver rather than the network stack, and so may help a
little but it won't be a complete solution.

Kieran



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Fabian Koch-2
In reply to this post by Piero 74

Hey,

we performed pretty thorough Tests with the Stack (including the usual stuff like SYN-Floods) and found the TCP Options-bug.
I would give LwIP a pretty good grade there. The Stack itself is very robust.

The problematic part is always the driver implementation. And that is where LwIP could provide more help to developers (more documentation, tips, hints, best practices).
Because timing issues, flooding issues and all that stuff all arise in the driver. If your driver is not secure, the stack can't help crashing.

So debug your driver while under SYN flood and you'll probably find something overflowing.

Now on to the topic of filtering. Filtering packets in the MAC layer by whitelisting IPs is pretty much nonsense. It's basically the same simulation of security as MAC-ACLs in Wireless routers. An IP can easily be spoofed just like a MAC can. Building extensive packet filtering options and configuration options into LwIP will only increase complexity and code size. And if you want filtering on the lowest level it will be a driver issue anyways.

Network-security is a very complex topic and you can't try to make a single device ultra-secure and then never worry again. The whole network has to be taken into account. Also there are no statements about it that are correct under every circumstance (like using UDP because it's simpler).
You cannot judge the security of a device by the IP stack alone.

To close: you should probably never expose a device with such low resources that it uses a minimal Stack like LwIP _directly_ to the internet. This WILL starve your resources and DoS your device.
Packet-filtering should be done by appliances that are built for that. Firewalls, VPN-Tunnels, ...

regards,
Fabian
_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Piero 74
Hi


we performed pretty thorough Tests with the Stack (including the usual stuff like SYN-Floods) and found the TCP Options-bug.

Where? Is it a lwip bug? is it already solved in current cvs? (i'm using last 1.3.0 release)
 

I would give LwIP a pretty good grade there. The Stack itself is very robust.

good!
 

The problematic part is always the driver implementation. And that is where LwIP could provide more help to developers (more documentation, tips, hints, best practices).
Because timing issues, flooding issues and all that stuff all arise in the driver. If your driver is not secure, the stack can't help crashing.

So debug your driver while under SYN flood and you'll probably find something overflowing.

which tool i can use to simulate a flood attack and debug the driver and the stack?
 

Now on to the topic of filtering. Filtering packets in the MAC layer by whitelisting IPs is pretty much nonsense. It's basically the same simulation of security as MAC-ACLs in Wireless routers. An IP can easily be spoofed just like a MAC can. Building extensive packet filtering options and configuration options into LwIP will only increase complexity and code size. And if you want filtering on the lowest level it will be a driver issue anyways.

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.
 

Network-security is a very complex topic and you can't try to make a single device ultra-secure and then never worry again. The whole network has to be taken into account. Also there are no statements about it that are correct under every circumstance (like using UDP because it's simpler).
You cannot judge the security of a device by the IP stack alone.

To close: you should probably never expose a device with such low resources that it uses a minimal Stack like LwIP _directly_ to the internet. This WILL starve your resources and DoS your device.
Packet-filtering should be done by appliances that are built for that. Firewalls, VPN-Tunnels, ...

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|

Bye
Piero
 


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Fabian Koch-2

Hey,

lwip-users-bounces+fabian.koch=[hidden email] wrote on 28.01.2009 12:43:22:
> 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

> 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)

> 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.

> 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"?

regards,
Fabian
_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Piero 74



> 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)

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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Piero 74
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 <[hidden email]>



> 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)

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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

goldsimon@gmx.de
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


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 <[hidden email] <mailto:[hidden email]>>
>
>
>
>
>         > 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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Piero 74


2009/1/28 [hidden email] <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>





       > 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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Kieran Mansley
In reply to this post by goldsimon@gmx.de
On Wed, 2009-01-28 at 17:33 +0100, [hidden email] wrote:
> 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.

The above sounds correct to me.

A very quick calculation suggests the timeout is of the order of 10
minutes, but I've not checked my maths, and depends on what TCP_MAXRTX
has been set to.

I notice when looking at the code that we treat PCBs in the SYN_SENT
state differently to those in the SYN_RCVD state, and have a different
TCP_SYNMAXRTX value to limit the number of times a SYN is transmitted in
SYN_SENT.  SYN_RCVD is treated just like a fully open connection.  I'm
not sure this is right, but the only difference is how long the timeout
is, so it's probably not the source of the this problem.

The other reason why we'd not correctly time out a connection is if we'd
decided to do zero-window probes instead of retransmission.  This is
relatively recent code, so could be to blame, but a 5 minute audit
doesn't show up anything obviously wrong with it.  It should be easy to
rule out with a packet capture after the SYN attack has finished.  i.e.
Is lwIP retransmitting the SYN-ACKs, or is it sending zero-window
probes, or is it sending nothing?  I think that would be a useful thing
to try.

Kieran





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Jonathan Larmour
In reply to this post by goldsimon@gmx.de
[hidden email] 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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Rejean Groleau
In reply to this post by Piero 74
My solution on the application-side was to implement
the backlog-ability (TCP_LISTEN_BACKLOG) of LwIP,
with a few additional macros based on tcp_accepted().

It solved my own issues with outgoing connections
failing to work (when out of PCBs). So now my application
is able to "tell me" that something odd is going on,
even when flooded with numerous connections.

I haven't done "SYN flood" attacks though, only
"normal connections" flood attempts.

As soon as I have time for this, I'll check with nmap
and see how it crashes (and how much time it takes
to come back on, if it ever does).

- Reggie.

Piero 74 wrote
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.
Reply | Threaded
Open this post in threaded view
|

Re: Security implemented in LWIP

Piero 74
In reply to this post by Jonathan Larmour
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 <[hidden email]>:

> [hidden email] 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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users