Products > Networking & Wireless
[solved] networking, a simple fake FIN package causes a lot of troubles
legacy:
we are managing a CCC-like event, and during one of the recent preliminary meeting, we experimented an attack that shut down the whole local area network. The attacker is anonymous but we found his source code, so he operated inside our LAN. He used a long piece of code which creates fake FINs packages and open a TCP/IP ports. We are still studying the source, and it's not 100% clear. When it tries to open a port, then it invokes these two lines
--- Code: --- shutdown(sock, SHUT_RDWR);
close(sock);
--- End code ---
Shutdown() is a socket's primitive offered by the standard UNIX networking engine, and it sends a FIN package. Combined it seems that the approach is causing problems on our local network because computers do no more responsible within 50 minutes.
edit:
I was focused on the wrong piece of code. The attack can be classified as "SYN flooding", so this topic is now cleared from useless links, and the title is edited with [solved]
edit2:
Things can also be summarized this way
--- Quote ---TCP/IP 3-way handshake is done to establish a connection between a client and a server.
The process is :
Client --SYN Packet--> Server
Server --SYN/ACK Packet --> Client
Client --ACK Packet --> Server
The above 3 steps are followed to establish a connection between source and destination.
SYN Flood DOS attacks involve sending too many SYN packets with a bad or random source IP to the destination server. These SYN requests get queued up on the server's buffer and use up the resources and memory of the server. This can lead to a crash or hang of the server machine. After sending the SYN packet it is a half-open connection and it takes up resources on the server machine. So if an attacker sends syn packets faster than memory is being freed up on the server then it would be an overflow situation. Since the server's resources are used the response to legitimate users is slowed down resulting in Denial Of Service.
Most servers nowadays use firewalls which can handle such syn flood attacks and moreover even servers are now more immune.
For more information on TCP Syn DOS attack read up rfc-4987, titled "TCP SYN Flooding Attacks and Common Mitigations".
--- End quote ---
madires:
--- Quote from: legacy on March 05, 2019, 03:18:22 pm ---as bench test, we are bombarding a subnet with a portscanner that
- tries to see if a port is open
- tries to shutdown the port by issuing a poison signal
--- End quote ---
You can't close ports remotely. It seems that you're DOSing yourself.
xani:
It would be much easier to guess what exactly the problem is if you made a tcpdump of the traffic (wireshark is AMAZING tool to analyze dumps made by it). Trying to look at C calls and effects via port scanner is like using multimeter instead of oscilloscope. Even better if you posted the dump so we can see it (if it's nothing secret)
As for Linux side, look into:
* dmesg command or kernel log - linux kernel will generally yell there when you hit any limit
* ss --all will show all open and listening sockets in system, ss -t will do same for only TCP connections. If you see few thousand connections there you might just created a lot of unclosed connections. lsof -i if your machine doesnt have ss command
* TCP by default have LONG timeouts, and by that I mean HOURS so if daemon listening on port didn't change anything idle connection can sit unused for a long time
* normally you can't have more than 30k to ~64k connections to a given port between same pair of IPs, you just run out of source ports. A lot of connections that are not closed properly can cause that.
bson:
--- Quote from: legacy on March 05, 2019, 03:41:38 pm ---Anyway, I still have to understand why servers stop to respond after a while they are bombarded with a FIN packet :-//
--- End quote ---
The way it's supposed to work is:
Client sends data to the server
Server responds with data to the client
Server, when done shuts down its write side
The client reads remaining data and when its read side is fully drained it gets an EOF (because the server sent a FIN on shutdown)
The client shuts down its write side and closes the socket
The server gets an EOF when the client has shut down its write side, and this confirms the client has seen everything sent
The server closes the socket
When a TCP connection is closed its goes into a TIME_WAIT state. This is to prevent the same address,port pairs to be used again since they uniquely identify a connection. If they're used too soon there is a risk of confusing TCP segments in the current connection with segments from a past connection that may have sat delayed in router queue, or got misrouted and took a while to find their way to their destination. The TIME_WAIT state is configurable, and by default fairly long (forget off hand, several minutes). When a connection is closed in an orderly fashion (using the shutdown semantics above), the TIME_WAIT period is dramatically shortened (to a few seconds). If it's shutdown due to an error, the full period applies as one of the endpoints may still be trying to use it. When you shutdown the read side, if there is any data in the socket buffer a TCP RST is issued - this signals an erroneous disconnect. The reason is so the other part can detect that you didn't see some of the data sent. The full TIME_WAIT applies. When you have two hosts, or localhost, the addresses are static, plus the server port number is static, and the address, port pairs of the endpoints uniquely identify a connection, you soon have the full 65536-1024 possible anonymous ports stuck in TIME_WAIT on either the client or server or both. No more ports are available and no more connections can be made.
The classic textbook is TCP/IP Illustrated by Richard Stevens. Vol 1, Chapter 18. http://www.pcvr.nl/tcpip/ (http://www.pcvr.nl/tcpip/tcp_conn.htm#18_0)
There are tons of tweaks, options and adjustments to TCP since then, but this describes very much how it still works...
westfw:
This was my guess as well.
--- Quote ---by default fairly long (forget off hand, several minutes).
--- End quote ---
255 (max IP TTL) seconds...
--- Quote --- shutdown(sock, SHUT_RDWR);
close(sock);
--- End quote ---
So scan, open, shutdown, close? Or just make a fake FIN?
Navigation
[0] Message Index
[#] Next page
Go to full version