The alarm.log is a 'tagged' format that is fairly self descriptive. This is an example from the alarm.log file:
t=1000057981.940712 no=AddressScan na=NOTICE_ALARM_ALWAYS sa=10.1.1.1 sp=2222/tcp da=10.2.2.2 dp=3333/tcp msg=10.1.1.1\ has\ scanned\ 2000\ hosts\ (3333/tcp ) tag=@42
Where the tags indicate the following:
The alarm file format is designed to be easy to parse and interpret by programs, not humans.
NOTE: the examples in this section still use the old log format. This needs to be updated
Bro generates a number of types of alarms, such as suspicious connection attempts directed at your systems (address scanning), port scans, and attempts to gain access to user accounts. We describe some of these in more detail here.
Vulnerability scans directed against systems
The first category of suspicious connection attempts that Bro identifies and reports is vulnerability scans directed against systems. Instead of burdening you with every vulnerability scan (no matter how tiny) against systems that occurs, it reports only scans that occur at or above its threshold in terms of a specified size, such as the number of vulnerability scan attempts per second. The following entry indicates that IP address 66.243.211.244 has scanned 10000 of your systems on tcp port 445, the port used by newer Windows systems such as Windows 2000, XP and Server 2003 for share access:
Nov 16 06:30:49 AddressScan 66.243.211.244 has scanned 10000 hosts (445/tcp)
Important note: If the source of a scan is an IP address within your own network, the probability that this system is infected or has been taken over by an attacker is very high.
At the bottom portion of each Bro report summaries of scan activity also will appear for your convenience (see the bottom part of Figure 1). Scan summaries look like the following:
Nov 16 8 01:30:11 ScanSummary 194.201.88.100 scanned a total of 145 hosts
Port scanning
Port scanning means that a system has targeted one system, connecting to one port, then another, until it has scanned a whole range of ports. In the following example a system with an IP address of 218.204.91.85 has scanned 50 ports of a system named diblys.dhcp within an internal network:
Nov 16 06:30:50 PortScan 218.204.91.85 has scanned 50 ports of siblys.dhcp
An address dropped entry is likely to appear shortly after a port scan is reported. In the following entry, the system with an IP address of 218.204.91.85 was systematically probing low ports, that is, ports in the range from 0 to 1023, on sibyls.dhcp:
Nov 16 06:30:52 AddressDropped low port trolling 218.204.91.85 403/tcp
Connection attempts
Bro finds attacks against user accounts, such as password guessing attempts. When it does, it reports them as follows:
(Need example here)
Weird events
Bro labels unusual or exceptional events as weird Weird events include a wide range of events, including malformed connections, attacker's attempts to confuse or evade being detected, malfunctioning hardware, or misconfigured systems or network devices such as routers. Some weird events could be the result of an attack; others are just anomalies. The better you know your own systems and networks, the more likely you will be to correctly determine whether or not weird events compromise an attack. Weird events are divided into three categories:
1. Weird flows in which data is being sent between two systems, but no specific connection between them can be identified, and
1. Weird network behavior that cannot be associated with any particular system.
The following entry shows a weird connection in which packets are being sent between systems in what appears to be an ongoing ftp session, but Bro has not identified any initial connection attempt (i.e., there is an ack above a hole):
Nov 16 06:30:58 WeirdActivity window/50406 > klecker.debian.org/ftp ack above a hole
The next entry (below) shows another weird traffic pattern in which eqvaadvip1.doubleclick.net has sent a flood of FIN packets, packets that tell the other system in a connection to terminate the connection, to bcig-8 within the network that Bro protects.
Nov 16 06:32:09 WeirdActivity bcig-8/2044 > eqvaadvip1.doubleclick.net/http: FIN_storm
Here's another one -- in this case a system with an IP address of 222.64.93.208 has sent a flood of packets that have both the SYN and the ACK flags set, something that should normally happen only once in a TCP session. nsx
is the destination system.
Nov 16 06:30:58 WeirdActivity 222.64.93.208/1115 > nsx/dns: repeated_SYN_with_ack
Packets sent over networks are often broken up (or fragmented) for various reasons. Fragmented packets are not necessarily a sign of an attack, but large fragments can indicate suspicious activity such as attempts to cause denial of service. In the following example Bro has identified a very large packet fragment sent by p508c7fc5.dip.t-dialin.net to an internal system with an IP address of 131.243.3.162:
Nov 16 06:30:50 WeirdActivity p508c7fc5.dip.t-dialin.net -> 131.243.3.162: excessively_large_fragment
Sometimes attackers attempt to evade being detected by sending malformed packets to the system they are attacking. The receiving system cannot process them, so it informs the sending (attacking system) accordingly, asking it to resend them. The sending system may now send packets that constitute an attack. Some intrusion detection systems (but not Bro) ignore what is resent because in theory it is unnecessary to reanalyze what has already been sent. Bro detects this kind of retransmission inconsistency (rexmit inconsistency) and reports it. The following example shows that there has been retransmission inconsistency in packets sent by a system at IP address 131.243.223.212 to origin2.microsoft.com:
Nov 16 06:30:59 RetransmissionInconsistency 131.243.223.212/2270 > origin2.microsoft.com/http rexmit inconsistency (HTTP/1.1 200 OK^M^JDate: Tue, 16 Nov 2004