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