Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: What server hardening are you doing these days?
From: James Eaton-Lee (james.mailinggmail.com)
Date: Fri Nov 11 2005 - 17:18:41 CST
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.