BPF Filters Across Protocol Header Boundaries

BPF has keywords to address layer 3 and layer 4 protocols, such as IP, TCP, UDP and ICMP. But what if you need check the value of a field in a higher layer protocol, such as DNS? If the header you're working with is static, that is, never changes size like UDP, you can then go past the end of that header and into the next. Johnathan Ham teaches this in the excellent FOR558 Network Forensics class at SANS.
To use his example, say you wanted to filter packets to see only DNS queries. The QR bit in the DNS header, which specifies whether a DNS packet is a query or an answer, is found in the 2nd byte offset from zero in the DNS header, or the third byte. Since a UDP header is always exactly eight bytes long, we can extend what byte we specify past the end of that header and into the DNS header. The last UDP byte is number 7 (it consists of bytes 0-7), and we want to drill down to the second byte from zero in the DNS header. Counting from that 7th byte, that would be the 10th byte from the beginning of UDP. Our field is one byte in length, and the QR bit is first bit on the left, or as it's known, the highest order (or most significant) bit. Networking is big endian, meaning we address bits from the left to the right, the same way English speakers read. Now we need to apply our bit masking to check the value of just that one bit. As we know, we want to apply a bitwise AND operation to all the bits, using a one to preserve the bit and a zero to mask the bits we don't care about. So our byte is laid out like this:

QR  Opcode   AA TC RD
 0     1  2 3 |4   5    6    7

Our first nibble, or four bits, contains the QR bit and the first three bits of the Opcode field (bits 0-3).
Our second nibble contains the last Opcode bit, the AA bit, the TC bit and the RD bit (bits 4-7).

If you want to know what those other bits are used for, you can take a look here.

So our mask would be 1000 0000 in binary. Our first nibble has a one in the 8's column (2 to the power of 3) and everything else is zeroed out, so in hex our mask would be 0x80. We apply that mask using our BPF filter and look for a value of 0 in that bit (which designates a query, as a value of 1 designates a response).

We can add port 53 for some extra assurance we get DNS queries and not syslog or other UDP traffic. The tcpdump command I used is: tcpdump -nnvvv -i eth0 'udp[10] & 0x80 = 0 and port 53'

And sure enough, what I end up is packets that look something like this:


21:20:49.596637 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 60)
    x.x.x.x.2051 > 208.67.222.123.53: [udp sum ok] 2800+ A? ws.immunet.com. (32)

Here we see a query from one of my boxes (munged to x.x.x.x) to an OpenDNS server for the address record of ws.immunet.com.

Now if we change the value from 0 to our mask value in our filter (udp[10] & 0x80 = 0x80), we can look for DNS answers instead. (Or we could just specify not 0, since the only other possible value would be a one). So we could use 'udp[10] & 0x80 != 0'
Either one would work. Very nice!

NetSec and Linux

   Network Security requires having knowledge in a large number of areas. I can't think of a job in IT that requires a person to have at least some expertise in so many areas. How much a learning curve it is depends, of course, on where you came from to get to your first NetSec position. If you're starting straight out of college, and you took an Information Security track in school, you've no doubt been introduced to some or most of what you'll need. If you were already in IT, you may have moved into the field from a server or infrastructure team, or perhaps from desktop or a help desk. Regardless of what your knowledge base is, if you don't know the basics of working in Linux, you'll soon find out it's a prerequisite. (If you're going to work in Information Security and deal with things like access controls, policies, audits and vulnerability testing, you may not need much in the way of knowing Linux.)

   The primary reason you'll need to get familiar with Linux is that the majority of NetSec applications (like IDS/IPS, log servers, packet auditing and so forth) and security tools run either exclusively or best on Linux.
