This document covers the 'general' security configuration and setup for Elliquiy. IPTables has its own section, and SELinux will have two or three as well after I am fully comfortable with it. Security considerations for specific programs - Postfix, NTP, MySQL, Apache, PHP and eventually Nginx go into their own sections.

It is important to remember that security is a process and a mode of thinking. It is not enough to assume that a server is secure just because you followed a checklist. Is your own system secure? What about political, legal, or financial issues? How much do you rely on DNS and in what ways? Even if this setup is considered 'hardened', it does little good if the applications can be compromised.

If you are using Windows, I highly recommend getting PuTTY and placing Pageant in your startup. I enter the passphrase for my keys once per bootup, and I'm good to go, no further worries about passwords save for when I su to root. : ) Likewise, for Linux or BSD you use ssh-agent. The power of ssh-agent and pageant is in simplifying better security - you only need a few keys (generally) to control a lot of machines, to say nothing of accounts. Your own system security is, of course, important, but that is outside the scope of this documentation.

Creating a public-private key pair is fairly simple. In Windows, just use puttygen to make a pair - save each. You don't specifically need a passphrase, but it makes it more secure and keeping the fingerwork simple is what pageant is for. In *nix, ssh-keygen -t rsa -b 4096.

RSA versus DSA

According to FIPS-186-2, DSA keys must be 1024 bits long, and security is dependent on the subgroup size, which by spec is 160 bits and provides 80 bits worth of security. This latter number is what the ssh protocol currently uses, regardless of generated bit size. The FIPS-186-3 draft specifies 2048/224 and 3072/256 keysizes, for 112 and 128 bits of security respectively, but for now at least, generating larger keysizes for use with ssh provides no additional security.

Since 1024 bit keys are not recommended beyond 2010 and I'm writing this in 2009, you should use RSA keys. A 4,096 bit key should last until quantum computing forces us to use something different entirely.

SSH

The first order of business when securing a machine is securing root and ssh.

I delete the administrative user my host added and create my own - adduser someadminname. I give it access to the adm, src, and staff groups and go to town. I add my public key to ~/.ssh/authorized_keys for the user (actually I have it in /etc/skel/.ssh/authorized_keys >_>).

Next I add wheel and nosu groups addgroup --gid 70 wheel, addgroup -gid 71 nosu, add my admin and root to the wheel group and everyone capable of logging in to nosu. I also edit /etc/pam.d/su to uncomment the auth required pam_wheel.so group=wheel and auth required pam_wheel.so deny group=nosu lines. This essentially forces only my 'secret' administrative user to be allowed to su to root, and only my admin and root can su at all. So, in theory at least, in order to remotely grab the root account on my server, a person needs 1: My rsa key, 2: My passphrase to that key, 3: The name of the admin account, and 4: The password to root. Rubber hose and black bag cryptanalysis are of course concerns, but are outside the scope of this document, though despite the seeming amusement I may actually address them to certain degrees in future posts if there is interest.

Make sure you can sign into your admin account with the key and su to root with it before modifying sshd_config.

In /etc/ssh/sshd_config:1) Set Port to a non-standard port to help free yourself of botnet troubles. They may be futile, but the logspam is exceedingly annoying. 2) Set ListenAddress to listen only to your primary (or otherwise chosen) IP address. If you have five ips it may not be to your benefit to accept traffic on the obvious one.3) Set PermitRootLogin to no4) Set PasswordAuthentication to no

/etc/ssh and everything within it can be safely hidden from the outside world - chmod -R o-rwx /etc/ssh/

If feeling paranoid, restart ssh after each step and make sure you can still sign in properly. Revert changes that don't work. We will then be done with ssh, at least specifically.

I am going to have four ports open here - 25, 80, 443, and my chosen sshd port. I might add pop3 later but I've grown to like the simplicity of alpine >_>. Note that hosts.deny/allow only actually apply to tcp connections for programs that use the tcpwrapper library. Apache is not one of these, but I leave it in there just in case I decide to dump Apache for something else that uses tcpwrappers later. If you are going to add pop3 for just yourself, you may wish to actually specify your current ip address in hosts.allow instead of letting anyone try to get your mail.

MySQL uses the wrappers by default. Naturally, if you are running a specific MySQL server, you will want to permit access appropriately.

Users

As I mentioned, I add my public key to /etc/skel/.ssh/authorized_keys - this makes handling things a lot simpler. Whether or not you want to actually do this will depend at least in part on how many other people are going to be accessing the server. For me, there are potentially two people I may let touch it - I can modify it for the accounts I give them access to as appropriate : )

I set umask 027 in /root/.bashrc and my admin's ~/.bashrc. It's also important to add umask 022 to /etc/skel/.bashrc - since we will be using a fastcgi setup and we want people to be able to read the files that our php scripts create (usually). chmod o-r home prevents people from easily spying other usernames.

It is important to set limits appropriately. My /etc/security/limits.conf looks like so, except sekret is not my admin name.

core files are prevented to keep them from littering all over the place, especially while we toy with things - they can provide details about the system that we do not want others to know. Playing with and optimizing php configurations can rapidly generate core files if this is not set. If something is breaking, we can manually arrange for core files to be created and inspect them that way.

If you are running mpm_prefork, you may want to permit apache ('www-data') to use more than 300 processes, depending on your configuration. memlock is for enabling large-pages support in mysql, likewise. It's important to give root and your admin account access as well (or at least add the appropriate ulimits in /root/.bashrc) because finding out days later that MySQL reverted to standard memory access because you restarted mysqld from root is annoying.

