Dynamic Protocol Detection

Gentle people,

I have enabled dpd in brolite.bro with

const use_dpd = T;

At the same time I also comment out this line because I want to look into port 80 traffics.

redef restrict_filters += [ [“not-http”] = “not (port 80)” ];

I get a lot of this


t=1166923564.867909 no=ProtocolViolation na=NOTICE_ALARM_ALWAYS sa=1.2.3.5 sp=46616/tcp da=1.2.3.4
dp=80/tcp msg=[1.2.3.5/46616](http://1.2.3.5/46616) >\ [1.2.3.4/http](http://1.2.3.4/http) analyzer\ HTTP\ disabled\ due\ to\ protocol\ violatio
n sub=not\ a\ http\ request\ line tag=@5618

In the wiki, it says that Bro can disable an analyzer on the fly if that finds that it cannot parse a connection’s payload—which most probably means the protocol detection went wrong. I’m curious about the protocol violation part. From what I have studied if I enable dpd, it should examine the traffics via dpd.sig before determine which protocol is used. Since I have pcap logging, I try to examine the traffic manually with tcpdump and it seems to be normal http session from 1.2.3.5 to 1.2.3.4. Thus I’m wondering why it happens as if the http analyzer is disabled then the ids can be evaded.

Another strange behaviour is the

redef restrict_filters += [ [“not-http”] = “not (port 80)” ];

I have few ports running http traffic, so I need to avoid the report of http traffics running on port other than 80. For example I have two ports such as ports 7777 and 7778 running some http kind of daemon, so to do it I just add this in the dpd section of brolite.bro

redef restrict_filters += [ [“cpanel2”] = “not (port 7777)” ];
redef restrict_filters += [ [“cpanel3”] = “not (port 7778)” ];

So it works as expect but when I add another port for example port 7785 below above two lines,

redef restrict_filters += [ [“cpanel3”] = “not (port 7785)” ];

Suddenly it doesn’t work and report http traffics running on those ports. So I’m curious if anyone have this similar issue. I have tried to define multiple ports with not(port 7777 and port 7778) for example but it doesn’t work, I read the wiki and it says that restrict_filters introduces “and” so that’s why I have to specify multiple restrict_filters instead.

One interesting issue also that happens to me is that I have tried to enable the full trace in bro.cfg,

BRO_CREATE_TRACE_FILE=YES

It logs the pcap correctly, so I try to disable it with

BRO_CREATE_TRACE_FILE=NO

Then restart bro-ids with bro.rc checkpoint, however it is still logging, thus I have to comment out the line

BRO_CREATE_TRACE_FILE=NO

Restarting bro-ids again and this time the full pcap logging no longer works. That’s all, I know sooner this will be replaced by time machine for full content logging but just would like to know if this is my problem or anyone have this.

Thanks and cheers.

seems to be normal http session from 1.2.3.5 to 1.2.3.4. Thus I'm wondering
why it happens as if the http analyzer is disabled then the ids can be
evaded.

Hard to say without seeing the actual packets. Can you send me the
trace of that connection?

redef restrict_filters += [ ["cpanel2"] = "not (port 7777)" ];
redef restrict_filters += [ ["cpanel3"] = "not (port 7778)" ];

[...]

redef restrict_filters += [ ["cpanel3"] = "not (port 7785)" ];

Assuming that this is not just a typo in the mail, you're using the
same index twice (cpanel3), and therefore the second entry for that
index overrides the first one, and you are going to see packets on
port 7778. If you load print-filter.bro, you see what Bro's packet
filter looks like.

Note that another way for suppressing alerts for certain
ports/servers is redefining ProtocolDetector::valids. See
detect-protocols.bro for exampleas.

BRO_CREATE_TRACE_FILE=NO
# BRO_CREATE_TRACE_FILE=NO

(Can't say much about this, but probably it's a small bug in the
shell script.)

Robin