Bro-NIDS: Pairing with Ourmon

Beside Snort, Bro-NIDS is another one of the most powerful open source NIDS that developed by Vern Paxson and his team with community supports.

I figure out the lacking part of Bro, the detail explanation of analysis flow definitely. So what's the problem with that? Let's take a look at its logs -

shell>ls -la logs
-rw-r--r-- 1 bro wheel 196714 Jul 26 12:17 alarm.hostname.07-07-23_00.00.01
-rw-r--r-- 1 bro wheel 406878 Jul 23 17:33 alarm.hostname.07-07-23_00.00.01-07-07-23
-rw-r--r-- 1 bro wheel 142239 Jul 24 21:39 alarm.hostname.07-07-23_00.00.01-07-07-24
-rw-r--r-- 1 bro wheel 585678 Jul 25 22:39 alarm.hostname.07-07-23_00.00.01-07-07-25
-rw-r--r-- 1 bro wheel 258391385 Jul 23 00:00 conn.hostname.07-07-18_15.25.41-07-07-22
-rw-r--r-- 1 bro wheel 130996 Jul 23 00:00 conn.hostname.07-07-18_15.25.41-07-07-23
-rw-r--r-- 1 bro wheel 35500032 Jul 26 12:17 conn.hostname.07-07-23
-rw-r--r-- 1 bro wheel 100144755 Jul 24 00:00 conn.hostname.07-07-23_00.00.01-07-07-23
-rw-r--r-- 1 bro wheel 76778138 Jul 25 00:00 conn.hostname.07-07-23_00.00.01-07-07-24
-rw-r--r-- 1 bro wheel 83297924 Jul 26 00:00 conn.hostname.07-07-23_00.00.01-07-07-25
-rw-r--r-- 1 bro wheel 856239 Jul 23 00:00 ftp.hostname.07-07-18_15.25.41-07-07-22
-rw-r--r-- 1 bro wheel 603 Jul 23 00:00 ftp.hostname.07-07-18_15.25.41-07-07-23
-rw-r--r-- 1 bro wheel 765952 Jul 26 12:17 ftp.hostname.07-07-23
-rw-r--r-- 1 bro wheel 2371772 Jul 24 00:00 ftp.hostname.07-07-23_00.00.01-07-07-23
-rw-r--r-- 1 bro wheel 2529580 Jul 25 00:00 ftp.hostname.07-07-23_00.00.01-07-07-24
-rw-r--r-- 1 bro wheel 1646301 Jul 26 00:00 ftp.hostname.07-07-23_00.00.01-07-07-25
-rw-r--r-- 1 bro wheel 179461957 Jul 23 00:00 http.hostname.07-07-18_15.25.41-07-07-22
-rw-r--r-- 1 bro wheel 47554 Jul 23 00:00 http.hostname.07-07-18_15.25.41-07-07-23
-rw-r--r-- 1 bro wheel 77824 Jul 26 11:49 http.hostname.07-07-23_00.00.01
-rw-r--r-- 1 bro wheel 642726 Jul 24 00:00 http.hostname.07-07-23_00.00.01-07-07-23
-rw-r--r-- 1 bro wheel 627456 Jul 25 00:00 http.hostname.07-07-23_00.00.01-07-07-24
-rw-r--r-- 1 bro wheel 202697 Jul 26 00:00 http.hostname.07-07-23_00.00.01-07-07-25
Output truncated .....

Ouch! There are so many logs here and how should I start? Just like sguil where you must speak mysql pretty well to perform better analysis, you must speak shell scripting enough to perform smooth analysis flow on Bro logs. The power of Bro lies in it's protocol anomaly detection and therefore having different protocols logging in different files(prefix with its protocol) do make things clear. However you can't consider its logs as alert and indicator of malicious event(different approach comparing with snort) even though alarm, notice and weird logs do give some clues about suspected network event. Another problem should be when the file grows larger in a day, it is pretty hard to crawl the file to check on malicious event. For example look at one of the file -

