Cryptographically Hiding TCP Ports

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

Comments

Neat in theorey, imho.

[c0l0]

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.

[JohnGrahamCumming]

Clock drift is an issue, hence the fact that three overlapping minutes are kept active at once.

Re:Neat in theorey, imho.

[morbiuswilters]

I agree that it's pretty nifty, but seems like a lot of work that is more failure prone than just using a firewall to exclude invalid IPs.

Re:Neat in theorey, imho.

[egomaniac]

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.

[AndyST]

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:Neat in theorey, imho.

[AvitarX]

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.

[Anonymous Coward]

... 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 ;) Try booting the kernel with notsc, this will fix your timeskew issue.

Re:Neat in theorey, imho.

[Rob_Ogilvie]

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

Re:Neat in theorey, imho.

[Anonymous Coward]

Cant you use OpenNTP on one server to get the proper time & get all the others to use that server? I realise this might not be as fault tolerant as other solutions but if your clocks are out by up to a minute, I'd think missing a few time updates isn't that important anyway.

Re:Neat in theorey, imho.

[thatseattleguy]

There are programmatic ways to mitigate the clock-skew problem. To give just one example off the top of my head, if the remote user attempts to connect to the port just "behind" (in time+crypto sequence) or just "ahead" of the current "correct" port, they could get a waiver - not a full connection, but not an autoblacklist, either. That wouldn't necessarily solve the problem completely, but would allow other opportunities/methods of authenticated assuming that both ends can recognize at that point that there's a clock-skew issue. (details left to the reader and implementer on that)

I believe that SecureID and other systems that require a token produced by a crypto device implement something like this, where there's a "greylist" to allow semi-synced remote users another shot at authenticating.

Re:Neat in theorey, imho.

[BuckaBooBob]

Port Knocking is the way to go. With no ports answering alot of the Port Scan "Network Spam" would go away.. They should stop trying to invent a new wheel for everyone to ride and focus on a way to use a passphrase to determine what ports should be probed in what order with what time span. Leaving ports open Just encourages hackers to continue to probe your machine. Honeypots or no..

Re:Neat in theorey, imho.

[Wornstrom]

or just use tcp_wrappers...

Re:Neat in theorey, imho.

[cowbutt]

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:Neat in theorey, imho.

[JohnGrahamCumming]

Your passphrase to determine the ports is pretty much what tumbler does.

Re:Neat in theorey, imho.

[camperdave]

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.

Re:Neat in theorey, imho.

[Anonymous Coward]

By 'local clock' do you mean the machine's clock, which displays the time in the BIOS menus?

I have 20 Dell Poweredge 1950 machines. The time drifts by several minutes each day. I'm trying to figure out if my system's time is drifting due to the machine, or due to a Linux issue.

Re:Neat in theorey, imho.

[Midnight Thunder]

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.

Re:Neat in theorey, imho.

[Sancho]

Port knocking is neat, but it suffers from sniffing attacks. Anyone who can sniff the connection can determine the sequence being used. You can use something like one time passwords to make a new set of sequences each time, but then you have to calculate those sequences (one of the neat things about port knocking is that you can do it from pretty much any machine--not just one with a special client.)

Honestly, people spend way too much time worrying about hiding their SSH ports. Use public key authentication and disable password authentication, and no one's going to brute-force their way in.

Re:Neat in theorey, imho.

[Brian Gordon]

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)

Re:Neat in theorey, imho.

[jandrese]

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:Neat in theorey, imho.

[nacturation]

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 and that's all the security you practically need.

Re:Neat in theorey, imho.

[cp.tar]

You can set Linux to sync your hardware clock to kernel clock.

And usually it's a hardware issue; hardware clocks are quite often rather crappy.

Re:Neat in theorey, imho.

[AvitarX]

The 8 digit code would simply be to access the SSH, you could still use a private key to authenticate.

The whole shifting port knocking pattern is to protect from flaws found in whatever implementation of SSH, not to replace a login.

The private key does not hide the existence of SSH even existing on the server.

This is nothing I would ever implement, but I could see why it may be desirable to have essentially zero open ports on an external machine, but still be able to administer it remotely. Something short of an air gap, but more secure that keep up to date security. Didn't they use an SSH flaw in the Matrix to break in?

I would think that a port knocking daemon could be kept simple enough to prevent buffer overflows, and if all ports are high I don't think it would need to run as root either.

Re:Neat in theorey, imho.

[Anonymous Coward]

Yes, but the point here is that your 'server' is supposed to be secret. It won't have an open NTP port.

Re:Neat in theorey, imho.

[spun]

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.

Re:Neat in theorey, imho.

[MadMidnightBomber]

The protocol is fine. It's the lusers who setup accounts like upload/upload and forget about them that are the problem.

Re:Neat in theorey, imho.

[mr_mischief]

I concur. A good way not to stress a public NTP server is to set up a private one. You also get closer synchronization over a LAN than over the public Internet. It also reduces your vulnerability profile if only one server makes the connection to the outside, and the rest only connect to it for time. Having a second for fail-over might be wise if it's really important, but if all you're running on a server is NTP then you're probably down to just hardware failure to worry about.

Any server you have that's not fully maxed on load and that can handle the quite small additional security risk of serving NTP to the local network only would be fine, or you could use an old Pentium 100 or such that does nothing but serve NTP.

The local NTP server grabs its update every day (or every 12, 8, 6, or 4 hours) from the public server. There's really no need to hit the public time server too often because you're mostly concerned with synchronization within your network anyway. You can then sync your local machines all to your private NTP server as often as you like, even down to once a minute if you're really that concerned. Using ntpd should work better since it adjust the system clock according to past skews and gets better over time. Using ntpdate would be passable if you run it often enough that your skew isn't significant to your application, but ntpd is still better if you can stand running the daemon on each server.

My preference is to use an old machine to do nothing but get time from the net and provide it to the local network. I always locked mine down in every other way but allowing ssh in, and it only allowed ssh from within the local network. No ssh back out from it, no compilers, and more could be done if you're really paranoid.

There's also PTP for some applications that require better resolution than NTP. I'm not aware of many people actually using it on regular servers, though. Being synchronized within a couple hundred microseconds is usually more than adequate.

Re:Neat in theorey, imho.

[Anonymous Coward]

I agree there.. there are probably more practical and effective ways to attack that problem. Besides when working with a lot of systems and with a lot of connections it is probably more of a hassle than anything else. Also, what if I just use their 16 or 6 (or whatever number of ports) all at once ? Probably not that difficult to come up with something for that. Script kiddies are easy to take care of, the sophisticated well thought out attacks are the ones that one has to worry about. I think it is better to anticipate and effectively respond to an attack, rather than hide from it.

Re:Neat in theorey, imho.

[HaloZero]

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

Re:Neat in theorey, imho.

[F1Rumors]

The timing problem has been resolved already -- almost every VPN solution I have used comes complete with a 'SecureId' card, which generates a number that changes every minute. Not only is it unique to the actual user, but the drift is so low that the one I have had for over 4 years is still good to a second or so.

Re:Neat in theorey, imho.

[mr_mischief]

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.

Re:Neat in theorey, imho.

[Anonymous Coward]

It is not difficult IMHO, just takes about 15 minutes of reading. You do not need a UI, you set it up once and forget it.

Re:Neat in theorey, imho.

[somersault]

You mean the Matrix where that guy kills a bunch of robots with his mind? Hardly the most realistic of movies to choose. Unless they were hacking the Matrix within another Matrix :o The computing power in the outside Matrix must be pretty good. I wonder if it could get a score of 6 on Vista?

Re:Neat in theorey, imho.

