Computer security

It can. Memory pages are swapped or paged to disk when an application needs physical memory. Even though the page file (see Control Panel->System->Performance->Virtual Memory) is not accessible while the system is running, it can be accessed by, for example, booting another OS.

There is a registry key that can be created so that the memory manager clears the page file when the system goes down:

HKLMSYSTEMCurrentControlSetControlSession ManagerMemoryManagementClearPageFileAtShutdown: 1

Note that the clearing of the page file only is done when the system is brought down in a controlled fashion. If the machine is just switched off or brought down in any other brute way, of course no clearing will be performed.

Normally, the netstat program should report information on the status of the networking connections, routing information, etc. With the option -A or -a, it should list all TCP and UDP available connections and servers that are accepting connection. On Windows NT, even though the documentation states otherwise, this is not the case.

There are no simple way to check what services that are running with TCP ports opened to accept connections. Currently the only way to get some information about this is to use a port scanner program and test through each TCP port on the NT machine. This is not a fool proof way of dealing with the problem.

This is a serious problem if you plan to have NT based computers in the firewall environment. You cannot easily hardened them to become bastion hosts, since you are not confident what types of network services that might be reachable from the outside.

It is a confirmed bug in Windows NT 3.5, 3.51 and 4.0. I do not expect Microsoft to fix it soon enough.

Update:

netstat.exe is fixed as of NT4 SP3, but it still shows some strange behavior. For example, on a moderately loaded machine, you can find numerous duplicates of open connections. Why is that?

A NULL session connection, also known as Anonymous Logon, is a way of letting a not logged on user to retrieve information such as user names and shares over the network. It is used by applications such as explorer.exe to enumerate shares on remote servers. The sad part is that it lets non-authorized users to do more than that. Particularly interesting is remote registry access, where the NULL session user has the same permissions as built-in group Everyone.

With SP3 for NT4.0 or a fix for NT3.51, a system administrator can restrict the NULL session access, see $$$: Q143474. With this fix, a new well-known SID is defined, named "Authenticated Users", which is Everyone except NULL session connected users. Replacing Everyone in all ACLs on the machine with this Authenticated User would be a good thing. To do this in a controlled fashion, one can use cacls.exe for the file system, but have to rely on some third party product for the registry ACLs. Using explorer.exe/winfile.exe or regedt32.exe will most certainly break the system. The cause for this is that these tools replace the ACL instead of editing it.

There is known problems with the FTP server that ships with Windows NT. There is another FTP server that comes with the Internet Information Server, IIS, that is supposedly more secure.

As stated elsewhere in this document, logging is not turned on by default. To turn on logging of the FTP server, there are a number of registry key parameters that can be changed. They are located under the following key

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesFtpSvcParameters

Some of the parameters are LogAnonymous, LogFileAccess, LogNonAnonymous.

See Microsoft's articles on how to turn on * Better logging in the FTP server. * Accessing the root directory. * Access Rights for Anonymous Users of FTP Server * LogAnonymous Does Not Always Make an Entry in System Log

By default, all auditing in Windows NT is turned off. You have to manually turn on auditing on whatever object you want audited. First off, you should have a policy for

* what to log (user behaviors, changes on files or processes)

* for how long to keep the logs

* whether or not you should turn on auditing on all your machines, or if you only turn on logging on the servers

Then you should configure the auditing. You should also remember that it is hard to have a good use of auditing (or any use at all), if you don't have good tools and a good suite of policies on how to handle the logs.

You have to remember that cranking up auditing might give you performance degradation. The trick is to find the balance between how much to log without getting problem.

Remember that Windows NT saves the logs locally on disk. If someone can take control over the machine, it is quite likely that the logs might be manipulated as well. A better solution might be to send away the logs to one or more protected, centralized log-servers.

* Who knows the passwords for systems that perform critical business functions?

* Do we regularly change passwords on critical systems?

* Do we require end users to change their passwords? How often?

* Do we educate end users about good password choices? (e.g. avoid family names and dates, use a password longer than 6 characters, don’t use words found in dictionaries, include numerals in the password).

* Do we discourage sharing of user names and passwords among multiple people?

* Do we provide tools to help people choose strong passwords? (Note: some system administrators use automated tools to scan the user database or password file for easily-guessed passwords.)

* Do our systems “lock out” an account after a pre-determined number of failed login attempts?

* How do we manage which people have privileged access to our systems? Do we periodically review which people have “root” or “superuser” or “administrative” privileges on systems? Do we have a procedure to remove privileges for employees who have left the university? Do we remove privileged access when an employee no longer needs it?

