Discussion:
boost::asio interaction with SYN Cookies
(too old to reply)
Nounou Dadoun
2015-11-30 18:05:41 UTC
Permalink
Hi asio folks,

Using boost::asio for basic network connectivity and I'm working on hardening the system to mitigate SYN flood DOS attacks. I've been looking at using SYN cookies which have been a very common approach for the last 20 years - they were first proposed and implemented in 1996. I'm sure most people here will know how they work but essentially they avoid committing resources for an incoming TCP connection until they get confirmation that the connection request is "real". (Briefly, they encode enough information in the SYN-ACK sequence number to reconstruct the connection information and don't fully process the connection until they get the ACK and use the sequence number to finish processing the connection. This allows a server to avoid committing any resources unless the incoming client is willing to send the SYN ACK which it often isn't in a SYN flood DOS attack.)

My question is: How does boost::asio figure in here? I'm assuming that enabling the use of SYN cookies is transparent to asio but if asio processes the connection on the SYN (allocating some resources) and doesn't wait til the ACK then it defeats the SYN flood mitigation effect of the SYN cookies. Anybody have enough knowledge of the low-level plumbing to know what the interaction is?

Alternately I'd like to know if there's any built-in or standard boost facility for mitigating SYN flood attacks; I could try to handle it at a higher level but it's such a common problem and best handled at the connection establishment layer that I figured that there must be a common approach - is there?

Thanks in advance for any consideration ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn


This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.




------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
Sam Liddicott
2015-12-01 09:46:49 UTC
Permalink
My understanding is that with SYN cookies enabled, the accept syscall does
not complete until the ACK returns, and select/epoll won't indicate that
the listen socket is ready for write (and accept() ) until the ACK returns,
for the reasons that you give.

accept() returns a new file descriptor. If this were allocated before the
returning ACK the the system would have allocated resources contrary to the
reasoning of SYN cookies.

With SYN cookies disabled, the accept might return sooner with a new file
descriptor.

What may confuse you, if you have been taking measurements, is that on some
systems syn cookies are automatically enabled only when the system decides
that it is necessary.

This is perhaps because if the accept returns earlier (on the first SYN)
then the server can do some preparation for the new connection concurrently
while the SYN+ACK, ACK are in transit, but that is only a guess. It would
though, allow for greater efficiency in the case where the mitigating
benefits of SYN cookies were not needed.

Sam
Post by Nounou Dadoun
Hi asio folks,
Using boost::asio for basic network connectivity and I'm working on
hardening the system to mitigate SYN flood DOS attacks. I've been looking
at using SYN cookies which have been a very common approach for the last 20
years - they were first proposed and implemented in 1996. I'm sure most
people here will know how they work but essentially they avoid committing
resources for an incoming TCP connection until they get confirmation that
the connection request is "real". (Briefly, they encode enough information
in the SYN-ACK sequence number to reconstruct the connection information
and don't fully process the connection until they get the ACK and use the
sequence number to finish processing the connection. This allows a server
to avoid committing any resources unless the incoming client is willing to
send the SYN ACK which it often isn't in a SYN flood DOS attack.)
My question is: How does boost::asio figure in here? I'm assuming that
enabling the use of SYN cookies is transparent to asio but if asio
processes the connection on the SYN (allocating some resources) and doesn't
wait til the ACK then it defeats the SYN flood mitigation effect of the SYN
cookies. Anybody have enough knowledge of the low-level plumbing to know
what the interaction is?
Alternately I'd like to know if there's any built-in or standard boost
facility for mitigating SYN flood attacks; I could try to handle it at a
higher level but it's such a common problem and best handled at the
connection establishment layer that I figured that there must be a common
approach - is there?
Thanks in advance for any consideration ... N
Nou Dadoun
Senior Firmware Developer, Security Specialist
Office: 604.629.5182 ext 2632
Support: 888.281.5182 | avigilon.com
Follow Twitter | Follow LinkedIn
This email, including any files attached hereto (the "email"), contains
privileged and confidential information and is only for the intended
addressee(s). If this email has been sent to you in error, such sending
does not constitute waiver of privilege and we request that you kindly
delete the email and notify the sender. Any unauthorized use or disclosure
of this email is prohibited. Avigilon and certain other trade names used
herein are the registered and/or unregistered trademarks of Avigilon
Corporation and/or its affiliates in Canada and other jurisdictions
worldwide.
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
Loading...