Standards in desktop firewall policies -1

The idea of a common desktop firewall policy in any size organization is a very good thing. It makes responses to external or internal situations such as virus outbreaks or network-oriented propagation of viruses more predictable. In addition to providing a level of protection against port scanning, attacks or software vulnerabilities, it can provide the organizations local security team a baseline or starting point in dealing with such events.



The purpose of this article is to discuss the need for a desktop firewall policy within an organization, determine how it should be formed, and provide an example of one along with the security benefits it provides an organization.
The Problem
The trick to a good desktop firewall policy is to provide a balance between security and the networking requirements of the applications needed by the organization. It's possible the organization may not yet have a complete knowledge of these requirements. This should make the first attempt to define a standard/global policy interesting, depending on the level of protection one is trying to provide and the situation or environment the desktops may be in.

One thought on an initial policy is to provide a port-based firewall with all inbound ports blocked on the desktop. On the other hand, an old school of thought might involve one blocking only the ports that need to be blocked, by estimating software network requirements and then combining this with an effort to also block the most obvious of possible vulnerabilities or services. Evaluating FTP, Windows IIS or NetBIOS requirements might provide a first pass at a standard global policy. Our old school of thought again would leave the balance tipped toward the (as yet unknown) network requirements of the software, and less toward protection. In other words, offer functionality over security. While providing consistency, cases where the desktop (or laptop) is located off site may not fully satisfy security requirements of the organization.

Location awareness may be a feature of the desktop firewall that one could use to design a policy that changes to better fit a user's location. Some personal firewall solutions provide location awareness as a feature. Location selection could be automatically selected depending on a successful Windows domain login, specific IP address, DNS server address, network adaptor type, or it could be based on the client firewall's ability to connect to a policy manager.

If location awareness is not a built-in feature of the firewall, the policy could be designed around the organization's internal IP address range or, if available, be configured around the DNS domain name. For example:

allow all inbound *.someorganization.org
Issues with a "block all" inbound policy
A block all inbound policy while connected offsite would seem to present the least amount of risk, but might not be completely possible while onsite. The first issue may be caused by the firewall itself. Depending on the vendor, characteristics of the firewall may impact application functionality while using a block all inbound policy. This may include UDP, complex protocols like FTP, NFS, applications running in a service mode, and problems with a Intrusion Prevention System if one is provided with the firewall. Each of these issues will be discussed below.

UDP, being a stateless protocol, is difficult for any firewall to handle. A simple UDP based service may run on port 1313, or example. The UDP client (running the desktop firewall) would attempt to connect to 1313, and assign a port for a reply. There may or may not be a reply; if there is, it won't be easy for the firewall to determine whether or not to allow it. Either the firewall needs to attempt to keep state of all outbound UDP traffic on its own, or UDP port requirements must be known and the firewall must be configured to allow the reply on a case-by-case basis.

An example of a facility requiring UDP might be printer or scanner client that issues a UDP broadcast and then awaits a reply. That reply would come from a scanner or printer the user may want to access, and it might include its status or availability.

FTP could cause another possible issue with the firewall. In some cases the firewall may not support active FTP, which is unusual as Microsoft Windows doesn't support passive mode. Active FTP is where the ftp server will initiate a connection back to the client to do the actual transfer of data. Oddly, FTP is still used and sometimes even embedded within other software. Fixes for active FTP on firewalls can be ugly and may end up being one of the first application-based rules.

Applications running in a service mode can have one of two solutions: either the firewall requires an application-based rule where the application's network access is restricted to predefined ports, or one can simply allow the open port, possibly with some other restricting criteria. Restrictions by IP address or time of day are possible as well, and may be desired.

An Intrusion Prevention System may be an additional feature of a desktop firewall within an enterprise. This would allow the firewall to detect possible attacks by examining the inbound packet and matching data and port usage against a list of known attack signatures. The IPS may be configured to respond by blocking the inbound packet or allowing it and sending an alert. False positives on a firewall supporting IPS could mistakenly block inbound traffic and would need to be analyzed and adjusted on case-by-case basis. Logging the event and allowing the traffic may be the quickest and easiest way to deal with false positives.
The Environment
In this part of the article, we detail what is needed to create an environment where software requirements are known and our corporate standards are enforced:

1. a desktop firewall This is the tool used to enforce restrictions on network access by limiting port and protocol access. The firewall should limit the user's ability to change its configuration, yet provide enough function such that the user can identify issues that may be caused by the firewall policy. The firewall should support port- and application-based filtering.
2. A security policy This will define what is or is not permitted to or from the network, on a standard desktop. Typically this would be generated by a high-ranking security group or set of officials in the organization, and would be generalized into a non-technical document (it could be as simple as block all inbound rule).
3. Knowledge of existing port requirements or a baseline of requirements These would be taken standard or default desktop operating system configuration used in the organization. Typically an organization would have an install tailored to its own requirements, and it may include patches, anti-virus, and common software required by all users. This, combined with the security policy, would form the basic desktop firewall policy.
4. Ability to deploy a single global firewall solution to all desktops This means deploying the solution to all desktops in the organization with a consistent or single policy. Enforcement and tracking of deployment would also be necessary.
5. Facility to provide and update the firewall policy Some firewalls can be centrally managed directly. Depending on the needs or structure of the organization, the minimum requirements would require a common/global firewall policy that can be updated, for example through the replacement of a configuration file. Obviously some form of central software management would need to be in place.
6. Large plastic bat to handle upset users
7. Tools to aid in the analysis of the networking requirements For example, this might include Ethereal for monitoring traffic, the ability to analyze firewall logs, Perl scripts to test firewall rules, Nmap for port scanning, and so on.

