Securing a server

#1

I am currently in the process of redeploying my home server after an SSD failure and I though it would be a good idea for you to do a video about how you secure your own or clients servers. Going through your process from say a clean load of Debian. What security software do you use, security settings do you change. This would be helpful for people starting out with a home server or client project. Even starting a discussion about what different people do because I am still unsure if my server is secure enough.

1 Like

#2

If reasonable to do so, use encrypted boot drive using LVM & LUKS and turn off passwords for SSH, use keys only. After that deny everything unless necessary for running the server. I might do a basic video soon as there are a few people asking and LUKS is awesome once you get to know it :slight_smile:

2 Likes

#3

Would you recommend OSSEC for a home single server and do you do any special file change detection or anything to detect/prevent comprimise. You would add anything for log monitoring/alerting. Something like Zabbix seems cool but I am using Docker and with only a single server and it is seems way overkill. I am just over thinking securing my server? I plan to have a few public Web servers but they will be routed through a proxy (I only have 1 dynamic ip) which will handle auth.

0 Likes

#4

Would you recommend 2FA for SSH, do you use it with your servers or clients servers?

0 Likes

#5

If you have critical data on the server look into the Yubikey for management access, use mandatory access control lists, static IPs, lock down directory and file access to specific users. In short treat your home / lab server the same as you would a client’s server it’s just good discipline.

0 Likes

#6

In most cases I’d consider 2FA overkill. As long as you’ve: disabled root login, disabled password auth (keys only), set AllowUsers option in OpenSSH config for only your SSH users… you’re probably good.

Add-ons: change the SSH port (just cuts down on so much auth.log spam from bots) and fail2ban installed with aggressive maxretry/bantime rules. Whitelisting IPs for SSH access at firewall would be another step, but I’ve locked myself out and required console access to fix that more than I think it has saved me from any hacks…

I’ve got dozens of VPS’s and dedicated servers out there with these basics configured properly and none have been brute forced since I really got into managing my own servers 7-8 years ago.

The 1 box that did get brute forced had: root login enabled, password authentication enabled, and a very weak root password set by the hosting company on first install. They delivered it at like 1am and I didn’t get around to the email and attempting to login until 11am. Some bot brute forced it and started using it to DoS folks in something like 6 hours of being online :joy:

1 Like

#7

Yup whitelisting can have pitfalls. Well maybe we can take some pleasure in knowing the “stresser” bot operators and their clients are starting to get some stiff prison time. What was the line from the song “paranoia runs deep.”

0 Likes

#8

Is there software that you use to monitor intrusions on your server, so you can detect comprimises or is that again just a bit overkill?

0 Likes

#9

Experimented with many systems but have settled on the plugins for pf-Sense Snort or Suricata (probably spelled wrong). Also use splunk to search through log files. The best open source package for parsing logs is the Security Onion. SO is a package of applications that work together to give deep insight. It takes a bit of work to configure but once done work great and the $ cost is right. No Starch Press published " The Practice pf Network Security Monitoring" by Richard Bejtlich a comprehensive guide to the Security Onion, I recommend getting a copy well worth it.

0 Likes

#10

There are tools such as https://wazuh.com/ (which is based on OSSEC) that offer security monitoring but they are far from being a turnkey / set & forget it software.

There is also https://cisofy.com/lynis/ which is free in many repositories and does a check to see if you missed some common settings for security.

0 Likes

#11

I’ll second Tom’s recommendation for lynis. Excellent software if using for a client go with the enterprise version. Had it on a desktop but was the community edition. Also look at OpenVAS it’s a fork of Nessus and is also one of the packages in Kali Linux.

1 Like

#12

@Mike How did you work out it had been comprised? also Thanks everyone for your helpful suggestions

0 Likes

#13

It started DoS’ing other servers and the hosting company suspended it for abuse :man_shrugging:

Took a few tickets back and forth but eventually got it re-provisioned and they picked a better initial root password than like ‘p@ssword123’

1 Like

#14

I will just leave this here, very basic and approchable recommendations: https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

0 Likes