News for hackers. Stuff that matters.
Re:How to Secure a Linux Server by ozim on Saturday February 16, 2019 @03:17PM (#19180702)
Securing ssh, 2FA for ssh, using key authentication...

Yes but first and foremost you don't expose ssh to all internet, it should be allowed only from known IP addresses and you should VPN to have connect to that known addresses. Section about firewall config just tells to open ssh...

Re:How to Secure a Linux Server by zlynx on Saturday February 16, 2019 @03:49PM (#19180856)
It might help protect against an OpenSSH zero-day but those are pretty rare.

I've been running my home server with an completely open SSH port since 2012 and haven't been hacked yet. And I know since I check occasionally with Tripwire and/or RPM verification from a clean boot.

The only downside to an open SSH port is the thousands and thousands of log spams from connection attempts. The upside is that I can log in from anywhere using my phone directly or as a hotspot for the laptop.

Oh yeah, and VPN just pushes the problem back one level. For me SSH is the VPN. Requiring VPN access first to get to SSH is just pushing any security problems back into the VPN server. Because now IT is the one with the open port to the internet.

Re:How to Secure a Linux Server by imthenachoman on Monday February 18, 2019 @03:40PM (#19194225)
Can you use Tripwire for free for home/consumer stuff? And what does RPM verification do? Just make sure all the packages you have installed are legit?
Re:How to Secure a Linux Server by zlynx on Tuesday February 19, 2019 @09:35AM (#19199151)
Tripwire is packaged up in Fedora. It's listed as GPLv2 licensed. So, yes.

RPM verification checks that all of the files installed through RPM have checksums that match the original RPM. It also checks that the RPM cryptographic signatures match.

So that should guarantee that files like the kernel, systemd, /bin/sh, /lib/libc.so.6, etc are not compromised.

A system can still be vulnerable to persistent attacks installed in unwatched files such as /root/.bash_profile, /etc/profile.d, extra files in /usr/systemd/system, etc. So you also have to check for extra files that you didn't install.

I don't have anything except Secure Boot to protect against UEFI attacks.

Re:How to Secure a Linux Server by imthenachoman on Wednesday February 20, 2019 @04:11PM (#19212021)
Got it. Thanks!
Re:How to Secure a Linux Server by ozim on Sunday February 17, 2019 @02:50AM (#19183219)
That is the thing, if we are talking about my personal linux server I am good with key auth + fail2ban and ssh on high port to have less spam in logs.

For work related stuff if I have to deal with multiple people accessing multiple servers then it is different story. Strictly forbidding ssh to have people connect from one IP is a lot more control. Then also key auth but I don't have to setup some google auth.

Re:How to Secure a Linux Server by imthenachoman on Monday February 18, 2019 @03:41PM (#19194237)
Agreed. The guide is intended for a home server. Anything more and you'd need a more robust network with dedicated firewalls and a DMZ, etc....
Re:How to Secure a Linux Server by Avamander on Saturday February 16, 2019 @06:37PM (#19181649)
If you use an UDP VPN on an non-standard port it's quite a bit harder to find than SSH on a TCP port.
Re:How to Secure a Linux Server by laumars on Saturday February 16, 2019 @07:21PM (#19181829)
if your primary goal just is to hide SSH then you could have it on a none-standard port and enable port-knocking. Then you’re reducing your visibility to network traces.

Ultimately though, many would argue that’s just security through obscurity so you’d still want something like fail2ban or denyhosts running - namely a tool that monitors your log files for failed log in attempts (or other suspicious activity) and then auto blacklist that IP in your filewall. I’d personally recommend fail2ban over denyhosts for a variety of reasons but ultimately either is better than none.

What I also like to do is have the public SSH box a bastion server with its own unique credentials so you effectively have the same multi-tiered authentication as you would for VPN.

You can also add MFA for SSH too if you wanted. In fact there are a few PAM modules you can use; from captchya’s (to reduce bot effectiveness) to Google Authenticator.

Even enhanced SSH tools like the file server protocol (SFTP / scp / etc) and port forwarding can be enabled or disabled for specific logins / groups or everybody if you wanted.

So it’s entirely possible to harden SSH in the same way you would VPN.

Re:How to Secure a Linux Server by imthenachoman on Monday February 18, 2019 @03:42PM (#19194251)
Thanks for the idea on port knocking. I always forget about it. Will look into it more...
Re:How to Secure a Linux Server by imthenachoman on Monday February 18, 2019 @03:39PM (#19194212)
I have a need to be able to SSH to my server from unknown sources, like my friends house or something. And VPN just moves changes the open port so no real benefit there. I agree on the firewall...
Re:How to Secure a Linux Server by symisc_devel on Saturday February 16, 2019 @03:35PM (#19180796)
Do you have any resources on how to allow ssh access from certain IP ranges? I can't find anything useful on this topic.
Re:How to Secure a Linux Server by imthenachoman on Monday February 18, 2019 @03:45PM (#19194268)
LAN IPs or WAN IPs?

If you're using public/private keys you can use the "from" option for the keys. But it's not fool proof.

Re:How to Secure a Linux Server by zegl on Saturday February 16, 2019 @03:52PM (#19180867)
iptables, ufw, Security Groups (if you’re on AWS). There is a lot of ways to it.
Re:How to Secure a Linux Server by laumars on Saturday February 16, 2019 @07:29PM (#19181860)
There isn’t lots of ways to do it; there’s just the one: firewall rules. There just happens to be lots of different types of filewalls.

If you want to get clever then you can enable port knocking but my personal preference is just good old fashioned whitelist of IPs with fail2ban running ready to auto-blacklist any of those IPs that have too many failed login attempts in a given period of time.