Hey /g/entoomen.
I want to have a secure Linux server, so I was looking for tips to harden my system (from securing stacks, to firewalls rules, IDS settings and any other recommendation).
It's going to provide the following services: IRC, SSH and probably FTP and email, advice on securing them services is also welcome. (I'm also going to have a few users).
The server's probably going to run Arch/Gentoo/FreeBSD/OpenBSD, for I already have experience with them.
Change SSH port to non default. Set up something like fail2ban to auto ban IPs from brute force attempts on your services
>>51701330
Will do, thanks.
Use KDE and not GNOME
>>51701720
I'm not going to use any DE.
Setup a cron for security updates to your OS. Keep an eye out for any major exploits that hit the news. Use rkhunter to scan for rootkits.
>>51701769
>he doesn't use KDE
>>51701720
>>51701948
>de on a server
>>51701928
Thanks for the advice.
>>51701124
You could look into selinux too, there is a flag for it on gentoo.
For email setup some RBLs to keep out spam, spam assasin + clamAV, make sure ur not an open relay, use full email as usernames (or something complex), fail2ban on sasl auth cause bots go crazy trying to get in
>>51701720
>>51701769
>>51701948
Set up firewall rules to block all of china
>>51701124
>keyfile-only ssh
>sane firewall rules with something efficient and not a huge pain in the ass to maintain (pf is nice)
>follow the principle of least privilege with user/daemon accounts and permissions
>keep shit patched
>>51702089
AppArmour, Grsecurity, SELinux, SMACK a lot of options :(
>>51702119
Thanks!
don't watch porn
>>51702180
kek, even as a KDE user.
>>51701124
And advice on IDS or non secure (OS or daemon) default configurations?
>>51701124
use hardened gentoo, don't use arch. if not gentoo, then go with openbsd. most of the other posts in this thread are solid ideas too. check out OSSEC for HIDS
>>51702345
Thanks for the advice.
Also, opinion on Red Hat?
>>51702395
>Also, opinion on Red Hat?
fascists
>>51702395
I use centos alot, yum is great
>>51702180
So it is really great if you are into that sorta thing and horrible if you are not?
Sounds a bout right.
https://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps
>>51701330
>>51701695
Also, remember to disable root's ability to log in. Set an AllowUsers line in sshd_conf with only your account on it, and anyone else who has to log in. Consider disabling password login and using public-key authentication like >>51702211 mentioned.
>>51702395
CentOS is breddy good. I prefer Debian though
>>51702211
>keyfile-only ssh
This. If you feel a need to run fail2ban, you're doing it wrong.
>>51702969
Digital Ocean has distro-specific tutorials for that sort of thing too, as well a crapton of other useful stuff. It's easily as useful as the Arch Wiki.
>>51701124
Drop all connections except those you allow. Change ssh to disallow root login, change ssh port, disable ssh password auth and only use keys. Make your root password a sha512 hash of a favorite phrase, and make your password just as strong.
>>51701124
ssh + sshguard + iptables
Actual sysadmin here. I would recommend CentOS 6. (7 is a shit show due to immature systemd issues. 8 should be better.) Some packages might be older than you're looking for, but security fixes are backported to the official repos quickly (if needed at all). You'll also want the EPEL repo.
As for hardening advice, check out the Centre for Internet Security benchmarks. These are free documents (don't sign up for anything) that take you step-by-step through some basic hardening for a wide variety of OSes and web services. Yeah, some of them seem pretty dated, but the advice is generally solid even if it requires tweaking for modern versions (don't bother trying to harden Tomcat 8 with the Tomcat 6 benchmark, for example, it's just too different).
Cont'd shortly with specific advice.
>>51703292
Why would you prefer centOS over Debian?
>>51702529
What it actually means is that it's great if you're a faggot.
>>51703292
1) Ideally, you would be running the IRC, FTP, and mail (as in a relay or what?) on different servers. This seems to be a personal project, though, so best practices can be bent a bit.
2) I just reread your post and saw your OS list. You can probably ignore my suggestion, then. But if you do go Red Hat, learn how to build an RPM package. You probably won't need this immediately, but may save you some time and frustration in the long run.
3) Configure SSH to *only* allow public key authentication. If you don't know how this works, look it up *now*. Do not ever use password authentication except perhaps during initial setup. Also, disable root logins. Set up a user account with sudo access, instead (even if sudo access is passwordless, this is still an important step).
4) Changing the SSH port is stupid. Running services on non-standard ports is stupid. Don't do it. A better solution, if you're getting pounded by the Chinese or whatever, is to put SSH access behind a VPN. Expose OpenVPN to the internet, which is better equipped for this, then SSH over the secure virtual network. Of course, then you've got yet another thing to research, but OpenVPN itself is pretty easy. Just read the man page and use the directives that make sense as you go. Boom. There's your config. The PKI is the hard part, but if it's just you, there's plenty of guides out there to get you up and running with a self-signed cert or something similarly simple.
>>51703483
>Changing the SSH port is stupid
Do you have any reason other than my feelings?
Curbs the daily chinese attacks on my ssh when I moved it to a higher vacant port.
>>51703326
Yes. Debian and distros based on it are better suited for workstations. Debian's packages for network services tend to come a bit more "vanilla" than Red Hat's, but this is actually not a good thing, because you end up having to do a LOT of hardening just to get where CentOS is at after 'yum install'. This is coming from someone who used Debian on all his personal systems for six years prior to spending the last year as a Red Hat sysadmin. I had to overcome PTSD from RPM hell (back before yum was even a thing) when I got this job.
>>51703483
Cont'd.
5) Use SELinux. Yes, it is a pain in the ass. Yes, most guides will tell you to disable it. Don't. Take a few days to learn what it is and how it works. 90% of the time, you only have to enable it to get the benefits. Sometimes you'll need to search the audit log to see why something broke and then build a policy module to allow the denied action. It sounds and looks a LOT worse than it really is, it just comes down to a few files, concepts, and commands.
6) Install postfix. This, again, is a monster to get your head around. The documentation is massive and extremely dense. You don't need most of it, though. Just install the packages and edit the main.cf as needed so that you can send mail from your system. You will be listening only on a local port so that shit can alert you when shit breaks.
7) Install OSSEC. This is an intrusion detection system. You can either build your own packages or use the Atomicorp repository. If you followed the CIS benchmark, don't bother with AIDE, that's only useful for post-mortem shit.
8) By default, iptables will default to allow all traffic. *At the very least* change the INPUT and FORWARD policies to DROP and then add exceptions for the ports you want public.
>>51701124
If you dont require bleeding edge features, or paid tech support, or have hardware thats not compatible, I'd seriously consider looking into FreeBSD or OpenBSD. FreeBSD for the most part can do, or surpass anything on the server that Linux can do. OpenBSD isn't a good choice for a really complicated setup, but for basic servers it's rock solid, and more secure than anything else.
We should make one of those charts like the necessary software flowcharts but for server hardening
>>51703665
that would only cover the broadstrokes really, needs a wiki page.
>>51703550
These attacks are pretty simple though as they just bruteforce passwords for the admin user. If you only allow public key authentication, you are good to go. Well, you could change the ports to keep your logfile clean, if that bugs you.
>>51703550
Because mild obfuscation is not actually solving anything. It only means more work for you and anyone else who might help manage your system. You're focusing on the wrong problem.
Those quick port scans are harmless, unless you're vulnerable. If you are vulnerable, you're fucked. That's the real problem. Security is an onion. Instead of layers, you're rotating the onion slightly, hoping attackers won't tilt their heads to see the opening.
>>51701330
>ssh port to non default
kek are you retarded
disable root login and disable password login
>>51703706
To finish my thought, non-standard ports are frowned upon because they are a placebo. Placebos are not just useless; they actively undermine security.
>>51701124
Disable root SSH login
Disable outdated ciphers from OpenSSH
Disable passwords from SSH
Enable key authentication in OpenSSH
If you want to make life hard for yourself install a OTP PAM module for SSH
Install Fail2Ban
Don't bother changing the SSH port or with port knocking
Configure IPTables. Install ufw if you find it too complex. Only allow ports you use. Check ipv6 rules too!
Install security updates
If you think someone might physically steal the server you might want to use full disk encryption
Hard mode: Use SELinux/GRSec
>>51703810
>Disable outdated ciphers from OpenSSH
what's an optimal cipher config for openssh look like these days?
>>51703810
>If you think someone might physically steal the server
protip: keep your server in a nigger free area
>>51703835
I use chacha20 cipher & curve25519-sha256 exchange
>>51703292
>>51703483
>>51703604
Really useful, thanks! And yes, it's a personal project.
>>51703688
great idea, though i have not enough knowledge nor time on the subject to do it myself right now
>>51706109
would be great to have the red hat sysadmin guy give some selinux/grsecurity pointers for a hardened kernel, i think that's the most overwhelming thing for a lot of people. i'm sure if i did enough research i could cobble some things together but at the same time i'm not experienced enough to know what is truly good or not in certain regards
