Lesson 1: Establishing Intrusion Detection for Public Servers

Lesson 1: Establishing Intrusion Detection for Public Servers

The most vulnerable servers on your network provide Internet services, such as Web services and e-mail. To defend against intrusion into these servers, you must be aware of attacks as they occur. In this lesson, you examine the kinds of intrusion incidents you can expect to encounter on public servers, and how to detect them.

To complete this lesson, you will need

  • A domain controller for the domain.fabrikam.com domain

  • A Microsoft Windows 2000 Server computer to act as a decoy server


After this lesson, you will be able to

  • Understand the concept of intrusion detection

  • Configure Windows 2000 for strong auditing

  • Configure Microsoft Internet Security and Acceleration Server (ISA Server) to forward unused services to a decoy

Estimated lesson time: 45 minutes


Common Network Intrusions

Attackers who attempt to gain access to your network without knowledge of your network architecture use a standard sequence of attacks. They start with information gathering, then attempt to exploit known vulnerabilities, and finally move on to more difficult to perpetrate impersonation attacks, which involve attempting to take on the identify of a valid user by guessing or stealing an account name and password, stealing a smart card, or appropriating a certificate.

To gain information about your organization and your public targets, most hackers who attempt a sequence of attacks against a network will

  • Check your public DNS records to determine the IP addresses of your Internet servers.

  • Use port scanners to scan your Internet servers and identify the services you are running.

  • Probe all services found to determine which set of vulnerability attacks to use against these services.

Once they've obtained this information, they will

  • Send attacks that exploit known bugs in common services to attempt to gain remote administrative access. These attacks typically send executable code along with malformed message syntax designed to execute the sent code.

  • Attempt brute-force impersonation attacks.

  • Perform various denial of service (DoS) attacks if they have been unable to gain access.

Knowing how hackers work is the first step towards detecting and stopping their attacks. When you understand the basic process that hackers use to attack your network, you will be able to differentiate their patterns of usage from the patterns of regular users.

Detecting Network Intrusions

Intrusion detection is the methodical process of searching for signs that hackers have attacked your network. Just as there are numerous methods for attacking a computer, there are many ways to detect attacks.

Detecting Denial of Service Attacks

Although denial of service (DoS) attacks aren't really intrusions, detecting them is still considered to be intrusion detection. While you might be able to detect some types of DoS attacks by examining event logs or real-time status of the performance monitor in Windows 2000, you won't be able to detect the majority of DoS attacks. Reliably detecting DoS attacks requires intrusion detection software, because Windows 2000 doesn't log every processing action that occurs so it can't match actions to specific known attacks.

To defend against DoS attacks, you use two methods: hardening the TCP/IP stack on the targeted server by implementing IP filters and opening only those ports that you need for the services, and filtering known DoS attacks with a firewall that can detect them. You should use both methods in tandem.

Any attacks that the firewall filters are attacks you don't have to consume server resources to defend against. But firewalls cannot filter all types of attacks; public servers need to be able to defend themselves against attacks that firewalls can't filter. For example, many firewalls can recognize and block synchronous idle character (SYN) floods originating from a single IP address, but if the source addresses have been randomized, there's no way to distinguish a SYN flood from a high volume of valid connections. There's certainly no way to determine which attempted connections are part of a malicious flood and which are valid users trying to reach a server.

Even if you could somehow filter out SYN floods that have random source addresses, you won't be able to defend against all types of DoS attacks, because clever DoS attacks come disguised as dramatic increases in valid traffic.

Consider what would happen if your Web site URL were posted on a very popular news outlet. If millions of readers were to click the link to your site, your Web server might not be able to service the majority of the requests. While not malicious, this certainly causes a DoS problem, which happens frequently when popular Web sites contain links to small sites. If a hacker included a link to your site on a popular Web site and misrepresented its contents to increase the appeal to the site's audience, the members of the audience would be unwitting participants in a malicious DoS attack that you would not be able to distinguish from a sudden enormous increase in traffic.

Detecting Vulnerability Attacks

Vulnerabilities are bugs in public services that hackers can exploit to cause some behavior that the software is not supposed to perform, such as crashing servers or gaining access to them as an administrator. Vulnerabilities exist in all software, but hackers concentrate on finding them in public services, such as those on Web and e-mail servers, that they can reach from the Internet.