[spun]

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 conf file directly. Also, use the burst/iburst mode in ntp, if you have your own server (you don't want to go bursting on a public server!)

Re:Neat in theorey, imho.

[AvitarX]

This page http://www.theregister.co.uk/2003/05/16/matrix_sequel_has_hacker_cred/ has the info on it.

The point was that there were real exploits in SSH, and I used the Matrix because I thought most people would remember the big hub-bub when it was indeed shown fairly accurately in a movie. I also thought using a real example from an obvciously false movie would be entertaining, but I am a fairly dull person, so I guess I shouldn't be shocked if it is not.

Re:Neat in theorey, imho.

[cmat]

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.

Re:Neat in theorey, imho.

[phoenix321]

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 seconds in sync with the server. This way, everyone can select their own personal luser password and still be secure. I'd recommend this for all high-security needs, as it presents pretty good two-factor authentication with no client side requirements other than eyes and a keyboard and no software-based attack vectors. (Compared to smartcard readers, certificates etc.)

The only way to steal login should be social engineering or plain violence.

Re:Neat in theorey, imho.

[Anonymous Coward]

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. pam_abl http://sourceforge.net/projects/pam-abl/ and let them try ;)

Re:Neat in theorey, imho.

[Nonsanity]

One could have a known port that only shares the internal clock time for the server. Then any client could sync as needed, as long as they know the hop sequence.

The basic idea is using the same sort of security that frequency-hopping radios rely on. They have their own systems for syncing, some of which might be useful for this network security technique.

  ~ Nonsanity

Re:Neat in theorey, imho.

[Fweeky]

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:Neat in theorey, imho.

[Brian Gordon]

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:Neat in theorey, imho.

[Minwee]

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.

[Anonymous Coward]

Running ESX server 3.5, I have to do none of these things for CentOS 5.1 or Fedora 6 guests. All I needed to do was run ntpd on the host, make sure VMware Tools was running in the guest, and click the "synchronize guest time with host" checkbox. I did have to re-complile VMware Tools for Fedora 6, but CentOS 5.1 (RHEL 5.1) was a drop-in binary.

The guest OS clocks are never off by more than a second.

Re:Neat in theorey, imho.

[spun]

That's good news, we haven't upgraded to 3.5 yet. The issue did seem to get better with the upgrade to 3.0, and from what you say, perhaps it is finally resolved.

Re:Neat in theorey, imho.

[erc]

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?

Re:Neat in theorey, imho.

[erc]

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

Re:Neat in theorey, imho.

[erc]

How does that work? I've got a Verisign dongle that works with my PayPal account, and I'd love to be able to use it with my Linux box ... anyone know how?

Re:Neat in theorey, imho.

[Lehk228]

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:Neat in theorey, imho.

[MichaelSmith]

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:Neat in theorey, imho.

[mr_mischief]

I tend to think the separation between the transport and the authentication is a good thing. I had been using PAM and a firewall, but if I ever need such security again I'll be looking into the pam_abl module another poster mentioned.

Re:Neat in theorey, imho.

[Lennie]

Better yet, if you're gonna sync with a local server, take atleast 2 servers.

Let them sync each other and other public servers.

We've got a DNS entry with both IP's (A records) on the same name (ntp.domain).

Point the rest of the network to that name. OpenNTPd on all the OpenBSD/Linux
server-machines, ntpd on the ntp-servers (public servers from pool.ntp.org).

Windows servers: net time /setsntp:ntp.domain

Windows desktops sync with the domain-controller (AD if you like).

profit ?

I've not had any problems with this scheme.

If there is any drift, it's in the 1 second or less range.

Re:Neat in theorey, imho.

[mattmatt]

They've always worked the first time for me... Except for one time when I was trying to read it upside down.

Re:Neat in theorey, imho.

[fireboy1919]

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.

Which is precisely why I've ended up losing 10-20 seconds per minute in a VMWare ntp session. I think it's probably because realtime hardware clock isn't hardware or realtime, so the linear skew modeling of it doesn't work. NTP can sometimes make things worse, which may be a problem for the GP as it has been for me (before I replaced it with an 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.

It's not all software, though. It has to depend on some piece of underlying hardware to figure out fixed quanta of time - at worst, it has to use the system clock (the one that determines clock speed, not the one keeping track of the local time).

Re:Neat in theorey, imho.

[chill]

Having had to implement those security features, and get millisecond synchronization for a major telco by using NTP, I say leave it alone!

If you want simpler and easier, check out OpenNTPD.

Re:Neat in theorey, imho.

[RedBear]

there's no reason to try to mask what port it's on when SSH is a secure protocol anyway. There is no such thing as a 100% secure protocol and more importantly for this case there is no such thing as a 100% secure computer program. As someone a lot smarter than me already said, "Any program more than three lines long contains at least one bug." Or something like that. So even if the SSH protocol is 100% secure from every form of attack (which is impossible), the SSH daemon running on the targeted system will always have some chance of being exploited. Keeping unauthorized users from even being able to find the SSH service or connect to it on that system just increases the security. If this port-hopping thing were done correctly even notoriously insecure services could be used safely, as long as the authorized users connecting to it can be trusted and there is no way to guess or obtain the shared secret.

The main technical problem with this technique will probably be with the intervening network junk like routers and firewalls. Many routers, at least the consumer level crap, have very limited connection queues that will fill up and crash the router when you try to do something that uses a lot of short-lived transient connections (like BitTorrent). A firmware upgrade will solve that, however. Firewalls don't like incoming ports that move around, so the firewall itself would need to be the same system that's doing the port forwarding. I don't think UPnP or NAT-PMP would be able to react quickly enough or be secure enough to make this work on a typical consumer router/firewall device. But it's all doable otherwise.

I don't think the operating systems themselves would have any trouble with this scheme. It should even be possible to create a sort of filter software that would sit between the user's network connection and any software attempting to use a port-hopping protected service, so that the end-user software wouldn't even need to be modified. A proxy, I think that's what they call it. So support for this should be easy to implement in any modern network-capable operating system, theoretically. Make it an embedded hardware device and it would be platform independent, so even if an OS had a defective TCP/IP stack that could be worked around.

Re:Neat in theorey, imho.

[yoyhed]

The computing power in the outside Matrix must be pretty good. I wonder if it could get a score of 6 on Vista?

On Vista, yes. On the version of Windows that's current at that time in the future, no.

Re:Neat in theorey, imho.

[MadMidnightBomber]

There is *everything* wrong with creating a standard user account upload with a password of upload and enabling ssh access. The guys had made no attempt to set up an account for uploading only.

Re:Neat in theorey, imho.

[somersault]

Nah that is pretty cool. That story is from my Uni days, where I kinda stopped reading computing magazines and keeping up with developments for a few years (while I studied Computer Science :p ). Nice to know that the Matrix sequels had at least one redeeming feature xD

Re:Neat in theorey, imho.

[riegel]

Why couldn't the server just tell the client what time it thinks it is when the connection is initiated? Then the client would use the server time in place of its own time. Seems trivial to me.

Re:Neat in theorey, imho.

[WuphonsReach]

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)

We don't run our SSH servers (on publicly available interfaces) on standard ports for the simple reason that it cuts down the number of attack probes by about 1000x. So while I think port knocking or moving ports around frequently may be overkill, there are good reasons to not run services on standard ports if you don't have to.

Re:Neat in theorey, imho.

[WuphonsReach]

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.

You're confusing your terminology (I think). Local clock in NTP is used to refer to the kernel clock. What you're thinking of is the difference between the hardware (BIOS) clock and the kernel/software clock. Under GNU/Linux, the hardware clock is only referenced at startup with the option to write the software clock time to the hardware clock when you shutdown.

NTP disciplines the local/kernel clock while the system is then running.

Re:Neat in theorey, imho.

[WuphonsReach]

Having a second for fail-over might be wise if it's really important, but if all you're running on a server is NTP then you're probably down to just hardware failure to worry about.

A man with two clocks is never quite sure what time it is.

Either run one server or four-plus servers. With four servers, your clients (who should reference all four servers) can deal with a single server failure (leaving them 3) and still figure out if one of the servers is "insane".

With 2 servers, your clients are going to be hopelessly lost at figuring out which server is serving up "better" time.

Three servers works fine, until one fails, leaving your clients in the 2-server (which is right?) dilemma.

Re:Neat in theorey, imho.

[nacturation]

The whole shifting port knocking pattern is to protect from flaws found in whatever implementation of SSH, not to replace a login. And what's protecting against flaws in your implementation of a port knocking daemon?

Re:Neat in theorey, imho.

[bill_mcgonigle]

Honestly, people spend way too much time worrying about hiding their SSH ports. Use public key authentication and disable password authentication, and no one's going to brute-force their way in.

They can still exploit those unknown bugs in OpenSSH and bugger up your logs. A simple 1-port knock is sufficient to keep out the riff-raff, which is much more common than the determined hacker.

"Obscurity" tag is misleading

[egomaniac]

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:"Obscurity" tag is misleading

[Loibisch]

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

Re:"Obscurity" tag is misleading

[$RANDOMLUSER]

It's not that different a concept from Frequency hopping.

Re:"Obscurity" tag is misleading

[morbiuswilters]

Actually, it seems possible to lock out legitimate users as well, by sending them to a URL like http://example.com:12345/ 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

[sumdumass]

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.

Re:"Obscurity" tag is misleading

[morbiuswilters]

That's still not security through obscurity because it requires a shared secret to work. The method for determining the next port is not completely encoded in the algorithm, but instead is dependent on an external key. Using zombie machines would be little more than brute forcing the key, although the relatively small number of TCP ports results in a very short key length.

Re:"Obscurity" tag is misleading

[mea37]

I'm not too sure about that.

Ok, if it's not security through obscurity, then the attacker is allowed to know everything but the shared secret (i.e. doesn't know how to determine the correct port). We're testing for added security, so any authentication built in to the underlying service doesn't count (unless it interacts with Shimmer in a way that creates even more security than the sum of the parts; but I assert that it doesn't).

So the attacker knows that there are 3 sets of 16 ports. He knows what ports are in each set and when each set became active and when it will expire. He knows that one port from each set is good, and the other 15 are bad; but he doesn't know which one.

So what are you going to do if your attacker has access to 16 IP addresses on 16 different networks? Hackers have been known to arrange that kind of thing. So I run 16 parallel attempts to connect, and 15 of them get blacklisted. I still win.

Alternately: What are you going to do if the attacker is in a position to watch traffic to and from your box for a while? It would be pretty easy to find the real port if you could watch connections by legitimate users.

Looks to me like it is, indeed, security through obscurity.

Re:"Obscurity" tag is misleading

[egomaniac]

Re-read my comment. You're assuming that a single connection attempt is good enough, whereas I explicitly said that I was assuming that you'd have to reconnect.

Re:"Obscurity" tag is misleading

[mea37]

Nope. The key is what tells you what port to connect to. I can connect to the right port by brute force, never discovering the key. In other words, I can circumvent the true shared secret. (By "true shared secret", I mean the only "secret" that has any level of associated security. "I'm thinking of a number from 1 to 10" isn't a shared secret in any useful sense of the term.)

Re:"Obscurity" tag is misleading

[sumdumass]

I'm not saying that it wouldn't add a layer of security. But as I understand it, It seems that I could stumble onto the right port in the first place and hack my way in using zombies or not. The key only points you to the right port and then you validate. This is like placing 500 ignition keys to a car in a fish bowl and telling someone they win the car they can pick one key and start the car. So if I was to pick the right port then validate or hack my way in without validating, the security did nothing. The only real security is the random chance I wouldn't find the right port/car key and whatever is normally there to stop my entry. The security key is more or less just convenience so that i can find the right port the first time.

Now if I am not understanding something correctly and you need the key to even get access to a/the port then I am wrong. I mean if the ports are all blocked and the key opens them for you to attempt authentification? But as I understand it, the port it already there and exposed along with numerous fake ports, you just don't know which one it is without the key and that is obscurity.

If this is how I am thinking, then combining it with something like port knocking where the ports aren't even available until another challenge succeeds might make it better.

Re:"Obscurity" tag is misleading

[mea37]

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 noise on the RF spectrum for the FH signal to "look like". There is no such "noise' in the domain of IP port connections.

Re:"Obscurity" tag is misleading

[mea37]

Re-read my post. I'm making no such assumption.

Re:"Obscurity" tag is misleading

[DomerMike]

Actually, the blacklist isn't really an effective solution to the scanning problem, given the proliferation of botnets. All I'd need is a botnet consisting of 65,535 hosts to scan every TCP port on your system in a distributed fashion. Not an unusual size nowadays.

Re:"Obscurity" tag is misleading

[morbiuswilters]

Yes, this is a horrible, insecure idea but it is still not security through obscurity. Having access to the source code and algorithm does not allow you to guess the port any more easily than by brute force (assuming there are no flaws in the cryptographic method used to determine the port). The small number of ports makes brute forcing easy, but that still does not make this security through obscurity. Short passwords are also insecure, but that doesn't change the cryptographic strength of the underlying authentication mechanism. The ports can be sniffed, but so can any plaintext password, which is precisely why the proposed idea is about as stupid as sending unhashed, 3 letter passwords over the wire. Security through obscurity means that an attempt at security has been embedded in the algorithm itself and not in the key, which is not the case here. Please read up on Kerckhoff's principle.

Re:"Obscurity" tag is misleading

[mea37]

Please read up on Kerckhoff's principle

I have, in fact.

From the first sentence of the article you linked: "a cryptosystem should be secure even if everything about the system, except the key, is public knowledge".

The shimmer system is secure only if elements of the system other than its key -- such as the port list, the rotation timing, etc. ... or ideally the fact that Shimmer is in use at all -- are unknown to the attacker. It is security through obscurity.

Re:"Obscurity" tag is misleading

[Anonymous Coward]

I would consider implementing this because it sharply decreases the chance of having a vulnerable SSH server found by IP block scanning.

Re:"Obscurity" tag is misleading

[morbiuswilters]

The currently active port is derived from the key, via the algorithm. Just knowing the algorithm without the key would not tell you which port was in use. As evidenced by your other comments here, you are ignorant of many cryptographic and networking fundamentals. I don't mean that in an insulting way and you shouldn't let yourself be discouraged, but please educate yourself before you make broad statements that are inconsistent with the facts.

Re:"Obscurity" tag is misleading

[russotto]

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

Re:"Obscurity" tag is misleading

[sumdumass]

Actually, if I understand it correctly, it would increase your chances, it would increase the number of SSH servers found with the hops of locking the bad guy out before he gets to the right hole or trapping them in a useless honey pot.

That is why security through obscurity is a bad idea, it gives you the false sense of added security.

Re:"Obscurity" tag is misleading

[mea37]

The currently active port is derived from the key, via the algorithm.

Yet the set of possible active ports is not (and cannot be), and that's all one needs to get into the system. The entire point is that the key can be circumvented unless other secrets are kept.

As evidenced by your other comments here, you are ignorant of many cryptographic and networking fundamentals.

Do you always interpret disagreement about how concepts apply as ignorance, or are you just being particularly arrogant today?

Re:"Obscurity" tag is misleading

[GodfatherofSoul]

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?

Re:"Obscurity" tag is misleading

[morbiuswilters]

Yet the set of possible active ports is not (and cannot be), and that's all one needs to get into the system. The entire point is that the key can be circumvented unless other secrets are kept. That's like saying the AES algorithm is security through obscurity because if you have the plaintext you don't need the key. Do you always interpret disagreement about how concepts apply as ignorance, or are you just being particularly arrogant today? I apologize. My tone was a bit harsh but I didn't mean to offend. You are free to disagree, of course. Perhaps you fully understand the concepts represented and are missing how they apply. The active port is the "plaintext" and the key is how you find the port. There are several additional features (like the blacklisting) which do not weaken the cryptographic strength of the system, although they don't do much to enhance security either. Additionally, the blacklisting can be leveraged by malicious parties to lock out legitimate users, as I explained above. The biggest problem with the proposal is that the active port (or "plaintext") can be guessed trivially, making the cryptography pointless, also as explained by me above. That doesn't mean the system isn't cryptographically strong, just that overall it is poorly thought out and more harmful than helpful. The real lesson is that strong cryptography is no panacea, but only a piece of the security process. I should note that I haven't actually bothered to verify that the developers of shimmer haven't introduced errors in their implementation of the cryptography in question, I was only evaluating the theoretical aspects of their proposal. Since cryptography is notoriously difficult to work with and many otherwise brilliant developers have introduced glaring security holes by attempting to use it in novel ways, this is quite possible.

Re:"Obscurity" tag is misleading

[Anonymous Coward]

Or for even more fun, a disgruntled attacker starts IP spoofing after they've been locked out a couple of times, and manages to lock _everybody_ out.

Re:"Obscurity" tag is misleading

[mea37]

That's like saying the AES algorithm is security through obscurity because if you have the plaintext you don't need the key

Nope. The set of ports that could be active are not the "plain text". The specific port to which to connect is the plain text, and I don't need to know that in the attack I described. In fact, I discover it without discovering the key, using nothing but information about how the algorithm works.

My argument is more like saying "if you can't implement AES without broadcasting a piece of information with which an attacker who understands AES can circumvent the key to get the plaintext, then AES is security through obscurity". Which is true; the reason that AES isn't security through obscurity is that you can implement it while keeping the key -- and only the key -- secret, and it is secure in such an implementation.

There are several additional features (like the blacklisting) which do not weaken the cryptographic strength of the system,

This appears to be the crux of our disagreement. What, exactly, are you evaluating the security of? Only the part of the system where some function maps a key to one of 16 port numbers? We don't have enough information about that function to debate its particular cryptographic strength -- and certainly you could choose a cryptographically strong function to implement that step -- but in any case that focus is far to narrow to have practical meaning. It's academic.

The other steps don't weaken that one step, but they are critical parts of the overall system and they do make the system as a whole weaker than that single step. The strength of the system as a whole is what has practical importance, and that is what I'm evaluating.

To get back to your AES analogy -- AES is strong. But how would you rate the strength of a system where I use AES to encrypt the shift offset for a ceasar cypher, having used said ceasar cypher to encrypt my message? The "extra steps" involved in the ceasar cypher don't weaken AES, but they do render its strength moot with respect to the strength of my system as a whole. If you know what I'm up to -- i.e. if you understand my algorithm -- then you don't need the key; the security comes only from the secrecy of the overall algorithm. Security through obscurity.

By the way, should I conclude from the fact that your post is illegible (as apparently you posted as HTML Formatted instead of Plain Old Text) that you know nothing about posting to Slashdot?

Re:"Obscurity" tag is misleading

[Anonymous Coward]

What happens if the attacker is snooping a legitimate user on the far end of the connection, and is patient enough to analyze the traffic patterns to get a feel for what's going on, and then performs his connect at the same time that the legitimate user does?

The simple fact that the technique was published means that the "obscurity" tag is wrong. And now that it's out in the open, it's not security at all. It'll keep the honest people out...

Re:"Obscurity" tag is misleading

[mea37]

Hmm.

Now show me the spectrum analysis for a device that uses spread-spectrum techniques for privacy rather than merely to avoid interfering with conventional wireless signals. You know, since that's the context of this discussion.

Then again, the baby monitor doesn't seem to have a very good FH implementation at all. If I understand the third graph on that page, it would seem that while the monitor doesn't prevent the network card from functioning, it does severly reduce bandwidth.

Re:"Obscurity" tag is misleading

[morbiuswilters]

Since it seems we could go around forever and we're not getting anywhere, I think this is going to be my last post on the subject. You're also getting a bit nasty. I should have previewed my last post, but I was in a bit of a hurry because I'm at work right now. I am a software engineer who does quite a bit of networking work and has an obsessive cryptography hobby. It seems like every few months somebody comes up with some elaborate system to avoid using iptables. Bonus points if they can somehow work cryptography into the whole thing and make TCP/IP more difficult to secure in the process.

The active port is the plaintext. That is exactly what I said. Your example with the Caesar cipher isn't half bad, but shimmer isn't encrypting a second key, it's using a cryptographic function and the current time to generate a port to listen on. Just because the plaintext is painfully easy to guess doesn't mean the system is relying on the secrecy of the algorithm. Even knowing the algorithm, I still have to brute force either the key or the plaintext. One of the biggest problems with shimmer is that the plaintext is far, far easier to guess than the key.

Imagine if instead of encrypting a port, we were encrypting a single bit and you had two attempts to guess it. I could encrypt that single bit with AES and give the result to you and ask you to guess the plaintext. Even by knowing the algorithm I used, you still have to brute force either the key or the plaintext. It's simple to see which would be easier. Obviously you would discard the ciphertext and just guess 0 and if that was incorrect, 1. Was my single bit secure? Of course not. Did knowing how I encrypted the single bit help you in guessing it? No. Now imagine if I just inverted the bit, but I don't tell you this. You are still going to have to guess, but if you knew the process I had used to obtain the "ciphertext" you would be able to "decipher" it with no work at all.

In terms of efficacy, both methods leave much to be desired. However when I invert the bit, I must keep the knowledge of the process to myself lest I save you a single calculation. With AES there is a large body of documentation of the algorithm, and yet I can rest soundly, secure in the knowledge that you must freqently guess TWICE, devouring your valuable time! Ha ha ha! So the real lesson here is that you should never encrypt a single bit, or for that matter, a 16 bit TCP port number. If you must engage in such absurdity, do not convince yourself the system is secure, even if the algorithm can be published with impunity.

Re:"Obscurity" tag is misleading

[Lehk228]

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

[russotto]

Then again, the baby monitor doesn't seem to have a very good FH implementation at all. If I understand the third graph on that page, it would seem that while the monitor doesn't prevent the network card from functioning, it does severly reduce bandwidth.

Of course it does. There's no free lunch; introducing noise into the 802.11 signal will reduce the 802.11 throughput.

A device which uses FHSS for privacy will look basically the same on an analyzer. The difference would be that the frequency sequence would have a much longer pseudorandom repeat cycle. An attacker who can listen on all channels at once can negate the usefulness of FHSS for privacy.

Re:"Obscurity" tag is misleading

[edunbar93]

Even more importantly, this can be easily fooled by attacking with a botnet. Each bot tries only once before it gets blacklisted, which is fine, because the botnet master doesn't care much about how that one IP is no longer usable, and the end-user who owns it probably doesn't even want to access whatever it is that you're protecting.

Also, apparently this box can't be used for anything useful but the service you're trying to protect. I honestly don't see much use for this besides some cyperpunk's home firewall.

Re:"Obscurity" tag is misleading

[Anonymous Coward]

Or, conversely, this entire protocol is just using a port number as a time-dependent password. Why not just keep the same port and ask for a time-dependent password, like is quite common in some high security facilities?

Re:"Obscurity" tag is misleading

[mea37]

Since it seems we could go around forever and we're not getting anywhere, I think this is going to be my last post on the subject.

Fair enough; I don't have much more to add. Like I said before, we apparently disagree about how to apply the concepts, so that's that.

You're also getting a bit nasty.

Oh, so people don't like it when you imply they know nothing because of one error? I never would've guessed.

Give nasty, get nasty. Most people who open with insults don't get a reply from me at all, even if they do say "not to be insulting". Must've been in an off mood yesterday to have even bothered.

Isn't this port knocking

[crow]

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.

Re:Isn't this port knocking

[doofusclam]

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:Isn't this port knocking

[AndyST]

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 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:Isn't this port knocking

[Anonymous Coward]

in the real world there's a bunch of routers and other network devices that don't send correct ICMP or even at all; the friendly ol' internet where all hosts are nice to each other is long dead, hoss..

Re:Isn't this port knocking

[Dr. Manhattan]

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:Isn't this port knocking

[dave420]

You get blacklisted if you try an incorrect port, so getting lucky is pretty impossible.

Re:Isn't this port knocking

[Anonymous Coward]

You get blacklisted if you try an incorrect port, so getting lucky is statistically improbable.

Fixed that for you. Personally, I like my security schemes to be deterministic.

Re:Isn't this port knocking

[Sancho]

Yeah, because no hackers have entire networks of zombie computers at their disposal.

Re:Isn't this port knocking

[caluml]

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.

Re:Isn't this port knocking

[kaoshin]

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 within that time frame then it would hit the max of one user allowed to connect. I would terminate the webmin service on exit to also prevent tailgaters. The goofy thing is I went through all that just to keep a secure todo list on my home computer because my corporate phone had a lame one. In retrospect I think it was maybe overkill.

Re:Isn't this port knocking

[yarbo]

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

Re:Isn't this port knocking

[crow]

That assumes you have a static port knocking system.

The variation that I've liked best is one where you send a single UDP packet with a payload that is an encrypted request to open up a specific port for a specific IP address at a specific time. I suppose that's not technically port knocking, but it's the same idea--you send a magic knock first, then you can use the port. It's just that the knock is an encrypted command instead of a secret sequence.

Of course, you can use a sequence where the sequence is determined based on the source IP and time, so that a replay won't help.

Obscurity?

[matt4077]

Passwords are security by obscurity, too. It's just that the obscurity is neatly focused on a single point and can easily be changed. This scheme is quite like that, actually. But ssh+strong passwords is easier to setup and can be used for honeypots equally well. This only protects against remote exploits, which (as far as we know) don't happen too often.

Re:Obscurity?

[morbiuswilters]

Passwords (or any other shared secret) are not security through obscurity. http://en.wikipedia.org/wiki/Kerckhoffs%27_principle

Re:Obscurity?

[Anonymous Coward]

Open ports are no hazard to security if the server is well programmed. It will be fun to find the Obfuscated port, but if the server is weak it will fall all the same. Security is only as strong as the weakest link. In this case the weakest link being, as often is the case, the administrator.

Re:Obscurity?

[bugs2squash]

This will probably stop "john" trying to log in from Istanbul as he seems to try 100s of times each day, and I like the C3PO acronym - cute. So far, port knocking has also stopped 'john' and his friends.

It seems too easy to get locked out as one slip blacklists you.

I was shocked to read that even with NTP, some servers' clocks drift so far - I thought it could keep them +/- a fraction of a second worst case (ah, when reality bites)

Re:Obscurity?

[jmodule]

matt4077: "Passwords are security by obscurity, too."

No, no, no! A password is a *key* and has nothing to do with obscurity. The quote you refer to is using obscurity to mean enhancing an algorithm by "keeping its process a secret." That is not the case here.

See Security through obsecurity is no security and Security through obscurity

Re:Obscurity?

[matt4077]

I know that idea, I just don't agree with it. When I say "it's obscurity, too" I don't mean that it makes sense to rely on keeping your algorithms secret. It's obviously better to make the key/password the secret, or obscure, part of the system, because it's much easier to change. The wikipedia article above actually says something to that effect. These semantics do make a difference though when a new idea is shot down by the common "that's security by obscurity" argument. If the secret has all the properties of a password it's equally well suited. Using ports, such as in this case, is an example (though with some differences: ports are easy to try/guess so you need blacklisting).

Re:Obscurity?

[morbiuswilters]

Then you are incorrect. You are splitting hairs with your definition and missing the real point that embedding secrets in the algorithm is not secure. The "that's security by obscurity" argument is a completely valid one to make, assuming the proposed idea really meets the criteria. That doesn't appear to be the case here, even though the proposal does suffer from an extremely small keyspace and requires sending a plaintext key across the wire. So it is insecure, but it fails the obscurity argument. Still, the very definition of "security through obscurity" is embedding secrets in the process and not the key and you can't just disagree with the definition of a term you had no part in defining.

Re:Obscurity?

[Sancho]

This secret doesn't have all of the properties of a password, though.

At the very least, it's shared. This makes it unsuitable for use on a multi-user system, but if that's ok with you, then fine. It also, ultimately, hashes down to a pretty small set of values (ports). All this to ... what? Prevent logs from being filled with failed connection attempts? Protect your server against brute-force attacks? There are better ways to handle both of these problems.

Excuse me, but I have had enough.

[Noryungi]

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

Re:Excuse me, but I have had enough.

[mathimus1863]

I agree, this is overboard. But it is feasible. The time syncronization is not a huge issue: the same program which executes this type of secure protocol can easily keep track of the time syncronization issues since it will have access to both clocks when logged in.

For instance, if the interval is changed every minute, and the connection is used at least once a month, the syncronization state can be tracked pretty reliably. Even if the connection is only opened once per year, it could easily allow 2-4 failed attempts to allow for mis-syncronizations.

Re:Excuse me, but I have had enough.

[0xABADC0DA]

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.

Re:Excuse me, but I have had enough.

[Chineseyes]

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.

[VincenzoRomano]

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.

Wierd Coninsidence

[fotoflo]

Oddly, Last night i came up with a new way of doing this, and today this appears on slashdot. Here is my idea: UDP packets are are sent in a specified order to specified ports, this scheme can come from some kind of private key. The packets contain a signature file, which may be divided into several segments, each one containing the reply IP. After the sequence is complete, the SSL port uncloaks on a specified port.

Re:Wierd Coninsidence

[bobintetley]

You've just reinvented Port knocking. And why bother encoding the reply IP in the payload? The packets themselves have the reply IP on and if the idea is that your payload is encrypted verification for the IP, that'd be a real pain in the arse if you're ISP allocates dynamic addresses - just use public key auth for your SSH endpoint when it uncloaks instead.

Re:Wierd Coninsidence

[fotoflo]

good thing i didn't start writing a prototype then, huh?

Re:Wierd Coninsidence

[Sancho]

It's not really a private key--at least, not in the same way that SSH public/private keys are used. Generally speaking, you don't transmit your private key all over the internet when you want to use it.

More or less obscure than password encryption?

[YeeHaW_Jelte]

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:More or less obscure than password encryption?

[mea37]

There are 16 possible ports; I can try all of them independently. The blacklisting tries to block brute force, but it won't work against a hacker who knows what's going on (which is why this is security through obscurity).

In any good password scheme, there are at least billions of possible passwords. Even so, passwords are not as good as dual-key schemes, which have even more possiblilities.

The analysis is completely different for shimmer vs. password-based authentication.

Re:More or less obscure than password encryption?

[YeeHaW_Jelte]

All you are saying is that the obscurity in password encryption is multitudes larger than the obscurity in shimmer. This still does not change the argument that both are security through obscurity methods.

Re:More or less obscure than password encryption?

[mea37]

Well, the experts in cryptography say it is different, but suit yourself.

Re:More or less obscure than password encryption?

[Sancho]

Generally speaking, security through obscurity means that knowing the inner workings of the security system gives a hacker enough information to let said hacker in without much trouble. The common example is a case where knowing the algorithm is enough to let you in--if the hacker knows the algorithm, either through a corporate leak or by reverse engineering the software, then the system is said to be using security through obscurity.

Non-obscurity based security systems often have open algorithms--the user has a secret of some sort which he uses to authenticate himself to the system. It's perfectly true that the secret could be guessed or compromised, but this is true of nearly every security system on Earth. The simple point is that the system isn't relying on secrecy of the workings of the system itself.

It's entirely possible for a system which relies on security through obscurity to be more secure than an open system which relies on a secret. A black box with a chip and leads sealed in epoxy is unlikely to be hacked. A password system which requires that passwords be dictionary words will be hacked rather quickly. Yet the former is still security through obscurity (albeit with a layer of physical security which makes it harder to find the obscure component), and the latter still relies only on a mapping of a username and a secret.

The system described in the article really straddles the line, but not because the port is easily guessed. The obscurity portion of the system is in the fact that a single, shared secret is used (a secret which might be leaked and compromising the security of the whole system.) Shared secrets are fine when used to salt an actual authentication secret, but they're only barely better than worthless when used as the sole authenticator for a particular layer of your security model.

Frankly, the person who came up with this system was probably trying to avoid the rampant SSH brute-force attacks which clutter up all of our logs. There are much better ways of handling this, in my opinion.

Re:More or less obscure than password encryption?

[kkwst2]

I would argue that neither are. Security through obscurity is more an idea than a design principle. It's talking about ways to get around the security OTHER THAN the encryption key (password). The encryption key can be strong or weak, but it's not usually considered security through obscurity. Having several backdoors and hoping that nobody finds out about them would be security through obscurity, the obscurity being the "secret" backdoors. For shimmer, it would be whether there is some other way to guess/figure out the open port other than having the sequence algorithm. The idea itself isn't really security through obscurity.

Simple error in the method

[Anonymous Coward]

The way he describes the work there is a chance it will NOT generate 16 distinct ports, since he AES encrypts 0-15 and then takes the result mod N (where N is some number of ports you wish to use) to get port assignments.

AES does not guarantee these numbers will be distinct. Minor error, but these toeholds are how methods are broken. Someone who does not understand these simple items should not be designing security protocols, IMHO.

Re:Simple error in the method

[JohnGrahamCumming]

Correct. But, if you examine the implementation the counter is actually incremented enough times to get 16 distinct ports overcoming the fact that AES might provide a duplicate port or two along the way.

Complete Waste of Time

[Chris_Jefferson]

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?

Fascinating

[Anonymous Coward]

The service itself is not more secure in a mathematical sense; the clock is a rather well-known "secret".

It does however provide a degree of hardening for the *daemon that provides the service*, by reducing its surface area. This is worthwhile to investigate, but automatic blacklisting is problematic. If all of your services depend on the accuracy of the local time server, you now have a single point of failure for every service hardened in this way.

Maybe not quite ready for production environments, but a fascinating idea that has great potential.

Re:Fascinating

[Sancho]

Actually, one could argue that it increases the daemon's surface area. Instead of 1 port, 3 ports now forward to the listening service. Although a connection to a non-listening port will trigger a blacklist of the remote IP address, the same could be done with just one listening port.

Of course, since the port changes every minute, that gives very little time for the attacker to crack it before he has to find a new port. Nonetheless, if you're relying on this for security, it seems like a pretty bad idea. It's a lot of work to thwart a brute-force attempt, when using keys will work better.

Neat idea, but impractical.

Port knocking?

[Spazmania]

And this is better than classic port-knocking how?

Interesting...

[ZonkerWilliam]

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.

Re:Interesting...

[mea37]

It's a little more complex than that. Say the listening ports are 1001 to 1016, and the real port is 1008. A real user connects to 1008. Fine, but he's going to disconnect from it right away anyway, because that's the daemon's listening port (which needs to be freed back up so it can keep listening). If the service is session-based, then the daemon is going to assign the session to another arbitrary port.

However, you are correct that by watching traffic you could quickly identify the "right" port. It's just a little harder than watching for long-standing connections; you have to actually watch someone connect.

Re:Interesting...

[morbiuswilters]

You obviously have no idea how sockets work. The daemon does not close the connection nor does it need to to open accept new connections. The client IP and port and the server IP and port all combined make a unique connection.

Re:Interesting...

[mea37]

Hm. Well, it's been about 10 years since I wrote actual socket code without a library doing all the heavy lifting, so it's quite possible my memory on that point is confused.

I "obviously have no idea", eh? I'd hate to be in any situation where your powers of deduction might actually matter.

Re:Interesting...

[morbiuswilters]

I would not wish to be in a situation where you ability to write networking code or evaluate the merits of a security methodology might actually matter. Not to offend, just the way it is. Hundreds of thousands of people on a daily basis rely on my ability to perform these tasks correctly. It goes without saying that I am imperfect and make mistakes, but not very frequently. :-)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Frequency-hopping spread spectrum (FHSS)

[fbonnet]

It sounds close to the FHSS technique but applied to the Internet. FHSS is often used in military applications to avoid jamming and interceptions. Here, instead of switching carriers, one has to switch ports.

Actually, it gets better than that...

[PRMan]

If you are a competitor of these guys, simply forward people silently to one of their ports in a hidden iframe.

Bingo, permanent ban.

Re:Actually, it gets better than that...

[Anonymous Coward]

of course, this will get those people to be mad at you, cause them to distrust you, or open you to civil or criminal legal action.

Re:Actually, it gets better than that...

[Anonymous Coward]

If you are a competitor of these guys, simply forward people silently to one of their ports in a hidden iframe.

Bingo, permanent ban. RTFA. Blacklisting expires after a predetermined period of time.
Captcha: outcome.

not as good as port knocking

[vrmlguy]

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.

Re:not as good as port knocking

[dk90406]

True.
And if you do the math: 15 decoys and one real port. Changes every minute. 15 minutes penalty.
By trying opening random ports, the chance of you hitting the right port in 11 attempts or less (2,75 hours) is approx 51%.

Neat idea, but needs improvement. Like port knocking with honeypot (blacklisting) ports.

Re:not as good as port knocking

[Abcd1234]

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:not as good as port knocking

[Anonymous Coward]

Nice job there. I'm sure you actually read TFA. There are 48 ports being listened to.

"Since both client and server must be time synchronized to the nearest minute shimmer actual holds 48 ports open at a time (16 for the previous minute, 16 for the current minute and 16 for the next minute) to avoid problems due to small amounts of clock drift."

Re:not as good as port knocking

[raddan]

Even better is using authpf 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 question are port-forwarded to something nonstandard and tunnelled via SSL. Works great for us.

Re:not as good as port knocking

[vrmlguy]

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:not as good as port knocking

[raddan]

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

Re:not as good as port knocking

[vrmlguy]

I don't know anyone who uses port knocking to connect to an unencrypted channel. http://www.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 code every five seconds. If you allow any of the last twenty patterns to succeed then the odds of a successful attack drop to 20-in-1,000,000,000. If you really like authpf, then go ahead and connect to authpf once you get through. Even then, you should still restrict the user to an SSH channel. Layered security is good.

Re:not as good as port knocking

[Lehk228]

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.

stealth

[TheSHAD0W]

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 a packet containing the destination port along with a 32-bit entry code. (This entry code could be, for instance, the first 4 bytes of the SHA1 of a concatenation of a private key plus the client's IP.) Without receiving this packet the server's port would return no data on the attempted initiation of a connection, resulting in a "stealthed" server port.

Re:stealth

[JohnGrahamCumming]

Your UDP idea is implemented by tumbler.

Why bother with aes?

[pimpin apollo]

Maybe i'm missing something here, but the description lists the following steps

1. Get the current Unix epoch time to the nearest minute: minute
2. Get the name of the mirage being shimmered: name
3. Get the shared secret: secret
4. Calculate the SHA-256 hash of a combination of minute, name and secret to create a 256-bit Rijndael key that depends on time (changing every minute) and a shared secret: key.
5. Use key to AES encrypt the numbers 0 through 15 to obtain 16 seeds for port numbers: seeds.
6. Map each seed to a port number in the range specified for the mirage using a simple modulus operation to obtain a list of ports: ports.
7. The first port generated (corresponding to the first seed from encrypting 0) is the port that will be forwarded, the other 15 are traps.

Why are steps 4 and 5 required? Why not simply use 0-15 numbers as salts to the hash described in 4.

The only thing that seems useful is a concern that the SHA hash appears less random than the AES ciphertext. First, I'm fairly sure that such an attack is not publicly known (see comments to linux /dev/random char device), and second, the hash sets the key anyway. In any event, it seems unnecessary to go through these steps to randomize two bytes.

Re:Why bother with aes?

[JohnGrahamCumming]

It's true. I could have used the hash as a CPRNG all by itself, but I thought the implementation with a block cipher was clearer.

Distributing Cracking

[Applekid]

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

Re:Distributing Cracking

[Shadow-isoHunt]

If your computer can't handle 65535 simultanious SYN packets, you've got problems.

What are these passwords, kemo-sabi?

[igb]

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.

Re:What are these passwords, kemo-sabi?

[iusty]

Actually, as you access your key file from an untrusted computer, a keylogger in combination with another program could get both your passphrase and your private key.

Re:What are these passwords, kemo-sabi?

[Cajun Hell]

Presumably that's what he meant by "targeted attack."

Re:What are these passwords, kemo-sabi?

[iusty]

Possibly... but a keylogger/spyware/etc. program could very simply look for id_dsa or similarly named files... in which case I would call it smart but not targetted attack.

Anyway, it all depends on personal preference, but I regard the safety of my private key/passphrase as a very important thing.

Re:What are these passwords, kemo-sabi?

[igb]

I realise that. But the risk is smaller than a keylogger getting the password which alone provides access. I struggle to see the argument that it's not valid to use two factors because they could both be stolen, so it's better to use one. And realistically, and I realise this is a variation on security through obscurity, key loggers that look for id_dsa could be made harder by naming my key some_file_name.

Re:What are these passwords, kemo-sabi?

[Anonymous Coward]

Never trust the hardware where you can't. A relative's computer may be safe enough but on some random computer out there, if some guy plants a script that will copy the content of a usb stick as it gets mounted, you're done.

Hm

[Loconut1389]

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.

Re:Hm

[JohnGrahamCumming]

Sounds just like tumbler.

Re:Hm

[Loconut1389]

I hadn't heard of that. I originally wrote that around '98, so it probably predates both. Nice to see a more serious project.

Re:Hm

[Anonymous Coward]

You should sue them. Prior art and all that wonderful stuff. All you need is that self-mailed floppy from back in 98 when you present your case to a judge.

And if you don't; I have a similar utility created back in 1987. It's a on 5.25 floppy and the time stamp of the .c file proves me right. I think that predates your copy.

Re:Hm

[Loconut1389]

no need- it was internal use and built in to a proprietary app- it didn't use iptables or anything- it just opened the correct port directly. It never made a dime anyway.

Potential DoS scenario?

[Lieutenant_Dan]

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.

Re:Potential DoS scenario?

[multipartmixed]

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.

SSH implementations have defects

[tepples]

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.

Newbie Question about SSH Security ...

[thornomad]

I don't use an obscure port for SSH; however, I don't allow passwords (only passkeys). How insecure is this?

Re:Newbie Question about SSH Security ...

[KillerBob]

The only truly secure method is to make it terminal access only and accessible only by passcard or some other physical means. (IOW, to turn SSH off) Not exactly feasible for something you want to access remotely.

Passkeys can be relatively secure, or they can be relatively insecure. It depends on the level of security you're implementing in them. Another really easy way to secure it is to make it more trouble than it's worth to break into it. I have my SSH on the standard port of 22 on my server, and am not worried about security at all. I subscribe to the mailing list and it's kept up to date every time a new release comes out. More importantly, my SSH server is configured to only allow one user ID to log in, and to only allow one password attempt before disconnecting. It also doesn't disconnect until after you've entered the password, and will give the same error message no matter what, so you've got no way of knowing why it is that you're not getting through. Finally, the user name in particular that's allowed to log in through SSH doesn't have an e-mail account or home directory, and isn't published anywhere.

No, that isn't going to secure it entirely. It is, however, going to make breaking into it incredibly time consuming and generally not worth it unless you have a personal vendetta or other reason to go after me specifically. Security through obscurity. In this case, get away from Default Pass, and towards Default Reject security model.

Re:Newbie Question about SSH Security ...

[thornomad]

Thanks for the suggestions about limiting attempts -- I am going to look into that.

You wrote: "Passkeys can be relatively secure, or they can be relatively insecure. It depends on the level of security you're implementing in them."

Is that in reference to the size of the key ? Such as a 1024 or 2048 or something even bigger ?

I am only running a file server at home that I like to be able to remote into, so I am not so much worried about targeted attacks against my system ... not sure why someone would take the effort to do that to get a hold of my open office documents and music files. I am more concerned about making sure it isn't "easy" to do.

Re:Newbie Question about SSH Security ...

[KillerBob]

I am only running a file server at home that I like to be able to remote into, so I am not so much worried about targeted attacks against my system ... not sure why someone would take the effort to do that to get a hold of my open office documents and music files. I am more concerned about making sure it isn't "easy" to do.

It's not what they can do with your files. It's what they can do with your computer. :)

And yes, that was in reference to the key itself. The size, but also the algorithm used to implement it. Generally, limiting which user can actually log in and how many attempts are allowed is much more secure. The problem with passphrases is the same problem as with passwords, though. That's the user. I personally prefer passwords, because they're variable length. Much harder to dictionary your way through it when you're only allowed one attempt to break in before you get disconnected and the password could be anywhere between 6-50 characters long. The number of permutations is lower when you know for a fact that it's going to be exactly 128 characters hexadecimal, because that removes all of the possibilities from 1-127 characters long, all the letters from G-Z, all of the special characters, and all lower case letters.

That isn't to say that a passkey is insecure. Just that it's really not any more secure than a password.* Going through an encrypted channel (which is done with SSH), and making sure that your system is properly locked down as suggested above is a much better way to go about securing yourself.

Can I ask how many usernames you have that actually need shell access?

* - Math moment....
1024-bit key = 2^1024 possible permutations, ~= 1.78 * 10^308. Well into the numbers we don't have a name for.
With a password, each character has a choice from a dictionary of 32 (special characters) + 52 (letters) + 10 (numbers) = 94 possible characters. Not counting alt scancodes which can actually be used in some implementations. To make the math easy, though, we'll keep it that way.
1 character = 94 possibilities.
2 characters = 94^2 possibilities = 8836
3 characters = 94^3 possibilities = 830584
4 characters = 94^4 possibilities = 78074896
And so forth.
Note, however, that this only works if you know exactly how many characters are in the password. If you don't know, then the number of possibilities comes out to the sum of all possible lengths up to the maximum. So if the password could be 1-2 characters long, it'd be 8836 + 94 = 8930 possible passwords. When you make it 1-3, it becomes 830584 + 8930 = 839514 possible passwords, and so on.

Let's skip a few lines of the dissertation, and get to the end of what I'm trying to say:
When you get to 1-15 characters in length, you're already at 399542248261999180586863282762 possible passwords....
1-30 characters, you're up to 1.579357739749060926392038684028e+59 passwords....
Going much further than that crashes Calculator.... (well, it crashes at 41).

Mathematically speaking, a 1024-bit key = 128-bytes... a dictionary of 256 characters for a key that's known to be 128-characters long. For a dictionary of 94 characters, you need a password that can be from 1-155 characters long to be in the same ballpark.

So no. A 1024-bit key is going to be pretty difficult to dictionary. Much more difficult than a password, since most of us aren't going to have a 150-character password. (At work, I use a 42-character password right now, but I'm a freak. It's actually a sentence, translated into Japanese and written in Romaji, using roman numerals for places where the syllable sounds like the number... like 4 for "yo", and 7 for "shi".) But when you're limited to one attempt every 30s without even knowing if you have the right username in the first place, it's going to take a *very* long time to dictionary it.

All that said, real dictionary attacks against an SSH host are extremely rare anyway. They're too obvious in the security logs. Most of them are exploits, and that's why you need to keep the server up to date and subscribe to the mailing lists for all of the daemons you run. :)

