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?
What signatures do we have to protect this type of traffic?
- Large OPT record and Query name loop DoS attacks
- DNS responses that cause application buffer overflows or DoS's
- DNS Query Floods
- Known DNS lookups by viruses
- DNS Lookups by messaging clients
- DNS Tunneling
- 4620 - DNS Limited Broadcast Query
- This signature fires when multiple UDP packets are sent to the limited broadcast address of 255.255.255.255 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
- Memory corruption
- 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?
- 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.
- 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?
- 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.
- 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
- 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
- Buffer overflows
- DoS Attacks
- Portmap requests
- Sweeps for various RPC services RSTATD, RUSERSD, NFS, MOUNTD, STATUS
- 3328 - Windows SMB/RPC NoOp Sled
- Buffer overflows
- Local privilege escalation
- 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?
What are the potential issues by placing the IPS here?
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
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
