Re: ASK THE EXPERT- INTRUSION DETECTION SYSTEMS (IDS)

ciscomoderator · ‎10-31-2003

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Intrusion Detection Systems with Cisco expert Marco Caballero. Marco is a Quality Assurance Technical Lead at Cisco Systems, Inc. He specializes in the 4200 Appliances IDS Modules, Catalyst 6500 IDS Modules, and the Access Router IDS Modules. Marco joined Cisco Systems in 1998 as a result of the Wheelgroup acquisition. Feel free to post any questions relating to Intrusion Detection Systems. Remember to use the rating system to let Marco know if you’ve received an adequate response.

Marco might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through November 14. Visit this forum often to view responses to your questions and the questions of other community members.

david.d · ‎11-01-2003

Is Threat Response moving entirely to VMS in 2004 or will a stand alone version still be available? If a non-VMS version is to remain available should we expect enhancements to keep up with the version for VMS? Is email/page alerting not included with CTR now because it will be supported with VMS?

TIA

David

marcabal · ‎11-03-2003

Unfortunately I am unable discuss future versions of Cisco products on a public Forum. So as for the the future of CTR and VMS you can either contact your Cisco Sales Representative who can then contact the program managers for the 2 products, or wait for press releases revealing the new versions.

As for why email/page alerting is not in current CTR, this I can answer. When Psionic was purchased by Cisco they were a small company with limited development staffing. As such the features for their product Clear Response was driven by priorities. With the Clear Response customer base at the time, the email notifications were a lower priority than the other features being implemented.

When Psionic was purchased by Cisco, the Clear Response tool became Cisco Threat Response. The priorities for the first release were to give the product a consistent look and feel of the other Cisco management products and interoperability with the version 4.0 sensor that was being developed at the time. Once again email notifications had a lower priority and had to be dropped from the enhancement list.

Going forward we are hearing many more requests for email notifications and I have passed that information onto the program management team for CTR.

david.d · ‎11-13-2003

Here is a reply that came from a reliable unnamed source. I take this as very good news and hope it comes to be.

The current version of CTR is going to be enhanced and the program will be included in VMS. Cisco is not really changing the product, just putting it into VMS. The good news is they will shortly release a version of VMS called VMS Basic that will be free to you. It will have a limitation of 5 hardware devices, but it will include all of the VMS features, include CTR, when that product is rolled into VMS.

cscott · ‎11-02-2003

Marco,

I have some questions for you concerning the 4200 series Appliances, Threat Response, and the IDS signatures on the PIX Firewall's.

Threat Response/4200 Appliance Questions:

1) From my understanding, before the introduction of Threat Response technology, the IDS appliances were limited in their ability to actually prevent attacks. With the addition of Threat Response, are the 4200 appliances considered Intrusion Detection AND Prevention systems?

2) Can the IDS 4200 appliances sit in-line behind your firewall or router, or do they have to hang off a switch on a SPAN port?

3) If you have multiple interfaces on a firewall such as a Corporate segment and a DMZ segment, can one 4200 appliance protect both?

4) Do you have any options for failover other than purchasing another IDS appliance? For example, are there any "bypass" devices that allow traffic to flow past the appliance unrestricted in the event that it fails?

PIX:

1) Are there any plans to add more IDS signatures to the PIX firewall?

2) What is the level of interaction between the 4200 appliance and the PIX firewall? Is it purely a "block/unblock IP address" relationship?

Thank you in advance.

Chris Scott

marcabal · ‎11-03-2003

In answer to question number 1:

NO, the addition of Threat Response does not add to the IDS sensor's ability to prevent attacks.

Instead Threat Response is able to receive alarms from the sensors and do further analysis on the alarms before displaying them to the user.

In a standard setup without Threat Response, the IDS user would need to connect to the destination address of each alarm to determine what operating system and processes are running to determine if the destination address was vulnerable to the attack. If the destination address was vulnerable, then the IDS user would need to look at the logs on the destination box to determine if the attack was successful.

