SSH Password Gropers Are Now Trying High Ports

badger.foo writes "You thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port? It seems security by obscurity has lost the game once more. We're now seeing ssh bruteforce attempts hitting other ports too, Peter Hansteen writes in his latest column." For others keeping track, have you seen many such attempts?

Comments

Low Hanging Fruit

[Nerdfest]

It's still just going after low-hanging fruit. Anyone weth any real awareness of security does now allow password-only SSH connections anyway. Key based auth and fail2ban is pretty much required these days. You can always add some port knocking to obscure it a bit if you don't like reading about failed access attempts.

Re:Low Hanging Fruit

[bcmm]

And the bots are REALLY stupid. I have more than one internet-connected machine with a key-only sshd open to the internet, and, infuriatingly, they try to brute-force it anyway. That is, even though they don't even get a chance to offer a password, they still make multiple attempts to connect...

Re:Low Hanging Fruit

[DaveAtFraud]

I've been using key based authentication for ssh for years. I just moved the service to a high port to get rid of all the script kiddy password guessing attempts that were clogging my log file. I also added a "throttle" in iptables:

# Block brute force attacks
# Drop repeated ssh connection attempts within 20 seconds interval
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j DROP --rcheck --seconds 20 --name THROTTLE --rsource

# Accept ssh connection if not attempted within past 20 sec.
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j ACCEPT --set --name THROTTLE --rsource

It just cuts down on the noise. I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).

Cheers,
Dave

Re:Low Hanging Fruit

[Anonymous Coward]

Good. Now if I know your IP address I can deny you access to your server.

Re:Low Hanging Fruit

[Anonymous Coward]

But you don't, so he's safe sharing his secrets.

Re:Low Hanging Fruit

[cstdenis]

You can brute force a key to....it just takes much, much, much, much longer....

Re:Low Hanging Fruit

[larry bagina]

Just think -- if it was open source, you could submit patches to make it more effective. They're basically fucking themselves over by keeping it closed source.

Re:Low Hanging Fruit

[Anonymous Coward]

They're probably also trying for known (fixed) remote vulnerabilities, hoping to find an unpatched server.

Re:Low Hanging Fruit

[Anonymous Coward]

Actually, he could. Every 20 seconds he sends a failed authentication attempt with a forged source IP that matches Dave's.
Dave is now effectively locked out of his system.

captcha: capable

Re:Low Hanging Fruit

[lophophore]

I like that. Thanks for sharing!

Re:Low Hanging Fruit

[kiddygrinder]

while it's theoretically possible it's not really worth considering, especially when you're only giving them 4 attempts an hour.

Re:Low Hanging Fruit

[houghi]

I use http://www.aczoom.com/blockhosts.
Just remember: never rely on only one line of defense.

I do not run anything on a high port, because to me that is security through obscurity. Blockhosts I also only use to keep the noise down.

As it looks now, I might just start white listing IPs and turn that off when I am traveling or look at knockd. Again this is security through obscurity.

Re:Low Hanging Fruit

[Anonymous Coward]

You can't really spoof TCP connections.

Re:Low Hanging Fruit

[KiloByte]

DROP means regular TCP retransmit will defeat your throttle without the cracker having to do anything.

I'd instead use REJECT.

Re:Low Hanging Fruit

[Anonymous Coward]

Actually you can just as easily as UDP connections. The packets get routed the same way after all.

Either you have some other way of receiving the responses (source routing or packet sniffing), or you simply don't care about receiving the reply.

The above iptables rules would get triggered by the SYN packet before the SYN-ACK reply is sent. So to trigger the block all you need to do is send a load of SYN packets spoofing his IP as the source address. The SYN-ACK is never received so the connection never opens, but you've already managed to block him access so that doesn't matter.

Re:Low Hanging Fruit

[DarwinSurvivor]

REJECT tells them you've detected them, the not-so-dumb ones will use this against you.

Re:Low Hanging Fruit

[jgrahn]

I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).

Except if they're all behind NAT; then you're hurting legitimate users.

Re:Low Hanging Fruit

[SuricouRaven]

It's actually quite hard to spoof anything now. No domestic connection will forward packets that don't from from the designated IP address. You need to have access to either the LAN of a decently-sized corporation or the internal network of an ISP. Easy enough for skilled hackers to get, yes - they can compromise a device somewhere - but beyond the script kiddie.

Re:Low Hanging Fruit

[Anonymous Coward]

I use http://www.aczoom.com/blockhosts.

I do not run anything on a high port, because to me that is security through obscurity.

It won't prevent a dedicated hacker so you might as well not do it? What?
Using a high port is one more thing you can do. To me, using it to filter out 90% of scanners is worth it even though it will still let through the 10% of people scanning high ports. You still need something more effective in place, of course, but there's no harm in adding another defensive layer.

Want a car analogy? Leaving your window rolled up is another measure you can take to prevent your car from being stolen. Will it prevent a highly motivated individual? No, they can still break your window. But the other people who are looking for easy targets will probably move on to the next car.

Re:Low Hanging Fruit

[Pseudonym]

I do not run anything on a high port, because to me that is security through obscurity.

I do, but not because it adds security. I do it for the same reason as you use blockhosts: it makes the logs less noisy.

Oh, it also saves traffic.

Re:Low Hanging Fruit

[Pseudonym]

Using a high port is one more thing you can do. To me, using it to filter out 90% of scanners is worth it even though it will still let through the 10% of people scanning high ports.

Exactly this.

Using a high port will not prevent a determined act of corporate espionage, but it probably will make J. Random Script-Kiddie move on.

Re:Low Hanging Fruit

[Enry]

So you're saying that security through obscurity works?

Re:Low Hanging Fruit

[jamesh]

It's still just going after low-hanging fruit. Anyone weth any real awareness of security does now allow password-only SSH connections anyway. Key based auth and fail2ban is pretty much required these days. You can always add some port knocking to obscure it a bit if you don't like reading about failed access attempts.

There is nothing magical about keys, they are nothing more than very very long passwords that you can't type in if you ever need remote access from a machine that doesn't have your private keys on it.

If your passwords are good then ssh bots won't guess them, and fail2ban will make sure they don't get enough attempts to try.

Re:Low Hanging Fruit

[budgenator]

I'd use TARPIT instead.

Re:Low Hanging Fruit

[PlusFiveTroll]

Yes, as part of a defense in depth and not as a measure by itself.

Re:Low Hanging Fruit

[RedHackTea]

Why don't we just write a script to check emails. We email ourselves a specific time, e.g., "11:00". Allow SSH login attempts at 11:00 for 10 min. If no one logs in, then now drop SSH. Wait for next email. Here, hackers have to know your email (script only checks emails from yourself), your email's password, your SSH password, your time zone, and the format of how to send the time to your email. And theoretically during this window, they shouldn't be able to bruteforce in 10 min.

Re:Low Hanging Fruit

[Pseudonym]

I'm saying that just because an obscurity measure is no substitute for a security measure doesn't mean it's not worth doing.

A sysadmin's time is valuable. A simple measure which eliminates 90% of the noise in a log is almost always worth doing, especially if it doesn't significantly inconvenience legitimate users.

Re:Low Hanging Fruit

[v1]

That is, even though they don't even get a chance to offer a password,

you sure you don't have PAM on? it's enabled by default on some systems, and gives them a different way to provide a password.

From looking at the logs though, it was always the same way here. (before I moved ports) Trying a very limited number of specific usernames and passwords. (looking for common services like www and daemon, as well as common usernames like admin and john) On the other hand, if they really are trying to brute-forcing you, you're being specifically targeted and should review your security immediately.

Re:Low Hanging Fruit

[Chewbacon]

Add fail2ban and clean up your log. I've been using key-authentication for outside my LAN and was still getting hundreds of brute force attacks a day. After adding fail2ban, I see about a dozen attempts and 2-3 bans a day.

Re:Low Hanging Fruit

[Anonymous Coward]

Read what's being discussed. Security through obscurity doesn't protect you from anyone who was likely to succeed in breaking in in the first place, but it filters out a lot of noise you don't need to see.

Re:Low Hanging Fruit

[DigiShaman]

Isn't anti-hammering pretty much the standard these days? I'm shocked some fuzzy logic isn't being used in this regard. Variables such as IP country location, time of day, and reputation should calculate how strictly or relaxed the attempt-per-hour authorizations should be.

Re:Low Hanging Fruit

[hedwards]

It's not security by obscurity, I really wish this meme would die, seeing as so many people are misapplying it. This is one thing that you can do to make it more expensive to try and crack your systems. It's not the only thing that you should be doing and calling one technique security by obscurity when you can easily figure out which port it is, really just conveys ignorance about what you're talking about.

Anything you can do that makes it inconvenient to try and crack your system is going to help a bit.

Re:Low Hanging Fruit

[icebike]

Not sure pam gets a chance if your sshd_config specifies
PasswordAuthentication = no
ChallengeResponseAuthentication = no

Most installations default to UsePAM = no, or turn both of the above off.

Re:Low Hanging Fruit

[Anonymous Coward]

I imagine that a legitimate user will eventually report it, and with the help of a competent admin, they'd be able to figure out the NAT situation. They you can report it to your ISP, and they'll at least be able to notify someone that their machine has joined a botnet .... then nothing will change so yeah, you're right.

Re:Low Hanging Fruit

[DaveAtFraud]

I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).

Except if they're all behind NAT; then you're hurting legitimate users.

Walk your way through what happens when multiple users from the same location attempt to access my site. The first one attempts to resolve my IP address and his DNS server gets a response. The only way someone might be inconvenienced is during the brief window between that first request and when the requester's DNS gets my IP address. If another user tries to access my site before my DNS responds to the first request, their DNS server will not get a response for their request but will get a response for the initial request. When their DNS server retries the address request, it will find my address already in it's cache and will respond to the subsequent request.

At worst, a user who just barely gets beat to generating their request for my site might notice a slight delay before their request is retried and gets resolved by THEIR DNS. I'd hardly call that "hurting legitimate users". The basic concept here is that DNS caching logic should normally prevent multiple requests from the same source whereas cache poisoning generates multiple such requests.

Cheers,
Dave

Re:Low Hanging Fruit

[Anonymous Coward]

This. And in fact if someone needs fail2ban to protect their password against brute-force attacks, they should just use a bigger keyspace instead. True security layering would layer technology/implementations, such as requiring VPN+SSH. All this work to reduce attack time on passwords suggests that people don't understand password security to begin with.

Re:Low Hanging Fruit

[RocketRabbit]

I'm sorry but most people, even with awareness of security, still allow password-only SSH. As long as a strong password is chosen, and the SSH daemon increases the wait time between login attempts, password-only SSH is not a security problem.

Re:Low Hanging Fruit

[Anonymous Coward]

So you re-invented the iptables 'limit' rule. Maybe you should read the man page to look for all the new features of the past 20 years or so.

Re:Low Hanging Fruit

[DaveAtFraud]

Looked at limit. Thanks for the somewhat snarky pointer. I still like my solution because of the control it gives me over the "disallow" rule as it is a separate rule; not a rate limit on the allow rule.

I'm an old perl monger so the fact that "there's more than one way to do it" is a feature not a problem.

Cheers,
Dave

Re:Low Hanging Fruit

[mysidia]

It's actually quite hard to spoof anything now. No domestic connection will forward packets that don't from from the designated IP address.

This is simply not true. Most providers do not implement BCP38. Some ISPs do, some ISPs don't. It's trivial to spoof a single TCP packet. You don't need to spoof the actual connection to use that iptables rule to create a DoS condition.

It doesn't matter though... it's trivial to create exceptions to that iptables rule, by inserting ACCEPT statements before it.

Re:Low Hanging Fruit

[Anonymous Coward]

nah, this just makes attacking my box through bruteforcing take 7 thousand years vs 70.

Re:Low Hanging Fruit

[Anonymous Coward]

So you're saying that security through obscurity works?

If you're going to chant a mantra and feel smug and clever, then you should probably get it right. The correct saying is: "Do not rely ONLY upon obscurity."

Re:Low Hanging Fruit

[Anonymous Coward]

And the same is true for strong passwords. So what?

Re:Low Hanging Fruit

[Z00L00K]

Add to it the method to run SSH on some standard port like the chargen port or something.

A more intriguing way would be to have a rotating scheme of some ports in your server and that you know that when "current hour" % 4 == 2 it's the chargen port for SSH, otherwise the chargen port just generates characters. Of course - this only works if you are a few users on that system with ssh access. But it will at least cause some trouble for the port scanners since they need to determine if the answer is valid or not.

Re:Low Hanging Fruit

[Anonymous Coward]

This has nothing to do with security by obscurity. Security by obscurity refers to hiding the mechanism rather than the key(s)/secret(s) used in this mechanism.

Re:Low Hanging Fruit

[Dahamma]

It absolutely works. Obviously it's not foolproof and should not be relied on as the only security measure, but if it adds enough time/complication/etc that it's just easier to move on to an easier target it does greatly reduce the chances of a successful attack.

Re:Low Hanging Fruit

[Anonymous Coward]

You mean I have to stop using telnet?

Re:Low Hanging Fruit

[UltraZelda64]

And the bots are REALLY stupid

Is that really a bad thing? You should be thankful that they're dumb as fuck... stay silent, don't criticize, and maybe they'll stay dumb. Let your criticism get into the wrong hands and someone just might read it and take it as "suggestions" to improve their "product"... and then you might end up with real problems, and end up back here bitching that their bots are getting better at evading your security mechanisms...

Re:Low Hanging Fruit

[Anonymous Coward]

Remember many hubris deb1an people used to praise key auth as unbreakable ;)

Re:Low Hanging Fruit

[drinkypoo]

It's actually quite hard to spoof anything now. No domestic connection will forward packets that don't from from the designated IP address.

This is simply not true. Most providers do not implement BCP38.

I have spoofing protection at my router, you insensitive clod! My connection won't forward packets that appear to be coming from addresses used on the inside. Who cares if they spoof my addresses? I won't accept their traffic in any case.

Re:Low Hanging Fruit

[AlphaWolf_HK]

Better than port knocking is single packet authorization.

http://www.cipherdyne.org/fwknop/docs/SPA.html

Unless they have either a correct password or gpg private key and an exact port number and protocol, they aren't even going to have the slightest idea that a computer even exists at the IP address they are scanning.

Re:Low Hanging Fruit

[fa2k]

Anyone weth any real awareness of security does now allow password-only SSH connections anyway. Key based auth and fail2ban is pretty much required these days.

