Between the Lines

Larry Dignan, Andrew Nusca and Rachel King

Five tips for improving Linux security

By | June 15, 2010, 2:30am PDT

Summary: Protecting a networked computer is a never-ending challenge even in Linux. These simple measures from TechRepublic’s Five Tips blog will help protect your Linux box.

Protecting a networked computer is a never-ending challenge — even in Linux. These simple measures from TechRepublic’s Five Tips blog will help protect your Linux box. The advice is timely given the hubbub over Linux security.


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.

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Larry Dignan is Editor in Chief of ZDNet and SmartPlanet as well as Editorial Director of ZDNet's sister site TechRepublic.

Disclosure

Larry Dignan

Larry Dignan has nothing to disclose. He doesn’t hold investments in the technology companies he covers.

Biography

Larry Dignan

Larry Dignan is Editor in Chief of ZDNet and SmartPlanet as well as Editorial Director of ZDNet's sister site TechRepublic. He was most recently Executive Editor of News and Blogs at ZDNet. Prior to that he was executive news editor at eWeek and news editor at Baseline. He also served as the East Coast news editor and finance editor at CNET News.com. Larry has covered the technology and financial services industry since 1995, publishing articles in WallStreetWeek.com, Inter@ctive Week, The New York Times, and Financial Planning magazine. He's a graduate of the Columbia School of Journalism and the University of Delaware.

For daily updates, follow Larry on Twitter.

