Slashdot Mirror

Security through obscurity?

It doesn't matter what port SSH is on. If an attacker is even remotely interested he'll run a port scan and find your SSH port soon enough.

Better to invest your time into properly configuring/locking-down SSH. Good luck to any attacker trying to gain access if you only allow authkey access. Putting SSH on a different port is only giving you a false sense of security.

Sir –

There are valid reasons to move the SSH port around, including:

1. It decreases the number of "script kiddie" attempts that do not look beyond the standard port for a known exploit (i.e. your server is no longer "low hanging fruit"); and

2. You can react to a port-scan from a single host - e.g. by blacklisting the IP the portscan came from.

Sophisticated, dedicated attackers can get around these. However, the vast majority of attempts will be made by people who are neither sophisticated nor dedicated (depending on what you're securing, of course).

All to say, moving the port around isn't just security through obscurity. It decreases the statistical phenomenon of unwanted access by a measurable degree by slightly raising the difficulty of detecting and exploiting a given service. I completely agree, though, that this ought not give a heightened sense of security - the SSH server ought to be appropriately hardened. Nevertheless, where there is an exploit of the SSH server (of which there are examples) in the wild, you may reduce your chances of your server beng exploited before the exploit is fixed by operating on a nonstandard port.

A better alternative to a non-standard port, for those so inclined, is port knocking.

http://en.wikipedia.org/wiki/Port_knocking
http://www.portknocking.org/

Just to follow onto your comment.... I'm actually surprised this hasn't been a bigger deal in distros. Port knocking is a fantastic way to virtually eliminate these sorts of threats.

For a home server, this one's nice and easy to use:
http://www.zeroflux.org/projects/knock

ISPs may want to run an SPA tool like fwknop, allowing each user to have their own code:
http://www.cipherdyne.org/fwknop/

I personally use knocking on my home server as if I'm really in a bind, I can attempt to use the local telnet client rather than having to have a program to create the magic packet.

While I've heard talk of it, I haven't actually seen any software that ties together with ssh (or login) that only allows the user from a particular IP to log in. That'd really be the ideal thing for ISPs or any system with lots of users. This way, even if you hack one of the codes, you still have to know which user that code is for. And of course you still have all of ssh's normal authentication mechanisms you have to go through.

references:
http://en.wikipedia.org/wiki/Port_knocking
http://www.portknocking.org/

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.

"Once I moved the server to a different, more _obscure_ port, though, my logs rarely show any connection attempts."

You are still visible, a port scan will show it - it's not *obscure*. If you want *obscure* you should consider port knocking (http://www.portknocking.org/) or such other methods.

"I'm a creationist, and I'm not out of touch. For me, the incalcuably small probability of spontaneous generation of a lifeform able to be nourished by it's environment and then able to reproduce is not a large-enough foundation on which to build a scientific consensus."

Not wanting to downplay your beliefs, I find it a much much smaller probability the possibility of spontaneous generation of an entity able to create life by design.

and last but not least

3. install a port knocking daemon, like fwknop, or knockd

I was looking at a solution like your #3 (DenyHosts), but although it would be effective against dictionary and brute-force attacks it offers no protection against a newly-discovered or unpatched security flaw in the OpenSSH server.

I kept looking and fell in love with port knocking. There are many implementations and variations on the concept floating around, but the single best source of information that I found is at http://www.portknocking.org/ which in addition to an entire education on the topic, offers a very good free Perl implementation that the author walks you through the workings of, plus links to many other implentations.

The drawback to this is that you need to keep available a port knocking client in addition to an ssh client, which may be awkward if you need to connect from many different workstations (or especially while traveling), or if you have many users who need to connect.

Personally, I find port knocking useful in providing an extra layer of security.

Some of the systems that I am responsible for, have restrictions on when and how I can apply patches. So if a vulnerability is discovered, if I cannot patch it right away, I am relying on my FireHOL and port knocker to protect these systems. Since implementing these measures (and good security policy), none of these machines have been compromised in three years.

Of course, saying that, I probably just jinxed it...

A lot of these exploits are typically ancient worms that someone has managed to not clean off their computer. If it's not an ancient worm, it's probably a zomibe in someone's hoarde.

The problem with these two (most common) scenarios that the person who owns the computer isn't the real perpetrator, and the ability to track the perp down requires much more work than a simple whois lookup of the offending IP.

Most attacks you see are going to be automated and launched on a wide scale. There are thousands and thousands of compromised Windows machines out on the net that are being used by people such as spammers and crackers for their dirty work.

Lock your box down.
Don't allow root to log in on SSH.
Lock SSH and other sensitive services down to specific IP address blocks if you can. If you can't, investigate port knocking if you can do that. If you can't even go that far, investigate implementing a lockout policy for failed login attempts.

Unless you see a single host being the source of a large pile of offensive behavior, chances are these are machines in a zombie hoarde. If it is limited to a single IP or a few IP's in a single C class, contact the ISP's abuse department *politely* (remember these are folks like you in jobs like yours, if you go in with guns blazing, they're less likely to help) and provide as much information as you can regarding the nature of the attack. Then firewall off the offending IPs.

I used to aggressively track intrusion attempts and spam. I had a little PHP/MySQL tool I wrote where I could log these things, dumping in offending logs (or spam source), and it'd extract the culprit IP address, and once a day go through, looking up abuse addresses on whois and mailing a digest of the day's activities for that ISP to them.

Ultimately I probably got about a 1% response rate from the ISP's (excluding auto-responses). After ~6 months of this, and about 40,000 records in my database, I started some statistical analysis. It turns out that there were no significant outliers for abusive activity from any given ISP (considering the size of that ISP's net blocks). Basically every intrusion attempt was some kind of zombie. There were probably a few by-hand attempts, but these are typically so low profile that there's no easy way to distinguish them from the hoardes.

Some time later I was the recipient of a DDoS attack. Someone's zombie hoarde decided to repeatedly visit a page on my website that turns out to be a bit resource intensive to generate (my code is open source, so whoever devised this probably knew that). Every day, ~25,000 IP's each requested the same page every 4 minutes (+/- a few seconds I suppose for network latency). 375,000 hits an hour = 9,000,000 bogus hits a day. Day to day this number fluctuated, and the ISP's involved in the attack kept changing. It was obvious to me that whoever was driving the attack wasn't exposing the entire zombie hoarde to me at any given point because of how the ISP's involved kept shifting around. I figured he probably had a script set up to launch X number of zombies every day, and they probably had commands to execute for ~24 hours. The number was always pretty close to 25,000, never over, but usually more than 24,500.

Ultimately the attack lasted about a month. I figured out a simple way to distinguish the zombie computers from legitimate users based on an error in the request headers, and I could just exit() at the top of my site for those who exhibited this error. I also logged the attempts I blocked, and was left with over 900,000 distinct IP addresses once the attack finally stopped.

My point in all of that is that there *are* zombie hoardes out there, and it's the zombie hoardes that are most likely to compromise you. There's little you can do about it because getting a single IP from a hoarde firewalled off or cleaned up won't slow down your real attacker who was going to use a different zombie the next day anyhow.

Yes yes... that would be a good idea. Get Knoppix, run it on an old PC or something, route port 22 to that machine and enable ssh. Don't forget to set root password "root", you wouldn't want to make it too difficult, would you? ;-) Imagine the attacker's face, when he/she found out everything is on a CD! As for your real SSH, maybe you want to give portknocking try.

