Computer Forensics Incident First Response: First, Do No Harm

Forensics is becoming a popular following, thanks to the multitude of TV shows that show crime scene technicians collecting evidence, spending a few minutes in the lab determining the guilt of the culprit, and wrapping up the case at the end of the show. But in real life, forensics, like other complex issues distilled on TV, is much more time-consuming, process intensive, and sometimes inconclusive. The art and science of computer forensics is no different. Digital forensics is gaining in popularity as the next must-have skill set in the IT job market arsenal. However, computer forensics technicians and analysts require some intensive and usually expensive training.

Since computer-related incidences are sometimes few and far between (the ones that are discovered, anyway), most companies don’t see an immediate return on investment by hiring someone exclusively devoted to that task. Only a few more see some value in expensive training for the support technicians and system administrators that are already working for them, since they may never have a need for these skills. As a result, when incidents do happen and are actually discovered, the company may find itself in a situation where the “server guy” or other support technician may be called upon to do the initial response to the incident. Despite lack of training or experience, this article is here to help you with a few critical points that can make or break your investigation and ensure that key evidence is not contaminated or rendered unusable in administrative or legal actions. We’re not going to make you a forensics expert, but you will at least be able to handle the critical first response tasks.

Using Windows Safe Mode to Get Rid of Gunk-Ware

To me, Windows’ Safe Mode is one of the best inventions since sliced bread. I find that most “gunk-ware” (temp files, cache, and even some spyware and malware) can sometimes better be cleaned when the computer is booted into this special diagnostics mode. Since Safe Mode only loads a minimum of prescribed drivers and services, usually you don’t have the problem of trying to delete a file that is “in use” or running as a process (as a lot of malware does in normal mode).

Whenever I encounter a computer that is slow, sluggish, or in need of a good cleaning, the first thing I do is boot into the Safe Mode (Command Prompt) option and start cleaning house. When you do this, it’s a good idea to login as the local administrator account, or an equivalent account, because you’ll need higher privileges to complete some of the actions I’m going to describe. Because it’s difficult to delete some files belonging to the user profile you are currently logged in as, try to login as a user that normally does not log into the machine (you don’t log in normally as the local administrator, right?!) on a routine basis.

As a precautionary note, it’s a good idea to back up your system before executing any of the commands I’m going to discuss, of course. Although you shouldn’t have any ill side effects from any of these methods, I do have to warn you that these are just some of the things I do to clean gunk; try them at your own risk, your mileage may vary, offer not good in all states and countries, and so forth. Having said that, let’s move on.

One logged in, I usually change to the system’s root directory (usually known on the average PC as “C:”) and start there. First, I delete all of the .tmp files that can take up space and hide malware. Run this command at the prompt:

C:> del *.tmp /s /f

The /s switch recurses all subdirectories, and the /f switch forces a delete even if the file is in use (hopefully it won’t be since we’re in safe mode).

Planning an ISA Server Deployment (Part 2)

Welcome back to the continuing series on ISA Server 2004! In this article, part two of “Planning an ISA Server 2004 Deployment”, we are going to cover server requirements necessary to actually install ISA 2004. We’ll talk about hardware requirements as well as some of the unique requirements we need to plan on when installing the software on both Windows 2000 and Windows Server 2003 platforms.

As we talked about in our last article, planning is of vital importance in an ISA Server 2004 deployment, in order to prevent having to go back and correct what may become serious problems later down the road after the install is declared a “success”. Before the CD is even inserted into the box which will become an ISA server, some considerations that must be taken into account are hardware and operating system platforms. We’ll talk about both of those issues in this article.

First, let’s look at hardware. ISA Server 2004 has a minimum set of hardware requirements, of course, as all Microsoft products do, but the minimum requirements are only established to set the low-end boundary of what a computer must have just to get ISA server installed, not necessarily to run it well. We’ll list the minimum requirements, but understand that you should always, especially in a large production environment, go with considerably more hardware than just the minimum if you want it to run right.

Microsoft says that the minimum hardware requirements for an ISA Server 2004 are: a Pentium III or compatible CPU running at least at 550 MHz, 256 MB of RAM, and an NTFS –formatted hard disk drive with at least 150MB of space available on it. Of course, if you are going to use the ISA server for content caching, you will need additional hard disk space. It should go without saying, of course, that a CD-ROM, keyboard, mouse, and VGA-compatible video adapter are also necessary to install the server.

Planning an ISA Server Deployment (Part 1)

In this two- part article in our continuing series on ISA Server 2004, we will look at a very critical part of the process, the planning phase. Planning is one of the most important parts of an ISA Server deployment, but is also the part that very few people put a lot of time and energy into. Unfortunately, failing to plan the deployment properly can lead to problems later that will cost you more in terms of time and work to go back and correct these issues. That’s why this phase is so important.

