1 / 42

LCCN TCP SYN attack protection

LCCN TCP SYN attack protection. Submitting: Lena Lempert Ola Shor Eugenia Nimratz Instructor: Reuven Cohen Supervisor: Itai Dabran. Agenda. Introduction Basic concepts Project goals

badrani
Download Presentation

LCCN TCP SYN attack protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LCCN TCP SYN attack protection Submitting: Lena Lempert Ola Shor Eugenia Nimratz Instructor: Reuven Cohen Supervisor: Itai Dabran

  2. Agenda • Introduction • Basic concepts • Project goals • Description of Implementation (general layout, description of operation, main data structures, modules, algorithms) • 1st solution • 2nd solution • Performance Analysis • General notes • Comparison of 2 implementations in normal conditions • Comparison in case of SYN attack • Simulation Results • Conclusions • Acknowledgements

  3. IntroductionBasic Concepts • When TCP was designed, some of the attacks known today were not taken into consideration: • Big timeouts • Small buffers • Lack of security rules • In TCP SYN attack, big quantity of SYN packets requesting to open connection, fill up a buffer of pending connections, thus bringing down the server. • Naive approach: throw SYN requests with same IP. BUT: packets arrive with random IP addresses and port numbers. How to distinguish?

  4. Introduction (cont.) Basic Concepts • Another approach: change the implementation of TCP, so that to handle the attack (for ex. change buffer size dynamically depending on SYN arrival rate; limit number of accepted SYNs per sec). BUT: • Complicated! • Change TCP for every attack? • Our solution: let Firewall operate between the client and the server, protecting the server from crashes.

  5. Introduction (cont.) Project Goals • Implementation of 2 differently designed Firewalls: • 1st solution – server is located in a separate network. All its communication is forwarded by Firewall, which traces and sifts SYN attacks. • 2nd solution – Firewall and server are located in some local network. Firewall cannot prevent arriving of packets to server, but operates as a watchdog. When conclusion is made about SYN attack, it simulates the client in order to defend the server.

  6. Introduction (cont.) Project Goals • Comparison of Firewalls • In normal conditions • Under SYN attack In normal conditions, number of clients connecting to the server per second was the only parameter for comparison. Under SYN attack, both rate of SYN attacks and rate of regular clients were taken into consideration. • SO… Which one is better?!!!

  7. Description of Implementation1st solution • General Layout:

  8. client firewall internal server SYN SYN + ACK ACK SYN SYN + ACK ACK data data Description of operation, 1st solution (normal connection)

  9. client firewall internal server SYN SYN + ACK RST Description of Operation, 1st solution (SYN attack) timeout

  10. Description of Implementation2nd solution • General Layout:

  11. SYN SYN + ACK ACK ACK data Description of operation, 2nd solution (normal connection) client firewall internal server

  12. SYN SYN + ACK ACK RST FIN Description of operation, 2nd solution (SYN attack) client firewall internal server timeout

  13. Description of Implementation (cont.)1st and 2nd solutions • The communication is accomplished via RAW sockets. • 2 kinds of data structures: • FIFO queues of Packets • Tables of entries defined by connection parameters • 3 modules: • Receive & Send module, responsible for communication accomplishment • Process module, the main logic of the firewall • Timeout module, responsible for performing actions in case some time has expired for some condition.

  14. Modules interaction (1st and 2nd solutions) Process Module Receive & Send Module Timeout Module

  15. Modules interaction in detail, 1st solution Send Thread Receive Thread Send Buffer Process Buffer Process Thread SynAckWait Buffer ListsWait Buffer Opened Connections Buffer Pending Buffer Timeout Client Thread Timeout server Thread Close Connections Thread

  16. Algorithms of Receive & Send Module (1st and 2nd solutions) Receive Thread Send Thread no TCP packet? discard RST packet? yes yes no Add Ethernet trailer From/to server? no yes Send Insert to Process buffer and inform Process thread

  17. yes no (from server) yes • Insert to Pending Buffer • Send SYN+ACK to client Packet to server? Shown in other diagram ACK? Packet is for… • Insert to ListsWait Buffer discard • Delete entry from Pending Buffer • Send SYN to server • Insert data to SYN_ACK_WAIT buffer • Adapt packet • Send to server Algorithms of Process Module (packet to server) 1st solution SYN? no yes no Ack is for … Ack for 3-way handshake Ack for half opened connection (not yet opened with server) Packet for open connections else else Ack for open connection Packet for half opened connection (not yet opened with server)

  18. yes no (from server) Packet from server? Shown in other diagram Algorithms of Process Module (packet from server) 1st solution no Packet is for opened connections? SYN + ACK? no yes yes • Adapt packet • Send to client Data is in SynAckWaitBuffer? no yes discard • Delete entry from SynAckWaitBuffer • Send Ack to Server • Insert data to OpenedConnectionsBuffer • Send all packets waiting in ListsWaitBuffer

  19. Check all entries in SynAckWait Buffer Check all entries in Opened Connections Buffer Check all entries in Pending Buffer Found entry with timer expired Syn attack!!! • Delete from Pending Buffer • Send RST to client Delete entry Algorithms of Timeout Module 1st solution Timeout Client Thread Timeout Server Thread Close Connections Thread Found entry with timer expired Found entry with timer expired yes yes yes Send another SYN to server

  20. Modules interaction in detail, 2nd solution Send Thread Receive Thread Send Buffer Process Buffer Process Thread Pending Buffer Timeout Thread

  21. discard Delete from Pending Algorithms of Process Module (packet from server) 2nd solution yes no From Server? Packet is… Packet is… SYN from client FIN+ACK from server else else • Send ACK to server • Delete from PendingBuffer Insert to PendingBuffer ACK from client SYN+ACK from server • Start timer • Send ACK to server

  22. Check all entries in Pending Buffer Syn attack!!! Algorithms of Timeout Module 2nd solution Found entry with timer expired yes • Delete from Pending Buffer • Send RST to client • Send FIN to Server

  23. Performance analysisGeneral Notes, description of simulation tools • The conditions available in the lab although gave us results sufficient for comparison of 2 solutions, were still limited and didn’t allow testing on numbers close to reality. For purpose of simulation, we built a server that accepts single connection, sends a small amount of data and after closing this connection accepts another one (not multithreaded server). Clients too, connect one after another (a certain number per sec). That’s why without attacks or firewalls these conditions let us serve no more than ~2000 such client per sec. So, bigger numbers were not tested with attacks (irrelevant results).

  24. Performance analysisGeneral Notes, Explanation of threshold • With such simulation, a moment when number of regular clients don’t manage to connect to server under attack when they managed without attack was considered as a threshold when firewall/server would crash in reality. In our results, it didn’t happen since clients connect in a loop and they simply start to connect slower. In reality, rate of clients wouldn’t slow down and their requests would bring down the resources in Firewall/server

  25. Performance analysis (cont.)General Notes, limit of the 1st solution • Due to reasons described later in this section, even without attacks firewall of the 1st solutions can handle less clients than that in the 2nd solution. See Chart 1 in Simulations Results. That’s why no more than this number of clients (max ~500 clients per sec) was tested for condition when attack was present.

  26. Performance analysis (cont.)General Notes, Why stop testing after threshold • We stopped increasing parameters (clients or attacks) if it took server more time to handle a connection then it took it in normal conditions. The reason is that no matter with what speed, but such situation will bring down Firewall, server or clients (depends on solution), since at this moment arrival rate is higher than service rate at some node. In the 1st solution, Firewall’ll refuse to function and clients’ll exit with connection timeout. In the 2nd solution, server’ll be brought down (cannot serve so many clients) and clients’ll exit with the same connection timeout error. The biggest “working” parameter was considered as limit, although it could be not very exact.

  27. Performance analysisComparison of 2 solutions in normal conditions 1st solution: • In the 1st solution, Firewall performs forwarding of all the packets passing to/from the server. • Each connection is settled by simulation of both sides to each other (simulating server for client and client for server). • Then data about the opened connection is inserted to the table and all the following packets will be forwarded after making changes on fields according to the saved data in the table.

  28. Performance analysis (cont.) • In the conditions of the lab, CPU capability of Firewall could not manage to settle connection with the server before retransmitted packets of the client arrived. (Speed of network was higher). • As result, even when single (regular) client tried to connect, a certain quantity of redundant retransmitted packets was present. • When number of clients grew, connection with the server was opened even with bigger delay -> more retransmitted packets, wasted time on their forwarding.

  29. Performance analysis (cont.) • The result is that under normal conditions firewall can serve only limited number of clients, which is much smaller than number of clients without any forwarding. 2nd solution: • Here, Firewall doesn’t interfere with communication except sending a duplicated acknowledgement for each SYN it “notices”. This doesn’t disturb the server and network works as if there was no firewall at all.

  30. Performance analysis (cont.) Conclusion: the 1st solution works worse in normal conditions, than the 2nd one. (see Simulation Results) 2nd solution 1stsolution

  31. Performance analysis (cont.) Comparison of 2 solutions under SYN attack 1st solution: • Under SYN attack, Firewall in the 1st solution sifts attacking SYNs, thus protecting the server. • Therefore, a bottleneck in this solution is Firewall. • We tested different rates of attacks for several numbers of regular clients. With exactly the same parameters, 2nd solutions works worse. • The bigger rate of clients was, the faster we arrived at the threshold. For numbers, see Simulation Section.

  32. Performance analysis (cont.) Comparison of 2 solutions under SYN attack 2nd solution: • Our firewall was designed to protect the server from TCP SYN attack. That’s why we made reasonable timeout (several sec) to decide that the SYN packet was false. Then we close the connection with the server. • We DO protect from the SYN attack, since server doesn’t crash because of pending connections. • BUT! We don’t protect server from excessive connections.

  33. Performance analysis (cont.)Comparison of 2 solutions under SYN attack • It appears that 2nd solution works worse in presence of even relatively low rate of attacks, because many connections are still not closed (firewall waits for timeout) and many new connections arrive (from regular clients and attacks). • The design of this solution doesn’t allow us prevent opening false connections, and they “bomb” the server. • We cannot decrease timeout, since don’t want to interfere with normal clients that really require such timeout (packet loss etc.).

  34. Performance analysis (cont.) Conclusion: the 2nd solution performs worse under SYN attack, than the 1st one. (See Simulations Results) 1st solution 2ndsolution

  35. Simulation Results Chart 1 Without attacks, client service time in the 1st solution is longer than that of the 2nd. It means that 1st solution can handle less clients/sec than the 2nd solution.

  36. Chart 2 With attacks, client service time in the 2nd solution is longer than that of the 1st. It means that 2nd solution can handle less clients/sec than the 1st solution.

  37. Chart 3 With attacks, client service time in the 2nd solution is longer than that of the 1st. It means that 2nd solution can handle less clients/sec than the 1st solution.

  38. Conclusions • In this project we have implemented and compared 2 differently designed Firewalls • As result, in normal conditions the 1st firewall is inferior than the 2nd one, while under SYN attack, the 1st solution performs better than the 2nd one. • The implementation of the 2nd solution was much easier than that of the 1st one. • A definite result can not be made as to which firewall is better under SYN attack, since in the conditions of the lab we had no opportunity to test other interesting situations (for ex, higher rate of SYN attack).

  39. Conclusions • A notice should be made, that the problem with the 2nd solution was not actually SYN attack, but excessive rate of TCP connections, since the rate of incoming SYNs was much bigger than rate of regular clients. • In reality, to make a DoS is much more difficult than SYN attack, since a real server handles enormous amount of clients. We don’t know how exactly SYN attack looks, but we do know that a smaller number of SYN is required to fill up the buffer, than make DoS. That’s why the 2nd solution MUST be checked in real conditions to make conclusions. (Impossible in the lab)

  40. Conclusions • As to the 1st solution, it is useful for other reasons. Since it is “proxy”, it can: • sift or do something with other kinds of packets • do forwarding to another server. • Run NAT • On question “What rate of attacks can handle each firewall?” we can answer: • Depends on rate of regular clients “N” • In 1st solution – ~O(N) • In 2nd solution – ~O(N^2)

  41. Conclusions (cont.) • The following enhancements could be done: • In the 1st solution, a mechanism could be added to manage recognition of the retransmitted packets. • In the 1st solution, maximum improvements should be done to make code work faster (notice, that such thing will bring no result to the 2nd solution) • Dynamically refuse some percent of connections under high pressure of connections – avoid crashes!!! • At least during our testing, we did not arrive at any possible enhancements to the 2nd solution.

  42. Acknowledgements We would like to thank Reuven Cohen and Itai Dabran for their guidance during our project and Stas, without whom the project would hardly be accomplished, for his help in solving technical problems and their explanation.

More Related