There are some very decent Windows-only tools and some popular tools have Windows ports of them, but most of the really good tools were designed to run in Linux. (I've been told that Wireshark is a rare exception and actually runs better on Windows than Linux, but I have no proof that's the case).
Fortunately, there is an absolute glut of sites that's sole purpose is to help you learn Linux step by step. And Linux has a huge user base that relishes in helping out people new to the OS and getting them up to speed. You can take commercial, paid training courses if you wish, at places like New Horizons, Babbage-Simmel or other training centers, but the help you get through the Linux community makes that unnecessary (though if your company WANTS to pay you to learn Linux for a week in a classroom, no reason to turn it down).
Linux is, of course, free for the overwhelming majority of the distributions (a rare exception would be Red Hat Enterprise, where you pay for support and updates, but there's also the free community supported Fedora or CentOS which operationally are almost identical). You can download and install Linux on a box and get started immediately, or make a live boot disk on a CD, DVD or flash drive and use it anywhere. You can install the (free) virtual environment VirtualBox (from Oracle), then download several distros you'd like to try and run each one as a VM.

   However you  do it, you'll want to get up to speed as quickly as possible, as you'll find each new tool you need to do your job probably only runs on Linux or runs best on it. Linux has come a long way in terms of GUI support, but one of the advantages of Linux over Windows is how much less overhead it takes, so running from the terminal instead of X Server (the Linux GUI) is probably best. And you might as well learn to work from the command line from the start, as there may be situations where you'll need to work on a box that doesn't have X installed.

   As to what flavor to run, you'll not find anything close to a consensus anywhere. Everyone has their favorite, and most are passionate about why they believe their distro is superior to others. Personally I like Fedora and I managed boxes running RedHat Enterprise for many years. The boxes I inherited at my current position run another flavor (though now that I've taken over the care and feeding, that will change at the next reload). I've worked with Debian, Ubuntu, Slackware and others and most of the commands are identical except in things like network setup and package management.Other popular distros include CentOS, Mint, Mandriva, Arch, and Gentoo. Those are just a few. The site distrowatch.com is a great place to get the newest versions of whatever you run and find something new to try out. There are currently 317 distributions of Linux listed on the site (note that distrowatch does not host all these versions, but provides info on them and links to the developers site where you can download them).

    If all you've ever used before is Windows, there IS going to be a learning curve. But you might as well get started, because to work in NetSec, you'll need to learn a second "language". In my experience, the person who advised me told me to download FreeBSD and learn it (a flavor of UNIX, not Linux) as my first non-Windows OS. That was a bit of a nightmare and definitely not recommended as a first new system to learn. I know any version of Linux will be much kinder to you than that (though FreeBSD is a great system and very secure).  Have fun.  

Multiple Byte BPF's

If you're just beginning to use BPF's, you'll soon find you need to address fields than span more than one byte. This is very easy to do with a BPF (Berkeley Packet Filter, if you didn't read the previous post). We know we begin our filter with the protocol header we want to work with, such as tcp, ip, udp or icmp and specify the byte the field is in (starting with that byte offset, or counting from zero.) When we worked with the TCP flags field, we used tcp[13]. When we need to work with a field that spans multiple bytes, all we need to do is append a colon to that byte number and then specify how many bytes we want the filter to read. So if we wish to look at the source port field, we would write it as tcp[0:2] (the source port field resides in byte 0 and byte 1 of the TCP header). Now our filter will look at just those two bytes. To only look at packets who source port is 37, we would use the filter 'tcp[0:2] = 37'
BPF, however, has built in primitives, or keywords that apply filters, including "src" or source and "port". So if we wanted to see these packets, the easier way would be to use 'src port 37'.
Other fields have no primitive equivalent. If we needed to see all packets with a TTL greater than 64, we would specify that with a filter like this: 'ip[8:2] > 64'. We're telling tcpdump we want to start at the 8th byte offset from 0 and evaluate two bytes and show any packets that have a value in that field greater than 64.
With your protocol header charts in front of you, you can create a filter to show you any byte in any header and check it against whatever value you need.
By the way, if you're capturing packets for monitoring or auditing purposes, it's usually best to use the largest snaplength (size of each packet) that your storage space and processing power allows, and then use your filters to pull out the packets you need later.

BPF's and Bit Masking

BPF's (Berkeley Packet Filters) allow you filter down to the bit, not just the byte, of a protocol header. There a number of fields that might require you to do this, most notably, the TCP or IP flags fields.

The TCP flags indicate what type of packet it is. They are:

SYN - synchronize or begin the connection. SYN packets are only used during the initial three way TCP handshake.
ACK - acknowledgement that a packet was received
FIN - finish the connection gracefully with both sides shutting it down in an ordered manner.
RST - reset tears down the connection with no further exchange of packets, usually used when a host denies an attempted connection or a the client is terminated abruptly, like closing a web browser.
PSH - the push flag indicates to the other connection that it should process this data as soon as possible  instead of queuing it in the TCP buffer
URG - the urget flag is used to process data that must be processed immediately (such as a character in a telnet session) and uses a pointer to indicate the last byte of urgent data.

These fields are located in the TCP header at the thirteenth byte offset from zero (protocol fields start at 0, not 1). Proceeding them in this byte (highest order bits, or left-most since networking is big endian) are two flags used for differentiated services, or what used to be known as ToS (type of service). They aren't related, just know they are there as it will matter when we construct a BPF.

So our bits are laid out like this:

C E U A      P R S F

In the first nibble (4 bits) we have the two differentiated services flags, then the urgent flag and finally the acknowledgement flag.

In the second nibble we have the push flag, the reset flag, the syn flag and end with the fin flag.

So if we need to see only one type of packets to do our analysis, we need to employ bit masking to narrow our BPF down to that bit or bits. The way we do this is to write out the entire byte and mask out the bits we don't want to see and retain the bits we do. To do this, we apply a zero to bits we want to filter and a one to bits we wish to retain. For example, to see only SYN-ACK packets:

C     E     U     A     P     R     S    F
 0     0     0      1     0      0     1    0

We have zeroed out all the bits except the ones corresponding to the ACK and SYN flag. The ACK flag is the least most significant bit in the first nibble (4 bits make a nibble and two nibbles make a byte) and the SYN flag is at the second least significant bit in the second nibble.
This would give us a binary mask of 0001 0010. Convert that to hex and we have 0x12. To apply this as a BPF filter, we do a bitwise AND  operation on the byte. Any 1 ANDed with another 1 equals one, and a 1 with a 0, OR if both are 0, equals zero.

We use the "&" operator to do the bitwise operation. In BPF filters, the byte number is appended in square brackets to the protocol header we're working with. So in this case, we're working with the TCP header and byte 13. So the first part of our filter is tcp[13].

Now we add the bit shifting. So the second part of our filter is: "& 0x12". And finally, we tell it what value to compare the result to. Since we are checking for SYN-ACK packets, we want the entire byte to equal 0x12, which would be the value if only the SYN and ACK flags were set. So our entire filter would be:

'tcp[13] & 0x12 = 18' or we could write it 'tcp[13] & 0x12 = 0x12' since 12 in hex equals 18 in decimal. Either way would work.

You should always put your BPF in single quotes (on Linux boxes) or double quotes using WinDump, as a good practice. Your BPF may not be complex enough to need it every time, but if you always do it, it won't bite you when you have a compound filter that requires it.

Using this method, we can now specify any bit or bits in any byte in any header. Very powerful tool.

If you're new to packet analysis, you may need to learn or do a refresher on hex and binary, and look at bitwise operations, but that, with a copy of your protocol header charts, is really all you need to accomplish this.

You can span multiple bytes, chain multiple filters together, mix primitives (built in filters, like tcp) and complex filters, and get as specific as you need. And you can save your very exotic filters into a file and have tcpdump read them in from the command line with the -F switch.

Wireshark As A Teaching Tool

Wireshark, the most popular (and free) protocol analyzer, can be a great tool to gain familiarity in analyzing packets. The main Wireshark window is separated into three frames. The top frame is a list of all the packets Wireshark captured, showing the timestamp, source IP, destination IP, protocol and information about the packet (such as the source and destination port, the type of packet, the sequence and acknowledgement numbers, and so forth) The second frame shows the protocol headers in order, with expandable fields and the last frame is the actual packet data. If you're not familiar with the headers of a packet and the header charts aren't making sense yet, you can click on each field of the headers (Ethernet, IP, TCP, ICMP or whatever) and Wireshark highlights the field in the packet data frame for you.
This makes it very easy to see where the Ethernet header begins and ends, which parts are the IP header, TCP header, and so forth.
As you step through each field, you'll begin to become familiar with the layout of each header. With time you'll start to easily find the IP header (usually beginning with 45 00, the embedded protocol field (06 for TCP, 01 for ICMP, 11 (hex) for UDP) and so forth. This will especially be helpful for fields that don't fit neatly on byte boundaries, such as the flags field in the IP header (reserved, don't fragment, and more fragments bits) and the TCP flags bits (SYN, FIN, ACK, RST, and so forth).
Try capturing different types of traffic using the capture filters and step through each field. Some traffic will have other headers that Wireshark will display for you, such as DNS traffic. Within the Domain Name  System header, you'll be able to clearly see fields like the type of query, the transaction ID number, and the type and number of answers received from the name server.
Wireshark can analyze hundreds of protocols, is laid out very intuitively, and is a great aid to learn the inner secrets of packets. 