The first part of planning, which this particular article covers, is planning out the network infrastructure that your ISA Server will be a part of, and knowing exactly how it will fit into the architecture. This is critical because there are several considerations to look at before you actually bring the server online. There are several aspects of your infrastructure you will need to examine, including: network infrastructure, organizational security policies, client requirements, branch office connections, VPN structure, server publishing, partner access, fault tolerance, and the actual roll-out itself. We’ll briefly look at each one of these now:

Network Infrastructure: This involves having a comprehensive network diagram and configuration documentation that exactly lays out the way the network is built. Critical parts of the infrastructure that may affect and be affected by the ISA server rollout will be DHCP services, DNS, email services, Active Directory structure, perimeter network configuration, web servers, and any other network services that must be reconfigured to coexist with an ISA Server. You should know what protocols your company network uses, and how they should be secured as they enter and leave the network. You may have to move some services inside the DMZ, if you have one, or look at creating a DMZ if you don’t currently have one. You will need to decide how DNS is handled, and whether the ISA server will handle DNS resolution. You will also need to look at any web services that are accessed from outside your network and how they will be protected against unauthorized use. These are but a few of the considerations you will have to contend with on the network, but it depends on how your network is built and what your requirements are as to how you plan for them.

Deploying ISA Server 2004

Welcome back to the series on ISA Server 2004. So far we’ve talked about what ISA server is and does, and its functions and editions. This article will take it one step further by discussing the many different ways you can use ISA server in your network, no matter how large or small.

ISA Server 2004 can be deployed in a number of different configurations to suite your organization’s needs. Since ISA server is well suited for small, medium, and large businesses, a wide variety of deployment scenarios are possible. There are three basic deployment configurations we will discuss, and then talk about some variations on these.

The first scenario is as an internet edge firewall, probably the most common scenario. The ISA Server protects an internal network from an external one, such as the Internet. One network interface is attached to the Internet, or other untrusted network, and the internal network is attached to the second interface. There may or may not be a perimeter network between the Internet-facing ISA server and the internal network, depending upon the size of the network and the needs of the organization. The ISA server may allow internal servers to be published, such as a web server, and it may even operate as a VPN server. In any case, the ISA server serves as the only entry and exit point into the internal network from the outside world, and controls all inbound and outbound network traffic.
A second method is to deploy the ISA Server as a back-end firewall. In this case, the ISA server is one of two firewalls deployed in a demilitarized zone (DMZ) or perimeter network configuration. The front-end or Internet-facing firewall serves as initial entry point into the network. This machine may or may not be an ISA server. This firewall offers some protection for the internal network and serves as the primary protection for servers deployed inside the DMZ. The ISA server acting as the back-end firewall, on the other hand, primarily protects internal assets and allows publishing of resources outside the internal network. For example, a web server in the DMZ may require data from an SQL server that resides on the internal network. The back-end server would allow access to the SQL server from the web server inside the DMZ only, and not from any other external host. Then the web server would provide requested data to an Internet host through the front-end firewall.
Yet a third scenario would be to use an ISA server as a branch office firewall and/or VPN server. In this case, the ISA server would serve as a single entry point into a smaller, geographically separated branch office network, usually connected to the Internet with a WAN connection, and connect to another ISA server at the main office, in a site-to-site VPN configuration.

Keep in mind that when factoring in additional roles for your firewall, such as proxy or caching server, VPN server, or a remote access server, this can add variations to the complexity of the basic scenarios mentioned above. You may choose to have separate ISA servers host these roles, or combine them onto one server. Additionally, having arrays configured in each of these scenarios can both add to your deployment options and the overall complexity of the deployment, as an ISA server may also function solely as a configuration storage server for an array. The bottom line to remember here is that ISA Server 2004 is quite versatile; it can be deployed to fit the unique needs of any size organization.

With that, we’ll close out this installment. In our next article, we’ll discuss an often-overlooked, but extremely critical part of getting ISA Server 2004 up and running – the planning step. See you then!

Securing the Administrator Account

The most powerful account on any Windows machine is the local administrator account. Anyone having access to this account pretty much has the keys to the castle, as far as Windows machines go.  (Note: Although domain controllers don’t have a local administrator account per se, the domain administrator account that resides on them is effectively the same thing.)     Even on a Windows box joined to a domain, the local admin account is sometimes even more powerful than the domain administrator account, simply because the local administrator can remove the domain admin account out of the computer’s local administrators group at any time and effectively take away a domain admin’s privileges on a machine. (Of course, there are ways to prevent that from happening as well, usually through the use of Group Policy.)   The only account that is more powerful on the local machine is the built-in SYSTEM account.  With the local administrator account, any action that can be taken on the machine can be accomplished with its privileges, including creating users, adding or removing resources, managing the network, and so forth. That’s why it’s definitely necessary to secure it.