A list of one-time passwords & a simple daemon, that verifies them & enables ssh access (in some high level language) at the user request would do as fine. Give such daemon some IQ, so it would make brute-force attacks very hard, and you have the same thing. Except for the "cool" part.

Why not just mod me up instead? I provide links!

"This port need not be open -- since knockd listens at the link-layer level, it sees all traffic even if it's destined for a closed port." This is from the page of the implementation this article is about.

Also, the first sentence from portknocking.org: "Port knocking is a method of establishing a connection to a networked computer that has no open ports." A little further down on the page: "This is a form of IP over closed ports."

Also, you may wish to read the FAQ: http://www.portknocking.org/view/faq.

This is only implementing basic static knock sequences, but it could (and likely will) be further developed to support cryptographic knocks that are embedded with other data, such as which port to open.

The guy at portknocking.org has a good example of how to do this.

check it out

www.portknocking.org

Note the encryption/hash of the ports, source IP, and port to be opened.

www.portknocking.org/view/documentation
There is a Perl reference implementation. (GPL'd, of course)

"I am in no way affiliated with this group."

www.portknocking.org

Note the encryption/hash of the ports, source IP, and port to be opened.

www.portknocking.org/view/documentation
There is a Perl reference implementation. (GPL'd, of course)

"I am in no way affiliated with this group."

You'll find some more stuff on http://www.portknocking.org...

Lots of info available via a google search...

A few implementations here.

I don't think will be very useful/valuable until clients (such as ssh) have it built in. I don't feel like going through the hassle each time I want to connect. Though it would keep comcast from discovering my ssh service...

http://www.portknocking.org/view/about/obscurity

It does a much better job of explaining this than anything yet posted here.

it seems there already is a bunch of specialists working on it - well experienced in knocking the 80th one. Wish they open the door one day, though.