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

great

[mike_scheck]

So now I don't just have to worry about losing my vpn into work in the middle of the night because of some unavoidable packet loss, but also because of some automagic utility that people will throw into place for my benefit. Will the "features" never stop?

Re:great

[nadadogg]

Well, you could prevent this by assigning a list of "safe" IP addresses that would not call for termination, but merely be logged. This way, unauthorized entry into the network would be stopped, and working from home would be brought to the higher-ups' attention, thereby making you look good :)

Just a thought, really.

Re:great

[ColdGrits]

Or we just employ proper secutiry procedures, rather than relying upon a script running twice a day to kill off connections (let's face it, the original suggestion, namely run this twice a day, is pointless - the intruder woudl already have been in, done whatever they were doing, and gone long before the script dropped their connection. Yes, you'd have a nice shiny log to say "J00 waz 0wn3d", but it's a bit late by that point...

The actual killing of connections, now, THAT is a useful tool where your intrusion detection has detected an active intrusion (or intrusion attempt). But that's not what was being discussed in this subthread :)

Well, that kills that.

[Divide By Zero]

So much for downloading the trailer for $NEXT_BIG_MOVIE on company bandwidth. We'll have to do work now. Dammit.

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:Would be handy

[Technician]

I think a fuse function should be included. Anything that saturates your uplink for 5 minutes should drop you off the net. This could be from anything such as a rogue robot, cracked or exploited mail server serving mass SPAM, a fast SQL type virus, or a break-in copying your fileserver. P-P serving lots of copyrighted material would also trip it. This could have a few anoyance false trips, but if fuses are widely used, it could greatly slow the kind of stuff we want off the net anyway. Maybe it could even save your webserver from melting when it's posted on /.

Evil bit comes to the rescue!

[RyanK]

Why not just turn on the 'evil' bit for these connections?

Then simply enable a filter to drop those packets during off hours or peak usage.

And people thought that was a joke!

nice first step

[Lumpy]

Give me a web interface showing all the connections and each end's ip address, how about a simple bargraph showing bandwidth use per connection also?

This would be the ultimate-awesome tool for a netadmin. couple this with cutter and you have a great way of managing that traffic!

Re:nice first step

[tensai]

Check out ntop. It watches traffic passively and generates quite a few pretty graphs. It has breakdowns by protocol, machine, time of day. All sorts of stuff. Extremely useful for troubleshooting the "my internet is broken" problems.

How to announce software on /.

[CoolQ]

How to announce software on /.:

1) Go to SourceForge.
2) Register a project; upload files
3) Post link to SourceForge page on /.
4) ???
5) Profit

How not to announce software on /.:

1) Upload software to your web server behind a T1
2) Post link to /.
4) ???
5) Cry over the money you just wasted.

--Quentin

Golden days at my company

[lateralus]

My old boss used to use bandwidth hogs as an excuse to cause users pain. We would track the inflated traffic down to hub port level, he would pull the plug and wait. After maybe 2 minutes always came the phone call from some frustrated user saying that his/her Internet was not working. Over the 12 times we did this EVERY time the phone call came from the abuser and not ONCE was he/she downloading anything work related.

The company has grown since then and those old tricks would get you fired nowadays. Ahhh, the days when IT ruled with an iron fist. Now there this newfangled notion of "service" in the department, how wierd is that?

tcpkill

[pknut]

The 'cutter' program introduced in the article sounds suspiciously similar to Dug Song's tcpkill program (a member of his dsniff network utilities). In fact, tcpkill appears to be superior because it matches packets via tcpdump expressions, and hence is more versatile.

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.

NO They weren't slashdotted...

[splerdu]

The script is obviously in place, and cuts unwanted connections originating from a referer-id of slashdot.org!

Re:fuckwit? I don't think so.

[tomhudson]

I tend to distrust session variables (especially those stored in /tmp, and, yes, I know you can designate another directory), so I authenticate users on each access. This has the following added benefits

1. Any changes in permissions are immediately reflected in the user app - not only after they log out
2. Single point of failure - the user validation code, not user validation && session management
3. Shutting down and restarting the server doesn't affect user access between clicks

Don't get me wrong - sessions are fine for those who like them. I'd just rather do things a bit differently. Besides, there's nothing to keep you from maintaining state with one or more of these techniques:

1. keeping state in variables in a database
2. keeping state in a file for that particular user
3. passing state in forms with POST or GET
4. passing state with urls
5. passing state with the carrier-pigeon protocol (for very high latency :-)

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.