What SSH Hacking Attempts Look Like • Hacker News Board

Re: What SSH Hacking Attempts Look Like

#91

Post by wgjordan » Sat, May 05, 2018, 4:26 PM UTC

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…

> it's kind of a security-by-obscurity measure

This comes up as a point of confusion often, so allow me to clarify:

A non-standard port as the only security mechanism (e.g., an unauthenticated HTTP admin-interface) would indeed be 'security through obscurity', but a non-standard port as an extra mitigation layer on top of existing security mechanisms (e.g., SSH authentication) is 'defense in depth'.

Re: What SSH Hacking Attempts Look Like

#92

Post by ktpsns » Sat, May 05, 2018, 4:42 PM UTC

I wonder why the author set up a dedicated SSH python server which mimics some unix userspace as a honeypot. Why not a VM with a real standard widespread linux distribution to see what attackers actually do? Obviously their codes are not very sophisticated that they stop when "uname" fails with certain arguments.

Re: What SSH Hacking Attempts Look Like

#93

Post by gsich » Sat, May 05, 2018, 4:49 PM UTC

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 am using high ports >30000 but you can chose what you want.

Re: What SSH Hacking Attempts Look Like

#94

Post by gsich » Sat, May 05, 2018, 4:55 PM UTC

gumby wrote: post #82

gsich wrote: post #51

Earlier quoted context omitted.

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.

Seeing that you need to press enter, the arrow keys are not far away.

I doubt the later one.

Re: What SSH Hacking Attempts Look Like

#95

Post by gsich » Sat, May 05, 2018, 5:06 PM UTC

munin wrote: post #87

xur17 wrote: post #85

Earlier quoted context omitted.

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.

What is the problem?

Re: What SSH Hacking Attempts Look Like

#96

Post by iforgotpassword » Sat, May 05, 2018, 5:10 PM UTC

ktpsns wrote: post #92

I wonder why the author set up a dedicated SSH python server which mimics some unix userspace as a honeypot. Why not a VM with a real standard widespread linux distribution to see what attackers actually do? Obviously their codes are not very sophisticated that they stop when "uname" fails with certain arguments.

Because it's much easier to set up? It's not breaking after any session no matter what the attacker does. Every session is isolated if several run concurrently. Getting this with a VM involves quite some effort. Then you need to make sure the attacker cannot use any commands to cause external damage but still make them seem to work. But the latter is also a problem with the simulated environment. It's quite easy to detect if you're not just blindly sending automated keystrokes without checking the feedback.

Re: What SSH Hacking Attempts Look Like

#97

Post by simias » Sat, May 05, 2018, 5:10 PM UTC

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.

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, oracle, mysql etc...). I wonder who bothers doing that.

Since I disabled password logging on all accounts and my key is stored on an HSM I'm not too worried about it though.

Re: What SSH Hacking Attempts Look Like

#98

Post by f311a » Sat, May 05, 2018, 5:13 PM UTC

ktpsns wrote: post #92

I wonder why the author set up a dedicated SSH python server which mimics some unix userspace as a honeypot. Why not a VM with a real standard widespread linux distribution to see what attackers actually do? Obviously their codes are not very sophisticated that they stop when "uname" fails with certain arguments.

They stop because they know that it's a honeypot. I guess it's a simple check for popular honeypots which emulate linux commands.

Re: What SSH Hacking Attempts Look Like

#99

Post by iforgotpassword » Sat, May 05, 2018, 5:16 PM UTC

jacquesm wrote: post #71

jgtrosh wrote: post #40

Earlier quoted context omitted.

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 usefu…

As a compromise you could just do "< infile grep word | awk '{...}' | sort" so you still have the input file first but got rid of cat ;)

Re: What SSH Hacking Attempts Look Like

#100

Post by nitrogen » Sat, May 05, 2018, 5:19 PM UTC

gsich wrote: post #95

munin wrote: post #87

Earlier quoted context omitted.

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.

What is the problem?

Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.