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 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.
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?
So much for downloading the trailer for $NEXT_BIG_MOVIE on company bandwidth. We'll have to do work now. Dammit.
Dare to Hope. Prepare to be Disappointed.
The old icmp "attack" I used to run it on people on irc all the time to annoy them. I believe the version I used was called click.exe. just paste their address in one space, the server address in the other, and send some icmp packets to a few ports and they got connection reset by peer.
I also like ice cream.
Just pull the network cable out, then lets see the hacker getting past THAT script!
fart/faart/(coarse) (v.intr.): emit intestinal gas from the anus. (n.): emission of intestinal gas from the anus.
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.
Wow, now aol users can close aol without using ctrl+alt+delete.
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!
Then you could just ignore your outages after hours since you couldn't ssh in anymore.
I always wanted to work 9 to 5 like the executives
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.
So does this method allow DOSsing connections, with forged IP addresses?
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!
Do not look at laser with remaining good eye.
Anyone got the tarball of this? The google cache is all well and good, but how am I supposed to try it on my friends^W rogue users?
--QUentin
Without a competent sysadmin and specific application (triggered only for certain events/time lengths), this will go from handy to crude (much like many other tools, come to think of it).
Two words: "dsniff", "tcpkill". *yawn*
If only this "utility" could be integrated in some nice GUI package or application...
It would make "security" that much more fun!
Tm
Support TBI Research: http://www.raisinhope.org
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
"By definition, if it's a 24/7 operation, you wouldn't be terminating tcpip connections at all..."
Well done!
You understood the point of my post. Congratulations. Now you understand why it was moderated the way it was...
People should not be afraid of their governments - Governments should be afraid of their people.
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
Well... perhaps somebody can enlighten me on this but I was thought that SSH tunnels, and even https are nothing but VPN's. I know VPNs can initiate trough IPSec (among other things) but in principle there is no difference between VPN, SSH, and SHTTP... or am I wrong?
Oh, come on, you can have your web server and ftp server up 24/7, and terminating connections twice every day isn't going to have much effect on legit users, unless you're hosting isos, in which case they'll just have to restart their ftp client and resume from where they left off.
the web server can be shut down and restarted every hour with no effect on users - http is, after all, a connectionless protocol, and on todays machines, it only takes 3 to 4 seconds to shut down and restart apache.
Also, with the newer high-latency DDOoS attacks, this would be a good way to stop them :-)
Just because you don't see the utility of something like this right off doesn't mean there is no use, or that it can't be adapted to certain situations.
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?
If you outlaw the law, only criminals will have laws
I would have gotten first post, but my firewall terminated my connection to /. :(
I don't see how this is really that much different than running a script that intermittently drops access to certain ports.
Why do you need to ask either side of a tcp connection to abort? Shouldn't the fact that the connection is lost be enough?
If you're trying to stop large downloads run a usage tracking app to a database and temporarily block the IP. Geez.
I, like many people here, develop software. But I have to say, in this case, is this really needed? It just seems like it would be just another thing to test, configure, manage and keep up to date.
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.
See, his webserver can not accept any connections, and I bet he's not using cutter at the moment
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.
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!!!
Don't mix VPNs in. The thread is about nuking TCP connections and unless you mean SSH or PPP by VPN, the issue is irrelevant. Moreover, even with TCP-based VPNs it is easy to write a proggy that will add IP/port pair of authenticated VPN peers into the list of 'dont drop' connections.
3.243F6A8885A308D313
I've never tried shutting down Apache during a session, but it seems to me that any web applications that require authentication or maintain application variables could be severly impacted by restarting Apache.
I suppose it depends on application.
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
When Route wrote it, and it was called "Juggernaut."
http://www.phrack.org/show.php?p=50&a=6
-Ben
Cat got your tongue? (something important seems to be missing from your comment ... like the body or the subject!)
Soon we'll have to add "cutting" to the hacker's dictionary. And, sorry to say, the cracker's dictionary.
Instead of running the script once after everyone left, why not combine it with some kind of intrusion detector so that it only runs when there's suspicious activity. This would prevent accidently kicking people off and would actually stop attacks completely. You can't crack something that isn't connected after all.
read my blog
musings on politics and technol
The script is obviously in place, and cuts unwanted connections originating from a referer-id of slashdot.org!
- Any changes in permissions are immediately reflected in the user app - not only after they log out
- Single point of failure - the user validation code, not user validation && session management
- 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:It seems to me the connection just drops every five minutes, perhaps they have this on their crontab ;)
Looks like the site is kaput.
slash-dotted-server
You wouldn't happen to be using Cogeco would you? :)
...dare pulling that cable! My coffe machine is on the other and!
...the site is not "kaput", thatÂs just the damn script running :P
C-title
If a high school kid can be expelled for writing a newspaper article how long will it take?
Hey! You can't do that! I'll cleanly exit your session and use the honor system to ensure you don't start it again! Take that, you icky poopoo-head hacker-guy! I sure wish I had a "Linux IPTables based firewall/router" so I could keep you from... - oh wait... never mind.
*sigh*
PR
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?
or Time Warner ...
Nice try, but my dsl/vpn is thru Earthlink/Covad dhcp, so let's just make all of earthlink's ip address range's "safe".
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.
This article calls to mind
a catchy Echo and the Bunnymen> song from those ca-razy 1980s....
anyone still reading this? Perhaps someone can answer what is the functional difference between a hardware rounter like the fancy dancy linksys 4 port router/switch/firewall and a linux firewall? My friends and I are split, some think there is a difference, some of us don't and neither side has any reason to beieve one way or the other.
because I have been enjoined by this Holy Office to abandon the false opinion which maintains that the Sun is the centre
n/c
After a short while, the script kiddies will have new types of VPN software which periodically drop an d re-establish a connection.
Or they'll just tunnel over http or whatever. Sure, it will be slower and more laggy, but they won't care, because they're 133T.
Much better to invest your time in regular network monitoring and IDS. If you know what your systems are supposed to be doing, you'll know when they're doing something else.
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.
Ntop, jnettop, iptstate, iptraf... I'm sure there's many more, although most work on the CL. However there are no pretty pictures and whatnot you can see in your browser.
Anti-social? My code is just platform-specific.
It depends on how you look at it. A linux firewall is essentially the same as say, a Cisco router, except with Linux you have a full-fledged PC with a full OS, Cisco, Linksys, and the others use small hardware with a shrinked-down OS to route.
In fact, I believe Linksys routers use Linux (and presumably iptables, but who knows...). So, in effect, there is no difference. I use an old IBM Aptiva as my home router, it just costs me some more space.
Hypocrisy is the 8th deadly sin.
The easy part of this problem is cutting off the TCP connection. It is a simple matter of sending FIN and/or FIN-ACK TCP packets to the endpoints of the connections.
The hard part of this problem is in deciding which TCP connections to cut off. I don't think that randomly cutting off connections once a night or aborting long downloads is a good idea. This may inconvenience some legitimate users, and there are probably much better criterion that one could use to determine if a connection is "malicious." For instance, if overlapping IP fragments are detected, this may be an indication that someone is trying (a naive approach) to subvert your intrusion detection system, since fragmented packets are rarely used in the internet today.
More research may need to be done in determining good application-level criterion that indicates a malicious connection, and in how to map these application-level criteria to firewall rules.
Sincerely,
Neil Daswani
http://www.learnsecurity.com/
There's an even better solution that is guaranteed to terminate a TCP/IP connection. I unplug the NIC from my switch. I mean, how can data flow from one computer to another, if they aren't connected?
Hypocrisy is the 8th deadly sin.
I set up something similar on the firewall where I work. It drops AOL packets at various times to encourage people to work instead of using AOL (on our freaking T1).
Man, I hope I don't get flamed by some newbie for this. This post and all of the subthread posts are wrong.
The "-j DROP" target is (mostly) unrelated to the project highlighted by this thread. Please let me explain.
The great advance of the Netfilter/Iptables code is the connection tracking table (ergo Iptables). The problem is that once the connection (not simply TCP, but UDP, and possibly other protocols as well) has been "ESTABLISHED", the firewalling code no longer examines the packets. See the packet traversal diagram for details.
Basically, the earliest place you can have access to the packet and dropping it is in the mangle table in PREROUTING. However, if a packet belongs to a previously established connection, it would already be matched by the conntrack table in PREROUTING. Therefore, it becomes impossible to drop packets belonging to that connection. This _is_ precisely the reason why the aforementioned project was created, to deal with this problem.
Of course, if Netfilter/Iptables had the ability to remove specific entries from the connection tracking table, none of this would be necessary (but that's already the subject of another post).
I want a big red button on the wall that does some sort of manual seperation of our main link cable.
Or possibly one of those big mad scientist 'its alive' lever switches...
Yay me!
couic
sniffit + touch of death, jugglenuts, dsniff etc etc etc .... and to the windoze lamer running "click.exe" it was called nuke.c , but thats a totally different concept anyway.
I added the "cutter" program to the CVS for Devil Linux last week. There should be beta Devil Linux ISO's containing "cutter" appearing on the FTP site shortly.
- BS (Devil Linux core developer)
Ummm even easier.. A single user shouldn't saturate the company OC3. Hovever a set of servers and a bunch of compromised users machines will. This is the multimple minute saturation level that trips the fuse.
The truth shall set you free!
Just so you don't feel put-upon for no reason. You are wrong about the use of tool. It can only be used by root on the box that actually performs the NATing, which is almost always going to be the firewall box. If someone has root access to the firewall box and wants to be a dick, there is a LOT more they can do than simply play with a tool like this (which is really just a script simplifying what can be done by that person who got root on your firewall).
Its a tool that might be useful to a system admin, nothing more, nothing less.