JeffSoh on NetSec

BPF Filters Across Protocol Header Boundaries

2012-01-24T22:01:00.000-05:00

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

2012-01-21T23:17:00.000-05:00

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

2012-01-12T22:02:00.001-05:00

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

2012-01-10T23:12:00.001-05:00

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

2011-12-23T09:34:00.001-05:00

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

2011-12-19T13:34:00.002-05:00

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

2011-12-14T07:31:00.000-05:00

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

2011-11-01T15:26:00.000-04:00

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

2011-10-29T17:33:00.000-04:00

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

2011-10-19T14:55:00.000-04:00

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

2011-10-12T15:03:00.000-04:00

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

2011-10-11T14:47:00.000-04:00

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

2011-10-07T10:04:00.000-04:00

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

2011-10-05T13:40:00.000-04:00

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

2011-10-04T08:10:00.000-04:00

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.

IDS/IPS 101-1

2011-10-03T21:37:00.000-04:00

IDS (intrusion detection systems) and IPS (intrusion prevention systems) are a core part of network defense in-depth yet today, despite Gartner's proclamation that "IDS is dead" in 2003. The IDS/IPS market is still kicking, and for the intrusion analyst, most of the alerting he looks at will include events from IDS. That's even if they are aggregated in a SEIM (security event information manager) with firewall, router and host logs and alerting from anti-virus, web application firewalls and proxies.
If you're just getting started or have been tasked with standing up an IDS/IPS where none was previously, there are a number of things to take into consideration, even before you make your first contact with a vendor.
Some things to start working into you project plan would include:

Are you going to deploy NIDS (network intrusion detection systems), HIDS (host-based intrusion detection systems) or both, or are you going to deploy NIPS/HIPS (network or host-based intrusion prevention systems)
Where are you going to deploy your sensors? Depending on the budget being allocated, will you settle for a few "umbrella" sensors, boxes deployed along the perimeter of your network to try and see as many packets as possible? Or will you do targeted deployments, putting sensors in front of web farms, DNS servers, core switches, and critical internal assets such as database servers, payroll and HR?
How will your sensors monitor packets (this will be determined a lot by whether you go IDS or IPS). Will you use network taps or span ports for IDS? If you use inline IPS, how will you address redundancy? Does fail-open circuitry on your IPS box make you feel confident your phone won't ring at 3 AM when the sensor dies or reboots?
How will IDS/IPS integrated into your network teams architectural plans? If the network topology changes, will you be able to adapt to things such as a change in media or major increases in bandwidth?
Who will monitor alerts? What will be your coverage window? If you will be the primary analyst, how is alerting covered during off-hours? Holidays and days off? If a team will handle the duties, is there coverage if a member is out for an extended period of time? Are you considering an MSSP (managed security services provider) to handle the level one monitoring and alerting?
If this is a new addition to your corporate security infrastructure, will there be training provided for the analysts? (like the SANS Sec 503 Track). What about incident response? Will the intrusion analysts also be the incident handlers? If so, will there be training for that as well?

More Packet Sites

2011-09-20T21:39:00.000-04:00

