What steps do you take to secure a Debian server?

Question

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.

View more solutions

Comments

[Zoredache]

There is a lot of overlap with serverfault.com/questions/42/securing-a-fresh-ubuntu-server and

[Thomaschaaf]

Ubuntu has ufw Debian does not ;) I was woundering whether people were configuring iptables them selves or using some software like fireHOL

[Scott Pack]

I have always tended to writing iptables rules myself. I have a boiler plate that does stuff like drop all fragments, xmas packets, etc. Anything beyond that is system specific, and usually pretty dang small. I can't stress enough dropping fragments when using iptables, btw. For some reason I haven't yet researched, iptables only checks the first fragment, and blindly passes the rest without checking. To my mind, that makes fragments a liability.

[womble]

Uhm... Debian has ufw. packages.debian.org/ufw

[Scott Pack]

After doing all these run BASTILLE against the system to look for anything else. I would also recommend doing a full bore, unsafe checks Nessus scan of the system as well; then fix whatever it alerts on.

[Adam Gibbins]

Compiling a custom kernel doesn't provide security advantages unless you really know what you're doing. You'll also neglect to keep it up to date unless you put it within the package management system, which would result in worse off security.

[dwc]

-1 for security through obscurity. Otherwise decent answer.

[dwc]

+1 for nice answer. I must point out that default deny is not annoying to manage if you approach it right. Surely you must know what you are allowing, right? In fact, this should be written down in plain language as a policy statement. If you're not doing that as normal routine then you're not doing your job as an admin. If you are, it's a simple matter to update the firewall rules.

[pQd]

@Adam - yes, i do know that, still i prefer to have monolithic kernel that consists only of parts that i need. that is probably very backward, but yet i do it. @dwc - it's just one additional step which is just an icing or as we say cherry on the top of pile of unpleasant smelly things.

[Fernando]

Very good points. Every organization should have a plain language security policy statement. As the organization's needs change, the policy statement should be updated. If only for the admin to plan firewall rule implementation and CYA, a smart admin would maintain such a policy statement even if the organization management can not be bothered to think about security.

[Matt Simmons]

Ugh. You had me till "change SSH port". There's no point. Especially not when any joe schmoe with enough time on his hands can port scan you and instantly find out what port SSH is running on. It declares the service name (and server version) as soon as you connect.

[derobert]

You get an upvote for disabling password auth.

[Vihang D]

Yes, I know anyone can port scan you, and find out the right port. But most attacks are on default port. Just try to get some stats by changing the port.

[LapTop006]

And you mean sudo not su -

[Martin K.]

++ I do the same, but I missed fail2ban !!!

[Sam Holder]

The Debian Security Manual is a fantastic resource.

[L0neRanger]

"...a small number of eyes vs an earth-full of eyes." - I wish enough "corporations" realize this, but security through obscurity seems to be the trend most follow. Yes running a service, like ssh, on a non-standard port will not keep away a determined attacker. It will however keep the script kiddies away - someone running a dictionary attack on a range of ip addresses on port 22.