downloads advanced host intrusion prevention with csa phần 7 pptx

Builtin Policy Details 167 NOTE Policies for Cisco CallManager and Unity Server are also available from Cisco. Check the CallManager and Unity sections of the Cisco website for software updates for the policy export files. These files can then be imported into the CSA MC using the import function found under the Maintenance heading in the MC. The following section takes a look at a few of the application policies and what protections are included. Some of the policies examined are specific to a single operating system, whereas others are applicable to all CSA supported operating systems. Web Server—Microsoft IIS—Windows This module contains the Common Web Server Security Module and the Microsoft IIS Web Server module. The Common Web Server Security Module contains rules that apply to any web server running on a Windows host, whereas the Microsoft IIS Web Server Security module contains rules that are specific to IIS. The rules in this module are shown in Figure 8-4. Figure 8-4 Web Server—Microsoft IIS—Windows Rule Policy 168 Chapter 8: Basic Policy The overall effect of these policies is to secure the web server against common attacks and exploits encountered by IIS servers. Some of the policy highlights include: • Common Windows file exploits are denied. • IIS can act as a server for FTP and HTTP. • Any application trying to write to IIS executable directories causes the local user to be queried. Because this rule is applied to a server and a local user is not commonly logged on, this rule usually results in a denial. • CSA restarts IIS if the service does not respond to HTTP or FTP requests or if the service does not respond to the service control manager. • IIS and Apache web services are protected from Cross-Site Scripting (XSS) attacks, SQL command injection attacks, common log file exploits, and common Windows command execution exploits among others. Web Server—iPlanet—Solaris The iPlanet Web Server policy is similar to the IIS module in that it is a combination of a generic Common Web Server Security module and the more specific iPlanet module. Many of the protections provided by this module are the same as the IIS module, except that they use Unix commands and objects instead of those found in Windows. Rules for XSS, SQL command injection, and common log file exploits are present in this module just as in the IIS module. The rules in this module are shown in Figure 8-5. Figure 8-5 Web Server—iPlanet —Solarisp Policy Builtin Policy Details 169 Web Server—Apache The Web Server—Apache policy applies to all three supported operating systems. It contains six modules: the Common Web Server Security module for each of the operating systems and a specific Apache Web Server module for each operating system. The protections offered by this policy are similar to the protection in the preceding two policies. What makes this policy so convenient to use is that it is applicable to all three operating systems, so the same policy can be used for protecting hosts of all three types. Notice that the Linux and Solaris rules in this policy are mixed together in the rule listing. This is because Linux and Solaris use the same conventions for objects, such as system directories and devices. This view allows you to compare the policy differences between the two operating systems on the same screen. The rules are also handled and processed essentially the same way on Unix and Linux systems. The Windows rules are in a separate list because of the wider differences in operating system type. This module is shown in Figure 8-6. Figure 8-6 Web Server—Apache Policy There are few differences between the Microsoft IIS policy and the Apache policy as applied to a Windows machine. The bulk of the rules from each policy come from the Common Web Server Security module. This module contains most of the data access 170 Chapter 8: Basic Policy control rules, although the IIS and Apache-specific modules address file access control and application execution control rules relevant to the web server application. The same is true of iPlanet and Apache on Solaris. No other Web Server packages have built-in policies for Linux because Apache has the largest market share by far for Linux web servers. Microsoft SQL Server 2000—Windows The Microsoft SQL Server 2000 policy simply contains the Microsoft SQL Server 2000 Rule module. The purpose of this policy is to protect the SQL Server system and data from harm and contains rules specific to SQL Server 2000. This policy allows SQL Server to write SQL data files, but no remote network applications can write those files. It also lets SQL Server write only SQL data files so that the xp_cmdshell stored procedure cannot be exploited to write to the file system. A service restart rule is also included to restart SQL Services in the event it is unresponsive. Other Builtin Policies CSA includes other policies out-of-the-box that are useful for protecting individual systems and the network as a whole. The Network Quarantine policy restricts all network traffic to or from a host and is useful for machines infected with a virus or malware. The Cisco Trust Agent (CTA) policy is used to enable CTA communications between the host and network devices running Network Admission Control (NAC). The previously mentioned Network Personal Firewall policy protects Windows and Linux desktops from network-based attacks. Other policies such as the Application Behavior policy and Security Classification policy do not enforce any security, but add processes to dynamic application classes used by rules in other modules and policies. The next chapter discusses the Application Behavior policy in greater detail. Summary Throughout this chapter you saw that a security policy has different forms, functions, and purposes. The written security policy is made up of other documents, such as incident handling procedures, data classification guidelines, and information protection mechanisms and standards. CSA is the tool that actively enforces the written security policy using CSA policies. The CSA policies are made up of modules, which in turn are made up of rules, and applied to different system groups. Although Windows, Linux, and Solaris are fundamentally different operating systems, CSA provides each one a high level of protection. To safeguard hosts running different applications and services, application specific policies can be used to protect web servers, database servers, and other infrastructure servers. [...]... exported from another CSA MC (or a previous export from this CSA MC), you should understand which items are duplicated and renamed and also which items replace the original Additionally, you should understand that part of every CSA software upgrade, such as moving from CSA v4.5.1.628 to CSA v4.5.1.639, also includes an import process as part of the upgrade During software upgrades on the CSA MC, the imports...Preparing for the CSA Tuning Process 177 User-State Sets Overview User-state sets are matched on an endpoint when specific users or groups are in use on the system You can both define as many of these sets as you want and use the state sets that are pre-installed with the CSA MC These objects allow you to enforce policy that is not normally allowed... determined the system is infected Preparing for the CSA Tuning Process 179 • Security level—If you allow users to see the CSA in the system trays of their computers, you can also allow them to use the security-level selector that allows them to change the setting to Off, Low, Medium, or High These settings can enforce different policies as defined by the CSA administrator • Network address ranges—This identifies... applying specific allow rules to the system temporarily while the administrator is logged into the system Administrative CSA control—You might define a rule module that allows the CSA to be viewed or stopped only when the matching state set is active User-State Set Configuration 178 Chapter 9: Advanced Custom Policy System State Sets Overview System state sets are matched on an endpoint when various criteria... installation without causing the CSA administrator the headache of providing updated policy every time a new installation occurs The key to everything in the previous example is the dynamic application class and the amount of intelligence and control it provides you Mastering this concept ensures a successful deployment The list of rules we added, as seen in Figure 196 Chapter 9: Advanced Custom Policy 9- 17, ... problem with the last two options is that the CSA administrator would need to be involved in every daily task In addition, it’s possible that the security is completely removed in test mode rather than just slightly degraded and controlled In this example, we use the following procedure to start to configure the objects Step 1 Create a user-based state set named INSTALL-TECH that matches a local group with. .. Set 184 Chapter 9: Advanced Custom Policy Step 2 Create a policy named Install Allowed Policy and also a rule module named Install Allowed Rule Module The rule module should be enforced only when the INSTALL-TECH state set matches The configuration for the rule module can be seen in Figure 9-5 The rule module should be associated with the policy Figure 9-5 Install Allowed Rule Module with State Set Step... rules will temporarily apply to the system 186 Chapter 9: Advanced Custom Policy Step 6 Create a policy named Remote Registry Access Policy and a rule module named Remote Registry Access Rule Module that you can associate to the policy This rule module should be enforced only when your state set matches on the system Step 7 As shown in Figure 9 -7, add a Registry Access Control rule to the rule module... Figure 9 -7 Remote Registry Access Rule Remember, if you apply this correctly, you allow access to the registry remotely only after a successful authentication of a specific user or group member This is much more secure than allowing all access to the registry at all times Sample Custom Policies 1 87 Securing the System When Away from Home When systems connect to your network, corporate firewalls, intrusion. .. matches IP addresses that are not part of your address space Also, be certain that the CSA MC is not reachable as shown in Figure 9-8 When a system does not have an IP address you own and also cannot reach the CSA MC server, you can assume that the system is not local Figure 9-8 OFF-NET Systems Set 188 Chapter 9: Advanced Custom Policy Step 2 Create a policy named OFF-NET Protection Policy and a rule . many other Host Intrusion Prevention System (HIPS) products. Become familiar with two types of state sets: user and system state sets. These sets provide mechanisms that enable a CSA administrator. Administrative CSA control—You might define a rule module that allows the CSA to be viewed or stopped only when the matching state set is active. Figure 9-1 User-State Set Configuration 178 Chapter 9: Advanced. part of every CSA software upgrade, such as moving from CSA v4.5.1.628 to CSA v4.5.1.639, also includes an import process as part of the upgrade. During software upgrades on the CSA MC, the imports