Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss configuration and troubleshooting IDS/IPS sensors with Madhu Kodali. Madhu is a senior QA engineer on the Intrusion Prevention Systems development team in Austin, Texas, which supports the quality assurance of Cisco's intrusion detection and prevention solutions. He has been with Cisco for 10 years. His expertise lies in intrusion detection and prevention and the associated range of Cisco management products including Cisco IPS Manager Express and Cisco Adaptive Security Device Manager. Madhu holds a master's degree in computer science from the University of Texas at Dallas and currently holds CCSP certification.
Remember to use the rating system to let Madhu know if you have received an adequate response.
Madhu 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 December 23, 2010. Visit this forum often to view responses to your questions and the questions of other community members.
We are using ASA with AIP-SSM.The host ip of SSM is on the same subnet as the inside interface of the ASA. The ACL is configured to permit traffic from all network on the inside.
The ASA and SSM cannot ping each other.
From a PC connected to the inside interface, we can ping the ASA and can launch ASDM. we cannot ping the SSM.
We would like to configure the SSM from ASDM. We are asked to fill the IP address of the IPS, username and password and we cannot access SSM from ASDM.
We tried to permit ip from any source and any destination on the ASA, we always meet the same problem.
What shloud you do to be able to access IPS from ASDM?
Please find here attached the configuration of the ASA and IPS.
The AIP-SSM connects to the network through the external interface on the SSM. You can visually locate the interface on rear of the SSM card and make sure it is connected to the switch in the right vlan. The management traffic to the SSM comes through this interface and not through ASA interfaces. Access lists on ASA are used only to permit and create traffic policies for the traffic that need to be inspected by SSM. You can clear the ACL outside_mpc on your ASA and assign the right ip address, mask and default gateway on SSM (after connecting the external interface to the switch). I assume your SSM ip address is in the same subnet as your ASA management ip address. Once you provide the right values on SSM via ASDM or CLI you should be able to connect via ASDM.
Some advanced traffic setup configurations for SSM using ASDM are available on CCO link
Please let me know if you need more help.
Thank you for your reply. it's working now.
I am not familiar with signature. where can we a find a best lab/tutorial about tuning signature and what tool can we use to validate what all signature are well tuned for our network / application.
Sorry I missed this question. Better late than never.
Here are some links like white papers and configuration guides available on CCO to help you
Getting started with IPS : http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/guide_c07-464689.html
Cisco IPS Tuning Overview : http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/overview_c17-464691.html
Deploying IPS using Cisco ASA/SSM : http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/white_paper_c11-459025.html
Configuring the Cisco IPS : http://www.cisco.com/en/US/partner/docs/security/ips/7.0/configuration/guide/cli/cliguide7.html
Tuning is a continuous process based on your network traffic. Make sure to backup the tuning for later recovery.
To send interface related traps an IPS-4255 sensor uses “ceAlarmAsserted” object defined in ENTITY-ALARM-MIB.
A sample Trap received on Management Station from a sensor would like this (when interface Gig0/0 goes down)
Received SNMPv2c Trap: Community: "public"
mib_220.127.116.11 = 38429472
ciscoMgmt.18.104.22.168.1.3 = 3 <== The index is 3 (Gig0/0 from snmpwalk)
ciscoMgmt.22.214.171.124.1.4 = 0 <== Link went down for gig0/0
ciscoMgmt.126.96.36.199.1.5 = 4
ciscoMgmt.188.8.131.52.1.6 = 38429472
The possible values for ceAlarmHistAlarmType to denote a particular situations are listed below :
0 : netInterfaceLinkDown,
1 : LinkUp,
3 : TrafficStopped,
5 : trafficBypassStarted
6 : trafficBypassStopped
I am assuming you can access your ASDM without any problems. Here are the basic steps to configure IPS via ASDM :
1) Click on the "Configuration" menu item on the ASDM. Then you can click on "IPS" tab at the bottom. This will bring up the screen to provide the ip address, username and password to be entered. If you have never setup the SSM earlier then this screen will show the default ip address. I would recommend bootstrapping SSM by running "setup" on the SSM cli before you access it via ASDM.
2) If the AIP SSM is running IPS Version 6.0 or later, ASDM retrieves IDM from the AIP SSM and displays it as part of the ASDM interface. The IDM panes appear in the ASDM window. If the AIP SSM is running an earlier version of IPS software, ASDM displays a link to IDM. Click the link to launch IDM in a new browser window. You need to provide a username and password to access IDM.
3) On the IDM panel you can configure SSM for various purposes. At the minimum you need to add the physical interface Gig0/0 to the virtual Sensor on the "IPS policies" tab for the traffic to be analyzed.
4) To send the traffic to IPS you also need to configure policy on ASA for traffic to be sent to IPS. This is detailed under this link http://www.cisco.com/en/US/partner/docs/security/asdm/6_1/user/guide/ips.html
Please let me know how it goes. I can provide more details at any step if necessary
Thank you Madhu,
Presently i had configured firewall with DMZ and everything is woring fine,hopefully in couple of days i will do the IPS work and if i face any problem during that i will surely write to you.
In the IME client, every signature definition shows a field for "Obsoletes", where other signature IDs are sometimes listed. However, this field can't be edited (via IME), even for custom signatures. It is also "marked as protected" when cloning a signature; thus, it doesn't get replicated to the cloned signature either.
What is the purpose of this field?
What impact does it have on signatures and how they are implemented/evaluated by the system?
Is it for informational purposes only, or something more?
The "Obsoletes" field is used to obsolete an older signature with a newer signature usually due to better lightweight engines or better functionality. Like signature 3306 subsig 0 which belongs to service-smb engine was obsoleted by sig 5579 subsig 0 in the service-smb-advanced engine. Because of its nature you cannot copy this value to a cloned signature.
If Sig A has the Sig B listed in the "obsoletes" field then during inspection the Sig B is not loaded and only Sig A will be called to analyze the traffic. Any tunings on sig B maybe accepted but should be ignored. So it has no impact on the performance of the sensor
Hope this helps
Thanks, that's very good information, and something I had not read before. So, does the "obsoletes" parameter take precedence over a signature's "Enabled" setting? Such as, if Sig A obsoletes Sig B, but Sig B is still enabled and un-retired. Will the fact that Sig A obsoletes it prevent Sig B from being part of the evaluated set?
Also, even when creating a new custom signature, the obsoletes field can be viewed, but no signatures can be added to the list. Can the end user not specify their own obsolete values?
That is right Michael. The "obsoletes" takes precedence over signature's enabled settings. Even if Sig B in this case is enabled and un-retired it will not be part of the evaluated set.
This field is not for customer usage so a custom sig is not allowed to add a sig in this list. You would see the error as shown below:
qsensor-204(config-sig-sig-sta)# obsoletes 1000 0
Error: Cannot create a new obsoletes entry. Available entry(s):
If you want to make the sig B inactive my suggestion would be to retire that sig instead of obsoleting.
Another use of obsolete field which I just recalled is to enable processing of SigA on one type of platform vs SigB on different kind of platform (which cannot process SigA). To clarify more, a SigB which is obsoleted but enabled maybe called to inspect (hence active) on platform X, but will be not called on platform Y. Platform Y will instead call SigA to act on the traffic. This is due to the platform limitations. This is the reason Customers are not allowed to tune this parameter.
We have two ASA5505s, v8.3(2), each with a SSC IPS module running the latest IPS engine code, 6.2(3)E4. Twice now I've upgraded the IPS signature file and both times, on both devices, through ASDM, it takes about 7 to 10 minutes before a message comes back saying the update was successfull. During all that time, there is a small ASDM screen displayed with an update bar moving back and forth.
Is it normal for the SSC module to take sooooooo long to update? Do the SSM IPS modules in the 5510, 20, and 40 take this long also?