Live data from Hacker News

Ask HN: Anonymous person sent proof of SSH access to our production server

news.ycombinator.com

221–230 of 246 posts

Re: Ask HN: Anonymous person sent proof of SSH access to our production server

#223
post #174
post #73

Earlier quoted context omitted.

Ask for a BTC address and send a tip.

If you're sending an even slightly significant amount of money, there are potential tax implications too. You might need to do a 1099.

Haha! I don't know how you intended your comment, but I just had a funny thought of filling out a 1099 for blackmail.

Re: Ask HN: Anonymous person sent proof of SSH access to our production server

#224
post #156
post #83

Earlier quoted context omitted.

I'd be very cautious before moving SSH to a non-privileged port (over 1024). Any user on the server might start their own SSH server on the port assuming the real SSH server is dead. While this is hard to exploit (needs access to normal user, needs to kill real SSH server, need to get around SSH server key checking), it still is at least a theoretical reduction in security.

A user can always start their own SSH server. Just because you've decided to move it to a different port doesn't really encourage them. I suppose you could make this a bit more difficult for them by removing compilers (no really, you don't need compilers everywhere) and making sshd owned by root, mode 700... However, proper ingress filtering or local iptables/pf rules would stop any unwanted inbound traffic from reac…

removing firewalls has effectively no benefit; a non-root user can trivially download and run an arbitrary distro or package manager (e.g. nix from nixos, portage from a gentoo prefix, etc) and effectively do a chroot + package management without root.

Re: Ask HN: Anonymous person sent proof of SSH access to our production server

#225
post #78
post #55

Earlier quoted context omitted.

Hire someone because they exploited a single vulnerability?

Maybe offering a reward is a good way to reduce the anonymity of the person, since rewards can be tracked. Speaking only for myself.. If I were to go the trouble to anonymously tip somebody off about a security vulnerability, it would be because I cared that they were secure and that I did not wish to be identified. I would neither expect nor accept a reward.

Yes but a white hat like you would probably give at least some hints on how to fix it or what vulnerability you have discovered, not just a screenshot showing that you have/had access.

I think just the fact that they didn't do this points to malevolence. I would expect the ransom demands to follow shortly.

Re: Ask HN: Anonymous person sent proof of SSH access to our production server

#228
post #184

Earlier quoted context omitted.

100% agree. Disclaimer I own a data center and have dealt with customer collocated equipment breaches. In addition to the above steps: -> disable root being able to login inside your sshd_config file. Make sure PermitRootLogin no -> rename the root account too so if they are using an exploit based on user authentication then perhaps they won't be able to elevate to root. -> disable password based logins and go to cer…

just a note: intelligent exploiters hide their files inside of yours, so the -mtime is useless in many cases, they will set the mtime of their upload to match the rest of the folder they hide in. command history is also easy to alter if you know what you are doing.

yes, excellent point, agree. I run the scan regardless in case I'm dealing with the non-intelligent exploiter type ;)

Re: Ask HN: Anonymous person sent proof of SSH access to our production server

#229
post #191

Earlier quoted context omitted.

+1 for link to lynis. I had never heard of that before!

You are replying to the author of lynis, might as well thank him for writing it :)

You are welcome (even without thanking) :)

Re: Ask HN: Anonymous person sent proof of SSH access to our production server

#230
post #156
post #83

Earlier quoted context omitted.

I'd be very cautious before moving SSH to a non-privileged port (over 1024). Any user on the server might start their own SSH server on the port assuming the real SSH server is dead. While this is hard to exploit (needs access to normal user, needs to kill real SSH server, need to get around SSH server key checking), it still is at least a theoretical reduction in security.

A user can always start their own SSH server. Just because you've decided to move it to a different port doesn't really encourage them. I suppose you could make this a bit more difficult for them by removing compilers (no really, you don't need compilers everywhere) and making sshd owned by root, mode 700... However, proper ingress filtering or local iptables/pf rules would stop any unwanted inbound traffic from reac…

The point was that you could more easily replace the SSH server with a malicious one and e.g. hijack your agent when you connect to it.
Post reply on HN