Focus on Microsoft
RE: Binding Windows Services to Specific Addresses Only May 22 2008 01:16PM
Wayne S. Anderson (wfrazee wynweb net)
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 (at) adOpenStatic (dot) com [email concealed]]
Sent: Wednesday, May 21, 2008 12:24 AM
To: wfrazee (at) wynweb (dot) net [email concealed]; focus-ms (at) securityfocus (dot) com [email concealed]
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 (at) wynweb (dot) net [email concealed]]
> Sent: Wednesday, 21 May 2008 1:11 PM
> To: Ken Schaefer; focus-ms (at) securityfocus (dot) com [email concealed]
> 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 (at) securityfocus (dot) com [email concealed]
> [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
> Behalf Of Ken Schaefer
> Sent: Monday, May 12, 2008 9:39 PM
> To: focus-ms (at) securityfocus (dot) com [email concealed]
> 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 (at) securityfocus (dot) com [email concealed]
> > [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Wayne S. Anderson
> > Sent: Saturday, 10 May 2008 8:24 AM
> > To: 'Devin Ganger'; 'Steve Friedl'; 'Christian Koerner'
> > Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> > 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 (at) 3sharp (dot) com [email concealed]]
> > Sent: Friday, May 09, 2008 11:43 AM
> > To: wfrazee (at) wynweb (dot) net [email concealed]; 'Steve Friedl'; 'Christian Koerner'
> > Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> > 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.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus