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.
Two words: "dsniff", "tcpkill". *yawn*
I just set inactivity timeouts for SSH and Telnet logins, the firewall guys set their's for VPN connections.
I just don't see the point.
Never answer an anonymous letter. - Yogi Berra
this is supposed to be for tearing down established connections, not just what to do with any unrequested packets that hit the firewall
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.
Looks like the site is kaput.
slash-dotted-server
> this is supposed to be for tearing down established connections, not just what to do with any unrequested packets that hit the firewall
Slight correction - this is for cleanly tearing down established connections - if you suddenly impose a -j drop rule on a connection, that connection *will* be torn down, just not as cleanly.
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.
Check out ntop for the per ip bandwidth utilization. Not exactly what you wanted, but it might do the job.
As for the bar on kernel.org, just click on it for the source. Dang kernel.org has been slower than balls for me lately.
You can manually do this with hping2.
If the IDS 'sees' traffic it doesn't like, it sends out a RST packet to the sender, addressed as if it came from the receiver, and vice versa. So, to both parties in the transmission it looks like the other party sent out the reset packet.
The one downfall to this was that the MAC address used in the RST packet was FF:FF:FF:FF:FF:FF. So, all one had to do is to modify their drivers to ignore RST packets when the senders MAC is FF:FF:FF:FF:FF:FF.
The current method is to now use a randomly created MAC address.
Also, if you have a VPN tunnel setup, and all packets between the endpoints are encrypted; The tunnel endpoints would reject the RST command because it is coming out-of-band. Most VPN tunnel endpoints ignore any traffic that is outside of the VPN tunnel. Therefore it serves no purpose to send an RST anyhow.
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.