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

233 comments

  1. Would be handy by tomhudson · · Score: 4, Interesting

    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.

    1. Re:Would be handy by ColdGrits · · Score: 4, Insightful

      Which is all well and good if your organisation is strictly a 9-5 place.

      However, given that a hell of a lot of places run 24/7, when woudl you propose running said script in their cases?

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    2. Re:Would be handy by Technician · · Score: 5, Interesting

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

      --
      The truth shall set you free!
    3. Re:Would be handy by nadadogg · · Score: 0, Redundant

      see my post for how do to things 24/7 without interrupting work.

      --
      i use linux and windows oh god how can i have an opinion
    4. Re:Would be handy by ColdGrits · · Score: 0, Redundant

      And see my reply as to why that won't work.

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    5. Re:Would be handy by tomhudson · · Score: 0
      Which is all well and good if your organisation is strictly a 9-5 place.</quote>

      My point was that you want to look at connections that shuldn't be there, such as outgoing connections when nobody's supposed to be on certain machines (say Joe has the habit of forgetting to log off before leaving); you'd dump his connection as a matter of practice, and leave a note on his seat (email can be ignored - a big photocopy saying "You left your machine on again last nite, and we found all sorts of kiddie porn on it" on his chair, where everyone can see it, will get noticed)

      Doing this on a departmental basis is sound, even in a 24/7 environment.

    6. Re:Would be handy by interiot · · Score: 1

      It might increase you S/N ratio some to do that, but things like automatic debian updates, etc. could easily show up as "suspicious" activity.

    7. Re:Would be handy by ColdGrits · · Score: 1

      Still not really a useful excersise, killing all active connections twice a day on a department basis. Our site is 24/7, part of a global 24/7 operation world-wide.

      Just because Joe sixpack has gone home for the evening, does NOt mean his session should be killed - he (in our case) is quite probably running stuff even while he is away.

      Now, you might want to limit operations to 33% of the maximum available time, but for sites which require 24/7 operation, that is a very bad idea.

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    8. Re:Would be handy by 56ker · · Score: 4, Interesting

      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.

    9. Re:Would be handy by Anonymous Coward · · Score: 0

      Anything that saturates your uplink for 5 minutes should drop you off the net

      Like a file copy? That will saturate a connection faster than anything else.

    10. Re:Would be handy by Surak · · Score: 4, Interesting

      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.

    11. Re:Would be handy by tomhudson · · Score: 1
      Posters wrote:

      <quote>

      Anything that saturates your uplink for 5 minutes should drop you off the net
      Like a file copy? That will saturate a connection faster than anything else.
      </quote>

      Sounds like bittorrent to me. Man, does it saturate your uplink or what!

    12. Re:Would be handy by tomhudson · · Score: 1
      It might increase you S/N ratio some to do that, but things like automatic debian updates, etc. could easily show up as "suspicious" activity.</quote>

      And on my box it would be suspicious activity - I'm not running debian.

      Seriously, I don't do automatic updates, and I don't allow the other boxes to, either. Maybe I miss out on some of the latest and greatest, but I also know exactly what is supposed to be on each box. If I want an update shoved onto the other machines, I'll host it off an anternal server. Just felel more comfortable with that :-)

    13. Re:Would be handy by Anonymous Coward · · Score: 0

      try edonkey - it really hammers mine

    14. Re:Would be handy by tomhudson · · Score: 1
      But most Joe 6-Packs, when they go home, their sessions should be killed. People not only forget that, they forget to log out and their box is sitting there for anyone to use.

      How many boxes run underground warez servers w/o the user even knowing? "Gee, /my machine/the net/ seems to be a bit slow today?"

    15. Re:Would be handy by pheared · · Score: 2, Funny

      Maybe it could even save your webserver from melting when it's posted on /.

      It will do nothing for your uplink though.

      I'd guess that in most instances of the slashdot attack, line saturation is your biggest factor.

    16. Re:Would be handy by iabervon · · Score: 1

      Considering that you're doing this on a relatively sophisticated firewall, have it hit different connections at different times, depending on when you don't expect those sorts of connections.

      For that matter, losing a connection is generally not that big a deal, and tends to happen anyway. If something is actually attended, the person will notice and restart it without losing much.

    17. Re:Would be handy by ianjk · · Score: 1, Flamebait

      If your security at work consists of a Linux box running iptables, I would be scared. On the other hand, this could be usefull for the home network.

    18. Re:Would be handy by radish · · Score: 3, Insightful

      If you have internal desktops visible to the outside world you have bigger problems...

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    19. Re:Would be handy by tomhudson · · Score: 4, Insightful
      If your security at work consists of a Linux box running iptables, I would be scared.</quote>

      If the box is running only the minimum of services, only allows incoming connections that are established & related, doesn't allow connections from a blacklist of known bad ip blocks, etc., and has someone checking the logs on a regular basis, requires external access through a second box, doesn't have a bunch of /virus-laden internal machines/windows boxes/ on the internal network to serve as zombies for internal attacks (went through that once, all the sales reps lost their windows boxes, cd-roms and floppy drives the same day. They bitched for a while, but they got used to linux) :-), what's the problem?

    20. Re:Would be handy by Anonymous Coward · · Score: 0

      > P-P serving lots of copyrighted material would also trip it.

      ? You're saying this is a "smart fuse", able to look at the contents of packets as well as the quantities being sent? Otherwise, how would you know if the material is copyrighted or not?..

    21. Re:Would be handy by tomhudson · · Score: 2, Insightful
      If you have internal desktops visible to the outside world you have bigger problems...</quote>

      I agree 100%. But it does happen, and this is one of the /ways/tools/ to help sniff them out. More importantly, now Joe Sixpack can be educated to /log out/shut down/ when he leaves, instead of saying "what harm can it do to /leave my machine on all the time/run all sorts of downloaders while I'm home/". Any connection to his machine that comes in after all tcp/ip connections are cut will be obviously wrong, even to a non-computer-literate user. There will be no doubt in his/her mind that someone is "using" their machine, and they will be angry enough to be on your side in the battle for less sloppy security. Any time we can educate the masses, rather than talking at them, we should grab it :-)

    22. Re:Would be handy by Technician · · Score: 1

      Take a look at the typical university bandwidth usage or small ISP. Saturation in absense of P-P is rare. Short spikes do occur. This of course will not work on your typical home user on a less than 1 meg connection on DSL or a Cable Modem. The single user BW cap creates saturations at the cap. Now if a virus nailed your ISP servers and a good portion of users each at their BW cap, this would saturate the main connections for a sustained period. To limit contributition to the problem the fuse should disconnect the shool/small ISP giving the IT staff time to examine the fault offline.

      --
      The truth shall set you free!
    23. Re:Would be handy by Anonymous Coward · · Score: 0

      "Otherwise, how would you know if the material is copyrighted or not?"

      And why do you assume that just because it's copyright it is not okay to copy it in any given circumstance? I'm an artist, my work is copyright. It's also free to distribute.

      The Linux kernel is copyright. Are you saying it should not be okay to copy and distribute it?

      The work I do for my employer is copyright. Are you saying I should not be able to upload a binary that I made for him, because it is copyright?

    24. Re:Would be handy by Anonymous Coward · · Score: 0

      Just because you don't see a firewall doesn't mean it's not there. Let me guess, you've never heard of transparent proxying...

    25. Re:Would be handy by SpaceJunkie · · Score: 2, Interesting

      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.

      --
      OrionRobots.co.uk - Robots From sol
    26. Re:Would be handy by aminorex · · Score: 1

      any box that is connected to a network can
      *become* visible to the outside world.
      there are trojans, such as windows xp, which
      can be triggered by a web page, to connect
      to a remote system, and thereby create a tunnel
      into your network. it happens every day.

      --
      -I like my women like I like my tea: green-
    27. Re:Would be handy by 56ker · · Score: 1

      A lot of the businesses on broadband here are on the residential style 100k/128k . Single user BW caps of 1Gb/day at the ISP end prevent most of these problems. Yes - you have the occassinal problem with viruses etc - but good IT security at both ends should prevent that.

      " To limit contributition to the problem the fuse should disconnect the shool/small ISP giving the IT staff time to examine the fault offline."

      That's very disruptive. The IT staff may be on callout (eg spend an hour to get there), part-time - asleep, at home etc. Best to automatically e-mail/ page the tech with the problem rather than pull the plug on the network (unless it's really serious)....

    28. Re:Would be handy by Fesh · · Score: 1

      So all you have to do is have your virus forewarn the fuse script in the same manner to nullify it's utility, yes?

      --
      --Fesh
      Kill -9 'em all, let root@localhost sort 'em out.
    29. Re:Would be handy by SpaceJunkie · · Score: 1

      I am sure if you are legitamately running the scripts, you would authenticate them in some way. If a malicious emloyee decides to authenticate a virus internally, then you would have a problem - cutter or none.
      Maybe you really should have given them that holiday....

      --
      OrionRobots.co.uk - Robots From sol
    30. Re:Would be handy by walt-sjc · · Score: 2, Insightful

      Nice troll. Years ago, I would have agreed with you on Linux as a firewall.

      The fact is that a properly configured linux machine is a pretty damn good firewall that is as good or better than many commercial firewalls.

      If you are a fortune 500 type company it's not really appropriate, but for many of the millions of smaller businesses out there, it's just fine.

    31. Re:Would be handy by NicolaiBSD · · Score: 2, Insightful

      If your security at work consists of a Linux box running iptables, I would be scared. On the other hand, this could be usefull for the home network.

      Upon what do you base this conclusion? I guess ignorance. We are the second largest DSL telco in the Benelux countries, and we use redundant Linux firewalls to protect important pieces of our network, such as places where our DNS and radius servers live.

      This doesn't scare me at all, actually I like the setup better with regards to availability, maintainability and security then the setup in other parts of our network which are protected through Cisco PIX firewalls.

    32. Re:Would be handy by Anonymous Coward · · Score: 0

      Another prime example of ignorance breeding fear. Linux/BSD are much more powerful than you'd like to think and are perfectly capable of being a firewall for a large company.

      In fact, you can get the same results for a far cheaper price than the equivilent Cisco or Sun solution.

    33. Re:Would be handy by ansible · · Score: 1

      Well, I am reluctant these days to put a Linux box out on the Internet, protected only by iptables.

      Do yourself a favor, and check OpenBSD's pf if you want to see something much better. It is very powerful and flexible. Configuration files are way smaller too, which makes it easier to verify that they are correct.

      Oh yeah, and it uses a configuration file. Which is nice, because I can put in comments. None of the state-saving, can't really edit it stuff.

      I need to run Linux for many things, because applications haven't been ported to OpenBSD. But until someone takes on the considerable task of porting pf to Linux, all my Linux boxen will be protected by OpenBSD routers.

    34. Re:Would be handy by jorgen · · Score: 1
      you'd dump his connection as a matter of practice, and leave a note on his seat

      (BOFH, is that you?!)

      There are nicer ways of educating users, besides I might have a very good reason to leave a TCP connection up when I go home. I never log out from my workstation, I just lock it and go. Why not enforce auto locking after n minutes of inactivity, instead of being a counter-productive asshole and cut all connections just to "educate people"?

    35. Re:Would be handy by tomhudson · · Score: 2, Insightful
      1. (BOFH, is that you?!)
        Depends on who you talk to, but nah, can't take too much credit for that :-)
      2. I might have a very good reason to leave a TCP connection up when I go home.
        Ordinary desktops don't, and they should be logging out completely, as a habit. If they also learn to shut down properly at the end of every day, they could also help save the environment (less electricity, less heating, so less cooling required, so less electricity again :-)
      3. Why not enforce auto locking after n minutes of inactivity, instead of being a counter-productive asshole and cut all connections just to "educate people"?
        Some people resist other forms of education, some are damn lazy, some are just stupid. When polite requests, not-so-polite requests, etc., go unheeded because they are being, as you so kindly put it, unproductive ass-holes, this unproductive asshole will still try to find other methods to induce cooperation.
      If it;'s your home machine, you can do what you want with it. If it's not, then you have to go with the company policy.
    36. Re:Would be handy by Anonymous Coward · · Score: 0

      If I removed Windows from our sales-floor machines (or pissed off the sales reps for ANY reason) I would be immediately fired.

      You obviously don't know your place in your organization.

      For one, in my company, we are a computer school, so we are required by Microsoft to use only Microsoft software for all vital business functions with the exception of classes which specifically require non-Microsoft software. If we fail in this we will have our licenses for teaching Microsoft curriculum pulled.

      Secondly, network administrators are NETWORK ADMINISTRATORS. You do not make policy. You do not make decisions. You are given orders by your management and you follow them. EXACTLY AND WITHOUT QUESTION. If you don't like this there are lots of other people who would be more than happy to take your position and follow orders.

      You, sir, are the problem.

    37. Re:Would be handy by Crazy+Eight · · Score: 1

      As your other respondant asked, what is the problem with that? Put another way, what would be better? I'm not baiting you here. I'm looking for some free education from the professionals who deal with these issues on a daily basis.

    38. Re:Would be handy by tomhudson · · Score: 1
      Poster wrote:If I removed Windows from our sales-floor machines (or pissed off the sales reps for ANY reason) I would be immediately fired.

      Sucks to be you, then, doesn't it?

      Poster wrote: For one, in my company, we are a computer school, so we are required by Microsoft to use only Microsoft software for all vital business functions with the exception of classes which specifically require non-Microsoft software. If we fail in this we will have our licenses for teaching Microsoft curriculum pulled.

      Why not post a copy of this policy, along with your real name (not an AC troll) to the US DoJ division concerned with Microsofts' anti-trust compliance?

      Poster wrote:Secondly, network administrators are NETWORK ADMINISTRATORS. You do not make policy. You do not make decisions. You are given orders by your management and you follow them. EXACTLY AND WITHOUT QUESTION.

      Like I said, sucks to be you. I re-wrote the apps so we could do the inventory control, financial calculators, contact manager, etc., using a web interface and mysql. Got rid of the Windows point-of-failure the same day a virus attacked my machine from inside our network.

      And, no, I didn't present this as a "we could do this...", I made it quite clear that it was essential for the integrity of our network, and to ensure that the sales reps could continue to access their data in a timely fashion.

      I also pointed out that management could now access the same data in real time from home.

      Couldn't have done this as easily or cheaply under WinBloze, and it would not have been virus-free.

    39. Re:Would be handy by Anonymous Coward · · Score: 0

      +1 calling winxp a trojan.

    40. Re:Would be handy by tomhudson · · Score: 1

      Finally - an AC post to one of my posts today that isn't a troll! Now I can go home complete :-)

    41. Re:Would be handy by snake_dad · · Score: 1
      besides I might have a very good reason to leave a TCP connection up when I go home

      Then you might need to arrange it with the network admin so he knows what's happening. So he can add it to the "don't kill tonight" list. Maybe this level of security applies to your company, maybe it doesn't...

      --
      karma capped .sig seeking available Slashdot poster for long-term relationship.
    42. Re:Would be handy by danbuhler · · Score: 1

      How can you tell the difference between an employee downloading a large pdf file and an employee uploading a copy of your fileserver?

      umm, easy
      one is down, one is up

    43. Re:Would be handy by Col.+Panic · · Score: 1

      I will agree that OpenBSD pf provides terrific protection but I would like to know why you are reluctant to use iptables for commercial use.

    44. Re:Would be handy by Anonymous Coward · · Score: 0

      tomhudson is, by far, the biggest fag in the world.

    45. Re:Would be handy by Talez · · Score: 1

      If it;'s your home machine, you can do what you want with it. If it's not, then you have to go with the company policy.

      And thats why nobody is going be sorry about seeing your ass go.

    46. Re:Would be handy by Dwonis · · Score: 1
      (BOFH, is that you?!)

      I can check for you, if you like. Just tell me your username...

    47. Re:Would be handy by lewp · · Score: 1

      Hate to say it, but his attitude will keep him employed a whole lot longer than yours will.

      --
      Game... blouses.
    48. Re:Would be handy by lewp · · Score: 1

      Future posting hint:
      Your credibility becomes zero as soon as you say "WinBloze". You sound like an eight year old bragging about how his "N3W L1NUX R00LZ". If you really are a professional, act like one.

      If you replaced all my apps with their rich, functional GUIs with a weak web interface tied to a mysql database I'd kill you in your sleep.

      Yes, I am pretty staunchly anti-Microsoft. Yes, I love Free Software as much as the next rabid Slashdotter. Your attitude still makes me want to vomit.

      --
      Game... blouses.
    49. Re:Would be handy by tomhudson · · Score: 1
      &;t;quote>If you replaced all my apps with their rich, functional GUIs with a weak web interface tied to a mysql database I'd kill you in your sleep.</quote>

      Depends on

      1. what apps you are using, and
      2. whether it's possible to replace them with a web interface to a database, and
      3. what other functionality is needed/desired
      After all, with a bit of javascript and some css, you can make a pretty functional gui for many different tasks. The user doesn't even have to know they're using a web browser.

      But, yes, I would agree that if you make a boring-looking app which is just a bunch of static forms that make calls to a db, you might have a reason to *hmph* commit mayhem *hmph* :-)

      As for my using the term WinBloze, I wasted saturday afternoon restoring a friends' box after his anti-virus software allowed a virus AND a trojan onto his system. Fortunately, I had previously installed linux on his system, so I was able to recover most of his data (unfortunately, large chunks of his filesystem were hosed).

      I really do have better things to do than re-install sucky operating systems, but he is a friend, so ... (sigh :-)

    50. Re:Would be handy by 56ker · · Score: 1

      I meant on total bandwidth (which is a total of down and up). :P Anyway - point taken.....

  2. great by mike_scheck · · Score: 5, Insightful

    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?

    1. Re:great by nadadogg · · Score: 5, Interesting

      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.

      --
      i use linux and windows oh god how can i have an opinion
    2. Re:great by aurelian · · Score: 1, Funny
      working from home would be brought to the higher-ups' attention, thereby making you look good :)

      until they check the logs...

    3. Re:great by ColdGrits · · Score: 2, Insightful

      No good.

      I can (and indeed, HAVE to) VPN in from absolutely anywhere I happen to be if Things Go Wrong with systems. So do my peers around the world.

      We could be required to connect from anywhere at any time. So how do you list all those "safe" IPs? They have to onclude hotels, Kiosks, internet cafes, etc al. Which kinda makes your "safe" list completely pointless.

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    4. Re:great by arkanes · · Score: 1

      Well, then, obviously your organization is going to have to trade the enhanced security offered by such a script for the convenience of 24/7 access from any IP. Other organizations, without the need for such broad access, can still use it.

    5. Re:great by ColdGrits · · Score: 5, Insightful

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

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    6. Re:great by BrookHarty · · Score: 2, Insightful

      I hate having my VPN sessions drop in the middle of work. Screen/Vnc to keep my work sessions alive. Abort 1 hot backup and you tend to get pissed at the IT folks.

      It gets so bad with IT and uber security, having urls with *trans* aka translate blocked by the web proxy software, blocking ftp (sorry mr vendor, you cant get this 100meg core file on your ftp site), etc.

      If it gets any worse, i'll use my wireless modem in my laptop and route around IT.

    7. Re:great by nadadogg · · Score: 1

      That is an excellent point. In your situation, this cutter technique would probably not be very effective. My safe IP idea would be more valid with situations like where I work, when the only outside>in connections are some supervisors checking databases from home, and me checking dns/mail servers from my home. If anything Crazy(tm) happens, the office is only a 30 minute drive from my apartment to fix things on the spot.

      --
      i use linux and windows oh god how can i have an opinion
    8. Re:great by Anonymous Coward · · Score: 0

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

      Why would you care about gracefully closing these connections instead of simply blocking them with the firewall and purging associated TCP session(s) ?

    9. Re:great by tomhudson · · Score: 1

      So just set up a separate box with its' own internet connection for only those types of connections/sessions. It's not like servers are expensive nowadays. Come on, this is /., I'm sure given 15 minutes somebody can come up with 20-line script that will take care of what you need :-)

    10. Re:great by ColdGrits · · Score: 1

      "If anything Crazy(tm) happens, the office is only a 30 minute drive from my apartment to fix things on the spot."

      I live 15 minutes drive from work.

      I dunno about you, but I much prefer rolling out of bed, logging on, fixing problem and rolling back to bed over getting out of bed, getting dressed, spending 30 - 60 minutes round trip driving,. fixing problem, getting undressed and rolling back into bed :-D

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    11. Re:great by nadadogg · · Score: 1

      Well, if you were only connecting from home, like I do, your IP would be on the safe list. And when I say something Crazy(tm) happens, its usually something like our database server shutting itself down or locking up, which requires a physical reboot.

      --
      i use linux and windows oh god how can i have an opinion
    12. Re:great by Anonymous Coward · · Score: 0

      you keep up your vpn in the middle of the night? Are you sleeping or working in the middle of the night?

      If you are sleeping, your vpn should not be connected. If you are working, maybe the disconnect should be done at the end of the night (like 4 AM?) instead of in the middle.

      Just a thought. One disconnect per day isn't too much to ask to keep those zombied connections under control. It is, after all, to your (and everyone's) advantage to not have a zillion dead connections eating resources.

      l8,
      AC

    13. Re:great by ColdGrits · · Score: 1

      (1) I am not always at home - I could be absolutely anywhere when The Call comes in. It's just that when I am at home, it is easier to fix without having to drive for 30 minutes.

      (2) You mean you are unable to remotely reboot your systrems? For real? Then you need to get a proper sysadmin and configure things up properly. I woudl hate to be admining our Norwegian servers (which I also do) and have to catch a flight just to be able to reboot them...

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    14. Re:great by Fembot · · Score: 1

      On another, only vaugely related note does anyone know of a script which I can run on my linux firewall/router to provide the following stats:

      - Current Bandwidth utilization (like the bar on kernel.org)
      - Data transfered in total
      - Data transfered since last reboot
      - Data transfered in the previous (rolling) 24 hours
      - The above 3 stats on a per IP address basis

    15. Re:great by gid · · Score: 2, Informative

      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.

    16. Re:great by BrookHarty · · Score: 1

      Exactly, and with GPRS modems, no reason you cant make your office workstation a server. ;)

      Of course, your prob breaking every company security policy.

    17. Re:great by Anonymous Coward · · Score: 0

      Use IPSec. All connection related information is encrypted. Any disruptions will have the same effect as packet loss, no more, no less. If network administrators continue to base their strategy on snooping, silently redirecting, port based blocking/trafficshaping and now connection-cutting, then they're in for a rude awakening when transport level encryption becomes ubiquitous.

    18. Re:great by MrWa · · Score: 1
      And then I could write a script at home to check email periodically, modify a file, copy some powerpoint back and forth, look good, and profit!

      The elusive second step solved!

    19. Re:great by Fembot · · Score: 1

      Looks like I might have to write my own solution to do the above (and more) then over the summer :-(

    20. Re:great by gid · · Score: 1

      Also check out darkstat It seems to be a bit better and cleaner than ntop. I just installed it out of curiosity and it seems to be working pretty well.

      As far as total data transferred stats, do an ifconfig, it should show stats for network interfaces, writting a few scripts probably wouldn't be that incredibly complex. Or maybe even extending darkstat to incorporate what you want to do, if it's good enough, send the author a patch. :)

    21. Re:great by nadadogg · · Score: 1

      I have no comment there my friend ;)

      --
      i use linux and windows oh god how can i have an opinion
    22. Re:great by Fembot · · Score: 1

      That looks pretty good thanks :-)

      Might see if I can knock up a patch to make it suit my requirements slightly better over the next week or so

    23. Re:great by Anonymous Coward · · Score: 0

      heh.. use mozilla for private stuff. Name the mozilla icon "command line debugger". They only check IE history anyway when they walk past your machine. "Logs? What logs? We have no fireplace here.." (yes, our management is like that)

    24. Re:great by treat · · Score: 1



      We could be required to connect from anywhere at any time. So how do you list all those "safe" IPs? They have to onclude hotels, Kiosks, internet cafes, etc al. Which kinda makes your "safe" list completely pointless.</i>
      <p>
      If you're allowing logins to your network from such insecure locations as kiosks and internet cafes, you don't care about security anyway.

    25. Re:great by Anonymous Coward · · Score: 0

      Where I work, many of our systems are rebooted automaticaly if they have problems. I only have to do anything if the automated operation fails. :)

    26. Re:great by ColdGrits · · Score: 1

      Really?

      Care to explain how you reach THAT invalid conclusion, please?

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    27. Re:great by treat · · Score: 1
      Care to explain how you reach THAT invalid conclusion, please?

      Why do you believe that it is safe to trust a system that you have no control over and that an unknown (but large) number of people have had physical access to before you?

    28. Re:great by ColdGrits · · Score: 1

      I don't.

      I don't trust that system either.

      But then again, I never said I did.

      I don't HAVE to trust that *system*.

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
    29. Re:great by treat · · Score: 1
      I don't HAVE to trust that *system*.

      Then you will not be using it to connect to a system of yours unless you don't very much care about its security.

      We're not talking about connecting from a trusted system over an untrusted network. We're talking about a system on which you don't even know who may be able to see and control the screen and keyboard.

    30. Re:great by ColdGrits · · Score: 1

      If that's what you wish to believe, then I'm not going to stop you.

      Your skewed belief of how we overcome these issues is of no concern of mine.

      --
      People should not be afraid of their governments - Governments should be afraid of their people.
  3. Well, that kills that. by Divide+By+Zero · · Score: 5, Funny

    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.
  4. Oh, I remember this by Anonymous Coward · · Score: 2, Funny

    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.

  5. I have an even better idea: by Sloshed_dot · · Score: 3, Funny

    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.
    1. Re:I have an even better idea: by Anonymous Coward · · Score: 0

      Yeah, now we just need to write a script that shoots out the network cable when it detects a hacker! Great idea!

    2. Re:I have an even better idea: by arcanumas · · Score: 1

      Very nice idea , but you can not put it in Cron.
      .. althought i am sure slashdoters will find a way to do even that.

      --
      Slashdot Sig. version 0.1alpha. Use at your own risk.
    3. Re:I have an even better idea: by thogard · · Score: 1

      I hope you were being funny.

      If you pull the plug out and then plug it back in hours latter, the connection may just pick up where it was and keep going. TCP timeouts are much longer than a typical application layer timeout and real TCP doesn't drop the connection just because the link light goes out (windows style).

    4. Re:I have an even better idea: by Asprin · · Score: 1


      Sure you can -- you just need that robot arm thingy.

      --
      "Lawyers are for sucks."
      - Doug McKenzie
    5. Re:I have an even better idea: by Crazy+Eight · · Score: 1
      "i am sure slashdoters will find a way to do even that."

      How about something with 2 ether jacks, a few relays, and serial port interface?

  6. Google Cache of post, and a quick comment by Cruel+Angel · · Score: 5, Informative
    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.

    --
    Two Rules For Success:
    1) Never tell people everything you know.
    1. Re:Google Cache of post, and a quick comment by Anonymous Coward · · Score: 0

      Someone has, google for "TCP reset". This is really not news.

  7. Google cache by arvindn · · Score: 4, Informative

    slashdotted with less than 5 comments posted. google cache.

    1. Re:Google cache by Anonymous Coward · · Score: 1, Funny

      Karma whoring after only 5 comments posted.

  8. For Aol Users by jetkust · · Score: 3, Funny

    Wow, now aol users can close aol without using ctrl+alt+delete.

    1. Re:For Aol Users by Anonymous Coward · · Score: 0
      Wow, now aol users can close aol without using ctrl+alt+delete.

      Now someone just has to port Netfilter/iptables to windows.

    2. Re:For Aol Users by Anonymous Coward · · Score: 0

      Where's the double + key?

  9. Evil bit comes to the rescue! by RyanK · · Score: 5, Funny

    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!

    1. Re:Evil bit comes to the rescue! by Anonymous Coward · · Score: 1, Funny

      Where did you find out about that evil bit? Slashdot should run an article on it!

    2. Re:Evil bit comes to the rescue! by Anonymous Coward · · Score: 0

      Forgive me, but that' Dr. Evit Bit to you.

    3. Re:Evil bit comes to the rescue! by mek2600 · · Score: 1

      I'm sure we'll (once again) be seeing that article any day now...

    4. Re:Evil bit comes to the rescue! by Anonymous Coward · · Score: 0

      dude, this stopped being funny about 2 months and 15 days ago.

  10. That would be great by missing000 · · Score: 4, Funny

    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

    1. Re:That would be great by Anonymous Coward · · Score: 0

      Yes you could - it's just that any connections open at 5 would be closed and you'd have to re-establish them.

    2. Re:That would be great by missing000 · · Score: 1

      Yes you could - it's just that any connections open at 5 would be closed and you'd have to re-establish them.

      That's just great. If that's what the poster intended, it sounds almost completely useless.

      If I can just reconnect, the script kiddy will too.

      This looks worse than simple logging.

    3. Re:That would be great by tomhudson · · Score: 1
      The point is that you would then have a new, unexpected connection from the outside coming in, rather than a continuation of an existing connection from the inside going out.

      Or, better yet, you would have a new outboud connection showing up in the logs from a machine that nobody is using, on which there are no cron jobs running (at least none authorized) and which is not suposed to be connected at that time.

      It's not supposed to be a one-shot solution - just another tool in our swiss army knife :-)

    4. Re:That would be great by missing000 · · Score: 1

      Not to beat a dead horse here, but this is silly.

      If you just want to drop all tcp connections there are much easier ways to do this.

      Also, if you find unknown connections in a log file for that time frame you are so worried about, it's real easy to get more information on them.

      A script that uses cutter to terminate all connections will be slow, presents no new security, and serves to really screw up my day if /usr fills up at 4:59.

      Don't get me wrong, cutter is a good tool. It's just not the right tool for that job.

    5. Re:That would be great by tomhudson · · Score: 1
      A script that uses cutter to terminate all connections will be slow, presents no new security, and serves to really screw up my day if /usr fills up at 4:59. </quote>

      why would /usr fill up at any time. /usr/local, maybe, if you have users installing stuff on the server (which they shouldn't be - they should be sticking the stuff on their own machines).

      maybe you meant /home? If that fills up, that's a different story, but then again, if that fills up, it may be an indication that you really do need to cut external connections once in a while to keep people from downloading all those /movies/porn/warez/isos/ after-hours :-)

    6. Re:That would be great by SpaceJunkie · · Score: 1

      Damn straight.. Now there is an idea.. We could solve network security and bandwidth issues, and 24/7 workforce issues in one hit. Also - maybe you could have business discounts, for businesses guaranteed to only use the download bandwidth 9-5. Although thats probably gone a bit far..

      --
      OrionRobots.co.uk - Robots From sol
  11. But what about UDP tunnels? by dpilot · · Score: 4, Informative

    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.
    1. Re:But what about UDP tunnels? by dissy · · Score: 2, Informative

      UDP doesnt need 'killed' since there is no connection at any time to be killed.
      Each UDP packet is seperate.

      Just block the incoming UDP packets. The stream will just stop.

      If you just block a TCP connecting _from being established_, this rule will not effect currently established connections, and that is what this tool is for.

    2. Re:But what about UDP tunnels? by dpilot · · Score: 1

      I thought about that after posting. Ideally you'd want to block the connection, not the port. I guess this is already standard fare for "dynamic firewalls," just not for this application.

      --
      The living have better things to do than to continue hating the dead.
    3. Re:But what about UDP tunnels? by mike_scheck · · Score: 1

      >> After all, UDP tunnels are frequently better

      I suppose it depends on how you look at it. true, you have better performance with udp, but you all so have to *really* worry about not having all the connection oriented things that that extra overhead offers you. Its a policy at several places I have worked to flat out drop incoming udp because its impossible to prove if its being spoofed or not.

      >> SSH tunnels are merely secure and easy, not >> necessarily the best

      Of all the things you can compromise when setting up a vpn into your internal network I don't think security is one I'm not willing to cut any corners on.

    4. Re:But what about UDP tunnels? by dpilot · · Score: 1

      But you can tunnel tcp over udp quite readily, and you can encrypt udp streams, as well. That's why I mentioned OpenVPN - they go into this stuff in better detail than I can. Apparently an OpenVPN author was involved in IPSec development, has beefs with several parts of it, and improvements in OpenVPN. (Of course beefs and improvements may be a matter of opinion, but his writing looks reasonably sound.

      --
      The living have better things to do than to continue hating the dead.
  12. Does this work for DOS? by juahonen · · Score: 1

    So does this method allow DOSsing connections, with forged IP addresses?

    1. Re:Does this work for DOS? by Anonymous Coward · · Score: 1, Interesting

      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.

    2. Re:Does this work for DOS? by Anonymous Coward · · Score: 0

      Only if someone is as stupid as to have an IDS set up to cut and reject on probes, which sadly does happen

  13. nice first step by Lumpy · · Score: 5, Interesting

    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.
    1. Re:nice first step by Anonymous Coward · · Score: 0

      you should look into mrtg

    2. Re:nice first step by sql*kitten · · Score: 1

      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?

      The way Open Source works is if someone wants something, they write it themselves, perhaps using other Open Source things as a base. Saying "give me X feature" rarely results in it happening.

    3. Re:nice first step by Anonymous Coward · · Score: 0

      mrtg will show you details on 5000 different connections real time with end to end IP numbers?

      Wow! when did they add that ability to a GRAPHING PROGRAM.

      you should read the posts before replying... What he asked for does not exist in this world yet.

    4. Re:nice first step by Anonymous Coward · · Score: 0


      The way the real world works is that a demand creates a desire.

      Oh an Lumpy was very open source in giving the world his great idea for FREE instead of keeping it to himself.

      I agree with him... Gimmie that feature! Come on Cisco, where's a router with that abilities... because with sql*kitten's attitude the Open Source community wont do it because of spite now.

      Or just pure stupid arrogrance...

    5. Re:nice first step by tensai · · Score: 5, Interesting

      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.

    6. Re:nice first step by mike_scheck · · Score: 1

      Have you ever seen ntop (www.ntop.org). Its a nice utility with a web interface, and good reporting features for bandwidth usage. If you put it on the gateway/firewall its pretty decent.

    7. Re:nice first step by MerlynEmrys67 · · Score: 1

      Hmmm... RMON on the switch... Been working for me for over 5 years now You can even look at Top-N senders, and other fun things

      --
      I have mod points and I am not afraid to use them
    8. Re:nice first step by peter · · Score: 1

      Luckily, ambitious hackers have already thought of this. (minus the web interface...)

      iptstate does that (not the traffic volume, though) on a Linux NAT firewall. It actually shows you everything the netfilter connection tracking stuff is keeping track of, so it's useful on any stateful firewall, not just NAT.

      Also, try ipband, iftop, or iptraf.

      --
      #define X(x,y) x##y
      Peter Cordes ; e-mail: X(peter@cordes , .ca)
    9. Re:nice first step by snake_dad · · Score: 1
      Saying "give me X feature" rarely results in it happening.

      But it often results in "hey dude, look here, been done already". Phrasing it like "has X feature been done anywhere?" would give more replies ofcourse.

      --
      karma capped .sig seeking available Slashdot poster for long-term relationship.
    10. Re:nice first step by Anonymous Coward · · Score: 0

      Interestingly, this is not the case. The question whether a feature has already been implemented is the user's problem. Asking for a feature prompts developers to get to work. Other people in the loop tend to block off such requests for unnecessary utilization of scarce developer resources, but don't care about users who are to lazy to use a search engine. If you want to get a list of the most popular implementations of feature X, propose that someone should implement it. Asking for the list directly will usually only get you "use google" responses.

  14. Anyone got the tarball? by CoolQ · · Score: 1

    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

  15. Useful by globalar · · Score: 2, Insightful

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

  16. It the cutter tool itself the news here? by Anonymous Coward · · Score: 2, Informative

    Two words: "dsniff", "tcpkill". *yawn*

    1. Re:It the cutter tool itself the news here? by danbuhler · · Score: 1

      no kidding, what a waste of a story

  17. GUI Integration? by jedi_gras · · Score: 1

    If only this "utility" could be integrated in some nice GUI package or application...

    It would make "security" that much more fun!

    1. Re:GUI Integration? by spydir31 · · Score: 1

      Better yet, it should look like psDooM :)

    2. Re:GUI Integration? by nagora · · Score: 1
      If only this "utility" could be integrated in some nice GUI package or application...

      Yes, I really want to install and maintain X on my firewall/gateway.

      TWW

      --
      "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
  18. Thought that was builtin?? by Tmack · · Score: 2, Insightful
    Im sorry, but isnt that what -j DROP is for??? If someone is messing with your firewall, just write a rule to block by that IP or IP/port combo that targets the DROP iptables target. Drops the packets, makes it look like the whole machine turned off. Works great for spam too, anyone that spams repeatedly gets their addy added to a rule that drops all port25 traffic from them.

    Tm

    --
    Support TBI Research: http://www.raisinhope.org
    1. Re:Thought that was builtin?? by Anonymous Coward · · Score: 1, Informative

      this is supposed to be for tearing down established connections, not just what to do with any unrequested packets that hit the firewall

    2. Re:Thought that was builtin?? by Anonymous Coward · · Score: 1, Informative

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

    3. Re:Thought that was builtin?? by Anonymous Coward · · Score: 0

      good distinction - thanks

    4. Re:Thought that was builtin?? by zaad · · Score: 1

      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

      "-j DROP" does no such thing. DROP does exactly as it implies. It silently drops packets with no acknowledgement.

      The cutter project injects RST packets into an established connection causing aborts on both end nodes. Cleanly tearing down a TCP connection would be to do a 4-way TCP handshake by sending ACK-FIN packets.

  19. How to announce software on /. by CoolQ · · Score: 5, Funny

    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

    1. Re:How to announce software on /. by Anonymous Coward · · Score: 0

      Bitter about not being able to download it?

    2. Re:How to announce software on /. by Anonymous Coward · · Score: 0

      How to count to 3:

      1)
      2)
      5)
      Three sir, three!
      3)

  20. Re:What kind of fuckwit moderates this insightful? by ColdGrits · · Score: 0, Redundant

    "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.
  21. Gee, by funwithBSD · · Score: 2, Informative

    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
  22. SSH tunnels or VPNs - isn't that the same? by rxed · · Score: 1

    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?

    1. Re:SSH tunnels or VPNs - isn't that the same? by Anonymous Coward · · Score: 0

      or am I wrong?

      Yes, you are.

      VPN = virtual private network.
      Give every word a thought, especially the last one.

    2. Re:SSH tunnels or VPNs - isn't that the same? by FreeLinux · · Score: 4, Informative

      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.

    3. Re:SSH tunnels or VPNs - isn't that the same? by Tony+Hoyle · · Score: 4, Interesting

      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.

    4. Re:SSH tunnels or VPNs - isn't that the same? by evbergen · · Score: 1

      On the mark, except that ssh doesn't use ssl/tls, but is different protocol based on a number of the same cyphers and hashes.

      --
      All generalizations are false, including this one. (Mark Twain)
  23. Re:fuckwit? I don't think so. by tomhudson · · Score: 4, Insightful
    By definition, if it's a 24/7 operation, you wouldn't be terminating tcpip connections at all...</quote>

    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.

  24. Golden days at my company by lateralus · · Score: 5, Funny

    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
    1. Re:Golden days at my company by CoolVibe · · Score: 1
      I hear ya.

      I too remember those days when a sysadmin (me) could use a 'special' DHCP lease as a LART because some $(LUSER) kept opening virus infected e-mails.

      Anyhoo, disconnecting connections on the local network is ieasy. Just spoof the server endpoint and send some RST's to the connection origin you want to kill. That should stop any connection made quite easily. At least, that's how I stopped network connections originating from the LAN I used to administer. Great lart too. My hacked up version that did that used libpcap and also the parser, so I could target the offending host(s) quite effectively.

    2. Re:Golden days at my company by Anonymous Coward · · Score: 0

      Absolutely - we called it "see who yells". It was the preferred method of troubleshooting at one time.

    3. Re:Golden days at my company by Anonymous Coward · · Score: 0

      You're not the only one. Imagine doing it with a power plug that purposely shorts out the whole circuit.

      It's been done...

    4. Re:Golden days at my company by the_machine · · Score: 1

      We used to use the same trick. Except, we would pull the cable of the cute girls and then wait for the call. We would then have to make a visit to the workstation to meet her (I mean, to fix the problem). We would then patch it back in at the comm closet and look like a hero. It worked great.

    5. Re:Golden days at my company by lateralus · · Score: 1

      There used to be a student that came to work part time as a secretary in one of the companies buildings. She used to model when she was younger and now she was in university.

      The building was just across the street and yet we had no comfortable way of moving equipment between the two. On days that she was working, half the staff would suddenly feel like carrying 5 new 17 inch monitors across to the other building no question asked;

      "Hi there, I've just carried this immensely heavy object a long distance, where would you like me to put it for ya". Looking back I feel pretty foolish but boy was she ever worth it. Talking with her was usually the highlight of the workday.

      --
      If you outlaw the law, only criminals will have laws
  25. First P by CHatRPI · · Score: 0, Offtopic

    I would have gotten first post, but my firewall terminated my connection to /. :(

  26. Can of Cron and a Script? by Line_Fault · · Score: 3, Insightful

    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.

    1. Re:Can of Cron and a Script? by Dachannien · · Score: 1

      It permits the connection to be shut down "gracefully" (at least, at the transport layer), freeing up at least one socket on the machine inside the firewall. Hopefully, this would also free up application-level resources (depending on how the app was written).

      Without terminating the connection (just dropping packets), it becomes entirely encumbent upon the application to have appropriate timeout code for those situations. There is no guarantee that the app has timeout code, or the timeout could be lengthy.

      Certainly, this shouldn't be the only tool in a sysadmin's arsenal, but it has its uses.

    2. Re:Can of Cron and a Script? by Anonymous Coward · · Score: 0

      No configuration needed. Just compile and run.
      Works marvellously.

  27. sniffit by wotevah · · Score: 4, Informative
    Cutting a TCP connection is really simple - just send a RST packet to one or both ends and enjoy.

    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.

    1. Re:sniffit by AuraSeer · · Score: 1

      Cutting a TCP connection is really simple - just send a RST packet to one or both ends and enjoy.

      Didja read the article?
      The article explains why this doesn't work.
      It might be a good idea to read the article.

    2. Re:sniffit by wotevah · · Score: 2, Informative
      The article was already /.-ed so I didn't bother. RST was my idea, assuming you're on the router you have access to the sequence numbers so it's no big deal.

      Sniffit (or the tool it used - tcpkill I think) was using the FIN method though, because if my memory does not fail me, the error message you'd get on either end was "Connection closed by foreign host". I think the RST method would show a different error, probably "Connection reset".

    3. Re:sniffit by AuraSeer · · Score: 1

      The article was already /.-ed so I didn't bother.

      Wow, too bad people didn't post the Google cache anywhere. It would be really useful if somebody showed us the cached page. Why oh why didn't any posts point out the Google cache for us?

  28. No need for cutter by hhg · · Score: 4, Funny

    See, his webserver can not accept any connections, and I bet he's not using cutter at the moment

  29. tcpkill by pknut · · Score: 5, Interesting

    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.

    1. Re:tcpkill by Abcd1234 · · Score: 2, Interesting

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

    2. Re:tcpkill by pknut · · Score: 5, Informative

      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.

  30. Easy to hack around! by Line_Fault · · Score: 3, Interesting

    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!!!

    1. Re:Easy to hack around! by Anonymous Coward · · Score: 0

      Think about what you're saying for a bit. If someone really wanted to lock you down using this, they most certainly could. Just because you can ensure you leave a couple of "half open" connections, that doesn't mean you can now somehow magically continue the sessions.

    2. Re:Easy to hack around! by Dachannien · · Score: 1

      Of course, this depends on whether you had root access to the remote machine.

    3. Re:Easy to hack around! by evilviper · · Score: 1
      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.

      That's too much work for me. I'd just enable keepalive in OpenSSH, and have it re-open the connection ever time it gets closed... The benefit of that being, if something like this is happening with a GOOD firewall that actually flushes the connection, it will be opened up again right away.

      The only real problem is that most software doesn't handle connections closing, which is unfortunate... I want to be able to disconnect from the server, then reconnect only to have the same things still running. That goes for X, the console, network connections (FTP, HTTP, etc), etc.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  31. VPN by apankrat · · Score: 2, Insightful

    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
  32. Re:fuckwit? I don't think so. by Oculus+Habent · · Score: 1

    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
  33. I liked this util better the first time... by Anonymous Coward · · Score: 2, Interesting

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

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

    -Ben

    1. Re:I liked this util better the first time... by Cthefuture · · Score: 1

      Gotta love that K&R C... spblech.

      --
      The ratio of people to cake is too big
  34. MOD PARENT UP by Anonymous Coward · · Score: 0

    Cat got your tongue? (something important seems to be missing from your comment ... like the body or the subject!)

  35. Tools of the Trade by jabbadabbadoo · · Score: 1

    Soon we'll have to add "cutting" to the hacker's dictionary. And, sorry to say, the cracker's dictionary.

  36. An idea by d3faultus3r · · Score: 3, Insightful

    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
  37. NO They weren't slashdotted... by splerdu · · Score: 5, Funny

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

  38. Re:fuckwit? I don't think so. by tomhudson · · Score: 5, Interesting
    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 :-)
  39. My ISP is using this already by chronos82 · · Score: 4, Funny

    It seems to me the connection just drops every five minutes, perhaps they have this on their crontab ;)

  40. Our friend, the google cache by JamochasWitness · · Score: 1, Informative

    Looks like the site is kaput.

    slash-dotted-server

  41. Re:My ISP is using this already by Anonymous Coward · · Score: 0

    You wouldn't happen to be using Cogeco would you? :)

  42. Don´t you... by dark-br · · Score: 1

    ...dare pulling that cable! My coffe machine is on the other and!

  43. No... by dark-br · · Score: 1

    ...the site is not "kaput", thatÂs just the damn script running :P

  44. DOS? No, I think you need a real OS. by Anonymous Coward · · Score: 0

    C-title

  45. Go To Jail by wagemonkey · · Score: 1
    Seriously, run this and "interfere with computer communications", and someone is going to be nervous in the shower as a result.

    If a high school kid can be expelled for writing a newspaper article how long will it take?

  46. Abort hacker attacks??? by Poison-R · · Score: 1

    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
  47. Generic Tools? by commonchaos · · Score: 2, Interesting

    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?

    1. Re:Generic Tools? by phorm · · Score: 1

      IPtables has abilities for packet-mangling... I think that it can do something along this line.
      Somebody can come and flame me down if I'm wrong, I've never had much need to mangle packets myself, and all the things that do I don't need to mess with anyways.

    2. Re:Generic Tools? by peter · · Score: 1

      I don't know about tools to do it without breaking the connection (because I think the two sides would get confused about sequence numbers if you just stuck an extra packet in), but I have come across the nemesis project. Haven't actually used it, though. For more general packet-generating, sendip can generate arbitrary ip packets.

      --
      #define X(x,y) x##y
      Peter Cordes ; e-mail: X(peter@cordes , .ca)
    3. Re:Generic Tools? by dagda76 · · Score: 2, Informative

      You can manually do this with hping2.

  48. Re:My ISP is using this already by jasonsfa98 · · Score: 1

    or Time Warner ...

  49. Re:great -safe ip range by Anonymous Coward · · Score: 0

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

  50. Injecting packets into the connection by zaad · · Score: 5, Informative

    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.

    1. Re:Injecting packets into the connection by peter · · Score: 1

      mod parent up, or do some research and see if there is a way to change timeouts.

      ipchains (kernel 2.2) used to have a variable timeout for NAT, but I think they changed that for netfilter/iptables (kernel 2.4). because they improved something so "normal" connections got dropped when they were over, so the kernel's tables didn't fill up, even with a long timeout. With ipchains, I used to set the timeout to > 2 hours, so TCP keepalives would keep SSH sessions from being dropped. I don't have to do that with iptables (and I guess I actually can't!)

      BTW, you're right about the 5 days. Running iptstate on my NAT firewall shows that quite clearly. I had been thinking it was two hours, but it's actually 120 hours! I've got a couple connections kicking around with 60 hours left to time out.

      --
      #define X(x,y) x##y
      Peter Cordes ; e-mail: X(peter@cordes , .ca)
  51. Spare us the Cutter! by Anonymous Coward · · Score: 0



    This article calls to mind
    a catchy Echo and the Bunnymen> song from those ca-razy 1980s....

  52. Difference between harware router and linux firewa by asscroft · · Score: 1

    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
  53. MOD PARENT UP! by Anonymous Coward · · Score: 0

    n/c

  54. Dont' see it helping much by ansible · · Score: 1

    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.

  55. Resetting TCP sessions by JRHelgeson · · Score: 2, Informative
    Sending out TCP resets is something that network based IDS packages have been doing for some time now.

    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.
    1. Re:Resetting TCP sessions by pbemfun · · Score: 1

      Sending a MAC with FF:FF:FF:FF:FF:FF would only be a problem on the local subnet since MAC addresses are not routed.

      Therefore, if you modified your driver to ignore RST's from a FF:FF... MAC, it would only matter if a router/machine on your local were sending them to you.

  56. Web interfaces? Bah! by Read+Icculus · · Score: 1

    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.
  57. Re:Difference between harware router and linux fir by ReNeGaDe75 · · Score: 1

    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.
  58. The easy vs. the hard problem by neildaswani · · Score: 1

    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/

  59. Better solution by ReNeGaDe75 · · Score: 1

    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.
  60. Re:My ISP is using this already by Anonymous Coward · · Score: 0

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

  61. Clarification - Re:Thought that was builtin?? by zaad · · Score: 1

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

  62. Big Red Button by Hecatonchires · · Score: 1

    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!

  63. something of interest by Anonymous Coward · · Score: 0
  64. Wasnt this better the first 15 times? by Anonymous Coward · · Score: 0

    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.

  65. One dedicated firewall distro already has cutter! by blubdog · · Score: 1

    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)

  66. Re:umm, easy by Technician · · Score: 1

    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!
  67. Re:Hmmmmmm... by Anonymous Coward · · Score: 0

    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.