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?

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

Ubuntu has ufw Debian does not ;) I was woundering whether people were configuring iptables them selves or using some software like fireHOL
–
ThomaschaafMay 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 PackMay 23 '09 at 23:24

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]

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 PackMay 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 GibbinsMay 23 '09 at 21:37

@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.
–
pQdMay 23 '09 at 21:53

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.

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.

"...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.
–
L0neRangerMar 29 '14 at 18:26

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:

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.

+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.
–
dwcMay 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.
–
pcapademicMay 23 '09 at 22:32

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

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 SimmonsJun 3 '09 at 3: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 DJun 3 '09 at 7:07