It is not possible for a server to specifically detect vulnerability attacks. If the affected service could detect the problem, it would not be vulnerable to it.

You will have no warning of effective vulnerability attacks and there is very little that you can do about them except to keep your security fixes up to date. The only other potential solution is to use a security proxy to scan the protocol for malformation before delivering it to the intended service, but there is no guarantee that proxies will detect the malformation that causes the vulnerability to be exposed.

However, attempted vulnerability attacks are sometimes recognizable as strange characters sent in a URL or in FTP upload file names that contain characters that are not valid. While the server might not recognize which bug the characters represent, it can be configured to drop connections that make suspicious-looking requests. This is exactly how the IIS Lockdown tool and the URLScan tool recognize malicious attempts to exploit Internet Information Services (IIS) Server and drop the connection before the attack can succeed. When properly configured, URLScan is able to prevent many of the attacks against IIS without being specific to the attack. You can find these tools at http://www.microsoft.com/technet by searching on their names.

Even though a tool like URLScan can protect an unpatched IIS server against vulnerabilities, you must keep your security fixes up to date. URLScan and similar tools can't guarantee effectiveness against all types of exploits in the future.

Detecting Impersonation Attacks

There is no way to detect a hacker who is logging on using a valid user account name and password. However, truly public servers should be configured to process only anonymous requests for public services. An attempt by a specific user to log on from the Internet could then be detected as an attack.

For services that necessitate a log on, such as Microsoft Outlook Web Access or extranet access, require Secure Sockets Layer (SSL) and certificate authentication to ensure that only valid users can connect to the public service. This prevents hackers from using brute-force attacks to determine account names and passwords and simplifies and automates authentication for valid users.

If an attacker authenticates against a machine that normally processes only anonymous requests by using a user account, the logon attempt can be logged, and the user's activity in the system can be tracked. By separating public systems into different domains or workgroups from those of the interior private systems, you can keep hackers from being able to use account names that are valid in the interior of your network to attack public servers.

Windows 2000 can detect all impersonation attacks if hackers do not know account passwords. Auditing logon events and configuring logon policy will log the occurrence of brute-force password-guessing attempts in the security event log and will stop most attacks except against the administrator account, which cannot be locked out and should therefore be renamed.

Because brute-force attacks against the administrator account cannot be stopped, rename the administrator account to something that is not obvious, and create a new limited user account with the name "administrator." This way you can detect attempts to log on as administrator and lock the account after a few attempts. Remember that domain member servers have two administrator accounts the domain administrator account and the local machine administrator account. Make sure you rename both the local administrator account on public servers and the domain administrator account for domains in which they are members.

Using a Decoy Server

Detecting intrusions into a Windows 2000 test machine is easy: you enable auditing to record every access of every account, file, object, and use of rights by every user account. Then monitor the security logs, and trigger an alert any time a file is accessed that isn't being explicitly served. Unfortunately, this level of auditing cannot be performed on a production server because the processing and logging overhead is extreme and would prevent the server from processing valid requests.

Detecting intrusion into a production Windows 2000 server is extremely difficult. All three types of attacks (exploiting vulnerabilities, impersonation, and DoS) can be crafted to simulate typical usage that cannot be distinguished from routine valid access, and busy production servers don't have the resources to enable the types of auditing that would be required to reliably detect intrusion.

The solution to this load problem is to use a decoy machine to detect intrusion and use a production machine to service valid requests. This can be accomplished using any modern firewall or security proxy to create a decoy server.

A decoy server (also called a honeypot server) is simply a server running an unsecured (or lightly secured) version of the same operating system as your production server. The theory is simple: all types of access are forwarded to the decoy except those that you want to serve publicly, which are forwarded to the actual server. To an outsider, the two machines look like a single machine, but all extraneous services go to the decoy rather than the real server.

Creating a decoy is simple, but it requires a firewall or a proxy server. On your firewall or security proxy, you can forward to this decoy machine the TCP ports of incidental services that you don't use but that are commonly available on unsecured servers. The decoy machine would be located in the DMZ but configured to block outbound connections. The point of this machine is to be attacked and exploited and to alert you to any access at all. Simultaneously, you can use your firewall or security proxy to forward the TCP ports of your actual public services to your production machines in the perimeter network. Figure 13.1 shows how this configuration works.

