Linux

Five tips for improving Linux security

Protecting a networked computer is a never-ending challenge -- even in Linux. These simple measures will help protect your Linux box.

What's that you say? You don't need to do anything about security on your Linux box because it's Linux? Think again. Linux is an operating system that begs to be online, so it wants to be secure. Sure it's fairly secure out of the box, but NO operating system is 100% secure if it's, well, turned on. Here are five crucial Linux security tips.

1: Take advantage of the keyring

To many, this is an annoyance. You log in to your machine, your machine requests a connection to a network (or LDAP server, etc.), and you have to enter your keyring password. The temptation is to disable this feature by giving it an empty password and dismissing the warning that you'll be transmitting unencrypted information (including passwords). This is not a good idea. Although you might think it a hassle, this feature/functionality is there for a reason -- to encrypt sensitive passwords when they are sent over the wire.

2: Enforce user password update

If you run a multi-user environment (as Linux is wont to do), you should make sure that your users change their passwords every so often. To do this you use the chage command. You can check the expiration with the command sudo chage -l USERNAME (where USERNAME is the name of the user you want to check). Let's say you want to expire a user's password and make him change it upon next login. To do this, you could issue the command sudo chage -E EXPLICIT_EXPIRATION_DATE -m MINIMUM_AGE -M MAXIMUM_AGE -I INACTIVITY_PERIOD -W DAYS_BEFORE_EXPIRATION (where all options in CAPS are user defined). For more information on this command, see the man page (issue the command man chage).

3: Don't blindly disable SELinux

Similar to the keyring, SELinux is there for a reason. SE stands for Security Enhanced and it provides the mechanism that controls access to applications. I have read of a number of "solutions" to problems that involved disabling SELinux. If this is seen as a solution, it will only lead to more, uglier problems. If a particular program isn't running properly, look into modifying an SELinux policy to fit your needs rather than disabling SELinux. If you don't want to do this via the command line, you might want to check out a GUI tool called polgengui.

4: Don't log in as root

It may sound as if I'm a broken record with this one, with good reason. I can't stress enough that Linux users should NOT be logging in as the root user. If you need to do administration on a machine, log in as your regular user and either su to the root user or take advantage of sudo. When you log in as the root user, you effectively bypass a major security hurdle and allow access to systems and subsystems that normally wouldn't be accessible when logged in as a standard user. Do not do this. Log in with your regular account. Period.

5: Install security updates quickly

There is a HUGE difference between the way Linux and Windows handle updates. Where Windows typically does an infrequent massive update, Linux does frequent smaller updates. Ignoring these updates can be disastrous if the right security hole is not patched on your system. You have to remember, some of those updates are in fact security patches and need to be applied immediately. Never ignore that icon indicating updates are available. And if you are using a GUI-less server, make sure you set up a cron job to check for updates or check them manually either daily or weekly. Stay up to date and you stay more secure.

Small steps

Do you and your Linux box already feel more secure? You should. With these five tips alone you have taken your Linux box to a new level of security. Mind you, this isn't a complete to-do list. It's just the start. The security of a networked computer is ongoing and ever-changing. But with tips like these, you'll be better prepared to meet that elusive goal.


Check out Five Tips... the newsletter

Get a concise roundup of solutions and techniques that will make your IT job go more smoothly. TechRepublic's Five Tips newsletter, delivered every Tuesday, gives you instant access to the information you need. Automatically sign up today.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

25 comments
Humgut
Humgut

A fundamental networking component is the venerable secure shell daemon sshd. Every Linux system I admin for work, home or family/friends has sshd set up so I can painlessly access via command shell, file transfer, and remote desktop (nx). Here are some tips for doing it all safely: 1. FTP is insecure. Turn off ftpd. Use file transfer over SSH instead (SFTP). 2. Disallow root login over SSH. For added security, limit login to specific user(s). Both can be set in /etc/ssh/sshd_config 3. Don't listen on port 22. Setting sshd to listen on a port number above 1024 (nmap scan limit) will hide you from 99.9% of would-be brute force attackers. If behind a router/firewall this can be done on the router by mapping the new external port number to 22 on the inside server, or by configuration in /etc/ssh/sshd_config if the server is also acting as the firewall. 4. Use DSA public key authentication. This is both secure and convenient, once it is set up. Client simply runs ssh-keygen, then ensures public key is copied to ~/.ssh/.authorized-keys on remote account. Be sure to enforce the use of keys by disabling passwords in /etc/ssh/sshd_config 5. Limit domains that can connect. TCP wrappers lets you specify which domains can or cannot connect. Edit /etc/hosts.allow and/or /etc/hosts.deny to set it up. For example you might only explicitly allow connections from your known remote IP addresses, or you could broadly exclude domains you know you'll never connect from : *.ru *.cn ...

