Re: What server hardening are you doing these days?

From: James Eaton-Lee (james.mailing_at_gmail.com)
Date: 11/12/05

  • Next message: Paul Greene: "break in?"
    To: matthew patton <pattonme@yahoo.com>
    Date: Fri, 11 Nov 2005 23:18:41 +0000
    
    

    On Thu, 2005-11-10 at 22:59 -0800, matthew patton wrote:
    > ok, seems I need to clarify since several people have responded with
    > their bookmark collection of tips, cheats, workarounds, papers, etc.
    > etc. etc.
    >
    > While not having looked at all of them, the point is none of them has
    > bothered to address the basic, out of the box faults of the windows
    > filesystem permissions, nor the culture of permissiveness that
    > permeates all things windows. It's one band-aid after another.
    >
    > LocalSystem isn't 'root'. It's similar in some aspects, but I can trash
    > an NT box by denying LocalSystem permissions to certain files. I can
    > lock out the Administrator likewise. The point is not that there aren't
    > a zillion different guides to living "more safely" with windows. The
    > point is that on a most rudimentary level, when you start with
    > LocalSystem having Full Control over the entire disk and there is NOT
    > ONE reason for it to be that way, you have a situation where security
    > wasn't thought thru. IIS has no business running as LocalSystem for
    > example. It should be fully capable of running as a 'normal' user with
    > maybe a couple of special privs attached. The concept and
    > implementation of 'sudo' has been around for what, more than 10 years?

    Services running as LocalSystem are a security hazard, but the general
    permissiveness of services running as privileged accounts is (although
    particularly bad in windows) not solely a windows problem - many
    services in linux (depending upon the distribution) run as root - on an
    ubuntu linux system, I can see acpid, powernowd, sshd, sdpd, cron, and
    several gdm/X-related processes, all running as root - and this is a
    system on which I've stopped and removed 'unnecessary' services.

    This is something doesn't do particularly well either - there's no
    reason that a process relating to bluetooth (sdpd), really, should be
    running with permissions to load and unload kernel modules, add and
    remove user accounts, access raw block devices, etc.

    Even processes running as their own user (such as dhclient) are still
    running as a user account (dhcp) with permissions allowing them to
    execute arbitrary files on the host in question, a fact which coupled
    with a privilege escalation vulnerability could quite happily yield a
    malicious intruder root access in an instance which could have been
    mitigated by more restrictive permissions on an app, even if the same
    bug (remote code execution) existed.

    You could argue that linux is a step ahead of windows in this respect in
    that the fact that we have a dhcp user, a www-data user, etc, is
    superior to LocalSystem, but progress in adding capabilities to the
    linux kernel to *properly* restrict service accounts (or using DACLs to
    alter the permissions on.. ooh.. the entire filing system) so that my
    DHCP client can't run arbitrary executables from /*/bin seems to be
    exceptionally slow. We're not all running everything as root, but
    without weeks of effort and considerable expertise.

    This can also be no mean feat for anyone who has a distribution which
    doesn't support Linux Access Control Lists or who doesn't know they
    exist - very few linux administrators I've encountered actually use
    these, and without them locking down the filing system is really quite
    hard. If only I had a penny for every group I'd created in accomplishing
    this in the past... ;)

    Again, although windows doesn't do this spectacularly well at the
    moment, this is one issue which Vista seems to be attempting to address:

    Quote from http://tinyurl.com/aww4r (microsoft.com):
    > Windows Service Hardening reduces the damage potential of a
    > compromised service by introducing new concepts which are used by
    > Windows services:
    >
    > Introduction of a per-service security identifier (SID).
    >
    > Moving services from LocalSystem to a lesser privileged account such
    > as LocalService or NetworkService.
    >
    > Stripping of un-necessary Windows privileges on a per-service basis,
    > for example the ability to do debugging.
    >
    > Applying a write-restricted token to the service process. [...] Write
    > attempts to resources which do not explicitly grant the Service SID
    > access will fail.
    >
    > Services are assigned network firewall policy, which prevents network
    > access outside the normal bounds of the service program. The firewall
    > policy is linked directly to per-service security identifier (SID).

    Write-restricted tokens, per-service SIDs, and stripping of privileges
    would all go very far towards addressing the criticisms you've levied.

    > How many of you throw the vendor documentation in the trash and
    > actually make the product run as an unprivileged user? Say Oracle? or
    > ColdFusion, or WEbsphere, BEA, etc? Think about it. You have all these
    > operating system components, 3rd party "daemons", and who knows what
    > all running as the same user. And said user has full control
    > permissions to practically every file on the disk. So what that maybe
    > there are 30% fewer buffer overflows in the unholy number of millions
    > of lines of code. If the filesystem/registry permissions are such that
    > LocalSystem can't do jack, I don't care so much if there are glaring
    > problems. (not to imply I condone sloppy coding)

    Wherever possible, our services run under their own accounts, and
    there's a very simple process (as far as I'm concerned) for vendors who
    are un-cooperative in allowing customers to run their software under
    restricted accounts - not buying their software in future.

    > I have yet to find a guide that actually spelled out the REAL
    > permissions needed for LocalSystem. It needs 'read' to pieces of the
    > %system% tree and 'write' to a couple of files but that's it. Mention
    > to Microsoft that you've wholesale mucked with their "anything goes"
    > permission set and they have a coronary and disavow any notion of
    > support. Why is that? Are they ignorant about what their own product
    > actually needs? Where is the security team that has gone thru and
    > redefined all permissions to what they should be and told the
    > programmers to go back and fix their code?

    Obviously, fixing localsystem isn't the answer, moving to separate user
    accounts is - even if you lock down localsystem to the point at which it
    has no permissions required for your services not to run, your DHCP
    Server still has permissions that your DNS Server requires, your DNS
    Server has permissions required for your IIS Installation, etc.

    > The filesystem is the easy one. I don't have the interest or the time
    > to bother with the registry though in some respects that's probably
    > more important.

     - James.

    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------


  • Next message: Paul Greene: "break in?"

    Relevant Pages

    • RE: Adding AD Account to NT Global
      ... member server in the Windows NT domain. ... Create a group in the Windows Server 2003 domain and add the accounts to ... Windows Server 2003 domain directly to set permissions. ...
      (microsoft.public.windows.server.migration)
    • Re: What server hardening are you doing these days?
      ... permeates all things windows. ... an NT box by denying LocalSystem permissions to certain files. ...
      (Focus-Microsoft)
    • Re: Windows Services
      ... They are accounts, just like your user accounts, but they are somewhat ... LocalSystem exists since Windows NT begin and your kernel and all its ... services used to run as LocalSystem, having full control over your system. ... When a service running as LocalSystem accesses the network, ...
      (microsoft.public.dotnet.general)
    • Re: Install Permission
      ... All of our accounts are Windows NT 4.0 Domain accounts; ... applications is to either make them Domain Admins or to add their Domain accounts to the local Administrators group on their ... Set, View, Change, or Remove Special Permissions for Files and Folders in Windows XP ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Group Policy -- managing user accounts
      ... Create and Configure User Accounts in Windows XP ... Set, View, Change, or Remove File and Folder Permissions in Windows XP ... Description of File Sharing and Permissions in Windows XP ...
      (microsoft.public.windowsxp.security_admin)