Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Cryptographically Hiding TCP Ports 206

Posted by CmdrTaco from the can't-see-the-ones-for-the-zeros dept.
JohnGrahamCumming writes "The shimmer project implements a cryptographically-based system for hiding important (e.g. SSH) open ports in plain sight. By automatically forwarding from a range of ports all but one of which are honeypots and by changing the ports every minute only a user knowing a shared secret can determine the location of the real SSH server."
This discussion has been archived. No new comments can be posted.

Cryptographically Hiding TCP Ports More

Cryptographically Hiding TCP Ports

Comments Filter:

  • Neat in theorey, imho. (Score:4, Interesting)

    by c0l0 ( 826165 ) * on Tuesday January 08, 2008 @10:14AM (#21954142) Homepage
    Sounds like a neat hack indeed - however, I doubt its practical feasibility.

    I manage quite a bunch of remote systems, each one equipped with OpenSSH for adminning and OpenNTP for syncing system clocks, yet their local clocks still drift a little over time; sometimes easily up to quarter a minute or more. So if the interval of changing ports is too narrow, one would eventually lock himself out of the remote system because of unsynced clocks and a wrongly computed destination port. Sucks big time.

    ... rubbing the crytsal ball even more, I can forsee that if VMWare doesn't fix its abhorrent clockskew problems on Linux guests, and the hype^Wtrend towards virtualization continues, it's going to be a real mess for anyone who's willing to try such a setup in said virtualized environments - though I'll save that rant for a more fitting time, I guess ;)

    At the end of the day, choosing some non-standard port in the 30000+-range for sshd (mostly to save logrotate some work by keeping futile scriptkiddie-login-attempts out, but anyway) and turning off password-authentification in favour of pubkeys still provides enough security for just about anybody. Services that don't allow for such measures may be tunnelled over SSH (or e. g. OpenVPN, for more demanding protocols/apps) with ease, again rendering the project's idea somewhat moot to me.

    • Re:Neat in theorey, imho. (Score:4, Informative)

      by JohnGrahamCumming ( 684871 ) * <.gro.cgj. .ta. .todhsals.> on Tuesday January 08, 2008 @10:15AM (#21954160) Homepage Journal
      Clock drift is an issue, hence the fact that three overlapping minutes are kept active at once.

      • Re:Neat in theorey, imho. (Score:4, Informative)

        by egomaniac ( 105476 ) on Tuesday January 08, 2008 @10:18AM (#21954204) Homepage
        I saw that, but I agree with GP that this won't fly in practice. Even with NTP servers it's too easy to have your systems end up out of clock sync, so now you're blacklisted and don't know why or how to fix it.

        • Re:Neat in theorey, imho. (Score:4, Interesting)

          by AvitarX ( 172628 ) <me&brandywinehundred,org> on Tuesday January 08, 2008 @10:34AM (#21954428) Journal
          Perhaps a port knocking pattern on a separate set of ports that are never used otherwise.

          It should theoretically be impossible to snoop the port not (by virtue of it not being used), but it will be there if and when it is needed.

          You could even have it as a seperate 24 hour updating set, long enough that no one should fail it, but still makes snooping it fairly useless.

          Of course with up to 3 minutes to used snooped port pattern it is not completely invisible.

          If security was super high, and there were a limited number of people needing to access, you could have the login give you an 8 digit code and you would enter that into the client next connection, and it would use that to pick the ports to knock. This would make it impossible to access SSH even after snooping an exchange.

          It could also wait 3 minutes before allowing another connection, in the interim running a daemon that accepted and login and spit out "please wait 3 minutes" instead of a real prompt.

          • Re:Neat in theorey, imho. (Score:4, Interesting)

            by Brian Gordon ( 987471 ) on Tuesday January 08, 2008 @11:32AM (#21955288)
            I don't know, I don't like this at all. It's obviously abuse of TCP/IP, and there's no reason to try to mask what port it's on when SSH is a secure protocol anyway. Also I have my doubts that many OSes TCP/IP stacks can handle so many transient connections, or that it would be implementable at all (cough windows)

            • SSH is a secure protocol anyway.
              Just because the SSH protocol offers security services such as authentication and privacy doesn't mean that all implementations are without defect [slashdot.org].
            • The protocol is fine. It's the lusers who setup accounts like upload/upload and forget about them that are the problem.
              • Exactly. Rummaging through the userlist on our company's website, I found hundreds of unused accounts, bogus accounts, accounts that somehow use the md5 of "password" and tons of other stuff. Yes, I know, we didn't use salted passwords, I don't know why but we're cleaning up already.

                The new authentication is much simpler and incredibly secure from my perspective: use a personal password concatenated to a 6-digit number displayed on a separate keyfob-style authentication token. This number changes every 30 s

              • Re: (Score:2)

                by Lehk228 ( 705449 )
                there is nothing wrong with upload/upload, it's allowing the upload account to read it's own files that is the problem. if all upload can do is blindly send data the worst possible attack is filling the disk, and disk quotas exist already so that problem is effectively zero.

            • Re: (Score:2)

              by cmat ( 152027 )

              I don't know, I don't like this at all. It's obviously abuse of TCP/IP, ...

              No reason it has to be implemented in TCP; coudl easily be implemented as UDP "knocks". Alternatively, if one wanted a more robust solution, you could implement a service that opens a range of ports, and you "knock" the ports in a certain order and send a certain set of data during each known via regular TCP. Incidently, the point behind port knocking is to NOT have your service (SSH in this case) actually listening on whatever port until you "knock" correctly.

              • Yeah but that's stretching software ports way beyond what they were meant to do. Instead of knocking on different ports, why not just have a daemon listening on ONE port like the system was designed that silently takes a password (or a series of port numbers if you really wanted to be exactly the same) and if it's right then forwards you to ssh or whatever you're actually trying to connect to? Using the system like it's designed, and gives attackers no idea that they're even connected to a used port

            • Re: (Score:2)

              by erc ( 38443 )
              Abuse? What are you talking about? Port-agile programs aren't new, just not well-known. And there's *plenty* of reason to mask what port you're running a listener on - to avoid getting your server hacked because you're running **TP listeners on well-known ports that script kiddies can find easily. Most UNIX-like operating systems can handle a fair number of inbound connections easily (think *BSD).

          • If security was super high, and there were a limited number of people needing to access, you could have the login give you an 8 digit code and you would enter that into the client next connection, and it would use that to pick the ports to knock. This would make it impossible to access SSH even after snooping an exchange.

            It could also wait 3 minutes before allowing another connection, in the interim running a daemon that accepted and login and spit out "please wait 3 minutes" instead of a real prompt.

            Or you could use public key authentication for your SSH security rather than just passwords. I have a 1 in 10^8 chance of guessing your 8 digit code. You have a 1 in 2^1024 (often less) chance of guessing the correct private key. Combine that with blocking brute force attacks [bgnett.no] and that's all the security you practically need.

          • Re:Neat in theorey, imho. (Score:5, Insightful)

            by mr_mischief ( 456295 ) on Tuesday January 08, 2008 @01:30PM (#21957282) Journal
            I used to run a network with an ssh-only server. All it had facing the world as an actual service was OpenSSH's sshd on a fixed nonstandard port. It also had two fixed and four randomly hopping honeypot ports that added any /24 network that hit them to a 24-hour firewall DROP rule.

            Once someone logged into that server using their own key or pass phrase, the only command they could run was ssh. All the other servers in the network only allowed ssh in from that ssh box, and by policy their keys and pass phrases had to be different on the ssh server than on the internal boxes. Each failed attempt at logging in caused a 5-second wait, and after three a 12-hour wait.

            Is it as secure as having the real port hop around and synchronizing that with the clients via a shared secret? Well, I guess that depends on just how secret the shared secret is. We never had any problems, though, and the only thing our people had to take with them were the name of the server, their private key or passphrase, and the proper port to use. They usually didn't have much problem remembering three of those, and the you have the same issue with private keys no matter what (that being that they're only as secure as the system on which they are stored).

            There's probably some security advantage to the solution presented in TFA, but I'm just not sure it's worth the extra coordination hassle compared to people's home-grown solutions. It seems like every fifth post in the comments is about alternative ways to safeguard ssh ports. Surely not knowing which someone is using provides a bigger hurdle than getting past any single one of them. When you're practicing security by obscurity, which is what this really boils down to, then being more obscure is probably a good thing.

            The best fix for brute force is the old idea you mention of an enforced wait between attempts. It's a pain when you're locked out of a server you're legitimately allowed to use, but it's very useful to keep brute-force attacks down. Giving a couple of chances with a short wait and then imposing a much longer once after 2 to 5 tries seems to be a pretty good balance.

            • The best fix for brute force is the old idea you mention of an enforced wait between attempts. It's a pain when you're locked out of a server you're legitimately allowed to use, but it's very useful to keep brute-force attacks down. Giving a couple of chances with a short wait and then imposing a much longer once after 2 to 5 tries seems to be a pretty good balance.

              Add to this a nokia phone and a data cable, gnokii, and a script that when it receives a SMS from a specific phone number with an IP address

            • The best fix for brute force is the old idea you mention of an enforced wait between attempts. It's a pain when you're locked out of a server you're legitimately allowed to use, but it's very useful to keep brute-force attacks down. Giving a couple of chances with a short wait and then imposing a much longer once after 2 to 5 tries seems to be a pretty good balance.

              Which would be so easy to implement in openssh. Seems silly not to have it there as a standard feature.

        • Re: (Score:2)

          by cowbutt ( 21077 )
          If this is a problem, write a wrapper script that uses ntpdate to immediately set the clock from the same NTP server as the servers you're trying to connect to. Not great for multi-user machines, but should be fine for desktops and other single-user machines with a modicum of care (e.g. making sure 'make' isn't running whilst you do so...)

        • Re: (Score:2)

          by Fweeky ( 41046 )
          Or, you could be a bit more proactive about making sure the things you depend upon are working and set up a little system monitoring so you know when things fail.

        • Re: (Score:2)

          by erc ( 38443 )
          Even with NTP servers it's too easy to have your systems end up out of clock sync
          Really? How often do you run NTP? I've run it once a day for 20+ years and I've *never* had my server out of sync for more than a second or two between synchs. Maybe you're running crappy hardware?
      • Clock drift is an issue, hence the fact that three overlapping minutes are kept active at once.

        But if you have ever used one of those RSA generators you will find that it will sometimes take three or four attempts before connecting to your VPN. This is even with the valid pass-key.

        Sometimes being too smart is the wrong answer.

      • It turns out that clock drift is no longer an issue. There is Open Source clock sync software that can get you into the microseconds range of accuracy across the internet using no other hardware than your microprocessor's clock. TSClock [google.com]

    • Re:Neat in theorey, imho. (Score:5, Interesting)

      by AndyST ( 910890 ) on Tuesday January 08, 2008 @10:22AM (#21954268)

      OpenNTP for syncing system clocks, yet their local clocks still drift a little over time; sometimes easily up to quarter a minute or more.
      Okay two things most people don't get when ntp is involved.

      1. An ntpd not only syncs time, but adjusts the running speed of the kernel clock. Otherwise it would be nothing more than a ntpdate cronjob.

      2. Under GNU/Linux, the local clock may be used to initialize the kernel clock, but those two run independently of each other until shutdown (or manual set). Only then the local clock is set to the kernel time, regardless of what the local clock was doing all the time.

      • Re: (Score:2)

        by Minwee ( 522556 )

        Something else that many people don't get where OpenNTPD is involved is that it is not the same as ntpd. I haven't kept up with openntpd development recently, but the last time I checked it only implemented the SNTP protocol and was noticeably broken in how it implemented many parts of NTP.

        It's still fine for what it does, but don't confuse it with a real NTP server.

    • Re:Neat in theorey, imho. (Score:5, Funny)

      by Rob_Ogilvie ( 872621 ) <rob@axpr.net> on Tuesday January 08, 2008 @10:36AM (#21954474) Homepage
      If your ntp-enabled systems are drifting 15 seconds out of whack with each other, you have bigger problems than additional SSH security.

      • Re: (Score:2)

        by jandrese ( 485 )
        IMHO, this is a problem with NTP. It's really hard to figure out if it's working or not and the documentation is obtuse and spends page after page going on about security features nobody wants to deal with (it's hard enough to get NTP working without the security stuff). While I admire the difficulty in getting clocks synchronized down to the picosecond over the internet, some work on the UI would be greatly appreciated.

      • Re: (Score:3, Informative)

        by spun ( 1352 )

        If your ntp-enabled systems are drifting 15 seconds out of whack with each other, you have bigger problems than additional SSH security.

        Yes, it's called Linux on VMWare. There are workarounds, but they involve recompiling the kernel, setting boot options, and VMWare tools settings. Without the workarounds, even with ntp enabled, clocks can skew on the order of seconds every minute. I've seen systems get a minute out of whack in under ten minutes. With some settings, ntp actually makes it worse, as ntp and VMware perform dueling clock-skews.

        • What flavor of linux (as guest) are you seeing this with?

          • Re: (Score:2)

            by spun ( 1352 )
            We use SLES & RHEL, and it happens to both. Worse on SLES, due to the clock settings in the kernel as shipped by Suse. Also happens on every other distro I know, and the *BSDs. Basically, the fix is to put a "clock=pit" or "clock=pmtmr" line into your boot conf (for 32 bit systems, whichever works best, for 64 bit systems, you need "notsc" instead), recompile the kernel with no more than 100mhz timer interrupt rate, and set the VMWare tools option "tools.syncTime = TRUE" using the tools GUI, or edit the
    • The clock drift issue is fairly easy to solve. Just make the secure machine a time server, serving its own time. The client machine first syncs to the server, then proceeds with the port hopping ssh.

  • "Obscurity" tag is misleading (Score:5, Insightful)

    by egomaniac ( 105476 ) on Tuesday January 08, 2008 @10:16AM (#21954172) Homepage
    I see this got tagged "obscurity", but this isn't security-through-obscurity. If you actually RTFA, you'll see that hooking up to the wrong port automatically blacklists you. So it's not like you can just try different ports until you find the right one -- any attacker without the shared secret will almost immediately be blacklisted, assuming that they have to reconnect a few times (e.g. to try different SSH passwords).

    Still, requires a shared secret plus synchronized clocks, and any mistake automatically blacklists you. Sounds ridiculously impractical IMHO.

    • Re: (Score:2, Informative)

      by Loibisch ( 964797 )

      [...] and any mistake automatically blacklists you. Sounds ridiculously impractical IMHO.
      Yup, anything that would potentially that easily deny me access to my own machine won't get installed.
      It's all fun and games till you've locked yourself out from an only remotely accessible server...
    • It's not that different a concept from Frequency hopping [wikipedia.org].

      • Re: (Score:3, Insightful)

        by mea37 ( 1201159 )
        There are substantial differences. Enough so that, while the sound similar, they are really nothing alike.

        Frequency hopping has a much broader domain to "hop" across.

        Frequency hopping requires the communication to keep hopping even after it's established. Not only can't you connect without the key, you can't even keep a conversation going without the key. You can't hear or be heard at all, in fact.

        To someone without the key, frequency hopping "looks like" random noise. This works becuse there is random

        • Re: (Score:3, Informative)

          by russotto ( 537200 )

          To someone without the key, frequency hopping "looks like" random noise.

          No, it doesn't. It looks pretty much like you'd expect -- spikes in power more-or-less uniformly (but discretely, not continuously) distributed over some part of the spectrum.

          Check this link for pictures:

          http://www.metageek.net/docs/sample-recordings/video-baby-monitor [metageek.net]

          • Re: (Score:2)

            by Lehk228 ( 705449 )
            that's a baby monitor.

            the fact that a baby monitor implements FH very poorly does not so much reflect on FH technology as much as it does on this particular product.

    • Re:"Obscurity" tag is misleading (Score:5, Interesting)

      by morbiuswilters ( 604447 ) * on Tuesday January 08, 2008 @10:25AM (#21954298)
      Actually, it seems possible to lock out legitimate users as well, by sending them to a URL like http://example.com:12345/ [example.com] Since it only appears to be operating at the TCP layer, requests from a web browser would accomplish the goal of blacklisting a target IP. If port 12345 was one of the honeypots at that time, the legitimate user gets blacklisted. Throw it on a malicious web page that uses several XMLHttpRequests to try various ports and you have a pretty good shot at locking the user out.

    • Re:"Obscurity" tag is misleading (Score:5, Interesting)

      by sumdumass ( 711423 ) on Tuesday January 08, 2008 @10:25AM (#21954300) Journal
      Well, this is still security through obscurity. You are in essence hiding a port within many and then attempting to enforce rules based on the many. the problem with security through obscurity is that if the hacker gets lucky then nothing is secure again.

      So to keep this in the same context of the article, what if the hacker picks the correct port right off the bat? No black listing, no honey pot, no security other then what was already there without the system. but better yet, what if there was 1000 ports operated in this manor, Could I effectively find the right port by using 1000 zombie machines to connect and then see the response on a second connect attempt to see when the blacklisting comes about? I'm willing to bet that the first connection that survived the longest without black listing is the correct port. So now I can attempt to exploit the server on that port to gain access.

      I would think it adds a level of security and might stop the average script kiddie but I'm not sure that it is a level of security beyond the equivilent of security through obscurity.
      • What exactly is the difference with password encryption? Would you say that password encryption is also security through obscurity? Because all the points you raise to argument that this works due to obscurity also apply to password encryption, IMHO.

      • Re: (Score:3, Insightful)

        by GodfatherofSoul ( 174979 )

        Well, this is still security through obscurity.

        In that case, isn't cryptography just "security through obscurity" since the real key is buried in known iteration of numbers?

  • Isn't this port knocking (Score:5, Insightful)

    by crow ( 16139 ) on Tuesday January 08, 2008 @10:18AM (#21954202) Homepage Journal
    Isn't this essentially the same as port knocking? Actually, it's not as good, as you can get lucky with this. With port knocking, you have to send a secret sequence of packets (possibly one that changes with time) before the port is available for your host to connect to. And you send UDP packets, so there's no indication from the server that the machine is even powered up unless you are successful. And, of course, there's the variation where you send a single UDP packet with an encrypted payload that instructs the server to open up a port for you.

    So while this is a little different, it's inferior.
    • I'd imagine port knocking is easier to implement, as you don't have to keep changing the port an app is listening on. You could cryptographically change the knocking sequence, which would be far easier than the solution described here.

    • Re: (Score:2, Informative)

      by AndyST ( 910890 )

      And you send UDP packets, so there's no indication from the server that the machine is even powered up unless you are successful.
      Except for the missing dst host unreachable [wikipedia.org] from the last hop before the target. "Stealth"/DROP instead of "Closed"/REJECT add nothing to security. Same with not replying to pings. People listen to Steve Gibson way to often.

      • Re: (Score:3, Interesting)

        by Dr. Manhattan ( 29720 )
        I did something a lot simpler, using TCP/IP, and much easier on CPU requirements. (I use it on a 16MHz M68K machine.) See the link in my .sig...

        • Re: (Score:2)

          by caluml ( 551744 )
          I suspect that the vast percentage of viewers to this site are Anonymous/not logged in, and hence can't see your sig. So here's the link: SSH not secure enough? Try Ostiary [homeunix.net].

        • Re: (Score:2)

          by kaoshin ( 110328 )
          I never heard of port knocking before and this program looks awesome. I used a similar procedure to this several years ago I think. I had set up a procmail recipe to accept a passphrase which I rotated daily and would print and bring with me to work each day. When the event was triggered it would enable a firewall rule that allowed connections to my webmin port from my IP at work. If no connection was established within x amount of time then the rule would turn off. If successfully logging into webmin

    • Re: (Score:2)

      by yarbo ( 626329 )
      If you can sniff some traffic for a successful login attempt you can learn how to defeat the port knocking system. With this system, if you sniff traffic you'll only be able to attempt to login for one minute before your information is obsolete. If I understand both correctly, that is...
  • First came exotic ports (as if using 922 instead of 22 was security -- it just throws off scripted attacks), then port knocking, and now this ?

    Whatever happened to just plain good passwords (including a little helper for good measure [fail2ban.org]), TCPWrappers, sensible firewalling and ssh private/public keys?

    I could understand this type of security with more brittle services, things that can be hacked, but this is IMHO going way oervboard.

    • What are these passwords, kemo-sabi? (Score:5, Interesting)

      by igb ( 28052 ) on Tuesday January 08, 2008 @11:19AM (#21955124)
      Surely passwords are the wrong answer. I carry the contents of .ssh from my office machine on a tiny USB thingie from pqi. Very handy when I was at my father in law's last month. I also have Windows binaries of ssh on it. Mount the USB disk, use the id_dsa file from it as my key, job done. Yes, a keystroke logger will get my passphrase, but won't get the key. A very targeted attack would be needed. If I were worried about that, I'd tie our SSH listener into our SecureID infrastructure, but that seems a bit keen.
    • Passwords won't help you avoid traffic shaping and 'no server' rules from your ISP, but automatically changing port numbers and servers that no longer 'exist' when the ISP's batch process gets around to connect to them to look for 'unauthorized use' will.
    • People use exotic ports as a security measure? I've always done it to keep my log files from becoming bloated from script kiddies attacks. When I see something out of the ordinary in my log files now I can be reasonably certain it is more serious than an automated script.

  • Not so smart, though. (Score:3, Insightful)

    by VincenzoRomano ( 881055 ) on Tuesday January 08, 2008 @10:33AM (#21954424) Homepage Journal
    Well, if you use cyphers just to shuffle the TCP ports ... plain SSH with public key authentication would work with the same level of security.
    In both cases you need to keep a crypto key secret otherwise you'll end with secuity hole. A shuffled one, but still a hole.

  • Complete Waste of Time (Score:3, Insightful)

    by Chris_Jefferson ( 581445 ) on Tuesday January 08, 2008 @10:42AM (#21954564) Homepage
    There seems to be two reasons this might be useful:

    1) Another piece of information needed
    2) If your SSH server has a buffer overflow or similar in it.

    And both seem useless.

    1) You are surely going to keep your SSH key in the same place as the code to access this thing. If you wanted a similar level of security, why not hide your SSH key in two pieces?
    2) Now we have to completely test two programs instead of one.

    Seriously, what security problem is this supposed to fix?
    • Reason 1 is, as you say, useless; if you worried about it you could just enforce long-enough passphrases.

      But your Reason 2, SSHd bugs that might be security holes, is the problem this is trying to address. Various deployed-in-the-real-world SSH implementations have had security holes, and crackers and skript kiddies do go hunting for them, and even if your implementation has been patched around the existing holes, you can still get your logfiles cluttered up with scanning events, plus crackers are always

  • And this is better than classic port-knocking how?
  • I can see a problem, if you use a sniffer and capture enough packets, should be easy enough to see encrypted session on a single port for a length of time, now add in that true randomness doesn't exist in the computer world unless using radioactive decay or some solution, it should be doable to figure out what ports are being used for the SSH connection. I agree with one reader though, this wouldn't be needed if using best practice methods for passwords, firewalls, IDS/IPS, etc.

  • not as good as port knocking (Score:3, Informative)

    by vrmlguy ( 120854 ) <samwyse AT gmail DOT com> on Tuesday January 08, 2008 @11:07AM (#21954952) Homepage Journal
    There are 16 ports being listened to, so an attacker has a 1-in-16 chance of finding the correct port. Knocking, using 16 ports and just three knocks, gives an attacker a 1-in-4096 chance of getting through. If you changed the knock pattern every minute, then I could see something like this being useful, but as presented it seems less secure.
    • I take it it never occurred to you to just increase the number of ports and knocks? You have 64k to choose from. Go nuts.

      • Re: (Score:2)

        by Lehk228 ( 705449 )
        the point is that no matter how many ports you use, just 3 knocks will be far more secure, and there is no need to auto-ban with port knocking.

    • Re: (Score:2)

      by raddan ( 519638 )
      Even better is using authpf [openbsd.org] to modify the firewall's running ruleset. This way, you get the advantage of portknocking, since the protected port is not open until the user does their little dance with the firewall, and also the advantage of a real authentication system, since authpf uses SSH to authenticate the user. Because the authentication part uses SSH, you can plug in any authentication source you want, via GSSAPI, or /etc/passwd or whatever. We use SSH public keys, and the protected ports in questi

      • Re: (Score:2)

        by vrmlguy ( 120854 )
        In my mind, the advantage to port knocking is that no data payloads are ever transfered; the authentication is done entirely via the timing of TCP control packets. This eliminates the possibility of, for example, buffer overflows in the program performing the authentication. Any vulnerability in the authpf program (or its authentication source) would potentially allow an attacker to perform arbitrary modification of the firewall rules. That would be a bad thing.

        • Re: (Score:2)

          by raddan ( 519638 )
          But you also have to worry about replay attacks with portknocking. This is not a problem when you use SSH.

          • Re: (Score:2)

            by vrmlguy ( 120854 )
            I don't know anyone who uses port knocking to connect to an unencrypted channel. http://www.portknocking.org/ [portknocking.org] says, "There will be situations in which port knocking is ideally suitable, such as remote administration provided by a latent, on-demand SSH service. In other cases port knocking is not the right answer." So, I don't see a replay attack as being that likely.

            As I said in my top post, I like the article's idea, just not the implementation. For instance, use 1,000 ports and change the three-knock c
  • The largest problem w/ the proposed system is that, even though it may make the active port difficult to find, it leaves a large footprint. The open ports may be implemented as honeypots, but if you aren't using the standard tcp stack library it doesn't inconvenience the attacker but instead tells him the target exists. Any vulnerability in the implementation can then be exploited.

    I have an alternative proposal. Have a udp or icmp service where, before connecting to a tcp server port, a client must send

  • Distributing Cracking (Score:4, Interesting)

    by Applekid ( 993327 ) on Tuesday January 08, 2008 @11:14AM (#21955046)
    This approach pretty much assumes that the brute-force attack wouldn't be happening from many different computers on many different IP addresses each attacking an individual port. If we're talking 1 port in 30000 then all you need is a botnet at least as large as 30000 machines. All except one will waste time with their respective honeypots but one will be getting the job done.

    I wonder if the DDoS would bring the server to its knees first, though. :)
  • Reminds me of something I wrote once that listens on a UDP port that moves on a time based algorithm, you send a signed message to the UDP port and if your key is right, it opens a random port and tells you what that is. You must be in the auth keys/users list and you must know the time algorithm- otherwise the box sits quiet like it was never there.
  • Figure out or guess the internal LAN subnet, create your (thousands of) fake TCP-packets and just hit random ports on a server running this. Before you know it everyone will be black-listed and someone has to go locally to the server to clean this up.

    Mind you, an IDS will probably see this activity and if there's an IPS it may be able to block the fake packets. Mind you, most places don't have that.

    • I dunno, man, one of the first things in my iptables rules is to drop all packets for/from the internal network which appear on the external interface.

      I'll bet a LOT of routers are built the same way.
  • This is indeed a nifty hack, however it seems a bit impractical and overly complicated way of protecting SSH.

    I use the software script Denyhosts which runs whenever an SSH connection comes into the system
    http://denyhosts.sourceforge.net/

    You simply set the Account / IP address lockout threshold and so after X number of failed login attempts the system will put the connections source IP address into the hosts.deny file. The IP address stays there until eventually released, or it can stay there foreve

  • Time to break out infinities (Score:3, Interesting)

    by mattr ( 78516 ) <mattr@telebodGIR ... minus herbivore> on Tuesday January 08, 2008 @12:57PM (#21956700) Homepage Journal
    This may sound like tongue in cheek but I assure you I'm serious.

    Clearly some aspects of computers not as sexy as high speed graphics lag behind, as some examples the number of bots, the number of ports, the number of concurrent connections (10K problem) and the data transfer speeds possible by consumer hardware, especially when divided by storage media size, all seem to be relatively small numbers still. A ton of bots can game this game, etc.

    Obviously it is time to break out the heavy math. First imagine if instead of having only measly thousands of ports you could use a floating point number to designate a port. It's not like we have thousands of ports in hardware right? Meaning virtual port addressing. Needs a big botnet to get through that. You could make the system answer on any port, or only answer on those which are being used. Well floating point still may not have a lot of significant bits to hack, so time to break out the math.

    I think Rudy Rucker could have some good ideas for computer security. Not that I'm a mathematician or anything, but if you read his latest book minus 1 there are plenty of descriptions of navigating infinities. If you had a transfinite number of ports I think you might even be able to prove that the obscurity is more secure than anything else in the real world. So while it is a bit of a ticklish idea I'd very much like to see a math-minded hacker think about what would be involved in designating such a number or abstract symbol representing it and using that as a destination address. Thank you.
  • why not simply have one fixed known port that hosts an NTP Server serving the Servers local time... the SSH Client would connect to that first and use it to calculate a time offset from the server to the client
    That way it wouldn't matter if the server, the client, or both are totally out of sync with reality!

    Still, i don't see any advantage of this to simply using a fixed port that blacklists any client after a set number of failed login attempts. I mean if the attacker tries to guess he would get blackl

Slashdot Top Deals

In space, no one can hear you fart.

Close