Re:Newbie Question about SSH Security ...

[thornomad]

Thanks for the time to go over that -- am not in a computer technologies field (work as an interpreter, actually) but I love computers. Anyhow, at home I have two users. Myself and my significant other. I use (if I remember right) a 2048 bit RSA key with a passphrase (nothing too special in the passphrase itself). The machine is behind a router which only forwards port 22. I run a web server on another box (don't trust it to have them both on the same machine). Locally I run AFP (through netatalk) and NFS. NFS exports are all read-only and AFP requires username password. Theoretically, I think, it is only the SSH that has outside encounters (unless someone hacked the web server, which is possible). With disabled root access and password login I feel more comfortable with the way things are ... But am always thinking I should have more going. But I may be paranoid -- no, I am paranoid. I might get the recently reviewed "linux firewalls" book to learn some more about this stuff. I keep the system updated but, to be honest, if someone was using my machine I wouldn't know what to look for unless the services I used stop working. I like to think it's still more secure than my old XP machines. Thanks again for your time. Is interesting stuff. I will read it again when I am out of the hospital and not on my blackberry.

Re:Newbie Question about SSH Security ...

[KillerBob]

In the world of computer security, there's no such thing as paranoia. They really are all out to get you.

I can't really suggest more than I have, then. But you may want to look into whether or not your other half needs access to the server remotely through SSH. If not, then disable it. :) If yes, but not through the firewall, then run a second SSH server on an unforwarded port, though which it's allowed, and disable it on the public one.

It's not difficult to secure, really. Just gotta treat it like driving: everybody else sucks and is going to try to get you killed.

DenyHosts SSH script

[HumanCarbonUnit]

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

Thus its easy for me to share the login with friends so they can SSH and SFTP into the system and any / all attempts to guess or force a login are blocked after the threshold is reached.

Why not use FWKnop?

[fmachado]

FWKnop can use signed GPG keys to authenticate both sides (if one side does not match, no open ports). It can pass parameters inside the one package it uses (and it's just one package). Seems more productive and safer. And it only opens the port to service (SSH) which still has it's own security.

To the critics: it's not STO (security through obscurity) as it's not the only form of security. It's called Concealment, it hides the service that have it's own security, it's another layer of protection (much better than password only). FWknop can be time based so it also can suffer from problems with sync but it's an option, not imposed.

The solution proposed in the article is not STO also. The security relies on the password/certificates/whatever authentication SSH uses. It's somethink like One-Time access Port, to compare to One-Time Password.

The proposed solution has some troubles to account for (time) but can also be a promising kind of concealment solution.

Time to break out infinities

[mattr]

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.

Re:Time to break out infinities

[rjames13]

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.

The problem with using either floating point or transinfinites is in how are they encoded. If I say that the port is number 1.326 that still needs to be encoded back into binary. If you say Aleph-Null + 256. Aleph-Null requires more bits to transmit than say a tillion trillion bit per second connection for a trillion trillion years could carry. Now that is a lot of bits but Aleph-Null is always more bits than are possible to transmit because it is so big. Aleph-Null is larger than every point in the Universe being a bit for the entire lifetime of the Universe. You might think why not encode Aleph-null as say a smaller sequence of bits but then that is no better than just adding more bits to the port addresses.

If you take Aleph-Null as a concept like the words I just used it lowers it's size to a finite number. If you try and get Aleph-Null as an actual number then it is just 111111111...infinity. BTW all the transinfinites have this problem not just Aleph-Null.

Re:Time to break out infinities

[mattr]

Yes, I understand. Clearly the problem is how to have your cake and eat it too. Of course if you *could* do it, it would be very cool. Maybe we should theorize an ideal computer that can access these amazing numbers, and then security is an exercise in approaching it.

Is the plain old factoring a large number problem the only answer? Could the power of a group of distributed systems together access higher security numbers for their collective security? Yes I understand unless you have the bits in your hand, you don't have the bits in your hand. But we can certainly download a megabyte of digits easily.

Well perhaps real infinities are so wild it is impossible to even theorize about being able to grab them, so I'd accept massive irrational or even finite floating point numbers. (Sorry I know I am not really fit to talk about these concepts.) I think a different method of managing port access cryptographically, or even just drastically increasing them, might be useful and am not a fan of knocking. Perhaps existing tech is enough if it is just applied to the problem.

I still wonder if there is something for us in higher maths that might open a window into much vaster spaces where it is difficult for others to go without our intentionally holding their hand. Certainly there is a problem with email addresses too, but they have to by memorizable by humans, or do they.

Re:Time to break out infinities

[rjames13]

Yes, I understand. Clearly the problem is how to have your cake and eat it too. Of course if you *could* do it, it would be very cool. Maybe we should theorize an ideal computer that can access these amazing numbers, and then security is an exercise in approaching it.

Perhaps some forms of quantum computing can approach that. Linear systems too can be used to store say fractional numbers, the problem their lies in getting the numbers back out of the system. Which is why we use non-linear computers for most jobs.

Is the plain old factoring a large number problem the only answer? Could the power of a group of distributed systems together access higher security numbers for their collective security? Yes I understand unless you have the bits in your hand, you don't have the bits in your hand. But we can certainly download a megabyte of digits easily.

I don't have the math nack to answer the first question but I certainly agree that by increasing say the number of ports by a factor of 4 to 64bits would mean that you would need to control ~18,446,744,073,709,551,616 hosts in order to bypass the system as mentioned in the article.

Well perhaps real infinities are so wild it is impossible to even theorize about being able to grab them, so I'd accept massive irrational or even finite floating point numbers. (Sorry I know I am not really fit to talk about these concepts.) I think a different method of managing port access cryptographically, or even just drastically increasing them, might be useful and am not a fan of knocking. Perhaps existing tech is enough if it is just applied to the problem.

I still wonder if there is something for us in higher maths that might open a window into much vaster spaces where it is difficult for others to go without our intentionally holding their hand. Certainly there is a problem with email addresses too, but they have to by memorizable by humans, or do they.

The main problem is that redesigning the Internet standards just to deal with this issues is the wrong approach. IMHO we should seek to patch the holes in current systems instead of handwaving new superior systems to do the job for us. Of course that doesn't mean we should stop looking at new systems, because they might solve other problems we have.

Clock drift not an issue

[StCredZero]

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

About the whole Time Sync'ing thing...

[Raven737]

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 blacklisted just the same. All it's changing is what the attacker is trying to guess.. a password used in combination with a known fact (to calculate a port) or just a password...
Cryptographically speaking they are both of equal strength since the additional key component is universally known.
but what do i know... sounds like a fun 10 minute oss hack ;)

Re:"Obscurity" tag is misleading (botnet?)

[Anonymous Coward]

So it's not like you can just try different ports until you find the right one

If you only have one IP address. Someone with a bunch (botnet anyone) can try all 48 ports,
or even all possible ports....

clock synchronization isn't needed

[Anonymous Coward]

One can simply open an additional fixed port, which would just broadcast the time on the system in question. Or, even simpler, use a standard unix time service.

K.L.M.

C3PO

[Dryanta]

I really think this whole shimmer thing (as it is not an improvement on port knocking, tumbler, or any other best practice) was just an excuse for the author to come up with something to fit that acronym. Good show old chap!

Re:C3PO

[Anonymous Coward]

Yeah, congrats on that one! :)

