01-16-2014 01:25 AM - edited 03-10-2019 06:07 AM
If my ASA IPS is in promiscous mode, can I demonstrate traffic bloc/drop for any signature?
I am sure in inline mode it can be done but is it possible with promiscous mode since in this mode the traffic is only duplicated and sent to IPS.
Solved! Go to Solution.
02-02-2014 04:00 PM
Let's clarify the promiscuous mode's inability to shunt -- I don't believe that's correct; both inline and
promiscuous modes WILL block offending traffic.
Cisco has been very explicit in their documentation to describe the mechanics of how promiscuous mode works; specifically it WILL block traffic by using dynamic ACLs but the timing may NOT be as robust as the inline mode.What they fail to describe is exactly how the deny ACLs are inserted into the ASA's running config. There I admit I need better clarification from Cisco.
Meaning some traffic WILL pass before the dynamic ACL is put in place hence they always recommend the inline mode which puts the ASA in a blocked mode so to speak from the software world where no traffic passes until the SSM passes it back to the ASA for forwarding.
02-03-2014 09:24 AM
Biandov -
You are correct, I did neglect to take Promiscuous mode ACL shunning into account when I said promiscuous mode would not block traffic. The ACL blocking was the original method of Cisco IDS sensors to block traffic, before the in-line mode was available. There are separate signature responses when editing the signature actions for Block and Drop. Block is the ACL mode blocking (with an appropriately configured Cisco router or Firewall). Drop only has an effect when the sensor is in-line.
- Bob
02-03-2014 09:36 AM
Very helpful Bob, Thank you. I never knew the distinction in the action definition where block and drop actually apply to each method of delivering the shunt
Now that we have a good discussion I want to go back to the original question since that same issue had come up in the past. There's got to be some utility which generates malicious traffic? A script for WireShark generator feature or a whole another executable or what not. It's the Internet; I find it fascinating that we can't have one of those for "legit" purposes as we are all in the business of proving that IPS works
Thanks!
02-03-2014 09:44 AM
There is no need to get complex for testing signature detection and if your response actions are properly performed. You can just enable one of the ICMP sigs and run pings past/thru your IPS:
http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_tech_note09186a0080bf911b.shtml
If you want to test signature fidelity (the accuracy of each signature), then you will need an attacker, like Metasploit http://www.backtrack-linux.org/ and a victim like http://www.offensive-security.com/metasploit-unleashed/Metasploitable
- Bob.
01-22-2014 03:43 PM
If your ASA AIP-SSM module is in promiscious mode, then you can't block traffic.
The sensor module is not aware of teh ASA's config setting that controls in-line or promiscious mode, so both modes looks the same from the ISP module.
You can turn on the ICMP Echo Request sig, set it to drop and watch yoru ASA pass pings if you want proof.
- Bob
01-24-2014 05:15 AM
Is is applicable for all kind of traffic? Can I enable blocking for tcp based signatures?
01-31-2014 08:31 AM
Yes it is applicable for all kind of traffic.
02-02-2014 04:00 PM
Let's clarify the promiscuous mode's inability to shunt -- I don't believe that's correct; both inline and
promiscuous modes WILL block offending traffic.
Cisco has been very explicit in their documentation to describe the mechanics of how promiscuous mode works; specifically it WILL block traffic by using dynamic ACLs but the timing may NOT be as robust as the inline mode.What they fail to describe is exactly how the deny ACLs are inserted into the ASA's running config. There I admit I need better clarification from Cisco.
Meaning some traffic WILL pass before the dynamic ACL is put in place hence they always recommend the inline mode which puts the ASA in a blocked mode so to speak from the software world where no traffic passes until the SSM passes it back to the ASA for forwarding.
02-03-2014 09:24 AM
Biandov -
You are correct, I did neglect to take Promiscuous mode ACL shunning into account when I said promiscuous mode would not block traffic. The ACL blocking was the original method of Cisco IDS sensors to block traffic, before the in-line mode was available. There are separate signature responses when editing the signature actions for Block and Drop. Block is the ACL mode blocking (with an appropriately configured Cisco router or Firewall). Drop only has an effect when the sensor is in-line.
- Bob
02-03-2014 09:36 AM
Very helpful Bob, Thank you. I never knew the distinction in the action definition where block and drop actually apply to each method of delivering the shunt
Now that we have a good discussion I want to go back to the original question since that same issue had come up in the past. There's got to be some utility which generates malicious traffic? A script for WireShark generator feature or a whole another executable or what not. It's the Internet; I find it fascinating that we can't have one of those for "legit" purposes as we are all in the business of proving that IPS works
Thanks!
02-03-2014 09:44 AM
There is no need to get complex for testing signature detection and if your response actions are properly performed. You can just enable one of the ICMP sigs and run pings past/thru your IPS:
http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_tech_note09186a0080bf911b.shtml
If you want to test signature fidelity (the accuracy of each signature), then you will need an attacker, like Metasploit http://www.backtrack-linux.org/ and a victim like http://www.offensive-security.com/metasploit-unleashed/Metasploitable
- Bob.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: