TechNet Top Questions - November 8, 1999

Greetings! Here we provide detailed answers to popular questions submitted to TechNet via the answer forums and feedback alias. TechNet's Lon Collins, Microsoft Support Professional, provides you with answers and tips that can help many of you working in the trenches to deploy, maintain and support Microsoft products.

This Week:

On This Page

Windows NT Security

Setup for SQL Server 7.0 will not work

Where did the files go?

Windows NT Security

This first topic starts out as a typical "top question" issue on something that is (or should) be on every network administrator's mind: Security. Security threats can come from external sources "out there on the Web" or from a co-worker on the other side of the cube wall. Just as with a Database Administrator, one of the most important responsibilities of the Network Administrator is protecting his or her company's computing and information assets. It could be summed up as "covering your assets." Then again, maybe not.

The question comes in from IT Pro Thomas Harris:
Can anyone recommend methods/applications for tracing a cracker back to his/her source using info captured in NT Event Log? Or do I need to use Network Monitor & see if they make another attempt?

A response from frequent Answer Forum contributor Phil Renouf was:
What I would do as soon as you find your system has been compromised is make sure you have an exact duplicate of the hacked system. If you can take the server down and ghost the drive to a backup drive then bring the server back up, either in the same condition, or rebuilt (depending on if you want to alert the hacker you're on to him or not), that way you have an exact copy of the drive the way it was for use as evidence or in tracking the hackers.

As for tracking them, I have never had to do such a thing, but gather up as much information as you can from event logs, firewall logs, or anything else you can muster up. Track down IP's (who owns them, what OS they are running, is it a dial-up or dedicated machine? etc.) once you build a map of where they came from you can use that to contact their ISP or employer, the Police, or even their Upstream provider.

Like I said at the beginning, I am not a computer forensics expert, but be extremely careful and track down every single connection in the time period of the hack, eliminate them one by one to make your job easier.

Anyone else have some experience in this area? I too would be interested in some methods of prevention (tripwire etc.) as well as how some people have gone about tracking down a hacker.

Nathan Stovall also responded and suggests
One thing you can try is to run network monitor (or another tool) to capture packets, and root around for the IP address. These days they are probably using a cable modem, and have a static IP address. The main thing is to make a link on the times of your alerts, to the IP addresses captured in that time frameU

Thanks to Phil and Nathan for their responses. Here's my $0.02 worth. From everything that I can dig up, if the needed security logging and monitoring has not been implemented before a break-in, it is exceedingly difficult to track down the culprit after the break-in has been detected. As the old saying goes "The best offense is a good defense." Taking the time to properly plan, test and then implement your network security will reduce the need to play Sherlock Holmes and try to track down the bad guy. With the ability to spoof IP addresses, it is very difficult to track down the actual person committing the break-in. You need to gather some evidence to start with. Some of the sites listed below provide information that you can use to track break-in attempts.

First, let's start with some information from Microsoft's Security Web site. There is a great deal of information here, ranging from introductory information on security, security white papers, security guidelines, Product Security Notification Services (a free e-mail notification service), a list of security related books, seminar information, and, of course, a lot more. I suggest that you visit the Web site and take a look around.

One item that Phil Renouf is curious about is "methods of prevention (tripwire etc.)" This would fall under the category of "Intrusion Detection". A network-based intrusion detection system monitors network traffic and responds with an alarm when it identifies a traffic pattern that it deems to be either a scanning attempt or a denial of service or other attack. "Intrusion Detection" is a key phrase that you can use when searching for papers or products that address this area of security.

Here are a few resources that you can research for information on Windows NT© (and network in general) security.

SANS Institute

The SANS (System Administration, Networking, and Security) Institute is a cooperative research and education organization through which more than 62,000 system administrators, security professionals, and network administrators share the lessons they are learning and find solutions for challenges they face.

The SANS Institute publishes Security Digests – a couple that are of interest to our TechNet IT Pro audience. One is "Windows NT Digest" and another is called "Network Security Digest", which focuses on a wider perspective, and can cover issues ranging from specific computer manufacturers, networking infrastructure, and software. These digests are published monthly, and SANS' website says that they can be read in about 8 minutes.

There is a huge amount of information on the SANS site. It is well worth spending some time there, reading the FAQs, Digets, and other publications. One of my favorites was "The 7 Top Management Errors that Lead to Computer Security Vulnerabilities".

For complete details, please visit the SANS Institute's Web site.

Another site worth visiting is NT SECURITY.NET. This site provides a lot of Windows NT related security information, including;

  • A good Resources List of 3rd party products. Some topics are: address intrusion detection, log analysis & monitoring, network monitoring, password utilities, and port scanners.

  • Security Tools

  • Windows NT Security Newsletters (free)

  • Frequently Asked Questions

  • List of security related links

One last reference: a list of Windows NT Security related links.

Setup for SQL Server 7.0 will not work

Here's what can happen: Setup does not get past the screen that displays "Setup is searching for installed components". There is plenty of free disk space, memory, the correct version of Windows NT 4.0 and Service Pack is installed – everything appears to be ready to install.

If you have an unsuccessful installation of SQL Server 7.0, there are several files that can help you determine what went wrong. The first file is the Sqlstp.log file in the Windows directory. The Sqlstp.log file gives detailed information on what Setup is doing. Reviewing this file will give you an idea of where Setup is failing.

If the Setup process is failing in the Configuration part, review both the SQL Server error log in the MSSQL7\Log directory and the Cnfgsvr.out file in the MSSQL7\Install directory. SQL Server Setup runs an application called Cnfgsvr.exe to configure the SQL Server. This application starts SQL Server, connects to it, and runs the initial installation scripts. Any error encountered during this process is written to the Cnfgsvr.out file. When SQL Server starts, it generates an error log that contains errors SQL Server may encounter. This file, called errorlog, is in the MSSQL7\Log directory.

Another resource that you can use is the SQL Server 7.0 Setup Troubleshooter. Often, it can help figure out the problem or help narrow it down. For all SQL Server troubleshooters, click here.

If you are unable to determine the cause of the Setup failure, save the files mentioned above and call Microsoft Product Support Services or a Microsoft Certified Support Centers to contact a SQL Server Support Professional, who will help you to resolve your problem. Note that if the Setup application fails, it will roll back changes to the file system, including removing any copied files, and also remove changes to the registry.

Where did the files go?

This problem has popped up now and again. On a Windows NT Server 4.0 (regardless which Service Pack is installed), every time someone deletes a file from the network server, the file does not appear in the recycle bin. What's going on?

If you delete a file or folder from a resource that is not local (such as a network computer), the file or folder does not go to the Recycle Bin, the item is instantly deleted. This is true even if you do not have the "Do not move files to the Recycle Bin. Remove files immediately on delete" dialog box checked. This is default behavior, as designed and cannot be changed.

On a related note (albeit a little outdated), there used to be an "anomaly" (i.e. bug) with Windows NT 4.0 that might be worth mentioning. The title of the Knowledge Base article that addresses this pretty much sums it up: "Files with Long Extensions Bypass the Recycle Bin When Deleted". Therein it says

Files with extensions longer than three characters are not displayed in the Windows NT 4.0 Recycle Bin when they are deleted from My Computer or the Windows NT Explorer.

After performing a quick check on this problem on Windows NT 4 Service Pack 5 and Windows 2000 beta 2, I can report that this problem is no longer a problem. Files with long extensions (greater than 3 characters) now behave as they should: They go to the Recycle Bin on local file deletes.

That is it for now. Happy reading and check out the new TechNet Top Questions on November 22, 1999.

Illustration by Elizabeth Anderson, MSN Staff