shell>du -h \
conn.hostname.07-07-18_15.25.41-07-07-19_00.00.00
510M conn.hostname.07-07-18_15.25.41-07-07-19_00.00.00

It could be deep pain if you want to read them, don't you? Therefore it becomes unclear when one first learn about Bro and want to proceed to examine the logs but don't know where to start. Here I will give you some insight of how I perform analysis using Bro but I need another powerful tool to assist me, I vote ourmon!

Bro only generates network statistical data in its daily report therefore we don't have real time view of current network statistic, therefore ourmon plays the main role for you to access to the network statistical data via its well crafted graph. But where's our flow data to understand each connection? Bro does store connections flow data, all its connections flow stored in the file with the prefix of conn.*. The only data we don't have is full content(pcap), you can either use tcpdump, daemonlogger or Bro alone to do the job for you however I would like to ignore this part for the moment because generally you can have idea of each connections because most of the widely used and popular protocols such as http, smtp and so forth are decoded and stored in its corresponding file such as http.*, smtp.* and so forth, other protocols that are not decoded(provided no decoder for it) still can be seen in conn.* to understand its nature. Here's the example when you find unconfirmed or suspected malicious activity in certain time frame via notice log -

notice.sguard.07-07-23_00.00.01-07-07-25_00.00.00:t=1185314110.984062 no=ProtocolFound na=NOTICE_FILE sa=1.2.3.4 sp=33071/tcp da=10.0.0.1 dp=443/tcp num=14 msg=1.2.3.4/33071\ >\ 10.0.0.1/https\ FlashCom\ (via\ HTTP)\ on\ port\ 443/tcp sub=FlashCom\ (via\ HTTP) tag=@2113

Interesting connection from 1.2.3.4 to 10.0.0.1, you have the tag number @2113 for this connection flow, now we can grep the flow from connections log -

shell>egrep '@2113' \
conn.sguard.07-07-23_00.00.01-07-07-25_00.00.00 | cf
Jul 25 05:55:05 122.708121 1.2.3.4 10.0.0.1 https 33071 443 tcp 13384 12298 RSTR L %332 @2113 HTTP

You may see I pipe to cf, cf is small utility to translate unix epoch time format to human readable form, therefore it's more easy for you to read and correlate the event based on time frame. The format of connections flow should be read in this way -

| Start | Duration | Local IP | Remote IP | Service | Local PORT | Remote PORT | Protocol | Orig Bytes Sent | Res Bytes Sent | State | Flags | Tag |

The only part which is not clear is the connection state - RSTR, you can check out here -

RSTR Established, responder aborted.

While L means connection is initiated locally.

There are two tags, %332 and @2113, so now we know about the connection flows which is http, we should search the tag %332 in http log -

shell>egrep '%332' \
http.hostname.07-07-23_00.00.01-07-07-25_00.00.00

1185314105.742038 %332 (200 "OK" [10])
1185314107.122409 %332 POST /idle/315397832/2 (200 "OK" [67] ic.flashcom.peopleim.userplane.com:443)
1185314107.750136 %332 POST /send/315397832/4 (200 "OK" [1260] ic.flashcom.peopleim.userplane.com:443)
Output truncated .....

Here you go, you are now having full understanding of the network connections(all those http requests with same tag number), this is kind of batch analysis to identify network events. I don't explain how I make use of ourmon here or maybe I will make it for future post. Ourmon generates the graph by plotting such as TCP flags ratio, network errors, irc stats and some other graphs that you can correlate with the data provided by Bro to fully understand your network and readily countering any network threats.

Below I demonstrate some of the tips I use before I examine Bro logs, it's good catch if we want to read the separate kind of logs in timely manner, for example I want to check out the alarm log only, I just execute -

