IDSIPS Device Hardening

IDS/IPS Device Hardening

Like all your network devices, your IDS/IPS can and should be hardened against attack before you use it to harden your network. The reason is quite simple: if the attacker can disable your alarm system, they have free reign on your network.

Hardening PureSecure and hardening a Cisco IDS require two dramatically different techniques. As a result, I am going to cover the hardening process for each product individually.

Hardening PureSecure on Microsoft Windows

Because PureSecure runs on top of an underlying operating system, the most important thing you can do is to harden the HTTP server it uses for the console (for example, IIS on Windows) and the operating system itself, as prescribed in Hardening Windows Systems by Roberta Bragg (or Hardening Linux by John Terpstra, if you decided to run PureSecure on Linux).

Beyond those general instructions, however, are a few tasks that should be performed to harden the IDS. These tasks include the following:

• Implementing HTTPS

• Hardening remote access

• Hardening network interfaces

Implementing HTTPS

PureSecure is managed through a web-based interface running on Microsoft IIS. As a result, one of the first tasks is to implement HTTPS to ensure that all management traffic is encrypted and protected accordingly . The following steps detail this process:

1. Open the Internet Information Services administrative tool, connect to the web server, right-click the website, and select Properties.

2. Select the Directory Security tab and click Server Certificate. This will start the Web Server Certificate Wizard. At the Welcome screen, click Next .

3. At the Server Certificate screen, select Create a new certificate and click Next.

4. At the Delayed or Immediate Request screen, if you have implemented a public key infrastructure, select Send the request immediately to an online certification authority. (If you have not implemented PKI on your network, you must obtain a certificate from a public certificate authority [CA] by creating a request file and following their instructions to obtain the server certificate.) When you re finished, click Next.

5. At the Name and Security Settings screen, enter the appropriate name and select a bit length of at least 1024 bits. When you re finished, click Next.

6. At the Organization Information screen, enter the appropriate organization and organizational unit. When you re finished, click Next.

7. At the Your Site s Common Name screen, enter the name you want to use to connect to the server (for example, the fully qualified domain name). When you re finished, click Next.

8. At the Geographical Information screen, enter the appropriate country/region, state/ province , and city/locality information and click Next.

9. At the Choose a Certification Authority screen, enter the appropriate certification authority server for your environment and click Next.

10. At the Certificate Request Submission screen, click Next.

11. Once the certificate has been obtained and installed, click Finish to complete the wizard.

12. At the Directory Security tab under Secure Communications, click Edit. Check the boxes to require secure channel (SSL) and 128-bit encryption, as shown next, and then click OK. Click OK to close the website properties and exit the Internet Information Services administrator tool.

    

At this point, the server should only accept HTTPS/SSL connections.

Hardening Remote Access

The next step is to harden remote access by implementing users and IP address restrictions concerning who is permitted to log onto the management console. You do this by clicking Configure in the top bar and selecting PureSecure Console Users from the configuration menu. This will present you with the user configuration screen:

One of the nicer features is the ability to add an IP address restriction for the user account. If the user does not connect from a permitted IP address, they will not be allowed to log in. You can use a semicolon to separate IP addresses (for example, 192.168.1.25;192.168.1.26). In addition, you can use wildcards, such as entering 192.168.1.1-254 to permit all hosts on this subnet. You can also combine the two methods (for example, 192.168.0.1-254;192.168.1.1-254).

You can also specify five user roles:

• Super User This type of user has full administrative privileges, including the ability to add, edit, and delete other users (with the exception of the original admin account specified during installation).

• NIDS Admin This type of user has the ability to administer the NIDS portion of the PureSecure console, including editing the Snort ruleset.

• ESM Admin This type of user has the ability to administer the Extensible Service Monitoring portion of the PureSecure console, including the ability to add, modify, or delete any monitored services.

• SIV Admin This type of user has the ability to administer the System Integrity Verification portion of the PureSecure console, including the ability to add, modify, and delete the rules for the files and web pages being monitored.

• Regular users Regular users have none of the check boxes checked and can only view the PureSecure console, with the exception of adding new alert rules for themselves .

Hardening Sensor Network Interfaces

One of the problems that you have to address in deploying a sensor is that one of its network interfaces will frequently be connected to an unsecured network segment. For example, it is very common to deploy a sensor outside of the firewall to monitor the attack attempts that are hitting the firewall. This creates an obvious security issue: if the network interface is outside of the firewall, it is largely unprotected . For this reason, most sensors have two network interfaces. One network interface is known as the management interface and is connected to your protected network, typically on your management subnet. The other network interface is known as the monitoring interface and, as the name implies, is the interface that the sensor uses to monitor network traffic.

The most effective method of hardening this interface is to remove any and all protocol bindings from the interface. You can unbind the network protocols and services by accessing the network interface properties and unchecking all the components . This will prevent anyone from being able to communicated or connect to this interface because no protocols are bound to it.

Hardening Cisco IDS

Like all your other network devices, the Cisco IDS sensor should be hardened before it is deployed in your environment. You need to be sure that the IDS is secure and protected before you can expect it to adequately protect your network. We are going to look at the following hardening tasks:

• Restricting remote access

• Specifying users

• Configuring NTP

Restricting Remote Access

The first task in hardening your Cisco IDS sensor is to restrict which IP addresses can connect for remote administration. Remote access is controlled by the accesslist command. You can permit remote access by running the following commands at the CLI while consoled into the sensor:

 cisco-ids# configure terminal cisco-ids(config)# service host cisco-ids(config-Host)# networkParams  cisco-ids(config-Host-net)# accesslist ipAddress 192.168.1.105  netmask 255.255.255.255 

Once you have done this, you should be able to connect to the sensor via HTTPS/TLS, SSH, and the Management Center for IDS Sensors from the permitted IP address.

Specifying Users

The Cisco IDS sensor supports four user roles that define what operations can be performed:

• Administrator This role can perform all administrative functions on the sensor.

• Operator This role can view everything and can modify the following items:

  • Signature tuning

  • Assignment of virtual sensor configuration to interface groups

  • Managed routers

  • The Operator user s own password

• Viewer This role can view the configuration and any events but cannot modify anything other than the Viewer user s own password.

• Service This is a special role that can only be assigned to one account. This role allows the user to log into the underlying Linux operating system with a bash shell instead of using the CLI. This account should only be created at the direction of the Cisco TAC for troubleshooting purposes only.

Like many Cisco devices, the IDS sensor has a default username of cisco, which should be removed (the username cannot be changed) at the first opportunity. This can be done by first creating a new administrator-level user, logging in as that user, and then removing the cisco user.

You can add a new user via the GUI at the Device Sensor Setup Users screen by clicking Add, entering a username and password, and selecting the appropriate user role, as shown next. One of the nice security requirements of the IDS sensor is that it will not allow you to use a password based on a dictionary word. You must use letters and numbers or special characters . When you are finished, click Apply to Sensor.

You can then remove the cisco username by checking the user at the Device Sensor Setup Users screen and clicking Delete.

Configuring NTP

A critical component of your IDS logs is ensuring that they contain accurate timestamps of the activity being logged. You can configure the time settings for the IDS sensor at the Device Sensor Setup Time screen, as shown here:

The IDS sensor requires that you use NTP authentication, which is another nice security requirement that Cisco has implemented.