Pre Installation Design
Many people run into the issue of sizing their IDS deployments and determining what hardware to use. While most open-source IDSes have been installed on very old hardware, it mostly depends on the network utilization that the IDS will be tapped into.
50Mb/sec or more is my rough estimate on when you need to be careful about what hardware to put in place. The best approach, in my opinion, is to get the best server you have that is laying around, install your IDS engine (Snort/Suricata) and configure as if it were going to be your production sensor. After it's deployed and in place, find out where the bottleneck is. If it's CPU utilization, memory, disk space, disk I/O, etc. The one downfall to this approach is that you must have hardware laying around.
A span is when a switch is configured to send a copy of all traffic to a specific switchport. If the switch has 24 ports, you can configure the switch to send all traffic going in and out of port 1-23, plug your Snort sensor into port 24, and have the switch send that traffic to port 24, which is linked to the Snort sensor. The downfall to this approach is that the switch is now responsible for forwarding all that traffic, so it's going to run higher in CPU and memory. On small links, this shouldn't be an issue. Bigger network links, such as a large company's internet gateway, this could be an issue. Also, in previous Cisco IOS versions, there was a cap for only 2 span ports on a switch. Running something like a 6500 serious Cisco switch chassis, it means that you will only be able to forward to two ports out of the hundreds of ports possible to put in there (depending upon the modules plugged in). This could cause you to have to purchase bigger hardware. If you're using VLANs, this will cause design issues later with the IDS engine in that you lose some granular control.
Taps to the rescue! Taps are a passive sniffing technology that helps offload some work from the switch. Most taps are only one way, so tapping one link actually requires two taps and two network interface cards (NICs) in your sensor.
Further reading: http://www.ntop.org/blog/ntop/port-mirror-vs-network-tap/
Whatever OS your most comfortable with. Hopefully it's a Unix variant (Unix, *BSD, Linux), not Windows. If you're new to those types of systems, I recommend Ubuntu. It's easier to manage for new-comers. Just remember to apply security updates and host-level monitoring software (like Sagan!).
While there's not a whole lot of discussion on how fast the CPU should be, CPU's above 2.0GHz are pretty cheap and that seems to be a standard. Regardless of speed, there's a good guide on the number of CPU's you need. It is outlined below. Do be careful, new-comers might struggle with a multi-core instance. Snort 3.0 is supposed to be multi-threaded, Suricata currently is.
Further reading: http://ossectools.blogspot.com/2011/04/network-intrusion-detection-systems.html
Memory is affected by many different contributing factors. The size of the ruleset being ran, if the rules contain regular expressions, network utilization, traffic, and the operating system! If possible start with about 2GB of RAM and see if there's a bottleneck.
This largely depends on if you enable OpenFPC (Full Packet Capture). Without it, disk space requirements are at a minimum. But I highly recommend you enable OpenFPC. If you're a systems administrator reading this, you'll make any real security analyst much happier.
Using barnyard2 and unified2, disk I/O doesn't seem to be much of an issue.
You can either have your IDS log to the database directly, or use barnyard2 (http://www.securixlive.com/barnyard2/). Using barnyard2 is preferred because it takes the load off the IDS from having to perform the logging.
Emerging Threats (http://www.emergingthreats.com/ link is dead) - great for knowing a system is compromised. It's free, and anyone can contribute. Supports Suricata and Snort. Emerging Threats Pro (http://www.emergingthreatspro.com/ link is dead) - paid subscription, adds more signatures developed by the company's security researchers Talos (http://www.snort.org/talos) - They have a personal and business subscription, both require purchasing the ruleset. The personal ruleset is very cheap. Talos mostly tries to detect shellcode and attacks while they're happening.
This is the way to go. You will have multiple servers, that means two or more. You will have one or more servers dedicated towards your IDS engine, one for Snorby and for your database. Depending upon the number of IDS engines you plan to deploy, it may be best to even separate out the database server and the Snorby server. You'll find that by separating those out, resource utilization on the servers will not be as demanding and you can save money on not having to purchase heavy-duty servers.
(I would like a diagram here illustrating it)
Mike Lococo wrote a good sizing guide, mostly notes from his past experience: http://mikelococo.com/2011/08/snort-capacity-planning/
On Snort's website, look at "Snort Deployment Guides": http://www.snort.org/docs