* Do we ensure that in case of emergency someone will have passwords for critical systems (for instance, if the primary system administrator is unavailable).

* • How often do we apply vendor updates operating system software? Office productivity software? Other software?

* When we update computers, do you have to physically visit each computer, or do you use centralized management tools (e.g. SUS for Windows)?

* Do we set up computers for automated scheduled software updates?

* Suppose that major media are reporting that Microsoft has released a patch to close a major vulnerability in Windows. We need to update all our Windows computers immediately.

o How would we rapidly communicate with all users in the department?

o How long will it take us to complete this task for the 100 computers in our department?

o What about patching laptop computers our users have off-site?

o Should our users power down their computers or unplug them from the network until we can do this update?

* • Do we allow end users to install operating system patches (e.g. Windows Update)? Do we allow end users to install applications software?

# Have we educated our users about the risks of using wireless (Wi-Fi) networks, especially on unsecured open networks (e.g. public spaces such as at many hotels and coffee shops)?

# Do we encourage use of encryption above network layer such as SSL or Virtual Private Networks (VPN)?

# Do we operate Wi-Fi access points in our unit? If so:

o Have we turned off the broadcasting of SSIDs?

o Do we require an encryption key (WEP or WPA) to use our access points?

------ How do we manage the passphrase?

------ Do we enforce periodic changes to passphrase

? o Whom do we let connect to our access point(s)

•------ Just people in our department? Guests? Anyone

? o How do we monitor activity over our wireless access points?

* Assume this scenario: The network security staff at the Computer Center just informed me that a computer in our department is infected with the ReallyBig virus. It is disrupting network performance, sending out thousands of infected emails, and serving first run movies to pirate worldwide.

o What do we do immediately? Would we remove the compromised system from the network?

o What sort of investigation would we carry out to determine the nature of the attack, and what vulnerability was exploited, and what data may have been compromised?

o How would you restore this computer to normal operation? .. Do you intend to disinfect it, or format the hard drive and reinstall operating system and software (perhaps from “ghost” image)?

* Do we regularly monitor event logs on servers, other computers, and firewalls to look for patterns of attack? Are the logs available after an attack?

Unfortunately, there's a lot to worry about. There are security risks that affect Web servers, the local area networks that host Web sites, and even innocent users of Web browsers.

The risks are most severe from the Webmaster's perspective. The moment you install a Web server at your site, you've opened a window into your local network that the entire Internet can peer through. Most visitors are content to window shop, but a few will try to to peek at things you don't intend for public consumption. Others, not content with looking without touching, will attempt to force the window open and crawl in. The results can range from the merely embarassing, for instance the discovery one morning that your site's home page has been replaced by an obscene parody, to the damaging, for example the theft of your entire database of customer information.

It's a maxim in system security circles that buggy software opens up security holes. It's a maxim in software development circles that large, complex programs contain bugs. Unfortunately, Web servers are large, complex programs that can (and in some cases have been proven to) contain security holes. Furthermore, the open architecture of Web servers allows arbitrary CGI scripts to be executed on the server's side of the connection in response to remote requests. Any CGI script installed at your site may contain bugs, and every such bug is a potential security hole.

From the point of view of the network administrator, a Web server represents yet another potential hole in your local network's security. The general goal of network security is to keep strangers out. Yet the point of a Web site is to provide the world with controlled access to your network. Drawing the line can be difficult. A poorly configured Web server can punch a hole in the most carefully designed firewall system. A poorly configured firewall can make a Web site impossible to use. Things get particularly complicated in an intranet environment, where the Web server must typically be configured to recognize and authenticate various groups of users, each with distinct access privileges.

To the end-user, Web surfing feels both safe and anonymous. It's not. Active content, such as ActiveX controls and Java applets, introduces the possibility that Web browsing will introduce viruses or other malicious software into the user's system. Active content also has implications for the network administrator, insofar as Web browsers provide a pathway for malicious software to bypass the firewall system and enter the local area network. Even without active content, the very act of browsing leaves an electronic record of the user's surfing history, from which unscrupulous individuals can reconstruct a very accurate profile of the user's tastes and habits.

Finally, both end-users and Web administrators need to worry about the confidentiality of the data transmitted across the Web. The TCP/IP protocol was not designed with security in mind; hence it is vulnerable to network eavesdropping. When confidential documents are transmitted from the Web server to the browser, or when the end-user sends private information back to the server inside a fill-out form, someone may be listening in.