IPv6 Address Cookies

[Adrius]

These can accomplish something similar, except more secure and hide the entire address, not just the port. In fact they likely provide the same level of one-time usage without requiring any special clients. Clients merely need to know a secret, fixed DNS name. Of course everyone would have to use IPv6 and there aren't any practical applications available yet.

Info here.

Other Options for SSH

[Zaphoddd]

This is not the same, but as others have suggested it helps keep the kiddies at bay; We've implemented a "Failure Penalty Timer" (my term) pam_delay - for SSH. Failing authentication on login makes the user wait a long time (seconds to minutes) before being allowed to try again. For a legitimate user this is at most a slight annoyance. But.. To a scriptkiddie - it generaly makes the target not worth it, and for a bot the same thing. 20 tries a minute - turns into 1 try every 2 minutes or worse. Its not making the server more secure in the purest sense; but in practical terms its akin to locking your doors or a wheel lock - its not going to stop a determined crook, but for a random bandit it will make your asset much less attractive We still get the tries, but only one or two per haxxer;

Use ssh-faker instead

[Anonymous Coward]

Instead of going to all this trouble, simply use ssh-faker (http://www.pkts.ca/ssh-faker.shtml) and you'll achieve at least the same level of security with a whole lot less hassle.

With ssh-faker, all ip addresses are denied access to sshd until the connecting machine provides the proper ssh-faker password. At that point, ssh-faker inserts an entry in /etc/hosts.allow to allow that one particular IP address access to sshd. Then, you connect again using ssh and get sshd instead of ssh-faker, and you log in.

Advantages over this system:
A lot simpler to impliment. Sshd already uses tcpd and /etc/hosts.allow /etc/hosts.deny for IP granularity access controls. So installing ssh-faker involves a one line change to /etc/hosts.deny and you are done.

No need for any special client software at the remote end in order to be able to connect to your system. You just need a working telnet program and you can insert your current IP address into /etc/hosts.allow.

Absolutely no "lucky guess" aspect. With 48 ports open, three of which are "valid", a hacker has a 3 in 48 chance of randomly guessing the correct, operational, ssh port, at which time the only security you have remaining is the strength of your passwords (if you allow password based ssh logins).

This can be mitigated by disallowing password based logins, but doing so means you "must" carry your ssh-key data with you everywhere you might need to log in from. Ssh-faker gives you the security of a password-less login sshd without the need to carry your key data with you (and be able to make use of it).

Disadvantages of ssh-faker:
1) You need to have a working perl interpreter on the machine running sshd. No big deal on a full PC box, but might be a problem on low memory embedded systems.

