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

Comments

Google Cache of post, and a quick comment

[Cruel Angel]

here

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.

Re:tcpkill

[pknut]

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.

Injecting packets into the connection

[zaad]

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

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 /usr/src/linux/net/ipv4/netfilter/ip_conntrack_pro to_tcp.c is 5 days!).

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.