figure 13-1 using a decoy to detect intrusion

Figure 13-1. Using a decoy to detect intrusion

A hacker who scans your public IP addresses will see what appears to be a single unprotected server. The valid service port forwarded to the actual server will appear among all the service ports forwarded to the decoy server. Architecture probes that attempt to determine which operating system and types of services are running will reveal no difference between the machines because the decoy and the production server use the same operating system. Using common identification methods that are forwarded to the decoy, hackers are lured to the decoy server by easier exploits than those that can be perpetrated against your actual service ports. Because the decoy server alerts you to any access attempt, the intrusion attempt is revealed immediately.

Valid users of the public service will not reach the decoy server at all, and their requests will be processed with no additional overhead. The intensive auditing and intrusion processing on the decoy server do not affect the ability of valid servers to function and do not affect valid users.

The Psychology of Decoy Intrusion Detection

For a decoy to be effective, hackers must believe that the decoy is a valid server. This means that the combined list of ports from the decoy and the valid server should be similar to those a hacker would see when attacking a regular server. Most servers aren't completely unprotected, but they might have unprotected services that hackers can exploit. This means that you don't want your decoy servers to seem completely unprotected. However, you should add unprotected services that are forwarded to the decoy server to attract hackers away from attacking the valid service ports. For example, you might want to forward ports 135, 139, and 445 (which provide file sharing) to the decoy while forwarding port 80 to your valid Web server. Hackers who want to attack your Web server will be attracted to the file-sharing ports because they provide numerous ways for hackers to get in.

Hackers expect public servers to be protected by a firewall, so they will expect to see only those services that an administrator has explicitly made public, and they will expect ping responses to be blocked. What a hacker hopes to find is a protocol that administrators use for remote administration or to transfer files, such as FTP or the RDP protocol used by Terminal Services.

There are a number of services in Windows 2000 that are so tempting to hackers that the detection of their presence in a port scan invites attack. These services are almost certain to be attacked by any hacker who finds them, because they can provide easy administrative access if the administrator has not been careful. Commonly attacked ports include

  • The NetBIOS session port (139)

  • SMB over TCP port (445)

  • FTP (21)

  • Telnet (23)

  • SMTP (25)

  • POP3 (110)

  • PPTP (1723)

  • L2TP (1701)

  • RDP (3389)

By configuring your decoy to alert you when these services are accessed, you'll catch any hackers who don't know you're running a decoy. Even if they know you are running a decoy, to avoid immediate detection, they would have to know which services are really serviced and which are trapped by the decoy, and they would not be able to run a port scan.

Clever administrators will even include an offline copy of their Web site host files on the decoy server, so the hackers will find what they expect to find if they are able to compromise the decoy system. This keeps the hackers online longer, lengthening the audit trail and creating a stronger body of evidence.

Determining Which Service Ports to Decoy

The best way to create a decoy is to mimic standard services on the server using standard services on the decoy. If you want to mimic an Exchange server, install Exchange on the decoy, along with other services that hackers like to exploit, such as IIS and Telnet. Then forward to the actual server only the mail service ports you need to use, and forward the remainder to the decoy.

It's common to decoy an e-mail server. But the only service port you need to make public for an Exchange server is port 25 SMTP. Hackers will expect to see POP3 and IMAP4 on a mail server as well, so you can forward those ports to the decoy.

If you use SSL to secure public services such as Web, POP3, and SMTP, you gain an additional decoy advantage: SSL secured services don't run on the same ports as their traditional counterparts, so you can forward the SSL ports to the real server and forward the non-secure ports to the decoy.

Determining Where to Place a Decoy in Your Network Architecture

The ideal place for a decoy server is on a network segment of its own, if you have a firewall that can support four zones (public, private, perimeter, and decoy). ISA Server can be configured to support four zones, but the configuration is very complex. The reason for this four-zone methodology is to prevent hackers from gaining a foothold inside your network once they exploit the decoy.

Your network must block access from the decoy as if it were a hacker's machine, because the decoy is designed to be exploited.

To simplify configuration, reduce hardware costs, and remain compatible with firewalls that do not support additional network segments, you can place decoy servers in the perimeter network with public servers. If you do this, you should ensure that all of your public servers are configured to filter and drop packets from the decoy server and that your private-side firewall drops any packets from your decoy server.

