Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Charlie Stokes about Intrusion Prevention Systems. Charlie works as an Intrusion Prevention Systems (IPS) technical marketing engineer and has been a network security specialist for over eight years. Charlie came to Cisco as part of the Wheelgroup acquisition in 1998 that brought Intrusion Detection Systems (IDS) technology into Cisco. After the acquisition, he worked in the Technical Assistance Center (TAC) for two years covering the Security and VPN products. Since 2000, Charlie has been covering IDS/IPS products as the lead technical marketing engineer.
Remember to use the rating system to let Charlie know if you have received an adequate response.
Charlie 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 February 10, 2006. Visit this forum often to view responses to your questions and the questions of other community members.
Thanks for the response. One item I would question is that there is a Interface column set for Security Monitor and it does show the default name of the sensing interface for a given event - i.e. ge0_0, etc. I would just like to be able to name that a customized string and have that display vs. the default name.
May I ask one WAN connection question?
I need to draw my company WAN diagram. WAN connection are using Metro Ethernet, Frame Realy, ISDN. "show cdp neighbor" isn't work. What command can I check the connection and WAN bandwidth?
Samuel - there is no protocol similar to CDP to detect an IPS in a network. An IPS should be viewed as a layer two intelligent bridge, hence it has no IP address and will not respond to ARP requests so essential it has no MAC addresses. Bottom line is the device is stealth and connot be detected by protocol queries.
I'd like to know whether the following excerpt is incorrect or not:
"The non-alert generating actions (deny, block, TCP reset) go through the filters for each signature event unsummarized. The alert-generating actions are not performed on these >>> summarized <<< alerts; instead the actions are applied to the one summary alert and then put through the filters."
"If you select one of the other alert-generating actions and do not have it filtered out, the alert is created even if you do not select Produce Alert. To prevent alerts from being created, you must have all alert-generating actions filtered out."
This should probably be written as follows:
"There are two types of EventActions: Alert-generating (produce-alert, produce-verbode-alert, request-snmp-trap) and Non-alert-generating (all others). Both can be filtered out by Event Action Filters. If any of the Alert-generating actions remains in the Alert after filtering the non-verbose Alert is generated (??? not sure here ???).
The Non-alert-generating Actions cannot be summarized by alert-frequency mechanism. RST or Shun is always sent for the Individual alert. The Alert-generating Actions may be summarised. So-called Summary Filter do this. The Alarm or SNMP trap is sent for the Summary or GlobalSummary Alert.
Both Non-alert-generating and Alert-generating Actions can be suppressed by the event-counter mechanism (??? not sure, but this was the case in 4.1 ???). Actually this mechanism suppresses the Alert itself.
Alert-frequency mechanism and Event-counter mechanism are compatible and can be used at the same time for the same signature, but alert-interval parameter should not be used (??? not sure, but this was the case in 4.1 ???)."
Any comments on this?
Thank for taking the time to answer questions.
With IPS 5.1 is it possible to sniff a specific vlan on a trunk port? i.e 2 vlans one for voice and one for data, sniff the ethernet int of a wan router and only sniff the data vlan?
Since a sensor is a passive network device it has no control over what packets get sent to it for analysis (in either IPS or IDS mode). So in your case, much will depend on the capabilities of the switch. If it is capable of sending the required packets then the sensor will analyze them.
In IDS mode, the sensor has no specific capability to only watch certain vlans. It analyzes all packets sent to it. Filtering off unwanted packets would be part of the job of the switch. In IPS mode, this would be more doable but then those packets wouldn't reach their destination, so it's important to have a well thought out plan for what kind of traffic you plan to pass through an inline IPS device.
Is this in relation to something IDS/IPS related? If not then I won't be able to help much. If it is IDS/IPS related, then I have never heard of it. Google finds an answer for pairgain hdls in relation to T1 wan links so maybe you should be consulting the WAN forum.
I am new to IDS. My company ordered and received an IDS system with 2 sensors (one 4215 and one 4235) and Ciscoworks VMS 2.3. I have installed all of the components with little trouble.
I have questions about tuning my IDS system. Is there a guide to explain the why and how to tune IDS alerts?
When I open Security Monitor I have hundreds of alerts. For example I have many for Nmap UDP Port Sweep (sig. 4003). What is my next step? Any documentation you can point me to would be greatly welcome.
There are numerous general guides for tuning IDS sensors from a variety of sources.
The first step in your case could be sorting by the NMAP UDP port sweep events and figuring out what address is sourcing them. If 90% come from one address and the source address of the packet is a known port (like 53) then that is a prime candidate for filtering. So you could then create a filter for that source address and that source port (assuming you are running 5.x code). That would then prevent that event from firing in that specific instance. Because what the sensor saw is one source sending UDP packets to either one or more end destinations on a variety of ports. If the packets are from the same specific low port, then it's likely the sensor is mis-identifying normal network traffic (the replies from DNS queries in this instance).
Thanks for your reply.
Do you have any links for guides on tuning IDS? Most guides I have found tell you how to filter but give little information on how to investigate the alert to determine if it should be filtered.
100% of the Nmap alerts are sourcing from one IP address and port 111. My sensors are running 4.1 code (with sig. 215)
I will be upgrading to 5.1 soon.
Since 111 is very likely the portmapper service on (also likely) a unix server, it is a candidate for filtering. Since what is likely occuring is this, as many clients make connections to this service the sensor sees lots of packets coming from the Unix server on port 111 going to various high ports on many other boxes. This looks similar to an NMAP UDP scan. This is a false positive in v4.x sensors. v5.x improves upon the algorithm used in the sensor to try and filter out return traffic from legitimate connections. v5.x sensor code also allows much more granular filters including the source and dest ports of the events.