Showing results for 
Search instead for 
Did you mean: 

TAC IPS Media Series, Episode 3 - IPS Placement


Episode Information

Episode Name: Episode 3 - IPS Placement

Contributors: Blayne Dreier, Stijn Vanveerdeghem

Posting Date: February 3rd, 2011

Description: In this episode, Cisco TAC engineers discuss placing the IPS in different locations of the network and what signatures are available for the type of traffic the IPS would observe.

Episode Show Notes

The purpose of this episode is not to educate on or suggest IPS design, but instead, educate on what traffic the IPS will see if placed at various locations in the topology and on how the IPS will react to and protect that traffic.

    • IPS can be logically placed anywhere in the network without affecting the flow of through traffic. Placement does not cause alteration to the L3 header, and in most configurations, does not cause alteration to the L2 header.

We show various network segments that you can inspect and what response you can expect to see from your IPS, but please note that a single sensor can be configured with multiple inline pairs or promiscuous interfaces like "legs" that are "stretched out" to monitor multiple segments. Examples of this include a single sensor that is configured with 2 inline pairs. One inline pair can sit behind an ASA to inspect ASA-to-Inside traffic, while another inline pair inspects ASA-to-DMZ traffic.

Signature Groups
    • A significant amount more signatures exist for TCP than exist for UDP.
    • The number of application specific vulnerability signatures is greater than any other group of signatures available on the sensor.
    • Buffer Overflow and DoS signatures are common in each signature engine.
Internet Edge

When talking about this segment, we do of course see a variety of traffic coming from or going to different locations on the inside of our network.

We can put the IPS on multiple locations within this segment: behind the ASA towards the internal network, in front of the ASA facing the internet connection or we could put an IPS module inside our ASA firewal.

Internet Edge - IPS in front of ASA

What types of traffic will be seen on this link?

When we put the IPS in front of the ASA facing the internet connection, We will see traffic initiated by the inside hosts going to the internet, AND we’ll see return traffic from these sessions.  A lot of this traffic is typically HTTP and HTTPS.
We will see bi-directional traffic from the internet going to our DMZ servers.  This traffic may be from a variety of different protocols, depending on what servers we have in our DMZ.  This could include HTTP, HTTPS, IMAP, etc.

Other traffic we may see on this link is encrypted VPN traffic between a remote route and our VPN headed.
Besides that we may also see routing traffic between the service provider router and the ASA on our network.

When we look at potentially malicious traffic on this link, we may see reconnaissance traffic which can be used to determine what the vulnerabilities in our network are.
We can also see traffic specifically targeted at attacking the servers in the DMZ.

What signatures do we have to protect this type of traffic?

When we look at the signatures available on a sensor, Signatures of the sweep type are directly applicable to reconnaissance type traffic.  These signatures fall in 3 categories, TCP sweep, UDP sweep and ICMP sweep signatures.   
A sweep basically means that a host is initiating a connection or sending traffic to multiple destination IP addresses or multiple ports on the same destination IP. 
Besides signatures, other features such as “reputation filtering’ can protect this network segment by dropping traffic sourced from blacklisted IP addresses.

Many signatures are applicable to protecting traffic on this link because this is a convergence point for much of the traffic coming from the internal network.

What benefit the IPS will provide?

An IPS in front of the ASA can be used for outside traffic analysis.  Having the IPS on the outside, will allow it to see unfiltered traffic as it comes in from the internet towards our host and servers in our dmz which will then allow us to determine what kind of attacks are targeting our network.

What are the potential issues by placing the IPS here?

We will not be able to inspect encrypted VPN traffic from a remote VPN user to the VPN headend device on our internal network. Also, an ASA really is better suited for permanent filtering based on L3/L4 headers than the IPS is.

The core function of the IPS is to detect and prevent intrusions based on packet pattern matching, not static layer 3 or layer 4 information such as IP addresses and ports.