Threat Response was developed to automate some of these previously manual tasks. Threat Response will receive the alarm, then automatically check the destination ip address to determine it's operating system and what processes are running. If the destination machine is found to be vulnerable to the attack then Threat Response will also look for system logs to help in analyzing what ocurred.

This greatly reduces the amount of time an end user will spend trying to analyze the alarms generated by the sensor. The end user will be able to quickly see which alarms were not applicable to their network, and more importantly which alarms may have resulted in a successful attack. So the end user can spend there time on tracking down these attacks rather than tracking down false positives.

------------

In answer to question 2:

The IDS-4200 appliances are not currently "inline" devices, but instead are more like network sniffers. If your firewall or router is connected to a hub then the sniffing interface of the IDS-4200 can be connected to this same hub for monitoring. If your firewall or router is connected to a switch instead, then switch will need to be configured to send copies of the packets to the IDS-4200 through either a switch Span port or a Vlan ACL Capture port (Vlan ACL capture port is only supported on the Cat 6500).

-----------------

In answer to question 3:

Yes, one sensor can be used to monitor both segments. The IDS-4215, IDS-4235, and IDS-4250 each support the 4 port 10/100 card which gives each sensor a total of 5 sniffing interfaces. The IDS-4250 can also support the SX card with a single Gig fiber port resulting in 2 sniffing ports.

The IDS-4250 can also support the XL card with 2 Gig fiber ports.

You would just plug in each interface to monitor each of the different segments.

There are a few things to keep in mind:

1) You will need to connect each interface to a hub or span port.

2) The sensor will report which interface the alarms was detected on.

3) However, you will not be able to configure a different set of signature or a different filter set for each sniffing interface. The current version of the sensor supports only a single signature definition set that is applied to all of the sniffing interface.

4) In addition, if a user on the internal network attacks the DMZ and the sensor is monitoring both networks, then only one alarm may be generated for TCP connection based alarms. This is because the sensor tracks TCP state, and will detect duplicate packets. Since the same packet is seen on both segments the sensor will see the packet as a duplicate and will generate just the one alarm on with the interface listed for the first segment on which it was seen.

----------

In answer to question 4:

Since the sensor is not "inline" there is no need to purchase a "bypass" device. The sensor is just receiving a copy of the packets, so the hub or switch to which it was connected will just continue transmitting the packets.

If you are reffering to other IDS vendors that do offer "inline" IDS, then there are multiple possibilities.

Many networking devices have built in capabilities for handling failover. You can rely on using the existing failover capability in these devices to do your IDS failover.

For example:

If you are connecting your IDS to the interfaces of the firewall, then you may consider deploying failover firewalls. You would have an IDS sensor for each firewall. If one IDS sensor fails, then the firewall to which it is connected would detect that the link is down. The firewall could then failover to the 2nd firewall where the 2nd IDS is attached.

Similar capabilities exist for failover with routers and switches.

-------------

In answer to your first Pix question:

I work on the IDS Appliance Sensor and Module Sensor test team, and do not work on the IDS testing for the Pix Firewall. So I am not aware of what developments may be planned for the Pix Firewall IDS feature.

---------------

In answer to your second question on the Pix:

Yes, currently the only interaction between the Pix Firewall and the IDS Appliances is through the block/unblock functionality.

The IDS Appliance can connect to the firewall and execute the "shun" and "no shun" commands to block and unblock addresses on the Pix.

pannuzzo · ‎11-10-2003

Hi, regarding question 3: What about topologies when there is redundancy? where we have two swithes, two routers, two firewalls? how and where are the IDS used in thes king of design? One hub connected to both switches and the the IDS?

Could you recomend a topology for this without the need of using a second IDS?

Thanks in advence,

Paula Pannuzzo

marcabal · ‎11-10-2003

Let me take a couple of example topologies to see if I can answer your question.

Lets say we have 2 Pix Firewalls (Pix A and Pix B). Each Pix Firewall has 3 ports. One port is the "outside" connected to a router which is connected to the service provider through a WAN connection. Each Pix has a "dmz" port that is connected to a switch on a "dmz" vlan. Each Pix also has a "internal" port that is connected to the same switch, but this time to an "internal" vlan.

So you have Router A connected to Pix A which is connected twice to Switch A (once for the DMZ vlan and once for the internal vlan). Additionally you have Router B connected to Pix B which connected twice to Switch B.

Now I want to monitor these networks. The first question is which networks to monitor. In this situation I generally recommend monitoring the DMZ and internal vlans. Montoring the "outside" connection of the Pix is not as important if you are monitoring all of the other ports of the Pix. So in this scenario you would want to monitor the "DMZ" and "internal" ports of both Pix's.

Since both the "DMZ" and "internal" ports of Pix A are connected to Switch A, then you can usually use a Span port to monitor both these ports. Most switches support a port mirroring capabaility known as Span. Many switches will allow you to Span both the switch port connected to the DMZ port of the Pix as well as the Internal port of the Pix to a single port connected to a monitoring port of your sensor.

So that single monitoring port of the sensor will see both the DMZ and Internal traffic on the one monitoring port of the snesor.

This means in a redunandant network with 2 switches I would need a sensor with at least 2 monitoring ports. One port would be connected to a Span port on Switch A, and one port would be connected to a Span port on Switch B.

To know which sensor to buy would require you to know what traffic rate you will need to monitor. These easiest thing to do is to setup the Span port and connect it to a network sniffer that you network administrator will usually already have access to. Monitor it for a day or 2 to determine the max traffic rate. Connect it to the other switch and do the same thing. Add the 2 rates together to get an aggregate max traffic rate. You will want to purcahse a sensor that is rated higher than this aggregate max traffic rate and supports more than one sniffing interface.

For Cisco sensors you have the following options:

IDS-4215 - rated at 80Mbps

- supports the 4 port 10/100 card to give you 5 10/100 TX ports for monitoring.

IDS-4235 - rated at 250Mbps

- supports the 4 port 10/100 card to give you 4 10/100 TX and 1 10/100/1000 TX ports for monitoring.

IDS-4250 - rated at 500Mbps

- supports the 4 port 10/100 card to give you 4 10/100 TX and 1 10/100/1000 TX ports for monitoring.

- alternatively it also supports a 1 port 10000SX card to give you 1 1000SX and 1 10/100/1000 TX ports for monitoring.

- if you're rates are above 500Mbps, the IDS-4250 also supports the XL card. The XL card is a hardware accelerated NIC. The XL card has 2 1000 SX ports. The XL card will boost the performance of the IDS-4250 to 1Gbps.

All of the above options will work for monitoring the above topology since all of the above options have 2 or more sniffing interfaces.

---------------------------

Another topology would have separate switches for the "DMZ" and "Internal" networks. In this scenario Pix A would be connected to 2 switches A1 and A2. Pix B would be connected to 2 switches B1 and B2.

In this scenario you would wind up with 4 Span ports (one from each switch) and would require a sensor with at least 4 sniffing interfaces.

As long as the bandwidth out of each span port does not exceed 100Mbps then you could use any of the above sensors supporting the 4 port 10/100 TX card to monitor the 4 span port connections.

-----------------------

A similar topology as above would use hubs instead of switches. So Pix A would be connected to a hub for the DMZ and a hub for the internal network. When monitoring traffic on a hub all you have to do is connect the sniffing interface to the hub. All traffic on the hub will be copied to the monitoring port of the sensor without having to any special configuration on the hub (unlike switches ehich require configuring a span port).

Since there would be 4 hubs you would need a sensor with 4 sniffing interfaces.

