DShield

DShield is an extension of the SANS Internet Storm Center and is a "distributed intrusion detection system for data collection and analysis", to quote their site. What this means, quite simply, is that DShield aggregates firewall logs submitted from all over the world, analyzes them, and makes the information available to anyone to use. What you'll find on the site is trending information on what ports are being probed and attacked and who the top attackers are. What makes it really interesting (and useful) is that if you are a contributor, you can see what IP addresses have been targeting you (via the My Reports page and if you so elect, daily summary emails.
To participate, which benefits not only yourself, but the NetSec community at large by increasing the pool of knowledge, you would do the following:

1. Download and install a syslog server (for Windows, Kiwi from Solarwinds works well and is free).
2. Point your broadband router firewall at it.
3. Install the Dshield client and configure it and point it at your syslog file.
4. Use Task Scheduler to run the client at least once a day and no more than once an hour. 

I left out a whole lot of niggling details there, but it's not that difficult to get up and running, there is documentation, and help is available by sending an email to the address provided if you can't get it going. Of course, if you're using some other type of firewall (like a Linux box and iptables) or want to send anonymized logs from a commercial firewall, you'll need to do a little more to get things set up.

The client, called cvtwin, has built in support for most of the major manufacturers of broadband equipment formats. My current router is a Buffalo, and cvtwin parses the logs nicely with no tweaking needed.

You can find the information and the client for download at http://www.dshield.org. You'll not only get some impressive insight into who's thumping your door (without all that manual log inspection), but you'll be helping the overall security of the Internet as well. What a bargain! =-)

Using Filter Files

tcpdump will read BPF's from a file, using the -F switch, making it easy to reuse long, complex or just difficult to remember filters. Unfortunately, there is no way to use a multi-line file, so you must create one file for one filter. To make this a little easier you can create a directory and put all your filter files in it and then set a environment variable for it, like bpf=/home/jeff/netsec/bpf_filters. They you can use the $bpf variable in your command. Tab completion will let you choose between similarly named filters like "syn_only" and "syn-ack_only". You'll probably want to make your filter names as intuitive as possible, but if you find yourself constructing filters to string four or five or more conditions, giving it an (accurate) name that isn't almost as long as the filter itself can be problematic. So, another way to do this is to create a text file with a list of of all your filters, giving each file a number as a name. Then, to use that filter to check for source routing, all you need to do is specify -F . Much easier than typing out a BPF like:
'ip[0] & 0x0F > 5 and (ip[20] = 0x89 or ip[20] = 0x83)'.

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.