Earlier quoted context omitted.
What can you tell from the line?
Hasn't rebooted in a year
That used to be a selling point of Linux versus Windows.
Times have changed...
What SSH Hacking Attempts Look Like
131–140 of 186 posts
Re: What SSH Hacking Attempts Look Like
#132One 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…
Good info! Got any good resources on configuring sshd algos?
Re: What SSH Hacking Attempts Look Like
#133One 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…
Good info! Got any good resources on configuring sshd algos?
I highly recommend Mozilla's OpenSSH configuration guideline[1].
Re: What SSH Hacking Attempts Look Like
#134One 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…
Good info! Got any good resources on configuring sshd algos?
Nirv's recommendation below is spot on, but here's a ready-made version as well: https://github.com/ejrv/linuxconfigs/blob/master/etc/ssh/ssh...
It's basically a clone of Mozilla's, except enforcing only the very strictest encryption. You can just lift the first 16 lines out of that and merge them into your sshd_config if you don't want to change your existing sshd_config too much.
Re: What SSH Hacking Attempts Look Like
#135Earlier quoted context omitted.
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.
Seeing that you need to press enter, the arrow keys are not far away. I doubt the later one.
You doubt that they keyboards lacked arrow keys? Just look at an ASR-33 (teletype) keyboard or ADM3A. The latter had arrows printed on the hjkl keys but there was no special way to generate “arrow” key presses — those terminals sent 7-bit ASCII characters directly. Look at what # and @ do in cooked mode — THAT goes back to Multics.
The teletype was a printing terminal and the ADM3A was a “glass teletype” — essentially a printing terminal too.
It’s possinle to write a lot of good code this way
Re: What SSH Hacking Attempts Look Like
#136Long ago I made the same thing.
Re: What SSH Hacking Attempts Look Like
#137Earlier quoted context omitted.
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.
Seeing that you need to press enter, the arrow keys are not far away. I doubt the later one.
I’ll add that bash was the first Unix shell to have interactive editing with history, which comes from me suggesting the design of the readline library to Brian Fox around 1985. I was inspired by the editing JSYS (system calls) in TOPS-20 (VMS had something similar I believe) though they lacked the history mechanism.
Re: What SSH Hacking Attempts Look Like
#138Some 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-standa…
> Use non-standard ports
While I completely agree and encourage people to use all of your suggestions, this single step - not being on port 22 - has easily provided the most benefit. When sshd listened on port 22, I regularly saw attacks that would run through thousands of common passwords at high speed[1]. After moving to a random port, it was over a year before I saw another hostile login attempt.
It may be easy to discover the server with a simple port scan, but in practice the attacks seem to focus on the easy targets.
> fail2ban
Fail2ban is great and highly configurable. I could accept having to manually reset occasional false positives, so my fail2ban will immediately (no retries) ban on the first use of anything that is known to be malicious such as any attempt to login as root with a password, asking to login with an account name like [admin, mysql, squid], or any apache access log matching /\/phpMyAdmin/, etc.
[1] Several logins per second over ADSL could use a large fraction of the upload bandwidth.
Re: What SSH Hacking Attempts Look Like
#139Earlier quoted context omitted.
> I'm not really sure what's bad about it You say it yourself: > also a (very minor) inconvenience to real users I would disagree with the “very minor” part. To paraphrase myself ( https://news.ycombinator.com/item?id=6617312 ): As I understand the argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security . The problem is that: 1. It adds very little s…
You're looking at this the wrong way, because you seem to assume that non-standard ports adds to security the same way the key length does, which is not the case.
I can’t think of any way it could be otherwise, but please, feel free to enlighten us all how a non-standard port number adds any more security than would an additional 16-bit key.
Re: What SSH Hacking Attempts Look Like
#140Changing 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.
Years ago (actually probably more than 10 years ago now) I actually switched from port 22 to 622 on my server because I wanted to get rid of the noise of people attempting to bruteforce my SSH regularly. It worked perfectly for years but surprisingly I've had a handful of bruteforce attempts on port 622 in the past year or so. Nothing particularly targeted either, always the same typical default users (root, admin, o…
622 might be too low. Scanning first 1024 ports is easier.