RE: [RE: Access to well-known ports on Win2K]

From: Roberta Bragg (freouwebbe@msn.com)
Date: 11/04/02


From: "Roberta Bragg" <freouwebbe@msn.com>
To: "'Scott Mulcahy'" <scottcm@usa.net>, <focus-ms@securityfocus.com>
Date: Mon, 4 Nov 2002 12:42:39 -0600

Ah, perhaps I am the perpetrator of thread drift (or drifting consciousness
whichever you prefer). It was unintentional, and I stand corrected. Thank
you for bringing it back to the original request. When responding, I should
have done so as well. I was making an assumption about access control, and
thinking of inbound access to w2k - the destination port from the
perspective of the w2k. For outbound communication the filter, of course
could be written to only allow outbound communication using a specific
destination port and ANY source port. ANY if left to the normal
communications process would mean the use of ports above 1024, however,
perhaps a crafted packet could potentially use ANY port, including those
below.

> -----Original Message-----
> From: Scott Mulcahy [mailto:scottcm@usa.net]
> Sent: Monday, November 04, 2002 12:08 PM
> To: freouwebbe@msn.com; 'Scott Mulcahy'; focus-ms@securityfocus.com
> Subject: Re: [RE: Access to well-known ports on Win2K]
>
>
> I'm a bit surprised by your confusion on this topic.
>
> >> You do not need to create 1024 filters; you creat one
> which 'blocks all'
> then create one for each one you wish to allow.
> <<
>
> Normally you would use specific permits and block all else.
> If you had read
> what the original poster wanted, you would know that the
> request was for only
> admins to be able to use ANY port above 1024. This makes
> sense since client
> communication typically uses the ephemeral port range. So
> unless you intend
> to create 64,411 permit filters to allow every port above
> 1024, you'll need to
> create 1024 ports to block ports 0 - 1023.
>
> -------------------------------------
> "Roberta Bragg" <freouwebbe@msn.com> wrote:
> Additional Information:
>
> TCP/IP filtering allows you to 'only' allow certain ports -
> that's blocking
> access and thats what was asked about.
>
>
> IPSEc does not provide security at the user level; its a
> machine level
> policy - works for all users of the machine; and can allow
> or block access
> according to IP address of accessing machine (to be user
> level policy, it
> would have to be able to be configured to work for a specific
> user account,
> and it cannot be)
>
>
> You do not need to create 1024 filters; you creat one which
> 'blocks all'
> then create one for each one you wish to allow.
>
> again: the policy is based on the machine; so would not
> matter if user
> logged onto domain,
>
> many routes for deployment as you mention: Group Policy;
> Local Security
> Policy; property pages of network connection; script or batch file
>
> all security is only good if its applied, as you say.
>
>
> Solaris or W2K, if a user can change the security policy
> then its not going
> to be an effective security policy.
>
> > -----Original Message-----
> > From: Scott Mulcahy [mailto:scottcm@usa.net]
> > Sent: Friday, November 01, 2002 12:53 PM
> > To: focus-ms@securityfocus.com
> > Subject: RE: Access to well-known ports on Win2K
> >
> >
> > TCP/IP Filtering does not provide port level security at the
> > user level. You
> > could use an IPSec policy and deploy to all users to block
> > source ports below
> > 1024. Then have a subset of those users in a different OU
> > and assign that OU
> > a policy that permits all ports.
> >
> > There's a couple of potential problems, though. 1) You need
> > to create 1024
> > selectors for TCP (or as MS calls them filters): 1 for each
> > port. The good
> > news is you'd only have to do this once. 2) If the user is
> > able to stop the
> > IPSec Policy Agent service then the IPSec policy is no
> longer active.
> >
> > This approach has the same limitation as applying any
> > security using GPO's:
> > Problems can occur and a GPO may not get applied, if a user
> > doesn't log in
> > using AD credentials they won't get the GPO, etc.
> > Alternatively, you could
> > apply IPSec as a local security policy but management of the
> > policy just got
> > much more difficult. You would also need to make sure that
> > the user doesn't
> > have the ability to modify the IPSec policy in this case.
> >
> > Quite simply, W2K, XP, .NET have the ability to do what you
> > ask but it's not
> > as simple as Solaris. On the positive side, if you go with
> a GPO then
> > deployment is fairly simple.
> >
> > Good luck,
> > Scott
> >
> > -----Original Message-----
> > From: Roberta Bragg [mailto:freouwebbe@msn.com]
> > Sent: Thursday, October 31, 2002 4:17 PM
> > To: 'Rangan, Govindaraj'; focus-ms@securityfocus.com
> > Subject: RE: Access to well-known ports on Win2K
> >
> >
> > Several well know methods for restricting port access exist
> > in WIndows 2000,
> > XP and .NET.
> >
> > Take a look at TCP/IP filtering and IPSec policies (IPSec
> > policies can be
> > written to filter port access, as well as for encrypting
> > data in flight)
> >
> > The Remote Access service can also be configured to provide
> > this type of
> > access control -
> >
> > None of these services require xtra purchases, downloads or
> > other activity -
> > they are built into the operationg system, just require
> > configuration as
> > does Solaris --
> >
> > > -----Original Message-----
> > > From: Rangan, Govindaraj [mailto:govindr@ti.com]
> > > Sent: Wednesday, October 30, 2002 10:59 PM
> > > To: 'focus-ms@securityfocus.com'
> > > Subject: RE: Access to well-known ports on Win2K
> > >
> > >
> > > Hi All,
> > > Greetings.
> > > Do all users on Win2K have access to the
> > > well-known ports? This
> > > question arose when I was doing some security tests in a
> > heterogeneous
> > > environment with Windows and Solaris boxes. Solaris RSHD's
> > > only security is
> > > that before allowing access, it checks the source host and
> > > source tcp port.
> > > The host should be in hosts.equiv or .rhosts and the source
> > > tcp port should
> > > be one of well known ports (0-1023). The rsh client is a
> > > setuid script and
> > > starts as root. However on Windows 2000, it is possible for
> > > any user (not
> > > necessarily an admin user) to open a "well known port" to
> > > connect to any
> > > rshd.
> > > Can we restrict access to well known ports to a
> > > certain user or
> > > group? If not, the secure way is that Solaris hosts shouldn't
> > > trust Windows
> > > hosts. Your help in resolving this is highly appreciated.
> > >
> > > Regards,
> > > Govind
> > >
> >
> >
>
>
>
>



