I sent this to msusec last time. Oops.
--
Joe Budzyn [log in to unmask]
301 Computer Center Ph: (517) 355-4500 x162
Michigan State University
East Lansing, MI 48824
---------- Forwarded message ----------
Date: Wed, 20 Mar 2002 20:25:57 -0500
From: Gordon Williams <[log in to unmask]>
To: Joe Budzyn <[log in to unmask]>
Cc: FredO SECURE <[log in to unmask]>, Gordon MSU <[log in to unmask]>
Subject: Re: null sessions
Joe,
We do not have any domain trust relationships defined at this time.
I asked my son about the significance of 1 vs 2, and here is his
response...
1 simply says anonymous users CAN enumerate the registry,
shares & printers but NOT enumerate usernames.
2 means unless you have permission, I ain't gonna talk
to you.
2 does carry some baggage with it though:
A. An administrator in a trusting domain can not
grant local access to a user in a trusted
domain.
B. Down-level members can't set up a netlogon
secure channel.
C. Down-level domain controllers in a trusting
domain can't set up a netlogon secure channel.
D. Windows NT clients can't change their password
after it expires.
E. Macintosh users can't change their password.
F. The Browser service can't retrieve domain or
server lists from backup/Master/Domain Master
browsers that have RestrictAnonymous set to 2.
He uses 2 without issue (on servers), he says. But if we have a
need for some of the features noted above (A-F), then we may have to
use a value of 1. Perhaps our NT4 servers needed one of these,
whereas the W2K servers got along without it.
I hope this may be of some additional help.
Gordon
-----
Joe Budzyn wrote:
>
> Thanks for the information, it helps. Do you do any inter-domain trust
> relationships?
>
> The registry value for 2000 is 2, and for NT is 1 according to ISS. This may
> explain why you saw lock ups on NT with a value of 2. As far as I know, it
> is undefined.
>
> On Wed, 20 Mar 2002, Gordon Williams wrote:
>
> >
> > Joe,
> >
> > FYI - Fred made this registry change to 6 NT4 servers last Wednesday
> > and to 5 W2K servers (using the registry change, not the method for
> > W2K that you outlined)... except the DWORD value that had been
> > recommended to us was a 2.
> >
> > W2K servers seem to have been okay with this change, but Fred saw
> > lots of lockups on NT4 servers. On Tuesday, he set the NT4 servers
> > to value of 1 (left the W2K servers at 2). The NT4 servers seem to
> > be "happier" with value of 1.
> >
> > I've copied Fred in case he can fill you in more on our 8 days' of
> > experience with this registry change on servers (not workstations).
> > He's the one who has the details (I'm out with pneumonia).
> >
> > I hope this might help you as you consider a more public release.
> >
> > Gordon
> >
> > -----
> > Joe Budzyn wrote:
> > >
> > > Recently there have been several incidents on campus involving someone
> > > enumerating Windows NT and Windows 2000 user lists, determining which users
> > > have administrative privileges, and attempting to guess these users'
> > > passwords. If account lockout is turned on, the server will lock out the
> > > attacked user accounts, resulting in a denial of service. If account lockout
> > > is off, and given enough time, the attacker is likely to gain access to the
> > > server.
> > >
> > > One variant of the attack is to try and guess passwords for all of the users
> > > on the server. Another variant includes attempting to guess the internal
> > > user passwords, including the IUSR_computername account that is used by
> > > IIS. If account lockout is turned on, this may result in the web server
> > > being unable to access the html files.
> > >
> > > To stop outsiders from downloading the entire user list from NT or 2000 servers
> > > null sessions must be turned off. Null sessions allow anonymous connections
> > > to download the user list, NetBIOS shares, and policy information like
> > > when users can log in and what rights they have. My understanding is that
> > > they are not used very often, and may be disabled in most cases.
> > >
> > > Null sessions are used in one-way trust relationships between domains (see
> > > the Microsoft Knowledge Base article Q143474 for more information). They are
> > > also used by certain third party software packages like ARCserve 6.0, and some
> > > very old printing configurations (see Microsoft KB article Q121853).
> > >
> > > To disable Null NetBIOS sessions on Windows NT 4.0.
> > >
> > > 1. The system must be at least on Service Pack 3.
> > > 2. Run Registry Editor (Regedt32.exe).
> > > 3. Go to the following key in the registry:
> > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
> > >
> > > 4. On the Edit menu, click Add Value and use the following entry:
> > > Value Name: RestrictAnonymous
> > > Data Type: REG_DWORD
> > > Value: 1
> > >
> > > 5. Exit the Registry Editor and restart the computer for the change to
> > > take effect.
> > >
> > > To disable Null NetBIOS sessions on Windows 2000:
> > >
> > > 1. From the Start menu, select Programs --> Administrative Tools -->
> > > Local Security Policy.
> > > 2. Under Security Settings, double-click Local Policies,
> > > and then click Security Options.
> > > 3. Double-click Additional restrictions for anonymous connections.
> > > 4. Under Local policy setting, click No access without explicit
> > > anonymous permissions.
> > >
> > > Several people have tried this on their workstations, and did not notice
> > > any problems. I don't know of anyone at MSU who has applied this to
> > > a server yet. Each server administrator will have to weigh the risk of
> > > their user database being attacked with the risk of possibly breaking
> > > certain functionality. Under NT null access may be restored by setting
> > > the value of RestrictAnonymous to 0. Under 2000, simply set the
> > > additional restrictions for anonymous connections local policy back to the
> > > default setting.
> > >
> > > Please review the knowledge base articles, and research null sessions before
> > > making this change. It seems to work, but I really don't know what the
> > > side effects may be.
> > >
> > > I would like to post this procedure to the security web page and the msusec
> > > mailing list in the near future. Any suggestions, comments, or results would
> > > be greatly appreciated.
> > >
> > > --
> > > Joe Budzyn [log in to unmask]
> > > 301 Computer Center Ph: (517) 355-4500 x162
> > > Michigan State University
> > > East Lansing, MI 48824
