[Bro] handle out of order and retransmitted packets in offline trace

[Song Zhao]

Hi,

In the 12G rewritten trace, the port numbers range widely. http-rewriter.bro
loads http-reply.bro,which loads http-request.bro,which loads http.bro. The
codes about filteration in these policy scripts are as follows:

In http-request.bro:
redef capture_filters +=  {
    ["http-request"] = "tcp dst port 80 or tcp dst port 8080 or tcp dst port
8000"
};
In http-reply.bro:
redef capture_filters += {
    ["http-reply"] = "tcp src port 80 or tcp src port 8080 or tcp src port
8000"
};
In http.bro:
# DPM configuration.
global http_ports = {
    80/tcp, 81/tcp, 631/tcp, 1080/tcp, 3138/tcp,
    8000/tcp, 8080/tcp, 8888/tcp,
};
redef dpd_config += { [ANALYZER_HTTP] = [$ports = http_ports] };
redef dpd_config += { [ANALYZER_HTTP_BINPAC] = [$ports = http_ports] };

Any of them sets DPD on? If not, why the port numbers in the rewritten trace
range so widely, which range much more widely than the range of global
http_ports?
I didn't load dpd.bro anywhere. After checking the payloads roughly, as far
as I found, they all contain HTTP requests or responses. I mean they are
really "HTTP streams" whatever the port number is.

Thanks
Song Zhao

On Fri, May 27, 2011 at 4:43 PM, Vern Paxson <vern at icir.org> wrote:

> > I also tried ./bro -r readfile -A writerfile http-rewriter.bro, whose
> > results seem to be the same as those of ./bro -r readfile
> http-rewriter.bro
> > -A writefile. And is there any difference of the resulting trace between
> > using -A and - w for http-rewriter.bro?
>
> If you specify both, then you get the untransformed trace in the -w file
> and the transformed one in -A.  If you specify just one, then that's the
> transformed file.
>
> > Does http-rewriter.bro by default use DPD to find http streams intead of
> > port numbers?
>
> I don't know.  But you can avoid this question by just wiring in the
> ports of interest into the initialization of capture_filters in
> http-reply.bro.
>
> > Interestingly, majority of
> > them are port 20480.
>
> Note, 20480 = 80 but little endian.  This suggests either a bug in how
> you're viewing the port numbers, or in how Bro is displaying (or possibly
> processing them).
>
>                Vern
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20110530/005188f5/attachment.html