Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Intrusion Detection Systems with Cisco expert Joel McFarland. Joel is a Product Marketing Manager within the VPN and Security Business Unit at Cisco. He has been in the computer security industry for over five years with a focus in the area of Intrusion Detection technologies. Feel free to post any questions relating to Intrusion Detection Systems .
Joel may 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 April 12 . Visit this forum often to view responses to your questions and the questions of other community members.
I posted this question just last night to the forum but would like your take. I am about to rollout a 4210 running CSPM 2.3(f). I already have a 515 in place. Will the 4210 be able to pick up intrusions by hackers who have already gained entry into the network and access to usernames, passwords, services and have gotten backdoor and Trojan horse programs already on the network?
Part 2: Will Cisco be releasing some type of manager software for the 4200 IDS other than the bundled CSPM 3 in VMS? I would like to able to upgrade from the CSPM 2.3 but don't really need the VMS bundle.
Thanks in advance!!
Thanks for the question. IDS technology is very complementary to your existing PIX 515 firewall. IDS is capable of augmenting the layer 3/4 protection provided by the firewall allowing you in inspect the contents of both "permitted" and "denied" traffic to identify malicious activity, worms/viruses, etc. Out of the box, an IDS sensor treats both allowed and disallowed users on the network similarly -- if you do something bad, then it will act. So if hackers who "have already gained entry into the network" perform unauthorized commands or attacks against network services, OS, and applications then the IDS system can take action.
Part 2: Cisco is just weeks away from released an embedded management solution on the IDS 4200 series appliances that will allow users to browse in and configure these devices. This embedded manager is intended for smaller scale deployments while VMS/CSPM is intended for larger scale deployments.
Hope this helps!
I am interested in confirming if CSPM v3.x now supports PIX firewalls and Cisco Secure IDS's on one single platform i.e. no longer a CSPM vx.xf or i but just one product to do the lot.
Also would like to know the maximum DB size of the CSPM v3.x I believe the current DB size on v2.3.3 is 2GB, after which the DB just corrupts and the data is lost, which is a real pain if you actually want to prove you where under attack.
This may not be the correct forum to ask this question but I would also like to know when the next major PIX firewall code release is going to come out, I went to a product update seminar last year in which a statement was made that this was coming out this year (v7.0), one of the feature I am interested in is to monitor CPU usage via SNMP, which you cannot do at the moment.
There have been theoretical developments in the area of IDS: specifically abnormal traffic detection on your network. Papers have been written about neural nets and more recently rough sets as a method of detection.
Is Cisco going to pursue a new theoretical approach to IDS in a way that would complement the signature matching behaviour of the existing model?
There has been a lot of "buzz" in this industry recently around the different method or algorithms for attack detection. Cisco/WheelGroup has been shipping IDS product since 1995. Prior to this, many of the original developers were in multiple branches of the military and intelligence communities. They have significant experience and expertise with the different methods of doing intrusion "detection".
The current Cisco IDS product uses multiple techniques for identifying attacks -- stateful pattern matching, protocal parsing or protocol anomaly detection, and heuristic-based analysis.
Many of the "new" concepts under review are really not new. There are just a number of new-comers on the market that believe their approach is unique.
Cisco is actively working and research other detection methods and algorithms. It is important to note that one *single* approach is the cure-all. It is important to use multiple modes. Recent studies have shown that anomaly-based systems only 75% accurate and prone to high false positives. How would you model network the day before and the day after 9/11?
I'm going to use WS-X6381-IDS running SC6K-IDSM-2.5 software. I'm seeking a newest version of Cisco Secure Policy Manager that can support that IDS module.
Someone recommends me SEC-POL-MGR-2.3-R, but I wonder if it is an evaluation version of CSPM (limitting up to 3 devices and 20 days of trial use). Is this the such version ???
Pls. note that the latest version of IDSM sensor software is 3.0. There are number of features (e.g.
shunning, module overrun indicator, automatic signature updater, and others) and enhancements that are supported with IDSM 3.0 that are not supported with IDSM 2.5.
CSPM may be purchased through a number of different options, depending on the number of devices you would like to manage. The available options are: CWVMS-2.0R-K9 (VMS Bundle - includes CSPM (10 devices)), CWVMS-2.0UR-K9 (VMS Bundle -includes CSPM (unlimited)), & SEC-POL-MGR-2.3-R (for 3 devices).
The latest version of CSPM that supports the IDSM 3.0 (3) S13 is CSPM 2.3.3i S (17a), or higher.
Pls. refer to the info. below for details on the latest sensor s/w and management console s/w links:
The latest IDSM s/w is available at:
Updates for the Management Console:
Pls. let us know if you have any further questions,
I have currently deployed a IDS 4230 with CSPM2.3i. The IDS is monitoring one port of a switch & the other is connected to a management VLAN.
My concern is, since I am monitoring only one port, do I still have to create the whole network topology using CSPM? Or can I just simply create my management VLAN where my IDS is also connected?
You can just create the management vlan within the CSPM topology.
The topology is mainly used when configuring Firewalls and Routers, and is only used for IDS communication configuration when NAT addresses are being used between CSPM and the sensors.
The topology does not configure the IDS to know about which networks are Internal networks.
To configure the IDS to know which networks are internal you need to enter these on the Properties tab of each IDS sensor within CSPM.
Hey Joel, I have a basic one here that I haven't been able to find an answer to. On the new smaller switches with IOS like the 3548, I can't monitor multiple VLANs with one sensor (or at least I haven't seen a way to do it).
We're running 6500s in the core with CatOS 7.x and I would like to monitor multiple VLANs there with a 4230 that I'm about to install. I can enter the set port command without errors but am I truly getting traffic from other VLANs?
Thanks for any help.
For the smaller switches you have to use the span or monitor command to mirror packets from the switch to the monitoring port of the IDS sensor. The span command has different limitations depending on the switch being used. The 2900 and 3500 switches have different limitations than the 3550 and other switches. You would need to carefully read the documentation for your specific switch and software version you are running.
I looked up the User Guide for the 3548 using the latest software and it appears that span is only supported for a single vlan per span port, and you can't use the span command on a trunk port for multiple vlans.
The 3550 series switches on the other hand will allow multiple vlans to be spanned to a single port.
The 3550 documentation does also list an interesting guideline:
"A trunk port can be a source port or a destination port. When a destination port is a trunk port, outgoing packets through the SPAN port carry the encapsulation headers configured by the usereither Inter-Switch Link (ISL) or IEEE 802.1Q. If no encapsulation type is defined, the packets are sent in native form."
If the monitoring port for the IDS sensor is not setup as a trunk port then multiple vlans can still be spanned to it, and the packets will be transmitted without trunk headers to the IDS sensor. This scenario works well for the IDS appliance sensors.
If the monitoring port for the IDS sensor is setup as a dot1q trunk port then multiple vlans can be spanned to it, and the packets will be transmitted with dot1q trunk headers. The IDS sensor software can read the packets with dot1q trunk headers, but because of the increased size of the packets it will be necessary to get a special engineering driver from the IDS marketing team to handle the larger packet sizes.
So for practical purposes you can configure the IDS monitoring port to monitor multiple vlans (or ports from multiple vlans) and not setup the monitoring port to be a trunk port and your sensor will work fine with out the need of an engineering build.
I also noticed that for both the 3548, and 3550 switches, the span port can send traffic to the switch. So TCP Resets will not work when the IDS sensor is connected to the span ports of the 3548 or 3550 switches.
As for the 6500 series switches running the traditional Cat OS there are two methods of sending packets to the IDS monitoring port. You can use the span command similar to the other switches or you can use the capture feature of the Vlan ACLs.
If using Span in the 6500 with Cat it has a similar guideline as the 3550 in relation to span with destination ports that are trunk ports. Just like in the 3550 I would recommend you not configure the IDS monitoring port as a trunk port.
For more on the span command refer to:
The other option is to use the capture feature of the Vlan ACL. Any line the Vlan ACL with permit can also have an optional keyword "capture" packets which are matched by the permit line with the "capture" keyword are copied to siwtch ports that have been designated as capture ports. The IDS monitoring port can be configured as a capture port. If the IDS monitoring port is only in a single vlan and is configured as a capture port, then it will only monitor captured packets on that single vlan. If the IDS monitoring port is configured as a dot1q trunk port and a capture port, then it will monitor captured packets from all the vlans being trunked.
For more information on the capture feature refer to:
Some examples also exist in the documentation for the IDS Module:
Correction to Paragraph 4:
"I also noticed that for both the 3548, and 3550 switches, the span port can send traffic to the switch"
should have been
"I also noticed that for both the 3548, and 3550 switches, the span port can NOT send traffic to the switch"
How do you tell on a 4210 Sensor if it's dropping packets? I'm getting an unusually high number of 1208 alarms and suspect the sensor canno thandle the data rate.
In CSPM execute the View->Statistics menu option from within Event Viewer.
or in OpenView execute the Security->Advanced->Statistics->Show.
This will query the sensor for the statistics of it's monitoring interface.
At the bottom of the statistics will be a line for DLPI drops.
Ordinarily this line should read:
DLPI drop: 0
This line indicates packets that were dropped by the interface driver because it was not able to pass the packets to the analysis code.
This number is the number of dropped packets since packetd was started.
Just because this number is not zero, does not mean there is anything to worry about.
The sensor will occasionally drop packets when the sensor is being reconfigured or first coming up.
To get a feel if the sensor is dropping packets execute this command, and wait a minute or two and re-execute.
See if the DLPI drop has increased.
If the counter does not increase then you are not dropping packets.
If it increases by a small amount you likely have nothing to worry about.
Another possibility for the 1208 alarms could be configuration.
Our defaults for the Fragmentation Reassembly feature have changed, but previously configured sensors are not updated with these new defaults when they are upgraded. We have increased several of these parameters from their original values.
Compare your existing configuration and perhaps increase your values to match these latest defaults.
ReassembleFragments On # Fragment Reassembly On/Off
ReassembleFragmentTimeout 30 # Seconds to wait for a completed Dgram
NOTE: All of the above options may not be configurable through CSPM or the Unix Director.
We do not use the CSPM or Director, we use the IDSs in a stand-alone configuration. So how can we tell on the sensor itself if it is dropping packets? I run 'nrget .... StatisticsOfPacketSocket' to get byte and packet counts as seen by packetd, but I'm still suspicious of packets being dropped.
I have tried to look at the sensor statistics from within the Event Viewer. The Statistics option is greyed out. Is there something I need to have highlighted when I want to use it?
I have tried the "nrget" command on the IDS but I keep getting Usage errors or timeouts. Any help would be appreciated.
Try selecting an alarm from that sensor prior to selecting the menu option.
To run the nrget command on the sensor, you will need to login as user netrangr.
Then execute the following:
nrget 10008 hostid# orgid# 1 StatisticsOfIp
replace hostid# and orgid# with your sensor's host id and org id numbers.
nrget 10008 6 100 1 StatisticsOfIp
CSPM is only supported on WIN NT. WIN 2K support will not be provided for CSPM (for IDS). Going forward, you can expect to have WIN 2K support on newer platforms.
I am interested in intercepting UDP 45000 alerts and writing a agent to process them.
I haven't looked at this yet but was wondering if there is any detail on the protocol etc anywhere that will help.
The Postoffice protocol that runs on UDP port 45000 is a Cisco proprietary protocol that has not been publicly published.
For end users requiring access to the alarms, errors, and commands transferred across UDP port 45000 we have implemented alternate methods.
This data is logged on the sensor in the /usr/nr/var directory.
It is also logged on the Unix Director in the /usr/nr/var directory.
Users can also pull the information from the CSPM database using the cvtnrlog command.
The sensor can also be configured to ftp the log file from the sensor to an ftp server when the log files is closed on the sensor.
Unix Director users can also use the eventd program to execute custom scripts when alarms of a certain level are seen.
The custom scripts could generate pager alerts, create SNMP traps, or anything else that the user can script.
CSPM users can also execute custom scripts when alarms of a certain level are seen.
The only thing end users can do is receive a live feed directly from Postoffice, however, several of Cisco Security Partner Companies have built in a Postoffice SDK (Software Development Kit) in order to receive real time feeds through postoffice from our sensors.
The Postoffice SDK is only available to Cisco Security Partner companies.
I will pursue this with our internal sources in cisco. I understand that this is available via Cisco ?
We want the SDK for a commercial product we will be launching.
The Cisco IDS SDK is provided to members of Cisco's AVVID Partner Program as way for them to integrate their solutions with ours and hence augment existing capabilities of Cisco IDS in areas of reproting, management & redering, etc. It is not a shipping product that is available for purchase.
Hi Joel, I have been having an issue with route down route up notifications. I get hundreds a day. I have been looking through the postofficed.conf file trying to determine if I should increase the timeout before the process is considered dead. In a previous message one person indicated that there is a HeartBeatIntervalMultiplier command that can be adjusted. However, my system logged an error when I tried that command.
My postofficed.conf file shows the following
# Sensor Version: 3.0(1)S4
# Sensor OS: SunOS
My question is what number should I adjust, if any, and is this a real fix or is there something else I should be looking at.
The HeartBeatIntervalMultiplier is only available in later versions of the sensor.
Try loading the 3.0(5)S17 Service Pack and then adding that token to the postofficed.conf file.
The HeartBeatIntervalMultiplier was previously hardcoded to 3 in the code, but was recently made user configurable in ServicePack 3.0(3)S12.
Postofficed will wait HeartBeatIntervalMultiplier times HeartBeat number of seconds for the other machine to respond to it's heartbeats.
The default HeartBeat is about 5 seconds.
The default time to wait for response would be 15 seconds (3 times 5) seconds for a response.
The HeartBeat is configured on a per route basis. It is the last number for each route in the routes file. In the following example the HearBeat for the route would be 10 seconds.
Example entry in routes file:
director.cisco 1 10.1.1.2 45000 1 10
Increasing the HeartBeatIntervalMultiplier and/or HeartBeat will help to reduce the number of route up/downs when communicating across slow links or great distances.
There are also other situations that cause Route Up/Downs that are not affected by the HeartBeatIntervalMultiplier and HeartBeat.
Every time the sensor is reconfigured it will shut down all existing connections and reopen them. So both the sensor and director/CSPM will generate route downs/ups when the sensor is reconfigured.
If the director/CSPM is reconfigured (such as adding a new sensor), then the director/CSPM will shutdown all existing connections and then reopen them. So in this situation the director/CSPM as well as ALL of the sensors communicating with it will each generate route down/up alarms.
It can also happen that the two postofficed processes (one on sensor, one on director/CSPM) can get out of sync with one another. When one of them detects this then the postoffice will auto correct itself by closing down and reopening the connection. This can be seen if the postoffice is under heavy load transferring large amounts of alarms, but even then it is fairly.
The Route Up and Down alarms used to have the severities hardcoded, but in Service Pack 3.0(3)S12 the severity levels were made configurable.
Refer to 3.0(3)S12 readme for more information.
I have received and worked with the engineering dot1q driver for iprb0 and reversed interface settings on a 4230 as per docs using the lastest software.
I found the spwr0 port because very unstable and kept going up and down no matter what switch settings I used and the iprb0 didn't decode the dot1q traffic correctly.
When I reversed my changes, everything was back to normal.
Do you have any info on this or whether Sensor version 3.1 will have a driver that work with dot1q traffic?
I have 2 IDS in my network that are not eporting events back to the CSPM. I spanned the switch ports for the appropriate traffic and I can verify (through a protocol analyzer) that UDP 45000 is getting to-and-from both IDSs to the CSPM Console. What is the best way to troubleshoot this on the local IDS devices? Are there commands to see what services are running or should be running?
Thanks in advance.
This could be related to a communications issue.
Try nrconns on sensor
Check event viewer's connection status pane for CSPM comms status.
Then check all IDS comms entries for sensor and cspm: host id, host name,
org id, org name, ip address.
You may have to open a TAC case to resolve this issue if you cannot discover anything from the above.