RE: Binding Windows Services to Specific Addresses Only



Actually, it sort of is possible to do this.

You can use IPSec settings to restrict what is available to communicate
where. Its kind of a poor-mans network firewall without actually using the
firewall service. There have been a few instances where this has been
necessary at places I have worked in the past. In windows Server 2008, with
the firewall service you can actually do this explicitly now using the
advanced firewall settings. An exception can be restricted to an interface
or to a source network segment.

The original posting question is actually quite broad and the entire list of
things you can do to harden a windows machine is frankly HUGE and possibly
even interminable when you consider the possible architectures and
permutations available at the overall system level. There are entire books
and courses on just this subject alone.

That being said, on a per host basis, there are several key steps to take to
begin securing your machine. This list is not exhaustive, this is just my
informal list of key things that I look to do even in low security
environments.

1) Document the server.
This is an oft-overlooked step. If this is a corporate environment, you
should have several key pieces of information for every machine in the
environment. The hardware on the machine. Who owns it. What applications
it serves. The data classification level the machine is intended to
support. Many IT shops simply don't do this but the frank truth of the
matter is that any company should.

If something is compromised, whether you think you are a hacking target or
not or you think you have high value data or not, you need to be able to
quickly return information on what the machine is, what it has, and what was
installed on it in the event of a compromise.

This does not have to be complex! It can be as simple as an excel workbook.
If you have multiple server rooms or data centers, set up a tab for each and
each row is one machine. Simple to use, easy to update. You can host the
workbook on a share or on a SharePoint site. If you have a SharePoint site,
it's even easier because then you can just build a custom list on a
SharePoint site somewhere and you are set. If you are a Lotus Notes shop,
there are options in domino to build such a list as well.

2) Install the minimums. If the server has been re-purposed, start with a
fresh OS install.
Minimizing the attack surface starts with not building in unnecessary stuff
in the first place. I have seen a "guest" base image in a highly
virtualized environment that seemed to have everything and the kitchen sink
in a corporate environment. During an audit, when challenged on this, the
IT folks said that they wanted the swiss army knife already in place so if
they needed a tool, everything was already in a path variable and they could
count on being able to type the same commands on any system being hosted.

Remember that utilities and non-role applications are a double edged sword.
Sure, they may save your IT guy 3 minutes while he doesn't have to put in a
live disk or some kind of utility CD or map a share but is saving those 3
minutes during a support response really worth the increased exposure that
you are placing on the system or giving those added capabilities to an
attacker during the initial compromise?

As an aside, installing Microsoft Office on a server that is not
specifically intended to be the back end of thin clients is stupid. Don't
do it. (I've seen it in multiple environments at several different
customers so it does happen, even with clients who should know better.)

3) Immediately review the service configuration and default accounts.
If you don't need them, disable them, or in the case of services at least
set them to manual so they do not run by default. With Windows default
accounts, make sure that the steps that you can take, you have.

* Disable Guest
* Re-name Administrator, where practical
* Use VERY strong passwords for default accounts
* The length and strength of the admin passwords should be
longer and stronger than your regular user complexity requirements.

With the services, take the most restrictive approach possible. Remember,
if something doesn't start, we can always restart whatever was stopped so
its ok if something now fails to start. We just make the necessary
adjustments and restart it and we know not to stop that particular service
again ;) You ARE building the security for this server while it is in a
build or pre-production stage..... right? You should be able to risk
causing other service failures while you determine what services are
necessary.

4) Make sure your host-installed security clients are installed and
configured correctly.

* Windows Update
* If applicable, does it point to the right WSUS
infrastructure?
* If applicable, does it download automatically and allow
you to manually install?
* Is the install consistent with policy, if applicable?
* Antivirus
* This varies by environment according to the security
architecture of the environment in question.
* If it is supposed to be there, is the client installed?
* Does the client have the correct auto-update settings?
* Is the client pointing at the correct management server,
if applicable?
* Are the correct automatic scans in place, if applicable?
* Host-Based IDS
* Again, varies by environment.
* If it is supposed to be there, is the client installed?
* Is it configured according to the norms of the
environment?
* Firewall Client
* Again, varies by environment.
* If it is supposed to be there, is the client installed?
* Is it configured according to the norms of the
environment?
* If necessary, have you configured the host specific rules
for this server at the firewall level in a centralized design or at the host
level if the rules are host based?
* Are your I/O streams documented somewhere? They should
be.

