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

Would be handy

[tomhudson]

This would be a handy thing to put in a script to run once a day, after everyone's gone home, then again before anyone gets in in the morning. Examining the logs for odd activity between the two instances would be VERY handy.

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

Re:Would be handy

[56ker]

What variables would you want to be able to alter on the fuse? Bandwidth usage is highly variable anyway (even with normal patterns of usage). How can you tell the difference between an employee downloading a large pdf file and an employee uploading a copy of your fileserver? There's also a fine line between security & convenience - and with logs you get the "little elves" problem too. It depends how bothered you are about IT security I suppose. I've seen plenty of corporate broadband connections without even firewalls - and managment is still IMHO pretty clueless about computers. At least they've moved on from regarding them as an unecessary luxury expense.

Re:Would be handy

[Surak]

Wouldn't work where I work. We regularly post files that are several hundred megabytes in size on our FTP server for download or upload them to other servers. You would have to somehow determine *what* wa saturating that uplink for more than 5 minutes and make sure it wasn't a legit connection. That might be a bit more complicated than it sounds, too.

Re:Would be handy

[SpaceJunkie]

IF they are that regular, they are surely tied into scripts. In which case, the scripts could forewarn the fuse script that they will be communicating the big file, so it can suspend its monitoring of that specific connection, while still monitoring other nodes on the netwokr that are not realted to that activity.

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.

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.

Re:Does this work for DOS?

[Anonymous Coward]

No. TCP sequence numbers prevent DOS in the same way that they prevent arbitrary data injection via IP spoofing. It's very tricky to guess both IPs, both ports, and the correct sequence numbers on both sides.

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

[Abcd1234]

Hmm, I can't tell from the manual page: will tcpkill shutdown TCP sessions which are being routed through (as opposed to originated)?

Easy to hack around!

[Line_Fault]

I'm sure I could get around this by packet capturing on both ends of the connection and dropping any packets that would abort my connection before they are processed by the OS or application.

If I getting disconnected was really bugging me, I'm sure changing a few lines of the TCP stack code, and a quick (rather lengthy) recompile would yeild two inevitable outcomes:

1. Less frustration from disconnects!
2. The same (or larger) security hole than before!

Fantastic!!!

I liked this util better the first time...

[Anonymous Coward]

When Route wrote it, and it was called "Juggernaut."

http://www.phrack.org/show.php?p=50&a=6

-Ben

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

Re:SSH tunnels or VPNs - isn't that the same?

[Tony Hoyle]

They have different purposes... With SHTTP the client isn't (usually) authenticated, just the server, so the traffic server->client is trusted, but not necessarily client->server (other than being encrypted).

IPSEC also verifies the endpoints and uses preshared keys, so it's secure enough for joining two LANs. PPTP/MPPE is good enough for picking up your email and stuff, but because there's no endpoint authentication it's not considered really secure.

SSH itself isn't a VPN but you can create one by running (for example) PPP across it.

Generic Tools?

[commonchaos]

One tool I have not been able to find, but would really like, would be a sort of packet creation/packet sniffer hybrid where you could inject arbitrary packets into a TCP/IP stream. Does anything like this exist?