Talkback Most Recent of 79 Talkback(s)

  • Better yet, consider switching to Windows
    1: Take advantage of the keyring
    Unix security ? inherited by Linux ? was developed in a friendly academic environment and for a single machine only. Hence, with no built-in notion of a networked environment this is what you get: Kludges and inconvenience. Compare to Windows which was built with multi-users and networks in mind: Authorization *and* credentials are manageable across multiple machines and domains.
    A Linux user can be member of a single group only. A file can have a single owner and belong to single group only. If you want to access a file which belongs to a different group from yours, you are out of luck. Either change the group of the file (but locking out users from the current group), change the user?s group (but user loses access to files in his current group) or (eureka!) change the file?s permission so that everyone in the world can access it.
    Windows users can be members of any number of groups. Files access control lists can allow any number of users and/or groups fine-grained access.
    Sure, you can bolt on ACLs on Linux. But hardly anyone does it. Why? Because it is a kludge which have all kinds of corner cases and in general works horribly across the network.
    2: Enforce user password update
    False sense of security! If you set up a draconian policy users will just change a few components and will thus use predictable/guessable passwords. Or worse, they?ll keep a note in their drawer with their current password.

    3: Don?t blindly disable SELinux
    Again, Unix and Linux lacks fine-grained security. This goes for the file system where you only have me-us-everyone levels with only read/write/execute permissions. But it is even worse: Practically nothing else is securable. If you cannot ?map? your object to a file system object it is not securable, period. You cannot secure an API using permissions.
    Windows has granular permissions for e.g. desktops, windows stations at API level. This means that with Windows you can associate permissions with roles/groups and have fine-grained (and policy driven) control.
    The Linux solution? Setuid and setgid. Two swiss cheese horrors which are open invitations to hackers! Why? Because these two gems will execute a file as the file owner/group instead of the launching user. With setuid/-gid you can design an executable which assumes that it runs as root (because it will). But what happens when the utility has a buffer overflow? Pwnage! Think this is theory? Think again, history is littered with vulnerabilities in setuid utilities: http://www.bing.com/search?setmkt=en-US&q=setuid+vulnerability.
    4: Don?t log in as root
    Duh!
    5: Install security updates quickly
    But I thought that Linux didn?t have any vulnerabilities? It does? But at least it has fewer vulns than Windows, right?
    Wrong. Linux (the kernel) requires many more patches than Windows. Compare Linux kernel 2.6 with Windows Vista:
    http://secunia.com/advisories/product/2719/
    http://secunia.com/advisories/product/13223/
    Linux kernel: 417
    Windows Vista: 183
    This is actually a bit unfair as the Vista numbers include vulnerabilities in bundled software such as Outlook Express, Movie Maker, Speech Recognition, Malware Protection Engine etc.
    ZDNet Gravatar
    honeymonster
    15th Jun 2010
  • some corrections...
    @honeymonster

    "A Linux user can be member of a single group only. A file can have a single owner and belong to single group only"
    false - you can add secondary group membership "useradd -G {group1, group2, etc}

    "Sure, you can bolt on ACLs on Linux. But hardly anyone does it."
    I set ACLs on ALL our production servers. It is no simple task so I am not suprised a typical windows user will be confused and not bother to config.

    "If you set up a draconian policy users will just change a few components and will thus use predictable/guessable passwords."
    This is blatently false. Try reading your pam.d man pages on enforcing pw length and complexity. Ovbiously you have no experience with this. You probably have not heard of SecurID or Centrify either.

    "Again, Unix and Linux lacks fine-grained security."
    If you ignore ACLs, then yes.

    "The Linux solution? Setuid and setgid. Two swiss cheese horrors which are open invitations to hackers!"
    Selinux + ACL address these issues. Oh wait, not to a typical windows user, my bad.

    "Linux (the kernel) requires many more patches than Windows."
    The actual number of vuln's will vary with your distro's version, a vuln count is not a risk assesment. Go ahead and beat the dead horse if you like, the "get the facts" campaign didn't really work well with technically knowledgeable staff IMHO

    "This is actually a bit unfair as the Vista numbers include..."
    see above
    ZDNet Gravatar
    ~doolittle~
    15th Jun 2010
  • Speaking of typical users
    @~doolittle~

    So, the most consumer-friendly Linux distro of all (and thus the one most in need of good, default security practices), Ubuntu has ACLs by default? Nope.
    But surely it has apparmor? Yes, but because it is such a kludge it is not even enabled for Firefox by default .

    SELinux or ACLs does not make the horrific setuid go away. You still have tons of utilities working this way. Each one offering an attack vector. Setuid/-gid is the ActiveX of *nix: You have to trust the utility (since you are handing over the keys to the kingdom) and you have to trust it's quality - that it does not contain bugs.

    But none of this matters if all your mitigations are too kludgy for average users to navigate. And they are. Horribly so.
    ZDNet Gravatar
    honeymonster
    15th Jun 2010
  • Did you actually follow the secunia links?
    @~doolittle~

    The quoted Linux vulnerabilities are minimum for all distros, as the 400+ vulns are Linux kernel vulns.
    ZDNet Gravatar
    honeymonster
    15th Jun 2010
  • Linux ACLs
    @~doolittle~

    The most consumer-friendly (and much lauded) Linux distro is Ubuntu. Hence, it is also the one most in need of proper default security settings, as it is being peddled as a Windows alternative for non-techies.

    Does Ubuntu come with ACLs by default? No it doesn't. Because it is such a kludge, canonical chose not to burden their users with that atrocity.

    But sure, you can enable ACLs (and then also break out of the single group madness). Then they will somewhat work on your local machine. Setting them up in a network and for network shares is a whole other ballgame!

    And on the topic on ACLs, how are *nix progressing with a proper UI tool for managing ACLs? You know, like right-clicking and choosing Properties|Security? Ah, what good are they to joe if you can only manipulate them from the command line?
    ZDNet Gravatar
    honeymonster
    15th Jun 2010
  • Honeymonster
    honeymonster You idiot you have never investaged ubuntu.

    In install options you can choose filesystem choose xfs and facl is on. Users by default start owning to multi groups.

    Ubuntu landscape turns facl's on by default when in network mode. Single group only exists until users join a full blown Ubuntu network.

    You are doing the same as comparing MS Windows 7 Home to MS Windows 7 PRO. Ubuntu magically changes between them.
    ZDNet Gravatar
    oiaohm
    15th Jun 2010
  • did you know that vendors actually compile patches into the kernel?
    @honeymonster

    That is why you have to install the updates.

    For example, if you are running Ubuntu 9.10:

    http://secunia.com/advisories/product/28063/
    "Unpatched 0% (0 of 78 Secunia advisories)

    Most Critical Unpatched
    There are no unpatched Secunia advisories affecting this product, when all vendor patches are applied.. "

    All those numbers after the kernel actually mean something. Read the errata.
    ZDNet Gravatar
    ~doolittle~
    15th Jun 2010
  • setuid, kernel and pretty GUI
    @honeymonster

    "SELinux or ACLs does not make the horrific setuid go away."
    Most sysadmins use the term "mitigated" when they are hardening systems. You either do it right or don't bother.

    "The quoted Linux vulnerabilities are minimum for all distros"
    So the kernel version and patch revision has no bearing... I am calling you "/facepalm" from now on.

    "how are *nix progressing with a proper UI tool for managing ACLs? You know, like right-clicking and choosing Properties|Security?"
    This is the exact reason we priv-seperated the developers and the sysadmins. Even the security group themselves are their own entity, they are responsible for penetration testing and compliance. Users are not admins. That is why XP was such a boon to the malware industry. Do cisco routers and firewalls have such pretty GUIs? no, and windows admins who do admin them don't complain about it. Well maybe you - catch ya later facepalm...
    ZDNet Gravatar
    ~doolittle~
    15th Jun 2010
  • RE: Five tips for improving Linux security
    @~doolittle~
    Secunia count of Ubuntu unpatched vulnerabilities may be somewhat misleading. Consider including Linux Kernel vulnerabilities from
    http://secunia.com/advisories/product/2719/

    Affected By: 217 Secunia advisories, 417 Vulnerabilities
    Unpatched: 5% (11 of 217 Secunia advisories)
    Most Critical Unpatched: Less critical
    ZDNet Gravatar
    Earthling2
    15th Jun 2010
  • therein lies the problem...
    @Earthling2

    How do you know what is covered or not covered by your current revision / patch level? You can't w/o performing a review of what has been patched or backported, and they are different depending on your distro. Ubuntu running 2.6.32-x and RHEL/CentOS running 2.6.18-x may or may not be the affected by the same vulns.

    I would love to clip one of my nessus or trustwave scan results along with my resolution analysis (it's usually "covered in this patch xxx") but I can't legally - and honestly if it does not come from my security group I could not care less. Not to mention I don't feel like doing one off ad-hoc just to prove you wrong, so I will just argue there are 2 schools of "get the facts" at work here - one windows/anti linux (the original MS get-the-facts campaign) and the real-life one I am preaching at the moment (the pro-linux stance) so I am going to stick to my guns and say, I am going to stand by my post of ubuntu 9.10 being fully patched w/ no vulns.

    And why not? my results have always been accepted by E&Y (our PCI/SOX auditors) and we pass w/ flying colors every time. It's what I am paid to do, and weather or not some MCSE says it's not I could care less.

    cheers
    ZDNet Gravatar
    ~doolittle~
    15th Jun 2010
  • RE: Five tips for improving Linux security
    @~doolittle~

    First of all, let me say that I do appreciate good responses.

    How do you know what is covered or not covered by your current revision / patch level?

    I don't. My assumption that the Kernel vulnerabilities should be counted is based on observation that Ubuntu is listed as fully patched until an update is issued.

    For example the recent Ubuntu patch for the Kernel happened on June 3, and it patched the same vulnerabilities and Redhat patched earlier (look for the oldest CVE there).

    What this means in reality is that Ubuntu remained unpatched for some time, while Redhat was, and Ubuntu still was listed as fully patched.

    I am not sure whether it is a formality that needs to be ignored, or it could create some window of opportunity for the hackers. What I see is a lag between the patches being issued to the Kernel and publicly disclosed (along with the code changes) and them appearing in Ubuntu fixes.
    ZDNet Gravatar
    Earthling2
    15th Jun 2010
  • Ok now I know why you reference the kernel vulns...
    @Earthling2

    After a random sampling of the vulns listed most of the CVE identifiers are "under review" and "candidate" status meaning:

    "This CVE Identifier has "Candidate" status and must be reviewed and accepted by the CVE Editorial Board before it can be updated to official "Entry" status on the CVE List. It may be modified or even rejected in the future."

    so they have yet to be officially. Here's the kicker: most of them ALREADY HAVE FIXES for redhat / suse / debian / ubuntu distros so they are covered. Out of five only one didn't. So that is a lot less than the 5% of vulns covered in the "distroless" 2.6 kernel listing.

    NOW WE HAVE THE FACTS LOL!!
    ZDNet Gravatar
    ~doolittle~
    16th Jun 2010
  • hey a patch was released for RedHat / Ubuntu yesterday
    Ironically, this fix is for cifs/samba that address the one out of five I mentioned above.

    What is happening with the CVE entry I believe, is the ones that are "candidate" status and are under review, do not make it into the distro CVE listings until they are officially submitted. Then, if no fix exists, it is listed under the distro-specific product listing as not patched.

    So this means, the way it stands, what I have posted before is true and Ubuntu 9.10 really is 0% unpatched and you are fully protected.

    The Kernel specific CVE entries that are under review are "potential" threats that have yet to be confirmed. Perhaps this is the "many eyes" in effect that I have seen being mentioned.

    I will be glad to debunk the "get the facts" kernel vuln CVE listings again in the future with another random sampling (it's not that hard, just a bit of time).

    cheers

    Have a nice day.
    ZDNet Gravatar
    ~doolittle~
    17th Jun 2010
  • RE: Five tips for improving Linux security
    @~doolittle~

    What is happening with the CVE entry I believe, is the ones that are "candidate" status and are under review, do not make it into the distro CVE listings until they are officially submitted.

    Nice analysis, thank you.

    CVEs for the two unpatched Windows 7 vulnerabilities have the "candidate" status. One of them is the SSL protocol design flaw, the other is a bluescreen in a video driver used with the Aero theme. It has no known (as far as I know) code execution exploits. The video driver is not installed by default on Windows Server configurations. Disabling Aero mitigates the problem.

    ... and you are fully protected

    Tread careful here: this is what my antivirus says. Seriously, it literally says "Upgrade now and be fully protected in a minute". happy

    Nice day to you, too.
    ZDNet Gravatar
    Earthling2
    17th Jun 2010
  • Spoken like a true MCSE
    The ignorance of the MCSE.

    "Unix security inherited by Linux was developed in a friendly academic environment and for a single machine only."

    Whilst *nix can be run in a single user mode, it has from early versions in Bell labs been multi-user, decades before windows even existed

    "A Linux user can be member of a single group only."

    This would be news to every Linux user, but is wrong.

    "A file can have a single owner and belong to single group only"

    Sure if Linux file systems didn't supported extended attributes, they do. And they're no kludge and work perfectly across networks.

    "Practically nothing else is securable"

    No idea of what mandatory access control systems like SELinux is.

    The end with the typical superficial analysis of vulnerabilities. All the MCSE ignorance boxes checked.
    ZDNet Gravatar
    Richard Flude
    15th Jun 2010

Talkback - Tell Us What You Think

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources