66

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?

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Thomaschaaf
  • 3,012
  • 5
  • 29
  • 24
  • 1
    There is a lot of overlap with http://serverfault.com/questions/42/securing-a-fresh-ubuntu-server and – Zoredache May 23 '09 at 21:02
  • 1
    Ubuntu has ufw Debian does not ;) I was woundering whether people were configuring iptables them selves or using some software like fireHOL – Thomaschaaf May 23 '09 at 21:06
  • 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. – Scott Pack May 23 '09 at 23:24
  • 3
    Uhm... Debian has ufw. http://packages.debian.org/ufw – womble Jan 17 '10 at 21:31

8 Answers8

50

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
Nick Devereaux
  • 191
  • 4
  • 9
pQd
  • 29,561
  • 5
  • 64
  • 106
  • 4
    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. – Scott Pack May 23 '09 at 21:33
  • 13
    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. – Adam Gibbins May 23 '09 at 21:37
  • 3
    -1 for security through obscurity. Otherwise decent answer. – dwc May 23 '09 at 21:46
  • @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. – pQd May 23 '09 at 21:53
  • 1
    And you mean sudo not su - – LapTop006 Jun 20 '09 at 11:03
  • ++ I do the same, but I missed fail2ban !!! – Martin K. Jul 25 '09 at 19:34
18

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 :)

Xerxes
  • 4,133
  • 3
  • 26
  • 33
  • "...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. – L0neRanger Mar 29 '14 at 18:26
12
  • 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)
x-way
  • 216
  • 2
  • 4
9

Start here:

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

KPWINC
  • 11,274
  • 3
  • 36
  • 44
6

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.

jtimberman
  • 7,511
  • 2
  • 33
  • 42
5

I would suggest not attaching a machine directly to the Internet. Place some kind of firewall between the machine and the Internet. This allows you to do security and network monitoring without putting more load on the server. Personally, I find network and function segmentation frequently simplifies network troubleshooting, although on occasion, the additional complexity does make analysis more difficult.

The safest, but most annoying to manage, firewall policy is to deny all and explicitly allow only the traffic you must allow. This is annoying, because one frequently needs update the firewall policy as the network needs change.

I would also suggest using some kind of interface firewalling on the server - defense in depth is the key. Using non-standard ports for administration related services doesn't hurt. fail2ban is fine. Pursue the more specific questions about security applications on Serverfault to find more ideas.

Security is like the joke about the two hikers and the bear - while one can never achieve perfect security, it is helpful to be a more difficult target than the other guys.

pcapademic
  • 1,650
  • 1
  • 14
  • 22
  • +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. – dwc May 23 '09 at 21:50
  • 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. – pcapademic May 23 '09 at 22:32
4

Some people have pointed at the Securing Debian Manual. This should be perfectly adequate for everything but military requirements.

Many people think that being ridiculously paranoid is cool or professional or something. It's not, it's just annoying for other admins and outright repressive for your users. Most of the stuff you'll see recommended is just fake busywork to feel useful for the paranoid admin, but not actually helpful, since the real security breach is likely to be caused by a not sufficiently updated system and/or from an inside source.

That said, I do consider it one of my tenets to not trust anything on the local network any more than anything from the Internet. Therefore, I configure everything to require authentication even on the local network. I encrypt and authenticate all traffic between every one of computer using IPsec.

I am in the process of converting to full-disk encryption for all my servers.

I install only services I use. I do not have a firewall; I configure the services I have to require authentication or limit them (by the program's own configuration or by TCP-wrappers) to certain IPs. The only thing I ever need to block using iptables was memcached, since it had no configuration file, and did not use TCP-wrappers.

I use good, randomly generated passwords for my accounts and trust my SSH server (and all other services) to keep those who do not know the password out. fail2ban is only for those with limited space for log files, IMO. (You should have good enough passwords to be able to trust them.)

Teddy
  • 5,134
  • 1
  • 22
  • 27
3

Go through this nice how-to at www.debian.org/doc/manuals/securing-debian-howto/

I personally change the ssh port and use fail2ban + denyhosts. And I block everything that is not needed. The more you block the less you have to worry about.

Vihang D
  • 632
  • 4
  • 7
  • 4
    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. – Matt Simmons Jun 03 '09 at 03:26
  • 3
    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. – Vihang D Jun 03 '09 at 07:07