Fairly straightforward segregation. I have two target logs generated by iptables - one is a standard script, the other triggers when someone is very likely up to no good. I'll let you guess which is which >_> Note that since this is the kernel log, other messages will show up in these logs as well. Ideally there would be an option to force iptables to use its own facility.

Suhosin is set to the local0 facility by the master php.ini file. Local php.ini files are used to pick the exact level - Elliquiy gets one, Blue Moon, Ewrimo, and PrP. All others are crowded into .err.

Since we generate - and receive - a significant amount of e-mail traffic, mail gets split up explicitly.

syslog.conf does not need to be world-readable - it's safe to do chmod o-rx for it.

SetUID/SetGID

I run find / -perm -4000 to get a list of setuid binaries. Since this is a server I'm running remotely, I can be pretty liberal in terms of what doesn't get suid:

You may want to run find / -group root -perm -2000 to see if anything is setgid root besides directories. Directories a la /var/cache/man are fine, this just causes subdirectories to inherit the parent group.

If you are using nginx and skipping cronolog, you don't need apache or sudo and can thus eliminate them. pt_chown, su and passwd are required, however.

TTYs

gettys 1-6 each take up RAM. We don't like that - if someone has to work with our maching, they only need one to start and if they really need to, they can undo the following edit to add more.

In /etc/securetty I comment out everything but console and tty1-12. I leave 2-12 uncommented in the off chance that it becomes more convenient for whomever has to get hands-on to just uncomment the lines in inittab.

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)# Turn on Source Address Verification in all interfaces to prevent some spoofing attacks# This is on, since we are not a router.net.ipv4.conf.default.rp_filter=1net.ipv4.conf.all.rp_filter=1

# Ignore ICMP broadcasts. There are few legitimate uses for broadcast echos, so if you have such a reason you probably already know to disable this when you need to anyway.net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignore bogus ICMP errors. As a counterpoint to 'log everything', we want to log as little of it as possible. If that makes any sense.net.ipv4.icmp_ignore_bogus_error_responses = 1

# Do not accept ICMP redirects. As with icmp broadcasts, we don't want to allow this sort of craftiness unless we really do mean it.net.ipv4.conf.all.accept_redirects = 0net.ipv6.conf.all.accept_redirects = 0

# Maximum number of open files permited. I leave this commented out for now as I do not particularly need it.#fs.file-max = 262144

# Likewise I leave overcommit_memory at the default. If you do set it to 2, be sure that you have a decent-sized swap enabled, else allocation will fail as you run low on memory.#vm.overcommit_memory = 2#vm.overcommit_ratio = 50

# shmall is set to shmmax - shmall is in pages, which are 4kb for this system.# vm.nr_hugepages is set for MySQL's large-pages support, and needs at least as# much shared memory allocatable (hugepagesize * nr_hugepages) in order to work.kernel.shmmax=1073741824kernel.shmall=524288vm.nr_hugepages = 256

You can set nr_hugepages live, however, be sure to increase the number of hugepages slowly on an active system, as it takes time to free up contiguous multi-megabyte blocks of RAM.

Program Pruning

It's a good idea to get rid of junk you don't need, so to speak. I specifically focus on server processes here, but libraries and other potentially unsupported programs can also be risks if a way is found to load them.

1) DHCP - this is a server, not a home machine.2) Since this is a single machine, I remove nfs/portmap. Not everyone will want to do this of course.3) at gets removed because nothing uses it.4) apcid because this is a server. Power management? Seriously.5) Some VPS templates also install the bind daemon and/or nscd, neither of which I have a particular use for. I use EveryDNS for name resolution - at least for now - and trust my host's nameservers. They take up a pretty significant amount of resources and we don't have a lot to spare.6) /etc/inetd.conf has identd enabled by default - which freaked me out the first time I saw it, so I killed it with fire >_>

About SELinux

SELinux really deserves its own discussion piece, or better, a set of them. As a fundamentally different way of handling security, it is not necessarily a good idea just to dive in without understanding it. It's easy to talk about how it works, creating a superior, more comprehensive policy is something I'm still tackling for Elliquiy proper, so I don't want to specifically recommend it just yet.

Still, ignoring the actual handling of policies themselves, a few tweaks are needed, and they are not necessarily bad ones to implement even without SELinux:

1) /etc/default/rcS - set FSCKFIX=yes - this is probably a good idea in general for a remote host where you are using a fully journaled filesystem such as ext3. The Debian wiki also suggests EDITMOTD=no, though the man page says this is depreciated. It causes no harm to add, however.pb[2)[/b] If you have a bout of insanity and intend to enable strict mode without understanding SELinux a lot better than I currently do, the wiki also instructs to make /etc/motd a genuine file and remove /var/run/motd, as well as commenting the motd editing lines in /etc/init.d/bootmisc.sh.3) Remove the shadow and gshadow backups from /etc/cron.daily/standard, as cron will not have access to these files.

If you are using tmpfs partitions along with SELinux, you will want to add context="system_u:object_r:tmp_t:s0" to tmpfs mount options.

Again, I hope to revisit SELinux in the future after coming up with a superior and more general policy configuration rather than just recommending people to enable it. Obviously, just diving in with audit2allow is not a wise security policy.

That said, if you enable SELinux and suddenly see avc errors exploding, make sure SELinux did not decide to remove some policies for you before you go crazy with audit2allow. There are a lot of default policies for various packages in /usr/share/selinux/default/