Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security

TCP/IP Connection Cutting On Linux Firewalls 233

Posted by Hemos from the better-then-vasectomy dept.
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 discussion has been archived. No new comments can be posted.

TCP/IP Connection Cutting On Linux Firewalls More

TCP/IP Connection Cutting On Linux Firewalls

Comments Filter:

  • Would be handy (Score:5, Interesting)

    by tomhudson ( 43916 ) <barbara.hudsonNO@SPAMbarbara-hudson.com> on Monday June 16, 2003 @11:10AM (#6212521) Journal
    This would be a handy thing to put in a script to run once a day, after everyone's gone home, then again before anyone gets in in the morning. Examining the logs for odd activity between the two instances would be VERY handy.

    • Re:Would be handy (Score:5, Insightful)

      by ColdGrits ( 204506 ) on Monday June 16, 2003 @11:15AM (#6212587)
      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?
      • 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.

    • Re:Would be handy (Score:5, Interesting)

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

      • Re:Would be handy (Score:5, Interesting)

        by 56ker ( 566853 ) on Monday June 16, 2003 @11:41AM (#6212910) Homepage Journal
        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.
        • 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 d
          • 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-ti

      • Re:Would be handy (Score:5, Interesting)

        by Surak ( 18578 ) * <surakNO@SPAMmailblocks.com> on Monday June 16, 2003 @11:43AM (#6212949) Homepage Journal
        Wouldn't work where I work. We regularly post files that are several hundred megabytes in size on our FTP server for download or upload them to other servers. You would have to somehow determine *what* wa saturating that uplink for more than 5 minutes and make sure it wasn't a legit connection. That might be a bit more complicated than it sounds, too.

        • Re:Would be handy (Score:2, Interesting)

          by SpaceJunkie ( 579366 )
          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.
      • 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.

    • That would be great (Score:5, Funny)

      by missing000 ( 602285 ) on Monday June 16, 2003 @11:21AM (#6212674)
      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
    • 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>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 a

    • Re:Would be handy (Score:2, Flamebait)

      by ianjk ( 604032 )
      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.

      • Re:Would be handy (Score:5, Insightful)

        by tomhudson ( 43916 ) <barbara.hudsonNO@SPAMbarbara-hudson.com> on Monday June 16, 2003 @12:32PM (#6213515) Journal
        <quote>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?

      • Re:Would be handy (Score:3, Insightful)

        by walt-sjc ( 145127 )
        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.

      • Re:Would be handy (Score:2, Insightful)

        by NicolaiBSD ( 460297 )
        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, maintainabili

        • 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, becau

  • great (Score:5, Insightful)

    by mike_scheck ( 512662 ) on Monday June 16, 2003 @11:12AM (#6212552)
    So now I don't just have to worry about losing my vpn into work in the middle of the night because of some unavoidable packet loss, but also because of some automagic utility that people will throw into place for my benefit. Will the "features" never stop?

    • Re:great (Score:5, Interesting)

      by nadadogg ( 652178 ) on Monday June 16, 2003 @11:16AM (#6212612)
      Well, you could prevent this by assigning a list of "safe" IP addresses that would not call for termination, but merely be logged. This way, unauthorized entry into the network would be stopped, and working from home would be brought to the higher-ups' attention, thereby making you look good :)

      Just a thought, really.

      • Re:great (Score:3, Insightful)

        by ColdGrits ( 204506 )
        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.
        • 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.

          • Re:great (Score:5, Insightful)

            by ColdGrits ( 204506 ) on Monday June 16, 2003 @11:33AM (#6212828)
            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 :)
            • 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

              • Re:great (Score:2, Informative)

                by gid ( 5195 )
                Check out ntop [ntop.org] 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 [kernel.org] for the source. Dang kernel.org has been slower than balls for me lately.

        • Re:great (Score:3, Insightful)

          by BrookHarty ( 9119 )
          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.
          • 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 :-)
            • Exactly, and with GPRS modems, no reason you cant make your office workstation a server. ;)

              Of course, your prob breaking every company security policy.

        • VPN (Score:3, Insightful)

          by apankrat ( 314147 )
          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.
      • 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!

  • Well, that kills that. (Score:5, Funny)

    by Divide By Zero ( 70303 ) on Monday June 16, 2003 @11:12AM (#6212555)
    So much for downloading the trailer for $NEXT_BIG_MOVIE on company bandwidth. We'll have to do work now. Dammit.

  • Oh, I remember this (Score:2, Funny)

    by Anonymous Coward
    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.

  • I have an even better idea: (Score:3, Funny)

    by Sloshed_dot ( 668214 ) on Monday June 16, 2003 @11:13AM (#6212565)
    Just pull the network cable out, then lets see the hacker getting past THAT script!

  • Google Cache of post, and a quick comment (Score:5, Informative)

    by Cruel Angel ( 676514 ) on Monday June 16, 2003 @11:15AM (#6212591)
    here [google.ca]

    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.

  • Google cache (Score:5, Informative)

    by arvindn ( 542080 ) on Monday June 16, 2003 @11:15AM (#6212599) Homepage Journal
    slashdotted with less than 5 comments posted. google cache [216.239.33.100].

  • For Aol Users (Score:3, Funny)

    by jetkust ( 596906 ) on Monday June 16, 2003 @11:18AM (#6212629)
    Wow, now aol users can close aol without using ctrl+alt+delete.

  • Evil bit comes to the rescue! (Score:5, Funny)

    by RyanK ( 338502 ) on Monday June 16, 2003 @11:20AM (#6212664)
    Why not just turn on the 'evil' bit [ietf.org] 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!

  • But what about UDP tunnels? (Score:5, Informative)

    by dpilot ( 134227 ) on Monday June 16, 2003 @11:25AM (#6212731) Homepage Journal
    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.
    • 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.

  • nice first step (Score:5, Interesting)

    by Lumpy ( 12016 ) on Monday June 16, 2003 @11:28AM (#6212772) Homepage
    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!
    • 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.

    • Re:nice first step (Score:5, Interesting)

      by tensai ( 121631 ) on Monday June 16, 2003 @12:21PM (#6213394)
      Check out ntop [ntop.org]. 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.
    • 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
    • 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 [sf.net], iftop, or iptraf.

  • Useful (Score:2, Insightful)

    by globalar ( 669767 )
    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).

  • It the cutter tool itself the news here? (Score:2, Informative)

    by Anonymous Coward
    Two words: "dsniff", "tcpkill". *yawn*
  • 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

  • How to announce software on /. (Score:5, Funny)

    by CoolQ ( 31072 ) <<gro.bulcmoc> <ta> <snitneuq>> on Monday June 16, 2003 @11:37AM (#6212868) Homepage
    How to announce software on /.:

    1) Go to SourceForge [sf.net].
    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

  • Gee, (Score:2, Informative)

    by funwithBSD ( 245349 )
    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.

  • Golden days at my company (Score:5, Funny)

    by lateralus ( 582425 ) <[yoni-r] [at] [actcom.com]> on Monday June 16, 2003 @11:43AM (#6212945) Journal

    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?

    • 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

  • Can of Cron and a Script? (Score:3, Insightful)

    by Line_Fault ( 247536 ) on Monday June 16, 2003 @11:47AM (#6212993) Homepage
    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.
    • 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 length

  • sniffit (Score:5, Informative)

    by wotevah ( 620758 ) on Monday June 16, 2003 @11:48AM (#6213008) Journal
    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.

  • No need for cutter (Score:4, Funny)

    by hhg ( 200613 ) on Monday June 16, 2003 @11:51AM (#6213053)
    See, his webserver can not accept any connections, and I bet he's not using cutter at the moment

  • tcpkill (Score:5, Interesting)

    by pknut ( 571294 ) on Monday June 16, 2003 @11:54AM (#6213081) Homepage
    The 'cutter' program introduced in the article sounds suspiciously similar to Dug Song's tcpkill program (a member of his dsniff [monkey.org] network utilities). In fact, tcpkill appears to be superior because it matches packets via tcpdump expressions, and hence is more versatile.

    • Re:tcpkill (Score:3, Interesting)

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

      • Re:tcpkill (Score:5, Informative)

        by pknut ( 571294 ) on Monday June 16, 2003 @01:14PM (#6213933) Homepage
        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.

  • Easy to hack around! (Score:3, Interesting)

    by Line_Fault ( 247536 ) on Monday June 16, 2003 @11:57AM (#6213129) Homepage
    I'm sure I could get around this by packet capturing on both ends of the connection and dropping any packets that would abort my connection before they are processed by the OS or application.

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

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

    Fantastic!!!

  • I liked this util better the first time... (Score:2, Interesting)

    by Anonymous Coward
    When Route wrote it, and it was called "Juggernaut."

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

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

  • An idea (Score:3, Insightful)

    by d3faultus3r ( 668799 ) <willpNO@SPAMearthlink.net> on Monday June 16, 2003 @12:11PM (#6213274) Homepage Journal
    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.

  • My ISP is using this already (Score:4, Funny)

    by chronos82 ( 680032 ) on Monday June 16, 2003 @12:19PM (#6213363) Homepage
    It seems to me the connection just drops every five minutes, perhaps they have this on their crontab ;)

  • Generic Tools? (Score:2, Interesting)

    by commonchaos ( 309500 )
    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?
    • 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.
    • 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 [packetfactory.net] project. Haven't actually used it, though. For more general packet-generating, sendip can generate arbitrary ip packets.

    • Re:Generic Tools? (Score:2, Informative)

      by dagda76 ( 108490 )
      You can manually do this with hping2.

  • Injecting packets into the connection (Score:5, Informative)

    by zaad ( 255863 ) on Monday June 16, 2003 @01:43PM (#6214273)
    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.
    • 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

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

  • 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 w

Slashdot Top Deals

If a thing's worth doing, it is worth doing badly. -- G.K. Chesterton

Close