I'd posted a few sites where you could download packet captures to study network traffic and practice your analysis skills, especially if you're new to network security or if investigating alerts is only one of many things that you do (that's more common, especially in smaller shops, than you may realize.) One of the security listserv's I subscribe to had someone post a question on where to find packet captures and the aggregate experience on that list came up with a nice list of additional sites.
Back in March, I posted the packet repositories found on pcapr.net, the HoneyNet Challenges and the Inter-Service Academy Cyber Warfare Competition (http://jeffsoh.blogspot.com/2011/03/practice-makes-perfect.html) . Add to that list these sites from that post..
1. https://www.openpacket.org/
2. https://www.evilfingers.com/
3.http://packetlife.net/captures/
4. http://forensicscontest.com/ (Excellent place to practice, as this is a scenario you must solve, like the Honeynet challenges..)
5. http://chrissanders.org/packet-captures/

A list of pcap sites can be found here

It can be tough after working all day to then sit at home and look at MORE packets, but the more you work with captures, you more familiar you'll become with the both the data and the tools and methods you'll learn to work through huge amounts of data to find that one packet that confirms or denies your investigations theory.
If you're a programmer as well, you'll soon write up all sort of nifty scripts to automate things. If you're not, others have written tons of them, and reinventing the wheel isn't really necessary anyways. Enjoy.

Packet Analysis Tools

2011-09-19T15:59:00.000-04:00

I'm often asked if doing intrusion analysis requires a lot of high-cost tools
(actually I don't recall anyone ever asking that of me, but it sounded good as a
lead in to this topic). The answer, if someone SHOULD ask me that, is no, it
doesn't have to.
After identifying alerts of interest, my current tool kit for analysis includes the following:

- Snorby: Open source front end to snort databases. I just recently started using this instead of BASE
- IDABench: Packet auditing system written by George Bakos, based on Shadow.
(Hasn't been actively supported since 2003, but still works fine. Going to look at OpenFPC as a possible replacement.)
- ngrep: The ever popular packet grepper from Jordan Ritter.
- Wireshark. The best free protocol analyzer available
- xtractr - packet indexer from Mu Dynamics
- Netwitness Investigator - packet indexer/search tool from NetWitness Corporation
- p0f, tcpdump, dsniff, chaosreader, and other various cmd line tools

All of those tools are open-source and freely available. Of course, we use multiple commercial IDS systems and a SIEM and a commercial log analyzer, but all the tools I use to do actual analysis are free.
Does that answer the question you didn't ask? Good!

chaosreader

2011-09-02T22:59:00.000-04:00

I've been tailoring most of my posts towards "if you're new to network security", and lately I've been seeing a good number of stuff on Twitter about how we need to increase mentoring in our industry and share info more effectively. That said, I'm going to use this blog primarily to try and share info with those who are new to security full time (realizing that doesn't mean new to the IT industry a lot of the time).
That said, here's another tool that might be helpful. It's old, but still very useful.

chaosreader:

What it is: chaosreader.pl is a Perl script, written by Brendan Gregg, that takes a libpcap packet capture and indexes all of the connections and extracts a fair amount of the data and organizes it all into a nice web site. You take all the output and load it up in a Web browser (you could do that locally if you're running X on the box you ran it from, or share it via a web server, or tar it up and move to a web server you own.) I personally find it easy to just copy everything to /var/www or /var/www/html, depending on what you're running, since I don't serve web pages out of the default location anyway.

You have lots of options, but the basic ones you need to know tell chaosreader what kind of files to create:

chaosreader infile # Create application session files, indexes
chaosreader -v infile # Verbose - Create ALL files
chaosreader -i infile # Create info files
chaosreader -r infile # Create raw files

Verbose will create all file types chaosreader knows about, -i, just the info files and -r, the raw files. Raw files are data files from TCP or UDP transfers, and info files are descriptor files listing the source, destination and such of the connection. chaosreader also generates a Get/POST report, an image report, and an HTTP proxy report.

Rather than me screenshot chaosreader, the author has created a live sampling here or here that you can browse and get an idea of what the tool does.

How to use it: Download the latest version and put it in a separate directory (it creates a lot of files; you REALLY don't want to run it in the root of your home dir). You can run it live on an interface, or, as I do, run it against a pcap file. Use the switches show above to determine how verbose you want it to be.
For example, if you want to see it all, and had a pcap called web.pcap, you would run:
" perl chaosreader.pl -v web.pcap". With the latest version, you'll see a list of connections scroll as chaosreader reads in the packets and processes them. After it's done, you'll have an assortment of .html, .info, .raw, raw1 and raw2 files, as well as other like JPEG's and GIF's.

It's a very useful tool, but one caution. Very large captures can take a really long time to process, and if your box is running with minimal memory, it might run out before the process finishes. A strong processor and lots of RAM make a good chaosreader box.

Foundstone Tools

2011-08-08T10:47:00.000-04:00

I hadn't been out to the Foundstone site recently (now owned by McAfee), until this morning, and found there have been quite a few new tools added. I keep Foundstone tools on a thumb drive, along with Sysinternals and others (like IceSword and some malware scanners), so I always have a ready copy if needed. If you've never looked at the free offerings available there, you can download any or all at there site found here.
Categories of tools available here are as follows:

Assessment Utilities
Forensic Tools
Foundstone SASS Tools
Intrusion Detection Tools
Scanning Tools
Stress Testing Tools
Spam Submission
Stinger
Utilities

IDABench Lives On

2011-07-29T07:40:00.000-04:00

I just did another install of IDABench, the intrusion analyst's toolkit based on SHADOW. This project hasn't been maintained or updated since 2003 when George Bakos left ISTS at Dartmouth, and yet it still remains a very useful tool (to me at least). I'm at a new job and the folks here never heard of IDABench, so I was happy to install it and show them it's usefulness. Still hoping some Infosec Perl jockey will come across it someday and decide it's worthy of their time to resurrect the project and continue extending it.

Tools from SANSFIRE

2011-07-23T02:14:00.000-04:00

I love finding new tools. Maybe the functionality they provide is simply a shortcut to something I can do with other tools, eliminating a step or two and saving time, or else they might provide a way to do something I hadn't considered before. I came across a good number of new ones at SANSFIRE. I'll post the ones that caught my interest as I review my notes and books, in case one might fill a niche for you.
The first one is pcapcat. This is a perl script which parses through a packet capture, identifies and displays all the sessions by source IP and port and destination IP and port and displays them for you. You then supply a filename and pcapcat writes out the session to a new capture file. Not only does this save some keystrokes and time over using tcpdump, but it's also a handy way to see all off the sessions quickly and determine which ones are of interest. The tool was written by Kristinn Guojonsson to help answer a challenge on forensicscontest.com, which is found here. The actual code can be found here to paste into a new script on you analysis box.
Try it out and see if it'll help save you a little time (or if you're new to network security and aren't sure about all the tcpdump syntax yet, use this until you get up to speed)

SANSFIRE Day3

2011-07-20T02:15:00.000-04:00

It's 2:09 AM Wednesday morning, day four of SANSFIRE. Insomnia has sent in, so it's time to update my blog on the training event. Day 3 saw more excellent teaching in the FOR 558 class. This class is both a logical next step after SEC 503 (Intrusion Detection In Depth) and a different perspective from that track. Going beyond the role of intrusion analyst, it shows you how to become a forensics investigator into events from the network perspective. More than just incident response (identify, eradicate and recover), we're seeing how to take packet data found all over the network and pull the artifacts from the packets. Hex editors and protocol specific tools for SMTP, AIM, Squid and others as well as general packet parsing tools all combine to not just reconstruct the session and see what happened, but extract the data much like a traditional forensics investigator would from a hard drive. We're told day four will be the most hard core yet. From a survey of the book, looks like we're going into Netflow and wireless, as well as concepts in digital evidence.

SANSFIRE Days 1 and 2

2011-07-18T00:52:00.000-04:00

Saturday began SANSFIRE for me with SEC 546:IPv6 Essentials. This was also Day 2 of the Security IPv6 Summit. The class was taught by Dr. Johannes Ullrich, a SANS senior instructor, Dean of Faculty and Chief Research Officer. If you're not familiar with IPv6 and the myriad of things to consider when preparing for migrating, I recommend you take this course (tell your boss you want to add it on to your five or six day course to help the security department prepare for IPv6). It was a huge amount of information packed into a one day course that will serve you well in any future discussion.

On Sunday, I began the FOR 558 course, which is network forensics. This is being taught by Jonathan Ham, an incredibly knowledgeable instructor, whose bio can be found here. This was my first class with Johnathan. The motto for FOR 558 is "No hard drive, no problem". As this suggests, the class is all about doing forensics analysis, not from the computer in question itself, but from the footprint (or fingerprint) it's network traffic has left. Day 1 took off at full bore after a quick review of networking essentials, using SNIFT, the FOR 558 equivalent of the SIFT tool used in the traditional forensics classes, to create and examine packet captures, examine them using tcpdump, Wireshark and a hex editor, and pulling data from the packets. It's not the ordinary course that has you carving graphics files with a hex editor out of bytes pulled from a pcap file. If you're an intrusion analyst, incident response team member or security investigator, you might want to look at this class. Though the class is called a forensics class, it's a perfect complement and next step to SEC 503:Intrusion In-Depth. If you have your GCIA and want to take your intrusion analysis skills a level higher, this is a great class to do so. Here's the details.

SANSFIRE Pre-Conference

2011-07-15T19:06:00.000-04:00

I'm at the hotel that's the site of SANSFIRE 2011 (the Washington Hilton in D.C.) and ready for tomorrow. I'll start out with a one day course with Johannes Ullrich, SEC 546, which is a primer on IPv6. Then Sunday we start on Forensics 558, five days with Jonathan Ham on Network Forensics. It's going to be a good week. Saw Stephen Northcutt earlier and got to say hello to him and tell him what classes I was taking, and hear from him how well the IPv6 Summit today went. I love the atmosphere of this conference. Eager to get started tomorrow.

SANSFIRE 2011 Evenings

2011-07-08T10:35:00.000-04:00

For SANSFIRE this year (starting July 15th) we have the following evening sessions to choose from:

Cyber Security Trends and Lessons Learned from Large Scale Incidents in Japan

- Tomohisa Ishikawa
- Sunday, July 17 * 9:15pm - 10:15pm

FACEROUTE: Mapping and Harvesting Social Media Sites

- Rob VandenBrink
- Monday, July 18 * 7:15pm - 8:15pm

Securing The Kids

- Lance Spitzner
- Monday, July 18 * 7:15pm - 8:15pm

Ninja Developers: Penetration Testing and Your SDLC

- Kevin Johnson
- Monday, July 18 * 8:15pm - 9:15pm

Securing The Human

- Lance Spitzner
- Monday, July 18 * 8:15pm - 9:15pm

Is IPv6 the Wolf in IPv4s Clothing?

- Richard Porter
- Tuesday, July 19 * 7:15pm - 8:15pm

Security Testing Automation and Reporting

- Adrien de Beaupre
- Tuesday, July 19 * 7:15pm - 8:15pm

Are your tools ready for IPv6?

- Jim Clausing
- Tuesday, July 19 * 8:15pm - 9:15pm

Nurturing the Next Gen of InfoSec Geeks: Creating Kid-Friendly Challenges for Fun and Mayhem

- Ed Skoudis, Kevin Johnson, Josh Wright
- Tuesday, July 19 * 8:15pm - 9:15pm

DNS Sinkhole Peer into your network while you sleep

- Guy Bruneau
- Wednesday, July 20 * 7:15pm - 8:15pm

Using Scapy to Craft an IDS/IPS Evasion

- Judy Novak
- Wednesday, July 20 * 7:15pm - 8:45pm

Adding Network Flow Analysis to your Security Architecture

- Sidney Faber
- Tuesday, July 20 * 8:15pm - 9:15pm

Cisco Malware; A New Risk to Consider in Perimeter Security Designs

- Manuel Humberto Santander Pelaez
- Wednesday, July 20 * 8:15pm - 9:15pm

SQL Ginsu: Better Living (and Data Reduction) through Databases

- Philip Hagen
- Thursday, July 21 * 7:15pm - 8:15pm

More Parsing for Beginners

2011-07-01T16:06:00.000-04:00

If you're new to NetSec, you don't have to learn a ton about any one subject to get started doing your job. There are more resources out there than you could possibly ever use to quickly get enough knowledge to take care of the job at hand and then go back later and learn more. Say you have a directory of packet captures. You've been using tcpdump or Daemonlogger to get raw packets as an audit trail (or IDABench, an outdated but still useful favorite of mine). Your boss wants you to do a sanity check for some sort of PII, to validate some control. A search on doing iteration in bash will probably lead you to the for command, where you can feed ngrep with your packet captures, one by one...
Here's an example...

for i in $( ls | grep -v .gz );do ngrep -q -I $i ' [0-9]{3}-[0-9]{2}-[0-9]{4} ';done

This is simply using the for command to use ls to search for any of your captures that aren't gzipped (if you use bzip, you'll need to modify it) and populate a variable called $i, then run ngrep against the value contained in that variable (one of your packet captures) and look for numbers in the Social Security format. There are all kinds of regex sites with common searches you can use without having to become a regex guru first.

Handle the job at hand, then backtrack and learn...

Reload

2011-07-01T15:48:00.000-04:00

I was given a really nice laptop at work as a scan/test box, so I loaded it up with Fedora 15 and Windows 7. I'll take this one to SANS with me in a couple of weeks. I realized as I started adding tools that it had been a really long time since I had updated my list that comprise my toolbox. So I just added a few basics while I gave it some thought. I do very little vuln assessment and no pen testing, so the majority of any tools I install would be analysis related, with the exception of some to generate packets or do a quick port scan. Here's what I've put on so far..

nmap
ngrep
hping
dsniff
etherape
iptraf
scapy
ipcalc
p0f
hexedit
wireshark

And to be installed...

netdude
chaosreader.pl
xprobe
xtractr

Now to find that old list and update it with the new stuff I've found lately..

Suggestions?

Switching Gears

2011-06-05T21:22:00.000-04:00

I'm about eight weeks into a new (actually just my second) network security job. After thirteen years at my former employer, I saw the end coming eventually and bailed (my old company was bought out by a Really Big Company and my job description didn't exist in their world). I went from, at various times, doing: intrusion analysis, sys admin of all NetSec servers, being the lead technical resource on most company-wide security technology roll outs, vulnerability testing, anti-virus, web content filtering, log server analysis and maintenance, end user education, security threat research, policy writing and upkeep, assisting with audits, incident response, desktop and server patching, and server hardening, to... intrusion analysis and maintenance, maintaining the SEIM, and eventually, maintaining the wireless IDS.
I also went from a really decent IDS to what has to be the worse product on the market. Fortunately, I AM involved in the project to find a new solution and replace the current one.
It's a really big change and it's taking some time to get used to NOT being involved in every security discussion, project or decision. I was the lone NetSec person supporting all of the rest of the IT department (something I grumbled about, especially when I finally got a direct report, who we had to fire and wasn't replaced). Now I'm one of a team of five, which means I can finally specialize for the first time ever.
I'm trying to decide if it's better now that I can focus on intrusion analysis or if I really MISS being the lone security person where I basically had carte blanche authority to run network security they way I saw fit..
As "they" say, be careful what you wish for, you may end up getting it..
Anyone going to SANSFIRE, drop me a line if you'd like to meet and have a cold beverage. Extending the network of network security folks is one of the best things about doing the live conference as opposed to the online training.

SANSFIRE 2011

2011-05-25T11:53:00.000-04:00

After a four year hiatus, I'll be returning to SANSFIRE this year, held on July 15 through the 24th. The event will be at the Hilton Washington Towers , and besides all the usual SANS @Night events will include a round of NetWars. This will by my fourth conference in D.C. and my sixth overall.

IDS\IPS Placement

2011-05-06T13:18:00.000-04:00

Determining where to place the sensors in an intrusion detection/prevention system is one of the first decisions that need to be made when deploying a new system (or replacing an existing system). To the extent that it has been determined what kind of sensors will be deployed (IPS or IDS, in line or promiscuous), placement can then be considered, regardless of what vendor will be used.

There are various types of placement deployments that can be used, such as using edge or “umbrella” sensors. This deployment model identifies the egress points at the edge of the network and situates a sensor there to monitor all traffic in and out. This is usually (optimally) deployed at some point behind the firewall that is performing address translation on the IP addresses. This allows traffic associated with a compromised host to be readily identified. Because of its location behind the firewall, the analyst does not need to deal with traffic that has been shunned at the edge router or dropped by the firewall.

Vint Cerf, one of the “founding fathers” of the Internet, once famously said, “The wonderful thing about the Internet is that you’re connected everyone else. The terrible thing about the Internet is that you’re connected to everyone else”. So it is with edge sensors. The wonderful thing about them is they see all traffic entering as network at that particular point. And that is their weakness as well. Tuning and filtering is a constant challenge at that point, especially if the sensors monitoring point is place outside the firewall, and all the malicious traffic that would be rejected is added to the flow.

Tuning can be accomplished much more readily with a dedicated sensor near the assets it will be protecting. For example if you have an Apache Web farm off your DMZ, a sensor located in front of it can run a tuned, minimalistic base of signatures looking for exploits against Apache and the OS you’ve deployed the Web servers on. Umbrella sensors need to run a comparatively larger signature set to be able to detect anything in the general flow of traffic coming in.

Consider fragmentation reassembly. If your sensor will protecting hosts that reassemble with both the favor old and favor new methods for handling overlapping offsets, your IDS/IPS will need to be able to reassemble traffic this way as well. Some IDS platforms, like Enterasys Dragon, give you an either/or choice. You can only choose which method the majority of the hosts use and hope for the best with the others, if you’re employing only an edge sensor. However, if your entire Web server segment is Linux servers, and all your database servers are running MS-SQL , you can tune the focus sensor according to the methodology used.

Note: Snort’s frag4 processor allows you to specify ranges of IP’s to be processed in one of the two methods.

Another consideration concerning focused sensors is reduced bandwidth. Obviously, a sensor only monitoring traffic to a specific segment or group of servers will see considerably less traffic than the sensor at the perimeter of the network. This can translates to a lower initial cost on licensing in addition to decrease in tuning and filtering.

All said, does that mean sensors should never be deployed at the perimeter? That is a decision for the intrusion analysis team to discuss with management and depends on the breadth of the deployment. The more places a flow of traffic is seen, the more likely an alert will be triggered. This loosely fits in with the general concept of defense in-depth (though true defense in depth would deploy different technologies to mitigate attacks). However, if the perimeter sensor is sitting physically beyond filtering devices such as firewalls, UTM, reverse proxies, application firewalls and the like, aggressive tuning to filter our noise will probably be in order.

Another consideration is whether or not to deploy the sensors exclusively from one vendors offering. Having a heterogeneous environment has the advantage of different signatures and security policies monitoring the traffic. You may have multiple monitoring points going deep into your internal network, but if an attack evades a signature, and all sensors are running the same signature, you’re blind to the traffic. Instead, by deploying another vendor’s sensor at some of the monitoring points, you now have two possible chances at detection.

In the end, where (and what) to deploy will need careful consideration and input from multiple parties. There is no one size fits all solution and this important decision should be at the front end of any deployment of intrusion detection technology.

IDS Signatures

2011-03-23T10:31:00.000-04:00

I'll soon be moving into a new job, where I'll be supporting an IDS with a closed signature set. If you're new to NetSec and are tasked with researching out a companies first IDS/IPS, NOT buying a system with a closed signature set is a really good idea. What I mean by a closed set is that the signatures are not editable, or even viewable, by the analyst. Companies will claim "that's our proprietary information and we can't let anyone see it to prevent theft of our intellectual property".
Amazingly enough, other IDS companies have open signature sets and do not have any those predicted issues. What closing the signature set DOES do, to the analyst using the system, includes:

Blinding the analyst to what traffic actually triggered the alert, making it difficult at best to determine if the alert was a false or true positive.
Prevents the analyst from modifying the signature to narrow the scope to prevent too many false positives, or using it as the template for a new signature customized the company's individual needs.
It keeps the analyst from sanity checking new signatures, to see if the vendor is putting out intelligent, well researched signatures, or just throwing out a very generic signature that will also trigger on hundreds of other packets with similar packet data. Companies will do this to allow them to say their signature base detects threat xyz, regardless of whether it's a well written signature or not.

One of the first questions you should ask any vendor (in my opinion) is whether or not they have an open signature set and can the analyst/admin modify or remove signatures (through the GUI, and not through a request process to the vendor), AND, can custom signatures be added.
Another thing to ask, if the signature set is open, is whether or not the signatures are written in a proprietary language or not. Being able to write signature by just following the prescribed format (like Snort or Dragon) is a great boon to the analyst, and cuts way down on the learning curve to get operational. Anyone can learn to write a Snort signature in a short time. However, learning to write a good Snort signature takes a good deal more investment of time..

IDS Placement

2011-03-15T08:46:00.000-04:00

A discussion on the SANS Alumni Group on LinkedIn started up concerning IDS placement. I weighed in with this:

"I've had this discussion before when a company I worked for mandated ONE IDS at the ingress points, with additional ones optional. I've always believed behind the firewall would be where you would put the IDS if you could only have one. My reasoning is that 1) behind the firewall shows you what traffic just made it past your router ACL's, firewall rules, reverse proxying,etc. 2) behind the firewall lets you see the real IP of outbound traffic instead of the hide address, so when boxes get infected or compromised and start connecting out, you can shut down the traffic and easily trace the box to clean it. 3) Outside the firewall keeps down the white noise of junk your perimeter defenses and allows you to concentrate on alerts of interest. If you have both, you tune your external IDS for the traffic you need to see, like specific high value servers or boxes that attract a lot of attacks, to gauge what preventive shunning needs done.
Mike Poor talks about the umbrella sensor, that is the sensor right at the edge of the network that's supposed to detect all traffic to everything behind it and how it's not a good architecture. Ideally, you should have layers of sensors at strategic points, like in front of your web farm, in front of your name servers, in front of WAN links with partners and clients, etc and then you can tune each one appropriately with what signatures you run and with filtering. That's the ideal set up. For many, especially those smaller companies, that umbrella sensor is all you're going to get. In that case, behind the firewall is the only place to put it..."

What do you think (especially those new to the network security field)? Assuming you had to work with an umbrella sensor and could only have one, where would you put it?

Practice Makes Perfect

2011-03-03T11:37:00.000-05:00

If you're just starting out in network security or working towards that end, packet practice will increase your familiarity and improve your speed in doing analysis. It's best to get better and faster now, when there's no pressure or duress, then when an incident is happening and folks are yelling for answers... or what you find determines whether a production system should be taken off-line.
By practice, I mean spending time working with packets. If you have monitoring access to your companies network, that would be the place to start. Not only will it give you access to a wider range of traffic than using your home network, but you'll start becoming familiar with what is normal. It's very difficult to find the anomalous if you don't know what's normal. If you don't have access to your companies traffic yet (and ONLY use your companies network if you have been given explicit permission, in writing, to do so), there are tons of places you can pull down interesting packet captures to play with and practice. pcapr.net has a huge repository, the HoneyNet project has monthly challenges, the Army ITOC posts captures from the Inter-Service Academy Cyber Defense Competition (the NSA provides a Red Team against the the service academies Blue Teams), and so forth.
There all different kinds of ways to practice. You can do scenarios; choose an attribute that would indicate possibly malicious activity, then see if you can find any on your network. Do a realtime sniff for any packets whose IP header is greater than 20 bytes, indicating that IP options are in use. Look for large sized ICMP packets (greater than 100 bytes), and if you find some and they aren't malicious, determine why they're large (Microsoft is one culprit in this category).
You can redirect the captures into text, and use awk and sed and grep and other utilities to start building up a collection of scripts and filters for things you'll want to look for often. If you're a perl programmer, you can use all the nifty perl networking modules to make yourself some automated programs to break apart captures and extract data.
You can use tools like xtractr and NetWitness Investigator to see your high level categories, then drill down and look at the individual packets when you see something interesting. I've been using both to look at events from our IDS.
You can run the packets through dnsiff and see if there are clear text authentication tokens you weren't aware of. Run them through ngrep and use keywords specific to your corporation and look for data leakage going beyond the perimeter of your network. You can load them in EtherApe and watch for the blooms of color.. readily identifying "top talkers", which could be indicative of malicious activity, a network issue or a bandwidth hog, like someone using BitTorrent.
There are dozens and dozens of tools you can run those captures through, and the more you do it, the more familiar you'll become with your network and the better at identifying those folks who refuse to play nice.
Links to packet captures:

pcapr - http://www.pcapr.net/home
HoneyNet - http://www.honeynet.org/challenges
ITOC - http://www.itoc.usma.edu/research/dataset/ (bottom half of the page.. scroll... they're there)

More NetWitness Investigator

2011-02-28T21:30:00.001-05:00

To import packets into Investigator, you need to create a collection (the default collection, as we saw, is simply called "Demo Collection". Create a new collection (Ctrl-L or use the menu), and then you can import your pcap file. The capture must be 1 GB or less, and you can have 25 simultaneous captures at any one time.
Double click your new collection, and after a second or so, you should see it's status change to ready. Now you can right-click on it and choose "Import Packets". Browse to where you've saved your pcap file (hopefully you captured it with full packet data), and you'll see the import process begin. Depending on how much of your 1 GB limit you used, this may take a little while. Once you get the "ready" status once more, double click your collection once more and open it up..

Here we see all of our source and destinations, aliases, content types, ports and services used... and in the lower part of the report, (below) we have counties and cities involved (mine always has Beijing, as does probably yours) and organizations.

Since we see some of our hourly packets from China there, we can now drill down and see that kind of traffic they entail. Clicking on the number in parentheses (the packet count) after Beijing takes us to a nice sessions screen with our summaries for each packet...

I'm redacting my IP address here, replacing it with x.x.x.x, but you get the idea.. Now I can zoom in on the packet data.. and see that as we mouse over each field in the packet header, we get a little pop up telling us the field and doing the hex conversion for us.

We have all the summary information of all packets in the capture to look at. We can, in a few mouse clicks, go from the high overhead view down to the single packet, to any field in that packet, and see it's identification and conversion, if needed. Pulling all this information out manually, then drilling down to granular of a level, even with scripting, would take far, far longer.
Next we need to explore using Investigator to do the data capture itself.

Another Free Packet Tool - NetWitness Investigator

2011-02-25T23:58:00.000-05:00

NetWitness Investigator is a free tool for packet analysis. This one runs on Windows (including Windows 7) only (except for the commercial version, which runs on Linux) and has functionality that includes wireless support, real time layer 7 analysis, IPv6 support, SSL decryption (with the server cert) and full context searching including regex. The freeware version license supports 25 simultaneous 1 Gb captures.

To get started, grab a copy from the download page here and install.
When opening the program for the first time, you'll be prompted to login, or create an account. Go ahead and create a community account and after activating Netwitness (from the email you'll receive), you'll be presented with the Investigator window. In the left hand pane will be a folder marked Demo Collection, a packet capture that allows you to test out the app immediately, without needing to do any capturing of your own.

Double-click the Demo collection icon, and a new tab will open with the contents of that collection, which will look like this:

We can see a whole host of attributes that can be drilled into to explore. At the very top, we see Investigator has flagged three alerts for us, non-standard http, cleartext passwords and irc file transfer. Clicking the "Alert" attribute will drill down to the next level where all the attributes are related to these three alerts. We see the services used, source and destination addresses, ports and protocols, and all our layer 7 info broken out for us, like email addresses, user accounts, and attachments.

Clicking on the "sample_vulnerability:cleartextpasswords:other (1)" link takes us down another level, showing us all the attributes of the packets that triggered this alert. We now know the IP addresses involved, the service type (POP3), the user account involved and the email address involved. When we drill down even further in our later 7 data, Investigator will do reconstructions for us. For example, the email address attribute has one session associated with it (the number in green in parentheses after the field shows the number of sessions). When we click on the number after the email address, NetWitness reconstructs the email header for us:

We can do the same for the other data presented, such as the Creditcards.txt attachment. Investigator will ask us how we want to open the file, allowing us to open it in a default app for the data type, choose a different app or use Investigator itself to open it.

This is just the very basic starting point of what you can do with this tool. Like xtractr, it's a very good tool to investigate a capture and you need to drill down deep in a visual way to ascertain what action took place.

BSides Cleveland

2011-02-19T17:46:00.000-05:00

Went to Security BSides Cleveland yesterday (February 18) and had a great time. The conference was at the House of Blues in downtown Cleveland, and there was a great lineup of speakers. You could truly say there was something for everyone, because the topics ran the spectrum of everything from security education and GRC (high level talks) to thicknet (SQL injection), using Netflow for security and claims based identity management.
I'm definitely looking forward for the next BSides that comes within range of me attending.
The videos are up and available at Ustream (http://www.ustream.tv/channel/security-justice---test)

Learning awk with Practical Examples

2011-02-14T15:21:00.000-05:00

Learning awk with Practical Examples Ten Days of Awk at bashshell.net. I just found this site today. It looks like it will be a good resource for beginners at Linux (including those just moving over to NetSec).

OpenFPC

2011-02-14T09:48:00.000-05:00

OpenFPC Network traffic capture tool. Three components here. A client device used by the analyst to request a packet capture. A master device (or devices) that receive the request, look up what device would have seen the traffic and pull the capture file and display it back to the client. One or more slaves, which are the sniffers doing the packet captures. Looks very interesting; added to my growing list of tools I'd like to test..

BPF's For Beginners

2011-02-10T15:16:00.000-05:00

If you've just started looking at packets, no doubt you've already found the need to pull out packets based on more than just the primitives built into tcpdump and other pcap aware tools (such as src, host, port, net, etc). tcpdump supports the use of the Berkeley Packet Filters expressions, allowing you to search on any field that tcpdump records. The basic syntax is field : operator : operand. For example, if you wished to see all IP packets whose length is greater than 20 (meaning IP options are in use) you would add the filter:
'ip[0] & 0x0F > 5' This says to look at the first field in the IP header (offset 0, headers begin counting at 0), and using a bitmask, filter out the first nibble (the first four bits, 0), looking at the last four bits, (F) and show any that are greater than 5. We know the IP header length field is expressed as a 32 bit word (four bytes), so a 5 in that field (5 x 4 bytes) equals 20, the length of a normal IP header (also the minimum size). So any size greater than 5 would mean a header more than 20 bytes. This means IP options have been added to the end of the header, such as strict source routing, or loose source routing, rarely used and often a sign of a malicious attempt to route packets through a particular node for sniffing or interception.
   Enclosing your filter in quotes to avoid syntax errors is a good habit to get into. You'll eventually need them as your filters get more complex.
You can search on any field in any of the embedded protocols as well. If you needed to see SYN packets only, you could filter on the TCP header with a filter of 'tcp[13] = 0x02'. Here we would see only packets with a value of 2 in byte 13, which would have only the SYN flag set.
   If we needed to look at just a single bit or combination of bits, instead of a whole byte or a whole nibble as in the first filter, we would go back to our bitmasking. Bitmasking bits here is simply applying a bitwise AND to filter out any bits we don't wish to look at, and preserving the bits we do. If we AND a zero to a bit, we end up with zero, if we AND a one, we end up with a 1. So if need to see all SYN-ACK packets, we would want to see all packets with byte 13 in the TCP header that have the least most significant bit set in in the first nibble and the second least significant bit set in the second nibble.

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

So our bitmask for SYN-ACK packets would be 0x12 and we would apply it as this:

'tcp[13] = 0x12' (no other flags should be set here as the SYN-ACK combination is only used in the TCP handshake.)

You can extend this to any field, down to a single bit, and chain them together to get as granular as you need. When you begin writing complex filters and using them over and over again, you can put each one in a file, and use the tcpdump -F parameter to load it, instead of retyping it each time. Very powerful stuff for dissecting packets, and very good to learn. You can't always be sure that you'll have access to Wireshark or some other protocol parser when you do to do network forensics. If you learn the command line way to do things first, you'll hopefully never get stuck.

If you want great training in bits and bytes, protocols and packets, and everything in between (especially if you want to be an intrusion analyst) I'd recommend looking at the SANS 503: Intrusion Detection In-Depth course. Taking it live, in my opinion, is always best, as you'll get the most interaction with the instructor, work with other folks interested in the same knowledge and absorb much more than just the class from the atmosphere of a SANS conference. But take it any way if you can, if you possibly can. And if you CAN go live, use the time you have there to its fullest. Sign up for the free SANS @Night classes, go to the Storm Center presentation, go listen to the keynote speakers in the evening, do the lunch and learns and sit in on a BOF (Bird of a Feather) session. That's why I'd never to go to a SANS conference at Disney World or Virginia Beach. Too many temptations to waste your time doing other things, and the opportunity to learn practically all day long is too valuable. But's that's just the way I roll. =-)

Packet Analysis With xtractr - Continued

2011-02-04T15:26:00.002-05:00

Now that we have our packets indexed, we need to start the web service and load them. The default address to bind to is localhost, on port 8080. If you're working remotely on your xtractr box, and especially if you want others to be able to look at the packets with you, you'll want to change to bind to your networked interface (realize no one can connect to the box and look at the packets or run queries without a Mu Dynamics account).
So we now use the browse parameter, like thus: xtractr browse (index_directory) --host (network_ip_address).

So using our example above, and assuming our box has an IP address of 192.168.100.10, our browse command would be: xtractr browse index_dns --host 192.168.100.10
If we wanted to use a port other than 8080, we could add the --port parameter to bind to a port other than 8080.

Point your browser to ip_address_of_the_xtractr_box:8080 or, if you specified a different port, ip_address:(port_number). Your browser will be directed to the Mu Dynamics xtractr site, where you'll be prompted to login with that account you created at step 1. Now, as you query and drill down, your data will be streamed through the Mu site where all the processing will take place (again note that unless you choose to upload your pcaps, they will remain on your box.)

Mu has a large repository of user supplied pcaps available to the community, to test with and experiment. They encourage you to contribute to the library, and there are some very obscure and esoteric packet captures available to you there.

You can go to the xtractr web site's live demo, at http://www.pcapr.net/xtractr/demo#/flows, and see what all this packet parsing goodness looks like, and play before you download.

(Folks at Mu.. if you come across this post and I've screwed up anything, please Twitter me @JeffSoh and I'll correct it ASAP)

Packet Analysis With xtractr

2011-02-04T14:58:00.002-05:00

I've mentioned xtractr by Mu Dynamics before, and over the last week or so I've been using it more and more to look at EOI's. If you've not used it before, here's a little overview of this tool.

xtractr runs on Linux (the latest version is 4.5.40426) and can be downloaded here.
You will need an account (free) with Mu Dynamics to use the query services.
xtractr can be used in stand-alone mode, which means your pcaps, queries and labels never leave your machine. It can also be used Mu Studio to convert the data into a stateful test case.
More than one person can look at the data at a time, and if you need to look at more than one capture at the same time, you can run multiple instances of xtractr.
The free lite version can index a capture of either 10 million packets or 1 Gig of pcaps.

That said, here's what you'll need to do to use xtractr. After creating your account, and downloading the tarball and installing, you're ready to index your packets. You'll want full length packet captures here if you're going to do network forensics.

Create yourself a workspace directory of whatever name you want, and copy (or capture, if you're testing) your pcap there. I'd suggest giving it a meaningful name, so you know later what that pcap is without having to run it.

Make a sub-directory, again, whatever you wish to call it, to store your indices in.
Now you need to index the pcap. The syntax is: xtractr index (index_directory) --mode

(basic|forensics) (pcap-file).

So if we had a pcap called "dns-traffic.2.4.11.pcap" and a sub-directory called "index_dns", and we wanted full data (forensic), we would run: xtractr index index_dns --mode forensics dns-traffic.2.4.11.pcap . Depending on how big your pcap is, this might take a little while to run, xtractr will give you a progress meter while running and return to prompt when down. You can omit the mode parameter, by the way, and xtractr will default to basic.
(Continued - Blogger is not co-operating today)

Enterasys Dragon IDS

2011-01-28T13:58:00.000-05:00

I've managed a Dragon IDS system for ten years now. When the company I worked for tasked me with researching and evaluating intrusion detection, some of the major players today didn't even exist yet, and snort had not yet been rolled into the commercial Sourcefire product.We looked at a number of the available offerings back then and settled on Dragon.
At the time, Dragon was winning IDS "bake-offs" and garnering a number of awards, and it seemed to be a decent choice. We did all of our own testing; there were no monies for calling in a security consultant to evaluate our needs and pair us with a product.

Dragon was written by Ron Gula, who is now the CTO of Tenable Network Security. Ron had just sold Dragon to Enterasy, which made some of the early support calls interesting.
But some of Ron's staff had gone with him to Enterasys (like Rick Olesek) and were excellent folks to deal with and very knowledgeable. We started out with Dragon 5, which by today's standards, had a rather primitive management interface. Changes were made by editing the various configuration files directly, either through the browser or using vi on the server itself (I actually missed that, once the interface became sophisticated enough to not require it anymore. Gave you a degree of confidence the changes you were making were actually getting made).

Over the last ten years, I've maintained a love/hate relationship with the Dragon (the original version we used called the HIDS component a "Squire" and the tools were in the sorcery directory. The product was originally named "Dragon Fire IDS). It's fairly easy to maintain, signatures are released for new vulnerabilities in a timely manner, the reporting is easy to set up and filter, and the newest interface has a really nice looking console that is easy to drill down into.

I also remember, however, the early versions of version 7, when I spent days on end on the phone with their developers, with them remoted into my desktop as they tried to fix issue after issue. I remarked more than once that I didn't remember signing on to be a beta tester, but I evidently was one anyway. Fortunately, as of version 7.4.1, all of the bugs have seemingly scurried back into the darkness, and the systems are running without intervention again. Which allows the intrusion analyst to spend his time actually investigating alerts, as well as tuning and filtering. What a concept.

Enterasys was merged with the Siemens Group in 2008.

Practicing Packet Analysis

2011-01-14T16:17:00.000-05:00

Here's one way to get started quickly practicing packet analysis, using nothing but open source, free tools.

You'll need a Linux box with sufficient drive space to store your capture packets and a monitoring interface patched to the network you wish to capture from (use your own network, or make sure you have permission to monitor the network you'll be using).

Packet Capturing

You can several different tools to produce packet captures.

1. First is Daemonlogger, written by Marty Roesch of Snort fame. Daemonlogger can write packets to disk (what we want here) or act as a software tap, rewriting the packets it captures to a second interface.

2. If you have Wireshark installed, you can use the command line utility tshark to sniff. tshark, like Wireshark, is a network analyzer that can display tons of information on the packets it receives, not what you want here. The options are many, and if you're just starting out, tshark may not be the best choice. Make sure you use quiet mode so the capture isn't displayed to the screen (you'll drop packets as that slows things down considerably) and set the snaplength (the size of the capture) to 0 or 65535. If you're going to analyze packets, you need full packet captures unless you're just doing statistical analysis/trending. -x will capture the hex and ascii data.

3. If the box already has snort installed, you can simply run snort in packet logging mode. After all, that was the whole reason Marty wrote snort in the first place. He didn't like the sniffers that were available at the time, so he wrote his own. It developed into an IDS later.

4. IDABench. IDABench is a now defunct packet auditing tool written by George Bakos. Even though development ended on it several years ago, it's still a wonderful tool that I use daily. Apart from the Perl framework that runs various tools and creates web pages of summaries, the first thing IDABench does is simply run tcpdump and create packet captures, one for each hour of the day. For what we're doing here, its overkill just to get dumps, so unless you want to use the toolbox IDABench provides you, that leads us to number 5.

5. Just use tcpdump itself. There is a parameter (-C) you can pass that tells tcpdump to roll over according to the size of the capture. Whatever you pass to -w (write to file) will be used along with a number as the filename (if you use “-w capture”, you'll end up capture1, capture2, and so forth).

Analysis Tools

Obviously, there are many, many tools available to analyze packets. I'm just going to mention a few that I use or have used in the past here to allow you to drill down into the packets and inspect either the header fields or payload, or both. Once you have a (libpcap compatible) packet capture, you can use any or all of these tools to start digging.

1. Wireshark. Wireshark is the most complete network analysis tool that I know of, at least of the free tools, and has dissectors, or decoders, for literally thousands of protocols. Open your packet capture in Wireshark and you can drill down to any level in the protocol fields, examine the payload, follow a TCP stream, save off reassembled files that are contained in it (including VOIP traffic that can be saved as a .wav file and replayed). It’s an excellent tool. It may also be yet another case of overkill, though, depending on what you're looking for. If all you want to do is extract any login authentication pairs found in the packet stream, for example, it may not be the tool to use.

2. dsniff suite. dsniff, however, IS the tool to find clear text logins. There are also tools that will capture email traffic (mailsnarf), older versions of instant messaging (msgsnarf), extract URL's (urlsnarf), files (filesnarf), and even surf along with a user in the stream using webspy, which will redirect any URL's it finds to your web browser (more fun than functional).

3. ngrep is a command line program that will search for content in a packet stream or capture, much the way that grep does text files. It supports regex and is a powerful way to quickly find strings in packet captures.

4. Netwitness Investigator. Investigator is a Windows GUI that performs "free form contextual analysis" of your packets. Install the software, create a new collection, import your pcap file into it and load it. You'll be presented with a visual screen of things like alerts, hostnames, user accounts, ports, protocols, even countries of origin, that have categorized info below them you can drill down to find the exact information you need, and finally look at the raw packet capture of. A very nice tool to experiment with.
You can capture new traffic on the box it's installed on , as long as WinPcap is installed, which is very handy to get up and practicing quickly.

5. chaosreader - chaosreader is a big perl script that takes your packet capture and parses it down to TCP/UDP sessions and application data. It will pull telnet and ftp sessions, HTTP, email. etc. and index it all in html files that you can feed to your web server, or open directly into your browser. Be warned, though, that parsing of large files will take a long time and use up all of your available resources on your machine. It's better to use smaller packet captures, or use filters to pull traffic of interest out and write it to a separate dump file and then feed that to chaosreader.

6. snort. Snort can be run in stand-alone mode, which means you can feed it a packet capture as a parameter and run the traffic through all of snorts pre-processers and signature libraries. You might want to do this to get a second opinion on events captured by another IDS or to find alerts to drill down to practice your analytical skills. Or if you're doing network forensics for someone else, you may only have access to the raw packet capture and need to regenerate the alerts for your use.

7. xtractr - xtractr is a tool provided by MuDynamics that takes a packet capture, indexes it and writes it out to an html file. The free version has a limit of 10 million packets or 1Gb of pcaps. That’s plenty enough to practice your analytical skills.

Packet Capture Tools
1. Daemonlogger
2. Wireshark
3. Snort
4. IDABench Sorry, links are no longer active. I have the install files if interested.
5. tcpdump

Analysis Tools:

1. Wireshark
2. dsniff
3. ngrep
4. NetWitness Investigator
5. chaosreader
6. Snort
7. xtractr

SANS Google Cheat Sheet

2011-01-10T08:58:00.000-05:00

Yet another cheat sheet for those who want to power user Google.. but this one's from SANS and is from a defense of Goggle as a hacking tool perspective (to check your own site and see what data is bleeding out unintentionally). This sheet will also help those who just want to get tight and relevant results and aren't familiar with some of the operators Google offers. (Note: the phonebook, rphonebook and bphonebook operators have been retired.)

Polymorphic Malware from Noah Schiffman

2010-12-09T09:27:00.001-05:00

Good, condensed explanation of metamorphic/polymorphic malware...

The propagation of malicious code dates back to the early days of sneakernet-style transmission of boot-sector viruses via floppy disks. Once the spread of infectious code reached critical levels, the security community counteracted with programs designed to patch, protect, scan and block -- the birth of the antivirus suite. Since then virus writers and antivirus vendors have worked day and night to outdo each other, which in turn has caused malicious code to evolve at a remarkable rate, creating new injection vectors, evasion techniques and attack payloads.

One of the most innovative and insidious creations of malware propagators has undoubtedly been the advent of metamorphic malware. To understand the concept -- and its cousin, polymorphic malware -- requires a basic understanding of underlying malware encryption techniques. In the simplest of models, an encrypted virus consists of a virus decryption routine (VDR) and an encrypted virus body (EVB). Execution of an infected application enables the VDR to decrypt the EVB, which in turn causes the virus to perform its intended function. In the propagation phase, the virus is re-encrypted and appended onto another host application. A new key is randomly generated with each copy, thus altering the appearance of the code. However, the VDR remains constant and this is its inherent weakness, resulting in detection via signature recognition.

Polymorphism, which literally means "changing that of appearance," adds an additional component to the encrypted code -- a mutation engine (ME). The ME essentially can change the code of another program without changing its functionality. For example, an ME can alter the code of a VDR with each replication, while maintaining its ability to decrypt the EVB. The continuous alteration of the VDR is achieved using obfuscation techniques such as junk code insertion, instruction reordering and mathematical contrapositives. However, the preservation of the decrypted virus body is its Achilles' heel, as it provides a form of complex signature.

Consequently, advanced techniques such as generic decryption scanning, negative heuristic analysis and the use of emulation and virtualization technologies have proven to be successful polymorphic detection methods.

Evolving from the deficiencies of polymorphism, metamorphic malware brought virus mutation to the next level. Instead of mutating the EVB and reapplying a cryptographic cover, metamorphism employs the ME to transform the virus itself. Using a disassembly phase, the code is represented as a meta-language that characterizes its end function, disregarding how the code achieves this function. Thus, after analysis, code morphing and reassembling, the end result is new code that bears no resemblance to its original syntax, yet it's functionally the same.

Metamorphic malware's ability to completely re-alter its code -- and change its signature pattern -- with each cycle is evidence to its disturbingly significant power to evade AV techniques. One prototypical model can be observed with the Win32.Metaphor virus (aka Win32.Etap, Win32/Simile).

Acronymically named for metaphoric permutating high-obfuscating reassembler, this virus first surfaced in 2002, with numerous variants following. Despite its non-destructive payload (various messages were displayed depending on the date), its incorporation of several innovative and advanced metamorphic techniques provided successful propagation and antivirus evasion. The powerful combination of entry point obscuring (EPO), pseudo-code permutation, size shrinking and expansion (the "accordion model" technique), anti-emulation time stamp analysis, advanced infection routines and cross-platform compatibility with Linux, created a new class of malware -- a threat level surpassing non-metamorphic code. This changed the enterprise security model, requiring different strategic perspective for central, perimeter and endpoint security.

While no definitive all-encompassing detection methodologies exist for this continually evolving class of malware, identification is possible.

Metamorphism reveals its inherent weakness in its need for self-analysis.

As an entity, it can analyze its own code, thus theoretically it can be analyzed by other programs. Effective methods have been developed using emulation techniques to heuristically examine the post-morphed function of the code. Furthermore, research in methods such as automated replication systems, similarity indices, geometric analysis, and tracing emulators continue to grow. Despite the advancements in detection and prevention, virus writers are creating more sophisticated and efficient mutation engines and new obfuscation techniques. Until a method for definitive identification is developed, new forms of metamorphic code will continue to propagate and pose a challenge for the security community.

Protection from any type of metamorphic malware is best addressed by blended threat management platforms using a multi-layered approach.

Antivirus software, updated frequently, remote access restrictions and compliance monitoring should be employed at the server and end-user levels.

Network and personal firewalls should have any unused service ports shut down. Email servers should employ content filters and file scanning.

Finally, any corporate setting should develop, maintain and enforce a well-defined and effective set of security policies. In extreme situations, when dealing with highly sensitive data, extra security measures such as real-time emulation analysis and specialized network segmentation may be considered.

About the author:

Noah Schiffman is a reformed former black-hat hacker who has spent nearly a quarter century penetrating the defenses of Fortune 500 companies. Today he works as an independent IT security consultant specializing in risk assessment, pen testing, cryptography and digital forensics, predictive analysis models, security metrics and corporate security policy. He holds degrees in psychology and mechanical engineering, as well as a doctorate in medicine from the Medical University of South Carolina. Schiffman is based in Charleston, S.C.

A Quicker Way

2010-11-10T15:49:00.000-05:00

I posted a command I found a while back to strip off the port number from the IP address in tcpdump-style notation, as in 192.168.11.1.23. I was going through my notes and found a quicker way (I believe this was posted as a reply to a Handlers article on the Internet Storm Center.)

The first command was: sed 's/.[^.]*$//' and though it works, of course, it's not real easy to remember on the fly (though we love regex... how much easier our jobs are because of it).

The simpler way is to use the cut command, like this: cut -d. -f1,2,3,4

This simply displays the first four fields delimited by a period, so it drops the last one (the port number). As Lola of Nick Jr. and book fame says, "Easy peasy lemon squeezie!"

Security Onion Live CD

2010-10-29T11:08:00.000-04:00

Doug Burks has created an IDS Live DVD running Ubuntu. Pre-installed are the following packages:
Snort
Squil
Suricata
Xplico
nmap
scapy
hping
netcat
tcpreplay and others.
The .iso can also be installed on a USB flash drive, giving you an IDS-on-a-stick. Very handy.
I'm looking forward to trying it out on the security test box I have at home.

Doug's page is at http://securityonion.blogspot.com. There you'll find a download link, a presentation on Security Onion and a FAQ, as well as his posts on network security.

Firesheep

2010-10-27T16:01:00.002-04:00

Security experts recommendation for users to subscribe to a VPN service isn't practical...even if there weren't the possibility that someone might grab that cookie as it leaves the VPN server for the destination. I just can't see many ordinary users shelling out money for a VPN service, setting it up on their laptops and using it. whatever the final solution is, it's going to have to be an end service fix, and transparent or nearly so, to get most folks to adopt using it.
Firesheep's site here.

A Few Handy Built-Ins

2010-10-08T11:49:00.000-04:00

Anyone who's worked with Linux knows it's a great operating system (which ever of the many flavors you run). Not only is it stable and secure, but it makes great use of hardware with lower overhead, making it fast as well. Another really nice thing about an open source OS is the constant additions of utilities that make life easier for both the admin of the box and the user.
Here are a few of my favorites for those new to Linux...

watch: watch allows you to re-execute a program over and over and output to the screen. It's very handy to watch for changes to a directory, or to watch for a service to start or monitor connections. For example, let's say you run a service on port 8000. You want to watch for any connections to that port. You could do that by running "netstat -an | grep 8000", or better yet, "netstat -an | grep 8000 | grep EST". that would take the output of netstat, which shows network connectivity, statistics and such, pipe it through grep to filter out all lines except those that contain 8000, the port you wish to monitor, then filter out from those lines any except ones that have upper case EST in them. This would show ports in the ESTABLISHED state.
That's great, but what if you were watching for connections over an hours time span? watch works great for this. watch takes a -n parameter, which is the number of seconds between executions. The default is 2 seconds. If we wanted updates as quickly as possible, we would run:
watch -n 1 'netstat -an | grep 8000 | grep EST'. Every second, watch would rerun the netstat command and show you the results, clearing the screen between each iteration.

lokkit: lokkit is a command line (used to be ncurses GUI based) utility to modify the iptables firewall. It's very simple to quickly open up a port with lokkit (I'd recommend making a copy of iptables, found in /etc/sysconfig, first). If you want to open port 21 to all inbound traffic, you'd run "lokkit -p 21:tcp". Viewing your firewall tables by running "iptables -L' should show:
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp
You can also disable and enable the firewall, open ports by service name, add trusted interfaces, add custom rules and add and remove modules.
Just make sure you back up before making changes, and be careful modifying iptables remotely, whether using lokkit or manually, as you could lock yourself out when you restart (if you screw up).

ntsysv: ntsysv is a ncurses GUI that allows you to enable or disable services at start up, the equivalent of using the chkconfig command. chkconfig is more granular, as you can specify the startlevel you wish, but if you're unfamiliar with Linux, it's helpful till you get up to speed. Just invoke the command, no parameters, and you'll be presented with a list of all the available services. Each has a box beside it that can be checked to enable it. Use the arrow keys to scroll down and back up and hit the space bar to toggle on or off.
Yes, there X apps that do the same thing with a nice GUI, but if you're working on NetSec boxes, you won't have X installed a lot of times (or shouldn't). Do you really want a GUI, with all the myriad of apps that installs that could have security flaws installed on your IDS or packet auditor?

Stripping The Port Off Tcpdump Output

2010-09-28T15:11:00.001-04:00

You can use the sed command in Linux to strip off the port from tcpdump output, after using awk to pull out the IP addresses. tcpdump adds a decimal point and the port number to both the source and destination, such as 192.168.11.1.23, which would designate port 23 on 192.168.11.1. If you wanted to capture all the source addresses on your network, you could do so with something like: tcpdump -nn -i eth0 -q | awk '{print $3}'. We're piping the output of tcpdump to the awk command instead of the screen and telling awk to print the third column. Our output, without awk, would look something like this:
11:59:15.871010 IP 64.30.1.50.62792 > 71.40.100.181.443: tcp 31
awk prints only the third column, separated by spaces.
64.30.1.50.62792
To strip the last octet off, which is the port number, we could pipe the results of awk through sed, using the search and replace function, like this: sed 's/.[^.]*$//'

What we would then have would be just a column of source IP addresses. Pipe it into a text file using the redirection operator, > file1.
Now we can run that file through the sort command, to sort them numerically, and then through the uniq command, to remove duplicates, and pipe that into another filename:
sort file1 | uniq > file2.

So command 1 would be:
tcpdump -nn -i eth0 -q | awk '{print $3}' | sed 's/.[^.]*$//' > file1 (change the -i parameter to whatever interface you will be monitoring)

And command2 would simply be:

sort file1 | uniq > file2

And file 2 can then be search, or run through a script to resolve hostnames, imported into a spreadsheet for reporting or whatever is needed.

IDABench

2010-09-23T21:41:00.000-04:00

One of my very favorite tools is IDABench. IDABench is a packet auditing tool using perl and tcpdump (and other libpcap based tools), based on Shadow. If you're familiar with Shadow, you know it's basic function is to capture packets into hourly dump files and give you a Web based interface to search those packets, as well as giving you a daily summary of source and destination addresses and ports. George Bakos, when he was at ISTS, the Institute for Security Technology Studies at Dartmouth, took Shadow and revamped it with Perl scripts to allow you to use ngrep, tethereal (now Wireshark's tshark) and p0f. What's even better is that IDABench is modular and can be modified to use just about any tool that can read pcap files. It runs on Linux and Apache and is a great tool for the intrusion analyst or team that looks at packets frequently. It hasn't been maintained for a number of years and as I searched for a download link, I found they all point back to ISTS and the page doesn't exist. That's a real shame, it's a very useful tool. If you're interested in trying it, let me know and I'll get the files to you...

Another Great Tool

2010-09-10T12:21:00.001-04:00

There are a number of good packet crafting tools available for Linux distributions, including scapy, nemesis and my favorite, hping.
hping was written by Salvatore Sanfilippo and is now in it's third major version (last updated in 2005).
It is a packet crafter, which means it allows you to construct and send packets independent of your TCP/IP stack built into your OS, using raw sockets. You can create TCP (the default), ICMP, UDP or raw IP packets (no higher level embedded protocol)
hping is a command line tool run inside a tcl interpreter, so you can make use of all of tcl's abilities to script your commands.
You can download the tool here.

A basic example of crafting your own packets:

Let's use hping to send an ICMP Address Mask Request. We need to to know the ICMP type and code for this, which is type 18, no code. We would construct our command as follows:

hping -1 -C 18 10.10.10.1

Here we're telling hping to send an ICMP packet (-1) of Type 18 (-C) to address 10.10.1.1.

Hping will display a line like this showing what operation it's doing:
HPING 10.10.1.1 (eth0 10.10.1.1): icmp mode set, 28 headers + 0 data bytes

Any replay from the host will be printed to the screen. In this case, the destination address dropped our packets. When we kill the command (Control-C), we'll see the stats:

--- 10.10.1.1 hping statistic ---
15 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

There's a built-in macro for this command, which is icmp--addr, so we could have just run hping icmp-addrr 10.10.1.1.

Lets use hping to send a ping packet so we can see the results:

hping -1 -C 8 10.10.1.1

HPING 10.10.1.1 (eth0 10.10.1.1): icmp mode set, 28 headers + 0 data bytes
len=46 ip=10.10.1.1 ttl=255 id=30150 icmp_seq=0 rtt=0.4 ms
len=46 ip=10.10.1.1 ttl=255 id=15674 icmp_seq=1 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=46964 icmp_seq=2 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=23097 icmp_seq=3 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=8324 icmp_seq=4 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=7159 icmp_seq=5 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=19765 icmp_seq=6 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=54740 icmp_seq=7 rtt=0.2 ms
len=46 ip=10.10.1.1 ttl=255 id=30929 icmp_seq=8 rtt=0.2 ms
^C
--- 10.10.1.1 hping statistic ---
9 packets tramitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.4 ms

Just like using the ping command, we see our response showing the ttl, sequence number and round trip time.

Now lets use hping to send some data in a TCP packet. Suppose we just wrote a very simple IDS signature that looked for the string "evil_string_123" and wanted test and make sure it worked.
First, we'd create a text file with the string in it. Lets say we called it packet_data.

Now we could use hping to fire that packets wit that string to a host that sits behind our IDS, then watch for our signature to fire.

hping -p -S -d 14 -E packet_data 10.10.1.2

Here we're using a TCP packet (the default, so we don't need to specify) with the Syn flag set (-S), a data size of 20 in a file called packet_data, going to host 10.10.1.2.

Running a sniff on the box we're using, we should see our string in the packet data, like this:

12:09:17.837181 IP 10.10.1.15.2572 > 10.10.80.203.22: Flags [S], seq 168566124:168566144, win 512, length 20
        0x0000: 4500 003c 412a 0000 4006 d37c 0a0a 010f E..
        0x0010: 0a0a 0102 0a0c 0016 0a0c 1d6c 5796 3dbf ..P........lW.=.
        0x0020: 5002 0200 a8f6 0000 6576 696c 5f73 7472 P.......evil_str
        0x0030: 696e 675f 3132 330a 0000 0000            ing_123.....

Salvatore goes in depth in using the tool, especially in the tcl shell for scripting here.

Sanity Checking Your IDS Config

2010-08-24T13:36:00.000-04:00

Tuning an IDS is never an once and done proposition. As a matter of fact, an IDS/IPS probably needs more constant maintenance and tuning than just about any other system you'll ever administer. After doing your initial setup and tuning, you';ll notice over time the false positive rate creeping up and the white noise getting louder.
A few things you might want to look at, on a regular basis, to keep the FP rate down and keep your focused EOI's that matter (events of interest) are:

Protected Networks: Have new segments been added recently? If you don't add them to your list of protected networks, all those signatures with a flow of external to internal traffic can false posit on internal traffic. Review your monitored segments periodically, and look at your events for new internal subnets that may need defined.
New signatures. Hopefully, your review your vendors new signatures before deploying (even if you use automation) to see if they're relevant for your infrastructure.Consider omitting signatures that aren't needed for your environment, or at least not adding them to real-time alerting or decreasing the alert level. If you're network is a strict Windows shop, running IIS Web servers, do you REALLY need 500 Apache/PHP signatures? Maybe your philosophy is you want to see ANY malicious traffic directed towards your networks, but you probably don't need real-time alerting on them in any case. How many analysts still get real-time alerting on Code Red?
New servers: As new servers get added, you may see a marked increase in FP alerts. Patching software, anti-virus management servers, web content monitoring and the like do a LOT of talking on the network that could be construed as attacks by the IDS. Make sure you track down your top talkers regularly and adjust your filters as needed.

Network Security Dashboards

2010-08-10T15:11:00.000-04:00

If you're a graphical person, and like the dashboard approach to an overview of what's going on in NetSec, there are a couple I've found that are pretty nice. The first one is the Talisker Computer Defence Operation Picture site, found at http://www.securitywizardy.com/radar.htm. Andy's had this up quite a while, and there's even a shot of it on the wall at a site owned by the NSA! (http://www.networkintrusion.co.uk/)

I just found the second one, Infocon, which is located at https://i.sectoid.com. I saw a post by the author, Valter Santos, on a listserv, and I guess he's working on a new version of the site. Pretty sweet even in it's present incarnation.

If nothing else, throw one of these up on one of your screens at work. Even if you rarely look at it, it's sure to impress folks when they come into your office or cube!

Favorite Tools

2010-08-10T14:59:00.000-04:00

New tools come out with amazing regularity. If you're getting started in NetSec, one of the first things you'll find out is there are tons of tools, and multiple ones to do any task, AND that you better learn enough Linux to install, configure and run them, as most of them don't have ports to Windows. With a few exceptions, even the ones that ARE available for Windows rarely run as well.
I have a toolkit (actually two, as I keep Windows and Linux tools separate) that has dozens and dozens of tools in it. Many I've tried out for a day or two, some I use on a semi-regular basis, and some I've never even found the time to install yet. But every network security analyst has, or should have, their core essentials.
If they run a distro on a thumb drive for emergency use, these would undoubtedly be on it. They are probably installed on every test box and personal box they have access to.
Mine as as follows (in no particular ranking or order...)

nmap - You have to have a port scanner, and year in and year out, Fyodor keeps making nmap better to the point that I've never changed. I've tried a bunch of others, but nmap continues to be the most stable and dependable scanner I've ever tried. (Unicornscan WAS fun, I'll admit... smokin'!)
hping - You also need a packet crafting tool.. in this area, I think there are several really good ones, including scapy and Nemesis, but I like hping the best for it's simplicity and functionality.
netcat - netcat does just about anything you need it to do as far as sending and receiving packets. It's called the "swiss army knife" of network tools for good reason. Need encryption? Get crypcat instead of or in addition to.
ngrep - Ngrep is a libpcap tool that searches for strings in packets. If you're doing traffic analysis, it's almost indispensable.
dsniff - This suite of tools by Dug Song includes dsniff that searches traffic for logon credentials, as well as tools to sniff for web pages, files, mail and chat. There are also tools to do man in the middle attacks on SSH and HTTPS, as well as a nifty sniping tool to shoot down traffic.

I use many others, but those are the core 5 for my toolkit...

Why I Still Like Fedora

2010-08-02T10:42:00.000-04:00

I see/hear the occasional trashing of RedHat/Fedora on the lists and from instructors (one really well respected and favorite instructor of mine said "Friends don't let friends run RedHat" =-) ) and I understand it, in part. The RedHat package for certain tools that NetSec folks use aren't up to snuff with with other distros or an install from source. Old tools like Shadow and IDABench took pains to mention if you're running RedHat, ditch the installed version and get source. But the issues I've found or heard about aren't game changers. I install most of my tools from source anyway. I rarely depend on a package. And RedHat's habit of renumbering interfaces between reboots...well, you ought to have the MAC hardwired in your network scripts anyway. The thing I love about RedHat is that it works. Plain and simple. I've used it for 10 years now (starting with RedHat 6.2) and never had a situation where it wouldn't install (unlike the Debian 5 install I just tried to do, where it couldn't find the factory installed (common) disk drive in an IBM 8171 Think Centre). It's been stable and easy to maintain version after version. I like things that work they way they're supposed. I've tested many other flavors for desktop/laptops, and always keep coming back to Fedora. I'd like to give Debian another shot. If it could find my hard drive...

Too Configurable...

2010-07-21T09:33:00.001-04:00

I was working with a semi-popular IDS system, and discovered that TCP checksum checking is turned off by default. That's bad enough, as an IDS that doesn't check (and drop) packets with a bad TCP checksum is vulnerable an IDS insertion attack (the scenario where the IDS sees a packet that the host will discard). It gets better... it's configurable from anywhere from 0 (check all packets) to 255 (check every 255th packet). What good is TCP checksumming if you're not going to do it on every packet, especially if you're going to skip every 10 or 50 or 255? packets? It only takes one packet with a bad TCP checksum to do an insertion attack, so to me the pretty common sense default here would be ON, and not allow the admin to tinker with what packets are checked. Yes, I realize the issue of overhead, but if you're going to check them, the only assurance you have against that particular attack is to check them all. Or you could turn it off altogether and enjoy your blissful ignorance

Winpcap 4.1.2

2010-07-05T18:46:00.001-04:00

New Winpcap is out, get it at http://www.winpcap.org/install/default.htm. Thanks, ISC.

OSSIM

2010-06-19T22:28:00.003-04:00

OSSIM is an open source security information management and correlation tool from a company called AlienVault (there's a pro version too). I installed on it on two boxes recently, one using the unattended install the other using the custom install. It's an incredibly easy app to install. You download an ISO from their web site and make an install CD, boot it up and give it some info (the unattended asks only for a few basic items like the network config info, a name for a box and a few details on how you want the app configured). The default unattended install sets up the server, sensor, and database all on one box. Once the app is installed and rebooted, you'll need to set up your monitoring interfaces (the custom install asks which ones to use) and you're off and running. If you want to use Nagios, you will need to configure that as well. You'll have over 30 apps all properly installed, with a nice dashboard to show your status at a glance, and then you can drill down to investigate events, check your network status, see what hosts are detected from the traffic and more. The box does passive vulnerability assessment using Nessus, runs Snort, arpwatch, P0F, Ntop, Osiris and many others.
I see this as being a great teaching tool for new analysts, as it will allow them to work with a lot of tools quickly without the learning curve of getting them all installed and configured properly and working together. The site for the open source version is here.

Tune It Like a Fiddle

2010-06-17T15:09:00.003-04:00

Whens the last time you did a comprehensive review of your IDS for further filtering? If you haven't done it in a while, you might be shocked at the false positive creep. New partner circuits get added, new app servers, maybe your company is using a a totally new app? Which brings up another point. Not only do you need to review what needs filtered, you may need to review what needs UNFILTERED as well. If your company wasn't using Citrix, for example, the last time you did a review, you may have all those signatures disabled to optimize the performance of your sensors and reduce overhead. If you work for a smaller company, and those decisions are left to your discretion, as opposed to a group that regularly reviews policy, you'll need to keep awareness of what platforms and apps your company uses on a regular basis. Doing regular ports scans should alert you to new services opened up, and using the OS scan switch can help determine if if there are new platforms you need signatures for.
And don't just do this for your external addresses. As they say, most networks are a Tootsie-Pop. Hard on the outside with a soft chewy center. If an attacker pops a perimeter box, he now has a pivot point to attack further in, depending on how in-depth your defenses and detectors are layered. That's why it's important not to put all your eggs in one basket with just perimeter sensors.
You need sensors in front of your most vital assets, like database servers, HR and payroll boxes and anything with confidential info stored on it. That way, if the attacker eludes your perimeter defenses, you have another opportunity to detect (and stop) her. HIDS, and log files are your last line of defense. All that good log data is worth anything unless you have a process in place to parse, and alert on it.
Review those signatures.. not only can you cut down a lot of white noise, you might find out you didn't know what you were missing.

Honeynet Challenges

2010-06-12T01:36:00.004-04:00

New Honeynet Challenges available at http://www.honeynet.org/challenges. The June challenge is VOIP based, so if voice is your cup of tea (or honey), slide over and take a whack at it. These really are great for self-training to sharpen your skills and find out what you know (and more importantly, don't...)

Google SSL

2010-05-25T11:11:00.002-04:00

Google is in beta with an SSL version of search. Another way of ensuring some privacy online in an age where privacy is becoming scarcer and scarcer (Facebook, anyone?). If I were a blogger or a journalist in a nation where the free dissemination of information is illegal (say, China, North Korea, Iran, etc.), I'd use the SSL version tunneled through Tor. No such thing as bullet proof privacy but every little bit helps..

ECN

2010-05-11T13:49:00.002-04:00

I was amazed at how little ECN traffic I see on a network I'm responsible for. One packet in a fifteen minute period?
Wondering if that's the normal experience for others.. is ECN really that under-utilized?
Anyone else look at this? Oooh... there went another. TWO now. Both SMTP based, which makes sense.. busy mail server, timely delivery and all that..

Snort 2.8.6 Released!

2010-04-26T15:14:00.001-04:00

Go here for the Storm Center article from Joel Esler (an ISC handler who also works for Sourcefire. Lot's of new additions..

Skipfish

2010-03-24T10:46:00.005-04:00

This seems to be my month to try out new tools (Jim Clausing would be happy with me), and I'm running another new one as I speak. This one is a web vulnerability scanner called skipfish. It runs on Linux, FreeBSD, MacOSX or Windows, so I'm, of course, running it on one of my *nix test boxes (I don't do security tools on Windows if I can help it). Downloaded the tarball, extracted it, and compiled after installing the one dependency the README said I'd probably need, GNU libidn (funny thing, how reading that documentation always seems to make these installs go smoother!)
I'm running it against a NetSec box, so I created an empty dictionary and used -L to disable brute forcing of extensions it found, which if I read the docs right, means I'll just get a nice crawl the first time through. Anyway, it's been mentioned on the SANS lists and even posted on the Storm Center diary. That in of itself is enough of a recommendation that I'd give it a test run, if you need a web test tool (maybe a pen tester or you're responsible for hardening/protecting web servers).
Get it here if you're interested...

Cyber Security Act Part 4

2010-03-19T09:31:00.004-04:00

The Cybersecurity Act has been reworked again, removing the so-called "kill switch" for the president, which would have allowed him to shut down key infrastructure segments under attack. Instead the new version requires the White House to work with the private sector to determine critical networks and how they should be protected. Details on the Post found here.

BotHunter

2010-03-12T15:23:00.003-05:00

I recently took BotHunter, found here, for a test drive. I fortunately already had a test box with an interface monitoring a segment I could use, so it was simply a matter of download, install, done.
Set up couldn't be any easier. The java-based installer does all the heavy lifting for you, compiling the binaries for BH, installing a customized version of snort, and using rpm to download any dependencies needed. It then prompts you for ranges of your internal networks, any DNS servers, mail servers and the like to add context to it's results.
It has a GUI console if you prefer, but you can also administer and monitor it via command line. It uses a weighting system, which is covered in-depth in the docs, to produce a score depending on events it's observed from the host. The higher the score, the more likely the box has been popped and is part of a bot net. Anything over .8, it flags for your attention.
It's free, of course, from SRI International, though it's not open source and they retain all rights over the software. You can choose to upload your results to their repository, adding the the overall knowledge of botnets and help fight the good fight, or you can choose to keep your results local if there would be issues with that. The install even helpfully offers to install Tor, if you would like to upload your results anonymously.
I wouldn't recommend doing this in a corporate environment, for obvious reasons, but for other places like a home network, research lab or NetSec vendor, adding to the overall info helps the community as a whole. Which is why, by the way, you should participate in DShield if you're not already. (https://isc.sans.org/howto.html)

Mum's The Word

2010-03-12T15:15:00.004-05:00

The firing of the State of Pennysylvania's CISO, for discussing a system breach in the states online driver exam scheduling system is a sober reminder to never, ever discuss security incidents unless you're been expressly given the OK. In writing. By someone who has the authority to authorize that. Incidents are usually the realm of the companies public relations department and decisions are made at the C-Suite level. Ouch. That little indiscretion cost him what was probably a decent gig. Details here.

A Moments Reflection

2010-03-09T22:51:00.004-05:00

I'm coming up on my 10th anniversary in Network Security, my 15th in Information Technology.
I moved, abruptly, from being the head of a desktop support team to NetSec, in a day. Probably not the usual path one takes to security. I think these days most start out in that area from college, or move over from Infrastructure or the Server Team.
There were no information security people on staff when I moved over. None, in any area. No one had any idea what I should do or even where to find out. So I became a generalist in every area, as well as having to build up each new area from the ground up, with no experience, no help and no training. I didn't get to my first training conference (SANS) until 2002, two years into my new duties.
I got IDS off the ground, then moved on to vulnerability testing, anti-virus, content monitoring, and centralized logging. I wrote policy, procedures on hardening servers and applications, did threat research, incident response and even a little end user awareness writing. Probably others I can't recall.
For all the negatives there are in never getting to specialize in one area (and consequently becoming a SME, at least to your company), I think all the exposure to different tools and technologies helped some too. Even though sometimes the "jack of all trades" gig gets old, it's instilled a confidence in me I'll never lose. I can dive head long into a new project, even if I know nothing about it at the outset, believing I can get myself up to speed eventually and accomplish what needs done. I've done just that many times out of necessity.
That role, for me, is quickly coming to an end. I'll soon be transitioned out of my generalist duties and into a more siloed position. My old company was bought by a new, much larger company and our migration to the new networks and ways of doing things are in full swing.
That said, if you're just getting started or will be soon, the way I see the industry going, my opinion would be to specialize. I don't see in the future how very many companies, except the very small ones will be able to get by with a generalist like I was. Find out what what really interests you, and hit it hard until you've mastered it. You'll make yourself very valuable to a team some where, and you'll go to work each day and do what you love and love what you do.
Diversification is great for stock portfolios, in my opinion. For network security people, not so much.

Packet Fun

2010-02-25T13:00:00.003-05:00

Last week I started playing with NetWitness Investigator, a threat analysis app that makes it very easy to sort and drill down into packets when doing analysis. There's a freeware version (limited to 1 Gb pcaps in the demo and to local collections only). You can download it here. NetWitness runs on Windows or Linux, but the Linux version is in the commercial version only.

So today I took a look at Mu Dynamics xtractor, a cloud app with similar capabilities. Their demo movie takes to task a forensics challenge asking you to answer 8 questions about Ann's online activities. It's quite nifty. The movie is here, as well as a download link. xtractor runs on Linux distros and starts a Web server. Just point your browser at it. They do say Chrome or FireFox work well; IE not so much...

Aurora Disinfect Tool

2010-02-11T14:44:00.003-05:00

HB Gary, one of the companies working on the forensics of the Aurora attacks against Google, Adobe and others, has released what they call an "inoculation shot" for Aurora. It's a free scan and remove tool for the malware. The tool can be found on their site here. There's a good write up on the investigation to date on Dark Reading, found here.

Packet Captures

2010-02-08T11:39:00.003-05:00

If you're looking for packet captures to sharpen your analytical skills, the folks behind Wireshark have a nice site, found at http://wiki.wireshark.org/SampleCaptures

You'll find captures with all sorts of protocols (over 60) from the mundane to the esoteric (how about a capture of a line of text using STANAG 5066 (S5066))?

There are lots of sites with packet captures of malicious traffic or war games traffic, but it's also always helpful to keep increasing your knowledge of normal traffic too. As the instructors say, if you don't know what normal looks like, how will you recognize the anomaly?

Oh and if you need some sites with challenge or war games type captures, here's a couple I've come across..

http://www.itoc.usma.edu/research/dataset/
http://www.honeynet.org/challenges
http://ismellpackets.com/2009/05/06/packet-challenge/

Trojaned Mozilla Plugins

2010-02-08T07:56:00.003-05:00

If you use either Sothink Web Video Downloader 4.0 or Master Filer add-ons in Firefox for Windows, both have been found to contain Trojans. Details at the Download Blog post found here.
This raises the topic again of how you verify safety of all the gadgets and gizmo's you install? This is especially an issue with automated updates and installs via the Web browser, like these Firefox add-ons.
The vast majority of end users trust almost everything they come across and click without giving it a thought, despite all the efforts at end-user education, so how do we protect folks against themselves on the Internet.
Even if you manually download every app, checksum it, and run multiple scanners against it, we know it's still possible to get burned, so how do find a way to protect folks who are willing to click on any link they come across? Or teach them that just because the site is "good" isn't a guarantee some Bad Guys haven't compromised the site and injected malicious code via a script, or a Flash ad, or replaced a good version of a file with a piece of malware?

UDP scanning with NMAP

2010-02-01T08:35:00.003-05:00

Fyodor has made a major improvement to UDP scanning in the latest release of nmap. Rather than regurgitate the entire write up by Rob Vanderbrink on the Internet Storm Center, found here, let me summarize by saying Fyodor has changed nmap's operation for certain UDP services. nmap will now actually connect to that service and therefore verify the port is open, and that the service is actually running. If you don't know why this was an issue in the past (and still is for any services not included in the new nmap), read Rob's diary entry. He does a great job of simplifying the explanation.
As always. the latest version of nmap can be found at Fyodor's site found here.

Security Blogs

2010-01-13T08:44:00.003-05:00

A few security blogs from well known players in NetSec...

Marty Roesch, author of Snort and CTO 0f Sourcefire, here

Joel Esler of Sourcefire and ISC handler, here

Richard Bejtlich, author, Director of Incident Response for GE and former head of TaoSecurity, here

Tenable Security, here

Dr. Anton Chuvakin, author, security researcher and consultant, here

RaDaJo blog, Raul Siles, David Perez and Jorge Ortiz, here

Joanna Rutkowska, security researcher, here

This is obviously just a small sampling, but the point is, there is an absolute glut of information out there provided by very smart and experienced people. Every time you read one of these blogs or some security website, listen to a podcast, participate in a webcast or do some free online training, you're adding to your cumulative knowledge, increasing your value and making yourself a sharper analyst..

2009 Data Breaches

2010-01-12T12:46:00.003-05:00

The Identity Theft Resource Center released their yearly report on data breaches, found here.
Malicious attacks surpassed human error for the first time in three years. One shocking stat is that of the 498 breaches reported, only six (yes six!) had any kind of encryption or strong security features guarding the data. Companies still continue to fall down on basic steps to safeguard their customers or clients data, and it doesn't look like it's getting any better...

SANS AppSec 2010 - San Francisco

2010-01-11T09:25:00.004-05:00

Send your developers to learn secure coding. The number one way to guard against vulnerabilities is to eliminate them to begin with!

Identifying TCP Retries

2010-01-11T08:55:00.002-05:00

When looking at packet dumps, distinguishing TCP retry packets from network scanning is straightforward. Look for these characteristics:

Source ports will remain the same across all packets, as this is the same connection attempt.
The TCP Sequence numbers will also remain the same, for the same reason.
IP ID numbers will increment, because the sending host is creating a new packet each time.
Time stamps will increment equally. This is due to the TCP back-off algorithm that waits an increasing amount of time before resending the next retransmission attempt. Usually the time before attempts will double; for example 3, then 6 then 12 seconds between attempts.

Linux SysAdmin Newsletter

2010-01-06T07:48:00.002-05:00

nixCraft has a nice newsletter for Linux users with answers to common (and not so common) questions posted by users of the site. You can go to their site to sign up. Today's email included questions like how to set port forwarding in Mac OS X, how to turn on SELinux protection in RedHat/CentOS and for the newer users, how to determine which services are enabled at boot time...

Netwars

2009-12-17T07:15:00.003-05:00

Round 5 of Netwars has begun. What is Netwars? It's a network security game sponsored by SANS designed to help you learn how to handle real-world scenarios, sharpen your skills, and learn new techniques for penetrating (and therefore learning to defend) your network.
Full information is available at the SANS Netwars site found here.

DNSCAP

2009-12-11T22:20:00.003-05:00

I was doing some analysis of dns traffic, and using BPF's to pull certain fields out of the header today, when I did a search for a better header diagram than the one I had. I stumbled upon a program called dnscap. Don't know how I missed this great little tool, but it's part of my toolkit now.

dnscap is a sniffer, like tcpdump, but specifically written to parse dns. It's available from the Domain Name Systems Operations Analysis and Research Center (known as DNS-OARC), found here. If you do analysis on dns traffic on a regular basis, or even if you only have an occasional need to, I recommend you grab a copy and put it on your analysis boxes. If you're running Fedora, it's available via yum, and may be in the repositories for other flavors as well...

Here's part of the man page..

NAME

dnscap - DNS network traffic capture utility

SYNOPSIS

dnscap [-ad1g?6vs] [-i if ...] [-o file] [-l vlan ...] [-p port]

[-x pat ...] [-m [quir]] [-h [ir]] [-e [ny]] [-q host ...]

[-r host ...] [-b base [-k cmd]] [-t lim] [-c lim]

DESCRIPTION

dnscap is a network capture utility designed specifically for DNS traf-

fic. It normally produces binary data in pcap(3) format, either on stan-

dard output or in successive dump files (based on the -b command line

option.) This utility is similar to tcpdump(1), but has finer grained

packet recognition tailored to DNS transactions and protocol options.

dnscap is expected to be used for gathering continuous research or audit

traces.

Network Miner 0.91

2009-11-25T15:12:00.002-05:00

Jim Clausing posted an article on the Storm Center diary today about some updates to network security tools (Jim is always all over that.. he's sort of the Tim "The Tool Man" Taylor of the NetSec world) and mentioned there was an update to Network Miner. I'd never looked at it before, that I remember, so I downloaded the latest version. What a neat tool. It runs on Windows, and uses Winpcap (it doesn't install Winpcap but if you do NetSec you'd probably already have it installed.) Just unzip the archive and fire it up. Tell it what interface to monitor, and it begins to track host connections to your box, showing the IP, fingerprint of the OS, frames received, files transferred, images, messages, credentials, sessions, DNS requests, any clear text and even what it deems anomalies. Very nice. I'll definitely keep this one in my toolkit for Windows hosts. You can get the latest version at SourceForge and if you don't have Winpcap, get that here.

NSA helped with Windows 7 development

2009-11-20T09:22:00.002-05:00

According to Richard Schaeffer, information assurance director for the NSA, the agency worked with Microsoft and the DoD to enhance security in Windows 7. The agency was also involved in Windows Vista, XP and Windows 2000.
Full article from Computerworld here.

Summary of Cyber Security Awareness Month Articles

2009-11-02T11:31:00.002-05:00

Each day last month, which was Cyber Security Awareness Month, the handlers at the Internet Storm Center wrote a diary article drilling down on a particular port or set of ports and the app that uses them. Now that it's done, what we've ended up with is a nice 31 chapter primer on common ports. So the Director, Marcus Sachs, made a summary page to that end. Link is here. Enjoy.

Windows 7

2009-10-27T09:34:00.003-04:00

I hate to admit this. I really do. I'm running Windows 7, and liking it. On two boxes, even.
My impressions so far are that it's:
1) Fast. Fast for Windows, at least. My 7 boxes boot up much faster than Vista ever did, and even faster than XP. I've made no changes so far as to reducing the "eye candy" settings, and everything I run on it loads quickly.
2) Friendlier. Much friendlier than Vista. No longer am I inundated with security pop-ups for every task I try to do. File sharing and copying and moving files and directories aren't the nightmare they were under Vista.
3) Backwards Compatible. Every program I ran under Vista and XP has worked so far under 7. Out of the box, with no downloads or wizards suggesting a work around (with the exception of my printer, and the Vista driver works just fine).
4) Easy to install. Easiest ever. and a nice little bonus.. Windows 7 install (at least if you had a previous Vista installation) saves a copy of user data from your profile and other programs under a directory called Windows.old. And any directories created under system root are saved and written back out. Some folks will gripe about this. But consider the number of users who might have saved all their pictures in a directory called Pics off the root. And forgot to back them up in their haste to try out 7. This feature just saved all those photos of the trip to the Ozarks last summer. I like it. I can always go back and whack them later (I do Carbonite PLUS regular backups to a USB hard drive, but I like the protection anyway).
So, I might change my mind in a month, but so far it looks like a win for Microsoft to me. I've been frustrated with the bloatware from Redmond just like everyone else, from Windows 3.1 WFW to Vista, and let anyone in earshot know it. And as a network security guy, I'll still use Linux each day as much or more than Windows. But fair is fair. If you're going to bash 'em when they screw up, let's also commend them when they get it right.
I just hope I'm not retracting this whole post in a month or two. Finger crossed.

China Cranks Up Cyber Spying Against US

2009-10-26T10:22:00.002-04:00

From the Wall Street Journal:

October 23, Wall Street Journal – (International) China expands cyberspying in U.S., report says. The Chinese government is ratcheting up its cyberspying operations against the U.S., a congressional advisory panel found, citing an example of a carefully orchestrated campaign against one U.S. company that appears to have been sponsored by Beijing.
The unnamed company was just one of several successfully penetrated by a campaign of cyberespionage, according to the U.S.-China Economic and Security Review Commission report to be released Thursday. Chinese espionage operations are “straining the U.S. capacity to respond,” the report concludes. The bipartisan commission, formed by Congress in 2000 to investigate the security implications of growing trade with China, is made up largely of former U.S. government officials in the national security field.
The commission contracted analysts at defense giant Northrop Grumman Corp. to write the report. The analysts would not name the company described in the case study, describing it only as “a firm involved in high-technology development.” The report did not provide a damage assessment and did not say specifically who was behind the attack against the U.S. company. But it said the company’s internal analysis indicated the attack originated in or came through China. The report concluded the attack was likely supported, if not orchestrated, by the Chinese government, because of the “professional quality” of the operation and the technical nature of the stolen information, which is not easily sold by rival companies or criminal groups. The operation also targeted specific data and processed “extremely large volumes” of stolen information, the report said. Attacks like that cited in the report hew closely to a blueprint frequently used by Chinese cyberspies, who in total steal $40 billion to $50 billion in intellectual property from U.S. organizations each year, according to U.S. intelligence agency estimates provided by a person familiar with them.
In the highly organized cyberspy scheme that drained valuable research and development information from a U.S. company, the report said, the hackers “operated at times using a communication channel between a host with an [Internet] address located in the People’s Republic of China and a server on the company’s internal network.” Source: http://online.wsj.com/article/SB125616872684400273.html 10.

One Packet Fingerprint

2009-10-22T20:06:00.002-04:00

Interesting concept from Packet Maestro Mike Poor (I'm doing a refresh on the audio from SANS Sec 503 Intrusion Detection In-Depth). Mike notes how an ICMP request packet could differentiate between a Unix/Linux box and Windows box, with one packet. Here's how. ICMP packets use a type and code. For some , like type 3, which is a Destination Unreachable error message, the code is relevant and tells you why it was unreachable (port unreachable, host unreachable, etc.) With echo request and reply packets, the code is irrelevant, and is set to 0. A Windows box will reply to a request by changing the type from 8, request, to 0, reply, but also sets the code to 0. Unix and Linux ignores the code field since it's not used and leaves it's value at what ever the request was set to. So by crafting an echo request packet with the code set to a non-zero value, you can look at the reply and determine the OS. Code reset to 0, Windows. Code set to the original value, Unix/Linux. This of course, assumes the box is one of the two operating systems and the stack hasn't been mucked with to respond differently. Ofir Arkin explains this technique and other ways to use ICMP for recon in the paper found here.

Rapid 7 Buys Metasploit

2009-10-21T15:12:00.005-04:00

It was announced this morning that Rapid 7, a network vulnerability and penetration testing company, purchased the Metasploit open source framework product from it's creator, H.D. Moore, and brought him on board as CSO and Chief Architect for development of the product. Congratulations to H.D. and kudos and thanks for the years of offering the product to the network security community to test and assess their infrastructure. The CEO's press release can be found here. Metasploit will continue to be offered as open source..

Ford Engineer Charged With Trade Secret Theft

2009-10-19T13:06:00.002-04:00

Think monitoring those USB devices being plugged into your company computers isn't important?
Xiang Dong Yu, also known as Mike Yu was arrested as he attempted to re-enter the United States through O'Hare, charged with copying over 4,000 design documents off of Ford's network and taking them to China and attempting to use them to secure a job. Details here.

Recert

2009-10-12T20:57:00.001-04:00

I'm about to take my re-certification test for GCIH. Amazing how much has changed, and how much you forget in four years. Great stuff, Ed. Thanks!

DDoS Blocking?

2009-10-07T14:41:00.002-04:00

From Network World:
October 5, Network World - (International) Prototype security software blocks DDoS attacks. Researchers have come up with host-based security software that blocks distributed denial-of-service attacks without swamping the memory and CPU of the host machines.The filtering, called identity-based privacy-protected access control (IPCAF), can also prevent session hijacking, dictionary attacks and man-in-the-middle attacks, say researchers at Auburn University in their paper, “Modeling and simulations for Identity-Based Privacy-Protected Access Control Filter (IPCAF) capability to resist massive denial of service attacks.” This new method is suggested as a replacement for IP-address filtering, which is sometimes used to block DDoS attacks but is problematic because IP addresses can be spoofed, says a professor of electrical and computer engineering at Auburn and lead author of the paper. The method also greatly reduces the resources attacked machines have to expend in order to figure out whether requests are legitimate, he says. Under IPCAF authorized users and the servers they try to reach receive a one-time user ID and password to authenticate to each other. After that they cooperate to generate pseudo IDs and packet-field values for each successive packet so packets get authenticated one at a time. The receiving machines simply check the field value in each packet in order to decide whether to reject it. Only after the filter value checks out are more memory and CPU resources allocated to further process the packets, the professor says. IPCAF runs on servers and client machines and does its work with negligible impact on performance of the machines involved, he says. For instance, the CPU on a machine running IPCAF and processing legitimate requests during testing was 10.21 percent. That rose to 11.78 percent when the same machine was under attack, the professor says. Source: http://www.computerworld.com/s/article/9138982/Prototype_security_software_blocks _DDoS_attacks

Cyber Security Awareness Month

2009-10-07T10:49:00.003-04:00

October is Cyber Security Awareness Month, and the Internet Storm Center is posting a series of daily diary entries, each featuring a different port and it's uses and misuses.
Check it out at here.

Hotmail\Windows Live Passwords

2009-10-07T10:46:00.003-04:00

Thousands of Windows Live accounts were compromised a few days ago, confirmed by Microsoft. Gmail and Yahoo accounts were also affected. If you use any of those services, it's be prudent to change your password, though Microsoft reported they shut down their affected accounts and were working with users to get them reactivated....

Great Book

2009-10-07T10:29:00.002-04:00

I'm currently reading "Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks by Michal Zalewski. It's a great book, and comes highly recommended from people like Stephen Northcutt and Richard Bejtlich. I'd definitely recommend checking it out.

HIDS

2009-10-06T10:50:00.003-04:00

My last post on IDS will be a high level description of Host Based Intrusion Detection.
Host Based Intrusion Detection, or HIDS, is a sensor that is based on the monitored device itself, as the name suggests. Whereas a NIDS monitors an entire network segment, and all of the hosts that talk on it, a HIDS watches for activity on one computer.
There are several ways that a HIDS accomplishes this. The first one is by monitoring the logs from the application that the server hosts. A policy will be applied to the HIDS telling it where the log file resides, what format it's in, how often it rotates and other config settings, such as whether the HIDS needs to do conversion from evasion tactics, like using uuencoding or hex equivalents to mask strings. The log is tailed and compared to signatures, like a NIDS, and if a pattern matched the software alerts.
Host based also does system integrity checking, similar to Tripwire. Certain key system files are monitored for things like their MD5 sum, file creation and modification times and size. If a file is modified or removed, the system will send an alert. The system can also monitor the system logs (like Event Viewer on a Windows box or logfiles in var/log on a Linux box) and alert on certain entries. It can aslo monitor the registry on a Windows box for certain key modifications or new entries, like a new process added to the Run key.
And lastly, the HIDS may have the ability to monitor the kernel of the system itself. If a process puts a system call or interrupts hook into the kernel, which could be indicative of a rootkit, the program can alert and identify the location on the file system of the process that initiated it.
This is is a very simple, high level overview of IDS. If you are new to network security or just interested in learning more, there are tons of good books on the subject. One of the better ones I've read is "Network Intrusion Detection" by Stephen Northcutt and Judy Novak. Stephen also co-authored "Intrusion Signatures and Analysis", which I consider to be the companion work, and would recommend reading both.

Tuning The IDS

2009-09-24T13:19:00.003-04:00

In tuning your IDS, you might want to take the "low hanging fruit" approach first. Once you have the system up and running, and your alerting is working properly, start by finding signatures that generate a lot of alerts and can be positively confirmed as false positives. For example, say you get a ton of ICA alerts to a Citrix Server. That is the function of the server, so that type of traffic is expected and normal.
How do you want to tune this? You want to be efficient and not make the system inspect any more traffic than it has to, and also be mindful you don't do it in a way that filters out traffic you might want to see. You might decide to change the signature and modify it so it only alerts on connections from external or non-trusted networks to an internal host. This would affect all Citrix Servers on your network, which might be what you want. You need to determine risk vs efficiency here.
Or you might want to apply a filter to only your internal sensors for any traffic to that server(s). If you want even less risk, you might write your filter to ignore only your internal network segments going to those servers.
You may maintain different sets of signatures for different types of sensors, too. You could have a library for external Internet servers, another for internal servers, and yet another for the corporate frame or intranet. By doing so you can exclude signatures that would require a lot of tuning. It all depends on your risk model for that connection.
Another way to tune out alerts you may not care about would be to disable ones not relevant to your network. If all of your Internet facing servers run Windows, you could disable signatures for exploits against Linux or Solaris. If you're strictly a IIS shop, you may not care about blind attacks against Apache Web servers. On the other hand, it IS hostile traffic directed at you. You have to determine how much risk you're willing to accept to increase the performance of your system.
I've heard of network security admins who say they're not willing to accept ANY risk, and they want to run every signature available for their system. This is a really bad idea for a couple of reasons.
Tuning is done primarily for two reasons. One, to filter out the background noise of false positives or true positives that have no effect on you, and two, to streamline the performance of your sensors. Each signature you apply means your sensor has to inspect packets traversing it for those particular attributes. Running all signatures puts a huge load on your sensors, and generates so many alerts it's very difficult to focus on the relevant ones.
There are a lot of ways to tune an IDS, and you won't ever reach a point where you sit back and say "I'm finally done tuning this thing.."
An IDS needs constant care, maintenance and tuning. If you're the lone network security person where you work, you may find you spend a significant part of your day working on it. It will need tuning as new signatures are added, new circuits are deployed and new applications are rolled out. Oh, and on top of all this, you need to allow a little time to actually LOOK at the alerts. That's pretty important too!

IDS Detection

2009-09-23T09:38:00.002-04:00

The most common way an IDS detects malicious traffic is through the use of signatures. A signature is a string that the IDS looks for in a packet and does a comparison for. If the string matches, the IDS alerts. The string can be a simple ASCII string, such as "cat /etc/passwd", or it can be a regular expression which allows much more granular control, or a binary match.
There are many ways to evade signature-based detection, using different forms of encoding, fragmentation, and other forms. IDS must be able to combat these methods to ensure what it sees will match what the packet ultimately looks like when it reaches the destination host.
Some IDS use pre-processors, modules that massage the data before running it through the rules base for efficiency. For example, if an attacker fragments his traffic with overlapping fragments (a fragment that overwrites part of a previous fragment) an IDS has to be able to reconstruct that packet the same way the host that receives it would. Some systems favor the original fragment that would have been overwritten, and some the fragment that overwrites the previous. Knowing which way your server will reconstruct this traffic is very important. Snort, for example, reassembles the packets both ways, since you may have Windows-based, Unix-based or other operating systems on the host. Others, like Dragon, force you to choose one method or the other. As long as all the systems on a segment being monitored are all on the same platform, this isn't a problem.
Signatures also specify other attributes, like which direction the packet is coming from, ports, protocols and more. Each one tunes the signature to be more specific, eliminating possible false positives.
The IDS engine does detection with built-in parameters that doesn't require a separate signature. For example, there may be an ICMP module in your IDS that alerts on packets over a certain size, or a certain number of packets in a time frame all going to one host to detect a ping flood. It may look for scanning by keeping track of the number of different hosts an external address tries to connect to one one port, or the number of ports on one host it tries to connect to (port sweeps and port scans).
Stateful inspection is important here. An IDS needs to be able to keep track of state to determine if packets are part of an existing connection or a new connection. Shell code being bounced off a server without a connection ever being made might cause the analyst to take notice and investigate what else the attacker might be doing, whereas shell code being passed on an established TCP connection would be cause to take action immediately.
Anomaly-based detection uses profiles to try and establish a baseline of what is "normal" traffic, and alerts you when traffic not fitting that profile occurs. Let's say you have a Web server that is primarily used by a few customers in the same country as you, in the morning hours Monday through Friday. The rest of the time there is little to no traffic to the box. Then one Saturday morning at 3:00 AM, the box is inundated with traffic from another country. There may be nothing in that traffic that triggers a signature or the IDS engine, but the deviation from the norm is curious at the least and probably alarming. Anomaly detection tries to determine events of this type.
This is obviously a very simplistic overview. There is much more that could be said for each type of detection, and other types like heuristics, protocol-decoding, etc., that you can read about if you'd like to learn more.

IDS Monitoring

2009-09-18T07:42:00.003-04:00

How do you monitor the network with an IDS?

There are a couple of different ways, depending on what segment you wish to monitor and your budget. The first way is via a network tap. A tap is a device that sits in-line and duplicates all packets to another interface or multiple interfaces for monitoring.
There are several different types of taps: passive or active, half duplex or full, single device or multiple.

A passive tap allows you to monitor all packets going through the device by copying the packets to one port (full-duplex) or two (half-duplex). Full duplex taps must use a time of arrival algorithm to aggregate the stream on the monitoring port. Simplex taps use two monitoring ports, once for each network port. You must use channel bonding on the monitoring device to aggregate them back into one stream.

An active tap allows you to put packets from the monitoring device back through the tap onto the network. This is used for active response in IDS, that is, shooting down certain traffic you wish to stop. This is usually done by sending spoofed RST (reset) packets to both ends of the connection and tearing it down.

Some taps (called regeneration taps by some vendors) can regenerate the traffic stream to multiple network ports, allowing more than device to monitor it. You may, for example, use a four device tap at an Internet ingress point, and patch one port to your IDS, another to a packet auditing system like IDABench or Shadow, another to an analysis/statistics box for the network team and leave the fourth available for some future use, such as vendor troubleshooting.

SPAN ports, or port mirroring, are done on the switch. A span port is a switch port that is set up to receive copies of all packets seen by another port. Though easy to set up and not requiring any additional cost, there are disadvantages to span ports as opposed to taps. Span ports can drop packets such as runt packets (undersized), giants (oversized packets), and packets with CRC errors. Also, if a switch gets overloaded and experiences high utilization, the SPAN port will be the first place the switch will start dropping packets. If you are under an attack that creates large amounts of traffic, you may start losing packets at the very time it's critical to see them.

In the next post, I'll cover the different ways an IDS can detect malicious traffic.

IDS - The Intrusion Detection System

2009-09-17T12:57:00.003-04:00

I'm going to take the next few posts to talk about IDS, Intrusion Detection Systems. I'll discuss it from the ground up for those who are new to Network Security.

An Intrusion Detection System is a host or piece of software that monitors either network traffic streams or logs and processes on one box for malicious activity. There are two distinct types of systems, NIDS and HIDS.

NIDS - Network Intrusion Detection System: A NIDS monitors network traffic. It can be placed about anywhere there is a need for it, but the most common placement is at an ingress point where Internet traffic comes into the network. There is some debate as to the optimal placement at an Internet choke point, as to whether it should monitor inside the firewalls or outside, but my experience is most experts agree if you only have one, inside is better. (Having one inside and one outside is, of course, even better).

There are several reasons for this. A NIDS that is placed inside the firewall is seeing traffic that was not dropped (either by design or unintentionally) by the various layers of border perimeter defenses. That traffic has traversed one or more border routers and was not prohibited by Access Control Lists, and has successfully passed one or more firewalls without being blocked by a rule. The assumption is this is normal, wanted traffic such as a customer accessing your web site. However, since ACL's block certain IP's and firewalls allow traffic to certain IP's on certain ports, this may just as easily be someone trying to exploit a vulnerability in the web sites application code. For discussion purposes, we're assuming the firewall in question isn't a multi-purpose appliance with IDS on board. Some firewall software also has a limited IDS signature set built in that may catch and block certain very well known attacks. A lot of network administrators are hesitant to run even this limited functionality because of the fear of blocking legitimate traffic by mistake.

A NIDS outside the firewall would alert as well. But you would be uncertain without checking logs on the firewall or a packet auditing system whether the traffic was allowed, or blocked by the firewall. With an internal IDS, you know instantly.

Another very good reason to have an internal NIDS is for tracing back internal compromises and outbreaks/infections. Let's say one of your end user desktop PC's get's popped and becomes part of a bot net. The code on the machine begins to connect out to the botnet controller to notify it that it's under control and to download other software or receive instructions. Assuming you use internal RFC 1918 IP addressing, that traffic will route out to your firewall, be translated to the hide address of your firewall and on to the Internet. Let's say your hide address is 66.66.66.1.
All hosts on your internal network would get translated to this IP address going out to the Internet.

A NIDS outside your firewall would only see the packets after they had been translated. Which of the desktops is infected and calling out to the botnet? Again, you'd have to rely on logs on your network infrastructure equipment, which is not only time consuming, but depending on how logging is set up, may not even help you. Because of sheer size of full logging, a lot of shops only log drops on the firewall and denies on routers, not allowed packets. A a packet that is accepted may not (probably not) even be logged.

But your internal NIDS sees the packets before the firewall, and hence, before they are translated, so your alert will identify the internal IP address, allowing you to easily trace back to the machine and do your incident response and shut it down.

In the next few posts, I'll cover different ways to monitor traffic, the different ways an IDS detects malicious traffic or activity, a few basics on tuning sensors and what Host-based Intrusion Detection is.