Relevant Pages

  • RE: Access to well-known ports on Win2K
    ... IPSEc does not provide security at the user level; ... policy - works for all users of the machine; and can allow or block access ... many routes for deployment as you mention: Group Policy; Local Security ... > TCP/IP Filtering does not provide port level security at the ...
    (Focus-Microsoft)
  • Re: [RE: Access to well-known ports on Win2K]
    ... communication typically uses the ephemeral port range. ... policy - works for all users of the machine; and can allow or block access ... many routes for deployment as you mention: Group Policy; Local Security ... > IPSec Policy Agent service then the IPSec policy is no longer active. ...
    (Focus-Microsoft)
  • RE: Access to well-known ports on Win2K
    ... TCP/IP Filtering does not provide port level security at the user level. ... IPSec Policy Agent service then the IPSec policy is no longer active. ... This approach has the same limitation as applying any security using GPO's: ...
    (Focus-Microsoft)
  • Re: IPSec filter to allow only sending e-mail
    ... Any Ip [or smpt server] ... >From any port to port 25. ... I think your policy may be backwards. ... > I have web server secured by IPsec policy that allowed only port 80 and ...
    (microsoft.public.win2000.security)
  • Re: How can I block port 1025?
    ... Is each machine configured individually or do they have the same policy applied via ... The port shows ... > closed on all of my other machines, ... > using the same IPSEC policy on each of my machines. ...
    (microsoft.public.win2000.security)