I consider myself quite aware of security problems, but I do have a publicly* accessible box with two users which can log in with randomly generated passwords, one 8 characters and one with 10. I do always set AllowUsers, to prevent any surprises. The bots haven't even guessed my username yet, but a human could easily guess that. After that they would have to make about 60^8 = 168 trillion attempts to guess the p/w. That could happen locally on multiple GPUs, but it's not even worth computing how long it would take over a crappy DSL connection. And of course, sshd has some built-in delays too. Please let me know if there's something I'm missing. The only reason I got so defensive is that I'm a bit worried..

* The computer is only on IPv6, which for now reduces the number of bots, but I can't rely on that.

Re:Low Hanging Fruit

[allo]

they will use it, to stop trying. win-win.

Re:Low Hanging Fruit

[GameboyRMH]

4 per hour? I give them 10 per week.

Re:Low Hanging Fruit

[Dr.Dubious DDQ]

Am I mistaken, or does REJECT give the same response as you'd get trying to connect to a TCP port with nothing listening to it (making it appear as though sshd wasn't even running, without alerting the connecting side that the port is "filtered")? I always assumed that the problem with DROP was that packets just disappear from the sender's side's point of view, which seems to not deter most of these scripts from continuing to try. (On the other hand, DROP has the benefit of cutting down on outgoing traffic a bit, but I'm under the impression this is mainly a benefit in Denial-Of-Service situations or extremely constrained bandwidth rather than annoying but not overwhelming brute-force password-guessing attempts.)

Re:Low Hanging Fruit

[v1]

with those settings, interactive passwords will be disabled but not tunneled. pam must be disabled to prevent tunneled passwords.

Re:Low Hanging Fruit

[Z00L00K]

I have a different filter that contains counter depending on source address:

-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ssh
-A blacklist -m recent --set --name blacklist --rsource
-A blacklist -j DROP
-A ssh -m recent --update --seconds 60 --hitcount 1 --name blacklist --rsource -j DROP
-A ssh -m recent --set --name counting1 --rsource
-A ssh -m recent --set --name counting2 --rsource
-A ssh -m recent --set --name counting3 --rsource
-A ssh -m recent --set --name counting4 --rsource
-A ssh -m recent --update --seconds 20 --hitcount 3 --name counting1 --rsource -j blacklist
-A ssh -m recent --update --seconds 200 --hitcount 6 --name counting2 --rsource -j blacklist
-A ssh -m recent --update --seconds 2000 --hitcount 9 --name counting3 --rsource -j blacklist
-A ssh -m recent --update --seconds 20000 --hitcount 12 --name counting4 --rsource -j blacklist
-A ssh -j ACCEPT

This limits the number of attempts an intruder gets from a single address before I start to drop traffic.

Re:Low Hanging Fruit

[smash]

This. I don't use fail2ban, but require usage of a secure VPN before being allowed to hit SSH. I simply do not allow SSH to be hit from outside at all. But yes, if you do not have other infrastructure in front of your box, allowing SSH only from known administrative IPs or IP ranges (at least) and using something like fail2ban is a very good idea.

Moving to a different port number is no real defence at all. Sure, it might avoid REALLY bran dead automated attackers, but thinking you're safe is very much a case of a false sense of security.

Re:Low Hanging Fruit

[Anonymous Coward]

And that's why you don't waste a sysadmin's time with moving stuff to obscure ports to make logs more readable. You have your logs read by a machine, e.g. with logcheck(1). Or maybe even sec(1). Then you can focus on the important stuff.

Re:Low Hanging Fruit

[Anonymous Coward]

Just keep in mind that every measure has a cost. Do youn know what is its cost? (Is it a public server? If it`s your home server you are the one facing the cost of your mesures, thus you know it.)

Re:Low Hanging Fruit

[hobarrera]

How would I check what goes wrong when my email server dies (which is what actually happened to me this morning)? I'm basically locked out forever.

Re:Low Hanging Fruit

[Anonymous Coward]

Now, since this is slashdot, I know it's a stretch for you to have RTFA, but you could at least have RTFSummary wherein it says that script kiddies are now scanning and brute-forcing high ports.

Re:Low Hanging Fruit

[DarwinSurvivor]

Most firewalls DROP by default so most scripts are designed to only try connecting a couple times. If you REJECT, they'll think that the port is *normally* open and try other things (such as hitting you again later).

Re:Low Hanging Fruit

[Garridan]

Security through obscurity works for me! I try to keep my passwords obscured from public view. If I told everybody that my password was CmdrTacoLover99, my account wouldn't be terribly secure anymore.

Re:Low Hanging Fruit

[Garridan]

Crap, how do you delete posts?

Re:Low Hanging Fruit

[Cramer]

Technically, it wasn't. Everyone having the same key (or nearly so) is a very different problem. A well constructed, unique key is quite secure.

Re:Low Hanging Fruit

[Anonymous Coward]

add about a hundred million more "much" and then....you are still way too low.

Re:Low Hanging Fruit

[Anonymous Coward]

this reduces scanning by about 90% as others have said. hardly just a little.

Security by obscurity ...

[Kardos]

.. is rarely the way to go, however port knocking would go a long way in terms of thwarting brute force guessing.

Most of the intrusion attempts on my machine are from APNIC. Is there a good way to block any attempt originating in Asia?

Re:Security by obscurity ...

[Stormthirst]

My defenses include:
Adding ALL : ALL to my hosts.deny
Adding the ranges I want to allow access to my hosts.allow
Denying root access

I'm also hoping to start using a Yubikey for password authentication, just waiting for my hardware token to arrive in the mail.

Re:Security by obscurity ...

[Stormthirst]

And yes - most of the hack attempts I'm seeing are coming from China

Re:Security by obscurity ...

[Anonymous Coward]

The advantages (were) of using high ports for obscurity was that at least you dont get flooded/ddos'd with break in attempts. It's not unusual to see gigabytes of data usage per day from ssh connection attempts and evne using fail2ban with iptables rules only helps so much as the bots are slow/stupid and don't give up in a hurry.

Not so great if you pay per GB for your internet.

Re:Security by obscurity ...

[deains]

Correction: most of the hack attempts you're seeing appear to come from China. I expect it's likely most of the attacks would come from botnets, which thrive in China thanks to the high adoption rate of pirate software. The actual hackers could be anywhere.

Re:Security by obscurity ...

[Anonymous Coward]

We are talking about banning ranges of IP addresses. Only the last leg of the journey matters. Saying the attackers aren't in China is a difference without distinction.

Re:Security by obscurity ...

[Peter H.S.]

Denying root access

I'm also hoping to start using a Yubikey for password authentication, just waiting for my hardware token to arrive in the mail.

"Yubikey" looks very interesting. I have been thinking about two-factor and OTP hardware to increase my security, but I wasn't aware of actual implementations that worked for Linux.

Re:Security by obscurity ...

[Stormthirst]

Agreed.

Re:Security by obscurity ...

[doohan]

I've been using google authenticator for a year or so on my linux boxes. It was pretty easy to set up too: https://code.google.com/p/google-authenticator/wiki/PamModuleInstructions

Re:Security by obscurity ...

[Stormthirst]

We have them for work, but they are only firmware 2.1 so you can't use them for Windows authentication

Re:Security by obscurity ...

[Pseudonym]

Most of the intrusion attempts on my machine are from APNIC. Is there a good way to block any attempt originating in Asia?

On behalf of Australia and New Zealand, I'd like to point out that you should be careful what you block. We might be interested in your web site.

Re:Security by obscurity ...

[ultrasawblade]

If it's a Linux machine consider using nfblock. You'll need to hook it into iptables using an NFQUEUE target. You'd also need to find the APNIC IP ranges and put them in a blocklist.

Re:Security by obscurity ...

[PlusFiveTroll]

https://www.countryipblocks.net/

Then pick a format you want to block with. I personally use the shorewall firewall and put them in the blacklist and keep all the traffic out (that wasn't requested by me first)

Re:Security by obscurity ...

[Anonymous Coward]

And you express that interest by trying to log into his sshd?

Re:Security by obscurity ...

[Pseudonym]

No. Moreover, this is perfectly consistent with the advice "be careful what you block". I have blocked whole countries from all access on occasion. Sometimes that's a good idea.

Re:Security by obscurity ...

[Anonymous Coward]

Is there a good way to block any attempt originating in Asia?

http://ipinfodb.com/ip_country_block.php

Re:Security by obscurity ...

[formfeed]

.. is rarely the way to go, however port knocking would go a long way in terms of thwarting brute force guessing.

Most of the intrusion attempts on my machine are from APNIC. Is there a good way to block any attempt originating in Asia?

You could put the whole IP block in your firewall's blacklist.

Re:Security by obscurity ...

[Anonymous Coward]

We'd like to point out that we are not in Asia. Thank you.

love,

Australia & New Zealand

Re:Security by obscurity ...

[Megane]

We might be interested in your web site.

Then why are you complaining about IP range blocks on SSH?

And I've put lots of port blocks for SMTP on my own server, so I know how badly laid out APNIC addresses are if you just want to block, say, China and Korea. The 220/8 block is particularly fun.

Re:Security by obscurity ...

[Pseudonym]

Actually, no. Blocking whole ISPs and/or whole countries from any access to your machines is sometimes a very good idea.

Re:Security by obscurity ...

[Anonymous Coward]

Further, The average Chinese user cares about security no more than the average American, possibly even less.

Just lock em out...

[Anonymous Coward]

Just lock them out after a certain number of wrong passwords.

Sheesh, it ain't rocket surgery.

Re:Just lock em out...

[Kardos]

That'd be quite effective against a single host, but much less effective against a botnet of thousands, each of which gets their quota of 5 tries...

Re:Just lock em out...

[Anonymous Coward]

You still think attacks come from a single IP? What's the weather like back there in the nineties?

Re:Just lock em out...

[macbeth66]

How so? You lock up an account after a few password failures. Why would it matter where the attempt is made. They'd have to try getting in with other accounts.

Re:Just lock em out...

[Anonymous Coward]

Oh, please. There are other tricks too.

Sharing blocklists. If server 'A' gets a 'groper' (nice term, heh), then it shares the IP with Servers 'B' and 'C' and 'D'. (B, C, and D may or may not belong to the same person/company), This is much more effective against 'a botnet of thousands', as each bot only gets 5 tries, once.

Non-existant accounts. Never have a "root" user for SSH. Therefore, any attempt to log in as 'root' is automatically a groper. Block them immediately. Same with any other popular users.

Unless you absolutely need it, block everything from China. That'll cut out like 90% of the attempts right there.

Etc.

I just don't see the problem.

Re:Just lock em out...

[msauve]

If you lock out the account, and not the incoming host, then you simply provide a DoS mechanism to lock out legitimate users.

Re:Just lock em out...

[Anonymous Coward]

If you have that big a problem, just Deny ALL : ALL

Then only allow the IPs you want to connect.

Re:Just lock em out...

[Kardos]

You're opening yourself up to a denial of service then. Anyone can lock your account out with a few password guesses.

Re:Just lock em out...

[Eil]

You lock up an account after a few password failures.

Thereby turning a nuisance into a DoS.

Re:Just lock em out...

[godrik]

"That'd be quite effective against a single host, but much less effective against a botnet of thousands, each of which gets their quota of 5 tries..."

I disagree with that. Assuming an attacker controls one million bots which is a reasonably big botnet (the largest known peaked at 30 million). That only give him 5 million tries to guess a valid login/password pair. But let's assume, the attacker already knows the login.

Where do you start? There is about 1 million words in the english language. So a simple password choice of one (truely) random english word and adding a single random number defeats the botnet in 50% of the cases.

A common password policy (uppercase, lowercase, 8 characters at least, at least one digit and one special character) would be enough to defeat mid sized botnet without having to do anything.

Re:Just lock em out...

[AmiMoJo]

Back at university someone would always use this one lecturer's five login attempts up at some random time once a week. I wonder what large companies do to prevent disgruntled employees trying to log in as steve.jobs or bill.gates and DoSing them every day.

Re:Just lock em out...

[Anonymous Coward]

+1 for blocking all Chinese net blocks. I routinely do this on servers. Really does cut down the bot traffic.

Re:Just lock em out...

[jamesh]

How so? You lock up an account after a few password failures. Why would it matter where the attempt is made. They'd have to try getting in with other accounts.

David has to unlock his account a few times a week because of rules like this.

Re:Just lock em out...

[PlusFiveTroll]

Make the users use long passwords or keys, then check the successful logins to make sure they aren't coming from Brazil when the employee is in Japan.

Re:Just lock em out...

[indeterminator]

I wonder what large companies do to prevent disgruntled employees trying to log in as steve.jobs or bill.gates and DoSing them every day.

Quite simple really. They will find the disgruntled employee, and fire him.

Re:Just lock em out...

[Anonymous Coward]

I just wish "The Great Firewall of China" faced both ways...

Re:Just lock em out...

[allo]

so you're thinking the great firewall of china is only blocking incomming connections? WTF

Re:Just lock em out...

[GameboyRMH]

Non-existant accounts. Never have a "root" user for SSH. Therefore, any attempt to log in as 'root' is automatically a groper. Block them immediately. Same with any other popular users.

Keep in mind that treating nonexistent and real accounts differently makes it possible to to bruteforce real accounts and focus the attacks on those. I like my DOSers to waste attempts on accounts that would never let them in.

Yes

[Anonymous Coward]

I ran SSH over port 8080 and for the first month I got mostly HTTP activity but not long after that I got a lot of SSH attacks in my auth.log

The best thing you can do is disable password based authentication altogether and use certificate based authentication.

Re:Yes

[benjfowler]

Is this suggesting that the Chinese skiddies are sharing intelligence, or are doing recon first? That suggests a level of organisation/sophistication that we haven't seen from the idiots before...

Fail2ban

[Anonymous Coward]

Jesus fucking christ, who care? Just use fail2ban or similar.

This is like complaining about spam when you have a perfectly operational bayesian classifier at your disposal.

Re:Fail2ban

[Anonymous Coward]

fail2ban has suffered from race conditions in the past and is a band aid fix more than anything.

Re:Fail2ban

[Anonymous Coward]

And sometimes a Band-Aid can keep you from bleeding to death.

No

[Ultra64]

"You thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port?"

No, because that's crappy "security".

Denyhosts/fail2ban is a much better solution.

Re:No

[SuricouRaven]

It's not for security.

It's to stop the script kiddies of the internet wasting your bandwidth and cluttering your logs with thousands upon thousands of rejection messages in their futile attempts to gain access. They can't get in, but their efforts are annoying.

Re:No

[Anonymous Coward]

I don't look at the logs so I'm not annoyed. Problem solved.

Re:No

[SuperKendall]

I'd never heard of "security through ignorance", but I find it compelling.

Perhaps we could call it "ostriching ".

Re:No

[k8to]

Yeah, I tend to notice them when they use a significant portion of my bandwidth.

Re:No

[jamesh]

I don't look at the logs so I'm not annoyed. Problem solved.

The other problem is when you have a device like an old wrt54gl which has to perform unnecessary work (and therefore gets hotter than it needs to) when trying to deal with several password attempts a second.

Changing the port to something like and rate limiting it from unknown addresses makes a huge difference.

I agree with not looking at the logs though, or at least in the default configuration. How is knowing that someone failed to log in a useful thing to know? That's just the security system doing it's job and is just noise. What you want to log is the successful logins from remote IP addresses that haven't been seen before, or have previously been seen trying many incorrect combinations of username and password. That's a significant event.

Re:No

[Maow]

It's not for security.

It's to stop the script kiddies of the internet wasting your bandwidth and cluttering your logs with thousands upon thousands of rejection messages in their futile attempts to gain access. They can't get in, but their efforts are annoying.

I dunno, I get a small amount of schadenfreude from having fail2ban block their IPs - with luck it wastes some of their time, making the whole effort less efficient. Maybe if enough people ran fail2ban then half the attacker's time would be spent waiting for failed connection attempts.

Plus, if they were to try to then access my web site or try some other form of attack, that would also fail as their IP is banned at the iptables level.

Of course, your tolerance for schadenfreude may mean that YMMV...

Re:No

[Anonymous Coward]

"Denyhosts/fail2ban is a much better solution"

This only helps for simple attacks, where the attacker scans your network all from the same source address.
Increasingly attackers are performing distributed attacks, where the one source IP never attempts more than 1 port, and there can be minutes between attempts.

It's only use is to reduce the number of logs generated by the script kiddies of the world. It doesn't increase your security.

Re:No

[jhol13]

It is for security.

Since I moved to another port I have had exactly zero attempts.
Would a hole be found from openssh, I'd be much less likely to be succesfully attacked than with port 22.

So it does improve my security.

Re:No

[Anonymous Coward]

How is knowing that someone failed to log in a useful thing to know?[...] What you want to log is the successful logins from remote IP addresses that [...] have previously been seen trying many incorrect combinations of username and password. That's a significant event.

Not as significant as you may think. People have a lot of passwords mulling around in their heads these days (especially old discarded ones), so fail-fail-success seems pretty common. Why not ban them for a limited time to prevent log file creep from the fails? After all, how are you supposed to know if an IP had multiple failed log ins before a success unless you log the failures? My guess is that you're confusing automatic notification from log parsing scripts with the logs themselves. Just the same, I like being notified upon repeat failures. It allows me to be quick to correct user error.

Re:No

[camperdave]

I agree with not looking at the logs though, or at least in the default configuration. How is knowing that someone failed to log in a useful thing to know? That's just the security system doing it's job and is just noise. What you want to log is the successful logins from remote IP addresses that haven't been seen before, or have previously been seen trying many incorrect combinations of username and password. That's a significant event.

Yes, that would make the logs worth looking at.

Re:No

[Anonymous Coward]

fail2ban is only as good as the filters and most people just use the stock filters which the hackers understand very well. It's another tool for the toolbox but I find it's largely overrated and gives a false sense of security even for todays script kiddies.

Besides, only wannabes approach security with a block this block that, make it more complicated to use for what it's intended mentality. Security not about blocking things and making it more complicated to use. Security is about risk management. Top to bottom how much security do you want vs usability.

Re:No

[Anonymous Coward]

But given enough scanning the problem is not just annoying. It adds significant I/O load. How is ignoring that working for ya exactly? If I was your boss I'd fire your sorry butt for ignoring something like that.

Don't rely on security-though-obscurity

[Gaygirlie]

You're being naive and just waiting for a disaster to happen if all you rely on is changing the default port. I, myself, use this application called Denyhosts that bans the IP-addresses that try brute-forcing passwords, and I've set it up to just ban access to any services, not only SSH, after 5 failed attempts. These days I've got thousands of IP-addresses on my hosts.deny - file and it just keeps on growing. That said, use Denyhosts or something similar if you need password authentication or just disable password auth altogether.

Re:Don't rely on security-though-obscurity

[Anonymous Coward]

My approach is to use a password that doesn't suck. Since when did a secure password become less than sufficient for this? Good luck brute forcing my 25 character password.

Re:Don't rely on security-though-obscurity

[gallondr00nk]

These days I've got thousands of IP-addresses on my hosts.deny

What's even cooler is you can set Denyhosts to synchronise your local hosts.deny or hosts.evil list, so you can quickly build a large and fairly comprehensive blacklist that updates over time.

Re:Don't rely on security-though-obscurity

[AmiMoJo]

You might as well expire those banned IP addresses after a day because 99.97% of them are compromised machines on dynamic connections. Having a file that size just wastes computing resources (having to check every single one) and slightly increases the chance you won't be able to log in from some random place one day.

Re:Don't rely on security-though-obscurity

[Anonymous Coward]

I am using denyhosts, but switching from port 22 alone dropped the failed attempts by at least a factor of 1000.

Re:Don't rely on security-though-obscurity

[Anonymous Coward]

Your not that clever.

You're not very clever either.

Re:Don't rely on security-though-obscurity

[adolf]

Good advice, but a day seems mighty short: My own "dynamic" IP address has changed only a few times in the 4 or 5 years that I've had this particular ISP. The address survives disruption, widespread power outage, and lengthy periods of time.

It's stable enough to use for a few personal things that don't grok DNS for whatever reason, and perfectly fine for everything else with DDNS and a short TTL.

Better advice: Lengthy expiration (a month or two, perhaps), and a fallback to a machine capable of fixing the unlikely issue you describe. This machine only accepts SSH connections with both a strong key AND a lengthy passphrase. In the off-chance your own killfile bites you (what, 1 out of 32 bits?), just log into that box and fix it.

Or, you know: Ignore it. With connection limiting, there's no good reason to care about the zombies out there that are randomly guessing. They won't make it in before you're dead and buried, as long as all of the passwords are good. So what if it clogs up the logs? (You have grep, right?)

And quite obviously: If anyone is relying on non-standard ports for security, they're already doing it wrong. TFA changes nothing if they are already doing it right (for whatever definition "right" might be in any one person's own context).

Re:Don't rely on security-though-obscurity

[ls671]

Easy, it is:
"my 25 character password."

Re:Don't rely on security-though-obscurity

[Dahamma]

You might as well expire those banned IP addresses after a day because 99.97% of them are compromised machines on dynamic connections. Having a file that size just wastes computing resources (having to check every single one) and slightly increases the chance you won't be able to log in from some random place one day.

*Might* make sense to expire the IP addresses eventually for dynamic hosts (especially ones that are at least in the same country/region that he might be connecting from).

But wasting computing resources "having to check every single one"?? It would have to be a moronically brain dead filter implementation to do that (and it's not). IP addresses are by nature great for hashing, I don't think a few extra pointer traversals per socket connection are going to make any difference whatsoever.

Re:Don't rely on security-though-obscurity

[Anonymous Coward]

It's even better to aggregate those logs into IP-ranges, and block them in the firewall. If you don't host a commercial or mission-critical website, you might as well block every /24 or even /16 that tries to attack your server.

I personally use the program portsentry, which puts the attackers /24 in my firewall upon the first connection attempt to a port that I don't use. Since not many attackers guess that my SSH server is on port 5 on their first attempt, they get blocked. Also, portsentry prevents portscans, as portscans either start on port 1, a random port or a popular port (e.g. port 80 or 22).

Re:Don't rely on security-though-obscurity

[allo]

most isps disconnect the connection after 12 to 24 hours, then you get a new ip. So you're an exception from the usual rule.

Re:Don't rely on security-though-obscurity

[Anonymous Coward]

One day leases do not mean a new IP every day. Residential broadband customers can easily go 6-8 months with the same DHCP-assigned IP address. You have a low enough UID to know this. You're not an idiot. Maybe you didn't have coffee yet or something.

Re:Don't rely on security-though-obscurity

[ntsucks]

We see thousands of attempts all day, every day. Its just part of being on the net. Fail2ban has been pretty effective for us. You can configure it easily to set up "move on" rules for the bots and not blow your leg off because you mistyped a couple times.

Re:Don't rely on security-though-obscurity

[Gaygirlie]

Or, you know: Ignore it. With connection limiting, there's no good reason to care about the zombies out there that are randomly guessing. They won't make it in before you're dead and buried, as long as all of the passwords are good.

Well, it's wasted bandwidth. Sure, it's not much, but why bother sending back any response whatsoever when you can just outright block the IP-address and not respond at all? Atleast I have such limited outgoing bandwidth that I sure am gonna save every bit I can get.

Re:Don't rely on security-though-obscurity

[adolf]

But with connection rate limiting, you're done. There is nothing more to adjust. Legitimate people legitimately getting their password wrong will still be allowed in within relatively short order, the zombies are mitigated, and there is no further administration required.

Surely your time and sanity is worth more than perhaps a few kilobytes of unwanted traffic.

Re:Don't rely on security-though-obscurity

[adolf]

By "most" I guess you mean "every ISP I've never had."

Even with dialup, I was keeping the same dynamic IP address for weeks at a time by virtue of simply staying connected. ISDN worked even better. Time Warner cable, better yet. And now I've got a bog-standard VDSL pipe from AT&T, which (for any normal residential purpose) doesn't change often enough to care about.

That said, I've seen issues with ADSL back when Ameritech was still a thing, where they'd reset the connections once every night, but that was more than a decade ago.

Who still behaves this way? Please name names.

Re:Don't rely on security-though-obscurity

[Anonymous Coward]

You might as well expire those banned IP addresses after a day because 99.97% of them are compromised machines on dynamic connections. Having a file that size just wastes computing resources (having to check every single one) and slightly increases the chance you won't be able to log in from some random place one day.

Apparently you aren't familiar with the concept of hash tables, which provide O(1) lookup performance.

I'd say hand over your nerd card, but it's clear you didn't have one anyway, and just snuck in here via the back door (of course /. has backdoors!).

Re:Don't rely on security-though-obscurity

[jrumney]

You're being naive and just waiting for a disaster to happen if all you rely on is changing the default port.

I run ssh on a non-standard port, not because I'm relying on it for security, but to cut down on noise in logs from all the bots trying various 'sploits on it. I figure I'm more likely to spot a real threat occuring in the logs if the noise level is low. Until about 6 months ago, mostly the log activity was port scans for HTTP ports, but about 6 months ago, I started getting regular ssh root login attempts showing up in the log as well.

Re:Don't rely on security-though-obscurity

[allo]

maybe its a american thing, most european isps cut your connection after at most 24 hours, and do not re-assign the same ip. The TV-cable ISPs are a exception from this rule, there it is hard to get a new ip.

Re:Don't rely on security-though-obscurity

[atgaaa]

Do this. One day your employer will call me and complain the network is slow, I will remove the thousands of ips from your firewall and be a hero.
ker ching.
Seriously brute force protections is a good thing, just remember your list has a short shelf life and you want to keep it small.
Oh, and I have seen these lists that have done reverse lookups, and add names to the file rather then ips. Result? What I said in my first sentence x 10.

Re:Don't rely on security-though-obscurity

[Gaygirlie]

Do this. One day your employer will call me and complain the network is slow, I will remove the thousands of ips from your firewall and be a hero.
ker ching.

First of all, why would the employer be using SSH to log into servers? It's stuff IT-workers do, not the management. Secondly, why would you need to empty the whole blocklist just to unblock a single IP within a range that you know perfectly well since it's inside your network? Thirdly, why would it affect the rest of his networking if he couldn't log in via SSH? Oh, and fourth: if it actually wasn't him trying to log in via SSH then it was someone else using his IP, and that should actually tell you that there's something wrong with this picture.

Oh, and I have seen these lists that have done reverse lookups, and add names to the file rather then ips. Result? What I said in my first sentence x 10.

Denyhosts does by default not do reverse lookups and I don't imagine Fail2ban does that, either. And why would they? There is absolutely nothing to be gained from that.

No I haven't, and here is why:

[Anonymous Coward]

I've blackhole'd all ports I'm not actually using, so the machines don't respond at all. I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

I've never even seen anything that wasn't me attempting to log in in my sshd and system logs. Root login disabled, and pubkey authentication is the only enabled method... so even if they did figure out my port knocking sequence they could literally spend infinity time trying to figure out my non-root non-existent password.

Also, wtf password groper? This used to be a news for nerds site, not a news for computer molesters site...

Re:No I haven't, and here is why:

[Anonymous Coward]

I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel.

And I change languages and character sets every chapter.

Re:No I haven't, and here is why:

[v1]

what's an easy way to set up port knocking?

Re:No I haven't, and here is why:

[Zaiff Urgulbunger]

I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel. And I change languages and character sets every chapter.

Not bad, not bad! But I'll share a little pro-tip with you; I do all the above, PLUS I turn my monitor upside down when I'm typing in my passphrase so that even if someone stole my SSH key, they'd still have to figure out it's orientation!!

Re:No I haven't, and here is why:

[Anonymous Coward]

While I enjoyed this post, I find it unfortunate that you did not also randomize the port-knocking, similar to the two-factor authentication schemes we see today. Preferably, a randomized song in your iTunes library would be chosen based on the epoch, after which you would have to convert the first verse's notes into ports to knock. If I'm being honest with myself, this is really the only way I would ever trust my SSH server to be "secure."

Re:No I haven't, and here is why:

[Anonymous Coward]

Ask the Chief Port Knocka

Re:No I haven't, and here is why:

[Barny]

Luxury. I have my screen, with an atomic random pulse generator, rotating my screen in a random direction every 2 seconds. They not only have to guess the correct orientation, but they have to continue guessing it right. Also, I limit my novel series writing to 5 words per minute to enhance this level of security even further.

On a serious note, I help run an old 'MUCK' style game. We get about 5 bots an hour hit up EVERY open port with attempts to login with 'admin' 'password' or 'root' 'password'. Do router/system makers really suck that badly that this is worth doing?

Re:No I haven't, and here is why:

[Anonymous Coward]

I've setup port-knocking to open the port I actually use for SSH, and my SSH key is passphrase protected. Passphrase not password.

Pfft. Lightweight. Nobody's ever getting into my passnovelseries-protected pubkey. Passnovelseries not passnovel.

And I change languages and character sets every chapter.

Not bad, not bad! But I'll share a little pro-tip with you; I do all the above, PLUS I turn my monitor upside down when I'm typing in my passphrase so that even if someone stole my SSH key, they'd still have to figure out it's orientation!!

Amateur stuff. I'll share another tip with you. I don't even have my SSH server connected to a network! How is that for security? It's invulnerable to remote exploitation!

Re:No I haven't, and here is why:

[jez9999]

Weak. I don't even HAVE a server! Try rooting THAT!

Re:No I haven't, and here is why:

[roscocoltran]

Are you serious, and why not invite hackers to your birthday party ? I did ALL the above, plus I've added "rm -rf /" to the bash_profile of the root user, so in case SSH source code is compromised, my machine will self destruct on a successful hack! (make sure you use sudo btw)

Use random IPv6 from a /64 range

[Anonymous Coward]

Typically server hosting with ipv6 will assign a /64 range to each box. Assign your ssh port to a randomly generated address somewhere i the range (2**64 addresses) and port scanning will never find it.

Re:Use random IPv6 from a /64 range

[tepples]

Typically server hosting with ipv6 will assign a /64 range to each box.

Which would require you to switch to a hosting provider with IPv6 and move your own home or office to an area whose ISP offers IPv6.

Re:Use random IPv6 from a /64 range

[Anonymous Coward]

Nope, just use a tunnel.

Re:Use random IPv6 from a /64 range

[Anonymous Coward]

Which is going to happen anyway, so why not do it now and be the first kid on your block with a shiny new 64 bit addy.
Hell, in Japan we are already there, and have been there for years. My first OCN fiber almost a decade ago was IPv6.
Just face it, you're a horrible lazy admin and your users know it!

Re:Use random IPv6 from a /64 range

[tepples]

How long will the existing tunnel brokers remain free to the general public?

Re:Use random IPv6 from a /64 range

[petermgreen]

I suspect the answer is as long as not too many people know they exist :/ Theres also teredo and 6to4 (though they may have problems with overloaded or even discontinued relays if they get too popular).

Re:Use random IPv6 from a /64 range

[Anonymous Coward]

That's fine — I'll just do a dictionary scan on your DNS zone instead and find the AAAA record that way.

Re:Use random IPv6 from a /64 range

[allo]

until the typical isp adopts ipv6.

Re:Use random IPv6 from a /64 range

[Anonymous Coward]

Why is that a problem? You obviously don't take security seriously...../snark off.

Re:Use random IPv6 from a /64 range

[tepples]

[Requiring the use of IPv6] would require you to [...] move your own home or office to an area whose ISP offers IPv6

Why is that a problem?

You tell me how much it costs to find a job in a different city and move to that city, and I'll tell you why moving is or is not a problem.

OK ...

[Anonymous Coward]

If using a higher, or non-standard, port number only give you a 2 character increase in password security, then why not just use a longer password?

We use a non-standard port, a non-standard user name, and a 16 character password. Normally we just connect via ssh key, but some applications we use require a username/password rather than using a key.

Are we safe? Yes. Are we completely safe, no matter what, totally and forever? Nope ... nothing is. You just have to be vigilant reasonable.

Obscure port still give you some protection.

[Anonymous Coward]

If you monitor your logs unless they guess correctly first time, you will see their failed attempts first.

CSF is the answer

[BradBeckett]

We are preventing this sort of attack on our Linux servers utilizing ConfigServer Firewall and a standard SSH port only we know. It's unlikely somebody is going to find our new SSH port before they are blocked for port scanning by CSF. There are other options then CSF such as cPanel Hulk, but we also like the other options CSF offers such as being able to use a distributed list of IP's to block which allows for a distributed firewall amongst all of our servers. http://configserver.com/cp/csf.html

Re:CSF is the answer

[wiredlogic]

Unlikely... unless the port scan is distributed across a botnet. Just 65K machines can scan the entire port space for any given protocol with one attempt apiece.

Re:CSF is the answer

[Anonymous Coward]

We've never seen that, although it is likely against a high value target, but then you have more important things to worry about. Like DDoS attacks.

avoid it all together

[Anonymous Coward]

fail2ban. done.

Dumbass parroting.

[Anonymous Coward]

It seems security by obscurity has lost the game once more.

How, exactly?

By ensuring the vast majority of brute force attacks - which hit port 22 - fail?

Security isn't fucking binary, and obscurity is a perfectly valid layer of the onion.

Re:Dumbass parroting.

[astralagos]

Security through obscurity is one of the most spectacularly misunderstood concepts in information security, partly because it's gotten confused with open source politics. The core concept behind it (Kerckhoffs' principle) is best stated as "assume that the enemy knows your system as well as you do". In cryptosystems this means that the secret is a controlled and limited entity - the key. The key must -still- be hidden and controlled, but Kerckhoff's principle ensures that you have only one thing to have to control. Various federal agencies used to, for example, assume that the first version of any cryptosystem they sold would be bought by Moscow and rapidly analyzed.

Well and good, but all any security implementation buys you is *time*. The real problem with StO is that the time it buys you is unpredictable, and in Kerckhoffs' era of large and slow system upgrades, it might take years to update a cryptosystem once it was broken. Malware authors have happily used StO for years -- for example, evading detection mechanisms by using a number of off the shelf packers in sequence. The approach works because they replace their malware faster than anyone figures out the packing sequence. The windtalkers during WWII were a security through obscurity approach, and it worked fine for the duration of the war, but would have gone horribly in the next one.

Now, what we're dealing with here is network defense, which isn't crypto. In network defense, creative lying is enormously helpful because you can use it to differentiate between your ignorant attackers and knowledgeable members of the community. The majority of attackers scan horizontally (all hosts on a fixed number of ports) rather than vertically (all ports on a number of hosts) because vertical scanning is a waste of time. Most attackers normally hit 9-10 ports and then move onto the next potential target -- they don't see the network in terms of what the hosts *are*, just what they can *exploit*. Moving SSH to a random port means that the attacker now has to spend 6000x the effort to figure out of there's anything on the host he cares about, and he's probably not going to bother when there are nice sysadmins out there happy to put everything on port 22 (as always, I don't have to outrun the bear. I just have to outrun you.) Copy it with some aggressive port blocking (like port 22) or a threshold random walk scan detector and you've got a perfectly fine way to ignore idiots. It's also worth noting that the mentioned port is 2222, which tends to be "stupid port manipulation rule #2" among folks (the other one being to add 1 in front of the port numbers, I can't tell you how fascinating it was to watch port 16888 the first time we blocked bittorrent).

Very few

[PktLoss]

We're running a network of 80+ servers around the world (https://wonderproxy.com).

We've moved in stages getting things off standard ports.

Whole network standard - several hundred attempts per day
a few standard, rest on non-standard ports - tens of attacks per day
all non-standard ports - 0-5 attacks per day.

It's been worth doing just for the reduced reporting volume in our status systems.

Re:Very few

[smegfault]

Moving to a non-standard work may not be very effective, but it sure saves me time checking access logs. Since I moved to a non-standard port, I've had to deal with maybe 5 attempts a day - which is much better than 50 a day!

Standard port

[Anonymous Coward]

I leave SSH on a standard port, but enforce complex passwords and put rules in place which greatly slows down guesses. An attacker can only try logging in a few times a minute. It's going to take them a long time to guess usernames and complex passwords at that rate.

Convenience

[Anonymous Coward]

Like someone allready said, it's not really for security but for convenience. I used to run sshd on port 22 but got tired, and slightly unconfortable, of all the login attempts I got. Moving to a non standard port has worked great for me for at least 7 years now.

I only allow a few specified users to log in and only with keys, not passwords, so the chances of someone actually gaining access by guessing a password are pretty slim. But it was still annoying.

Mod parent up

[Anonymous Coward]

Excellent advice.

VPN

[sgt scrub]

I thought all the cool kids put machines behind firewalls then SSH after connecting to the VPN.

Re:VPN

[Anonymous Coward]

That is actually how I run my hosting servers. No SSH is exposed on the internet. The KVM host doubles as an OpenVPN client, which connects a virtual RFC1918 network of VM's to my LAN where the VPN terminates onto a DMZ with very strict firewalling. No management ports are exposed publicly whatsoever, everything related to management and backup goes "around back" across OpenVPN over TLS.

Re:VPN

[nzac]

Because that's two steps instead of one.
VPNs are no more secure than SSH, just make SSH as secure as you need it.

Re:VPN

[PlusFiveTroll]

An in depth defense is a VPN that only is allowed connections to port 22. You are then protected against a direct remote exploit against SSHD, if your VPN is directly exploited hopefully it runs as non-root and would require an additional system level exploit to break out of.

My god, they've discovered nmap

[Gothmolly]

Paging Captain Romero - of course you will get traffic on high ports - there's only so many available to try. Moving your ports around just delays the inevitable and culls out the lazy.

Re:My god, they've discovered nmap

[LMariachi]

Making them scan for open ports wastes exponentially more time than just automatically hitting 22, and exponentially more than that if their scanner checks response types on open ports to see if 666 really is a Doom server or is that where ssh is hiding. As others have mentioned, it’s not about security so much as making things less convenient for attackers.

Re:My god, they've discovered nmap

[DamonHD]

No, not "exponentially". A fixed constant factor higher in fact.

Let's not use up the art terms until we mean them. Adding a port-knocking *sequence* before access could get you into exponential territory.

Rgds

Damon

Re:My god, they've discovered nmap

[Anonymous Coward]

Exponentially, hmm... This word does not mean what you think it means.

Re:My god, they've discovered nmap

[ArsenneLupin]

A fixed constant factor higher in fact.

Not even fixed constant factor. Rather, a fixed constant term (additivie constant, rather than multiplicative). Indeed, once the attacker has found the ssh port, he can start banging his list of username/passwords at that port, and he doesn't need to repeat the port-search sequence for each username/password that he tries...

Re:My god, they've discovered nmap

[Anonymous Coward]

They don't care much. The script kiddies are using zombies Windows boxes for these scans and attacks, and generally they only have to find *one* available host to tleapfrog their way forward. The "SSH fixes everything" people are particularly vulnerable, because inevitably the "gateway" or exposed machine has easily broken passwords, isn't kept patched, uses the same passwords as other broken passwords used in other locations because it's the home windows machine with LDAP passwords that got cracked already, etc.

And oh, yes, the "only use SSH keys" are particularly suckers because they inevitably fail to protect their SSH keys. They leave them lying around with bad passphrases, leave them unencrypted to use for Subversion or easy passphraase free login, leave them unlocked in accessible `ssh-agent` setups, etc. I especially llove scanning backup tapes and NFS mounted home directories for SSH keys: I've got several dozen github keys this way, which means I can change their source code on publicly accessible code repositories.

Re:My god, they've discovered nmap

[LMariachi]

Thank you. I should know better than to use math words in their colloquial sense on /. (Try using “decimate” to mean anything other than “reduce by 10%” for guaranteed responses.)

Re:My god, they've discovered nmap

[PlusFiveTroll]

You mean that you didn't ban their IP when it lit up every port like a christmas tree?

...and watch them lock YOU out

[tepples]

You lock up an account after a few password failures.

Which opens up a denial of service opportunity for anyone who can guess the primary administrators' usernames: the botnet could log in with an incorrect password several times to lock out the legit user. Cue a truck roll to reset the lockout.

Attempt Limits

[Anonymous Coward]

Don't most people use attempt limits now? Limit an IP to 10 attempts before an IP address ban and lock the account in question.

A better way.

[PenguinJeff]

I have my ssh port blocked with iptables. I have a script that reads email once a minute. If I type the write stuff in the email and the email comes from me (my email provider does good with emails claiming to come from me and acctually comming from someplace else I tested it they go to junk) it unblocks port 22 for the ip address I specify in the email. I use fetchmail to download new emails I use the standard "mail" program to pick off the first email and I parse the email for all the commands I type in. I check in on it from time to time and have never seen anyone attempting to even send emails that will open ports. I originally went one step further using pgp on both sides(encrypting then decrypting) but sending from my phone got to hard with pgp.

Re:A better way.

[Dr. Manhattan]

I made my own software that just runs fixed scripts. Handles typical things without needing full ssh, and when I do need ssh, I have a script to unlock it temporarily.

if you can log

[arbiter1]

If you can connect and directly log in to root, I think you are an idiot. Regardless of the password.

Distributed attacks

[tepples]

Denyhosts/fail2ban is a much better solution.

Not if the brute force attempts are distributed across thousands of different /24s, or if a botnet member is behind the same carrier-grade NAT as your machine.

Interface for specifying approved IPs

[tepples]

Then only allow the IPs you want to connect.

So how do you predict the IP address of the machines from which you will be connecting in advance? If you expose a web interface to edit the list of allowed IP addresses so that you can connect from an additional IP address, all you've done is added the length of that web interface's password to your SSH password.

Re:Interface for specifying approved IPs

[Anonymous Coward]

So how do you predict the IP address of the machines from which you will be connecting in advance?

You regularly connect via SSH from random IPs? Random IPs in China?

Re:Interface for specifying approved IPs

[srh2o]

Default deny is a great method and I've been using it for a long time. I'm not sure where your Web access brainstorm comes from but it has no place in a security strategy of default deny. Default deny is very very simple. Either you are a trusted IP or you aren't. Every security strategy has weaknesses. Default denies biggest weakness is that it isn't flexible. But it's biggest strength is that it can massively restrict the amount of potential connectors to a system.

Re:Interface for specifying approved IPs

[KiloByte]

You regularly connect via SSH from random IPs?

Your phone doesn't have a static IP, neither does a hotel or a random customer whom whose premises you need to quickly fix something. Or aunt Judy, if shit happens to your home server while you're away.

Random IPs in China?

You usually recall you've set up such blocks when you're already on your business trip you didn't expect 5 years ago.

And looking at my logs, they use botnets anyway. Heck, among 37 distinct IPs from today on one box, I see even a pwned IP from Vatican.

Re:Interface for specifying approved IPs

[Wovel]

Use a VPN..

Re:Interface for specifying approved IPs

[Anonymous Coward]

I always have my home server available on a fixed IP which allows the ssh service and nothing else outside of my network. That server's IP address has access to all of our external servers. If I'm out, then I ssh into that, then out to the external servers as needed. I also have another backup server I can use to do this. I can gain access from any device I have with me, without the external servers allowing any unknown IP to connect.

Re:Interface for specifying approved IPs

[RocketRabbit]

For most everybody, individuals and businesses, there is no reason whatsoever to allow Chinese traffic. Ditto Russian, Ukrainian, Brazilian, etc.

By eliminating those countries, you can cut down 90% of attacks or more. If you don't do business with, or have friends in, those countries anyway, there is no reason whatsoever to allow traffic from them.

Re:Interface for specifying approved IPs

[formfeed]

I guess, you could email your current ip to your server. After receiving a special command in the header of the email, a specific pattern in the body of the email (and maybe your laptop's name as originating sender) your server will extract the ip and whitelist that ip for two hours and 10 connects.

When an attacker controls 10,000 IPs

[tepples]

An attacker can only try logging in a few times a minute.

How does your system determine which IP addresses belong to a particular attacker's botnet?

Re:When an attacker controls 10,000 IPs

[Anonymous Coward]

At that point in the war 10000 to 1. Do you really expect to win? Clearly someone wants to defeat you and has amassed enough resources to do it. If what you hold is worth it, you will have the resources to fight back. Security is not a binary.

Re:When an attacker controls 10,000 IPs

[Anonymous Coward]

Time for 64bit TCP protocol and socket numbers.

Re:When an attacker controls 10,000 IPs

[formfeed]

How does your system determine which IP addresses belong to a particular attacker's botnet?

Easy.

Whoever thinks that
1. I would allow root to ssh in.
2. That the root password is admin
and
3. There is a user named cardiology
belongs to a botnet or uses the same script.

In Russia, attacker locks YOU out

[tepples]

Don't most people use attempt limits now?

See replies to macbeth66's post asking the same question.

I am working on a well Trojan horse

[Anonymous Coward]

That I call land mines. I place them in a file that opens on these ports so a hacker who downloads one and opens it is screwed it is not a virus so virus detectors wont stop it running. and slow dasteredly things are my fav.

Administrators group

[tepples]

What's the practical difference between being able to log in to root and being able to log in to a member of the sudoers group?

Re:Administrators group

[Culture20]

That depends on what commands the sudoers are allowed to run (sometimes it's pretty restrictive).

Re:Administrators group

[tepples]

Unless you have someone with physical access to the datacenter, at least some sudoers are going to need high-level privileges.

Re:Administrators group

[AmiMoJo]

You need two passwords to get root instead of one. Plus it is easier to assign blame because you know whose account was hacked, not just that the root password was lost.

Re:Administrators group

[lindi]

The largest practical advantage is auditing in the case where you have multiple administrators.

Re:Administrators group

[swillden]

What's the practical difference between being able to log in to root and being able to log in to a member of the sudoers group?

The attacker has to guess/discover a username in the sudoers group as well as brute-force the password space. If the attack is targeted, that doesn't help. If it's random, it can be a big help.

Re:Administrators group

[Anonymous Coward]

the practical difference is that you essentially add a second secret they need to guess, instead of just being able to use 'root'. Sure it doesn't help a targeted attack by someone who knows your username, but it does make things significantly harder for all the script kiddies.

seems like you're asking for it

[Anonymous Coward]

if you do not detect failed login attempts, and ban or block IP's temporarily... sure they could proxy up, but you could also then detect that trend for a given user account. why is brute forcing passwords still a viable infiltration method? that's the real question.

Rate limit and require keys on my VPS server

[caseih]

I have a couple of internet-facing VPS servers that I use, and I do ssh into them on a regular basis. But after a weak password let someone in, I re-installed and switched to requiring ssh keys. I also turned on simple rate limiting for ssh (I keep mine on port 22) connection attempts. I still allow password ssh logins, but only for connections originating within my VPN.

I haven't had very many problems with brute force attacks since. I'm still vulnerable to any ssh key-handling vulnerabilities that may come along, but I feel more secure than I was before.

I would be interested in the success rate.

[Tanuki64]

People, who configured their ssh to listen to a non standard port, are aware of a problem and probably at least a bit more knowledgeable than the average user. So I'd expect better passwords and maybe other means of protection. Does it really pay to try higher ports in comparison to the higher effort?

Re:I would be interested in the success rate.

[jgrahn]

People, who configured their ssh to listen to a non standard port, are aware of a problem and probably at least a bit more knowledgeable than the average user. So I'd expect better passwords and maybe other means of protection.

Either that, or they're more interested in tinkering with stuff, changing things that don't need changing ... thus more likely to mess something up and leave a hole open.

Seems to me the problem is logs filled with crap, and the right solution is not to log failed PasswordAuthentication login attempts if you have disabled PasswordAuthentication. No idea if OpenSSH supports that.

SSHGuard FTW

[water-and-sewer]

I'll probably have to go learn about key-based security. But meanwhile, I'm really happy with sshguard. It defends against brute force attacks by monitoring logs and aplying increasingly (exponentially) tougher time-outs as attacks from IP addresses continue. It's reduced my log from 100s of entries per day to about 15. http://www.rferl.org/content/world-press-photo-winners/24903576.html
    They've got it in FreeBSD ports, which makes it easy to install into an existing firewall.

Re:SSHGuard FTW

[water-and-sewer]

Great - copy/paste fail. That's a link to the Swedish journalist picture of Syria that got a prize. Here's the link for SSHGuard for the Google impaired.

http://www.sshguard.net/

Glad copy/paste fail didn't betray any other links I've hit while surfing-the-net-and-drinking-whiskey simultaneously.

Re:SSHGuard FTW

[Anonymous Coward]

Thank you for that "accident" ;-)

Very powerful photos!

yep, I do vpn

[urbieta]

thanks for the compliment lol! #no public ssh :P iptables -A INPUT -p tcp -i $INTERNET --dport 22 -j DROP PLUS I still use ssh keys, just in case. My fingers thank me because I no longer have to type the same thing all over again all day. My brain thanks me because I am no longer trying to remember a long password anymore (dont remember how long has it been since I no longer used passwords on public ports). YES, this is a lazy passphrase free key, so what! I am a cool kid and I can do what I want to haha

Tarpit?

[benjfowler]

Why doesn't somebody invent a tarpitting method, where you write something that'll listen on thousands of ports, completes a fake ssh handshake (slowly), rejects all authentication attempts, logs gropers to fail2ban; but then have your real SSH daemon on a higher port, using certificates only? For you, no problems; for them, like searching futilely for a needle in a haystack...

Wastes the gropers' time, and burns their bots. Get enough people doing this, and it might send a message to the idiots doing it.

Re:Tarpit?

[Anonymous Coward]

I believe something in the old days that was called the "deception toolkit" would do similar actions, but was relegated to an era of active defense, and now the trend seems to be block and forget.

Active defense requires tuning and administrative overheard, something I fear many organizations seem to have less and less.

I do security by antiquity

[Anonymous Coward]

You see, I don't use SSH, I use plain old telnet. That's right! These kiddies never heard of it!

And if they actually get in, I have a few gigabytes of stories growing up that they have to read. Like the time I was growing up in Idaho. We wore onions on our belts because that was the style back then, Benny Goodman was all the rage and I'd take my best girl - Betsy - to the church dance ... we were all Presbeterian in that town and with one church, new people would just go there - even the Jews because there wasn't a Synagogue - but that's another story and I won't bore you with that because I can be a bit long winded at my age - so anyway my best girl got her new dress and we over to the next town to Jo's soda shop - he had the BEST malts in the entire area - and the whipped cream was made fresh from a local dairy farm - farmer brown's was his name - he served in WWI as an infrantry man in France and boy the stories he told about those French girls - like the one he met, Jaquoline I think or it was Juliette - she had dark hair and hazle eyes and her father was a banker for a German who had a home in France before the war - of course when the war started the Germen businessman had to run home and he ended fighting himself, even though his father pulled some mighty strings to get him out of the German army ...ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Re:I do security by antiquity

[creepynut]

Replying to undo mod. Meant to pick funny.

Re:I do security by antiquity

[GameboyRMH]

I was expecting the story to turn erotic, between the tales of your girlfriend and Farmer Brown's tales of French girls.

Re:I do security by antiquity

[dcollins117]

I so want to hear the rest of this story. What's your IP Address?

It used to be a problem

[Anonymous Coward]

I have my SSH server listening on the standard port. I used to use tunneled passwords as the auth mechanism, but my auth.log was getting very cluttered (even after installing denyhosts and fail2ban). Most of the attacks aren't coming from script kiddies, but from other infected systems at the hands of "bigger" organizations.

I now run on the standard port, with denyhosts and fail2ban, using a 2048bit RSA key that resides only on my laptop, they key also requires a password. You should always make sure you have your sshd_config setup to disallow password auth, and root login.

In summary:
Changes to /etc/ssh/sshd_config
Denyhosts
Fail2ban
RSA key only auth
Key requires password

iptables

[markdavis]

If you want to end almost any possibility of brute force, load this with iptables:

/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "sshd_brute_force_block "
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Those three lines will slow the amount of connections by the same ipaddress to sshd. When the attacker reaches 4 hit counts it will be blocked for 60 seconds before resetting. If the attacker keeps attacking before the 60 seconds are up it will reset the the time limit to another 60 seconds. Have been using it for years and it is extremely effective. Even a botnet attack (which is unlikely) would be futile because there just aren't enough attempts.

Seriously, this type of thing should be built directly into ssh. If not this sophisticated, then at least it should include attempt and restart delays which would not be as effective but beat the hell out of the default behavior.

Re:iptables

[Gothmolly]

Given that there other, useful, general case workarounds for managing network traffic, this should NOT be built into SSH, rather the sysadmin should be clever enough to apply a general solution to his specific problem. Baking this sort of crap into every daemon out there is Microsoftian.

Re:iptables

[Anonymous Coward]

This wouldn't stop the now common attack of distributed SSH brute forcing (botnets trying to brute force by slowly guessing passwords of many machines over extended periods) because the attempts would come from different IPs and they'd come slowly over an extended time period.

Re:iptables

[markdavis]

It would still take an eternity, assuming the machine didn't have any horrible password problems (like blank or same as user name or something like that). I don't see how it could be an effective attack unless there were hundreds of thousands of machines all trying and for many months. I believe typical brute forcing on reasonable passwords would take millions of guesses per login.

Re:iptables

[markdavis]

I should mention that for this to be the best of effectiveness, one should also edit /etc/ssh/sshd_config and set "MaxAuthTries" to something like 1 or 2. I think the default is "6" which is far too many.... combined with the iptables 3 connections, that is 18 tries- many more than a legit person would need. 2x3 (6) or 1x3 (3) is more reasonable.

Re:iptables

[Anonymous Coward]

Uhm, the iptables 'limit' rule does all that in one line.

Re:iptables

[markdavis]

>Uhm, the iptables 'limit' rule does all that in one line.

I didn't write the offered iptables code, but if you think there is a better way, then feel free to offer alternative code. Keep in mind that the rule has to work the same- only restricting one address to a certain amount of attempts per X amount of time and adding additional time if they try again in that amount of time.

A quick look at "--limit" in the iptables man page doesn't show that option to be very useful in this situation from what I can tell.

Re:iptables

[hcs_$reboot]

Assuming the root ssh is blocked, how brute force can work without knowing the login name to apply the password to?

Re:iptables

[GWRedDragon]

Assuming the root ssh is blocked, how brute force can work without knowing the login name to apply the password to?

Simple: brute force the username. The username is just another part of the password to guess, except it likely contains much less entropy than your actual password.

Re:iptables

[Anonymous Coward]

Strongly agree, SSH need a "tarpit=y" config directive whigh does this better, and is system wide.

It is not worth writing since upstream has real NIH and will just ignore it.

MFG, omb

Most security IS security by obscurity.

[MasterOfGoingFaster]

From the summary: "It seems security by obscurity has lost the game once more."

I've got news for you. Most security IS security by obscurity. Think about it. If the attacker knew your password, account, IP address, certificates, keys, and combinations you would have no security.

Re:Most security IS security by obscurity.

[neonsignal]

"security through obscurity" usually refers to obscuring the design of a system, not to key secrecy. Unlike design obscurity, secret keys provide a measurable barrier to brute force attacks.

Changing port number for ssh is interesting to classify. If chosen it randomly for each system being set up, it could be argued that it wasn't a design obscurity. But it doesn't add to the total security against a targeted attack, because the port number can be determined prior to key forcing (and in a lot shorter time). Also, the port number is not secret, in the sense that it is sent in clear text across the network when the real user logs in.

Of course, changing port number may have practical advantages (reducing traffic, simplifying logs). But it isn't a security strategy.

Re:Most security IS security by obscurity.

[Anonymous Coward]

Please read up on Kerckhoffs's principle. Then you might actually understand what "security by obscurity" means.

I have the answer

[Anonymous Coward]

Upon 10 failed attempts on a given account, drop them to a fake shell prompt and log them. Put the longest or most entertaining logs up on a public web page for mockery.

Fixed

Re:I have the answer

[Culture20]

Upon 10 failed attempts on a given account, drop them to a fake shell prompt and log them. Put the longest or most entertaining logs up on a public web page for mockery.

Also known as "how to increase CPU and bandwidth usage on my server tenfold". It's like answering positively to a telemarketing call just to waste their time. It might seem like fun, but your number goes on a suckers list.

Re:I have the answer

[Anonymous Coward]

Of course... it's trivial to manage the cpu and bandwidth usage too.

Also, it apparently needs to be said that this isn't a professional response.

Re:I have the answer

[PPH]

But then throttle that connection back to the equivalent of a 110 baud connection.

Port knocking anyone?

[jurgen]

Like others have said, moving sshd to a high port was never meant to be additional security, just annoyance-reduction to reduce the sheer load in terms of bandwidth and log space. I did that for a while, but then (well over a decade ago) I saw an article about port knocking which is where you (i.e. the sshd) don't answer until the system receives a secret sequence of connection attempts at various ports... i.e. a secret "knock". The secret knock is a kind of password, and can be sent by executing a specialized client, or if you are somewhere where you don't have one available, by manually making telnet attempts, i.e. "telnet 16111; telnet 28123; telnet 22222".

The knock is basically a password for OSI network layer connections. This not only reduces the annoyance level of unsophisticated phishing attacks, but basically eliminates them altogether with a layer of real security. That security is not very strong... in a targeted attack, anyone who can monitor your link layer anywhere along a connection you make can see your secret knock... but it's an easy add-on and better than just playing tag with script-kiddies by moving ssh protocol to a high port.

Re:Port knocking anyone?

[Onymous Coward]

Actually, moving sshd to a different port is for added security.

It'll be some time before automated scans and worms try to find SSH on something other than port 22 in any substantial frequency. So moving the port gets you a reduction in attack frequency. That's of value. It's additional security.

Requiring a remote system to send SYN packets to 16111 28123 and 22222 before opening port 22 to them is just another way to reduce frequency (albeit using a much higher hurdle). The difference is degree, not kind, so it's not that one of these actions is actual security and the other isn't.

Re:Port knocking anyone?

[whois]

It's not real security, it's security through obscurity. Specifically, it has two very large flaws and one nitpicky one. One is shared password, meaning everyone who is using a system has to use the same password (knock).

The second is that anyone listening on a remote network can listen to your knock sequence and they've defeated your barrier to entry, leaving you falling back to your true authentication which hopefully isn't as simple to break.

Client based port-knocking can be better about this, implementing rotating ports based on time (as long as the client and server's time is in sync), but at that point all you have is an elaborate firewall that's emulating spread-spectrum frequency hoping on wireless. You might as well program the client to continue hopping through the entire session, making it more difficult to reassemble the original data (but likely useless because anyone sniffing can modify their parameters to suit this new shenannigan and just order the packets by time.. again it would fall back to whatever encryption you were using under the obfuscation).

Also in that case you've required a custom client on the user side which makes the service harder to use.

The final nitpick is that you can't ever open that service up to the public because it then requires the public to know the port knock sequence. So it's unfeasible on port 80. If you leave any port open you might as well leave all of them open, since you have no idea if your next attack vector is going to be HTTP or SSH. It's better to just keep the box patched and use rate limits/host based IDS/firewalls than deal with the extra hoopla.

Re:Port knocking anyone?

[Anonymous Coward]

>anyone who can monitor your link layer anywhere along a connection you make can see your secret knock

How about one time port knocking as an enhancement? You make a long list of three integers sequences, put one copy on a paper
in your wallet and another resides in your home server. When you knock the first time, you use the first group of three:

telnet 32382 telnet 21028 telnet 27710
or whatever and do your ssh connection within the allowed time window
when you're done, scratch out those numbers so you know to go to the next three next time. Likewise the server
somehow marks the file so it uses the next line of three numbers (either overwrites the file dropping line 1 or
saves off the line number somewhere. That way it doesn't matter if someone snoops the knock numbers, they won't be
valid again.

Re:Port knocking anyone?

[jurgen]

Like I already said, it isn't very strong security, but it's as much real security as any password ever is. I already said it can be listened in on at the link layer... and a password (shared or not) can always be listened in on somewhere, if you encrypt all your network links I can still listen in on your keyboard, etc.

All security is relative and its usefulness must be evaluated against the types of threats that your trying to protect yourself from. If you're trying to protect yourself from un-targeted attacks (and that's not just unsophisticated script kiddies, but includes large-scale phishing by serious attackers) then the port-knocking concept can provide real security, because you can use it to implement a strong password (strong in the sense of being resistant to brute force attack) for network layer connections. It doesn't even matter if these passwords are shared or if your colleagues put them on sticky notes under their desk... the attackers in this particular threat-model don't have access to your link-layer or your desks.

Re:Port knocking anyone?

[swilver]

There's nothing stopping you from giving every user a unique knocking sequence, apart from lack of imagination and software implementation. Is it knock #43? SSHD expects user X to log in. If not, even if using a valid username/password, reject.

Number 2, you already gave a potential solution to that. Also, that situation, in relation to what we're discussing (automated attacks by bots) is unlikely to occur. If you do suddenly get lots of valid knocks, just change your knock.

Number 3... we're attempting to make it less public, not more. So I'm sure that's a problem for a http server, but *shrug*, http is not even a secure protocol.

I just let them in my sandbox

[Anonymous Coward]

It's full of alien conspiracy files, celebrity photos, and random internet rants.

So far, nobody has managed to do any obvious harm.

obfuscation is a win

[Anonymous Coward]

I've secured networks and systems for almost a decade now using both good security engineering and tons of non-standard techniques. Relying only on nonstandard is security by obscurity. Using high quality, although obscure, alternative components for obfuscation has proven value in reducing risk.

Here's an easy one for you guys I won't charge you a consulting fee for: put the critical service on a non-x86 processor, but remove references to the actual ISA. The attackers might get one successful code or malware injection after another, but no execution. I've never seen one figure out why and progress further.

Nick P
schneier.com

Home server? Not everybody has that luxury

[tepples]

I always have my home server available on a fixed IP

Not everybody has the luxury of 1. a home server and 2. an ISP TOS that allows a home server. And even in your case, all you've done is added the length of your home server's password to your SSH password.

Re:Home server? Not everybody has that luxury

[GoogleShill]

You don't have the luxury of an always-on box at home, aka a "server"? Seriously, any old piece of crap system will work and you can use the free dyndns.com service to keep the IP resolvable to static hostname. 'ssh -L' has been a lifesaver for me numerous times. Also, I've never had an ISP block any incoming ports other than port 80 or 25. I've used high SSH ports for years.

Re:Home server? Not everybody has that luxury

[Anonymous Coward]

It's actually somewhat more secure than just 2 ssh logins (neither use default accounts, or the same user names, so it's a username+password for each). The attacker would also need to guess the IP of my home server, even if they knew I that was associated with the external sites. So that would be quite a feat.

To specify which IPs are trusted IPs

[tepples]

I'm not sure where your Web access brainstorm comes from but it has no place in a security strategy of default deny. Default deny is very very simple. Either you are a trusted IP or you aren't.

The web access part is the interface to specify which IPs are trusted IPs at the moment and which aren't.

The length of the VPN's password

[tepples]

All you've done by adding a VPN is added the length of the VPN's password to your SSH password.

Re:The length of the VPN's password

[PlusFiveTroll]

So your saying a 32 char password is better then a 16 char password, whoda thunk it.

Or, to rephrase that, all you've done is make it 500 trillion times harder to crack your ssh (if you're using good passwords), if you are using keyfiles for both then there pretty much needs to be a remote exploit in both the listeners.

Typical geek shit

[Sycraft-fu]

For some reason, geeks seem to think there is magic, perfect, computer security. "Just do THIS and your servers are secure, nobody can ever break in!" Those of us who've dealt with physical security understand there's NO SUCH THING. Good security is a layered approach. You never rely on one thing for security, you have layers so that when, not if, a layer fails you aren't automatically fucked, the other layers hopefully catch it.

While moving SSH to another port may not be a real big security improvement, security improvement don't have to be big to be useful, particularly if the cost is low, and in this case the cost is zero.

Also here's some news: It is 2013 and just now the bots seem to be adapting. That means that it was pretty effective. Seems to me SSH has been in use for, oh, getting close to 18 years now. That's not a bad amount of time for something to stop the bots.

The sooner geek admins start to understand that there is NO perfect security, ever, the sooner we'll start to have better computer security.

answer to OP

[Anonymous Coward]

For others keeping track, have you seen many such attempts?

Yes. Yes I have. And then fail2ban blocked them. My fail2ban keeps a list. This list is reapplied at startup, so blocked hosts persists across restart.

Stop fucking using non-standard ports

[Anonymous Coward]

RFC1700 (http://www.ietf.org/rfc/rfc1700.txt) was put in place for a reason. Stop using ports for purposes that do not belong to them. You're the reason I have kiddies port scanning me every day. If you don't want people logging into your public SSH server, then switch to key authentication and use a whitelist.

Re:Stop fucking using non-standard ports

[fazey]

The reason people move it, is because that doesn't stop them from trying to log in. Why waste the bandwidth? Also, good luck having a machine with 300+ users using ssh keys. Clearly you own one server, and are the only user. Thanks.

Not just ssh

[buss_error]

I'm seeing the old X-FORWARD-FOR 127.0.0.1 attacks come back too.

errr

[DulcetTone]

All security is by obscurity. As in "you don't know my password."

Re:errr

[neonsignal]

• obscurity - "not well known"
• secrecy - "concealed or hidden"

So a password is a secret, not an obscurity, and is not sent across the communications channel.

Zero attempts here the last week

[Anonymous Coward]

I use fail2ban and have a few ssh servers on high ports. It is easy to search logs for the last week - zero attempts across those 5 servers.

When ssh was on port 22, I saw over 1,000 attempts daily.

Seems that moving to high ports really does pretty much solve the problem, but I will not
* be removing fail2ban
* allowing password logins
* allowing remote root logins
No way.

Side effect of the reduced cost of cpu power

[damn_registrars]

While of course bot masters pay essentially nothing for their CPU power, someone has to buy the systems that become zombies for the botnets. As those systems get faster, the things that a botnet master can do expands. For what it's worth I haven't seen an ssh-based attempt on my system in over a month - and the most recent one was only a few hundred attempts from one IP address that maps to Missouri - but I have seen distributed attempts on my system in the past that have made thousands of attempts at the root password (futile when root is disabled, which they would know if they read the ssh greeting) as well as distributed whitepages attacks going for common user names with easy/non-existent passwords.

If ISPs would actually start to take action against the users whose systems make up the botnets, we would see this activity reduced. However it is more profitable for the ISPs to not do so.

question

[fazey]

Is the majority still coming from China? I had recently been tired of being forced to move my sshd ports. So I setup fail2ban, pam_tally2, and remote syslogging with php-syslog as a web interface... This will 1. ban too many bad attempts. -- fail2ban 2. prevent bad user passwords from actually letting the user in after 3 failed attempts -- pam_tally2 3. inform me about it -- remote syslogging+php-syslog I find that 80% of the attempts are from China. So I am about to flip the switch and simply ban all of china (http://www.okean.com/thegoods.html)

Re:question

[fazey]

dangit, new line characters seemed to disappear.

Who uses logins

[kilodelta]

Just use ssh-keygen and setup the key pair.

FYI: iptables tutorial

[Beeftopia]

iptables can be fantastically complex and powerful to protect enterprise networks from all manner of attack. It is also fast and easy to do a simple, basic, strong setup which will provide a powerful firewall to secure a server.

Some useful iptables tutorials and references:

1) From CentOS, but iptables runs the same way regardless of OS. This one creates a pretty solid simple iptables ruleset to protect a server.

2) An Ubuntu tutorial, again simple and informative.

3) From the netfilter/iptables project homepage. Good primer on network concepts too.

4) Deeper information, but very useful. Another good discussion of network concepts.

I recommend typing in a simple text file with the iptables commands, the chmod'ing it so that it is executable. Then execute it ("./myrules"). This works for a small, but powerful list of rules that can protect a server. Some of the tutorials talk of rulesets with thousands of lines. There are different, more efficient ways to load those.

Quick overview of iptables:
1) There are three default chains (containers which sets of rules) called INPUT, FORWARD and OUTPUT.

2) Each of these can have a default policy of ACCEPT or DROP. Input should have a default policy of drop. IMPORTANT - while you're first playing with iptables, make sure input has a default policy of Accept ("iptables -P INPUT ACCEPT") or you may well lock yourself out of your machine. Once you've got the rules set up as you'd like (you view the rules with "iptables -L -v"), then you can do "iptables -P INPUT DROP".

3) Always set these three "housekeeping" or basic rules (prefacing with a '#' is a comment):

# For the loopback interface 127.0.0.1, accept everything. Append to input chain.
iptables -A INPUT -i lo -j ACCEPT
# For ICMP packets, accept pings only
iptables -A INPUT -p ICMP --icmp-type echo-request -j ACCEPT
# For established connections, accept everything, using the older state module
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

4) Your input chain, which deals with incoming packets, will have a default policy of drop. Only ports which are then specifically allowed will be open:

# Accept SSH on port 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Accept HTTP on port 80
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Accept HTTPS on port 443
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

5) You're not using your box as a router, so your FORWARD chain should not get any activity. I leave the policy as Accept, so if there is any traffic logged here, I know something unusual is going on:

# Otherwise, accept all for FORWARD
iptables -P FORWARD ACCEPT

6) Finally your output chain should just allow everything:

# Accept everything:
iptables -P OUTPUT ACCEPT

7) Check your iptables ruleset with "iptables -L -v". If everything looks good, set your default input policy to drop with "iptables -P INPUT DROP"

And that is a spiffy, powerful way to block all ports but 22 (ssh), 80 (http) and 443 (https) by using iptables.

Cryptographic IPv6 Ranges

[zx2c4]

There's an interesting paper on using IPv6 addresses as cryptographic material for this kind of thing.

port 2222

[Skapare]

Port 2222 is fairly obvious for the next port to attack. Pick something totally random. That would work for another year or so until they start trying all 65535 ports. Then you'll probably need some "knock knock" protocol to get let in.

Re:port 2222

[UltraZelda64]

Fairly obvious? I think braindead obvious is a better description for port 2222. I never did get why people use it... are they so incapable of remembering short number sequences that they have to add two more digits of the same number to the standard port number? Just like those idiots who use the combination 1-2-3-4-5 on their luggage. 2222 seems so common as a suggestion for an alternate "high-number" SSH port, it might as well be considered semi-official and just as dangerous as the "real deal" port 22. Never mind that even if 22 wasn't just two more twos tacked on 22, four number 2s is already an easy guess.

There are 65535 ports... is that really the best people can come up with? Seriously, be creative. Have you lived in a house with a long, somewhat complex/random address of 5-6 digits? Use that or something similar! Want another "random" port for some other service? Divide or multiply that address by two, and there you go--a second good port number that you can recall easily knowing your main port number and doing a bit of math. Using something as weak as 2222 is just pure laziness.

Re:FYI: iptables tutorial

[Skapare]

And that is a spiffy, powerful way to block all ports but 22 (ssh), 80 (http) and 443 (https) by using iptables.

This isn't solving the problem. Actually, there are two problems. One is that a multi-user machine might have users that use weak passwords the probers can eventually guess. The other is all those probes. Before I used alternate ports, I've seen as many as half a million probes in just one day. Though no attempt ever got in, it flooded my logs. So it is still to be avoided. For now I'm using port 9173 (not really that one, but similarly obscure).

And you are leaving port 22 open. But even if you do close it and use an alternate port, the concept in this article is that the probers are trying other ports, now. As soon as they starts scanning ports for an SSH banner, they will know where to probe. This isn't solving the problem.

Something more sophisticated is needed. A knock-knock protocol, such as sending a UDP datagram to an obscure port that never responds to anything, but acts on a properly encrypted message by opening another TCP port to the sender or coded IP address (only) for SSH access, would be one good way to do this. Another is pre-shared IPsec in tunnel-mode (no response for packets that fail to decrypt because the inner checksum will fail).

A simple solution

[Beeftopia]

1) iptables to block all ports but the ones you allow.

2) fail2ban - 5 tries and they're gone for 30 minutes. Only the most persistent continue. But they get 10 tries an hour.

3) Configure ssh to disable remote root login (in ubuntu, it's in sshd_config - "PermitRootLogin No"). You can still log on as root if you're sitting at the computer and have a console window. Or you can su to root after you login as another user. Just can't ssh in and directly login as root. From what I've seen, this moots over half of the login attempts.

4) And of course, strong passwords.

So, they can try higher ports, or even port 22, all day long with no consequence.

Change the port to a random number

[Anonymous Coward]

Don't just change the port to something that is an obvious next step. Take 222, 2222, and 22222 off your charts. Pick something that is totally random as your SSH port so that they have to do a port scan in order for them to find the port.

Better yet, as most of the others have already mentioned, use a port knocker.

SSH already has the means to avoid this

[kriston]

Starting now, all the operating system distributions should turn off PasswordAuthentication by default. This really is a non-problem.

As for denial-of-service "script kiddie" attacks, SSH already has built-in rate-limiting in the form of the MaxAuthTries, MaxSessions, and MaxStartups, and even LoginGraceTime and, of course, UseDNS=no.

Besides these two easy and readily available fixes that have been in place for years, why are you logging every visit to SSH on your system, anyway? That's just asking for a DoS attack that fills your log directory or the log directory on your designated loghost. That is, unless you're smart enough to keep a bastion host's log directory in its own volume.

Unless, of course, this is the first you've heard of a bastion host.

Re:SSH already has the means to avoid this

[rubycodez]

I'm more worried about your never hearing of log compression, rotation and removal.

give the attacker something to chew on

[Anonymous Coward]

I don't know how to implement this but is it possible to send the attacker something computationally expensive to do with each failed attempt. if it only takes the host microseconds to reject a password but the client has to invest an escalating amount of time on his own machine to find the answer to some puzzle then it quickly becomes a waste of effort for the attacker.

No, I'm not

[DaveAtFraud]

Knowing my site's IP address (findable with some research) doesn't do him any good. He has to spoof the IP address of the location I'm connecting FROM. When I'm on the road and connecting in via ssh, I usually don't know (or care) what IP address I'm connecting from.

Somebody could try to sniff my ISP's traffic and watch for a connection to my ssh port and then attempt to spoof the source IP address for that traffic. They'd more likely step on someone else trying to hack my site, not me.

Cheers,
Dave

Two-factor?

[wellard1981]

I still run SSH on it's standard port with DenyHosts. However, I add a second layer such as two-factor authentication: http://code.google.com/p/google-authenticator/. Even if you do manage to somehow get my password, you still need my one-time pass code. It's not perfect, but I believe it reduces the risk of having a publicly accessible SSH server being compromised.

No option to not respond falsely?

[BlueCoder]

Portsniffing is nothing new. I just looked briefly but didn't see an option for what I was expecting to exist.

Does SSHD have no option to not respond to a bad credentials?

Seems to me like it should be trivial to implement. Don't acknowledge bad connections. Don't ack anything. Be a blackhole port. Only respond if and when ssh sends correct credentials. Require the initial connection over UDP.

Ssh provides excellent security. This is just about stopping the waste in bandwidth.

Re:No option to not respond falsely?

[drinkypoo]

Does SSHD have no option to not respond to a bad credentials?

How is it supposed to agree to accept them without leaking any information? This is a silly solution to this problem. A better one is to always use ipsec, whether you use ssh or not. Now they have to defeat two systems, not just one which you're trying to protect with obscurity.

Re:FYI: iptables tutorial

[Beeftopia]

And that is a spiffy, powerful way to block all ports but 22 (ssh), 80 (http) and 443 (https) by using iptables.

This isn't solving the problem.

True enough. I'd been meaning to make an iptables tutorial post for a while. Perhaps this wasn't the best place for it.

Re:Don't rely ONLY on security-though-obscurity

[Anonymous Coward]

There, I fixed the title for you.

I use both a nonstandard port as well as Denyhosts. My block file only numbers in the hundreds, yours in the many thousands. Why? Because every random scan that hits my system flags my IP as "not likely" and moves on, when it hits your IP you get flagged as "valid target" and then you get hit with focused attacks.

If you're going to pretend to understand security, then at least get the saying right. Yes, it's never a good idea to only use obscurity, but there's rarely any valid reason to NOT use it as part of a layered model.

Not a problem

[Jeremi]

I'm running my ssh server on port 23¾ now; that ought to keep the muggles out for a while.

Good ports ?

[redelm]

OK, lets say I want to try a "high port" -- why 2222 other than memorability? What ports are typical corp/govt/hotel/cafe router/firewalls likely to pass? What about the more anal firewalls?

FWIW throttling sshd can be done via MaxStartups in sshd.config .

Re:Good ports ?

[GameboyRMH]

2222 is the worst alternate port you could use, that's probably the second port a multi-port brute-force script will try after 22.

Re:Good ports ?

[fazey]

I use 23 for this very reason. A lot of people still allow telnet traffic. I ran into this problem when I was away at college.

Re:Good ports ?

[The Conductor]

I was surprised to see how many networks allow connections on port 23 when, for example, all web browsing goes through a proxy. I think the reason is that Cisco routers use plain 'ol telnet for administration.

Re:Good ports ?

[jrumney]

What ports are typical corp/govt/hotel/cafe router/firewalls likely to pass?

443 is a good candidate if you don't need https on the server you are running ssh on, as even with a proxy in the way, the content of the packets is not going to be expected to conform to some control-freak sysadmin's idea of what you should be allowed to do on his network.

Better than that...

[IBitOBear]

The below will create a dynamic blacklist. Any IP address that connects more than three times in five hours (pass or fail) will go into a blacklit that will persist until they stop trying for at least a day.

This will recodr your bad actors _and_ it will "expire" in case you invalidate a system by accident (e.g. over-use).

iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE

Re:Better than that...

[Anonymous Coward]

I take it you've never had a bad Internet connection while trying to get work done. Or never sent more than one scp alongside your terminal ssh connection. 3 per 5 hours is crazy. 3 per 10 or twenty minutes is more reasonable, but using something that reads security log files like fail2ban or denyhosts makes even more sense unless you're trying to piss off legit users and provide an excuse to the boss ("I'd unblock your IP, but I'm blocked until tomorrow. Guess you should have hired someone who gives a damn").

Re:Better than that...

[gmack]

If I ever did this on any of my employer's servers I wouldn't expect to keep my job for much longer. Any countermeasure that cannot tell the difference between good and bad attempts is worthless. Imagine a room full of webdevs behind a NAT that use SCP to transfer files and then take a guess at the resulting productivity after your "solution" is implemented.

Re:Better than that...

[Anonymous Coward]

Um, if it's key-only then your webdevs have a file on their computer with the key in it.
If your webdev has to swap keys, that's whole different problem.

Btw, Accenture only allows 4 password login attempts per hour on their email/portal systems. Works fine for a fortune-500 company with 100,000 developers in 100+ countrys, maybe you should consider it?

Re:Better than that...

[cthulhu11]

Don't monitor your servers, do you?

Re:Better than that...

[IBitOBear]

Why would the filter be on the NAT interface anyway?

If you don't know that every solution is not one-size-fits-all you deserve not to have that job.

If you cannot suss out the part where a generalized solution is a starting point for adaptation then you should never have managed to get the job in the first place. /doh.

Re:Better than that...

[IBitOBear]

I do. Instead of parsing a long log I just "cat /proc/net/xt_recent/bad_actors" instead of parsing the hell out of a log file looking for nuggets.

The hard was isn't always the best way.

Re:Better than that...

[gmack]

The filter would not be on the NAT interface but the servers are not in the office with the developers so connections from all of them would be from the same IP. That's multiple connections per hour for completely legitimate reasons.

Your "generalized solution" is not the starting point of anything. It's completely blind since it cannot tell the difference between a good or bad connection attempt and it treats them both as bad. Much better to use something like fail2ban (which we use extensively) since it can tell the difference between good and bad and will only block the bad actors.

Re:Better than that...

[cthulhu11]

M-x miss-point. Monitoring entails connection attempts from the monitoring server, which are impossible if one blocks them.

Re:Better than that...

[Anonymous Coward]

The rules are still useful, just not in your case. Being an IT professional, part of the job is knowing the right tool for the job. While it is good that you can recognize that this tool isn't the right one for your job, it doesn't invalidate the usefulness of the tool. I imagine it might be a quick useful solution to others, specifically home users. Personally, I use fail2ban to search the log files for bad password attempts. It is still IP based banning though. Proxy and NAT users beware.

Re:Better than that...

[IBitOBear]

one size does not fit all. If you don't know how to ajust filters, or how to spot when a solution is not for you, just come out and say so.

You look foolish when you bleat that what someone offers doesn't work for your specific case and so decry it as unilaterally unsound.

Grow up.

Re:Better than that...

[IBitOBear]

not if one adds logs to ones blocks, which is a different issue entirely.

Again "starting point".. contemplate it. Add "branching" and "core logical structure" and "basic computer programming" to the list of ideas you should work on and the do some reading up boy.

When you particluarly consider that I was addressing a "better way" to do the throttling (e.g. reducing from "4 attempts an hour" to "five attemtps in an hour causes indefinite block") all your plaintive whines are basically immature and off-topic blather.

Just admit that your "but what about (whatever)" statements reveal that you don't particularly know how to generalize yoru knowledge, the buckle down and do some study.

Re:Better than that...

[gmack]

If you post something three times to a discussion you should expect someone to call you out on the shortcomings and no amount of condescension on your part will fix the shortcomings of what you posted.

Re:Better than that...

[IBitOBear]

yea, right... so what were those shortcommings again? that one guy didn't like the filter for his monitoring purposes... I fee so wrong for posting now... my shame is endless... whatever shall I do...

Oh yea... remember that if chump don't want the help, chump can ignore the help.

Re:Better than that...

[wermske]

For any generic hypothetical, it is entirely possible to unleash the hounds of hypothetical challenge. Such, neither demolishes the original hypothetical nor emboldens the credibility of the challenge. Both are weighed on their own contributory merits. Principles over personality.

Re:Better than that...

[IBitOBear]

I would expect to be called on shortcomings... But that didn't happen... Someone who didn't bother to understand the code mis-applied it to his situation and then called that misapplication for being flawed.

See, I responded in a conversational chain about "brute forcing a key" with a basic structure on how to blacklist a brute force attempt source. (and in two other places I did paste the same code since Slashdot doesn't let you easily fold sub-topics, but in each case the conversation was slightly different.)

Now at no time did I say "this will solve all your problems or address all your issues". For example one of the "short-comings" was about logging and the other involved use _inside_ a VPN where connection rates would be intentionally much higher. Neither is a real short-coming as people with even trivial knowledge of program flow and iptables in general would know how to deal with both situations. Things like picking the network interfaces to apply the rules to, and fully understanding that where rules are not desired, they should not be applied. (it's kind of no-duh that way, life). [In fact, if you look at the command I use "ext+" (instead of the default "eth+" et al.) as the interface, which is completely non-standard to deter "cut and paste" application and encourage thought about how the model might be used.

Logging is another issue wholly. Most people collect _way_ more logs than they should and then end up losing their important information in a flood of data. [ASIDE: this is why Gestaltism failed and the Scientific Method came to prominence.] It _shouldn't_ take much brain at all to figure out the various ways that logging would dress onto the skeleton above. On systems with high logging standards I usually replace most-or-all "ACCEPT" rules with a jump to an accept chain that contains uniform "success" logging (e.g. see LOG target --log-prefix element). I like to put failure logging at "the point of failure detection", and only one fail notice, so that I don't have to fish through repeats. Then I let tools (like the way the "recent" match stores the date/time of encounters) do their jobs rather than spending a lot of CPU to re-chew raw logs for no flipping reason at all. [Mil-spec sites will, clearly, have other requirements, which are solved by other means.]

As for the Condescension. That too is a useful tool, applied quite carefully in this case, that makes people think and re-read instead of reflex flame. Now you have jumped valiantly to the defense of some clod, and I decry you for that, because you have amplified his mistake with your opprobrium. This makes you more wrong than him. You have stepped in as arbiter of form with disregard to content. You are pure noise with no signal whatsoever. your single data point is my *horror* repetition of the code in other contexts. You got me. I am willing to put the same idea in front of more than one subset of a conversation. How this must wound the internet, and confuse it beyond its ability to cope. The internet has never seen repetition so foul as I have done here.... oh wait....

I do indeed condescend, to him, and to you. His histrionic, left-handed, and unsupported assertion (q.v. "I would be fired if...") set the tone for what followed and I was willing in whole to treat with him on his terms. Your yappy-dog, I want to seem important too, infantile insertion was not even up to the low bar we were dancing above. Oh good show to you find tagger-along. You have wounded me to the quick with your amazing and subtle support of his shortsightedness. Bravo!

If you don't understand why littering a design pattern/example with noise is just plain bad instruction, perhaps you should retire from the field and take up something that better suits your cook-book-only, can't be bothered to think, self-limiting mentality.

Welcome to 2005

[Shaiku]

This phenomenon and all the proposed solutions (tarpitting, port knocking, fail2ban, rate limiting) are old news. This whole headline is old news. I've seen coordinated distributed robo-worm port scans and brute force attacks on every service of every port of my servers since ages ago. Fail2ban ultimately does nothing since the source IPs switch every few seconds to a random country. All it ever did was eventually lock myself out for 20 minutes when I typo'd a password.

The only real solution (which we can't implement) is to shut down the bot nets and disconnect infected hosts.

Auto-blacklisting throttle.

[IBitOBear]

iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE

Security through obscurity is also security

[talornin]

It seems like everyone is in agreement that moving sshd to a non-standard port is stupid and a waste of time.

I disagree. It is of course not a matter of just changing the port and then be done with it. In addition to all the other security measures (fail2ban, iptables-woodo, key-based auth, etc) moving your sshd (or any service) to a non standard port is both an advisable and mildly effective security enhancing activity.

It might be that some bots are taking the time to scan the entire port space, but the number probes that bother to try your high hanging ports are negligible compared to the never ending avalanche of zombies that tries to squeeze through port 22 (or any other standard port for any other popular service for that matter.)

There is also the matter of bugs in the software. Though sshd is one of the most vetted, and hardened pieces of code out there it only takes one bug to cause a disaster (which has happened before). Attacks never get worse, they only get better! In the case of a 0-day in sshd that allows for arbitrary code execution I sure as hell don't want to be amongst the masses running on port 22.

In conclusion: If your only security measure is to move your services to non-standard ports, you might as well not bother. But your security level is a shade of gray, and using non-standard ports moves the slider a tad in the right direction.

Better for me...

[IBitOBear]

I use the below. It has several benefits. It creates a blacklist of sorts of only the bad actors, which can be shared with other rule groups. It only does the test once instead of in separate rules for reject and log etc. I don't boter logging when I can check the bad actors table directly, but any fun things can happen after the ACCEPT (or RETURN) as long as you make sure you reach the pivotal --set operation.

Most importantly this lets 5 attempts per hour from any given IP address and if they have to go away for a day (obviously ajustable) before they can try again. This means you can get deep resistance (60 seconds is too short to truely deter some probes) but if you accidentlaly invalidate a host via over-use you just have to wait a day for things to be good again.

Good for use with ControlMaster option if you frequently have to connect to that host from a particular source. I also allow two password attempts only per connection.

Note that you can replace ACCEPT with RETURN if you want to run other tests after this before accepting the packet.

iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE

Port knocking

[hedley]

Just put sshd on a port of your choosing and light it up with a secret knock, disconnect and its back to a brick wall, no port reponses.

H.

Look in the mirror

[Anonymous Coward]

Standard ports are reflected back at the originating IP so the botnet hacks itself.

Why are you worried?

[Anonymous Coward]

OK, I've run the same ssh server allowing password auth from the internet for about 14 years now. I see the attempts, I was even a bit worried when the brute forces started around 2003-4. I've never once had a successful login. My passwords are slightly complex, but nothing to write home about. Every one of these attempts (ok, 99.99999999998% of these attempts) are trying super complex things like root:root toor:root root:god root:admin games:games, etc. They aren't even particularly persistant. They are looking for the super low-hanging fruit. Unless you are the super low-hanging fruit, what ar you worried about? I'm more concerned about a weakness in RSA or DSA than these morons.

Port 2222?

[gatkinso]

Who would EVER guess that someone is using that for their ssh daemon after failing to connect on port 22?

ssh hammering

[l3v1]

Well, I only handle 2 servers at work, both behind a router that only opens necessary ports. Also, using denyhosts to ban any IP for 2 months that tries getting in more than 5 times. Port 22 tries result in dozens of new daily bans, the other on a high port makes 1-2 monthly. Also, from time to time, I browse the logs manually as well. No - known - breakins in the last 3 years.

Not obscurity

[weegiekev]

Before anyone else comes in again with "security through obscurity doesn't work", running ssh on a non-standard port certainly isn't.

There's plenty of people out there who are scanning port 22 to find SSH instances. You can bet there's databases out there of IP addresses which responded with ssh and their ssh ident string that they returned. The second an SSH hole is found, those lists will be the first point of call for an attacker who wants to hit known vulnerable systems before they get patched.

If the people building these databases had to scan all ports to find ssh, they'd be spending a very very long time portscanning the internet.

Expose SSH over VPN only

[thenendo]

My solution is to not even expose SSH to the public internet. Instead I run OpenVPN on the server, and only expose SSH access to hosts who have joined the virtual network (which itself requires a client certificate). Even then, SSH access is pubkey/Kerberos only.

Now I get zero ssh gropes, and nobody even tries to get into the VPN. The OpenVPN port doesn't even show up in an out-of-the-box nmap -v -A scan.

Inactivity; carrier-grade NAT

[tepples]

You

I was referring not to my own situation but to the situations of others.

don't have the luxury of an always-on box at home, aka a "server"?

Not everybody has the luxury of an unlimited electricity budget to keep a box at home from going to sleep after 30 minutes of lack of input.

Seriously, any old piece of crap system will work and you can use the free dyndns.com service to keep the IP resolvable to static hostname.

But will the SSH server implementing a default deny policy know to check the free dyndns.com service to see which IP addresses are allowed to connect? If so, all you've done is added the length of your dyndns.com account's password to your SSH password. And the last time I used a free service similar to dyndns.com, I got a monthly e-mail asking me to click through and solve a CAPTCHA within the next seven days to keep the name active.

Also, I've never had an ISP block any incoming ports other than port 80 or 25.

Not everybody has the luxury of a home ISP that allows 60,000+ different incoming ports. Some ISPs don't even give home customers a dynamic IPv4 address; all outgoing connections pass through a carrier-grade NAT, and all incoming connections are refused.

Blocking customers in BRIC and Ukraine

[tepples]

For most everybody, individuals and businesses, there is no reason whatsoever to allow Chinese traffic. Ditto Russian, Ukrainian, Brazilian, etc.

If PhilsHobbyShop.com were to block all traffic from BRIC and Ukraine, even ports 443 (HTTPS) and 80 (HTTP), customers in those countries would choose one of Phil's Hobby Shop's competitors. And even if you're referring to blocking SSH and HTTPS administration interfaces and not blocking HTTPS customer interfaces, that still means all the other server technicians need to reconfigure the server every time a technician takes an international vacation (during which he's theoretically always on call for emergencies).

Re:Blocking customers in BRIC and Ukraine

[RocketRabbit]

Yes, but Phil is in Nashville, and there are closer and less expensive hobby shops available to the Ukranian shopper. In the last 12 years that Phil has been online, before he blocked all the dubious nations on Jan. 1, he never shipped internationally except to one guy in Canada.

Yes, I am advocating blocking all traffic from nations that generate the majority of these kinds of attempts. If this became a policy, and it was done by ISPs, major telecoms, etc, then these nations might clean up their act and their ISPs might respond to complaints with action and not just mocking laughter.

Re:Blocking customers in BRIC and Ukraine

[tepples]

Over 30 percent of the store's sales is international. I checked.

Re:Blocking customers in BRIC and Ukraine

[RocketRabbit]

No, he doesn't even ship to anywhere outside the US and Canada, and that one guy in Canada only made one order almost 8 years ago now.

For many businesses, the vague possibility of making an international sale is outweighed by the very real and persistent attacks coming from these dubious nations. For individuals, the possibility however slim of making a sale to the Ukraine or Russia or China is eliminated, also eliminating any necessity of allowing traffic from those nations.

My question to you: What is your agenda? Why are you advocating that people should engage in risky behaviors like allowing internet traffic from these dubious nations? Is there a potential benefit that you intend to exploit there, or is it based upon some misguided principle of openness?

Re:Blocking customers in BRIC and Ukraine

[tepples]

Full disclosure: I am involved with the web presence of Phil's Hobby Shop.

No, [PhilsHobbyShop.com] doesn't even ship to anywhere outside the US and Canada

Your previous post inspired me to add statistics to the software that powers PhilsHobbyShop.com. I have statistics, and Canada isn't even second place. It's USA, then someone else, then Canada. On the other hand, it could be that you're reporting a problem with the web software. Did something break when you went to PhilsHobbyShop.com, added an item to the cart, began checkout, and put in a non-U.S. shipping address? It doesn't appear so: the first order I saw when I logged in to an administrative interface was from (you guessed it) Ukraine.

For many businesses, the vague possibility of making an international sale is outweighed by the very real and persistent attacks coming from these dubious nations.

Then how do companies like Amazon and eBay, with their worldwide presence, fend off these attacks?

For individuals, the possibility however slim of making a sale to the Ukraine or Russia or China is eliminated, also eliminating any necessity of allowing traffic from those nations.

If a stateless firewall blocks all packets from these countries on all protocols and all ports, this would result in end-user confusion when one visits a legitimate web site hosted in one of those countries.

Is there a potential benefit that you intend to exploit there

More revenue. Lots more revenue.

I am a old CDC hacker

[Anonymous Coward]

I work alone and if you get locked in that is your own fault. It is not a question of being locked in or out it is the fact that most programmers and IT admin's worldwide are bums.

For the uneducated that is Cult of the Dead Cow; but a group of people who can program in many languages; lock down;, secure and s/send/patches for the good of all.

Multi-factor authentication

[MrdrJnkee000]

No system is flawless, but some of the techniques mentioned above can make a system reasonably formidable to potential attackers. Paul Sery created a wonderful PAM module (pluggable authentication module), for out-of-band challenge-response, called pam_obc. Da Beave improved pam_obc and made it available on GitHub (https://github.com/beave/pam_obc). Regarding bandwidth, system resources, etc., it depends on the specific organization's priorities as to what solutions they might implement at each "layer" of the security onion. PAM modules require a negligible amount of system resources, minimal bandwidth, and the challenges can be sent over encrypted channels. I am not saying that pam_obc will make an SSH server impervious to attacks, but for some people it may be part of the solution that they are looking for. Regards

P.S.

[IBitOBear]

The entire table is available for adding logging and whatnot. The (empty) range from the ACCEPT line to the final DROP in the sub table can also be decorated with logging or whatever else you might want to do with the failed packet, and then you only get one log entry per event instead of attempt. That logging or whatever was not germane to the example mechanic.

Re:P.S.

[cthulhu11]

Who said anything about tables?

Re:P.S.

[IBitOBear]

uh... I did... lets look at the command "iptables"... the word is right there... "table"... it's like the third through seventh letters... this is not that tough...

Perhaps the word "sub" confused you with sandwitch making issues?

See, the technique is to add a "--new -chain", which is correct to use synonymously as "table" given the history of the command (e.g. most people don't really try to get all "a chain isn't a table" particularly since I delinated a range in the table that happens to be in just the one chain therein so both words apply equally).

There is this mathematical discipline called "set theory" and a range within a table is itself a table, just as a subset is a set. So the range of the table that lies between the ACCEPT and the subsequent DROP is an ordered space where other directives can be added. If one wanted to log dropped connect attempts one could add "iptables --jump LOG" with no other conditionals or redundant tests right after the ACCEPT directive.

Perhaps you should learn to read before you get all corrective at people.

Maybe I am too old-school referring to a chain as a sub table, but that's where decades of experience tends to become a weight. Us old folks don't bother with distinctions that make no difference. I know that means the ball bounces a litte too fast for the self-obsessed to follow, but what is one to do in these circumstances.

Even more so, if one wanted to log _successful_ connections one could replace the word "ACCEPT" with the word "RETURN" and then place logs or whatnot after the --jump into ssh_throttle itself.

It's called "branching" and we use it in computer sicence all the time to remove things like redundant testing.

Block it

[Anonymous Coward]

Yes, I've seen many such attempts.

Non-Standard port, Certificate only, fail2ban and whitelist at Router level.

geoip kernel

[blokkie]

I use kernel module geoip which not only blocks ssh attempts but any other service you want. (http , ftp .. ) on network level.
It uses a kernel module , a csv with the ip country blocks and ip-tables.

So you can say : I only allow ssh from this country and block all the rest.
It does a remarkable job

I just had myself intentionally blocked by th GFOC

[Anonymous Coward]

My front page on my website is useless anyhow, so I phrases similar to Democracy is great, Free Tibet, and Remember Tiananmen Square to the body of the main website. Amazingly, this worked far better than I imagined, better than adding firewall rules to block all chinese IP addresses. My hack attempts have dropped to 0 over the past several months. It wasn't just SSH either.
Running your own server? ~$10/month for electricity. Internet Connection? Gotta have it anyhow. Having the great firewall of China block all hack attampts on your site? Priceless.

insensitive clod

[sys_mast]

ssh IS my vpn!!!

Re:insensitive clod

[sys_mast]

OK for all you kids out there, you can "tunnel" other traffic over an SSH connection. Used it all the time back in the day, only had an SSH port open and port 80. (80 for the stuff I wanted people to find)

The reason(s) for this constructon

[IBitOBear]

While I do use this at home, I also use it on a number of forward facing servers for business purposes (usually with different thresholds and numbers). I spend very little time at "my desk" so the ability to know that I will always have a computer with a pre-shared key available is quite limited. If I am, say, at a hangar at an airfield and I get an emergency call to check on a host, I can ssh to my own (unprivileged) account and elevate my privileges thereafter. So I, and my very few alternates, can respond from anywhere with no chance of leaking meaningful key material as one might if they tried to match up known/authorized keys (and USB sticks are verboten in many of the places I find myself).

In that usage pattern, if I ended up having to ssh in more than five times in a single hour then things are really not right. (and if I knew that sort of thing was going to happen I _could_ always tweak the rule, but I more often use the multi-session ControlPath etc options to side-step the 5-per-hour limit if larger maintenance comes to the front).

That is, I limit the connections pass-or-fail, because it matches the expected (sparse) use pattern and so also limits the ability of a compromised machine I might use as a source box from spanning into the target machine. For instance I can use a source host and then invalidate it by making a couple extra connections so if, say, I have to use an internet cafe (it's never happened, but it might) or hotel computer or whatever, I can keep a clever follower-on from using a key-logger or whatever, from just using the link agian. [granted he could use the information from a different computer etc and I have other means for dealing with that sort of thing (locking the access account after use until I can get somewhere secure and change the password; single-use passwords on some systems, etc), but in terms of a quick access and then block, this works well.]

Different access models require different tools. Being able to ssh in from just about anywhere has come up as useful. Having several useful ways of closing that door, or having it slammed shut perforce, after the valid use are also important levels in any paradigm.

Also, if you reuse the named recent table (e.g. "bad_actors" in this example) [or indeed a whole chain if it's not SSH specific if you replace "ACCEPT" with "RETURN"] in different rules you can easily catch a machine on its very first port-scan or on a single attempt to reach a service you know you don't offer (like SMB service) and drop it into the named table. This lets the co-variants of the one rule "gang up" on the bad actor from different parts of your rule set without invoking expensive external processes. For instance if you also --set an IP address as a bad_actor for sending you a SYN/FIN or a broadcast ping then that one host doesn't get to double or triple dip your security.

more on point

[IBitOBear]

since fail2ban would ban the entire NAT(ed) other office if one actor there were to fail-out from a host in that office, it suffers from the same "short coming" as my script in general, and if you know that some particular shop somewhere is behind a nat, why wouldn't you then white-list that address anyway? e.g. using fail2ban is a good way to let one noob at (remote office) lock out everyone at (remote office). Just because it _hasn't_ happened to you yet doesn't mean that you are ready for the case when it does.

That's a real wizzer of a solution there bob...

If you don't already have white-lists (and preferably VPNs) between known good sites you are just a denial-of-service or "I can't remember my password with this hangover" event away from the theoretical firing anyway.

Again, if you don't know how to apply your tools then all solutions that you don't already think are super-duper will seem suspect. Since you don't seem to know the weaknesses of your current solution, and you improperly apply your "wisdom" as analysis of _my_ solution, you are proved doubly wrong.

Cookbook fail to you, good sir...

(P.S. I know, and point out, that the good and bad attempts are counted in the limit. There are reasons. That those reasons don't apply to your case doesn't make _me_ wrong, it makes _you_ short-sighted for assuming that what doesn't work for your case can't possibly be correct for anyone. 8-)

Re:more on point

[gmack]

Pro tip. SYN packets are frighteningly easy to spoof and you are matching based on them.

Not only can your solution not be able to tell a good from bad one, it can't tell a real connection from a fake one. A firewall running this can have random hosts added to it by any attacker sending it the right packets.

When you make up storys be a tiny bit plausable

[Anonymous Coward]

Obviously never been to Idaho. Jews are very rare, a throw away rounding digit percentage wise and Presbyterian less than 1%
  In Northern Idaho few attend any church. and Southern Idaho is 35 to 90% Mormon, depending on the town.

Re:FYI: iptables tutorial

[slashuzer]

6) Finally your output chain should just allow everything:

# Accept everything: iptables -P OUTPUT ACCEPT

Now this is just plain shitty advice.

Thanks for the four links to external articles, though. Hopefully people will use them as a starting point rather than your own rules when deciding on their firewall configuration.

Re:FYI: iptables tutorial

[Skapare]

Maybe one that teaches people how to do easy open/close of a given port for new connection source, based on some other network event that can be securely evaluated (like a DH exchange on some UDP port), would be good.