You should never place decoy servers inside your private network, because an exploited decoy would allow hackers inside your network.

The Hole in Decoy Intrusion Detection

Decoy intrusion detection is not perfect. It cannot detect attacks against your valid services because it does not see them those attacks are forwarded to your valid public servers. On the other hand, your public servers cannot be exploited using any protocol they do not specifically serve. If a server serves only Web pages, it can only be attacked by Web server specific vulnerability and DoS attacks that are specific to HTTP. Everything else goes to the decoy.

This means that you must use a strong security proxy to scrub the protocols going to your public server, and you should use any additional security tools that will increase the security of your public services. The URLScan tool from Microsoft is an excellent example of this type of security tool it allows you to block suspicious URLs and malformed HTTP requests, and it logs them so that you can preserve evidence of them. All of your public service protocols need to be hardened using similar tools. Once hackers find that they cannot exploit the public protocols, they'll move to other protocols that are actually served by your decoy, and you'll be alerted when they do.

Performing Event Analysis and Preserving Evidence

When all auditing measures are enabled, the security log creates a strong body of evidence. The complete set of events that occur during an attack is called an audit trail. By examining the audit trail, you can reconstruct the hacker's activities with a considerable degree of precision. Your study might reveal attacks you were not aware of, or actual statistics you can use to justify new security policies.

When you initially configure your decoy server, and before you deploy it, create an image of the configuration and store it offline. You will use this image to refresh the decoy after each time that it is exploited.

The key to discovering hacking methods and eventually holding hackers responsible for their actions is preserving evidence. To do this requires that you preserve the entire state of the decoy server's hard disk, by removing it at the time you stop the attack.

As soon as your decoy server alerts you to an attack in progress, watch the event logs and open the event monitor to reveal the attack as it progresses. Allow the hackers to continue working as long as you can be certain that they are not able to use the decoy system to perpetrate further attacks against your network.

When you are no longer comfortable allowing the hacker to continue, and before the hacker is able to begin destroying evidence to cover his tracks (such as by deleting event logs), power off the server (without a shutdown), remove the decoy's hard disk and replace it with a new disk containing a fresh image of the decoy server's operating system and configuration. Then configure your firewall to block the hacker's IP address before it reaches the decoy or any services on your network.

The removed drive can be retained and analyzed for evidence by booting it in a recovery machine that is not attached to any network. Retain the full audit logs, changed files, and copies of anything the hacker placed on the computer. This hard disk can be turned over to law enforcement officials or examined by computer forensics experts to determine as much as possible about the identity of the hacker.

Practice: Detecting Intruders

In this practice, you configure an ISA server to protect an Exchange server by using a decoy server. In this case, you configure the decoy to run Telnet and IIS, and forward all e-mail protocols to the decoy. You will use the ISA server and the Exchange server configured in Chapter 11, "Public Application Server Security," along with a decoy server installed in this chapter.

To perform this practice, you must start with a default installation of Windows 2000 including IIS named exchange01, without membership in the domain and with an IP address of 192.168.241.160. For the purpose of this exercise, you should consider the 10.0.0.0 network to be the public Internet and the 192.168.241 network to be the perimeter network to minimize the amount of configuration you need to perform on the existing ISA server. This configuration will have the effect of changing the ISA server's role from being the private-side firewall to being the public-side firewall, and placing the decoy server inside the perimeter network instead of the private network. In an actual deployment, you would configure your public-side firewall to forward ports to the decoy server using the firewall's management interface.

Exercise 1: Configuring a Decoy Server

In this exercise, you create a decoy server to attract traffic destined for an interior server. The decoy will be configured to retain security log information until the log is cleared manually, and to shut down if the security log becomes full. This guarantees that the decoy server will shut down under a sustained attack, which will alert you to the attack in progress.