5) Review local security policy and configuration.
This one would seem straightforward. Have you taken the time to ensure that
the local security policy settings are appropriate to the environment and
that applicable GPOs, if any, are being applied to the system? Did you
ensure that you have secured access to critical places in the file
structure? If only certain kinds of accounts are allowed to have access to
windows/system32, for example, are the appropriate DACLs in place?

Have you specified SACLs to allow specific event auditing on those critical
file structures?

6) Configure the Event Viewer.
Make sure you have adequate space in your logs for events and that you have
configured event expiration appropriately. If you are logging file system
events and logon events, make sure you have the appropriate space for these
entries to be applied to the log. If you are in a Windows Server 2008
environment, have you taken the time to build the subscriptions necessary
for this server's event logs to be collated to your central event database?

If applicable, are the appropriate event monitoring clients installed and
configured correctly? Have you tested it? Did the event show up where it
was supposed to? This is particularly true for environments with SNMP
monitoring or Tivoli or similar centralized systems for server events.

7) Where practical, avoid using the default anything to run an application.
If you are installing a web service in particular, you want to avoid
defaults which can be guessed by an attacker. Use a custom domain account
to own the IIS application pool. If you are running apache on windows, take
the time to actually go through the configuration file and ensure you are
running the minimum required modules. The IIS equivalent in IIS6 and prior
is to make sure you have installed the minimum components possible.

In Windows Server 2008 and IIS7, the default IIS role install has very few
features. Add only the ones you need. You may need to work with the
application developer or the application vendor to ensure that you are
properly supporting the application. In my experience, the developer wants
everything and the kitchen sink to be available to ensure that they can
minimize the number of things they will potentially have to troubleshoot
later. Make it clear that this is not an option.

If there are concerns about ensuring the application runs, enable everything
they want at first, and get the application working. Then start tightening
feature selection item by item until something breaks. Then move on and try
to tighten other items. Done properly, you should help minimize both the
attack surface of the system in terms of installed software, and also the
capabilities that would be available to an attacker which compromises the
web host portion of the server.

8) Limit the access the server has to resources it does not need.
The network configuration for the server should restrict what the server has
access to and where traffic is directed. In cases where the server is
multi-homed, you can use routing rules and either a host based firewall
client or other access control means to limit server access.

* At the switch or router level, restrict in-bound or cross-network
paths which the server's segment does not require access to.
* At the host level, ensure that your default gateway is towards the
"outside". If you are in a complex environment where there are customer
specific networks or specific gateways, the default gateway on the server
should point towards the customer specific gateway, not towards an
infrastructure network or an "inside" enterprise network. Use route rules
to specify exceptions. Recall that default gateway and route rules locally
on the box affect only directions of the network flow, NOT necessarily
access control to services or the box itself.
* If you are using a local firewall, set the lowest permissions
possible. If possible, restrict your network source addresses to only those
that should be allowed access to the service. If, on a middle-tier
application server for example, requests should only originate from certain
web servers and a network segment hosting your engineers, then your
exceptions should be specific and should allow that traffic from only those
segments. Remember to set the appropriate permissions for remote access
applications in use.
* If you are using a remote access methodology, as in most
installations, ensure that you have appropriately secured it. The remote
access method should NEVER be world-accessible, particularly if it is being
hosted on the default port. If you are using a multi-homed box, restrict
the remote access port to the internal LAN access only or internal LAN
sources only, and then anyone outside of the organization who needs to get
to the box should have some capability to VPN in or there should be some
kind of private networking arrangement. If you can get to the box from the
web, so you can your opponent.

9) Security by obscurity is not security.
Changing the default names or settings does not, by itself, apply any kind
of security, it simply makes an attacker do a little more work to compromise
the box with some specific types of attack. Do not fool yourself that you
can rename some things and build a new application pool and call it "good".
You must ALSO secure the box with appropriate permissions and other settings
as discussed. Many companies fall into this trap.