------------------------

If the above doesn't answer your question or if you have a specific topology in mind then let me know and I'll see what I can recommend.

Marco

tomas.lada · ‎11-03-2003

Hello

I'm trying to configure IDS sensor, exactly I have two 4235 models.

I have two questions:

1.Can I delete IP LOG from IDS device manager or from system console? (I tried to capture traffic to one of my server and now I would to delete some

of these logs from system)

2. If I download and update new signatures, whats happen in configuration?

I would like to see all new signatures somewhere gathered (in one place) and then I could select only the ones which are interesting for me, because I have a servers on different platforms.

3. What about default action on sigantures, in a Signature configuration mode (in IDS manager) all signatures action are NOT filled, that means

NO ACTIONS take place when a attack is detected? What about in MONITORING -> EVENTS when I checked up some checkboxes, I still may see that

someone from X.X.X.X tried to attack my servers...(I have IDS pluged into our public network with sniffing interface) -> i.e. only the event are written to the event log by default?

4. I would like to easy configure signature updates, how i can do it? I know that IDS manager offers AUTO UPDATE function, but there is only a directory to fill up?

Does it have some algorithm to compare currently running signature engine and signatures update stored of ftp server? How I can automaticly process signatures update from CISCO ftp server and my LAN ftp server. (I would like to write some script which download a file named "IDS-sig-4.1-1-current.rpm.pkg or current_sig_update_blabla" which will be linked to actual signature file and then downloaded to my ftp server. IDS sensor then compare a current new file from tfp server with runing one). It is possible?

Thank you for your answer.

Regards

Tomas

marcabal · ‎11-03-2003

In answer to question 1:

On a version 3.x sensor the answer is "yes".

You would cd to the /usr/nr/var/iplog/new directory and delete the IP Log files you are no longer interested in.

On a version 4.x sensor the answer is "no".

The version 4.x sensor does not provide the user the ability to delete IP Logs off the sensor.

In version 4.x the IP Log data is stored in a sort of circular logging buffer. When the buffer is full the oldest IP Log data will be overwritten by the newest IP Log data.

Several users have requested the ability to delete IP Logs off the version 4.x sensor and this request has been passed onto the marketing for consideration for a future version of the sensor.

-------------

In answer to question 2:

When a signature update is installed on a sensor the new signatures are automatically merged into the existing configuration on the sensor. Also the default settings for existing signatures are also be updated in this same way.

There is not currently a method to group signatures by signature update level in order to see which ones are new.

I will pass on an enhancement request to the development to allow grouping by signature update level so you could which signatures are being added in each update.

To do this now manually you would need to look in the readme file for each signature update to see which signatures have been added.

Or you can execute the following commands on a version 4.x sensor to see the Signature Level where each signature was added:

configure terminal

service virtual-sensor-configuration virtualSensor

tune-micro-engines

show settings | include SIGID|SigVersion

----------------------

In response to question 3:

The creation of an alarm is not configured by the actions parameter. The parameter "Enabled" is what determines whether or not an alarm is generated.

If "Enabled" is set to "True" then an alarm will be created and sent through the fitlers.

If the alarm is not filtered out then it will be placed in the EventStore where it can be seen with "Monitoring->Events" in IDM, or be pulled by a management station like IEV or Security Monitor.

The "Action" parameter is only for additional actions beyond generation of the alarm. This includes TCP Resetting the TCP connection, Blocking the IP Address of Connection on another device like a router or firewall, and logging all of the packets to and from the source address of the attack.

Many users have been confused by the "log" action. The "log" action causes all of the binary packets to and from the source of the attack to be captured in a binary packet log we call an IP Log. Many users incorrectly thought that "log" had to be selected for the alarm to be seen in the "Monitoring->Events" tab in IDM or in the event viewer of the management tools like IEV and Security Monitor.

--------------

In answer to question number 4:

The auto update feature in the sensor was built to understand our naming conventions for the updates, and the version requirements for loading the different updates.

When you configure the autoupdate feature you configure the sensor to connect to your own ftp server (or scp server) and it provide it the proper username and passwords to gain access, and the directory in which to look for updates.

You also configure when/how often the sensor should check the FTP server for updates.

The user can then download any or all of the sensor updates from CCO and simply place them in this directory on their FTP server.

The sensor will determing it's currently running version, then connect to the FTP server to determine what updates are available. If any of the updates can be used to update the sensor then it will automatically download and install the update.

It will then automatically reschedule itself to look for another update.

Users often ask which updates they need to place in this FTP server directory.

The easiest approach is to look on CCO for the list of updates in the Latest Software page.

When you look on CCO you will generally see 2 or more links. One of these links is for "Latest software", another link is for "Archives". The additional links are for re-imaging and are only needed when re-imaging of the sensor is necessary.

All of the "Latest" updates needed by a sensor are placed in the "Latest software" page. When an update is no longer needed because it has been included inside a later update, the update is moved from "Latest software" to "Archives".

Sometimes we are a little behind in doing this cleanup, for example S53 to S57 are still in "Latest Software", but are included in S58 so shoudl be moved to "Archives".

However, you will also notice that IDS-K9-min-4.1-1-S47.rpm.pkg is included in this "Latest Software" page and will not be moved to "Archives". This is because it is a minor version file and contains features that are not included as part of the Signature Updates.

You will see that the file has "-min-" in the name instead of the usual "-sig-".

So in general the easiest method is to copy all of the updates from the "Latest Software" link on CCO to you FTP server's directory. The sensor will determine which updates need to be loaded and in what order.

NOTE: The sensor uses the name of the file to determine whether or not to install the file, so be sure to not change the filename when downloading from CCO.

The sensor can not automatically pull updates from CCO. This has been requested and is being considered for a future sensor version but is not currently supported. You can write your own automated script to pull updates from CCO. The CCO "Latest Software" link points to a FTP site. Your script would need to log into this FTP site and check for any new files and simply download all new files and place them on your own FTP server that the sensors would then access.

tomas.lada · ‎11-10-2003

Hello Marco

thank you for your answer.

So I have one question for email notification on product VMS 2.2. I read the archive and I configured this within IDS Security monitor. Then I started attack to my public server and I received some alarm message. It works fine. The question is: Can I see in email notification some additional information (like attacker and victim IP, signature version, time and attack count)?

Thanks

Regards

Tomas

marcabal · ‎11-10-2003

Security Monitor does not natively have this ability in the current version.

To have the other information included in your email notification requires you to use an external script to send the email rather than Security Monitor's native email capability.

In the "Rule Actions" window instead of selecting "Notify via Email" you would select "Execute a Script". When the script is called by Security Monitor it will pass it a large argument that contains the alarm information. The script will then parse the argument, convert it to a human readable format and then the script will send the email.

The TAC has created a script that will do all of this for user who are interested.

You can download the script and instructions for using the script from:

http://www-tac.cisco.com/~gfullage/SecMonEmail.html

jstewart · ‎11-11-2003

The link to the script doesn't work.

marcabal · ‎11-14-2003

I went ahead and posted the information fro, the link into the Forum.

Refer to this forum post:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.eea3f13/72#selected_message

marcabal · ‎11-11-2003

Both links are working fine for me.

Are you getting access to the page entitled: "Setting up email notifications with Security Monitor"?

In that page do you see the following:

If you have V3.x sensors, use this script.

If you have V4.x sensors, use this script.

The "use this script" are underlined and are links to the actual scripts.

You can click on the link and your browser will show you the content of the script and you woudl copy it all and paste it into a text editor, or instead of selecting the link you just Right Click on the link and select "save target as" in order to download and save it as a file.

If you are not getting access, try going to the cco main page and logging in before trying to access the link.