Okay, so I'm about to start over on my Linux server, but this time I want to go down the hardened route to increase its security. It is currently running Apache, Samba, MySQL and OpenSSH. So, since it is accessible to the world, thought it might be a good idea to beef it up even though there is nothing on there that is could potentially ruin me. It's just a family Web site with Christmas wishlists.

I'll be using Gentoo because it is what I'm comfortable using, and they have a Gentoo Hardened branch. The bit I'm stuck on is which MAC system I should use. I've found performance comparisons, but nothing that really states "as a newcomer use this one, for the old hand use this one" or "this one is absolutely the best". It doesn't seem like there is a clear winner.

I'd like some direction if any of you have some experience, no matter how little.

The best things in life are free.http://www.gentoo.orgGuy 1: Surely, you will fold with me.Guy 2: Alright, but don't call me Shirley.

I have almost no experience with MAC, but do have a little experience with securing public servers.

SElinix is probably the most widely deployed MAC framework for Linux, with AppArmor a close second. If you really want to enable some sort of MAC, I'd probably go with whichever one of those two is better supported on your distro.

That said, MAC is probably overkill in your case. My approach to securing a server like yours would be to do the following:

- Configure your firewall to allow incoming connections only on ports associated with services you want to be visible from the Internet. This includes firewalling the MySQL port (I am assuming that MySQL is only being accessed by other services running on the same host). Don't allow Samba access from the Internet either.

- Disable remote SSH access for the root account, and any user accounts which do not need the ability to log in remotely. Remote CLI admin tasks can still be performed by establishing a SSH session as a non-root user, then using su or sudo to run administrative commands.

- Make sure all accounts with remote SSH login capability have strong passwords. Alternatively, you could allow logins only via RSA key pairs, and protect the private key at the remote end with a strong passphrase. (Which approach you use depends on how much you trust your users to always use a strong passphrase to protect their private keys. The Fedora Project security breach last fall resulted from a Fedora employee who had an unprotected private key file.)

- Do not expose any remote desktop services (VNC, XDMCP, etc.) directly to the Internet, even if they are password protected. If remote desktop access is desired, firewall the port associated with the service and establish a SSH port forward to access the remote desktop service when needed.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

Some may actually consider that to be a disadvantage; but given that it is Open Source, the potential for NSA-mandated back doors is essentially nil.

Yeah, I knew they developed it too when I read about it way back when.

I also figured if there was a backdoor we'd know about it...then again, this is the NSA with connections to the CIA, DHS, FBI, SS, MiB....

Edit: And apparently there's something going around that has infiltrated several government agencies. The US is not on that list. I'm guessing SELinux may have something to do with that. Maybe. Possibly.

The best things in life are free.http://www.gentoo.orgGuy 1: Surely, you will fold with me.Guy 2: Alright, but don't call me Shirley.

Thanks for the tips, nightmorph. I'll read the OpenSSH articles in a moment.

I have my father and a friend who will be connecting to the server as well. The way I had the system set up, they were not in the wheel group, and root was only allowed without a password and from a specific machine on the network. (That introduced some real headaches when I got my Verizon service and hardware installed as nothing on the ISP provided hardware worked as anticipated.)

My father and my friend knew how to use the keys I gave them, and I told them to keep it in a safe place. My friend is a bit more tech savvy than my father, so my friend could probably handle the port knocking easily enough but not my father. So, taking that into consideration, I might just opt for running SSH on a non-standard port, which I know will only deter some automated attacks and will do nothing to prevent a more determined attacker from trying to gain access.

The best things in life are free.http://www.gentoo.orgGuy 1: Surely, you will fold with me.Guy 2: Alright, but don't call me Shirley.

- I run it outside the firewall that protects the rest of my LAN. That way, in the event that it ever does get compromised, it can't be used as a stepping stone to compromise the rest of my systems. (The downside of this is that you need two public IP addresses.)

- Just recently, I redid things such that the public-facing server is actually a VirtualBox VM, not the real server. This makes backing up the whole system (and disaster recovery, should it ever be needed) easier. It also allows me to clone the VM to try out new server configs without affecting the "live" copy of the server; the new config can easily be cut over when ready (cutting over is just a matter of changing which VM ports 22 and 80 get forwarded to).

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

just brew it! wrote:- Disable remote SSH access for the root account, and any user accounts which do not need the ability to log in remotely. Remote CLI admin tasks can still be performed by establishing a SSH session as a non-root user, then using su or sudo to run administrative commands.

radix wrote:Because the attacker will have to break two passwords instead of one: the users' and then root.

It also means the attacker doesn't know the name of the account that has SSH access ahead of time. The problem with the root account is that it always has the same name, so the attacker doesn't have to guess the account name and crack the password; they only have to crack the password.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

just brew it! wrote:It also means the attacker doesn't know the name of the account that has SSH access ahead of time. The problem with the root account is that it always has the same name, so the attacker doesn't have to guess the account name and crack the password; they only have to crack the password.

You can rename the root account, not so? It just has to stay as account#1 #0.

just brew it! wrote:It also means the attacker doesn't know the name of the account that has SSH access ahead of time. The problem with the root account is that it always has the same name, so the attacker doesn't have to guess the account name and crack the password; they only have to crack the password.

You can rename the root account, not so? It just has to stay as account#1 #0.

No, the root account cannot be renamed. It's root. The root of all that is root.

The best things in life are free.http://www.gentoo.orgGuy 1: Surely, you will fold with me.Guy 2: Alright, but don't call me Shirley.

1. For OpenSSH, in /etc/ssh/sshd_config, use the AllowUsers variable to limit who can login. This is good if you have a bunch of accounts but don't want everyone to have shell access.2. Bind MySQL's listening address to 127.0.0.13. Only allow access to Samba via your LAN if possible.

1. For OpenSSH, in /etc/ssh/sshd_config, use the AllowUsers variable to limit who can login. This is good if you have a bunch of accounts but don't want everyone to have shell access.2. Bind MySQL's listening address to 127.0.0.13. Only allow access to Samba via your LAN if possible.

That's not new to me. I've been doing that for a couple years now. Except for SSH, which I've actually only been using for the last year or so.

The best things in life are free.http://www.gentoo.orgGuy 1: Surely, you will fold with me.Guy 2: Alright, but don't call me Shirley.