This also applies to any "clever" ideas that the organization might have to
"disguise" a server. In one audit I was party to, I had a client with a
domain controller he had named to use the naming convention of an
application server. Because of this, he felt he did not have to protect it
as well. Within 2 minutes, I showed him 3 or 4 different ways to get the
list of DCs from Active Directory, including the "app" server in question.
Always assume your attacker is smarter than you are, this ensures a healthy
respect for them, and accordingly an serious approach to security.

10) Follow policy.
If your company does not have a security policy, get up, go find the IT
manager responsible for the infrastructure, and kick the chair out from
under them. With all of the news even on CNN and the rest of the public
(dis)information sources out there, there should be no one in IT that is not
aware at some level of the need for information security.

If your company DOES have a policy, make sure that your server is compliant.
This should include a window of time when updates can be applied. A method
of making and documenting changes to the server. Ensuring that at a
technical level, appropriate points on the system are compliant (permissions
are set correctly, necessary programs are installed, etc).

If the system is later compromised, the last thing that you ever want to
have happen is for some other company's lawyer to point out that the system
was not compliant with the company's OWN policy and that it was YOU who
built it. You might as well pack your box and move on before it gets to
that point if you did not follow, to the letter, the policy requirements of
the company or hosting environment.

Hopefully you find this useful, there is a whole lot more I could have
written here but this should be enough to get you started with things to
think about. Maybe some other folks would get value from this post. I
think I will mirror it on my corporate blog at some point.

Feedback welcome.

-W

Wayne S. Anderson

-----Original Message-----
From: listbounce@xxxxxxxxxxxxxxxxx [mailto:listbounce@xxxxxxxxxxxxxxxxx] On
Behalf Of Steve Friedl
Sent: Monday, May 05, 2008 9:56 AM
To: Christian Koerner
Cc: focus-ms@xxxxxxxxxxxxxxxxx
Subject: Re: Binding Windows Services to Specific Addresses Only

On Sun, May 04, 2008 at 01:13:17AM +0200, Christian Koerner wrote:
When it comes to Windows hardening and in specific restricting
Windows' services, the only suggestions that I've found so far are:
*) disable unnecessary services
*) restrict network access through packet filtering

What else can be done and isn't it possible to bind Windows' services
to a specific address/interface, e.g. LAN.

AFAIK, there is no general mechanism to bind services to specific
interfaces or addresses - I know the Services API doesn't have any
such thing. Instead, the application itself must choose to provide a
mechanism for this (which is normally exposed in a GUI or registry entry).

Most don't.

Steve

--
Stephen J Friedl | Security Consultant | UNIX Wizard | +1 714 544-6561
www.unixwiz.net | Tustin, Calif. USA | Microsoft MVP | steve@xxxxxxxxxxx



Relevant Pages

  • Re: Domains & Authentication
    ... different and only you know best - since it is your environment. ... Server' domain by running dcpromo on that machine - and be sure to check the ... format that server and install everything from scratch. ... Application Mode on a Domain Controller. ...
    (microsoft.public.win2000.active_directory)
  • Re: evaluation copy
    ... imagine that upgrading the existing server to SBS would be much more costly ... other thing is, if you like win2k server, how can you not like SBS? ... > time or the money to outlay a TEST environment. ... >>> I have a client who would like to install the eval copy of SBS2003 ...
    (microsoft.public.windows.server.sbs)
  • Re: Restoring Exchange 2000 cluster to "standard" Exchange 2000 En
    ... I did the restore to a server named EX04, ... install of Exchange with the computer named EX04. ... Our previous environment was an environment that wasn't built up using ...
    (microsoft.public.exchange.admin)
  • RE: Deploying WSS 3 in a SPS 2003 environment?
    ... I understand your concern is that you would like to know whether WSS 3.0 and SPS server 2003 can be installed on the same server. ... Deploying WSS 3 in a SPS 2003 environment? ... We would install ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: New Event Log Errors!
    ... Somehow along those lines I'd also installed the Certificate Authority ... Did you apply the last Server Pack for SBS Server? ... Please install Windows Support Tools on the win2k3 sp1 problematic ... Microsoft is providing this information only as a convenience to you: ...
    (microsoft.public.windows.server.sbs)