With this in mind, there some generally accepted things you should do to secure this account.  These steps are equally effective on both Windows 2000 and XP workstations as well as the Windows family of server operating systems.  Keep in mind also that you may not want to take these measures on every single workstation and server on your network, maybe just those that are of particular value or have a high risk factor associated with the information they contain.  Of course, a word of caution is in order: applying these security measures to your machine or domain may increase your security, but also may cause reduced functionality of certain applications if they were set up to rely on the local administrator account to function.  As always, test these security measures on a test box or lab network and make sure they don’t break anything before implementing them in your live network. (Note:  Some of these steps can be applied to domain and enterprise administrator accounts as well, to better secure them).

Dealing with Hosts File Poisoning

A common spy ware and pop-up tactic these days is hosts file poisoning.  Hosts file poisoning involves injecting new entries for Internet sites into a computer’s hosts file, so that web site requests are either rerouted to another site or simply return a “Page Not Found” error.

I first encountered this little trick when getting rid of some spyware and adware on a friend’s computer.  I tried to go to a popular anti-virus site to download the latest anti-virus definitions, and was constantly routed to another site filled with the typical pop-up ads for a variety of products.  I then did the typical things you’d do to help fix the problem, like dumping the Internet cache, cookies, and history, making sure my DNS was properly configured and working, and checking the browser’s settings.  When that didn’t work, I started looking a little bit deeper.  After a couple of minutes, I realized the problem was a bit simpler than some new form of malware.  It was an issue with the computer’s own hosts file.  For those of you who may not have messed around with the hosts file before, here’s a little background:

In the good old days before DNS was commonly used for host name resolution, computers used host files, which are simple text files, to resolve host names to IP addresses when accessing other computers or Internet sites.  These static text files contained mappings of Internet IP addresses to the destination computer’s host name or web site. When users requested access to those computers by host name, the host file was checked, and if an entry for that computer or site was found, it was resolved to an IP address, just as DNS does today.

As a holdover from those days, Windows computers still have and check the hosts file during the name resolution process. By default, the computer checks the hosts file first, before attempting to resolve the name through DNS.  If it finds an entry for the name, it uses that entry and does not try DNS.  On most computers there are no entries in the hosts file, except for the local loopback address, so name resolution proceeds normally through DNS.

A favorite tactic by those folks who send you tons of pop-ups and other annoying forms of malware is to put entries into the file, so that your computer will resolve certain names with it instead of going on to DNS.  On the computer I mentioned above, I found no less than about 100 entries in this file.  In addition to entries rerouting just about every common page you could think of, like web-based email and news sites, to other sites, the entries also rerouted popular anti-virus sites back to the computer’s own loopback address.  This would result in any attempt to get to those sites being redirected back to the computer itself and getting a “Page Not Found” error.  This meant that my friend would never be able to get updates to his anti-virus software.

The quick solution is to simply get rid of those entries and reboot, so the computer will re-read the file, but that doesn’t permanently fix the problem, of course.  It could get poisoned over and over.  So there are a few other steps you can take to make sure that this tactic can’t be used against you again.

If you don’t really have a need for the file, you could rename it to something else so it wouldn’t be read as the hosts file.  I experimented with this on a Windows XP SP2 box, and it didn’t seem to affect my name resolution.

On computers running Windows NT, 2000, XP, and 2003, this file is located in the %systemroot%\system32\drivers\etc folder. Just rename it; I wouldn’t recommend deleting it entirely, since one day you may actually have a need for it.  Then set the folder containing it to “read only” for the folder and all subfolders and files.

On the other hand, if you think you do have a need for it, at least mark the file as “read only” and change the permissions on it.  This at least may keep it from being altered by anyone except you, if you so desire.

In any case, when trying to get rid of spyware, adware, and those pesky pop-ups, I’d add checking the hosts file to my troubleshooting list, and you’ll have one more way of fighting malware!

Microsoft ISA Server Editions

Welcome back to our series on Microsoft’s ISA Server 2004. In our previous article, we talked about some of the features of ISA 2004. This time, we’ll talk about the two editions of the product and how they differ from each other and their predecessor, ISA Server 2000. We’ll also talk about the various upgrade paths from ISA 2000 to 2004.

ISA Server 2004 comes in two flavors: the Standard Edition and the Enterprise Edition. Although both offer similar features, such as the firewall, caching server, and proxy server capabilities, they differ in how they are implemented, the size of the infrastructure they are targeted for, and some advanced features. We’ll discuss the features of each and the differences between the two in this article.

ISA Server 2004 Standard Edition is the basic ISA Server package. It’s suitable for almost all networks, and is used mainly in a stand-alone environment. It can be used in small- or branch-office type of scenarios, or when you only need one ISA server installed to fulfill a specific role (such as a web proxy). It can be deployed in all of the roles previously discussed, including proxy server, caching server, and firewall configurations, or a combination of all three.

ISA Server Standard Edition differs from the Enterprise Edition in that it stores its configuration data in the local registry, instead of in a central location, such as Active Directory. This means that if you make any configuration changes that need to be applied to all of your ISA servers, you’ll have to go to each one and make the change individually. Additionally, Standard Edition does not support a centralized caching database configuration, as Enterprise Edition does when configured in an array. Each Standard Edition server has its own separate content cache.