Five tips for improving Linux security

Five tips for improving Linux security

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.

SHARE:

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.

Topics: Software, Linux, Open Source, Operating Systems, Security

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

Talkback

92 comments
Log in or register to join the discussion
  • Better yet, consider switching to Windows

    <u>1: Take advantage of the keyring</u>
    Unix security ? inherited by Linux ? was developed in a friendly academic environment and for a <i>single machine</i> 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 <i>networks</i> in mind: Authorization *and* credentials are manageable across multiple machines and domains.
    A Linux user can be member of a <i>single</i> group only. A file can have a single owner and belong to <i>single</i> 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 <i>everyone in the world</i> 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.
    <u>2: Enforce user password update</u>
    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.

    <u>3: Don?t blindly disable SELinux</u>
    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 <i>nothing else</i> 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 <b>swiss cheese horrors</b> which are open invitations to hackers! Why? Because these two gems will <i>execute a file as the file owner/group</i> 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.
    <u>4: Don?t log in as root</u>
    Duh!
    <u>5: Install security updates quickly</u>
    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.
    honeymonster
    • 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
      ~doolittle~
      • 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), <b>Ubuntu</b> has ACLs by default? Nope.
        But surely it has apparmor? Yes, but because it is such a kludge <i>it is not even enabled for Firefox by default</i>.

        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 <i>it's quality</i> - 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.
        honeymonster
      • Did you actually follow the secunia links?

        @~doolittle~

        The quoted Linux vulnerabilities are <i>minimum</i> for all distros, as the 400+ vulns are <b>Linux kernel</b> vulns.
        honeymonster
      • 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?
        honeymonster
      • 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.
        oiaohm
      • 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.
        ~doolittle~
      • 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...
        ~doolittle~
      • 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
        Earthling2
      • 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
        ~doolittle~
      • RE: Five tips for improving Linux security

        @~doolittle~

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

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

        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.
        Earthling2
      • 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!!
        ~doolittle~
      • 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.
        ~doolittle~
      • RE: Five tips for improving Linux security

        @~doolittle~

        [i]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.[/i]

        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.

        [i]... and you are fully protected[/i]

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

        Nice day to you, too.
        Earthling2
    • Spoken like a true MCSE

      The ignorance of the MCSE.<br><br>"Unix security inherited by Linux was developed in a friendly academic environment and for a single machine only."<br><br>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<br><br>"A Linux user can be member of a single group only."<br><br>This would be news to every Linux user, but is wrong.<br><br>"A file can have a single owner and belong to single group only"<br><br>Sure if Linux file systems didn't supported extended attributes, they do. And they're no kludge and work perfectly across networks.<br><br>"Practically nothing else is securable"<br><br>No idea of what mandatory access control systems like SELinux is.<br><br>The end with the typical superficial analysis of vulnerabilities. All the MCSE ignorance boxes checked.
      Richard Flude
      • RE: Five tips for improving Linux security

        @Richard Flude
        [i]No idea of what mandatory access control systems like SELinux is.[/i]

        SELinux is an afterthought. Something that NSA had to develop to make the system reasonably secure. It was released six years after NT 3.5.

        AppArmor was included in Ubuntu distribution in 7.10, right after the AppArmor team was laid off by Novell, half a year later than Vista's mandatory integrity control and more than a year since it MIC announced.

        LSM, a way to hook security modules into Linux Kernel, can be seen as a perfect example of a "slap-on" security afterthought. I am sure that Linux apologists view it as "flexibility".

        :-P
        Earthling2
      • RE: Five tips for improving Linux security

        @SITE DEVELOPERS

        When are you going to fix the bug that flags edits to posts?
        Earthling2
      • How do the Linux attackers not have reply.

        Earthling2 LSM is caused by a simple fact from 1992 to 2000 when it come to secuirty model a single model that covered every possible problem could not be found.

        Flexiblity has nothing todo with it. Its also secuirty by obscenity. Something MS likes claiming. An attacker cannot be exactly sure what security framework they are going head to head with.

        Debate about the security system had been going no where from 1992 on wards with the Linux kernel. Ie it was talked about before NT even existed. NT people don't want to admit there model has flaws.

        AppArmor is still in development by the way. I don't agree with using AppArmor due it it not being mainline Linux so has not passed peer review.

        Capabilities framework has been in Linux since 1992. One of the base frameworks that SELinux depends on to operate. Same with firewall and so on. Linux has just put the framework together in a different order. I could call Windows firewall a slap-on after thought as well.
        oiaohm
      • RE: Five tips for improving Linux security

        @oiaohm
        First of all, it was very tempting to call LSM a "slap on" model of security. It just is... :-&gt; There is nothing wrong with it, except, may be <a href="http://www.grsecurity.net/lsm.php">what</a> grsecurity people say, but I won't argue.

        [i]An attacker cannot be exactly sure what security framework they are going head to head with.[/i]

        Reading many a comment in these talk-backs made by a certain individual, I would say whole 99% (of that 1%) should be running Firefox if invincible AppArmor profile policing the Kernel itself. :-&gt; Seriously, when you get to noticeably large number of users, even with 101 different security profiles there will be millions worth taking over that have the same security (mis-) configuration.

        [i] NT people don't want to admit there model has flaws.[/i]

        First, some of them just try to argue that is has an analog of the x bit (from the rwx) since NT was first released, and then more. By default. Since July 1993. Second, new features are added (mandatory integrity control is one example). Third, the model is quite flexible from the start. More flexible than the original Unix model anyway. There is more info on MSDN if you care.

        [i]I don't agree with using AppArmor due it it not being mainline Linux so has not passed peer review.[/i]

        Does Ubuntu have something in the Kernel enabled by default that hasn't passed the peer review? Uhm... has there been shortage of eyeballs? I may suspect so after OpenSSL PRNG change that was overlooked for two years (was it two years)?

        [i]Capabilities framework has been in Linux since 1992. [/i]
        What is the difference between <a href="">capabilities</a> in Linux and <a href="http://msdn.microsoft.com/en-us/library/aa379306(VS.85).aspx">privileges</a> in Windows?

        The myth of Windows inferior security doesn't hold, actually, except two very important points: very relaxed default security and ineptitude of software vendors. Examples: nothing prevents Firefox from disabling the execute permission on downloaded binaries; Google made Chrome framework that is very secure. They appear to have problems with Linux though exactly because there is no standard security framework.
        Earthling2
    • How people get stuff so badly wrong.

      Run windows on FAT and you have less than Linux default. Sorry selection of filesystem is key. facl was designed into the ext filesystem. NTFS also can be run on facl disabled. So no MS is not magically better or worse here.

      MS also suffers from the removable cred problem blocking access to a file. Cause lost permissions due to ID of system or user being deleted. Having hard-drives movable between OS's taking permissions is bad basically.

      NFS and SMB when used by Linux is network aware. Can translate between local creds and network creds. Linux just skips over the idea of each machine having a unique id. So avoiding permission messes on local file-systems. You find for remote Samba places remote permissions in extended attributes on the filesystem.

      Windows so called creds have trouble mapping to NFS and Posix filesystems. By the way some filesystems under Linux you don't have the option of turning facl off its always on. Linux filesystem stack really wants facl's. Yes it a bad selection speed over secuirty is the reason not to use facl's. NFS ACls work perfectly across network. Most MS trained people are idiots here. When do you see a local machine user data on a Windows Server. Answer you don't unless you administrator is insane. Instead you see all users on the Windows Server being in the ADS. ADS is just a mutated LDAP causing all machines to have the same user data. Either machine stand alone or running in a network is how windows is happy. Linux provides a half way point. Standalone able to interface with network as required and leave behind clean.

      Biggest file system difference on Linux is that executables require an executable bit to run. A feature MS is sadly lacking.

      3 Setuid and setgid these are contained. one of the recent day credential settings tells application that is has root from Setuid or setgid but is real ID has not changed at all. Lieing to applications so they can be run at lower rights. Feature MS lacks. Yes an application can assume it will run as root but Linux can lie to it as well. The history if setuid issues causes this change. Sorry you are badly out of date. Most distributions with selinux or creds set right have been 100 percent protected against all the recent (last 8 years) setuid or setgid attacks. Get your information upto date please. Yes setuid or setgid possible exploits have appeared but they have been not operational on systems running selinux. Here is the killer you fool. http://wiki.postgresql.org/wiki/SEPostgreSQL_SELinux_Overview SELinux does reach outside kernel mode. Up into X11 up into API's and up into databases. Saying SELinux does not cover API's is a pure lie.

      Ie setuid and setgid control is API based. Linux does have API controls. SELinux does provide role based secuirty as well. That connects to the application itself. When I log into debian text based I get asked what role do I wish to run as. I could have the same question graphical with SELinux. Yes I can set my role based on what I am doing as a user. Where is that feature in windows. 1 user many roles.

      Yes on windows there are ways to boot up with role based secuirty turned off as well. Again its not advisable for either platform. Gets better under windows I can probe the secuirty system. Ie as an application ask can I do X get answer no don't do it so don't raise alarm. Selinux is silent running. You do something wrong selinux kills you instantly and sends alarm. Basically it hides it presence. SELinux policies kick Windows Policies for intruder stopping. Intruders are more likely to set off alarms on Linux than windows.

      5. Old lie. Linux 2.6.x is older than Windows Vista Linux 2.6.x 2004 vs Windows Vista 2006. So two years difference there. Next Linux kernel covers almost all drivers Linux uses. Windows Vista numbers don't include like ATI driver flaws or other third party drivers. Linux Kernel covers more CPU types than Windows Vista. Basically the higher numbers are perfectly explainable. Also does not help that Linux defines anything that does a buffer overflow as a secuirty flaw exploitable or not. MS only defines something as a secuirty flaw once an exploit exists attacking it. Almost 90 percent of Linux secuirty flaws are reported directly from developer discoveries not attackers. All of windows secuirty flaws come from attackers. MS steath rolls out secuirty updates that Linux developers are open about. At least Linux admin and attacker are on equal footing.

      If Linux went by the MS mode since 2004 Linux has had only 2 exploits in kernel. Most flaws are never exploited or require conditions attackers can never get.

      You got 2 completely wrong go read Microsofts Own Administrator guide for 2000 2003 2008 servers. They give exactly the same advice. Opps. MS says do this. You don't. Reason is password cracking. Give attacker enough time they might crack the password. Changing target harder to break.

      4. Please explain to me why Windows users still start defaulted as an administrator account. To by pass with the rights already given even in Windows 7 is simple.
      oiaohm