Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What SSH Hacking Attempts Look Like

medium.com

Post reply on HN
Print view View original

81–90 of 186 posts

Re: What SSH Hacking Attempts Look Like

#81

Post by orev »

gregmac wrote: post #80
gsich wrote: post #52

Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.

(I'm primarly a developer, not sysadmin) Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me. Same goes for other non-public services such as VPN. Wh…

I’m so tired of hearing people quote “security by obscurity” in relation to moving ssh ports. It is NOT security by obscurity (SBO). SBO is taking an insecure thing and trying to hide it, and relying on the hiddenness as the ONLY means of security. SSH is already highly secure, so hiding it has nothing to do with the security. You can debate whether it’s worth the inconvenience vs reducing log spam, but SBO does not come into it at all.

Re: What SSH Hacking Attempts Look Like

#82

Post by gumby »

gsich wrote: post #51
znpy wrote: post #50

Earlier quoted context omitted.

grep PasswordAuthentication /etc/SSH/sshd_config

Which is worse then using cat, from a user perspective. Imagine if you look for something else, you have to point the cursor in the middle, right after grep and before the file. With cat |grep you press Arrow-up and Alt+Backspace and you are right where you want to be, ready to search for something else. In scripts you can save the extra process though.

I just use ^...^... or !gre:... and make my edits that way -- it feels much faster and more intuitive than cursoring around, moving my hand over to the arrow keys etc.

The shells were developed on keyboards that didn't have arrow keys and have affordances for them.

Re: What SSH Hacking Attempts Look Like

#83

Post by orev »

Artemis2 wrote: post #16
arca_vorago wrote: post #6

My current take: nftables instead of iptables port-knocking non-standard port key+pass access/auth ip whitelist good logging ED25519 wherever possible!!!

I love the idea of Single-Packet Authorization with fwknop instead of port knocking: http://www.cipherdyne.org/fwknop/

I wish fwknop would be added to pfsense.

Re: What SSH Hacking Attempts Look Like

#84

Post by ryanlol »

larkeith wrote: post #37
vbezhenar wrote: post #4

I never understood why people would use fail2ban or similar approaches. Just set proper password and move on. SSH traffic is tiny, it's not a problem. You'll never be hacked with a proper password. Let them waste their time.

You aren't infallible. While it's easy enough to secure a minimal server with only SSH access, every time you add another service, provide access to a new user, or change a configuration, there's a chance you'll miss something or make a dumb mistake. Running Fail2Ban is a very cheap and easy method to ensure that, even if you do fuck up somewhere, there's another layer of security that should prevent malicious access…

Because fail2bans approach to log parsing is totally sane and confidence inspiring, right?

Re: What SSH Hacking Attempts Look Like

#85

Post by xur17 »

gregmac wrote: post #80
gsich wrote: post #52

Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.

(I'm primarly a developer, not sysadmin) Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me. Same goes for other non-public services such as VPN. Wh…

I typically just pick a high numbered port. > 10k would work.

I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down.

Basically it boils down to 'why not?' for me.

Re: What SSH Hacking Attempts Look Like

#87

Post by munin »

xur17 wrote: post #85
gregmac wrote: post #80

Earlier quoted context omitted.

(I'm primarly a developer, not sysadmin) Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me. Same goes for other non-public services such as VPN. Wh…

I typically just pick a high numbered port. > 10k would work. I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down. Basically it boils down to 'why not?' for me.

A high numbered port (above 1024) can be bound by non root programs. Use some non 22 port below 1024 if you want to change the port. Or use some RBAC system like selinux to keep anyone from binding to 2222 or whatever.

Re: What SSH Hacking Attempts Look Like

#88

Post by tempfs »

Some notes from an InfoSec person.

- Have a stand alone SSH server that is something like a R-Pi[type B] running an OS that gets patches regularly via unattended-upgrades and reboots itself at least once a week.[could also be a minimal VM like AlpineOS if you need Gbps+ line speed]

- Have this R-Pi and your network gear plugged into a UPS that can withstand at least a couple of hours of power outage.

- Use non-standard ports on your perimeter FW for forwarding to the R-Pi.

- Run fail2ban or something similar. Set a bantime of at least an hour[3600 sec] after no more than 5 attempts in 600 sec. This is mostly to discourage anyone who stumbles across your perimeter listening port.[which enough will] Password login will be disabled anyway, but a bot might not check for allowed auth types.[nmap -Pn -p 22 --script ssh-auth-methods ]

- No passwords allowed in /etc/ssh/sshd_config[PasswordAuthentication no]. Use public key based authentication.[PubkeyAuthentication yes] Put the public SSH key[id_rsa.pub] of any machine that you wish to authorize into ~/.ssh/authorized_keys on your R-Pi. This way you can authorize and de-authorize remote machines[with particular users] at will.

- add 'AllowUsers xxxx yyyy' to your /etc/ssh/sshd_config

- No root logins allowed![PermitRootLogin no]

- Maybe limit via perimeter or on the R-Pi which source IP ranges are allowed to access to SSH.[whitelisting]

- Periodically review your logs of perimeter FW, R-Pi FW and /var/log/auth.log to see what's going on. It should be pretty quiet, but look at them anyway once a week.

- Sleep well knowing that you have a simple, layered and robust defense strategy that also has power-event survivability.

Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds.

Don't use your perimeter device to host SSH services. It will not get patches fast enough when vulns come up.

Re: What SSH Hacking Attempts Look Like

#89

Post by meowface »

arca_vorago wrote: post #6

My current take: nftables instead of iptables port-knocking non-standard port key+pass access/auth ip whitelist good logging ED25519 wherever possible!!!

Nothing wrong with this, but a strong password for all Unix accounts (or, ideally, only allowing SSH with public key authentication) is essentially all you need. Unless you're using a dumb password, you're far more likely to be compromised by an application or OPSEC flaw (like someone getting into the email you used to register your server hosting account) than some crazy SSH compromise.

Re: What SSH Hacking Attempts Look Like

#90

Post by highesttide »

codetrotter wrote: post #72

> It absolutely shocked me that it is worth the time of these drive-by attacks to try combinations like root/password, root/root, or root/admin. Apparently they have enough successes using those incredibly insecure combinations that it is worth their time. It is fairly evident to anyone that has looked at the traffic that a honeypot gets that most of the activity is automated. Most of it is purely botnets, some of it…

I think they mean "time" for the botnet in this case
Post reply on HN