Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn about troubleshooting IPS with Cisco expert Marco Caballero. Marco is a Quality Assurance Technical Lead at Cisco Systems, Inc. He specializes in the Cisco IPS 4200 Appliances, Cisco ASA 5500 IPS Modules, Catalyst 6500 IDS Modules, and the Access Router IDS Modules. Marco joined Cisco Systems in 1998 as a result of the Wheelgroup acquisition. Prior to his current position, Marco tested IDS sensors for the Air Force and was a software tester with Wheelgroup.
Remember to use the rating system to let Marco know if you have 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 September 21, 2007. Visit this forum often to view responses to your questions and the questions of other community members.
In an enterprise using an in-line IPS deployment with CSM/MARS for mgt/mon of IPS devices/functionality, what is the recommendation for a lab to test IPS changes (signatures,filters,code,etc) in production? Looking for an enterprise perspective.
when deploying an IPS (inline monitoring) in an Enterprise environment there is always a concern that a new signature update will have a negative affect on your traffic.
The concern I have heard most often from customers is that a false positive for a new signature may cause a deny of legitimate traffic on the network.
To address this concern I would recommend being able to deploy new signature updates first on a test lab sensor before pushing them out to your deployed sensors.
But you need to ensure that you have traffic in your lab that accurately simulates the traffic seen in your network.
If you have a very good understanding of the applications running on your network then you may be able to simulate these services in your lab, and see how the sensor responds to the traffic.
However, quite often there are additional applications that your users may be relying on that you do not have simulated in your lab.
I have seen 2 good methods to account for these additional services.
1) Use a network sniffer to capture a days worth of traffic into in a pcap file. Then use a replay tool to replay the traffic through the lab sensor.
2) Use a network TAP to actively monitor live traffic on the network and simulate running an line sensor connected to the tap. Go ahead and configure the sensor for inline interface pair mode, and plug the 2 interface of the pair into the 2 interface of the network tap. This way you can trick the sensor into thinking it is inline, when in actuallity it is monitoring copies of the packets from tap.
In any of the above test scenarios I would recommend adding in an Event Action Override for Risk Ratings 40-100. Analyze what alerts are triggered before the upgrade, and what alerts are triggered after the upgrade. Any alerts triggered after the upgrade can then be analyzed to determine if it s a new or tuned signature from the update, and if the triggering is from an actual attack or from a false positive.
You can also look in these alerts to see if the traffic would be denied. Any alert that shows a denial should be looked at closely because these are the alerts that may cause a network problem if it is a false positive.
If you do find a false positive, then you have 3 choices.
1) Notify Cisco, and wait for another update with the fix.
2) Deploy the update, and try to follow up immediately with a signature tuning that disables the signature after the update is applied.
3) If you know what specific addresses or ports are triggering the false positive you could first create a filter to filter out the false positive, and then deploy the signature update.
Many users may not realize that you can apply the filter for the new signature even before the signature update is applied.
Tunings of the signature itself must be applied AFTER the signature update, but Filters can be created even BEFORE the signature update.
So if you do have a concern about a False Positive, then you can put in the filter even before you apply the signature update.
Similar methodology can also be used for other upgrade types (Service Packs, Major Updates, and Minor Updates).
Because you are using CSM and CSMARS I also recommend a second set of these boxes in your test lab. Major and Minor updates to the sensors will also generally cause CSM to be upgraded as well. You will similarly want to test the new CSM/MARS versions before deploying them to you live systems.
I've always struggled with the event counter and alert frequency settings for signatures. I've never quite been able to create settings that are predictable.
Would it be possible to get a good description of these settings and a couple examples of how they work together?
The signature I'm working on currently is 6250-0, FTP Auth Failure. I am trying to tune so that for a given source address we only get 2 alarms per day, the initial alarm and a summary alarm. When I say "per day" I really just mean for some long period of time...say at least an hour (but a day would still be better).
When discussing the differences between the Event Counter and Alert Frequency configurations I like to use the following 3 terms:
Match - A match happens when the regular expression is seen within a connection.
Inernal Signature Event - This is the internal triggering of the signature. Actions are added and filters are checked against this Internal Signature Event.
Alert - This the writing of the actual alert into the eventStore so a user can see it in the CLI or IDM "show events", or pulled by an event viewer like IEV or MARS.
For most signatures a single Match will generate a single Internal Signature Event. And for most signatures a single Internal Signature Event will generate a single Alert that a user can view.
However, this is not always the case as you have seen with signature 6250-0 FTP Auth Failure.
With 6250-0 one Match does NOT correspond to one Internal Signature Event.
Instead if you look at the Event Counter section for that signature you will see:
What this says is that you have to have 3 Matches instead of 1 before an Internal Signature Event will be created. Those 3 matches have to be within connections that correspond to teh "event-count-key".
The IDM screen provides a better explanation of the event-count-key.
Here are the list of options that you would see in IDM and the CLI:
IDM - CLI
Attacker address - Axxx
Attacker address and victim port - Axxb
Attacker and victim addresses - AxBx
Attacker and victim addresses and ports - AaBb
Victim address - xxBx
In the case of 6250-0 the event-count-key is set to AxBx. What this means is that the 3 matches have to happen within connections from the same Attacker address to the same Victim address. Since the ports are not included in the key, this means that the 3 matches do not have to happen in the same connection and can instead happen in 3 different connections.
If the key had been AaBb then the 3 matches would have to be seen within the one connection.
The "specify-alert-interval" is set to "No" so this means that the signature is not requiring that the Matches be done with a certain tim period. There is still a limit of time inwhich the 3 matches need to happen, but it is a dynamic limit instead of a configured limit. When a Match is detected the sensor will try to keep that information in its memory for as long as possible. However, if the sensor is heavily loaded then it may need to free up that memory in order to monitor new connections. If the 3 Matches happen fairly close together then the first 2 will likely still be in memory when the 3rd match is seen, but if there are a few minutes between matches then it is possible that the first 2 Matches may no longer be in memory when the 3rd Match is seen so the Internal Signature Event will not be triggered because it sees this 3rd Match as instead being the 1st Match.
The next question is generally what happens with additional Matches after the 3rd. I have seen a few different scenarios over the past several years. I am not positive how this specific signature is treated for additional matches, but here are a couple of possibilities.
If the additional Match is seen while the first 3 are in sensor memory then the additional Matches may just be counted and never cause any additional Internal Signature Events. Alternatively the engine may have been coded to begin counting again from 1 with the 4th Match. In which case an additional Internal Signature Event may be triggered every 3rd Match. I am not sure which of the 2 approaches has been taken with the latest IPS versions.
Also keep in mind that if the sensor needs more memory for monitoring new connections it may free up older memory and forget about the previous Matches. Any new Matches would then be considered a 1st Match.
Now that the Internal Signature Event has been created because of 3 Matches, the sensor will now add actions to that Internal Signature Event.
It will first add all of the actions configured for that specific signature, and it will then proceed through the Event Action Overrides and add additional actions if needed.
There are several event actions that can cause an actual Alert to be produced. These actions include:
If any one of these actions are added to the Internal Signature Event then the Alert Frequency configuration of the signature will need to be checked.
If none of these actions have been added to the Internal Signature Event then no Alert will be produced. This is common when you want to deny or tcp reset an attack without generating an actual Alert entry.
The Alert Frequency for 6250-0 is configured as the following:
The alert frequency has 4 possibilities:
Fire All - where every Internal Signature Event will create a corresponding Alert
Fire Once - where only the First Internal Signature Event will create a corrspending Alert. Additional Internal Signature Events within the same Summary-Key will not generate Alerts.
Summarize - An initial Alert will be generated for the first Internal Signature Event for each Summary Key. Additional Internal Signature Events will be counted but not create additional Alerts, and instead a single Summary Alert will be generated at the end of the interval.
Global Summarize - An initial Alert will be generated for the first Internal Signature Event for that signature. Additional Internal Signature Events will be counted but not create additional Alerts, and instead a single Global Summary Alert will be generated at the end of the interval.
The Summary Key is used in Fire-Once and Summarize modes. Similar to the event-count-key the summary-key will designate when the Internal Signature Events should be counted per attacker address, victim address, etc...
Most of these modes can then also be automatically upgraded to the next higher mode if the Internal Signature Event rate gets to high.
Fire All can be automatically upgraded to Summarize if the summary-threshold is exceeded.
Fire Once can be automatically upgraded to Global Summary if the global-summary-threshold is exceeded.
Summary can be automatically upgraded to Global Summary if the global-summary-threshold is exceeded.
However, remember what I mentioned above about the sensor freeing up memory and forgetting about Matches when it needs the memory for new connections.
The same thing can happen with Fire Once, Summary, and Global Summary modes.
The sensor may need to free up memory and may be forced to forget about some of the prior Internal Signature Events. This can cause the sensor to unexpectedly downgrade back to a lower mode, or for a summary interval to be cut short and for the count to start back again at 0.
In the case of 6250-0 the default setting is in Summary Mode.
The first Internal Signature Event between the same Attacker and Victim addresses will generate an Alert. Additional Internal Signature Events within the next 15 seconds will be counted and instead a Summary Alert will be generated every 15 seconds.
The signature will never upgrade to Global Summary.
For your particular situation I would suggest setting the signature back to defaults, and then change the summary-interval to as large a number as possible.
Because of memory constraints the summary interval may periodicaly be cut short, but it will reduce the number of times an actual Alert is generated.
Thanks for the detailed response Marco. I think that explains why I've struggled so much. It appears it will be difficult to really create signatures that fire in a predictable way from a timing perspective.
On a related note:
We are running Version 6.0(3a)E1. Why do the summary alarms look like normal alarms (perhaps this is a feature of v6 to deal with the summary alarm filtering issue)? My recollection is that summary alarms used to contain a running count, which was kind of useful.
The count should be included as part of the details field in the Summary Alarms.
Are you not seeing the counts in your Summary Alarms?
One thing I have seen is that some of the IPS viewers do not always show you all fields of the alert. And it is possible that the viewer is not showing the field that contains the counts.
When checking on issues like this you will want to check on the alert in the "show events" output directly on the CLI.
The CLI will always show you all fields in the alert, and can help determine what might be missing in the alert viewer tool you are using.
If you are not seeing the summary counts in the "show events" output for a Summary Alert then please let me know.
You can send me an email with the "show events" CLI output for that particular Summary Alert along with the output of "show version" and "show configuration" from your sensor. And I can take a look and see what is going on.
Also be sure to not confuse a single alert based off multiple Matches with an actual Summary Alert.
An alert based off multiple Matches will not have the counter, while a true Summary alert Will contain the count.
Also realize that with Summary mode there are 2 alerts that get generated. The first alert gets created (and is not a Summary), and then at the end of the Interval is when you actually get the Summery Alert and it is the Summary Alert that will contain the count.
So if you think it should be in Summary Mode and see a regular alert, then it may just be the first alert for that address set and so will not have any summary information yet.
I am Debashis Dey ,My CCNA Certification has expired on 26th April 2007 , And I want it for the CCNP Exam.
How can we get it through
I have not been involved in the Certification Exams, and am unable to answer your question.
I would suggest trying the Career Certifications Forum:
The users on those forums may know who to contact to answer your question.
As you are expert in IPS/IDS, I have a small question:
I have two IPS 4260 connected to 3750G switch and I want to load balance between them.
Note: I need two IPS works in promiscuous MODE.
I am not aware of any method for automatic load balancing of 2 promiscuous sensors when using a 3750G switch.
The only promiscuous sensor appliance load balancing I am aware of with Cisco switches is with the Cat 6K running traditional Cat OS.
Cat OS offers a feature called VACL Capture and functions somewhat similarly to Span.
With VACL Capture you can capture to an Etherchannel of ports. The Etherchannel distribution algorythm can then be used to load balance the traffic on up to 8 switchports (connected to up to 8 sensor appliances).
This capability, however, is limited to VACL Capture and does not work with Span the last time I checked.
In addition the capability last time I checked worked with Sensor Appliances and the IDSM-2 when using Cat OS, but only worked with IDSM-2 when using Native IOS. I have heard that Native IOS has recently implemented this also for Sensor Appliances, but I have not checked into it.
But from a 3750G perspective I am not aware of any Promiscuous Load Balancing methods.
Now if you were looking for inline mode rather than promiscuous, then there does exist a load balancing option.
You can configure the sensors for inline-vlan-pairing mode where the sensor does inline monitoring between 2 vlans on the same port.
You would configure 2 sensors for inline vlan pair mode using the same 2 vlans on both sensors.
Connect each sensor to the switch and configure the switch port to be a trunk port for the 2 vlans.
You woudl then combine the 2 trunk ports into an EtherChannel, and then the Etherchannel would load balance between the 2 trunk ports (between the 2 sensors).
Why the switch will choose the same physical link in an Etherchannel for returning traffic???
Most of the Catalyst switches implement Src-only or Dst-only Etherchannel load-distribution. This is the global switch setting. Outgoing traffic will choose the link with the inline sensor 1 and incoming traffic - may choose the link with the sensor 2, right?
To work properly the switch must have it's Etherchannel load balance distribution set to "src-dst-ip".
This way the client packets and corresponding server packets will both be load balanced to the same sensor.
The switch will XOR the 2 addresses together and so packets with source A and dest B get balanced to the same port as packets with source B and dest A.
The other load balance algorithms will not work correctly as you described in your post.
The client packets will get balanced to a different sensor than the server packets for the same connection.
There is one algorithm that might look like it would work better: "src-dst-port" For all packets that contain a full UDP or TCP header this works great, but it has a problem with Fragmented packets. The additional fragments do not have TCP or UDP port information so they fall back to being load balanced by src-dst-ip. This can cause the initial fragment to be load balanced to a different sensor then the remaining fragments.
So not even the "src-dst-port" algorithm will work.
So you will need to set the load balance algorithm to "src-dst-ip" for the IPS load balancing to work properly.
our Corporate Network we have IDS 4215 , Last week I have Upgraded to IPS by IPS-4215-k9-sys-1.1-a-5.1-1.img file , and it is working,
My problem we had lincence for the IDS,
Now This IPS asking for the Licence , Can I use Same Licence for the IPS ( I belive Not ), if i want to Buy new Licence , will i get any benifit for the IDS ( I can upgrade IDS Licence to IPS Licence)
The difference between IDS and IPS for the Cisco IDS/IPS product lines is primarily just a difference in file and product names, and what feature you turn on when configuring the sensor.
If it is an older product then the name starts with IDS. If it is a newer product then the name starts with IPS.
But the majority of the older IDS and the newer IPS products are all capable of both Promiscuos mode (IDS mode) as well as InLine mode (IPS mode).
So you can have an IDS sensor running in IPS mode.
The exception is only the NM-CIDS which can only run in Promiscuous mode. All other IDS and IPS sensors can run in either IDS or IPS mode.
So with an IDS-4215 running version 5.1 or higher you can choose whether to run it in IDS mode by configuring it with Promiscuous interfaces, or run it in IPS mode by configuring it with inline-interface-pairs or inline-vlan-pairs.
The license itself is not specific to the mode you are running in.
The license does not restrict what features you use on the sensor, instead it only restricts what Signature Updates can be applied to the sensor.
The license has an expiration date that coincides with the expiration date of your Cisco Service for IPS maintenance contract for the sensor.
The license allows you to install any Cisco Signature Update released prior to that expiration date.
Once expired the license will prevent you from installing any newer signature updates.
Because the license does not affect functionality there is no change in the license when upgrading software versions or when switching from Promiscuous(IDS) mode to InLine(IPS) mode.
If you still have your license from version 5.0, then simply install it on your 5.1 sensor (or even upgrade to 6.0 and use the same license).
Just be sure your Cisco Service for IPS maintenance contract is up to date so your license will have an expiration date in the future. This will ensure you can all of the latest signature updates.
I also noticed that you installed the System Image file (has -sys- in the filename).
For normal upgrades from a lower version to a higher version you do not need to use the System Image file. The System Image file will erase your current installation (including the license) and install a fresh version with default configuration.
FOr a normal upgrade you want configuration to be maintained. So for a normal upgrade you want to use one of the upgrade files. The upgrade file will install the same version as the System Image file, but will keep your license and your configuration in tact.
The latest upgrade file for the 5.1 version is IPS-K9-5.1-6-E1.pkg.
The System Image files should rarely be used. They are not intended for upgrades, but rather for emergency situation where the sensor has been corrupted and fresh factory installation is needed.
I in need of advice on the following scenario. We plan to upgrade our replace our Pix512 firewall. We got three options from our vendor to chose from:
The first option is redundant Pix515e UR/fail-over mode and the cheapest solution.
The second is redundant ASA5510 with security plus package that costs a bit more.
The third solution is redundant ASA5520 far the most expensive solution.
We need to provide for at least 100 hosts on our LAN that use outside internet, about 20 VPN's from outside users to the network and VPN tunnel from Pix515 in our another facility. The demand is expected to increase. What would be the best choice for us.
First in terms of hardware. What are the key enhancements in ASA over Pix lines. The pixes uses Intel PIII. Is ASA using different architecture? In particular are the Pix 515e and ASA5510 equivalent in terms of their capabilities.
Second in terms of licensing. I'm kind of new to this stuff and want to be clear with the idea since I worked more with routes and switches. In all three options we need redundancy. With Pix for fail-over I understand that active device has UR type of license and the standby may have fail-over, restricted or unrestricted. If we want to have both devices to share the load then we need both of them under UR license -is that right? Also is the licensing scheme on ASA different than that on PIX. To my knowledge ASA5510 can run in both Active/Active and Active/Standby mode. Is A/A mode do the devices share the workload or one of them waits for the other to fail? We don't want any device not utilized. We get the security plus option for 5510.
Last what is VPN plus option on ASA5520. We need to VPN. Are there any additional requirements for VPN for all three above devices. What is advantage of ASA5520 over ASA5510
My expertise and experience is with the IPS product line. I have dealt with the ASA as part of my testing of the IPS modules for the ASA (the SSM-AIP-10 and SSM-AIP-20), but my knowledge is fairly limited to the interaction of the ASA with the IPS module.
I will attempt to answer some of your questions with my understanding from some past conversations with others, but you may want to confirm this with others more familiar with the ASA and Pix firewalls.
My understanding is that Pix 515e is a good box, but the ASA family is the targeted future replacement for all of the Pix firewall models.
Also the ASA has several features not available in the older Pix hardware. The ASA has a module slot which can be used for an IPS module, or a virus filtering module, (or additional interfaces).
As far as dual ASA deployments, the difference between Active/Standby and Active/Active will be the number and configuration of the security contexts.
For any 1 security context, only one of the ASAs will be active and the other will be standby. If you are not running multiple security contexts then your configuration is forced to be Active/Standby. If you are running multiple security contexts, then half of your contexts can be configured to be Active on the first ASA and standby in the second ASA, while the other half of your contexts are active on the second ASA and standby on the first ASA.
So the first ASA is active for half the contexts and the second ASA is active for the other half of the contexts. If a failure of either ASA ocurrs then the other ASA becomes active for all contexts.
Unfortunately I am not very familiar with the licensing mechanisms in the ASA. But my understanding is that with the ASA you need the same license on both ASAs. Unlike the Pix that used to have a special redundant only license that could be used on the second Pix; the ASA I do not think offers this type of license.
As for what the VPM plus option is, and whether a 5510 or 5520 is better for your deployment; you are beyond by experience of the ASA.
I would suggest re-posting your questions on the Firewalling NetPro Forum:
As I said my expertise is in IPS, and so you may be able to get better clarification on the Firewalling forum from some Pix and ASA experts.
hi marcabal great to u in the forum.
hi marcabal i would like to know can we use the event action override when we are running the ids in promiscious mode.
Yes, the event action overrides are fully functional in promiscuous mode.
They can be used to add event actions that are applicable to promiscuous mode.
They can also add deny actions that only take affect in inline mode, but instead of doing the deny the alert will just state that deny was requested but not executed. This can be handy when planning a transition from promiscuous to inline. You can see which attacks would get denied once you do change to inline mode.
I will install IPS sensor between an ISA server and PIX 525 (in inline mode) i need your advice to know the following :
-the monitoring interfaces of the sensor should be connected to the outside interface of the ISA server and the inside interface of the PIX or not???
I assume you are referring to the Microsoft Internet Security and Acceleration (ISA) Server?
If so, then you need to understand what ISA features you are currently using.
If the ISA features are not modifying the packets/connections (encryption or compression); then placing the InLine Sensor between the Pix and ISA Server should work just fine. Plug one interface into the Pix, and one interface into the ISA and in the sensor configuration create an InLine Interface Pair for the 2 sensor interfaces.
However, if the ISA is modifying packets/connections then you may want to deploy the InLine sensor on the inside of the ISA server between the ISA server and your internal network.
The ISA server provides features such as encrypted VPN tunnels, as well as compression and caching of web pages.
If the sensor deployed between the Pix and ISA Server it will not see the packets/connections in the same way that an end user box behind the ISA Server will see the packets. The sensor won't be able to decrypt and/or decompress the data.
To ensure the sensor gets the same view of the data as the end user boxes you would need to deploy the InLine sensor between the ISA server and your Internal Network (aka between the ISA-Server and the switch for your Internal network.)
I want to know that in given cisco switch ,How can I used the fibre port ,what converter(with part number) will used and what are the connectivity ,is there possible to use fibre port in given switch .how......... please also explain can we used 2 uplink as a fibre ... also if possible please send me the link so that i can see the pic.
? 24 Ethernet 10/100 ports and 2 dual-purpose uplinks (each dual-purpose uplink port has one 10/100/1000 Ethernet port and 1 SFP-based Gigabit Ethernet port, 1 port active)
? 1 RU fixed-configuration
? LAN Base Image installed
I am not specifically familiar with the WS-C2960-24TC-L, but I looked up the data sheet and here is what I have been able to understand.
The C2960-24TC comes with 24 Ethernet 10/100 ports and 2 dual-purpose uplinks (each dual-purpose uplink port has one 10/100/1000 Ethernet port and 1 SFP-based Gigabit Ethernet port, 1 port active)
SO you will need to configure the switch to use the SFP-based Gigabit Ethernet port (check the switch configuration on what commands are needed, or it may be automatic with an SFP is installed).
You will also need to plug in an SFP that is compatible with the sensor fiber ports.
All of our sensor fiber interfaces are 1000BASE-SX (Short Haul) Gigabit fiber interfaces.
So you will need to use an SFP that is also 1000BASE-SX (short haul).
In you case that would mean purchasing a GLC-SX-MM= which is the part number for the 1000BASE-SX SFP.
Understand that when dealing with fiber interfaces there is generally:
A) a 2 letter abbreviation for the optics distance, (SX for short haul, LX for long haul, as well as a few other ones as well)
B) a 2 letter abbreviation for the mode of the fiber cable (MM for Multi-mode fiber, and SM for Single-mode fiber), and
C) a 2 to 4 letter abbreviation for the type of physical connector (SC, LC, MTRJ as well as a few other options) (This is primarily just the plastic connector around the fiber and does not affect the data traveling within the fiber)
The GLC-SX-MM= is a SX (short haul) transceiver using MM fiber (Multi-Mode) with an LC style connector.
All of our sensors are SX (short haul) and use MM fiber (Multi-Mode).
The style of connector is different depending on which sensor you are talking about.
The IDS-4250-SX uses an SC style connector.
The IDS-4250-XL uses a MTRJ style connector.
The IDS-4260 uses a LC style connector.
So if you want to connect your switch to a IDS-4250-SX you would need a Multi-Mode fiber cable with an LC connector on one end of the cable and an SC connector on the other end of the cable.
So be sure to purcahse a Multi-mode and not a Single-mode fiber cable, and be sure the 2 connectors on the cable will match the 2 boxes you are connecting. LC on one side for your switch, and then other connector will be determined by the sensor interface you are using.
As far as the capabilities of the switch port and the sensor port from a sofwtare feature standpoint, you will need to read your switch configuration.
Most Cisco switches are able to treat those uplink ports similar to the other 24 ports of the switch. So it likely can be configured as a span port for promiscuous monitoring, an access port for one interface of an inline interface pair, or a trunk for doing inline vlan pairs.
From the sensor configuration the fiber ports are capable of all the same features as the copper ports (with the exception of setting speeds of 10 or 100 of course)
Is it possible to change rule set for virtual sensor after the creation of one? I have the situtation where I have rule0 associated with one virtual sensor and I would like to change the association to another rule.
Yes, you can change the event-action-rules configuration instance applied to user created virtual sensor.
Create a new event-action-rules configuration instance first.
Then edit the virtual sensor itself, and tell it to use the new event-action-rules configuration instance.
The same can also be done for signature-definition configuraiton instances, and anomaly-detection configuration instances.
NOTE: rules0 is the default event-action-rules configuration instance. On any platfrom supporting multiple virtual sensor the user can create additional instances using any name that the user wants (some character limitations apply). For example: rules1, myrules, dmzrules, etc..
This ability, however, is limited to only those additional virtual sensors that the user creates. The default virtual sensor vs0 can not be changed to use other configuration instances. The default virtual sensor vs0 MUST use the default sig0, rules0, and ad0 configuration instances.
can you share any new features or direction in upcoming versions of Cisco IPS?
- SQL injection related signatures: is it possible to improve 'SQL in HTTP' signatures to reduce a number of false-positive alerts (for example specify the type of served pages .jsp, .asp, etc or rewrite regex, etc)?
- Will it be a good idea to have one more brute-force related signature for FTP?
For example 6250 is looking for multiple failures in the same FTP session. Same time looks like attackers are using separate sessions for each auth. attempt. Currently 3171 is currently doing something similar but it detects both brute-force and normal 'Admin' connections. Is it possible to improve?
Unfortunately I am unable to discuss any new features in Cisco IPS on this public forum.
We have plenty of cool features coming up, but our Marketing team makes the call on when they can be announced and discussed on Public Forums such as NetPro.
For improvements on SQL in HTTP signatures I will need to spend some time discussing this with our signature development team.
6250 looks for 3 530 responses (typically means a failed login) coming from an FTP Server. The 3 530 responses do Not have to be in the same session, the respones can be on 3 separate sessions.
Be sure you have the latest signature update loaded and then look at the event count key for the signature. An event count key of attacker and victim means the 3 reponses just need to be seen between the attacker and victim address on any numner of connections.
If the event count key had been attacker and victim addresses "and ports", then it would all have to be on the same session.
I remember some discussion on this several months ago, so it is possible that this event count kwy may have changed within the past couple of months. So be sure you have the latest sig update on your sensor.
Is there something beyond this that you are wanting to search for.
As for the 3171 signature it is technically only looking for a single attempt to login as root or admin. unline 6250 that requires 3 failures before triggering an Internal Signature Event, the 3171 will trigger an Internal Signature Event on each and every login attempt by root or admin.
You could get 6250 to act similarly by just changing the event count to 1 instead of 3.
Some other possibilities you could consider.
You could CLONE the 6250 signature to a custom signature. In the custom signature change the event count key to be just Attacker address, and set the event count key to 5 (or any other number). Then it will monitor for that Attacker address failing 5 login attempts to ANY victim ftp server.
But keep in mind that slow attacks may not build up the counts enough to trigger the signature.
The sensor is limited by memory. It will try to remember Matches for as long as it can, but if it needs the memory to monitor incoming connections it will be forced to forget about those older Matches.
So if you have 2 Matches and are waiting on the 3rd Match to trigger the signature. If the 3rd Match comes quickly the signature will trigger because all 3 Matches are in memory. But if the 3rd Match comes in minutes later, then the first 2 may have been removed from sensor memory if the memory was needed for monitoring newer connections.
If these are concerns for you, then be sure to purchase sensors rated higher than you need for your network. The higher the rated sensor, the higher the amount of memory and the longer the Matches can be maintained in memory when monitoring your lower bandwidths.
I have not found this in the ASA / AIP-SSM documentation:
When we only want some sessions to be inspected by the AIP-SSM module we define the sessions with an ACL. Is the returning traffic also inspected by the IPS module or do we need to specify it in the ACL?
Hopefully the following link will help answer your question:
The second Example in the "Inspect Specific Traffic with the AIP-SSM" goes into a little more detail.
In the case of TCP if the SYN packet for the connection is sent to the SSM for analysis, then because of the ASA's ability to TCP state tracking it will also send the corresponding SYN ACK from the server regardless of whether or not the ACL would have matched the SYN ACK packet.
So for TCP the return traffic is also inspected.
For ICMP, however, the ASA does not do statefull tracking. So with ICMP if an echo request is matched by the ACL and sent to the SSM, this does not automatically mean that the echo response will be sent to the SSM. The ACL must indpendantly match the echo response to send the response to the SSM.
What I am not sure about is what happens if the SYN packet does NOT match the ACL (or is denied by the ACL), but the SYN ACK packet DOES match the ACL (permitted by the ACL).
I am not sure if the entire TCP Session will or will not be sent to the SSM, or if half of the TCP session would be sent to the SSM.
I believe UDP is treated similarly to TCP where the first UDP packet between the addresses/ports will be treated similar to the SYN packet of a TCP connection. So if the first UDP packet is matched and sent to the SSM, then UDP packets being returned from the server will also be sent to the SSM.
However, I have not specifically tested it, and so am not 100% sure.
My recommendation has generally been to go ahead and specifically state it in the ACL.
So when creating a permit entry for one direction of traffic, to go ahead and create a second permit entry for the opposite direction of traffic.
By following this recommendation you can be more assured that both directions of traffic will make it to the SSM regardless of whether it is TCP, UDP, or ICMP traffic.