Some Simple Security Steps to secure your NT4 Installation
For the past few years, as you all know, NT has taken a beating in the hacker community in regard to security. This really became evident in early 1997 when a paper was released by Hobbit, of Avian Research on CIFS hacking (CIFS is the Common Internet File System, also known as SMB, or Server Message Block protocol.) CIFS is basically the underlying base architecture of Windows NT networking. Nathan Reynolds
For the past few years, as you all know, NT has taken a beating in the hacker community in regard to security. This really became evident in early 1997 when a paper was released by Hobbit, of Avian Research on CIFS hacking (CIFS is the Common Internet File System, also known as SMB, or Server Message Block protocol.) CIFS is basically the underlying base architecture of Windows NT networking. The UNIX aficionados like to claim that Windows NT is an insecure operating system, based on these exploits. I'm here to tell you that it isn't. NT can be just as secure, if not more so, than it's UNIX cousins.
There are several reasons that some would consider NT to have leg up, over UNIX
1. NT Source Code is not public.
I know, I know, open source fans say that security through obscurity isn't the way to go, and that bugs can be fixed faster with everyone seeing the source code. I don't know about you guys, (and gals) but, I'm not a coder. I don't really have any keen interest in looking at source code for security flaws. There are people who do, and more power to them. In real life, I am another variant of the Systemus Administratus (or more commonly known as the system administrator) And I'm just too gosh darn busy managing all these servers to have time to review code that runs on them. I support operating systems, backend applications, and the like. This takes a good amount of time, more time than I actually have, so I prefer to let someone else write the code, and check it out for me. I subscribe to a good amount of security lists, so chances are, that if an exploit has been released, I'll read about it somewhere. In addition to this, I practice the good practices of port scanning my systems, and using a tool called TCP Netview, which allows me to see what ports are open and by what processes. These are just a few methods I use to ensure the security of my systems, and I employ many other methods to verify the integrity of my systems.
2. Interactive Logon
Many privilege escalation attacks require you to log onto a console, or telnet to a machine, and execute a binary which exploits a hole in the operating system, to gain privileges. By default, UNIX variants (all that I know of) allow all the users to log on interactively to the system. By default NT only allows interactive logon to select few administrative accounts.
However, as we know, NT is not 100% secure. Some of its largest problems stem from the ease of use that Microsoft built into it, and the legacy compatibility for older applications and clients. Legacy clients include Windows 3.11, Windows 95 and 98. You might say Windows 98 can't be a legacy client, it was released after NT 4. Windows 98 doesn't include an authentication package for NTLM, only good ol' LM protocol. LM protocol was originally written by IBM and Microsoft, for IBM LAN Manager, and OS/2.. It's old, doesn't support the necessary encryption algorithms for any decent type of security. LM is a legacy technology, and thus a legacy protocol. The use of this protocol makes the use of decrypting passwords on the wire, relatively easy.
The simplicity of the user interface has attracted tons of amateur system admins. Amateur sys admins generally are also amateur security admins, so the lack of expertise in securing network systems has definitely had its part in the security problems of NT on the Internet worldwide.
So with this in mind, here are a few things you can do to improve your NT system's security
1. Disable access to TCP and UDP ports 135-139 at the network perimeter.
Using a firewall, or a border router, you can create a rules list that does not allow any TCP or UDP traffic coming into your network. These are the ports that NETBIOS uses. Since all remote authentication for NT takes place over NETBIOS, you would want to disallow access to these ports from the outside.
2. Set aggressive account policies
You should a minimum password length, I would use either 7 or 9 and higher. 8 poses a problem in NT4 with the way the system stores the encrypted password hash. Set a lockout threshold for 4 or less login attempts, and require accounts to be locked out until an admin manually unlocks them.
3. Implement passfilt.dll on NT4 systems
Passfilt.dll requires that passwords must be at least 6 characters long, and contain at least 3 of the 4 following criteria: Uppercase Letters (ABCDEFG) Lowercase Letters (abcdefg) Numeric Symbols (1234546) Extended characters ( @#$%%^&*) passfilt.dll must be enabled according to Microsoft Q article Q161990, for more information, see this article on Microsoft's website
4. Enabling Auditing and Logging
At a minimum you should enable Logon and Logoff failure, Use of User Rights Failure, Security Policy Change Success and Failure, User and Group Management Success and Failure, and Failure of File and Object Access.
5. Rename the Admin account
This one will only deter amateur intruders, but a full security plan always includes this one. If you rename this account to something inconspicuous, create a dummy account named Administrator. Enable full auditing on this account, and lock it out. Make sure all authorized personnel know not to use this account, as it is a minor deterrent to an intruder. If nothing else, it might help you catch someone before they notice that the administrator account isn't named Administrator. You should catch this in your event log, if the above conditions are met, you know someone who isn't authorized, is attempting to login as the administrator. An obvious security violation
6. Enable network lockout of the admin account
The NT4 resource kit contains a tool called passprop. Using the "passprop /adminlockout" command, you can enable the administrator account to be locked out, until someone logs on locally with it at the console, and resets the lockout. This can be useful since the administrator account can't be locked out by default. So no matter what your password policy says, if you don't enable this manually, a brute force attempt at your admin account can pretty much be carried out, with the only repercussion being the system logs, and nothing else.
7. Disable LM authentication if you can, only legacy clients need it.
If you haven't any Win 3.1, 95, or 98 clients on your network (you lucky dog) you can disable the use of LM protocol on your NT servers. There is actually a sequence of events that an intruder can exploit, which will cause a client to pass passwords in good 'ol LM encrypted hashes. If you don't need it, don't use it. You can disable LM on an NT server by setting the the registry key HKLM\System\CurrentControlSet\Control\LAS to either 4 or 5. According to Microsoft, this setting only works on Domain Controllers.
8. Enable Syskey
Service pack 3 came with an interesting utility called syskey.exe. Syskey encrypts the local SAM, so that if someone does actually gain access to the SAM file for copying and cracking of the password hashes stored within, it basically renders them completely unable to read the SAM file. You can specify that a password is generated by the system, and stored in the registry, or stored on a floppy disk. You can also specify that a specific password is entered when the machine boots, in order to load the SAM.
9. Protect access to the SAM
Physical access is probably the best way to prevent unauthorized individuals from obtaining access to the SAM. Anyone can pretty much walk up to a machine, cycle the machine with the power switch, and booting to DOS, copy the SAM either from %systemroot%\system32\config, or in %systemroot%\repair. The latter only has the copy from the most recent ERD creation, (only when rdisk was executed with a -s argument)
While these are only a few steps that you could use to increase the security of you networked NT systems, they are a good starting point. This isn't meant to be an entire security plan, just some pointers in the right direction. As always, you should perform rigorous testing before and after you implement these security features. In addition, you should subscribe to various industry security newsletters, I particularly enjoy the ones from securityfocus (www.securityfocus.com) and Microsoft's security advisories (www.microsoft.com/technet/security). And as always keep reading for more security tips from me.