2) You will need to connect twice from where-ever you are, first with a basic telnet to input the ssh-faker password, and a second time with your real ssh client to log in. Not such a big deal for all of the advantages provided.

3) The ssh-faker password is sent as cleartext. This leaves it open to a sniffing attack. But, keep in mind that this shimmer system as a 3 out of 48 chance of random guessing. A sniffing attack requires an actual attacker located on a link along the way sniffing your data to locate your ssh-faker password. If you are being targeted with this level of precision, well, you most likely have bigger problems that neither ssh-faker nor shimmer will cure. Note also that the ssh-faker password is only sent once per each new IP you are using. Once an IP is inserted, you don't need to resend the password. So an adversary must be interested and sniffing exactly when you once enter your ssh-faker password. Any other time, and she is out of luck.

No, that *is* the reason for this approach

[billstewart]

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 trying to scan random ports anyway.

Your Objection 2, that we also have to test this, is correct, but it's relatively simple testing on a relatively simple program that doesn't have any actual powers to grant the attacker except the ability to forward packets to 127.0.0.1:22, as opposed to sshd which lets you login to the host, potentially as root, and has lots more features and therefore lots more potential holes. If it's not buggy, it'll keep 93.3% of the crackers from bothering you once and keep 6.6% of them from bothering you for more than a minute, which makes it a lot harder for them to do successful attacks and cuts down on the junk in your sshd logfiles. (I assume it's got its own logfiles, but you're mostly not going to watch them for more than a week or two.)