shell>ls -lac alarm*
-rw-r--r-- 1 bro wheel 0 Jul 23 00:00 alarm.hostname.07-07-18_15.25.41
-rw-r--r-- 1 bro wheel 3999 Jul 19 00:00 alarm.hostname.07-07-18_15.25.41-07-07-18_15.25.50
-rw-r--r-- 1 bro wheel 4515 Jul 20 00:00 alarm.hostname.07-07-18_15.25.41-07-07-19_00.00.00
-rw-r--r-- 1 bro wheel 4525 Jul 21 00:00 alarm.hostname.07-07-18_15.25.41-07-07-20_00.00.00
-rw-r--r-- 1 bro wheel 1551 Jul 22 00:00 alarm.hostname.07-07-18_15.25.41-07-07-21_00.00.00
-rw-r--r-- 1 bro wheel 1363 Jul 23 00:00 alarm.hostname.07-07-18_15.25.41-07-07-22_00.00.00
-rw-r--r-- 1 bro wheel 0 Jul 23 00:00 alarm.hostname.07-07-18_15.25.41-07-07-23_00.00.00
-rw-r--r-- 1 bro wheel 206776 Jul 26 13:50 alarm.hostname.07-07-23_00.00.01
-rw-r--r-- 1 bro wheel 406878 Jul 24 00:00 alarm.hostname.07-07-23_00.00.01-07-07-23_00.00.04
-rw-r--r-- 1 bro wheel 142239 Jul 25 00:00 alarm.hostname.07-07-23_00.00.01-07-07-24_00.00.00
-rw-r--r-- 1 bro wheel 585678 Jul 26 00:00 alarm.hostname.07-07-23_00.00.01-07-07-25_00.00.00

I use ls with -c switch so that I can sort them by file creation time, that way making us easy to check out any daily log we want by date especially searching for connections tag. In the alarm log, you may see the time stamp of every network event started with t=, that render cf tool unable to convert the time stamp from unix epoch time to human readable form correctly -

shell>head -2 alarm.hostname.07-07-23_00.00.01
t=1185379996.560573 no=ProtocolViolation na=NOTICE_ALARM_ALWAYS sa=1.2.3.4 sp=33762/tcp da=2.3.4.5 dp=25/tcp msg=1.2.3.4/33762\ >\ 2.3.4.5/smtp\ analyzer\ SMTP\ disabled\ due\ to\ protocol\ violation sub=reply\ code\ out\ of\ range tag=@4363
t=1185380009.544433 no=PortScan na=NOTICE_ALARM_ALWAYS sa=1.2.3.4 da=2.3.4.5 dp=443/tcp msg=64.86.142.65\ has\ scanned\ 50\ ports\ of\ 10.14.42.154 tag=@4364

You can use sed to remedy this issue -

shell>sed 's/^t=//g' alarm.hostname.07-07-23_00.00.01 | cf

Just discard t= and parse it to cf. Bingo! Piping to less command is also great because you can perform certain function such as search by regular expression, easy log navigation and so forth(vi style functions).

Both Bro and Ourmon provide you great context for most of anomaly network events, I have spent my time to figure out the better way to utilize them and hopefully this help anyone who uses them because I did face difficulty when first dealing with Bro that it seems to require more man power to examine them. One more tip, remember to turn on dynamic protocol detection(DPD) when dealing with stealthy attackers.

Some of you may wonder why not examining the application protocol log(http.*, ftp.*) and instead of digging the connections log first, the answer is pretty simple, if you examine the connections log and found no data transfers(Orig Bytes Sent | Res Bytes Sent), it's pointless to look at the application protocol log and may indicate some kind of network probing or scanning activities. However this doesn't apply to every condition and sometimes you need to tinker of how to perform analysis effectively. I draw the simple diagram for better illustration -

I use color depth to indicate the understanding level of the network event. You may see the color in the entity becomes lighter and lighter from left to right when you have better understanding of network event through out the structural analysis process.

What's the lacking in Bro? Clearly enough that it really needs better way to organize and manage its logs and perhaps OSSEC can fill the gaps with additional log parser. Using this mechanism with the deployment of Snort NIDS, I'm pretty confirmed that you can identify known and unknown(0 days) network attacks.

Enjoy (;])