Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

SSH Password Gropers Are Now Trying High Ports

timothy posted about 2 years ago | from the for-higher-love dept.

Security 349

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?

Sorry! There are no comments related to the filter you selected.

Low Hanging Fruit (5, Informative)

Nerdfest (867930) | about 2 years ago | (#42923859)

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 (4, Interesting)

bcmm (768152) | about 2 years ago | (#42923961)

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 (4, Funny)

cstdenis (1118589) | about 2 years ago | (#42924119)

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

Re:Low Hanging Fruit (4, Informative)

kiddygrinder (605598) | about 2 years ago | (#42924331)

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 (5, Funny)

larry bagina (561269) | about 2 years ago | (#42924145)

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 (0)

Anonymous Coward | about 2 years ago | (#42924193)

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

Re:Low Hanging Fruit (5, Informative)

DaveAtFraud (460127) | about 2 years ago | (#42923981)

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 (0)

Anonymous Coward | about 2 years ago | (#42924075)

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

Re:Low Hanging Fruit (0)

Anonymous Coward | about 2 years ago | (#42924117)

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

Re:Low Hanging Fruit (1)

Anonymous Coward | about 2 years ago | (#42924195)

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 (0)

Anonymous Coward | about 2 years ago | (#42924349)

You can't really spoof TCP connections.

Re:Low Hanging Fruit (0)

Anonymous Coward | about 2 years ago | (#42924445)

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 (1)

lophophore (4087) | about 2 years ago | (#42924203)

I like that. Thanks for sharing!

Re:Low Hanging Fruit (2)

houghi (78078) | about 2 years ago | (#42924339)

I use http://www.aczoom.com/blockhosts [aczoom.com] .
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 (1)

KiloByte (825081) | about 2 years ago | (#42924415)

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 (3, Informative)

DarwinSurvivor (1752106) | about 2 years ago | (#42924503)

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

Re:Low Hanging Fruit (1)

jgrahn (181062) | about 2 years ago | (#42924521)

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.

Security by obscurity ... (1)

Kardos (1348077) | about 2 years ago | (#42923863)

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

Stormthirst (66538) | about 2 years ago | (#42923887)

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

Stormthirst (66538) | about 2 years ago | (#42923893)

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

Re:Security by obscurity ... (2)

deains (1726012) | about 2 years ago | (#42923959)

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 ... (4, Insightful)

Anonymous Coward | about 2 years ago | (#42924003)

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

Stormthirst (66538) | about 2 years ago | (#42924031)

Agreed.

Re:Security by obscurity ... (1)

Peter H.S. (38077) | about 2 years ago | (#42924021)

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

doohan (1829634) | about 2 years ago | (#42924153)

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

Re:Security by obscurity ... (1)

Stormthirst (66538) | about 2 years ago | (#42924427)

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

Anonymous Coward | about 2 years ago | (#42923901)

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.

I do security by antiquity (5, Funny)

Anonymous Coward | about 2 years ago | (#42924343)

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

Just lock em out... (0)

Anonymous Coward | about 2 years ago | (#42923873)

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

Sheesh, it ain't rocket surgery.

Re:Just lock em out... (1)

Kardos (1348077) | about 2 years ago | (#42923881)

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

macbeth66 (204889) | about 2 years ago | (#42923949)

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... (5, Insightful)

msauve (701917) | about 2 years ago | (#42923985)

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... (4, Funny)

AmiMoJo (196126) | about 2 years ago | (#42924515)

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

Kardos (1348077) | about 2 years ago | (#42923997)

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

Eil (82413) | about 2 years ago | (#42924017)

You lock up an account after a few password failures.

Thereby turning a nuisance into a DoS.

...and watch them lock YOU out (1)

tepples (727027) | about 2 years ago | (#42924035)

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.

Re:Just lock em out... (0)

Anonymous Coward | about 2 years ago | (#42923969)

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

godrik (1287354) | about 2 years ago | (#42924249)

"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... (1)

Anonymous Coward | about 2 years ago | (#42923937)

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

Re:Just lock em out... (0)

Anonymous Coward | about 2 years ago | (#42923995)

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

Then only allow the IPs you want to connect.

Interface for specifying approved IPs (1)

tepples (727027) | about 2 years ago | (#42924111)

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 (0)

Anonymous Coward | about 2 years ago | (#42924317)

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 (2)

KiloByte (825081) | about 2 years ago | (#42924497)

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 (1)

srh2o (442608) | about 2 years ago | (#42924435)

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.

Yes (0)

Anonymous Coward | about 2 years ago | (#42923877)

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 (1)

benjfowler (239527) | about 2 years ago | (#42924275)

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 (0)

Anonymous Coward | about 2 years ago | (#42923885)

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 (0)

Anonymous Coward | about 2 years ago | (#42923955)

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

No (2)

Ultra64 (318705) | about 2 years ago | (#42923889)

"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 (4, Interesting)

SuricouRaven (1897204) | about 2 years ago | (#42923923)

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.

Distributed attacks (1)

tepples (727027) | about 2 years ago | (#42924085)

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.

Don't rely on security-though-obscurity (4, Informative)

Gaygirlie (1657131) | about 2 years ago | (#42923897)

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 (0)

Anonymous Coward | about 2 years ago | (#42924429)

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 (1)

gallondr00nk (868673) | about 2 years ago | (#42924431)

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 (5, Insightful)

AmiMoJo (196126) | about 2 years ago | (#42924469)

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.

No I haven't, and here is why: (3, Interesting)

Anonymous Coward | about 2 years ago | (#42923903)

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

Use random IPv6 from a /64 range (4, Interesting)

Anonymous Coward | about 2 years ago | (#42923907)

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.

Mod parent up (0)

Anonymous Coward | about 2 years ago | (#42923989)

Excellent advice.

Re:Use random IPv6 from a /64 range (3, Insightful)

tepples (727027) | about 2 years ago | (#42924055)

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 (0)

Anonymous Coward | about 2 years ago | (#42924225)

Nope, just use a tunnel.

Re:Use random IPv6 from a /64 range (1)

tepples (727027) | about 2 years ago | (#42924345)

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

Re:Use random IPv6 from a /64 range (0)

Anonymous Coward | about 2 years ago | (#42924245)

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!

OK ... (0)

Anonymous Coward | about 2 years ago | (#42923917)

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

Anonymous Coward | about 2 years ago | (#42923925)

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

CSF is the answer (2)

BradBeckett (921952) | about 2 years ago | (#42923931)

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

Re:CSF is the answer (2)

wiredlogic (135348) | about 2 years ago | (#42924251)

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 (0)

Anonymous Coward | about 2 years ago | (#42924377)

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 (0)

Anonymous Coward | about 2 years ago | (#42923935)

fail2ban. done.

Dumbass parroting. (5, Interesting)

Anonymous Coward | about 2 years ago | (#42923945)

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.

Very few (4, Interesting)

PktLoss (647983) | about 2 years ago | (#42923963)

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.

Standard port (0)

Anonymous Coward | about 2 years ago | (#42923965)

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.

When an attacker controls 10,000 IPs (4, Insightful)

tepples (727027) | about 2 years ago | (#42924121)

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?

Convenience (0)

Anonymous Coward | about 2 years ago | (#42923977)

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.

VPN (3, Interesting)

sgt scrub (869860) | about 2 years ago | (#42923993)

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

Re:VPN (0)

Anonymous Coward | about 2 years ago | (#42924173)

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.

My god, they've discovered nmap (1)

Gothmolly (148874) | about 2 years ago | (#42924001)

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 (1)

_Ludwig (86077) | about 2 years ago | (#42924109)

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 (1)

DamonHD (794830) | about 2 years ago | (#42924205)

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 (1)

ArsenneLupin (766289) | about 2 years ago | (#42924483)

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 (0)

Anonymous Coward | about 2 years ago | (#42924209)

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

Attempt Limits (0)

Anonymous Coward | about 2 years ago | (#42924039)

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

PenguinJeff (1248208) | about 2 years ago | (#42924067)

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.

if you can log (1)

arbiter1 (1204146) | about 2 years ago | (#42924079)

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

Administrators group (2)

tepples (727027) | about 2 years ago | (#42924137)

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 (1)

Culture20 (968837) | about 2 years ago | (#42924257)

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

Re:Administrators group (1)

tepples (727027) | about 2 years ago | (#42924333)

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

I am working on a well Trojan horse (0)

Anonymous Coward | about 2 years ago | (#42924133)

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.

seems like you're asking for it (0)

Anonymous Coward | about 2 years ago | (#42924181)

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 (1)

caseih (160668) | about 2 years ago | (#42924227)

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

Tanuki64 (989726) | about 2 years ago | (#42924229)

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?

SSHGuard FTW (3, Informative)

water-and-sewer (612923) | about 2 years ago | (#42924261)

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 [rferl.org]
    They've got it in FreeBSD ports, which makes it easy to install into an existing firewall.

Re:SSHGuard FTW (1)

water-and-sewer (612923) | about 2 years ago | (#42924263)

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/ [sshguard.net]

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

yep, I do vpn (0)

urbieta (212354) | about 2 years ago | (#42924265)

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? (3, Insightful)

benjfowler (239527) | about 2 years ago | (#42924341)

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.

It used to be a problem (0)

Anonymous Coward | about 2 years ago | (#42924355)

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 (4, Informative)

markdavis (642305) | about 2 years ago | (#42924379)

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.

Most security IS security by obscurity. (1)

MasterOfGoingFaster (922862) | about 2 years ago | (#42924413)

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.

I have the answer (0)

Anonymous Coward | about 2 years ago | (#42924471)

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

Port knocking anyone? (2)

jurgen (14843) | about 2 years ago | (#42924481)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?