Daily Security Tips from Ed Skoudis - Week of January 20, 2003
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Security Tip for Friday, January 24th, 2003
Don't Forget The Incident Handling Final Report
The last part of computer incident handling is often the most skipped step – final report creation and sign-off. Given the slow wheels of justice, it could take one or two years for a computer incident to go to court for prosecution. If an incident ever goes to court, you'll be very happy you completed a final report describing what happened, summarizing and inventorying your evidence, and explaining the actions you took to stop the attack.
Within a week of returning a system back into production after an incident, the local incident handler should write a draft report. This draft should be distributed to all involved in handling the incident (Operations, HR, Legal, Physical Security, Public Affairs, etc.) for their review. Include a sign off sheet for each individual to acknowledge his or her agreement with the report. If various parties won't sign-off, work to get consensus by modifying the report appropriately and accurately. Most of the time, you'll be able to get consensus pretty quickly. Even if you can't get complete consensus, it's better to know that up-front than years later in a court case!
Security Tip for Thursday, January 23rd, 2003
PAM Is Your Friend
On UNIX systems such as Solaris, Linux, and FreeBSD, use Pluggable
Authentication Modules (PAM) to enforce password length and complexity. PAM can
help you stop users from setting their passwords to easily guessed values.
Beyond password complexity, PAM can be used to integrate other authentication
mechanisms, such as Kerberos or SecurID into a UNIX environment. An enormous
list of highly useful, free authentication modules is located at
http://www.kernel.org/pub/
linux/libs/pam/modules.html.
Security Tip for Wednesday, January 22nd, 2003
Password Length Does Matter
You want your users to select passwords that cannot be easily cracked, right? You worry that your users are selecting dictionary words as passwords. An attacker can crack a dictionary term in less than a minute without breaking a sweat. To prohibit users from selecting passwords that can be easily cracked, it's important to note that password length is often more important in password strength than the character set used. For example, mathematically speaking, it's much harder to crack a 30-character password than it is to crack a 7-character password that uses a bunch of funky characters. Therefore, consider configuring your systems so that passwords have a minimum length of 20 or more characters. To stop your users from revolting, get them to think of passphrases, such as "This is my difficult-to-guess passphrase," (which is very difficult to crack) instead of passwords, such as "p@55w0rd"(which can be cracked in a few days).
Security Tip for Tuesday, January 21st, 2003
Weak Windows Password Hashes Still Plague Us
By default, Windows NT, 2000, and XP store two different representations of each password locally and on servers: the LanMan hash and the NTLM hash. The LanMan hash is stored for backward compatibility all the way back to Microsoft's ancient LanMan product, vintage early 1990's. It's not really needed on a network where only Windows NT, 2000, and XP systems live. The LanMan password representation is extremely weak, and can be easily cracked. No matter how complex and obscure your password is, an attacker can crack it in under a week due to the incredibly feeble encryption used to formulate the LanMan hash.
To significantly improve your security, your best bet is to eliminate the LanMan hashes altogether. On Windows 2000, you can accomplish this by creating the registry key HKEY_LOCAL_MACHINE\System\CurentControlSet\Control\LSA\NoLMHash. On Windows XP, use regedit to create the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\NoLMHash as a "REG_DWORD – Number" and give it the value of 1.
Note that these registry entries only stop the creation of new LanMan hashes when user passwords are changed. Your current LanMan hashes will still hang around until your users select new passwords, which they should be doing when their passwords expire every 90 days or so (you did set a maximum password lifetime, right?). Also, note that these fixes break interoperability with Window 95 and Windows 98 machines.
Security Tip for Monday, January 20th, 2003
Are You Leaking Data Via Windows Null Sessions?
By default on a Windows system, an attacker can grab some seriously interesting information using a Null session. As its name implies, a Null session has a blank user name and password. Null sessions are supported by Windows to implement "Network Neighborhood" browsing and other functions, but could be very dangerous. They attract unwanted attention, give out file share information, and can be used to retrieve user names for a brute force password guessing attack. By default on some Windows NT systems, they can even be used to retrieve security configuration information!
On Windows NT, 2000, and XP, you can limit the data given out through Null sessions by setting the registry key HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous to a value of 1. Furthermore, on Windows 2000 and XP, you could even set this key to a value of 2 to eliminate nearly all data that can be gotten via a null session. However, the value 2 could break many services, and should be tested in a Quality Assurance environment before being rolled into production.