Binding Windows Services to Specific Addresses Only

[Christian Koerner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello everybody!

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.

Thanks in advance
    Chris




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIHPGV6rqywW28g1IRAohNAKCQ9vfcx/N5vRr0bbbiBityYayO4wCgottt
+JClyFFafYzq0ojEA0AfS1c=
=2nbF
-----END PGP SIGNATURE-----

[Lou Cipher]

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

Can you please provide more info on what you mean by binding Windows'
services  to a specific address/interface?

Thanks
saqib
http://doctrina.wordpress.com/

[Steve Friedl]

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  |   [phone]
www.unixwiz.net  | Tustin, Calif. USA  | Microsoft MVP | steve@...

[Davies, Alan (GE Money)]

Hi Chris,

You best bet is to start here:

http://www.cisecurity.org/


That'll give you both templates based on best practice and a scoring tool to
sink your teeth into.  There is indeed plenty more you can do, depending on
your environment, to harden Windows systems.

Obviously once deployed, you should also have a patching policy.  AV and
HIDS are good.  Proper change management, build policy, admin restriction,
etc. are the other "soft" bit that keep it the way you designed it.







alan
 

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of Christian Koerner
Sent: 04 May 2008 00:13
To: focus-ms@...
Subject: Binding Windows Services to Specific Addresses Only

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello everybody!

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.

Thanks in advance
    Chris




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIHPGV6rqywW28g1IRAohNAKCQ9vfcx/N5vRr0bbbiBityYayO4wCgottt
+JClyFFafYzq0ojEA0AfS1c=
=2nbF
-----END PGP SIGNATURE-----

[Wayne Anderson-3]

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@... [mailto:listbounce@...] On
Behalf Of Steve Friedl
Sent: Monday, May 05, 2008 9:56 AM
To: Christian Koerner
Cc: focus-ms@...
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  |   [phone]
www.unixwiz.net  | Tustin, Calif. USA  | Microsoft MVP | steve@...

[Maxime Ducharme]

Hello Chris

Look at the services configuration, you often have a "listen on" option

Example : DNS server

By default DNS is listening on all interfaces, you can verify with netstat
Command

netstat -an |find ":53"
UDP 0.0.0.0:53

Go to DNS server's config panel, and set an address to "listen to", let say
It should be bound to the internal address 192.168.25.16

Netstat will then show
UDP 192.168.25.16:53

Other interfaces (like WAN) shouldn’t reply to DNS requests.

Hope that helps

Have a nice day

Maxime Ducharme



-----Message d'origine-----
De : listbounce@... [mailto:listbounce@...] De
la part de Christian Koerner
Envoyé : 3 mai 2008 19:13
À : focus-ms@...
Objet : Binding Windows Services to Specific Addresses Only

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello everybody!

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.

Thanks in advance
    Chris




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIHPGV6rqywW28g1IRAohNAKCQ9vfcx/N5vRr0bbbiBityYayO4wCgottt
+JClyFFafYzq0ojEA0AfS1c=
=2nbF
-----END PGP SIGNATURE-----

[Devin Ganger]

This is a great list, Wayne!

However, I've got one addition for you.

Wayne S. Anderson wrote:

> 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.

<snip>

> 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.

Don't forget that with Windows Server 2003 SP1 and later, the OS includes a great tool for automating a lot of this work for you -- the Security Configuration Wizard. You'll need to go into Add/Remove Programs, Add/Remove Windows Components to ensure that it's installed on the system, but once you do -- it's a great tool that allows you to define and manage security policy for multiple systems.

--
Devin L. Ganger, Exchange MVP      Email: deving@...
3Sharp                             Phone: [phone]
14700 NE 95th Suite 210             Cell: 425.239.2575
Redmond, WA  98052                   Fax: [phone]
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/

[Wayne Anderson-3]

The only thing with using SCW in such a way is that if you are doing
multi-tier web applications, SCW can break things.  Even more so if you are
doing anything with non-default configurations.  

My list was looking more towards principles rather than focusing on the
technical accomplishment of those points.

SCW is an excellent starting point for default services however I would
advise being careful applying it after a custom web application and also
MAKE SURE you have a lab environment or developer test with the SCW
configuration after it is applied.  Build in time in your project schedule,
if applicable, for someone with appropriate experience to troubleshoot.

-W

Wayne S. Anderson

-----Original Message-----
From: Devin Ganger [mailto:DevinG@...]
Sent: Friday, May 09, 2008 11:43 AM
To: wfrazee@...; 'Steve Friedl'; 'Christian Koerner'
Cc: focus-ms@...
Subject: RE: Binding Windows Services to Specific Addresses Only

This is a great list, Wayne!

However, I've got one addition for you.

Wayne S. Anderson wrote:

> 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.

<snip>

> 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.

Don't forget that with Windows Server 2003 SP1 and later, the OS includes a
great tool for automating a lot of this work for you -- the Security
Configuration Wizard. You'll need to go into Add/Remove Programs, Add/Remove
Windows Components to ensure that it's installed on the system, but once you
do -- it's a great tool that allows you to define and manage security policy
for multiple systems.

--
Devin L. Ganger, Exchange MVP      Email: deving@...
3Sharp                             Phone: [phone]
14700 NE 95th Suite 210             Cell: 425.239.2575
Redmond, WA  98052                   Fax: [phone]
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/

[Ken Schaefer]

Can you elaborate on what types of things SCW can break for a "custom web app" or a "multitier app" (as opposed to any other type of app?)

Obviously if you start removing extension mappings, or you disable NTLM, then certain pieces of IIS functionality no longer work. But that's reasonably obvious. What other types of gotchas as there?

Cheers
Ken

> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On Behalf Of Wayne S. Anderson
> Sent: Saturday, 10 May 2008 8:24 AM
> To: 'Devin Ganger'; 'Steve Friedl'; 'Christian Koerner'
> Cc: focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> The only thing with using SCW in such a way is that if you are doing
> multi-tier web applications, SCW can break things.  Even more so if you
> are
> doing anything with non-default configurations.
>
> My list was looking more towards principles rather than focusing on the
> technical accomplishment of those points.
>
> SCW is an excellent starting point for default services however I would
> advise being careful applying it after a custom web application and
> also
> MAKE SURE you have a lab environment or developer test with the SCW
> configuration after it is applied.  Build in time in your project
> schedule,
> if applicable, for someone with appropriate experience to troubleshoot.
>
> -W
>
> Wayne S. Anderson
>
> -----Original Message-----
> From: Devin Ganger [mailto:DevinG@...]
> Sent: Friday, May 09, 2008 11:43 AM
> To: wfrazee@...; 'Steve Friedl'; 'Christian Koerner'
> Cc: focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> This is a great list, Wayne!
>
> However, I've got one addition for you.
>
> Wayne S. Anderson wrote:
>
> > 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.
>
> <snip>
>
> > 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.
>
> Don't forget that with Windows Server 2003 SP1 and later, the OS
> includes a
> great tool for automating a lot of this work for you -- the Security
> Configuration Wizard. You'll need to go into Add/Remove Programs,
> Add/Remove
> Windows Components to ensure that it's installed on the system, but
> once you
> do -- it's a great tool that allows you to define and manage security
> policy
> for multiple systems.

[Wayne Anderson-3]

Localized port proxies, custom service implementations, etc.  E.g.
application with traffic acceptance on a web server hosted on a standardized
port which then subsequently communicates using a non-web communication
stream.

SCW can only anticipate what it KNOWS to look for.  As a result when you are
using custom applications, you have to have an understanding of security
concepts and apply that dynamically to the specifics of your environment.

I have seen SCW break custom and boutique web apps that have secondary
processes which handle other portions of processing or communication for the
overall programmatic system.

Wayne S. Anderson
http://www.linkedin.com/in/wayneanderson

-----Original Message-----
From: listbounce@... [mailto:listbounce@...] On
Behalf Of Ken Schaefer
Sent: Monday, May 12, 2008 9:39 PM
To: focus-ms@...
Subject: RE: Binding Windows Services to Specific Addresses Only

Can you elaborate on what types of things SCW can break for a "custom web
app" or a "multitier app" (as opposed to any other type of app?)

Obviously if you start removing extension mappings, or you disable NTLM,
then certain pieces of IIS functionality no longer work. But that's
reasonably obvious. What other types of gotchas as there?

Cheers
Ken

> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On Behalf Of Wayne S. Anderson
> Sent: Saturday, 10 May 2008 8:24 AM
> To: 'Devin Ganger'; 'Steve Friedl'; 'Christian Koerner'
> Cc: focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> The only thing with using SCW in such a way is that if you are doing
> multi-tier web applications, SCW can break things.  Even more so if you
> are
> doing anything with non-default configurations.
>
> My list was looking more towards principles rather than focusing on the
> technical accomplishment of those points.
>
> SCW is an excellent starting point for default services however I would
> advise being careful applying it after a custom web application and
> also
> MAKE SURE you have a lab environment or developer test with the SCW
> configuration after it is applied.  Build in time in your project
> schedule,
> if applicable, for someone with appropriate experience to troubleshoot.
>
> -W
>
> Wayne S. Anderson
>
> -----Original Message-----
> From: Devin Ganger [mailto:DevinG@...]
> Sent: Friday, May 09, 2008 11:43 AM
> To: wfrazee@...; 'Steve Friedl'; 'Christian Koerner'
> Cc: focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> This is a great list, Wayne!
>
> However, I've got one addition for you.
>
> Wayne S. Anderson wrote:
>
> > 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.
>
> <snip>
>
> > 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.
>
> Don't forget that with Windows Server 2003 SP1 and later, the OS
> includes a
> great tool for automating a lot of this work for you -- the Security
> Configuration Wizard. You'll need to go into Add/Remove Programs,
> Add/Remove
> Windows Components to ensure that it's installed on the system, but
> once you
> do -- it's a great tool that allows you to define and manage security
> policy
> for multiple systems.

[Wayne Anderson-3]

Indeed, there are always steps you needed to take.

As far as my "fancy way of not saying much", I apologize if I was unclear.
I was referring to an instance where the web application I was dealing with
handed off data to a console app which then had to make the communication.
I was trying to make the point that you have to be cognizant of how the
entire application works in a distributed system, preferably working with a
developer to make sure that you have the necessary firewall rules, etc, in
place.

I am certainly not debating the value of SCW but rather simply saying that
the possibility is there and to make sure you don't ascribe it some
"magical" security properties that it will not need to be tested and you can
just assume your application works completely afterwards.

SCW is an excellent tool in the toolbox, make sure when you are implementing
the various methods to secure your hosting architecture, you plan some time
for debug with SCW or any other security implementation, for that matter.

Wayne S. Anderson
http://www.linkedin.com/in/wayneanderson


-----Original Message-----
From: Ken Schaefer [mailto:Ken@...]
Sent: Wednesday, May 21, 2008 12:24 AM
To: wfrazee@...; focus-ms@...
Subject: RE: Binding Windows Services to Specific Addresses Only

Hi,

> Localized port proxies, custom service implementations, etc.  E.g.
> application with traffic acceptance on a web server hosted on a
> standardized port which then subsequently communicates using a
> non-web communication stream.

I'm not sure what this has to do with n-tier web applications. Surely the
necessity of configuring firewall exceptions for non-standard or custom
ports is generic to any application?

Or is there some other part of SCW that was causing the issue?


> I have seen SCW break custom and boutique web apps that have secondary
> processes which handle other portions of processing or communication
> for the overall programmatic system.

This seems to be a fancy way of not saying much (what is an "overall
programmatic system" - an application?). What particular part of SCW was
causing what type of issue here?

Cheers
Ken

> -----Original Message-----
> From: Wayne S. Anderson [mailto:wfrazee@...]
> Sent: Wednesday, 21 May 2008 1:11 PM
> To: Ken Schaefer; focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> Localized port proxies, custom service implementations, etc.  E.g.
> application with traffic acceptance on a web server hosted on a
> standardized
> port which then subsequently communicates using a non-web communication
> stream.
>
> SCW can only anticipate what it KNOWS to look for.  As a result when
> you are
> using custom applications, you have to have an understanding of
> security
> concepts and apply that dynamically to the specifics of your
> environment.
>
> I have seen SCW break custom and boutique web apps that have secondary
> processes which handle other portions of processing or communication
> for the
> overall programmatic system.
>
> Wayne S. Anderson
> http://www.linkedin.com/in/wayneanderson
>
> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On
> Behalf Of Ken Schaefer
> Sent: Monday, May 12, 2008 9:39 PM
> To: focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> Can you elaborate on what types of things SCW can break for a "custom
> web
> app" or a "multitier app" (as opposed to any other type of app?)
>
> Obviously if you start removing extension mappings, or you disable
> NTLM,
> then certain pieces of IIS functionality no longer work. But that's
> reasonably obvious. What other types of gotchas as there?
>
> Cheers
> Ken
>
> > -----Original Message-----
> > From: listbounce@...
> > [mailto:listbounce@...] On Behalf Of Wayne S. Anderson
> > Sent: Saturday, 10 May 2008 8:24 AM
> > To: 'Devin Ganger'; 'Steve Friedl'; 'Christian Koerner'
> > Cc: focus-ms@...
> > Subject: RE: Binding Windows Services to Specific Addresses Only
> >
> > The only thing with using SCW in such a way is that if you are doing
> > multi-tier web applications, SCW can break things.  Even more so if
> you
> > are
> > doing anything with non-default configurations.
> >
> > My list was looking more towards principles rather than focusing on
> the
> > technical accomplishment of those points.
> >
> > SCW is an excellent starting point for default services however I
> would
> > advise being careful applying it after a custom web application and
> > also
> > MAKE SURE you have a lab environment or developer test with the SCW
> > configuration after it is applied.  Build in time in your project
> > schedule,
> > if applicable, for someone with appropriate experience to
> troubleshoot.
> >
> > -W
> >
> > Wayne S. Anderson
> >
> > -----Original Message-----
> > From: Devin Ganger [mailto:DevinG@...]
> > Sent: Friday, May 09, 2008 11:43 AM
> > To: wfrazee@...; 'Steve Friedl'; 'Christian Koerner'
> > Cc: focus-ms@...
> > Subject: RE: Binding Windows Services to Specific Addresses Only
> >
> > This is a great list, Wayne!
> >
> > However, I've got one addition for you.
> >
> > Wayne S. Anderson wrote:
> >
> > > 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.
> >
> > <snip>
> >
> > > 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.
> >
> > Don't forget that with Windows Server 2003 SP1 and later, the OS
> > includes a
> > great tool for automating a lot of this work for you -- the Security
> > Configuration Wizard. You'll need to go into Add/Remove Programs,
> > Add/Remove
> > Windows Components to ensure that it's installed on the system, but
> > once you
> > do -- it's a great tool that allows you to define and manage security
> > policy
> > for multiple systems.

[Wayne Anderson-3]

Absolutely.  

Hence " SCW is an excellent starting point for default services" in my
original post on the subject :)

Any time that you put security measures in place, you need to plan in time
to be able to debug them.  Network flows can be implemented incorrectly,
you could be missing firewall rules at the host or network gateway level,
permissions could be blocking your app from accessing necessary data or
program components, local security policy could be set to prohibit necessary
functionality.

Building in that security debug time is an important step, whether you are
using SCW or any other security tool.  But, absolutely, if you are securing
a windows server environment, you will want to make sure that SCW is in your
security toolbox.

Wayne S. Anderson
http://www.linkedin.com/in/wayneanderson


-----Original Message-----
From: Devin Ganger [mailto:DevinG@...]
Sent: Wednesday, May 21, 2008 1:27 PM
To: wfrazee@...; 'Ken Schaefer'; focus-ms@...
Subject: RE: Binding Windows Services to Specific Addresses Only

All you're arguing for is, "If SCW doesn't have specific XML files for your
applications, be sure to review settings and test before using it in
production." That's great advice no matter which security tools and
methodology you're using, but it doesn't change the fact that SCW is a great
place to *start* in hardening a Windows Server 2003 SP1 + box.

--
Devin L. Ganger, Exchange MVP      Email: deving@...
3Sharp                             Phone: [phone]
14700 NE 95th Suite 210             Cell: 425.239.2575
Redmond, WA  98052                   Fax: [phone]
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/

> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On Behalf Of Wayne S.
> Anderson
> Sent: Tuesday, May 20, 2008 8:11 PM
> To: 'Ken Schaefer'; focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> Localized port proxies, custom service implementations, etc.  E.g.
> application with traffic acceptance on a web server hosted on a
> standardized
> port which then subsequently communicates using a non-web
> communication
> stream.
>
> SCW can only anticipate what it KNOWS to look for.  As a result
> when you are
> using custom applications, you have to have an understanding of
> security
> concepts and apply that dynamically to the specifics of your
> environment.
>
> I have seen SCW break custom and boutique web apps that have
> secondary
> processes which handle other portions of processing or
> communication for the
> overall programmatic system.
>
> Wayne S. Anderson
> http://www.linkedin.com/in/wayneanderson
>
> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On
> Behalf Of Ken Schaefer
> Sent: Monday, May 12, 2008 9:39 PM
> To: focus-ms@...
> Subject: RE: Binding Windows Services to Specific Addresses Only
>
> Can you elaborate on what types of things SCW can break for a
> "custom web
> app" or a "multitier app" (as opposed to any other type of app?)
>
> Obviously if you start removing extension mappings, or you disable
> NTLM,
> then certain pieces of IIS functionality no longer work. But that's
> reasonably obvious. What other types of gotchas as there?
>
> Cheers
> Ken
>
> > -----Original Message-----
> > From: listbounce@...
> > [mailto:listbounce@...] On Behalf Of Wayne S.
> Anderson
> > Sent: Saturday, 10 May 2008 8:24 AM
> > To: 'Devin Ganger'; 'Steve Friedl'; 'Christian Koerner'
> > Cc: focus-ms@...
> > Subject: RE: Binding Windows Services to Specific Addresses Only
> >
> > The only thing with using SCW in such a way is that if you are
> doing
> > multi-tier web applications, SCW can break things.  Even more so
> if you
> > are
> > doing anything with non-default configurations.
> >
> > My list was looking more towards principles rather than focusing
> on the
> > technical accomplishment of those points.
> >
> > SCW is an excellent starting point for default services however I
> would
> > advise being careful applying it after a custom web application
> and
> > also
> > MAKE SURE you have a lab environment or developer test with the
> SCW
> > configuration after it is applied.  Build in time in your project
> > schedule,
> > if applicable, for someone with appropriate experience to
> troubleshoot.
> >
> > -W
> >
> > Wayne S. Anderson
> >
> > -----Original Message-----
> > From: Devin Ganger [mailto:DevinG@...]
> > Sent: Friday, May 09, 2008 11:43 AM
> > To: wfrazee@...; 'Steve Friedl'; 'Christian Koerner'
> > Cc: focus-ms@...
> > Subject: RE: Binding Windows Services to Specific Addresses Only
> >
> > This is a great list, Wayne!
> >
> > However, I've got one addition for you.
> >
> > Wayne S. Anderson wrote:
> >
> > > 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.
> >
> > <snip>
> >
> > > 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.
> >
> > Don't forget that with Windows Server 2003 SP1 and later, the OS
> > includes a
> > great tool for automating a lot of this work for you -- the
> Security
> > Configuration Wizard. You'll need to go into Add/Remove Programs,
> > Add/Remove
> > Windows Components to ensure that it's installed on the system,
> but
> > once you
> > do -- it's a great tool that allows you to define and manage
> security
> > policy
> > for multiple systems.