Book Recommendation

I'm reading a new book on packet analysis that would be good for someone new to network security (or just networking). It's by Chris Sanders and it's called "Practical Packet Analysis: Using Wireshark To Solve Real-World Problems". The first chapter on "Packet Analysis and Network Basics" would be especially helpful to someone just starting out, as it's one the clearest, easiest to understand summaries of protocols and the TCP\IP stack I've read. It's also not a terribly expensive book. I picked up my copy for about $30. If you're looking for some informative reading on packet analysis over the holidays, I'd recommend this one.

Network Security Tool list

Fyodor, author of nmap, maintains the excellent Sectools.org site, which lists the top 125 network security tools as determined by online survey. The 2011 results are posted, and there are no surprises (to me, anyways) in the top ten. This is a great site to peruse and find a new tool to do an old job better, or address a new need.
http://www.sectools.org

IDS Evasion Part II

  Another form of IDS evasion uses fragmentation to to evade the pattern matching function of the sensor. When a packet has to traverse a network with a smaller MTU than the network it originated from, the packet must be broken down into smaller chunks. In order for the destination host to be able to reassemble those fragments, IP uses an ID field to identify all of the packets that are part of the fragmentation train. Each packet will also have a fragmentation offset, which is it's order in the original packet.
Ethernet has an MTU of 1500 bytes. If the packet traverses a network with an MTU smaller than this, say 576 bytes, the maximum amount of data that could be carried in the first packet would be 576 bytes, minus 20 bytes for the IP header (assuming no IP options) and the size of the layer 4 header. If this were TCP, that would anywhere from 20 bytes (minimum) to 60 bytes (maximum).
   Let's say the TCP header is also 20 bytes for simplicity. The data in that packet would be 536 bytes. When reassembling that stream, the data in the first packet would have an offset (order) of 0 (counting begins at 0, not 1). The next packet's data offset would start at 536 (the previous packet would be contained in the first 0-535 bytes) and so forth. But what if the second packet gave a fragmentation offset of 516, instead of 536. This would produce fragmentation overlap, that is, the second packets data overlaps the first packets last 20 bytes. What does the network stack do with this data? Does it overwrite the last 20 bytes of the first packet, or, does it discard the first 20 (0-19) bytes of the second packet and start writing byte 20 at the 536 byte offset?
   What a network stack does here is identified by one of two methods, called favor old or favor new (or first or last). Not all network implementations use the same method. For example, Windows hosts use the favor old method. Linux uses favor new. In order for your IDS to properly reassemble fragments the same way as the destination host will, it needs to know whether the hosts it's protecting use favor old or favor new. Why is this an issue? Say an attacker sends a fragmented attack to a server. Withing those frag packets, he crafts one packet with some bytes of extra data that are not part of the attack, but sends the next packet with an overlapping offset to overwrite those packets, because the server is Linux based (favor new). As long as your IDS is set to favor new, it will correctly overwrite the bogus data as well, correctly detecting the attack. But if your sensor is set to keep the original data in the first packet, it will miss the exploit because it will use the bogus data in it's reassembled stream, which will not match the signature.
If you have a targeted sensor near the assets it's protecting and they are all on the same platform, like a Web farm of servers running Apache/Linux, you can set your IDS correctly to reassemble fragments the same way they servers do. But an edge sensor may be protecting assets of differing operating systems that use different methods for dealing with overlapping fragments. That's why targeted sensors that protect a subset of assets and are physically situated close to those assets on the network are preferable.