Another potential issue of having the IPS in front of the ASA is that it will not be able to inspect HTTPS traffic coming into the DMZ webserver. This traffic can not been inspected as it’s encrypted.

Internet Edge - IPS behind ASA

What types of traffic will be seen on this link?

The traffic we will see on this segment will be largely similar to what we say in the previous location, but there will be a couple of differences.  We won’t be able to see traffic coming from the internet towards our DMZ host, but now we will be able to see traffic coming from our internal hosts to our DMZ servers.  In addition to that, we may also see routing traffic between the ASA and the inside routers.

What signatures do we have to protect this type of traffic?

Since the traffic we see here is very similar to the traffic we see when the IPS is in front of the ASA, the signatures that will be applicable to protect this link are also very similar to the signatures we already mentioned such as the sweep signatures to protect against reconnaissance attacks.  Other signatures that apply here are the signatures that protect against DOS attacks from our inside network to our DMZ servers and signatures to inspect HTTP traffic between our inside hosts and the DMZ as well as anomaly detection signatures that can detect worm-like behavior.

What benefit the IPS will provide?

The ASA will block connections from the outside to the inside network that were not initiated from the inside based on it’s configuration and state tables. This means that the IPS will not see this traffic, and can use it’s resources to inspect traffic that was allowed through the ASA and traffic.
Another benefit is that,  when the VPN tunnel is terminated on the ASA, we will be able to see and inspect the decrypted traffic to our internal resources from the VPN tunnel between the ASA  and the remote VPN user.

What are the potential issues by placing the IPS here?

We won’t be able to inspect traffic between the internet and servers on the DMZ.

Internet Edge - IPS insideASA

What types of traffic will be seen on this link?

By using policy-maps, the ASA allows us to configure what traffic we want to send to the IPS module for inspection.
We will see a combination of the traffic we saw on the previous two examples.  We will see traffic from the inside network to the internet and the return traffic. Traffic from Internet to our DMZ server  as well as traffic from the inside to the DMZ server.

What signatures do we have to protect this type of traffic?

Also the signatures we have to protect this traffic are a combination of the signatures we discussed in the two previous scenarios. 
On top of that, the sensor is equipped with application specific signatures which can protect our DMZ servers such as webservers and email servers from exploits targeting these applications.

What benefit the IPS will provide?

The main benefit of having the IPS here is that it can protect traffic between the internet and the inside as well as traffic between the internet and the DMZ and traffic between the inside and the DMZ.

What are the potential issues by placing the IPS here?

We will be able to inspect VPN tunnel traffic that is terminated on the ASA as the ASA will decrypt the traffic before sending it to the IPS. We will however still not be able to inspect HTTPS traffic terminated on the inside HTTPS server.

Services Server Farm

What types of traffic will be seen on this link?

