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.