4 ms·

You can eliminate 99% of these attempted logins by changing your SSH port from the standard 22 to something else (say 2177 or whatever). Login as root (or su),

• drdaeman 16y ago
  This won't give you much security (most of entropy is in your password/keyfile), but will highly lower the convenience, because you'd have to use `-p 2177` or put the port number in `$HOME/.ssh/config`. Same goes to port-knocking. Just throw in denyhosts/fail2ban, and follow simple rules (no root login, no password/keyboard-interactive logins, possibly, except for special emergency "oh-shit-i've-lost-my-keyfile" account with secure passphrase and non-dictionary username), and you'll be perfectly safe.
  • eru 16y ago
    You are right about the entropy in one sense. So against a determined attacker the port does not matter. On the other hand, most drive-by attackers won't bother going for the other ports. Perhaps you can make some argument involving the probability/entropy/information of the attacks vs your defenses.
• ulf 16y ago
  Even better is to additionally setup a fake SSHd at port 22, so that port scanners do not even bother keeping on looking for the port and instead use what they suspect to be working
  • mfontani 16y ago
    I use https://code.google.com/p/kippo/ https://code.google.com/p/kippo/ as a ssh honeypot, and https://github.com/mfontani/kippo-stats https://github.com/mfontani/kippo-stats to display stats about it (number of attempts, successful logins, most usernames tried, most passwords tried for "root"). The data is quite interesting. Here's a snapshot of where most "attacks" to my honeypot originate from (the more, the brighter): http://darkpan.com/files/latlong255.png http://darkpan.com/files/latlong255.png
    • nodata 16y ago
      kippo's code is going to be less audited than openssh's. do you run kippo as root? is the risk of running kippo worth the stats?
      • gbrindisi 16y ago
        kippo can't be executed as root.
        • dmm 16y ago
          How does it open a server on a port <1024 without privileged access?
          • epochwolf 16y ago
            You use iptables to route port 22 on the external interface to a high port on localhost
          • rosser 16y ago
            It probably doesn't. # accept traffic to the normal ssh port iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT # accept traffic on the port kippo is listening on iptables -A INPUT -i eth0 -p tcp --dport 2222 -j ACCEPT # direct traffic inbound on port 22 to port 2222 iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 22 -j REDIRECT --to-port 2222 Make sure also to add an ACCEPT rule for traffic to whatever port sshd is actually bound to.
            • dmm 16y ago
              That's fine so long as you trust all of the users on your system. Otherwise they could potentially get something running on port 22. Which, so long as you aren't actually sending auth info to 22, probably isn't a big deal.
            • cft 16y ago
              http://www.faqs.org/docs/iptables/traversingoftables.html http://www.faqs.org/docs/iptables/traversingoftables.html Table nat is traversed <b>before</b> filter table. Therefore, the rule iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT is unnecessary.
  • dedward 16y ago
    As interesting and fun as honeypots are - unless it's your own gig, or the data from the honeypot fits into a larger security plan, it's just adding one more thing to manage. Move the port, run denyhosts, and in general just have access firewalled off to begin with.
• cd34 16y ago
  Good grief I hope you never do this. Do NOT use a port > 1023 for anything that should run as root. If you do, and your machine gets compromised, any unprivileged user could start an ssh daemon, you might think, oh, why is the key different, accept it, and they've keylogged your login attempt.
  • staunch 16y ago
    I don't disagree in principle. In practice: how did they manage to start their own daemon on a port sshd is already bound to?
    • cd34 16y ago
      Web exploit, get a web shell, crash your ssh daemon somehow, start my own. Since it is running on a non-privileged port, easy enough to run my own ssh daemon there. Crashing the ssh daemon isn't always easy, but, making the job easier for an attacker because 'obscurity' is considered a good protection scheme in this case opens up other potential vulnerabilities.
    • JoachimSchipper 16y ago
      Linux' OOM killer, just to give one possible example.
  • getsat 16y ago
    This is only an issue if you're using password authentication and do not drop traffic on ports on which you are not running services. Just use Single Packet Authorization, people.
    • dedward 16y ago
      It really depends on the scenario. Are you using one server? Do you manage a bunch of servers here and there for various clients? Are you responsible for corporate servers? All of them have different acceptable approaches to security. On my on personal servers? Single-packet or port knocking or whatever, it's fun to play around - that's how you learn. At the enterprise? The internet can't ssh to anything - you need VPN access, and not just any but the correct VPN access, and the right credentials on audited machines. There's nothing for outsiders to knock on (except maybe the VPN - but that has auto-lockout and password rotation tied into the enterprise auth system) If someone wanted to do port knocking or similar for enterprise stuff I think that'd be a staunch "Umm, no"
• deleted 16y ago
  [deleted]
• notaddicted 16y ago
  Make sure to open the relevant port on your firewall before you do this!!