Is .NET Server Really "Trustworthy"?
Date: May 1, 2002
Article is provided courtesy of Sams.
What's hot these days in the tech industry? Well, Microsoft's .NET initiative, and, of course, security. Bill Gates and Microsoft Corporation have considerable interest in assuring consumers that Microsoft Windows is a secure platform, and that Microsoft is doing everything possible to enhance security in Microsoft products. Of course, as InfoWorld points out, "In the world of IT, giggling usually follows mention of 'Microsoft' and 'security' in the same sentence. That may change, however, following the release of a whitepaper by independent security consultancy Foundstone, in Irvine, Calif., on the security of Microsoft's .Net Framework." (Check out the whitepaper by Foundstone, Inc., an independent security assessment firm that logged more than 2,800 hours reviewing the security architecture of Microsoft .NET Framework.)
With the release of each new version of Windows server operating system, you justifiably expect the security to be enhanced over the previous version. Windows .NET is no exception. This article examines the security updates to Windows .NET Server. The security improvements discussed in this article are based on Windows .NET beta 3. Of course, don't be too surprised if Microsoft decides to add or remove some of these features by the time the product is released. After all, .NET Server is still in beta phase; based on previous experiences, some of the code may change in the released version.
Let's begin by looking at some of the areas on which Microsoft is focusing in Windows .NET Server. This is by no means a complete listing of all the security changes, but this overview will give you a pretty good idea of the direction in which Microsoft is headed.
Blank Passwords
One of the new features allows administrators to restrict remote users from logging on with blank passwords. Users are allowed to log on locally with accounts that have a blank password, but since they're not connected to the domain at that time, they're not exposed to attacks from the Internet. In other words, remote users won't be able to connect to Windows .NET servers using accounts that have a blank password. As anyone who's worked in an IT department knows well, if you permit users to have blank passwords for their accounts, a lot of users will prefer to use blank passwords. Why? Well, it sure beats looking for the password on a Post-it note on the side of the monitor, or under the keyboard. With .NET servers, your company will be protected from Internet attacks even if the local administrator accounts on your workstations are left blank; users will only be allowed to log on locally if they're using accounts that have blank passwords. This behavior is enabled by default in beta 3.
Internet Information Services (IIS) 6.0 Changes
In Windows 2000 Server, IIS installs just about all the components by default. With Web services being a major source of virus and other attacks from the outside world, Microsoft decided to tighten the security in Windows .NET Server. It doesn't install any additional add-ons by default. In fact, by default there isn't any support for Active Server Pages (ASP) either; only static HTML pages are supported.
Another nice feature is that when you first run the IIS Management Console, the IIS 6.0 Security Lockdown Wizard gives you the option to enable only the extensions that you want. Microsoft clearly had a new mindset when they designed .NET services, and security is definitely a major area of interest. The default IIS configuration in a .NET server is much more secure than its predecessor.
Command-Line Tools
Another new feature is the ability to manage user credentials from a command-line tool. This allows administrators to use scripts to add usernames and passwords. The use of command-line tools could be essential for system administrators who manage large enterprises. In addition, several other command-line tools are available, such as takeown.exe, which allows administrators to take ownership of orphaned files, and xcacls.exe, which is an extensive Access Control List (ACL) editor.
Prevention of Buffer Overruns
The problem of buffer overruns is a major security challenge today. Hackers have been exploiting buffer overruns for years. For example, in November, 2000, there was a known vulnerability in Microsoft's Network Monitor (NetMon) in which a buffer overrun could cause some serious security problems. If someone sent malformed data on the segment where the administrator was monitoring the network using NetMon, it could cause a buffer overrun. In some cases, it could simply fail NetMon, which is not a big deal, as you could simply restart NetMon. However, in other cases, it could have resulted in running the sender's code on the administrator's computer, in the administrator's security context. Obviously, this could be disastrous. Microsoft released a security patch to fix the problem.
In Windows .NET, Microsoft decided to implement buffer overrun checking in the Visual C compiler used for Windows .NET. In addition, they've also taken other steps to analyze the code for buffer overruns. With these precautionary measures, hopefully Windows .NET servers will be less vulnerable to buffer overrun attacks.
Support for Newer Hash Algorithms
Under the Information Technology Management Reform Act (Public Law 104-106), the U.S. Secretary of Commerce is responsible for approving the guidelines that are developed by the National Institute of Standards and Technology (NIST) for Federal computer systems. These guidelines are issued as Federal Information Processing Standards (FIPS) for government use. However, NIST may develop and publish FIPS when the government feels that there are requirements, such as security, for which there are no acceptable industry standards. NIST has developed new FIPS standards that improve digital security. For example, FIPS 186-2 specifies a newer Digital Signature Standard (DSS) that specifies algorithms appropriate for applications requiring a digital, rather than written, signature. Windows .NET servers will support the new NIST hash algorithms to enhance security. As we move from beta 3 and beyond, we will have to wait and see exactly which hash algorithms will be supported in the final release, but Microsoft seems to be committed to using the newer algorithm standards to keep up with today's security challenges.
Fewer Services on the Menu
Compared to Windows NT, Windows 2000 Server includes far more services that are installed and started by defaultespecially on domain controllers. On one standard Windows 2000 domain controller, I counted 65 services that were running. An additional 24 services were installed but were not started. That's a large number of services installed on one domain controller! Microsoft has warned us for years to eliminate unneeded services and protocols to secure the servers. Needless to say, this huge number of services is a serious security concern for most organizations because hackers can exploit these services. As a result, Microsoft has made several changes to the security model.
First, services.exe will no longer contain any code that's not related to security. In addition, Microsoft has announced that they will be reducing the number of services that are running by default in Windows .NET servers. By some accounts, compared to Windows 2000 there will be as many as 20 fewer services running on Windows .NET servers.
Another step toward securing the services and the way they operate has to do with how much privilege each service has. Today, most services run under a built-in privileged service account known as local system. This account has pretty much all the administrative privileges. Users cannot log on as this account, but this service account has complete control over your computer. If intruders gain access to this account, they can wreak havoc not only on your computer, but potentially on the entire network.
The service account philosophy has changed in .NET Server. Now we will have two service accounts: a local service account and a network service account. Most services will run under the credentials of one of these two service accounts. The local service account will be limited to the local computer and won't have any access to the network. The network service account will be able to interact with the network using the computer's machine account credentials. This model will offer improved security and give administrators more control over the services running on the network.
IP Security Enhancements
There are several new updates related to IP Security (IPSec). The integration of Network Load Balancing (NLB) and IPSec-based Virtual Private Networks allows administrators to offer better security, along with faster IPSec failover and the reliability that comes with NLB.
In Windows 2000, clients can create a PPTP tunnel through a Network Address Translation (NAT) server. In other words, PPTP clients can establish a virtual private network connection from a client to a PPTP server on the Internet going through a local NAT server. However, you can't use L2TP with IPSec because IPSec packets can't be translated by the NAT server. You can create an IPSec tunnel from a NAT server to another computer on the Internet, but not through the NAT server. In Windows .NET Server, an L2TP or IPSec client now has the ability to pass through the NAT server. In addition, hardware vendors will be able to utilize new IPSec hardware acceleration functionality that will allow them to update their old hardware to meet the new standards. In Windows .NET, IPSec supports NAT hardware acceleration for both the Encapsulation Security Payload (ESP) and Authentication Header (AH) packets.
Microsoft has also increased support for the stronger 128-bit Internet Key Exchange (IKE) keys in IPSec. Now, when you establish IPSec tunnels, say between a remote branch office and corporate headquarters, you can benefit from this higher-level 128-bit security. This added security can be useful even on your internal LAN servers, say between your domain controller and the finance department server that holds company confidential information. The 128-bit IKE will result in providing a 3072-bit Diffie-Hellman key generation, resulting in increased security.
Encrypting File System (EFS) Support
Microsoft added support for the encrypting file system (EFS) in Windows 2000. The EFS feature allows users to transparently encrypt files or folders to protect their confidential data. Let's examine a couple of major areas of EFS where the security has been enhanced:
The first one has to do with how encrypted files behave when they are saved on a network server. In Windows 2000, when a user opens a file that's located on the server, it's decrypted so the user can read it. When the user saves the file, it is re-encrypted. However, while the data travels between the client's computer and the server, it's not encrypted. In other words, someone running a NetMon or a sniffer can potentially capture and read the data. This behavior has been changed in Windows .NET; the data traveling across the wire is now encrypted. (Makes you wonder, thoughwhy didn't they implement this feature before?)
The second cool feature has to do with sharing encrypted files. Now you can finally share your encrypted files with other members of your group. The advantage here is that you can share confidential files with other users, either over a public network or over a LAN.
Conclusion
In an internal memo sent out to Microsoft employees on January 15, 2002, Bill Gates talked about the "Trustworthy Computing" initiative. Some people find it humorous that large corporations label these marketing bulletins, which are leaked out to press intentionally, as internal memos. But seriously, the folks at Microsoft are taking this Trustworthy Computing initiative very seriously. As Gates points out, "Over the last year it has become clear that ensuring .NET is a platform for Trustworthy Computing is more important than any other part of our work. If we don't do this, people simply won't be willingor ableto take advantage of all the other great work we do. Trustworthy Computing is the highest priority for all the work we are doing. We must lead the industry to a whole new level of Trustworthiness in computing."
The security enhancements in Windows .NET framework are a major step in this new focus on security. Even Microsoft's critics are applauding their efforts and are impressed with the security improvements in Windows .NET Server. However, before we get too excited, we need to realize that so far we've only looked at the beta code. Although the overall security in Windows .NET Server looks promising, at this stage it's still too early to predict how Microsoft will handle the integration of its .NET infrastructure security with other vendors, or even its own legacy systems. Let's keep our fingers crossed and hope for the best.