BenCr
BenCr

You explain the how but not the why? What good reason is there for forcing a user to change their password every 30/60/90 days?

lefty.crupps
lefty.crupps

> Although you might think it a hassle, [the keyring] is > there for a reason ? to encrypt sensitive passwords when > they are sent over the wire. No, the protocol (FTP vs SFTP) determines if the password is encrypted. The keyring prevents you from having to type your various passwords often, preventing others from seeing you do so, or from typing a password in the wrong field (such as an IM by mistake), or from a keylogger getting your passwords.

Neon Samurai
Neon Samurai

I like the mention of keyring. A nice followup would be a clear howto on attaching to MS-LDAP for authentication. What steps does PAM need, what or if Samba is needed, does it use my existing local user or impose a user.domain account like Windows does with conflicting names? (ok, I'm selfish.. joining my work notebook into the active directory is on my todo list. It just seems like it would fit in with this article theme)

kama410
kama410

Re: "3. Don't listen on port 22. Setting sshd to listen on a port number above 1024 (nmap scan limit) will hide you from 99.9% of would-be brute force attackers. If behind a router/firewall this can be done on the router by mapping the new external port number to 22 on the inside server, or by configuration in /etc/ssh/sshd_config if the server is also acting as the firewall." Pardon my ignorance (yes, I know the post is months old, somehow I've only just seen this) but how does it help to change the port sshd is listening on? I've seen something like this before, about ports above 1024 being "secure." If someone is going to take the time to port scan you, aren't they going to check every port? Or would this be a bad plan since you could set up your firewall to ignore more than five or ten requests for different ports from the same IP? Would it be a bad idea to do that? Would it be a good plan to (at least temporarily) blacklist any IP making that kind of request?

eldergabriel
eldergabriel

Good thinking, but don't forget about denyhosts. Google about it if you need to. It is certifiably awesome, and pretty easy to implement on most distros.

Neon Samurai
Neon Samurai

You may cut out some low level network noise by moving SSH away from port 22 but there is little value in that bit of obscurity. People are going to scan ports and identify the services so your SSHd is going to be found anyway and automated tools that attack SSH don't care what port it's on. Point 5 is your real protection. Use iptables to allow port 22 only from specific remote places. Do it as a whitelist; allow only known places to contact. Blacklisting like blocking *.cn does nothing to protect you from evildoer.cn from bouncing traffic through any non-.cn location. If you have multiple non-admin users who need sftp access, I wouldn't use SSH; keep it for the few admins and use ProFTPd or similar with TLS or SSL required. The sooner cleartext protocols like FTP and HTTP can be replaced with encrypted prots (or wrappers), the better. I'm a big fan of listing ssh users allowed to connect in the config and using certificates. DSA or RSA (> 2048) is a great way to connect though I also leave the password in place on the certificate except for rare cases like automatically created tunnels.

Neon Samurai
Neon Samurai

If falls in with "don't use the same password everywhere, don't use the same password for ever, don't use simple passwords". If someone gets your password hash value, they can take it home and start working on breaking it. The idea is that if that takes someone in ideal conditions 30 days to break; you've probably already changed your password by the time they've finally got it. If they break it before your password expiry, it remains useful for a much shorter period of time because you will eventually change it. Alternatively, if they get your password and it's the same password you use everywhere or one you never change; they have the keys to your kingdom for as long as you do (maybe longer if they change it on you). based on current methods for breaking passwords, 30 days is the recommended lifespan but since average users resist; 90 days is the norm. At least 10 characters, capitals, lower, numbers and symbols. Anything shorter than 7 characters can be broken in under ten minutes with currently available rainbowtables. Simple passwords at 8 or 9 char can be broken with rainbowtables (hence the symbols/numbers/lower/upper for complexity). Anything 5 characters or shorter falls over easily to brute force regardless of complexity. 6 to 8 char brute force depends on the hardware and patience someone has but probably exceeds 30 or 60 day limits. Passwords are disposable items like drinking straws. You use them for a short while, don't get attached to them, replace them on a whim.

david.hunt
david.hunt

This article has also raised the hoary old myth about regularly changing your password for security reasons. We could start a whole thread on this particular religous topic. IMHO. Pick a *strong password* and stick with it. Only change it if you suspect it to be compromised. If you force users to change strong passwords often, they will be more inclined to dymo it on the front of the monitor, so they don't have to try and remember it. A popular alternative is to use the same password with the month number appended. Not much better, as the password in such instances is mostly dictionary word.

david.hunt
david.hunt

If it's just access to MS SMB Shares, then you can just enter the Domain/UserID and Password when connecting. I haven't used a Keyring for this, as I just let it forget the password at the end of the session. If you want to authenticate Linux users against MS AD, then VMware had a good How To for the ESX Console by configuring PAM to call AD using Kerberos. I had this working for over a year when it got broken by a change that increased the size of the Request / Response so it had to be TCP and the Linux library only supported UDP. After tearing my hair out for some time, I gave up. Hair growing again nicely now (in places);-) Maybe in the last two years, that library has been updated to support TCP. Sorry, but the details are somewhat fuzzy in my mind after the elapsed time.

Jaqui
Jaqui

it creates users for itself. and if there is duplicate names, samba doesn't care, a windows system will refuse the duplicate names.

seanferd
seanferd

More common casual attackers will not scan the full port range. You can also use a firewall which uses port "stealth" as opposed to just closing (normally unused) ports.

kama410
kama410

How does that work (whitelisting) if you have users connecting from their home broadband connection with a dynamic IP? Allow the entire range of addresses allocated to i.e., RoadRunner? (Yes, that is just a joke.) Can it work at all?

zhuatclfk
zhuatclfk

OK, I'm not an admin, but I do use several systems that require me to change my password every 90 days. What a huge pain in the rear. There is growing professional opinion that this password policy is not worth the trouble because a) using strong enough passwords to begin with makes them nearly impossible to brute force and b) requiring users to use strong passwords that are by nature hard to remember and renewing them periodically forces them to breach security in other ways, i.e. writing them down! Most (if not all) Linux distros nowadays use shadow passwords, so if someone can get your password hash, they already have root access and you're hosed anyway. If they find some other way (entirely possible), Linux uses a cryptographically secure one-way hash and the only way to decrypt a hash is by brute force. If I use a password (and I do) of 8 random characters or more (including upper and lower case, numerals and punctuation), that hash is virtually unbreakable. At 500,000 hashes per second, it would take up to half a century to crack. Since on average it takes half that long, we're still talking 25 years. And that 500,000 hashes per second is extremely ambitious. In reality it's probably more like 15,000 using today's tech. So, IMHO, unless you're working with nuclear secrets or something, Linux is secure enough that all one needs is a good, strong password and other reasonable security precautions to obviate the need for periodic password changes.

Resuna
Resuna

Forcing users to change their passwords routinely means that you will have more users using minor variants of the same password everywhere, using easily guessed passwords, and keeping their passwords written down. I know better. You know better. But you and I don't need to be nagged to manage our passwords better. The people who do, won't.

Neon Samurai
Neon Samurai

That second option is the one. I use direct authentication for Samba shares now but my side project is to join it into the AD for user authentication and whatever else I can get it recognizing. It's more for self interest to see how close I can get to duplicating the standard staff workstation.

Neon Samurai
Neon Samurai

For general CIFS, I've used Samba a lot. From what I've read briefly in passing, it's required to provide the netbios hostname or otherwise connect into the AD. Assuming this also involves the use of PAM, I was curious if the user names would stack since they don't on Windows proper against an AD. Hm.. must do a search and read in more detail once the new hardware order comes in and I've a bootable *nix partition again.

Neon Samurai
Neon Samurai

Changing the port is the very definition of obscurity. It's as affective as putting your spare house key under the welcome mat; secure until anyone thinks to look there, and they will think to look. Spare key for the car is similar. Changing a service port number is like moving the spare key in it's magnet box from the left wheel well to the right. It's all secure now because my friends only know to check for the spare by the left wheel and it'll take upwards of 30 seconds for one of them to think of checking by the other three wheels. Even port knocking is suspect. This is when you first connect to an unrelated port which tells the machine that your going to connect on the correct port. You ping port 23241 and the computer goes "cool, you are at IP ###.### and you want to next connect to SSH on port 22. Let me temporarily put that rule int he firewall." Ok, so now it's not just running a port scan; I have to know what port rings the doorbell. This is more complex that a simple non-standard port but it's still not a mechanism which will stop someone who knows everything except the cert/password. What you really want is a firewall allowing only known sources to reach destination ip/ports. Reject versus Drop is more a personal choice though I'm a fan of Drop myself; I figure if it didn't have a firewall rule permitting it then I needn't even acknowledge that it came in. Drop actually smells like obscurity because I'm effectively hiding my server behind no response rather than standing front and center saying "we don't accept that here, try again". My only argument would be that the obscurity is caused in relation to something with a real security mechanism; the firewall actively blocks unwelcome ip/port connections though it may passively obscure a negative response for the source ip. IPTables is actually pretty easy to work with if you just want to create a set of firewall rules. I do generally use Bastille though as it does firewall rules along with other system hardening. On systems where I don't currently have Bastille, I just use a basic shell script with relevant iptables commands listed: http://www.howtoforge.com/linux_iptables_sarge You'll use "iptables" and the firewall rules start "Configuring Rule Sets" though I'd recommend skimming the whole document just for information. Even if you then use a GUI firewall manager, you'll know what it's doing in behind. There are also a load of GUI firewall managers available. I thought Ubuntu had something installed by default. Mandriva has a specific firewall manager in the draketools ("Configure My Computer"). I'm comfortable with Bastille or my own firewall rules so I can't recommend a specific program for Debian.

kama410
kama410

So, really, changing your port is pretty much security through obscurity, yes? I mean to say, yes, it will hide you from the script kiddies that aren't going to be very subtle anyway, but against a determined attacker it isn't even going to slow them down appreciably. Yes, I knew about using a firewall that just drops incoming packets instead of refusing them.

Neon Samurai
Neon Samurai

For an IP range, I've had only a small group of users that need whitelisting. Have them connect to a more open protocol where you can see the source IP (netstat, pktstat, server logs). Whois that IP and get what network block it falls within. The hostname of that IP will also indicate what block it's within. For example blah-324.somename.ispdomain.com means you only need to be open to *.somename.ismpdomain.com. If it's SSH specifically that your watching for failed logins; syslog should show it or auth.log. You can also see something happening through the "lastb" command rather than "last" which shows successful logins. I run a daily schedualled 'grep "ailure" /var/log/auth.log' which emails me failed logins. One or two may go unnoticed but dictionary attacks are pretty obvious. (discovered a few in programs.. that is all kinds of fun until I get bored and temporarily blacklist the IP) Nonstandard ports will help against blind blanket attacks or threats hard coded to a port number. The method is hosed for anyone who'll do an nmap 1-65000 or everything coded smart enough to look for services on non-standard ports. In terms of security, there are ways to create strong and memorable passwords. Heck, you can double a weak password with some extra characters between and get something memorable but of strong character length. Worst case, you give them a password manager like Keepass. I put my money where my mouth is; 10 or more characters for remmebered passwords and 20 char or so fuly random for manager stored passwords. At work, I purposefully use passwords beyond the policy so I apply more grief to myeslf than I inflict on my users. It's really not hard enough to memorize a new password or keep it in a password manager to justify null or weak passwords even on home machines. Maybe a home user doesn't change it every 90 days but it still shouldn't be kept for ever or years on end. Passwords should be disposable items not a string of text one get's attached to. I agree that the lack of multi-part authentication is a problem. Biometrics improvements can only help things. Token authentication offers promis. The one trouble I see is the same issue with asking for strong passwords; "but it's too hard". Now they have to fumble with several tries before a successful finger print swipe or other scan. They have to cary an extra thing without loosing it. And, where do they keep the token? In the bag with the laptop it's meant to unlock. Here's hopeing something can finally usurp the single authentication password system soon.

kama410
kama410

I was going to ask if ISPs would willingly hand out there geographic range information, but the answer is pretty clearly yes, given that every weather site and street map site I've ever visited doesn't seem to need me to tell them where I am before presenting a fairly accurate local picture. So, yes, I can see how you could just open a small range of addresses for people who would only be connecting from their home. I think I like the dyndns service solution more, myself. Even if someone does manage to poison your cache they still have to get the password correct to log in. (Of course that brings us back to the whole strong password expiry question.) Unless they can find a hole somewhere. DNSSEC is supposed to be implemented on the internet root servers soon, isn't it? Would dyndns work for someone 'on the road' and connecting from a hotel's wireless service? (I'm not sure I'd want anyone connecting that way anyway. It requires you to trust the security of the hotel. I think I'd be willing to pay the cell bill and have them connect that way.) I guess it would depend on the setup at the hotel as far as getting dyndns to work? What would you check in your logs? faillog? I've looked at that after entering the wrong password on my own machine and it didn't show anything at all. I'm a bit confused about that one. Any of those solutions are definitely far better than the 'security through obscurity' approach of a non-standard port number. I'm not sure I agree with you about the mandatory password expiry. I have seen so many users with amazingly weak passwords. They're weak, they only rarely are aware that their password is weak, and if they did know they wouldn't really care. There really has got to be a better way. Something you know, something you have, or something you are. If I could have it my way it would be a combination of something you have and something you are. Sadly, all of those kinds of solutions seem to cost more than a high end workstation.

Neon Samurai
Neon Samurai

It depends on the serice and your users. In the case of SSH, you should be dealing with admin users and maybe some special cases. I know it was a joke but RoadRunner would have it's network broken down into smaller segments and know geographically where those IP segments are used. You wouldn't open up all of RoadRunner's range, only the minimal segment that the dynamic IP belonged too. 254 remote points that can see your port 22 rather than 254 * 254 or greater (based on 192.168.255.255/16). You can whitelist against a dyndns domain or similar service; benefit is allowing dynamic IP addresses, risk is DNS poisoning which can be mitigated. You can whitelist against an IP range; benefit is no dns server involved while allowing a small collection of dynamic IPs, risk is an attacking IP within the allowed group but the small IP group should just be the remote end's ISP so you can go after attacking IPs through the provider. You can whitelist just the IP then change it through a local admin or secondary connection when the dynamic IP is changed. You can whitelist the external IP if your dynamic IP is actually internal such as it would be at a hotel offering internet access. It opens you up to any remote IP behind that hotel's gateway but the logs are pretty obvious when someone's running a dictionary against your port 22. With firewall rules in place, port 22 does not exist for anyone outside the whitelisted IP ranges. Certificate login negates user/pass attacks and password on the cert helps protect it from local unauthorized use or being copied off for use from a secondary attack location. If someone does get your personal certificate and try to use it, a strong password negates dictionary, a string certificate bit strength reduces cryptography attack and a healthy password length negates brute force. (edit); it's not perfect but much better than relying on SSH with a non-standard port, leaving port 22 open to the world or blacklisting undesirable locations plus the ongoing task of adding new found undesirable IP.

Neon Samurai
Neon Samurai

Sadly, passwords remain the best we have even with the amount of other authentication methods that have tried to replace them. I'd suggest using a good password manager. I still wouldn't go less than 90 days though. Three months of reusing the same disposable item is a pretty long time. Passwords are disposable items that a user should be able to change on a whim even if not forced to by password aging. With the shadow file, strong passwords can negate the effects of evildoer taking a copy home to chew on with John or similar. Maybe the get a few other limited user accounts but can't break root's hash in a reasonable amount of time. It may be half a century for them at home but if they farm those hash values out to a distributed cracking project they may very well still take longer than 90 days so the password aging has done it's job. Periodic password changes is to easy a step to include in one's personal computing regardless of platform. It doesn't take enough effort to memorize your password off a post-it over the next 24 hours before destroying the paper crutch. Keep the current password locked away in keepass or similar and you can easily manage any number and length of random passwords by simply remembering one. I do get the "if it's not broken, don't fix it".. My mind just works in the "if it's easy to do, why wouldn't you" way of things in security. (Also did the DeICE2.100 disk over the last week.. great fun)

Neon Samurai
Neon Samurai

Use Keepass or similar to manage passwords. Remember a long passphrase to unlock the passwords. Then, it doesn't matter how frequently or complex the passwords become. The issue is users not understanding why the password policy is in place not the password policy being ineffective. That's also why the normal seems to be 90 days rather than 30 as it should be based on available breaking methods.