Forgot your password?
typodupeerror
Security IT BSD

SSH Password Gropers Are Now Trying High Ports 349

Posted by timothy
from the for-higher-love dept.
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?
This discussion has been archived. No new comments can be posted.

SSH Password Gropers Are Now Trying High Ports

Comments Filter:
  • Low Hanging Fruit (Score:5, Informative)

    by Nerdfest (867930) on Saturday February 16, 2013 @05:43PM (#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 (Score:5, Interesting)

      by bcmm (768152) on Saturday February 16, 2013 @05:56PM (#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 (Score:5, Informative)

      by DaveAtFraud (460127) on Saturday February 16, 2013 @06:00PM (#42923981) Homepage Journal

      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

      • by lophophore (4087)

        I like that. Thanks for sharing!

      • by houghi (78078)

        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.

      • by KiloByte (825081)

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

        I'd instead use REJECT.

      • by jgrahn (181062)

        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.

      • 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.
    • Better than port knocking is single packet authorization.

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

      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.

  • by Ultra64 (318705) on Saturday February 16, 2013 @05:47PM (#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 (Score:5, Interesting)

      by SuricouRaven (1897204) on Saturday February 16, 2013 @05:50PM (#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.

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

  • by Gaygirlie (1657131) <gaygirlie&hotmail,com> on Saturday February 16, 2013 @05:48PM (#42923897) Homepage

    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.

  • by Anonymous Coward on Saturday February 16, 2013 @05:48PM (#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...

    • by Anonymous Coward on Saturday February 16, 2013 @08:20PM (#42924809)

      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.

      • by Zaiff Urgulbunger (591514) on Saturday February 16, 2013 @09:16PM (#42925155)

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

    • by v1 (525388)

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

  • by Anonymous Coward on Saturday February 16, 2013 @05:49PM (#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.

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

  • Dumbass parroting. (Score:5, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @05:54PM (#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.

    • by astralagos (740055) on Saturday February 16, 2013 @07:41PM (#42924567)
      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).

    • Typical geek shit (Score:5, Insightful)

      by Sycraft-fu (314770) on Saturday February 16, 2013 @07:58PM (#42924679)

      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.

  • Very few (Score:5, Interesting)

    by PktLoss (647983) on Saturday February 16, 2013 @05:56PM (#42923963) Homepage Journal

    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.

    • 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!
  • VPN (Score:4, Interesting)

    by sgt scrub (869860) <saintium@ y a hoo.com> on Saturday February 16, 2013 @06:01PM (#42923993)

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

    • by nzac (1822298)

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

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

    • by _Ludwig (86077)

      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.

      • by DamonHD (794830)

        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

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

  • If you can connect and directly log in to root, I think you are an idiot. Regardless of the password.
    • 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?
      • by Culture20 (968837)
        That depends on what commands the sudoers are allowed to run (sometimes it's pretty restrictive).
        • by tepples (727027)
          Unless you have someone with physical access to the datacenter, at least some sudoers are going to need high-level privileges.
      • by AmiMoJo (196126) *

        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.

      • by lindi (634828)

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

      • by swillden (191260)

        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.

  • 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

  • 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?

    • by jgrahn (181062)

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

    by water-and-sewer (612923) on Saturday February 16, 2013 @06:44PM (#42924261) Homepage

    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.

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

  • Tarpit? (Score:4, Insightful)

    by benjfowler (239527) on Saturday February 16, 2013 @07:02PM (#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.

  • iptables (Score:5, Informative)

    by markdavis (642305) on Saturday February 16, 2013 @07:09PM (#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.

    • by Gothmolly (148874)

      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.

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

  • by jurgen (14843) on Saturday February 16, 2013 @07:29PM (#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.

  • by Beeftopia (1846720) on Saturday February 16, 2013 @10:30PM (#42925449)

    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 [centos.org]. This one creates a pretty solid simple iptables ruleset to protect a server.

    2) An Ubuntu tutorial, again simple and informative. [ubuntu.com]

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

    4) Deeper information, but very useful. [frozentux.net] 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.

  • by Jeremi (14640) on Sunday February 17, 2013 @01:47AM (#42926059) Homepage

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

Nothing succeeds like success. -- Alexandre Dumas

Working...