Use a different network to delete blocks

[ccguy]

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 in the text unblocks it, and you are set. That's what I use and it works pretty well, if I screw up it just costs me a few cents to get back to normal. In fact my (quite trivial) script can do a few other things as well as opening ssh to a particular IP (such as rebooting).

umm... bad idea.

[debatem1]

Listen, I like the idea of default drop as much as the next guy, I use fwknop all the time, but this is ridiculously easy to lock somebody out of. all i have to do is know the ip address you are logging in from and I can send one spoofed packet every 15 minutes to keep you out, and in the meantime, I can be spoofing 16 other ip addresses to brute force your password. sure, it makes me burn up ip addresses real quick (15/16 wind up being blacklisted immediately) but after 15 minutes it's ok again, and in the meantime, you can't do anything to correct the problem. if you want to secure against brute force, use snort- not cheap tricks.

New shimmer

[NaDrew]

So let me get this straight. It's a dessert topping and a floor wax?

No, it isn't. (Re:Isn't this port knocking)

[RedBear]

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.

You misunderstand the purpose of port hopping. Port knocking is simply a way of telling the server to open a port and let you through. Once that port is open it could be found by port scanning and attacked just like any other static open port, for as long as you keep it open. The longer you hold the port open the less effective the port knocking is security-wise. Port hopping is adding another layer of security through obscurity by moving the open port around randomly according to an algorithm governed by a shared secret, like with one-time pad encryption. Your system always knows which port to use next as long as you stay in time sync with the server.

