Viewing Bro Logfiles

Once you have configured Bro and re-loaded its configuration files, it's time to look into logging. You can view the logfiles in the /nsm/bro/logs/ directory. This directory will contain several subdirectories and one file. The subdirectories are organized by date. You will also find a file named current, which, in this case, is a symbolic link to the kirk node. This node will contain several different logfiles, such as:

• weird.log
• communication.log
• dns.log
• packet_filter.log
• ssl.log
• httpd.log
• scripts.log

I've found that the weird.log, dns.log, httpd.log, and scripts.log files are usually the most interesting. The weird.log file has a notice section, as shown in Figure 3.

Figure 3: Logfiles from Bro.

The notice section is interesting to me because, in my consulting experience, I've found that many attackers use attacks that take advantage of improper fragmenting of packets, and in some cases, packets are sent without a matched DNS reply.

Therefore, looking for unmatched DNS replies is a perfect first step in identifying what could be problem packets. In the notice field found in Figure 3, you will see that the packets I generated were tagged by Bro as dns_unmatched_reply , which means that this particular packet didn't have any corresponding DNS entry, either in the corporate DNS database or on the Internet.

Although you can't live or die by this one bit of information about DNS entries, it's very much a tell-tale sign. This is how Bro works: It gathers information and tell-tale signs and helps you identify issues and interpret possible security events.

Marking fragments is also important because firewalls tend to study only the first part of a packet. If an attacker can carefully craft a packet to avoid firewall detection by placing an improper fragment at the end of a packet, this improper fragment can then be used to confuse routers and conduct various denial of service attacks.

Bro does more than notice fragmented packets. Notice the active_connection_reuse field in Figure 3. Active connection reuse can denote man-in-the-middle attacks. They can also denote packets that have been re-sent out on the network. In this case, Bro is discovering that the packets I created have been used before; once again, Bro is excellent at tagging data. This ability to tag data allows you to identify trends on the network.

Denial of service attacks, of course, usually deploy forged network packets. Bro can easily mark such traffic and then find a way to see how this type of traffic is changing over time. Doing this can help identify trends, something that is increasingly important today.

Testing Bro

Once Bro is up and running, the next step is to test it. One way to test is to use packet-generating software. In my case, I'm using the old but (relatively) trusty PackETH program, shown in Figure 4.

Figure 4: Using PackETH to generate a fragmented packet.

PackETH is a fairly grumpy program that requires you to know your TCP/IP suite cold; you need to understand all elements of the IP header, as well as how TCP and UDP work, and you need to understand the MAC address. You'll need to know it all.

In my case, I created a fake packet to test fragmentation. I created a simple UDP packet that includes an improper length. In addition to forging packets, PackETH can send them across the network wire.

Next, I used PackETH to send the packet across the wire. To verify this transmission, I used Wireshark to do a standard, run-of-the-mill capture, as shown in Figure 5.

Figure 5: Viewing a packet generated by PackETH in Wireshark.

Wireshark captured the traffic sent by PackETH, but notice that, as you might expect, Wireshark simply shows you the information without providing any sort of real interpretation. In fact, it simply shows that a series of packets have been sent. Wireshark is terrific at grabbing data, but it isn't so good at turning that data into information. That's your job, with help of Bro.

Figure 6 shows the same series of packets found in Bro's weird.log file, which I found in the current/ directory:

Figure 6: Manipulated/fragmented packets appearing in Bro.

Notice that, now, the data is marked as having an unmatched DNS reply. This mark enables you to identify more quickly an issue in a protocol on your network.

Figure 7 shows something else. Bro is also capable of finding whether an active TCP connection has been re-used. You can see Bro marking this traffic in the entry marked active_connection_reuse .

Figure 7: Viewing active connection reuse markings generated by Bro.

Active connection reuse can sometimes reveal a replay attack, as well a connection hijacking attack. In this case, Bro is noticing that I have taken packets and replayed them onto the network using PackETH.

Managing Bro Policies

Bro lets you specify policies to define capture behavior. The best way to reduce or increase the amount of information you capture is to manage the policies that load whenever Bro re-reads its configuration files. By default, Bro will read all of the policies found in the directory /nsm/bro/share/bro/policy/protocols/. These policies are relatively simple text files, and it is possible to create your own scripts or download additional scripts.

Policies capture information about connection types, protocols (e.g., DHCP, FTP, HTTP, SSH), and connections. The list is quite comprehensive. In my implementation of Bro, I can list the policies that are loaded by using the command:

[BroControl] > scripts -c kirk

If you want to disable a policy, simply remove the script from the directory; then, make sure to re-load the scripts from within BroControl using the deploy command:

[BroControl] > deploy