NTP, DHCP, DNS, LDAP, Domain Controllers w/ Active Directory, NFS, TFTP, SMTP

    What signatures do we have to protect this type of traffic?

    • 4056 - NTPd readvar overflow
    • 23779 - NTPD Autokey Stack Buffer Overflow Vulnerability
    • Informational - DHCP Request, Offer
    • 4619 - Invalid DHCP Packet
    • 6257 - DHCP Client DoS
      • This signature fires when a DHCP server offers a malicious IP address to a client for use as a unicast address.
    • 5795 - DHCP Option Overflow Code Execution
    • 5681 - ISC DHCP Daemon Buffer Overflow
    • 6261 - ISC DHCP Remote DoS
    • 20619 - ISC DHCP Client Subnet Mask Buffer Overflow
      • Large OPT record and Query name loop DoS attacks
      • DNS responses that cause application buffer overflows or DoS's
      • DNS Query Floods
    Otherwise benign
      • Known DNS lookups by viruses
      • DNS Lookups by messaging clients
      • DNS Tunneling
    Protocol violations
      • 4620 - DNS Limited Broadcast Query
        • This signature fires when multiple UDP packets are sent to the limited broadcast address of and a destination port of 53.
      • Empty DNS Queries
      • Attempted Zone Transfers
      • Requests for All Records
      • DNS Version Requests
      • DNS Server Host Info Requests
      • BIND program stack information leakage
      • Buffer Overflows
      • DoS attacks
      • Memory corruption
      Domain Controllers w/ Active Directory
      • Buffer Overflows
      • DoS Attacks
      • Active Directory failed login attempts
      • Active Directory process memory starvation
      • ACS / Authentication Traffic
      • EAP Overflows
      • EAP-TLS Authentication Bypass
      • Large CSAdmin service requests (TCP/2002)
      • Oversized TACACS packet - causes service to crash
      • Directory traversal
      • Cross-site Scripting attacks
      • Buffer Overflows
      • DoS attacks
      • Service Sweeps
      • Buffer Overflows
      • DoS attacks
      • GET requests that cause service crashes
      • GET request directory traversal - password file retrieval
      • Unauthorized configuration retrievals from infrastructure devices
      • Syslog
      • Buffer Overflows
      • DoS attacks
      • Log Spoofing
      • Arbitrary mitigation
      • Remote username and password retrieval
      • Crafted packets causing service crashes
      • Community string retrieval
      • Use of generic "public" community string
      • Memory corruption
      • Malformed authentication attempts
      • Infrastructure device configuration retrieval
      • Arbitrary MIB access
      • Protocol conformance violations

      What benefit the IPS will provide?

      Protocol conformance
      • We know that every protocol behaves in some particular way. The IPS can monitor a protocol for anomalous behavior and take action if it begins to act in an unexpected fashion.
      Continuation of business
      • We know that most protocols are plagued by DoS vulnerabilities. In a server services farm, protocol function is essential to the network. By protecting these servers against DoS attacks, you can ensure that the network foundation will remain operational.

      What are the potential issues by placing the IPS here?

      False positives
      • Many of the low-level protocol conformance signatures have the potential to fire on generic behavior. Configuring notifications for each occurrence of an event can quickly become overwhelming. This may cause you to miss events that are indicative of a seriously malicious attack. Tuning with event action filters and event action overrides can reduce the noise of benign events.
      Performance issues related to UDP
      • Several of these protocols are high-traffic, small packet-size UDP. DHCP, DNS, Syslog and SNMP are examples. As we mentioned before, IPS sensors are highly tuned for TCP traffic, specifically HTTP. So you may not see the same level of performance when placing the IPS sensor in front of a busy DNS server that you would see by placing it infront of a busy web server.

      Application Server Farm

      What types of traffic will be seen on this link?

      The types of servers we have here will is a major factor in the traffic we expect to see on this link.
      When we have the IPS on this DMZ link, the only traffic we should see between the DMZ and internet link is traffic directed to and from ports where servers in the DMZ are listening on.  Our ASA is configured with the necessary ACLs to only allow inbound traffic to the DMZ to the specific ports used by the different servers
      Depending on the ASA configuration, the ASA may or may not be blocking certain traffic from the inside hosts towards the DMZ and vise versa.
      Most communication with a web server will be using HTTP or HTTPS protocols.  So we will want to make sure this traffic is inspected.  Examples of webserver applications are Apache or Microsoft IIS.  We will hence also need to make sure the IPS is able to protect against potential exploits targeting vulnerabilities in these applications.  Typical attacks targeting these servers are buffer overflow attacks, application denial of service attacks and other application specific exploits.
      Several protocols can be used on our email servers.  This includes SNTP,IMAP,POP3 and more.  Microsoft Exchange is an example of an email server.  We need to protect against exploits that may be targeting weaknesses in our server.
      The signatures that will apply to protecting traffic on this link don’t only depend on the traffic protocols we will see but also on the applications running on our servers and the relevant vulnerabilities.
      Potential malicious traffic coming into this link includes specific attacks targeting the applications or protocols running on our servers and Denial of Service type traffic targeted at overwhelming our server or servers.  Malicious traffic may originate from the internet or from a compromised host on the inside, or even from another server that has been compromised.

      What signatures do we have to protect this type of traffic?

      The signatures we have to protect this link include HTTP/HTTPS, SMTP,IMAP and other protocol specific signatures. We also have application specific signatures.  We have for example about 50 signatures to detect exploits targeting Apache and about 90 signatures specific to Microsoft IIS.  Most of these signatures look for “buffer overflow” type exploits, but some are also looking for denial-of-service type traffic aimed at overwhelming and potentially bringing down an application.

      What benefit the IPS will provide?

      There are a lot of benefits of placing the IPS on the DMZ link.  It will protect the servers against exploits.
      Protecting the server will also eliminate hackers from using this server as an attack vector attacking other resources in the DMZ.

      What are the potential issues by placing the IPS here?

      Without the use of a SSL servcies module, we are not be able to inspect HTTPS traffic terminated on  the inside HTTPS server.

      User Access Layer

      You can categorize the reasons for placing an IPS in the user access layer into three main groups.
      Protecting your resources and users from the threats out there (the Internet)
      • Hosts are often attack vectors and not attack targets. They have access to other devices on the network and will be used as jumping points to other devices.
      • That said, specific hosts, such as management or admin machines are targets for reconnaisance. Exploit payloads will be directed at these machines so that they can be compromised and configured as data collection devices.
      Protecting your resources and users from themselves.
      • Sometimes attackers break their way in and sometimes users welcome them with open arms.
      • Infections begin with the introduction of foreign software. The software can arrive via the network or a laptop that was taken off-site, or via a portable data storage device.
      • This means that you should not only be worried about infections coming in, but also be concerned about outbound infectious behavior.
      • Hosts can be exploited by other hosts. So protecting hosts from each other is a concern.
      Protecting the Internet from your users. (Lawsuits)
      • Hosts can also be used in unison for a Denial of Service attack, targeted at external or internal victims.
      • AD Scanner (reconnaissance)/Worm (infection spread) Propagation

      What types of traffic will be seen on this link?

      SMB/NETBIOS, RPC, WINS, FTP, SCP/SSH, TELNET, RDP, P2P, Multimedia, Unicast Audio and Video, Messaging, Email - IMAP/POP3/SMTP, VOIP, Video Calls, Web

      What signatures do we have to protect this type of traffic?

        • 3353 - Buffer overflow via an SMB request
        • 3303 - SMB Login successful with Guest Privileges
        • 3306 - SMB Remote Registry Access Attempt
        • 3312 - SMB .eml email file remote access
        • 3320 - SMB: ADMIN$ Hidden Share Access Attempt
        • 3323 - SMB: RFPoison Attack (illegal memory access which causes the server to crash)
        • 3356 - Remote Registry Request DoS
        • 5579 - SMB Remote Registry Access Attempt
      • RPC
        • Buffer overflows
        • DoS Attacks
        • Portmap requests
        • Sweeps for various RPC services RSTATD, RUSERSD, NFS, MOUNTD, STATUS
        • 3328 - Windows SMB/RPC NoOp Sled
      • WINS
        • Buffer overflows
        • Local privilege escalation
      File transfer and terminal
      • FTP
        • 12900 - Unrecognized FTP command
        • Various other FTP commands
        • FTP server buffer overflows and DoS attacks
        • Root logins
        • PORT command address and port redirection
      • SSH/SCP
        • SSH over non-standard ports
        • Buffer Overflows
        • Rapid SSH connections
      • TELNET
        • DoS attacks
        • Buffer Overflows
        • Telnet over non-standard ports
        • Navigating to the drive root (/)
        • Client information disclosure (when a victim client connects to a rogue telnet server)
        • Authentication bypass
      • RDP
        • DoS attacks
        • Heap overflow (client connecting to a rogue RDP server)
        • Heap overflow (client connecting to a rogue Web server)
      • P2P
        • File requests
        • Logins
        • Connection attempts
        • DNS requests
      • Multimedia
        • Multicast streams
        • Multicast source addresses
        • DoS attacks
      • Unicast Audio and Video
        • H.225 ASN.1 PER Encoding Issue (Overflow/DoS)
        • Q.931 Information Elements overflows
        • Transport Packet field modification
      • Messaging
        • Instant Messaging Application traffic (56)
        • DoS attacks
        • Buffer Overflows
        • Message Send/Receive
        • Logins
        • File Transfers (Data Loss Prevention)
        • Connection through HTTP proxy
        • Client DNS requests
      • Email - IMAP/POP3/SMTP
        • Long IMAP CREATE, UNSUBSCRIBE, EXAMINE, AUTHENTICATE, LOGIN, etc commands that can cause buffer overflows
        • 16693 - NULL IMAP APPEND Command
        • POP3 Authorization Failures
        • SMTP session starts with non SMTP commands
        • SMTP RCPT Bounces which can lead to remote code execution
      • VOIP / Video Calls
        • H.323 DoS attacks
      • Web
        • HTTP

      What benefit the IPS will provide?

      • Host-to-Host traffic
        • The IPS will see all host traffic, including that from host-to-host. An IPS placed in this location will provide a view into traffic that is not visible from anywhere else in the network.
      • Foresight
        • If you have available resources to monitor your host links via IPS, it will undoubtedly provide a great amount of insight into user traffic and potentially prevent problems before they start.

      What are the potential issues by placing the IPS here?

      • Discrimination of trusted and not-trusted traffic
        • The IPS will see a very wide variety of traffic. While trusted traffic can normally be excluded from inspection, user traffic is very diverse, which makes the identification of trusted traffic difficult. Additionally, today's trusted protocol may become a target by tomorrow's poorly written application. So you should take caution when applying Event Action Filters to user traffic.
      • Oversubscription
        • Due to the large amount of network traffic sent to, from, and between hosts, the potential for oversubscription is high. You may need to place the IPS on aggregate switches at higher levels of segmentation. This will cause you to miss some host-to-host traffic, but will be less strenuous on the sensor's resources while still providing a fair picture of the network traffic.

      WAN Link

      The WAN link in our diagram is the connection between a remote site and our network.  In our sample network, The actual link between the 2 is an MPLS VPN connection.  This link is only used for “intranet” traffic, traffic from the remote site to the internet does not go across this link.  This link may have limited bandwidth, so that’s another reason to keep unwanted traffic off the link.
      We could put our IPS in between our L3 switch and our edge router, or we can also use an IDSM-2 IPS module which goes directly inside a CAT 65K.

      What types of traffic will be seen on this link?

      We will see traffic initiated by remote hosts going towards the main network, such as user applications connecting to servers  on our head office network such as email, DNS and other services, intranet webservers and specific  application servers
      We will also see traffic going from the main network to the remote hosts.
      Another type of traffic we can expect to see on this link is management plan and control plane traffic including routing protocols, telnet,ssh,snmp and logging traffic such as syslog
      Malicious traffic originating from the remote site may be targeting hosts as well as servers on the main network. Risks are related to either an external user gaining access to the remote site via the remote site’s internet connection and that compromised connection to gain access to the main network or internal users on the remote site knowingly or unknowingly launching an attack.

      What signatures do we have to protect this type of traffic?

      A broad range of signatures can protect this type of traffic.  What signatures apply here very much depends on what traffic is exchanged between the remote location and the main network.  Examples of signatures that may apply here are the signatures that look for attacks using control-plane and management plane protocols and applications such as RDP SSH,FTP, Telnet and RDP.

      Also any signatures that look for DoS type attacks will be very much applicable here because we don’t only want to protect our servers but also preserve our bandwidth on this link.

      What benefit the IPS will provide?

      Placing the IPS here will protect the corporate network from at tacks from hosts on the remote end.  It will also help saving the bandwidth on this link for business applications.

      What are the potential issues by placing the IPS here?

      When we put the sensor on the actual MPLS link, certain signatures may fire on traffic that is not necessarily malicious.  As an example, we have a signature which fires on datagrams smaller than 400 bytes.  In an MPLS environment with default tag-switch mtu settings ,a high percentage of packets will be fragmented because the default MTU does not take into consideration the MTU tag. This will cause this particular signature to fire at a high rate. In this case, we can increase the tag-switching MTU to solve this.

      Branch Office

      The branch office mimics the Internet Edge as well as the User Access Layer. For efficiency reasons, the branch office likely has its own connection to the Internet, which introduces a myriad of possible issues. Also, branch hosts often need to be thought of as internal hosts because they will need to access the same servers and services that a host within the User Access Layer will need to access.
      So the IPS should accomplish a few tasks which are synonymous with these two locations. It needs to:
      • Protect the branch users from the branch Internet connection
      • Protect the branch Internet connection from the branch users (lawsuits)
      • Protect the core and entire backbone network from the branch users
      • And, to a lesser extent, protect the branch users from the core and backbone
      Depending on the branch's Internet connection solution and its solution for the connection to the backbone, IPS may be required on one or two interfaces to protect for each of these scenarios.
      You may be thinking to yourself, "Why do I need to have IPS deployed at the branch office, toward the backbone network if I already have it deployed at the core?" The answer is related to what Stijn said about protecting the WAN link. Leased lines are expensive, and data rates aren't all that high. Less malicious or superfluous traffic on the WAN link means more bandwidth for mission critical data. Additionally, and unfortunately, the physical and human portion of your security policy is all too often relaxed at remote locations, which makes protecting the WAN and backbone from the branch, with IPS, all the more important.

      Remote IDS Monitoring

      Instead of putting the sensor inline, we can put it in promiscuous mode.  In this mode we just send a copy of traffic instead of the actual traffic to the sensor.  In this case, the sensor operates as an IDS - Intrusion Detection System.  We can send traffic from various locations to the IDS.  The IDS does not have to be located where the traffic originates.

      We can use SPANS, VACLS or a network tap to send traffic from different sources to the sensor.

      Adding an extra link is very simple.

      There are several benefits of using an sensor as IDS:

        • No need to use 2 physical interfaces
        • More sensor resources are available for inspection
        • Easy to add additional links
        • IDS can be centrally located
        • Implementation requires no changes to physical infrastructure

      The IDS does not even have to be located in the same physical location as where the network is.  It can be located at a remote site, perhaps managed by a remote vendor.  In this case, we just send a copy of the traffic over a secure link to the vendor, and that vendor can take care of the monitoring.

      About the TAC IPS Media Series

      The Cisco TAC IPS Media Series is created by Cisco TAC engineers. Each episode will concentrate on a particular feature of the IPS, with a  portion dedicated to configuration and a portion dedicated to troubleshooting and debugging.

      Complete episode listing and show information

      Jay Johnston
      Cisco Employee

      This is really great guys, good job!

      Great videos,


      When doing config videos  can you please clarify the IPS <-> Layer 2 interaction with the network topology, namely

      - the difference, examples, reasoning behind inline pairs/vlan inline pairs/ vlan groups ?

      Thanks in advance


      Christopher Dreier

      Hello Yuri,

      We do in fact have an episode planned to discuss different interface configurations. Great suggestion!

      Thank you,

      Blayne Dreier

      Cisco TAC Escalation Team

      **Please check out our Podcasts**

      TAC Security Show:

      TAC IPS Media Series:

      Content for Community-Ad