Slashdot Mirror
TCP/IP Connection Cutting On Linux Firewalls
Chris Lowth writes "Network security administrators sometimes need to be able to abort TCP/IP connections routed over their firewalls on demand. This would allow them to terminate connections such as SSH tunnels or VPNs left in place by employees over night, abort hacker attacks when they are detected, stop high bandwidth consuming downloads - etc. There are many potential applications.
This article describes how a Linux IPTables based firewall/router can be used to send the right combination of TCP/IP packets to both ends of a connection to cause them to abort the conversation. It describes the steps required to perform this task, and introduces a new open-source utility called 'cutter' that automates the process."
This is a great idea that someone should have come up with a long time ago. I also like how the author took into consideration the security conserns of such a cutter.
Two Rules For Success:
1) Never tell people everything you know.
slashdotted with less than 5 comments posted. google cache.
After all, UDP tunnels are frequently better, since tcp-over-tcp can introduce odd timing effects. Run Google against "OpenVPN" for some pretty decent explanations of this and security issues. SSH tunnels are merely secure and easy, not necessarily the best.
The living have better things to do than to continue hating the dead.
As far as tools, I know of at least one that has been around since 97, "sniffit". It show connections in real time (like ethereal today) and has a hot key for resetting a connection.
No they are different. Let's start with an IPSec VPN.
IPSec VPNs are designed to be "networks" that encrypt the data that traverses them. This data is between two or more real networks, not just individual hosts. These VPNs are usually configured to completely conceal the contents including source/destination IP addresses of the networks traversing the VPN. These VPNs being actual "networks" also carry network traffic such as routing information and can even be rigged up enough to carry other protocols such as IPX.
SSH on the other hand is primarily intended to encrypt sessions between two hosts, rather than networks as is the case with IPSec. While it is possible to configure an SSH tunnel to forward multiple ports and there for multiple sessions between the hosts, it is far more difficult to configure SSH tunnels to carry whole network traffic and I am not aware of any way to carry protocols besides IP.
HTTPS is used to encrypt individual web sessions between two hosts. It is not able to due portforwarding or caryy other network traffic. The similarity between HTTPS and SSH is that they both use SSL/TLS as their means of encryption.
So, three different protocols for three different uses with very little overlap in functionality.
tcpkill will use network sniffing and packet insertion to kill any connections that are visible to the host computer. This usually means that connections to/from a computer on the same LAN segment as the host running tcpkill can be taken down. This is irrespective of whether the connection is being routed through the host computer. Running tcpkill on a gateway simply ensures complete visibility of the routed packets. In contrast, cutter does no network sniffing, and hence *must* be run on the gateway computer.
Though I haven't taken a careful look at the project, but this project exposes one major flaw of the Netfilter/Iptables firewalling code. Namely, it's impossible to flush the kernel connection tracking table without a reboot (or a complete unload of the Netfilter modules).
/usr/src/linux/net/ipv4/netfilter/ip_conntrack_pro to_tcp.c is 5 days!).
Connection tracking is a wonderful thing, and if you can flush out certain connections, this project wouldn't be necessary at at. Instead, there's no mechanism for aborting connections other than by injecting packets into a connection and getting both sides to abort.
This is probably a bad idea as well as RST packets don't have to be acknowledged (that's why they're RST, and not FIN). I might be completely wrong here, but this most likely leaves the connection in the tracking table alone to timeout on its own (which according to
And speaking of the timeouts, there are no sysctl adjustments possible. If you want to change the timeouts, you'd have to edit the kernel source and recompile. How's that for a giant pain?
Don't get me wrong, I like plenty of things about Netfilter/Iptables. But it's not "enterprise ready" yet.