Live data from Hacker News

What SSH Hacking Attempts Look Like

medium.com

121–130 of 186 posts

Re: What SSH Hacking Attempts Look Like

#121

Earlier quoted context omitted.

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 ;)

[deleted]

Re: What SSH Hacking Attempts Look Like

#122

Earlier quoted context omitted.

Fail2ban failing on ipv6 is strange given it doesn't do anything networky. It just analyses logs and updates iptable.

Calling "iptables" with a v6 address doesn't sound too clever actually.

Installing "iptables" also installs ip6tables.

https://linux.die.net/man/8/ip6tables

Re: What SSH Hacking Attempts Look Like

#123
My servers generally have an IPv4 address and a whole IPv6 subnet. I like to disable SSH except on a specific IPv6 address.

Many botnets just focus on IPv4 and there is a lot more territory to scan on IPv6. I usually couple that with moving to a non-standard port, enforcing modern encryption (ed25519 or ChaCha20, etcc), fail2ban, require SSH keys, etc

Re: What SSH Hacking Attempts Look Like

#124
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 d…

Objectively there should be no difference between a honeypot VM and an actual "productive" VM. I acknowledge that it is much harder to setup, maintain and supervise a network of honeypots VMs instead of a dedicated isolated honeypot server process which just simulates a system. However, as mentioned in other comments here, there is no gain of knowledge if you don't simulate a whole system but only parts of it.

Re: What SSH Hacking Attempts Look Like

#125
I think that by using obviously easy passwords anyone who really is looking for something is going to go to the next target. After all impossible to believe anything of value is behind 1234567 or changeme as a password. Even 'baseball' makes slightly more sense. Besides someone running an ssh server is not exactly mr computer newbie. Maybe a desktop you pick out of the trash might contain something interesting if that was the password.

In a classic CIA honeypot I would imagine the women are carefully matched to the target. If you are "James Bond" you get a better looking woman to try and trap you. If you are "Wallace Shawn" (in looks) you would probably figure out really quickly it's a trap if the woman looked like Angelina Jolie.

Re: What SSH Hacking Attempts Look Like

#126
post #102
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'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.

Re: What SSH Hacking Attempts Look Like

#127
post #55
post #3

$ grep -c sshd /etc/hosts.deny 1192 $ uptime 11:58:51 up 327 days, 21:33, 1 user, load average: 0.13, 0.11, 0.09 I'm using DenyHosts for this, there are alternatives but this works for me. http://denyhosts.sourceforge.net/

you should probably upgrade that kernel

If only there were some way to upgrade the kernel without rebooting. What a god-send that would be.

Re: What SSH Hacking Attempts Look Like

#128
post #103
post #93

Earlier quoted context omitted.

I am using high ports >30000 but you can chose what you want.

Really, this sounds like a bad practice to bind on non privileged port. A user can keep running a program to check if your non privileged port can be bound and if it could, it can start any behaving daemon that could be pretending to be a valid SSH daemon but could have anything like key loggers. Even a single restart of sshd could make it happen.

It doesn't have access to the host keys, so it can't do very much unless you intentionally bypass the "someone is intercepting your connection" error your ssh client will give you in that case.

Re: What SSH Hacking Attempts Look Like

#129
How configurable is fail2ban? Is it service based? Am I in danger of locking out a legitimate user like someone who makes 25 ajax requests within the span of 3 seconds? Can I make it work for authenticated HTTP endpoints as well?
Post reply on HN