Live data from Hacker News

What SSH Hacking Attempts Look Like

medium.com

71–80 of 186 posts

Re: What SSH Hacking Attempts Look Like

#71
post #40

# cat /etc/ssh/sshd_config | grep PasswordAuthentication PasswordAuthentication no ^ it should return that. The end.

Is it worth mentioning useless uses of cat in this day and age?

I'm pretty fanatical about efficiency, but it's kind of annoying to have to remember where in the argument sequence for a whole bunch of commands the input file goes.

Of course once you use the 'cat' trick you then have to remember which comments require '-', '-f -' or something to that effect because whoever programmed them didn't think the primary use case was to work as a filter.

Pipes are one of Unix's most useful features and cat somefile | asequenceofusefulcommands is a shorthand that anybody should be able to use.

Re: What SSH Hacking Attempts Look Like

#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 is automated password guessing followed by manual login. I think the amount of people manually trying passwords is insignificantly small.

Re: What SSH Hacking Attempts Look Like

#73

Someday I'm going to put all the different pieces together and have things like SMTP & SSH auth failures, hosts hitting my spamtraps, bots scanning for open 23/TCP, and so on, to where I end up with one central host collecting all those events and injecting /32 routes for those IPs towards null0 in my core.

A friend of mine built this complete with a whole pile of honeypots and lots of companies use it.

https://www.blockedservers.com/

Super useful.

Re: What SSH Hacking Attempts Look Like

#74

Earlier quoted context omitted.

Please educate me

</etc/ssh/sshd_config grep PasswordAuthentication

I've been taught wrong and I've done it wrong for 15 years O_o

Thank you.

It reminds me of the idiom of putting "# -- coding: utf-8 --" at the top of Python 2.x files. Which is incredibly useful, but nobody remembers, and googles everytime.

This comes from the fact the first famous tutorials on Python where written by emacs users, and this editor recognizes this idiom.

But fun fact, the regex matching this line is "^[ \t\v]#.?coding[:=][ \t]*([-_.a-zA-Z0-9]+)" (see https://www.python.org/dev/peps/pep-0263/) and accepts many variations (including a vim format).

The simplest variation is the dumb "# coding: utf8", which is not only straightforward and easy to remember, but way less magical for anybody reading the code.

Bottom line, if you are stuck in 2.x, use "# coding: utf8".

Re: What SSH Hacking Attempts Look Like

#76
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 do that. Security professionals will whine "security by obscurity is not security" but the fact is it cuts down these attempts by a huge factor.

Re: What SSH Hacking Attempts Look Like

#77
post #27

Earlier quoted context omitted.

They simply try password auth, and fail with a message that password auth is off. Constantly. All the time.

Set up a non standard port. This will stop over night.

It has stopped now (I simply removed port 22 from the whitelist except for connections originating with my home ISP, which is a local ISP where abuse reports actually work)

Re: What SSH Hacking Attempts Look Like

#78
One thing I've found amusing is you can cut down SSH hacking attempts to almost zero (at the cost of compatibility with legacy systems) by using very progressive encryption. If you force use of ChaCha20/Poly1305, ED25519 and so forth in sshd_config, you'll see these attempts almost disappear. There's probably an observation to be made about just how overwhelmingly many of these attempts come from fairly old software setups.

Re: What SSH Hacking Attempts Look Like

#79
post #38

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

why nftables rather than iptables?

Im also curious about this, they use the same netfilter backend

Re: What SSH Hacking Attempts Look Like

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

What ports should be used? I think clearly you don't want to use other well known services (eg, running ssh on port 25 is just going to fill your logs with failed connection errors). Should you use ports >1024? >10000?

Post reply on HN