If a port scanner happens to stumble on the open port at some point it's much less of a problem because that service won't be on that port a minute later. Any subsequent attacks on that port will simply be discarded or logged, and the same port probably wouldn't be reused for at least several hours.

This is basically the same as digital spread spectrum frequency hopping, a technique co-invented in the 1940's by actress Hedy Lamar forty years ahead of its time and meant to increase the security of things such as war-time military communications. DSS is in common use today in cell phones and household cordless phones. With phones you only have a few different frequencies to hop through so it's normally used as less of a security feature and more to keep nearby devices from interfering with each other. With TCP/UDP ports on the other hand you've got around 65,000 to choose from. So if you do a good job blocking any IPs that attempt to run fast port scans on your network it will be almost impossible in the limited amount of time to:

- scan the entire port range on the target system,
- identify open ports,
- identify the service on that port,
- identify the operating system,
- exploit the service successfully, and finally
- successfully run the correct sequence of commands on the exploited system that would give the attacker full access to the system even after the next port hopping cycle begins.

Sure, it may still be technically possible, but it's a lot less likely when using this technique that any attack would ever succeed beyond the part where it crashes the service. You'd have to have an army of computers (at least 30,000 or so) all around the internet and somehow coordinate them all to probe the target network on non-overlapping random ports at the same time. Even doing one scan every few seconds they would probably overwhelm most connections and eventually be detected and blocked.

Another firewall system set between the server and the internet could be set up to block any statically open ports coming from the target server and even to disable any port hopping sequences that don't fit in the currently active port hopping scheme, thus disabling most backdoor exploits from being functional for more than at most 60 seconds or so. So the only attack that could possibly continue to work beyond the initial exploit of the service would be one that manages to discover the port hopping shared secret and become part of the active port hopping scheme. Basic security precautions like giving the shared secret file a random name and location and restricting its permissions should keep that from happening too easily. Every other type of attack just becomes practically impossible, despite being technically po