"Software Networking Standards" – A potential benefit
If the organization knows the networking requirements of its applications, a policy could easily be created. Then the idea of software networking standards could be enforced through the policy.
An example
In order to provide a firewall policy for the examples below, let's first assume that a policy is designed and configured to block all inbound TCP/UDP, and allow all outbound TCP/UDP. We will also assume the firewall does not properly handle outbound UDP or complex protocols such as FTP. Some known software requirements in this environment may be obvious, for example support the organization permits file sharing. This would require inbound TCP port 445 open . A rule is created to support inbound 445 and also restrict the rule to a range of IP address (192.168.4.0 through 192.168.20.255 in this example, with the understanding that this private IP address range could be used by other organizations such as hotels as well, creating a potential hole for traveling users). Finally, ICMP is allowed for troubleshooting. A sample policy might thus be configured to:

* Allow all inbound and outbound ICMP
* Allow inbound TCP 445 from hosts 192.168.4.0 – 192.168.20.255
* Block all inbound TCP
* Block all inbound UDP
* Allow all outbound TCP
* Allow all outbound UDP

Let's now look at the benefits of using our sample policy.

Read More...

Summary only...

Standards in desktop firewall policies -2

Benefits of a desktop firewall policy

* The ability to predict the impact of security-related events is enhanced. An event could have many characteristics and take on many different forms. If some of those characteristics involve network port access, the policy may offer an initial form of protection. In addition, network-oriented responses to these events become more predictable. For example, the application of router and network firewall ACLs are sometimes used to deter the propagation of virus and worms. The problem is, the implementation of ACLs could impact production software, in cases where both applications and a security event have similar port requirements. Depending on the characteristics of the event, the example policy may make ACLs unnecessary on some network segments.


* Provide consistent software solutions (as opposed to multiple solutions that provide the same function). Two departments requiring a similar service may deploy two different software solutions. While it is best that departments in any organization coordinate development and deployment in software solutions, the reality is, this doesn't always happen. The policy defined above offers some hurdles for new applications. If the policy happens to conflict with the network requirements of the application a request for a policy enhancement would be required. At this point, if not already, the application becomes known to the organization.

* Restrict the ability for network-oriented programs from hitting the desktop until evaluated. Again, the policy may offer some new hurdles for applications, depending on their requirements. A recent example could be Microsoft's Activesync 4.0 software. The example policy above would require modifications, which could carry the concept of being loose or tight. (Visit Microsoft's Activesync page for the requirements.) The policy impacts the application in several areas: inbound port requirements, backend network construction, and these involve the use UDP along with TCP. A modification of the policy may include a fairly tight rule that binds the local ports to the application for the backend network only, such as:

allow 169.254.2.1 inbound access to the { required ports } AND { executables }

Analysis of the application through the use of Nmap can verify the port requirements on the backend network, but also reveals activity on the primary network. In this case a ‘status' port that is TCP 999 becomes active on the primary network when the handheld that uses Activesync is cradled. In theory one could execute a single port scan against port 999 on a subnet and identify all IP address which currently are ‘syncing' a handheld. Depending on the firewall internals and given the policy defined, Nmap may indicate ‘closed' for port 999. Some firewalls can be configured to drop an inbound packet for a port that is blocked, which would return nothing in this case.

* Restrict the use of service-oriented software. Individuals involved or concerned with security have to be interested and even frustrated with this. Software running on an ordinary desktop (as opposed to a ‘server') that requires a port used for listening could be susceptible to coding errors allowing inbound access or backdoors. They should be avoided.

* Software using unusual protocols will become known (such as systems using the streaming protocol IGMP). While the use of protocols other than IP isn't itselft an issue, it's an advantage to know they are in use. Some firewalls will not pass these protocols, and isolation of their use could be difficult. It's now common for the software provider or vendor to make their networking requirements available for organizations supporting a desktop firewall.

* Track the use of broadcast-oriented software which usually runs as UDP. The example policy in this article would disable the response to a UDP broadcast. A good standard for any organization is to define service-oriented equipment, such as printers and scanners, using static IP addresses, and make the user aware of the names and IP addresses of these facilities that are in their area. The security issue in this case is that the service could be spoofed. A phony print server could be created to capture and forward printouts to the actual server.

* Track the use of backend networks or dual-homed machines. The example policy may reveal a backend, depending on what it is being used for. The use of backend networks won't directly cause security concerns, but their existence and use should be identified. For example, asset and patch management could be impacted, and real vulnerability assessment would also not be possible.

* Software and desktop support can be impacted and simplified. The example policy offers some limitations on what software can do on the network. Software requiring modifications to the policy obviously becomes known, and the specific policy modifications would help create a consistent deployment.

* The example policy would help in the enforcement of the organization's security policies or detection of software which might break this policy. For example, it may be part of the security policy to prohibit the use of database, web, ftp or P2P servers on ordinary desktops. The policy in this example would block those services.

* A global policy could help enforce an organizations specific standards; such as the use of a remote access VPN or streaming media solution. The example policy would most likely require modifications to support VPN. Typically the software requirements of VPN would differ between vendors as well.

* The policy could be used to limit access to services running over non-standard ports. For example, assume that only minimum outbound internet access restrictions are in place and a policy and mechanism exists to monitor and log Internet web access. Typically web access is done using TCP port 80. However it is possible for a user to access an external anonymous web proxy (such as www.proxyblind.org; there are many others) that may run on a port other than 80. This usage would bypass logging and allow the user to surf the web anonymously. A modification to our example policy restricting iexplorer.exe to outbound TCP port 80 could be created. Limitations on other ports commonly used to support anonymous web proxies could also be created (for example, these are often found on TCP ports 3128, 8000 and 8080)

Summary
A common desktop firewall policy could lead to, or help in the enforcement of, software networking standards. If this is something an organization wants, there are clear benefits. Depending on whether the organization is running a firewall with a consistent policy or not, networking standards at some level may already be enforced. New applications may or may not be compatible with this policy, and changes or modifications would need to be requested. Those who deploy new software may need to be a bit more familiar with the network requirements of their software, to be able to adhere to policy.

The desktop firewall, typically just one piece of desktop security, often is combined with patch management, anti-virus and software deployment/management facilities to form a complete security solution. As part of that solution, the desktop firewall's job is to simply block network traffic and detect attacks. Yet the reality is, it can do more than this although added features may not be quite as tangible as the supplying desktop protection.

The implementation and maintenance of a desktop firewall can be a stressful and frustrating experience – particularly for those organizations who do not have a full understanding of their own network requirements. It can cause existing software to become disabled. It could require deployment dates to be extended due to additional development time required to isolate compatibility issues. It may require additional resources or steps to get software to the desktop.
Conclusion
In this article we discussed the need for a desktop firewall policy within an organization. It was discussed how such a policy should be formed, and then an example was provided – along with a detailed discussion of the security benefits it provides an organization.

An old school of thought would resist any restrictions placed on internal network access. But today the stakes are a higher, and security is paramount. At some point in the history of networked computing, an organization has become more accountable for its network traffic and legality of the software it chooses to run. Not many options are available for limiting the use of the network (beyond simply blocking it at the usual choke points, which doesn't allow for the controlling of specific applications). This approach needs to change, as more and more attacks and security concerns come from the soft underbelly of the organization's internal network.

Read More...

Summary only...

Winning the Hotfix Race

Even a Broken Watch is Correct Twice a Day

Any NT or IIS admin is familiar with the process of applying service packs and hotfixes--as well as all the problems associated with it. But the fact is, no software is going to work 100% of the time, especially when you take into consideration the many security concerns of a web server. But Microsoft does not always make it easy on us.



The process of keeping up-to-date can be a time-consuming and often confusing process. First, one must be aware of the issues and the availability of a fix. Then one must determine if the fix should actually be applied to each server. And finally there are the logistical issues of deploying hotfixes to a number of servers. But as long as there is software, there will be hotfixes for that software.

When To Fix

Obviously, a good time to apply service packs and hotfixes is immediately after installing a product on your computer. A fresh install of any OS is considered insecure and is normally full of holes. Windows NT and Windows 2000 are no exception. But applying hotfixes after a fresh install is not going to keep the OS secure. You must keep up with Microsoft Security Advisories in order to stay secure. You must also often reapply service packs and hotfixes when adding or removing certain system components.

But how do you know exactly what needs to be reapplied after which components are added or removed? Keeping track of what changes can be difficult and much of the documentation available can be confusing and sometimes contradictory. Often, many administrators will just reapply all service packs and hotfixes regularly just to be safe. But there are also some third-party tools that may help the process such as SPQuery or Service Pack Manager.

If It Ain't Broke, Don't Fix It

System administrators have many different philosophies when it comes to hotfixes. Some will religiously apply every available fix while others will never touch a system that is already working well. There's a an Italian saying "Una scopa nuova spazza bene" which translates to "A new broom sweeps well." We all like the new car smell but sometimes new software is not always the best answer. There are systems out there that have 99.9999% uptime but that is only because they are running the same software that was originally installed ten years ago. The proper way to approach the problem is to balance the benefits of a hotfix to the risks of introducing new bugs. I imagine that some hotfxes are nothing more than the software version of duct tape and bailing wire and even Microsoft warns against using all hotfixes unless specifically needed. Most hotfixes have not been fully regression tested so the implications of applying them are for the most part unknown.

So the question is really one of whether you really need the update or not. Often, the security benefits of a hotfix far outweigh the risks of applying the fix. Nonetheless, if the hotfix applies to a service or function that you are not using, you may be better off just not applying it. However, you must keep track of which fixes are applied to a server so that if you ever do use that service or function in the future, you can know to apply the hotfix.

When deciding to apply an advisory it is good practice to review the associated knowledge base article. Every hotfix will be accompanied by a knowledge base article that is often included with the hotfix itself. These articles will usually explain who needs to apply the hotfix and what problems are corrected. Keep in mind, however, that often the article will be vague about the actual exploit, making it difficult to decide if there is another workaround without having to apply the fix. Often, if the bug was discovered by another company and reported to Microsoft, they will have their own advisory that will have much more detail. Check the security mailing lists if necessary to get more information about the hotfix.

Applying the Patch

Once you have determined to install a hotfix, you should download and install it on a test system. Usually this is a non-critical server that has a similar configuration as your main web server. The time spent testing really depends on your resources, time, and risk exposure. Once satisfied with the stability of the patch, you can then plan to put it on your production server. If possible, time the update at a time when your web traffic is low. If you have multiple web servers, only work on one at a time, making sure that one is up and running stable before working on the next.

If you are installing a new server and are applying multiple patches, keep in mind that it is usually important that the fixes be applied in the correct order. Microsoft usually documents the correct order, but it is not always very clear and can sometimes be difficult to follow. To cope with this, I usually save each hotfix in a directory that includes the Q-number, such as "Q244599 C2-Fix." That way, the hotfixes are for the most part saved in a chronological order and can be reapplied in that same order. It is also important to remember to group them by service packs as well, as the service packs will include most of the previous hotfixes--but not always.

Another good reason for tracking the hotfixes by their Q-number is so that when you are reading the documentation for a service pack, you can easily see which ones are included and which ones are not. Although most hotfixes will be rolled in to the service packs, there are times when a fix may not be best for everyone and so therefore they are not included. You must manually keep track of this and be sure to apply the old hotfixes when necessary.

With the new Windows Update service, it is quick and easy to keep your system patched. But like the service packs, not all hotfixes are included. The only way to know which ones are included and which ones are not is to use both the Windows Update site as well as the Security Bulletin site.

Keeping Up With Updates

Keeping up with all the service packs and hotfixes is not as simple as it seems. I have already mentioned Windows Update and the Security Bulletin site, but there are also other places where fixes may be hidden. Here is a list of resources that may be good to check regularly:

Microsoft Sites:

Windows NT Hotfixes - Hotfixes for Windows NT 4 and 3.51

Windows NT Service Packs - Service Packs for Windows NT 4 and 3.51

Windows 2000 Downloads Page - Contains all critical updates, service packs, and other downloads for Windows 2000

Microsoft's Main Downloads Page - Allows you to search for downloads for any Microsoft product

Microsoft's FTP Site - FTP access to most product updates, although some are hidden in obscure locations

Office Update - Downloads and updates for Microsoft Office

Microsoft's DLL Help Database - Very useful database for tracking down dll versions

Non-Microsoft Sites:

Paperbits - Excellent update resource for Windows NT as well as third-party drivers

Versions - Tracks version numbers for a number of software applications

BugNet - Excellent resource for keeping on top of software bugs

Finally, do not forget Microsoft's Knowledge Base. If you search for the word "Fix:" or "security_patch" and only include articles for the last several days, you can sometimes find fixes that would otherwise sneak by without much notice.

One way to keep on top of all these pages using Internet Explorer is to navigate to the page, then from the favorites menu, select Add to Favorites. Then check the Make available offline button and click on Customize to create a synchronization schedule. I normally set it to synchronize every day. Save the schedule and the bookmark and next time the page changes, a red dot will appear next to the site's icon in the favorite's menu.

Distributing Updates

Keeping on top of updates difficult enough for one or two servers, but if you have to distribute updates to several hundred computers across an enterprise, the task can be quite overwhelming. To do this, I would recommended creating a network share for storing all service packs and hotfixes. To actually distribute them, you may opt to manually apply each one, use a script or batch file, use Microsoft's SMS server, or use some other third-party software. If you have all Windows 2000 systems, you may very well want to consider using ActiveDirectory's publish and assign features to distribute updates. Publish allows you to make updates available for installation and assign will actually force the install on every computer under the control of that policy.

Some day managing service packs and hotfixes will be a thing of the past. But for now you must know about the updates, know that you need to apply them, know where to get them, reinstall them (and in the right order) after changing your system, and have a good plan for distributing them across your company. Nonetheless, with a good strategy, it can be done and it can be done well.

Relevant Links

Windows Update
Microsoft
Microsoft Security Bulletins
Microsoft
Windows NT Hotfixes
Microsoft
Windows NT Service Packs
Microsoft
Windows 2000 Downloads Page
Microsoft
Microsoft Main Downloads Page
Microsoft
Microsoft FTP Site
Microsoft
OfficeUpdate
Microsoft
DLL Help Database
Microsoft

Read More...

Summary only...

Use Performance Counters and Alerts

Withstanding Denial of Service Attacks

Have you ever been ripped off by a company and wanted to get revenge somehow? Have you ever been terminated from a job and felt you were treated unfairly? As a teenager did you ever take a baseball bat to someone else's mailbox while speeding by in a friend's car?

We are all human and at some point we are angry with someone somewhere. Sometimes we just take out our anger on the next person who passes by. Our motivations could be revenge, jealousy, greed, or even just boredom.



But sometimes we are the victims of someone else's anger. Maybe we have wronged someone or maybe we are just a random victim. If you operate a high-profile web site, chances are that someone sometime will try to take you down. Their motivations may vary but whatever they are, you must still keep your site going 24 hours a day, seven days a week.

There are three basic ways in which a server can be attacked. It can be vandalized, robbed, or denied service. This article will be covering denial of service (DoS) and what can be done to make an IIS server more resistant to DoS attacks. This article will deal specifically with IIS and not cover other areas such as router configuration or DNS hijacking.

Configured correctly, an IIS server can actually be quite resilient to network-based attacks. Often, by following common security procedures, one can protect a server from the majority of these attacks.

What is Denial of Service?

Denial of Service is simply making a web site inaccessible to a site's normal visitors. This can be accomplished a number of ways including 100% bandwidth utilization, 100% CPU utilization, 100% RAM utilization, filling a hard drive, crashing the kernel or server applications, or redirecting traffic so that it never reaches the intended site. In the last few years there have been a number of vulnerabilities discovered in Windows NT and IIS that result in many of those conditions. There are also a number of weaknesses in the TCP/IP protocol that can be exploited to deny service from a web site. We will not be covering here the specifics of how each attack works but rather what methods can be used to protect from any number of attacks.

Keeping Patched

By following many common sense security procedures you can take a big step towards helping your site stand its ground under attack. The most obvious of these procedures is to keep up-to-date on the most current issues and vendor patches. Most importantly are Microsoft's security bulletins for Windows NT and IIS. You should also frequently monitor mailing lists and security web sites for other current security issues.

One downside of keeping up-to-date on patches is that you may be introducing code that has not been fully regression tested and may cause problems with your particular server. Patches should be analyzed carefully and backups should be made before applying them.

Closing Doors

Server software applications and services do have bugs and when you have more services running, you increase the number of battle fronts that must be monitored. Shut off all services that do not have a specific purpose for your web site. If you do not need anonymous FTP, disable it until the occasion rises that you do. The same is true for Terminal Server, NetBIOS, Telnet, and Mail servers. If you want a web server to keep serving, remove everything except that which you specifically are using to run and administer the server.

The same is true for ISAPI extension mappings and sample applications on IIS. Remove every extension mapping that you do not specifically use and keep your web root clean.

Regular Maintenance

Take advantage of the scheduler service and the disk cleanup utility to keep your temp directory and swap volumes clean with plenty of extra drive space. You should also regularly monitor log sizes and spread swap files across several volumes or drives if available.

Lock Down Network Services

The most basic advice one can give to protect the security and uptime to a web server is to remove the NetBIOS protocol. There are a number of attacks targeted at NetBIOS and the best solution is to eliminate it completely from a web server. Other protocols and clients (such as Client for Microsoft Networks) should be carefully considered when enabling them on a web server.

While on the network adaptor configuration, it may be a good idea to manually configure the IP address, gateway, and DNS servers to protect from attacks that exploit weaknesses in DHCP.

Although rarely done, enabling TCP/IP filtering on the server can also be a great protection form a number of attacks. You should only enable the ports that you will specifically be using such as 80, 443, and possibly 21 for FTP services. Keep in mind, however, that any TCP/IP filtering restrictions you set will apply to all adaptors on the system. If that proves to be too restrictive, the you should then consider a third-party firewall application.

There are a number of registry settings that can be used to make IIS more resistant to attacks based on TCP/IP protocol flaws, such as SYN floods. The recommended settings for these registry keys are as follows:
Registry Key Type Value
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SynAttackProtect REG_DWORD 2
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NoNameReleaseOnDemand REG_DWORD 1
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableDeadGWDetect REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime REG_DWORD 300,000
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PerformRouterDiscovery REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirects REG_DWORD 0

If these settings do not stop an attack, finer control can be gained over the TCP/IP parameters. Refer to the resource kits for more detailed descriptions of all the relevant settings.

Learning to use Windows 2000's Performance Counters and Alerts can prove to be very effective in protecting against DoS attacks. There are a number of performance counters that can be excellent indicators of a DoS attack. For example, counters that monitor the processor, RAM, hard disk, TCP, or ICMP data can all provide a good insight into how well your server is surviving. By adding alerts to predefined warning levels, you can be sure that you will have some warning in case of an attack.

Eventually someone will have some motivation for taking down your website. By taking these few precautions you can be ready when they come. Most of these techniques are very simple to implement but do require taking regular time each day to know what is going in the security world and stopping those who would like to knock your site to its knees.

Read More...

Summary only...

The NT Local Administrator and Shared Passwords

There is a Local Administrator account on every NT machine currently deployed. This account can be renamed, but not removed. It is extremely common to find many NT machines in an enterprise sharing the same password for this Local Administrator account. This article will establish that this shared password constitutes a security vulnerability, discuss various steps to mitigate the risk arising from the shared password, and make a case for applying unique passwords to every Local Administrator account in your enterprise.



The Security Issue of Shared Local Administrator Passwords

Workstations share the same Local Administrator password for a number of reasons. First and foremost, a shared password eases the daily burden of support personnel. No desktop support staff person wants to carry around a massive list of passwords or go through the cumbersome process of querying a centralized database of passwords. Secondly, automated build processes, which are very common, result in the deployment of a shared password. This is because disk imaging software ensures that each cloned machine has the same Local Administrator password as the original, and scripted installations reapply the same Local Administrator password each time the script is executed.

So how does a shared Local Administrator password constitute a security vulnerability? Very few of us have an enterprise in which the Local Administrator account cannot be cracked. This is usually by choice, we choose to give some users Administrator access so that the users can install his/her own software packages. We choose to leave bootable floppy drives in workstations and servers. Either of these choices may result in easy access to the Local Administrator account. Since this is a "shared" password, once the account name and password are obtained for one machine, this information can be used to access all the other NT machines that share the same password for the Local Administrator account. In short, successfully hacking a single machine results in access to multiple machines - and you don't have to be a CISSP to know that this is bad news!

Administrator access + common password = major security hole.

This is the vulnerability: access to one resource allows access to a second resource. Now, how does the access of the first machine lead to access of the second machine? Pay attention here, this material will get your manager's attention in a hurry! If your enterprise is normal and uses a common password for the Local Administrator account then any employee sitting at an NT workstation could own your CEO's access in less than a week. Let's imagine?

A contractor is hired to do some menial programming for your company. The programmer is immediately provided with a freshly-installed NT workstation built to enterprise standards. Using a DOS boot disk and an NTFS tool he copies the local SAM to a floppy disk. Next, using L0phtCrack software he cracks the Local Administrator account on his workstation. Now, posing as "Local Administrator", the contractor can gain access to any workstation because all the workstations have the same Local Administrator password. What is he going to do with this low level of access? Maybe he only wants Administrator access to his own machine so he can install his favorite screensaver. Then again, maybe not.

With Administrator access, he could install a keyboard sniffer on any target workstation and wait for the target to authenticate to the domain. In a short, he will soon know the victim's passwords for NT, Novell, Lotus Notes, mainframes, mail systems, file systems, etc. This points out the importance of securing the NT workstation. The victim of the keyboard sniffing could easily be the CEO of your company! All too often the focus is on the NT servers without sufficient regard to the workstation: securing workstations is as important as securing servers .

All right, so you think the workstation isn't important enough - you only want to worry about your servers? The same vulnerability exists if you have servers with a common Local Administrator password. Suppose your contractor is hired and given access to a single NT server. He may then crack the Local Administrator account on that single server thereby gaining access to all the servers that share the common password. Although your intention may have been for the contractor to have access to the lowly test boxes, he now has access to your production SQL servers. The contractor - who you do not know from Adam - has now bypassed your attempts to restrict his access to a single server!

So, just to recap: in many NT environments, most, if not all, of the NT workstations or servers share a common Local Administrator password. This implementation flaw allows Joe Customer Support to crack the Local Administrator password and use that access to escalate his privileges all the way up to the CEO. Now, how do we fix it?

Solutions to Shared Passwords

One obvious and straightforward solution would be to eliminate shared passwords altogether; however, in some situations this is not feasible. If management won't let you eliminate the shared passwords, the following mitigation steps will at least let you minimize the scope of your exposure.

Limit the Attacker to Machines to Which They Have Physical Access

To accomplish this, deny the Local Administrator network access to each machine. With this restriction in place, the cracker cannot use one machine to access others over the network. This doesn't prevent an attacker from walking over to the manager's machine and logging in as the Local Administrator, it just forces him to physically access the machine. However, be warned, this mitigation only removes the network access from the attacker, they would still have the capacity for local logins. Essentially it limits only the speed and convenience of compromise.

You will need to point User Manager at each NT machine and remove the user right of "access this computer from the network" from the Administrators Group (this is the Local group) and add the same right to the Domain Administrators group. (You'll have to specifically add the domain group while in the User Rights menu). Be sure the Domain Administrators group is in the Local Administrator's group.

Minimize the Time Window for Potential Crackers

With enough time, even the strongest of passwords can be broken by a brute force attack. Time is indeed of the essence in this regard because the stronger the passwords, the longer it takes to perform a successful brute force attack. Consequently, the stronger the passwords you apply, the less often you will need to change them. You can ensure that the window of opportunity for crackers is minimized by is accomplished by changing the passwords faster than they can be cracked.

While we're busy minimizing the time window, we must also maximize the time it takes for a brute force attack by using "strong" passwords. Passwords should be a least 12 characters in length and include some non-alphanumeric characters. You'll definitely want to develop an automated mechanism for applying the new password on a scheduled basis. Pointing User Manager at every machine in a domain is just not an acceptable option. If you really must change passwords manually, then consider a commercial option for synchronizing the Local Administrator password across multiple machines such as User Manager Pro. WARNING - this mitigation doesn't rule out the many fine alternatives to CPU cycles - such as cameras, hardware keystroke capture devices, shoulder surfing, etc.

Minimize the Scope of Exposure From Any Single Machine

Even if we cannot eliminate the use of common passwords completely, we can at least use different passwords for different areas of the enterprise. Functional distinctions provide for some obvious logical groupings. For instance servers and workstations should absolutely not share the same Local Administrator password! Consider using a different Local Administrator password for each resource domain, or perhaps for logical geographical divisions such as campuses or buildings. At the very least, make sure your "mahogany row" executive desktops have a different Local Administrator password than the rank and file workstations!

Protect the Domain Account Used for Applying New Passwords

If we are going to have a common Local Administrator password for all NT machines, then the interval between password changes must be shorter than the time required to brute force the password. We must use a Domain account to affect the Local Administrator password change on all the targeted hosts. The danger here is that now this Domain account NT hash will be exposed to any hostile target machine. As a result, it is crucial to protect this Domain account from compromise! For the same reason that we should frequently change the Local Administrator password, we should also change the Domain account we use when applying new Local Administrator passwords.

Removing the Shared Local Administrator Password

Considering the weaknesses and dependencies of the steps outlined above, it is without doubt preferable to eliminate the shared passwords completely.

Creating Unique, Unpredictable and Strong Passwords

First, let's consider what kind of passwords we want to apply in place of the shared password. The security vulnerability we have been discussing arises from the commonality of a single password; however, the solution is not simply a matter of creating unique passwords, but unique passwords that are also unpredictable. Imagine that every machine in the enterprise had a unique local admin password, but that password was the same as the hostname of the machine! What's the problem with that? Predictability. An attacker must not be able to use the password for machine A to access machine B. Having passwords that are predictable is as troublesome as having passwords that are similar. Clearly, the more unpredictable each password is, the stronger our security posture becomes. Random passwords would be truly unpredictable and therefore are an excellent choice, but we must also consider the strength of a password.

It must be kept in mind that unpredictable doesn't always mean strong. A password such as "37a" might indeed be "random", and thus unpredictable, but is weak and therefore ease to brute force. In order to be truly effective, passwords must combine strength and unpredictability. The idea is to have both 0% predictability and serious strength in order to resist both brute force and logical attacks. Strength is achieved by utilizing a large character set and a sufficiently long password.

Recovery of Passwords

Second, let's consider the administrative issues surrounding the recovery of those passwords. By recovery we mean the ability to determine the Local Administrator password for a particular NT machine in an environment in which the Local Administrator password is not shared. Access to the Local Administrator account on servers or workstations is a requirement for most enterprises. This means that after we apply unpredictable, unique and strong passwords to every NT machine we will need a recovery mechanism.

Why would we need to recover a Local Administrator password? Suppose the "Senior Executive of Irrelevant Paperwork" needs to print that huge Power Point presentation just minutes before the "big" meeting, but her NIC card decides to die at this most inopportune moment. Your support staff can save the day in minutes with the Local Administrator account, or they can lecture her about the value of storing important documentation on the file server instead of her local machine and start one of several time consuming processes to rectify the situation.

It might be a server rather than a workstation - perhaps it is the SQL server in Accounting that requires a new NIC card, or some other high demand machine like the employee internet access proxy server. Whatever the situation, there are inevitably times at which password recovery will be required.

The recovery process must be simple for reasons of expedience. When support staff need to recover the Local Administrator password for a particular machine, they don't want to be given a paper form requiring multiple managerial signatures! You'll need a central database with careful access controls applied appropriately so that only your support staff can access it.

Alternatively, to avoid the central database you could utilize an algorithmic generation mechanism. This simply means that if you provide the same input to the generation algorithm, it will produce the same output. For instance, if you had a secret knowledge key such as "TrailBlazers" and the hostname of an NT machine, then you could run both character strings through the generation algorithm to create a unique password. Hopefully, you will choose a generation algorithm that provides unique, unpredictable and strong passwords. The uniqueness in this scenario comes from the use of the hostname, which must be unique in any NT domain. The recovery process uses the same technique to generate the password whenever you need it. This solution avoids the storage issues surrounding a central database, but introduces the need to manage the secret knowledge key.

In the event that recoverability is not necessary for your organization, you might consider simply applying random passwords to the Local Administrator accounts wherever possible. A good site for random password generators can be found at CNET's WinFiles.com.

Conclusion

A Local Administrator account password shared by many NT machines constitutes a security vulnerability and must be mitigated. If you cannot remove the shared password, then it is vital to minimize security risks by implementing frequent password changes and restricting network access for the Local Administrator account.

If it is possible to operate without a shared Local Administrator password, do so with the following precautions. If support staff does not require access to the Local Administrator account, then consider applying random passwords to this account on each machine. If necessary, make sure that steps are provided to allow for recoverability. I strongly encourage you to create your own solution (see example above) or pursue a commercial package to eliminate this vulnerability. Here's one of many "practical" solutions you can implement yourself:

Divide your enterprise machines into logical groups (Servers, Workstations, Mahogany Row, Sales, Bean Counters, etc..) Use a random password generator to generate passwords for each target machine. Store each hostname/password pair in a central database Secure the database such that support personnel responsible for each logical group can only access the stored passwords for machines in their logical group. Use PERL and the NetAdmin module to script the application of these passwords to each logical group.

Think carefully through the issues of passwords and recovery. Without unpredictable uniqueness you've gained nothing. Without strength you haven't improved your security position. Overlook recoverability and you might be unemployed. Charge blindly ahead without a plan for storage considerations, manual recovery procedures, generation algorithms, and a dissemination process to support staff - and you are definitely asking for a headache.

Read More...

Summary only...

The ISA Community

ISA helps automation professionals around the globe, with careers in engineering, R&D, technology, management, and sales. They work in a diverse array of industries, building, operating and maintaining the processes that do everything from monitor air quality to build airplanes.


Automation professionals are essential to every manufacturing process. All industrial endeavors are the result of a series of complex operations or systems. And the complex systems must be regulated using various measurement and control devices. And most often these systems and instruments employ programmable response and action devices - automation.


For automation professionals, technology is changing at a rapid pace, with more information out there than professionals have time to sort through alone. Through input from professionals throughout the world, ISA has the answer to nearly any technical question, saving the time it takes to search in multiple places for information.

By participating in the Society, automation professionals are smarter on industry issues, more valuable to their companies, and more effective at their jobs. Pure and simple, ISA is the one essential unbiased source to the world’s knowledge of automation.

Read More...

Summary only...

Detecting Complex Viruses

There are many metrics by which to measure the efficiency and effectiveness of an antivirus product and the response organization that is backing it. Some of the commonly used metrics today include the antivirus company's response time to new threats and well as the availability of proactive detection. But are these metrics enough?

The purpose of this paper is to examine the difficulties of detecting complex viruses, including polymorphic, metamorphic and entry-point obscuring viruses. Whether or not an anti-virus technology can detect these viruses can be a useful metric to consider when evaluating AV products.



In this article, we will show how complex viruses can offer an entirely different threat to organizations. It is important to step into the world of complex viruses by defining what a metamorphic, polymorphic, and entry-point obscuring virus is, understand when it is considered a real threat, and then see some real-life examples of complex viruses that have been discovered. This will lead into a discussion on the limitations of current anti-virus engine technology, and then finally, we will try to gauge the importance of detecting these complex viruses accurately, and in a timely fashion.
Overview of complex viruses
At one time, the aggregate number of viruses a product detects was considered a useful and popular metric, but this has largely been abandoned in favor of other more useful and scientific measures. Today, an AV company's response time to new threats and the proactive detection that their product offers are both considered more important evaluation criteria. But these criteria often do not consider complex viruses, a different kind of threat. Detecting a complex virus means detecting a threat that is either inherently difficult to detect, or exposes engine limitations that make it difficult to detect. We will start with a few definitions.

A polymorphic virus is a virus that changes its appearance in host programs. For instance, it encrypts its body with a different key each time, and prepends a decryption routine to itself. The decryption routine (known as the "decryptor") is mutated randomly across virus instances, so as to be not easily recognizable.

A metamorphic virus, by comparison, is a virus that also changes its appearance in host programs, however it does so without necessarily depending on encryption. The difference in appearance comes from changes made by the virus to its own body. There are several techniques that can produce such an effect.

One of these morphing techniques used by metamorphic viruses is with the insertion and removal of "garbage" instructions. These are instructions that have no effect on the function of the virus, but simply take up space and which can make analysis more difficult when they appear in large quantities. Another technique is to change the basic encoding of instructions at the opcode level. That is, switching between two different opcodes that are functionally-equivalent.

Perhaps the most complex transformation of a metamorphic virus is the replacement of entire blocks of logic with functionally-equivalent blocks of logic. Consider the task of multiplying x by 3. One expression of this is "3*x". However, an alternative expression is to replace the single multiplication with a repeated addition instead: "x+x+x". Both expressions will result in the same answer, yet they look very different.

An entry-point obscuring ("EPO") virus is a virus that gets control from the host program in an indirect way, rather than straightforwardly through the main entry-point. Typically, it involves patching a variable location in the host program code, perhaps a function prologue or an API call sequence, and redirecting control flow to the virus code from there.

An inherently difficult virus could be a polymorphic Win32 virus whose appearance varies greatly between samples. Regardless of what technology is available to detect the virus, the first hurdle is to analyze and understand the way the virus works, and invent an algorithm capable of detecting all virus replicants. This can be a daunting task, even assuming the ability to write the detection as a standalone program in a language of one's choice.
Determining the threat
Complex viruses do not represent a real threat until they are discovered outside of a laboratory and "in the wild". Herein lies the problem: the difficulty is in defining what it means for a virus to be "in the wild".

The industry definition of a virus "in the wild" is typically a virus that has been seen by at least two independent submitters in at least two different regions. However, this definition overlooks the existence of localized outbreaks, in which one or more companies in a single region might be heavily infected. In that case, a virus might be considered "in the wild" based solely on the number of submissions, but this can be misleading if people submit the same virus sample repeatedly. This also overlooks the case of virus "seeding", in which a virus is placed in a public location, such as the Usenet newsgroups, in the hope that enough people will be tempted to run it -- but no one actually does.

The fact remains that many of the most complex viruses are not especially widespread. If a sample of this virus has not been submitted by a "sufficient" number of outsiders, in a short period of time, it may be considered a "zoo" virus with minimal widespread threat. However, it's important to remember that this level of threat can change at any time.
Examples of "zoo" viruses
Examples of infamous "zoo" viruses include the complex Win32 viruses known as W95/SK (PDF document), W95/Zmist (PDF document), W32/Simile (PDF document), W32/Efish (PDF document) (from the W32/Chiton family), and W95/Perenast. Just mention any of these names to an AV researcher and watch their terror-stricken face. W32/Gobi (PDF document) and W32/Zelly are two of the most recent such brain-teasers. Both are very polymorphic, employing multiple encryption layers and entry-point obscuring.

These examples are all worth a few days (and nights) of work at the least, taking into account reverse-engineering, replicating the virus, and writing the detection signature. It can help a researcher to start writing the detection as a standalone C program before integrating it into one's AV product.
Limitations in AV engine technology
Unfortunately AV researchers do not have the luxury to write standalone programs from scratch to respond to new viruses. Instead they are constrained by a framework imposed by an AV product. The framework may be more or less flexible, and usually comes with a set of constraints that largely determine how efficient a response will be possible.

A comparatively simple virus affecting an emerging platform (say, Win64) may expose AV engine limitations that make it just as hard to detect as a tough Win32 polymorphic virus, in a subjective way -- depending on what AV engine technology is available to respond. Maybe the affected file format is not parsed by the engine, or only incompletely supported. Emulation may or may not be available. These factors greatly influence the ability to detect the virus.

Some of the new viruses that affected the Win64 platform in 2004, and were relatively difficult to detect, included W64/Rugrat (PDF document) (IA64), W64/Shruggle (AMD64), plus some new viruses with MSIL infectors. The corresponding executable file formats are varied, and even the job of picking a simple search string for an immutable virus can turn into a contortionist's exercise if the underlying AV engine lacks support for these file formats.

Naturally, there is the fear of an inherently difficult virus affecting an esoteric or emerging platform like Win64. Such viruses do occasionally surface in zoo collections, to the delight of no one except a virus researcher. Two examples of these new viruses, both released in early 2004, are MSIL/Impanate (PDF) and MSIL/Gastropod (PDF document) - viruses for the Microsoft .NET framework. The first of these, MSIL/Impanate, is an EPO virus. It appends its code to a random method in the file, and rebuilds the host around it. The second of these, MSIL/Gastropod, is a metamorphic virus. Its appearance is altered by the virus intentionally adding and removing "garbage" instructions.
The importance of detecting complex viruses
You may rightfully ask: why does it matter to detect such viruses, if they belong to "zoo" collections? Well, first of all, sometimes they do find their way into the wild. W32/Toal, for instance, a difficult polymorphic worm, was discussed on an emergency virus mailing list after being spotted actively spreading. Some complex viruses currently registered as zoo samples spread aggressively enough that they would stand a chance to infect machines in the real world if some mischievous soul were to release them.

Moreover, even for purely zoo viruses unlikely to ever cause problems in the wild, the response (or lack thereof) of AV companies to such viruses can reveal a lot about limitations in the engine technology available, and perhaps the skill and dedication of the response teams. Some companies provide detection quickly, in a matter of hours or days, while some others finally ship a solution after months of work (or years in some extreme cases, like W95/Zmist!), and yet other companies simply give up.

Besides the speed of response, the quality of detections also varies greatly, as measured by the ability to detect all samples of a polymorphic virus for instance, and doing so with an acceptable false-positive rate. What is an acceptable false-positive rate? While this varies from company to company, usually no more than a handful of false positives would be considered acceptable -- however, there are exceptions to this. One recent example, W32/Zelly, was allowed an enormous (up to 50%) false-negative rate by some anti-virus companies just to be among the first to detect it.

What if your AV company gives up on difficult zoo viruses? It certainly says something about either the flexibility of their technology, or the skill and dedication of their response team. What if tomorrow's Mydoom is heavily polymorphic? Will they be able to respond to it in a timely manner?

If you think it's an unlikely scenario, compare it to the following analogy: if you had to pick a surgeon, would you choose the one who carried out hundreds of successful open-heart surgeries, or the one who only ever did appendectomies? Even for an appendectomy, most would choose the first one.
Conclusion
In this article we've looked as some of the difficulties in detecting complex viruses, by first discussing what they are and why they can be difficult to discover. We then looked at a few examples of "zoo" viruses and how they can uncover limitations in various AV engines. As we have seen, finding complex viruses can be another useful metric in determining which anti-virus technology is best suited to the needs of an organization -- in addition to other common metric such as response time to new threats, and how effective the pro-active detection offered really is.

Read More...

Summary only...