What steps do you take to secure a Debian server? [closed]

I am installing a Debian server which is connected directly to the Internet. Obviously I want to make it as secure as possible. I would like you guys/gals to add your ideas to secure it and what programs you use for it.

I want part of this question to cover what do you use as a firewall? Just iptables manually configured or do you use some kind of software to aid you? What's the best way? Block everything and allow only what is needed? Are there maybe good tutorials for beginners to this topic?

Do you change your SSH port? Do you use software like Fail2Ban to prevent bruteforce attacks?

Solution 1:

Obligatory:

• installation of system with expert mode, only packages that I need
• hand written firewall with default policy on iptables'input: drop, permitting access to SSH, HTTP or whatever else given server is running
• Fail2Ban for SSH [ and sometimes FTP / HTTP / other - depending on context ]
• disable root logins, force using normal user and sudo
• custom kernel [ just old habit ]
• scheduled system upgrade

Depending on level of paranoia additionally:

• drop policy on output except a couple of allowed destinations / ports
• integrit for checking if some parts of file system ware not modified [with checksum kept outside of the machine], for example Tripwire
• scheduled scan at least with nmap of system from the outside
• automated log checking for unknown patterns [but that's mostly to detect hardware malfunction or some minor crashes]
• scheduled run of chkrootkit
• immutable attribute for /etc/passwd so adding new users is slightly more difficult
• /tmp mounted with noexec
• port knocker or other non-standard way of opening SSH ports [e.g. visiting 'secret' web page on web server allows incoming SSH connection for a limited period of time from an IP address that viewed the page. If you get connected, -m state --satete ESTABLISHED takes care of allowing packet flow as long as you use a single SSH session]

Things I do not do myself but make sense:

• grsecurity for kernel
• remote syslog so logs cannot be overwritten when system gets compromised
• alerting about any SSH logins
• configure rkhunter and set it up to run from time to time

Solution 2:

Just a note on firewalling your machine...

• Use a whitelist, not a blacklist - i.e. block everything, and only allow what you need to, deny everything else.
• Don't use GUIs/ncurses or otherwise any software that tries to make the task of writing your firewall for you. If you do, you will be allowing the software to make assumptions for you - you don't need to take that risk and shouldn't. Configure it yourself, if you're unsure, disable it - you'll find out soon enough if it is required. If it is already an up and running system and you can't disrupt traffic (by accidentally blocking it), then run tcpdump (dump to file) and take samples - study them later, and then figure out what's valid and what's not.
• I personally don't see any point in running a service on a non-standard port, tools are not so dumb these days to assume that because something is running on port 22 for example, then it must be ssh, and not otherwise - for example amap, and nmap's -A option. Having said that, you can (and probably should if worried) modify your services to hide themselves from prying eyes, for example, the following would let the attacker know the exact version of OpenSSH that you're running, they can then look for exploits for that exact version. If you hide such things, you'd be making it harder for them.

    [root@ud-olis-1 uhtbin]# telnet localhost 22
    Trying 127.0.0.1...
    Connected to localhost.localdomain (127.0.0.1).
    Escape character is '^]'.
    SSH-2.0-OpenSSH_3.9p1

• Keep all your public services up to date and patched with the latest security patches.
• Don't store any DATA on the gateway server itself, at least you'll buy time when they manage to break in to this machine, and you'll lose a service or two, and some time, but not data.

Bottom line is that you will never succeed in making anything 100% secure - that's just not possible - so the aim is to make is as secure as possible - if it's just too much effort to break your system, it's good enough, and most lamer script-kiddies will move onto the next system.

• iptables is the way to go for any Linux system - but configure it yourself.

Don't ever ever use any "security software" that is not based on open standards - they're doomed to be poorly written and will get hacked (not a matter of "if", but "when"). Open source and open protocols are open to public scrutiny and converge to becoming a mature and reliable product; closed-source software relies mostly on the authors self-confidence of how great/secure-a-product they think it is - i.e. a small number of eyes vs an earth-full of eyes.

Hope that helps :)

Solution 3:

• disable root login
• disable login by password (allow only login by public-key)
• change SSH port

• use denyhosts (or similar)

• write your own iptbles script (so you control exactly what to allow and can drop everything else)

• force the use of SSL/TLS secured communications and make sure to have valid, non-expired and signed certificates

• turn on strict certificate verification for all external services (for example when authenticating users with an LDAP server on another machine)

Solution 4:

Start here:

http://www.debian.org/doc/manuals/securing-debian-howto/

Solution 5:

As a general starting point, I follow the benchmark/guides from the Center for Internet Security, which are comprehensive compilations of security best practices. It doesn't look like their Debian benchmark has been updated in some time, but a general overview of the steps is:

• Apply latest OS patches/packages
• Enable system / kernel / process accounting.
• Enable MAC (eg, SELinux or AppArmor).
• Enable host-based firewall (iptables).
• Verify APT sources.list (keys are correct, sources are trusted).
• Minimize network services, disable everything not required, and firewall what is.
• Use TCPWrappers to further restrict system access.
• Only use encrypted network protocols, disable unencrypted services (telnet, ftp, etc).
• Configure remote access to SSH only.
• Disable user login passwords and require key-based authentication.
• Disable filesystem sharing (NFS, SMB).
• Enable remote / centralized system logging (and regularly review logs!).
• Set a BIOS/firmware level password.
• Set a bootloader password.
• Configure system backups, have a disaster recovery plan and TEST that the backups are valid, and that personnel know disaster recovery procedures!

There are many resources on all these various settings, including the specific commands and configuration files to implement on the system in the CISecurity benchmarks.