To configure an ISA server to forward ports to a decoy

  1. Log on to the ISA server as the administrator.

  2. Click Start, point to Programs, point to Microsoft ISA Server, and click ISA Management. The ISA Management console appears.

  3. Expand Servers And Arrays, ISA, Publishing, and then click Web Publishing Rules, as shown in Figure 13.2.

    figure 13-2 isa web publishing rules

    Figure 13-2. ISA Web Publishing Rules

  4. Click the Create A Web Publishing Rule icon. The New Web Publishing Rule Wizard appears.

  5. Type Decoy Server in the Server Publishing Rules Name box, and click Next. The Destination Sets page appears.

  6. Select All Destinations, and click Next. The Client Type page appears.

  7. Select Any Request, and click Next. The Rule Action page appears, as shown in Figure 13.3.

    figure 13-3 the rule action page

    Figure 13-3. The Rule Action page

  8. Select Redirect The Request To This Internal Web Server.

  9. Type 192.168.241.160 in the IP address box, and click Next.

  10. Click Finish to close the New Web Publishing Rule Wizard.

  11. Close the management console, and restart the server.

To configure a decoy for audits and alerts

  1. Log on to the decoy server as the administrator.

  2. Click Start, point to Programs, point to Administrative Tools, and click Local Security Policy. The Local Security Settings management console appears.

  3. Expand Security Settings, Local Policies, and click Audit Policy. The Local Security Settings management console appears, as shown in Figure 13.4.

    figure 13-4 audit policy in the local security settings management console

    Figure 13-4. Audit Policy in the Local Security Settings management console

  4. Double-click Audit Account Logon Events. The Local Security Policy Setting dialog box appears.

  5. Select Success, and select Failure in the Audit These Attempts group, and then click OK.

  6. Repeat steps 4 and 5 for each of the policies listed.

  7. Select Security Options in the console tree.

  8. Double-click Shut Down System Immediately If Unable To Log Security Events. The Local Security Policy Setting dialog box appears, as shown in Figure 13.5.

    figure 13-5 local security policy setting dialog box

    Figure 13-5. Local Security Policy Setting dialog box

  9. Select Enabled, and click OK to close the dialog box.

  10. Close the Local Security Settings management console.

To manage log retention for the decoy

  1. Click Start, point to Programs, point to Administrative Tools, and click Event Viewer. The Event Viewer appears, as shown in Figure 13.6.

    figure 13-6 the event viewer

    Figure 13-6. The Event Viewer

  2. Right-click Security Log, and click Properties. The Security Log Properties dialog box appears as shown in Figure 13.7.

    figure 13-7 the security log properties dialog box

    Figure 13-7. The Security Log Properties dialog box

  3. Select Do Not Overwrite Events (Clear Log Manually).

  4. Type 2048 in the Maximum Log Size box.

  5. Click OK to close the Security Log Properties dialog box.

  6. Close the Event Viewer.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

  1. Which type of attack attempts to log on with a user's password?

  2. What type of attacks cannot be detected using a decoy server?

  3. What is the purpose of saving event logs after an attack?

  4. Where in the network should a decoy server be placed?

  5. What tool recognizes intrusion attempts through URLs on a Web server?

Lesson Summary

  • Denial of service (DoS) attacks attempt to slow down, stop, or damage a server, usually by overloading it with requests. Some DoS attacks cannot be detected until service is disrupted. You can prevent most of them by keeping software up to date, hardening the TCP/IP stack on the server, and using a firewall to detect known types of attacks.

  • Vulnerability attacks take advantage of vulnerabilities in the operating system or software services. New exploits might be impossible to detect, but known exploits can be prevented by installing security fixes. Tools like URLScan can recognize suspicious requests that might indicate this type of attack.

  • Impersonation attacks attempt to access the system using a valid user's password. The Windows 2000 password policy and auditing features can detect and prevent attempts to guess passwords. If an attacker knows a user's password, it might be impossible to distinguish the attacker from the actual user.

  • You can use a decoy server to detect intrusion attempts. This tactic provides services strictly for the purpose of logging intrusion attempts, using a server that can be easily replaced and that contains no important data. This tactic can also help you to both detect attacks early and preserve evidence when they do occur.



MCSA(s)MCSE Self-Paced Training Kit Exam 70-214(c) Implementing and Administering in a Microsoft Windows 2[.  .. ]twork
MCSA/MCSE Self-Paced Training Kit (Exam 70-214): Implementing and Administering Security in a Microsoft Windows 2000 Network (Pro-Certification)
ISBN: 073561878X
EAN: 2147483647
Year: 2003
Pages: 82

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net