I've heard a recommendation that for a new sensor implementation at a given site, it is better to allow the sensor to learn traffic patterns in promiscous mode before deploying inline mode, otherwise the sensor may not interpret certain events correctly.
Is that a valid statement, and if so, does that mean you must wait to deploy any particular policies until this learning is complete?
That statement is completely wrong. The right statement would be:
"For a new deployment you want to learn how the sensor behaves in your network before you enable restrictive actions in inline-mode".
For this learning-phase, using the sensor in promiscous-mode is less dangerous than using the sensor in inline mode. As it is only one parameter in your MPF to change from promiscous to inline, it's a good choice to start with promiscous.
For the AIP-IPS the detection-capabilities in promiscous and inline-mode will be the same. For the appliances, the detection is more accurate in inline-mode if the traffic is not normalized.
Sent from Cisco Technical Support iPad App
-- Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
There seems to be some differing opinions on this subject. In the spirit of the forums as a place to learn, agree/disagree, and grow, here is a different view from an engineer, assuming we are referring to exactly the same question.
You can always override the initial deny packet inline action. Signatures work differently in inline and promiscuous modes. That is why I do not agree with that statement. Also risk ratings are affected by the promiscuous delta if in promiscuous mode. Read the link below.
Promiscuous Delta: When an IPS is deployed in Promiscuous mode rather than in Inline mode and under certain conditions, attack recognition may not be accurate. In such instances, Promiscuous Delta (PD) is used to lower the overall risk rating of the event.
Everyone has a different opinion of how to initially deploy an IPS. Do you want to baseline your network differently than it will run normally?
The sensor in question is an AIP-SSM, so the traffic is normalized by the firewall. In this setup there is no difference in the detection capabilities between promiscous and inline. Promiscous mode has problems with traffic that the attacker has fragmented in an abnormal way or modified segments. Both are controlled by the ASA and don't show up at the sensor.
So the signatures will behave the same. Now you want to make sure that you don't lose traffic while you are stil in the phase of minimizing or eliminating your false polsitives. You could filter out the deny-actions, but as a human you could make a mistake there and you configure something that has to be reconfigured later when your first tuning-phase is over. Both is not a problem when you observe your sensor in promiscous-mode. The change to inline is then very easy and your sensor doesn't need to be changed any more.
For your promiscous delta: The PD has nothing to do how or if a signature triggers or how the signature behaves. It is only a modifier for your Risk-Rating that helps you to make better decisions when you are at your monitoring-console, have thousands of alarms and have to decide which to process first.
That version doesn't change anything in the way the traffic is processed compared to an AIP-SSM. Instead of a dedicated hardware it just uses dedicated ressoures from that ASA-platform. Still, I don't see where the signatures would behave differently in this situation. Perhaps you can clarify that with the TAC? It's never to late to learn or to change the mind on new input.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...