IDS Evasion Part I

Methodologies to avoid detection by IDS involve one of three types of techniques: evasion, insertion and denial of service. These are defined and described in the landmark paper "Insertion, Evasion, and Denial of Service:Eluding Network Intrusion Detection", released back in 1998 by Thomas Ptacek and Timothy Newsham. A new intrusion analyst would do well to read this paper, mostly still relevant after 13 years, and keep a copy for reference.
An insertion attack is where an IDS accepts a packet that the destination host rejects.
An evasion attack is where an IDS rejects a packet that the destination host will accept.

An example of an insertion attack would be where an IDS does not calculate TCP checksums, or does not calculate them correctly. An attacker sends a series of packets containing an exploit to host A. Within that stream of packets is one with a bad TCP checksum. If IDS B does not detect that the checksum failed, it will use that packet when it reassembles the stream and check it against it's signatures and processors. The match will fail because of the extra payload data contained in the bad packet, and the IDS will miss the attack.

Host A, however, will drop the packet with a bad checksum, reassemble the packets, and the exploit will be launched. The IDS never saw the attack. This is an unlikely scenario in 2011, but the next one I'll discuss involves at least one modern IDS that is still vulnerable to an evasion attack outlined over a decade ago.

NIC Offloading and Packet Capturing

Doug Burk, the guy who wrote and maintains the Security Onion Live DVD, posted a nice article on NIC offloading and the issues it can cause capturing network traffic here. Rather than try to regurgitate Doug's article, I'll summarize by saying it deals with the ability of modern network cards to offload the processing of traffic from the CPU, which is a great thing on fast (Gigabit) networks, but not what you want when capturing traffic. Why not? Because the controller does it's own reassembly at sizes greater than the MTU of your link, causing the sensor or sniffing program to miss part of the packet, in some cases, substantial parts of it. Doug is looking for feedback on this, so if you test and find you're getting "super-sized" packets in your packet captures (Wireshark will flag this for you as "Packet size limited during capture", let him know if you can.

IDS\IPS 101-6

Once your sensors are filtered and tuned, what you should have left are EOI's (events of interest), events that are either obviously malicious, suspicious, or enough of an anomaly to warrant investigation. How you investigate is dependent on a couple of factors. 1, What is your role? Or you strictly an intrusion analyst or do you do double duty as an incident responder as well? If  so, you'll need to go deeper in your analysis, possibly to the point of working directly on an affected server or desktop.
 But hopefully you're specialized as an intrusion analyst, and only touch alerts and the associated packets, and another team or person does the response and recovery.

Assuming that will be your role, what do you use to dig out the info you need to determine what happened?

Some IDS have a SIEM (security information event management) built in, like Enterasys' Dragon Defense, while others offer it as a separate, bolt on product (Symantec). Others are offered by SIEM-specific vendors such as Arcsight and LogRhythm. Log analysis tools like LogLogic and Splunk will also let you look at other data associated  with your alert.
But what if you work for a smaller company, and your IT security budget was just used  up with your IDS project? Fortunately there are lots of great open source tools you can implement to help you work through your alerts and determine what occurred (or didn't, as the case may more often be).

The first category of tools are the packet grabbers, the "packet auditing" tools. Your IDS will capture the packet or packets related to the alert, but not much else unless you specify it. Your IDS may not really be the place you want to collect more packets, as it's a busy box as it is. You can use another program on a separate host to do this for you, and do the analysis on that box as well, reducing the CPU cycles needed (it takes a while to decompress a 3 GB packet capture). I've mentioned many of these on this blog before, but I'll summarize them again here.

1. Daemonlogger (http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html) Written by Marty Roesch, author of snort, Daemonlogger will capture packets and write them out to a pcap file for you, or it can also act as a software-based tap, meaning it can capture on one interface and write back out to another. 

2. tcpdump - tcpdump has the ability to rotate pcap files based on size, doing the file naming for you, for x number of captures. Once you've reached the limit you specified, it will overwrite the oldest file with the newest. 

3. IDABench - based on SHADOW, IDABench is a perl based framework that captures packets into hourly pcap files, writes a summary of them out to a web page and allows you to search on multiple hours worth of captures using tcpdump, ethereal (yes it's old and outdated) and ngrep.Still a great tool. Contact me if you'd like a copy of it; it's no longer available anywhere on the Internet as far as I know.
Analysis Tools
1. Wireshark Wireshark (http://www.wireshark.org/) is one of the the most prolific protocol analyzers available. Wireshark supports hundreds of protocols and provides an interface that easily separates out the different headers to aid analysis, as well as allowing you to carve out content data.
2. Netwitness Investigator (http://netwitness.com/products-services/investigator) is a free form investigative tool that allows you to search and drill down into packets using contextual keywords instead of by header.
3. Network Miner (http://sourceforge.net/projects/networkminer/) Network Miner parses through pcap files or traffic on a network interface and identifies host names, operating systems, and open ports, as well as pulling out any files it identifies and filing them under directories for inspection.

IDS\IPS 101-5

Once you've determined what, where and how to deploy, and stand up your sensors, the real work begins. Once your IDS/IPS is up and running, the tuning phase begins (and never ends). If you're fortunate enough to be able to run the system in baseline mode for a couple of weeks to tune down the majority of the white noise, you can accomplish quite a bit using your trending or summary tools. Find the top talkers and start filtering out the obvious false positives that constitute large volumes of alerts. Lot's of internal processes can generate alerts that are benign, but look like events to the IDS, especially Windows networking processes. The IDS alerts themselves being forwarded to a mail server can even regenerate another alert for the same event, if you're including packet data (and the signature is especially broad in nature). Realize that once you've tuned your systems down to an acceptable level of alerts and feel confident you've about completed the process, you'll be doing this on a continual basis (or else see the white noise/false positive rate increase more and more over time). New signatures, additional network segments, new types of servers/services offered will all introduce FP's (false positives) into your system and will need filtered as they are identified. Your company may separate out the sysadmin duties from the analyst duties if the staff is large enough. For medium to small companies, you may wear both hats. I've found that's both an advantage and a disadvantage. The obvious disadvantage is that the more time you spend applying new signatures, filtering and tuning, and possibly even doing maintenance and patching, the less time you have to look at and analyze alerts. The advantage is that you, as the intrusion analyst, are uniquely qualified to make decisions or recommendations as to what traffic needs filtered, and what new signatures are relevant to your companies network infrastructure.

IDS\IPS 101-4

HIDS:
A HIDS (host based intrusion detection system) is installed directly on the server, and it's responsibility is to protect the system. The HIDS does not monitor traffic on the interface(s). Instead, it monitors it's application logs (such as Apache or IIS), and system logs (like the event logs on a Windows machine or syslog on a Linux box). Another important task of a HIDS is to check for changes to critical system files and alert when they have been modified (in the same manner as Tripwire). A HIDS will have a signature set, similar to the network IDS, that looks for strings associated with exploits being levied against the server. Since the packets reaching the host must be complete and formatted correctly, many of the evasion tactics used on the wire to bypass the NIDS will not be effective against the HIDS engine (such as fragmented packets with overlapping offsets, low TTL packets added to thwart the reassembly on the NIDS but dropped before they reach the destination, malformed packets for the same reason, etc.) A balanced, defense-in-depth security posture should include a HIDS on each public facing server at a minimum. Another good place to deploy host based detection is on critical systems such as database servers, human resources/payroll, servers that store PII (personally identifiable information) of clients or employees, and domain controllers and name servers.

IDS/IPS 101-3

Deployment:
One of the most critical decisions you will make concerning a new deployment is where to situate your sensors. Correctly locating your units will allow you advantageously monitor interesting traffic with less white noise to filter out. I was taught that there are two main schools of thought on the matter (and this is a 50,000 foot view of it):
1. The "umbrella sensor", as one of my SANS instructors called it. An umbrella sensor is one that sits at the periphery of your network, somewhere near your edge routers, firewalls and switches, and monitors all of the traffic coming in and going out. This may be fine (and the only financially allowable) solution for small, simple networks, but it doesn't scale well for complex networks. Large networks have many segments that need monitored, some public and some private, requiring many sensors. Encrypted tunnels such as VPN may make monitoring traffic impossible and infrastructure equipment on private segments with partners and clients may not be under your companies control. Sensors situated outside firewalls and routers may see so much white noise traffic as to make it nearly impossible to filter. If, however, your public infrastructure is small or budgetary limitations dictate you starting out with the "umbrella" approach, I would recommend placing your sensors behind your filtering equipment such as routers with ingress ACL's and firewalls. There are several reasons. The most obvious reason is noise. Unless you have near unlimited resources to look at and analyze events, you'll probably want to see just the traffic that made it past your router ACL's and firewall rules. Seeing what is traversing your network is critical and mandatory. Seeing what bounced off your hardened exterior is optional.
Another reason is that you'll be monitoring outbound traffic as well. Unless you're inside of any devices doing NAT/PAT such as firewalls, load balancer and proxies, you'll not see the real internal IP of an outbound connection. If that box was compromised and starts connecting back out to the attacker, and especially if data leakage is taking place, you'll need to shut that box down immediately. If what you are seeing is a NAT'd address, it may take you a while to find it in the logs (assuming you're logging on that device). With the real IP, you can locate and shut the offending device down easily (or isolate the port).
2. Targeted sensors. Targeted sensors sit close to the assets they are defending (like a Web farm). Because they are only a hop or two away, they see much less traffic (theoretically only traffic destined for one of those devices), so white noise is much less. The sensor can be tuned down to a smaller signature set specific to the protected assets. If your entire Web farm is Apache web servers running on RedHat, with no other services except what's needed for remote administration, your rulebase becomes a much smaller, more manageable subset of the whole. Hardware requirements drop as you're seeing much less bandwidth passing through the sensor, or the monitoring device attached to it. You'll probably want to still have a sensor behind the edge of your main ingress points as a first point of defense and a correlating packet collector, but your internal, targeted sensors will get most of your attention. If an attack has made it past all the filtering from the edge of your network down into one of your service segments, this would be a great time to see if your infrastructure blocking needs tightened up. IDS often is a validator of policy on your other security devices.

IDS/IPS 101-2

IDS vs IPS:
The difference between IDS and IPS is both in form and function. At a high level, an intrusion detection system is a passive device that monitors packets and identifies attacks using signatures and intelligence built into the IDS engine. The usual example is the string "get /etc/passwd", which used to mean (before shadowed password files) an attempt by someone to read the password file on a Linux/UNIX system. The IDS detects the string in the packets, and depending on how it's configured, alerts the analyst by some means, such as an email or via syslog or SNMP. This is a passive monitoring of the event (though some IDS have the ability to "shoot" down sessions by spoofing RST (reset) packets to both ends of the connection.) The IDS will have a management port with an IP address on it that allows it to forward it's data on to a collection/management console and allows remote access to it for administration (this may be done via an OOB (out of band) private network to limit access to the systems. It's monitoring port or ports will connect to a tap inserted at the desired point in the network, or a SPAN port on a switch.
Intrusion prevention systems sit inline, that is, they are connected directly to the network and all packets must pass through them. This is done via two NIC's (network interface cards), each attached to one end of the connection, such as between a firewall and a switch. Since all traffic passes through the IPS, like a router, the system has the ability to shun sessions it detects as being malicious by simply dropping the packets. No need to generate additional traffic in the form of reset packets. No notification is made to the attacker that the active response is taking place. The session, as the name implies, is prevented from continuing. Of course, if the event is a false positive, the very real possibility of dropping legitimate, business related traffic exists. Careful tuning and monitoring of the traffic must take place on an on-going basis to ensure the IPS doesn't interfere with normal traffic. Since the IPS sits inline, no tap or SPAN port is needed, but redundancy must be dealt with in case the device crashes or reboots. Most IPS are configured to fail open, which means if the software fails and stops working, the device will route all packets. Even then some traffic may be prohibited in the process of failing over. Some shops use a by-pass tap that routes all packets through the IPS as long as the interfaces are detected as being connected, but bypasses the device and routes the traffic directly if the interface goes down. Other use a second IPS, set up in fail over mode, so if the first device goes down, the second IPS takes over. The advantage here is twofold: you do not lose connectivity, the primary concern, AND you also do not lose your intrusion detection and prevention coverage while the first device is offline.