[Bro] broccoli tests

[Christian Kreibich]

Mike,

I'll just try to answer to your comments in the sequence they came
in. :)

On Mon, 2005-06-06 at 13:02 -0500, Mike Muratet wrote:
>
> > $ ./bro ~/devel/Broccoli/test/broping.bro
> > 1117837283.819435 warning: event handlers never invoked:
> > 1117837283.819435 warning:       ping
> >
> > $ broping
> > pong event from 127.0.0.1: seq=0, time=0.010662/1.010452 s
> > pong event from 127.0.0.1: seq=1, time=0.008867/1.008964 s
> > pong event from 127.0.0.1: seq=2, time=0.038239/1.009833 s
> > pong event from 127.0.0.1: seq=3, time=0.009923/1.009428 s
> > pong event from 127.0.0.1: seq=4, time=0.038738/1.009980 s

> I stopped bro and used nmap to scan 47757 and 47758 and they are both 
> closed. I then restarted bro with load @broping as the last line in my 
> local.site.bro and repeated the scan with the result that 47757 is now open. 

Sounds good. To be extra sure that no policy settings interfere with
broping.bro, just run broping.bro directly as shown above.

> The latest iana.org list shows these ports are in an 'unassigned' range. I 
> am starting bro logged in a root and the bro.cfg file defines root as the 
> user.

Don't be root -- there's no need. The reason why we're using the high
ports in the unassigned range is precisely so you don't have to be root.

> The comm.log file says that bro is listening on 127.0.0.1:47757. It also 
> complains on the line above this that "can't bind to port: address in use". 
> I have no clue what this means, since the port scan shows those ports closed 
> when bro is stopped.

I'm guessing that multiple attempts were made to bind to that port, and
while the first one didn't succeed the following one did. Looking at the
code I think that when Bro says it's listening, it definitely is.

> I looked at broping.bro, which loads listen-clear.bro which loads 
> remote.bro. remote.bro defines 'default_port_clear=47757.tcp'. 
> listen-clear.bro uses this value to initialize listen_port_clear. 
> broping.bro checks to see if listen_port_clear is defined and if so 
> redefines it to 47758. If this were successful, would not the port scan show 
> 47758 as open? Running broping -d -d I see in the output that the connection 
> was refused to 127.0.0.1:47758.

Does it say "connection refused", or "Could not connect to Bro"? This
difference is important -- the former would mean the TCP connection
couldn't be established, while the latter would mean something in the
Bro-internal protocol handshake may have gone wrong.

Make sure your high ports aren't firewalled.

On Mon, 2005-06-06 at 13:08 -0500, Mike Muratet wrote: 
> Here's another bit: when I broping -p 47757, the comm.log shows 'request for 
> unknown event pong' errors. It acts like broping.bro is not getting loaded. 

So now the connection definitely gets established; I'll assume the
connection refused problem above was a "Could not connect to Bro".

Just avoid any doubts regarding whether or not broping.bro is loaded
correctly by running Bro directly with it, per my example.

> Is bro prone to fail things silently?

Not in general, no.

On Mon, 2005-06-06 at 15:40 -0500, Mike Muratet wrote: 
> I have tried a few more things. It appears to me that my local.site.bro is 
> not getting called. I can use broping.bro or broping-record.bro as my 
> starting policy in bro.cfg and I can verify that bro is listening on 47758 
> with nmap. I can capture the transactions with tcpdump per Scott's 
> recommendation and I can see that there are 7 messages from 127.0.0.1:34102 
> to 127.0.0.1:47758 with replies.

That all sounds good.

> I forget how to interpret the payloads, but 
> I'll go back and read the manual.

Don't bother, that's just the details of the serialization protocol.

> In any event, all the combinations of 
> broping.bro, broping-record.bro and broping -r return "Could not connect to 
> bro at 127.0.0.1:47758".

Okay. Note that this is a Broccoli-level error message and not at TCP
one (I'll make sure that error message is more clear in that regard for
0.8). The underlying TCP connection does work, according to your
description above. Debugging output will likely allow me to answer
what's going on.

> So, I reconfigured bro with bro_config. It sets the start policy to 
> localhost.localdomain.bro and I gave it an empty file. I'm not sure I'm 
> entirely clear as to the purpose of this parameter, but that's OK--I don't 
> think that's where the problem lies. With this configuration, the broping 
> script is not getting called and it looks to me that local.site.bro is not 
> getting called. I put print and log statements in it and I don't see 
> anything on standard out or in the logs.
> 
> So, does local.site.bro get called automatically or do I have to coerce it 
> with a load statement? If I can make sure bro is configured properly then 
> maybe the rest will fall into place. I notice that bro_config writes some 
> network information into local.site.bro. What happens to bro if this 
> information is not available?

Forget all this for now -- just run broping.bro directly. Once that
works, we can always add more stuff around it.

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org