Hello everyone:
Bro 2.1 employs DPD to do application layer protocol classification. That
is, it looks at the first few packet's payload to determine its service
type.
However, I notice that a large number of flows go through port 80 are
considered as TCP not HTTP. We just want Bro to do application layer
protocol classification based on port. What should I do?
I hope that some people can give me some advice.
Thank you!
Bro 2.1 employs DPD to do application layer protocol classification. That
is, it looks at the first few packet's payload to determine its service
type.
Here's the paper that describes it in more detail if this helps:
http://www.icir.org/robin/papers/usenix06.pdf
However, I notice that a large number of flows go through port 80 are
considered as TCP not HTTP. We just want Bro to do application layer
protocol classification based on port. What should I do?
I think you're going to have to describe more about what you are actually seeing that you think is incorrect. TCP and HTTP are different classes of protocol anyway since TCP is transport and HTTP is application. Bro should be identifying supported protocols on any port and attaching an appropriate analyzer if one exists.
.Seth
Bro 2.1 employs DPD to do application layer protocol classification.
That
is, it looks at the first few packet's payload to determine its service
type.Here's the paper that describes it in more detail if this helps:
http://www.icir.org/robin/papers/usenix06.pdfHowever, I notice that a large number of flows go through port 80 are
considered as TCP not HTTP. We just want Bro to do application layer
protocol classification based on port. What should I do?I think you're going to have to describe more about what you are actually
seeing that you think is incorrect. TCP and HTTP are different classes of
protocol anyway since TCP is transport and HTTP is application. Bro
should be identifying supported protocols on any port and attaching an
appropriate analyzer if one exists..Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/
Hello Seth:
Thank you for your information, I have read the paper you mentioned.
I am wondering whether it is possible for Bro to do traffic analysis just
based on port. For example, traffic goes through port 80 is regarded as
http in traffic analysis. However, there are a large number of http
handshake flows such as "SYN-SYN/ACK-ACK". These flows mean there is no
data, but strictly speaking, they should be regarded as http traffic
although they carry no data. However, Bro2.1 just view these kinds of
flows as tcp. Can users modify its default standard for http? I mean how
to modify the event trigger for a certain application service. For
example, if some user just want to use port number to trigger http traffic
analyzer, what should us users do? Is there any information for this
kinds of requirements?
Besides, I observe that Bro2.1 can only classify flows who can complete
three-way handshake successfully. If the flow is incomplete, Bro 2.1 do
nothing to try to identify application layer protocols. Is it possible
for us users to modify this?
Thank again!
Keqiang
However, there are a large number of http
handshake flows such as "SYN-SYN/ACK-ACK". These flows mean there is no
data, but strictly speaking, they should be regarded as http traffic
although they carry no data.
I don't agree that it should be regarded as HTTP traffic. Just because you have a wine glass doesn't mean it's full of wine. 
Typically the "service" field in the conn log is supposed to be understood as the protocol analyzer or analyzers that Bro used upon the connection successfully (since it can try analyzers and allow them to fail then remove them).
Besides, I observe that Bro2.1 can only classify flows who can complete
three-way handshake successfully. If the flow is incomplete, Bro 2.1 do
nothing to try to identify application layer protocols. Is it possible
for us users to modify this?
This is a known issue and something that we've been planning on addressing in a generic way soon so that the analyzers will be able to "re-sync" to the traffic. There is a ticket somewhere in our tracker about it.
.Seth
However, there are a large number of http
handshake flows such as "SYN-SYN/ACK-ACK". These flows mean there is no
data, but strictly speaking, they should be regarded as http traffic
although they carry no data.I don't agree that it should be regarded as HTTP traffic. Just because
you have a wine glass doesn't mean it's full of wine.Typically the "service" field in the conn log is supposed to be understood
as the protocol analyzer or analyzers that Bro used upon the connection
successfully (since it can try analyzers and allow them to fail then
remove them).Besides, I observe that Bro2.1 can only classify flows who can complete
three-way handshake successfully. If the flow is incomplete, Bro 2.1 do
nothing to try to identify application layer protocols. Is it possible
for us users to modify this?This is a known issue and something that we've been planning on addressing
in a generic way soon so that the analyzers will be able to "re-sync" to
the traffic. There is a ticket somewhere in our tracker about it..Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/
Hello, sorry to disturb you again. Do you know is there any document guiding
users to make http or https's identification just based on port number. In
other words, how to disable http and https signature matching function?
Bro does more than we expected, can we make his standard of judging http
and https weaker?
Here's a script that does what you want…
https://github.com/sethhall/bro-scripts/blob/master/conn-port-service.bro
.Seth
Bill Jones
I've got another question on DPD (or at least on the implementation).
For example, http://www.bro-ids.org/documentation/scripts/base/protocols/http/file-extract.html
adds ports to the DPD config. Does this mean that Bro only uses DPD on
traffic over those ports added to the ports list? If we want/know of
HTTP traffic over ports other than those we should add additional
ports to the list or does DPD just "figure things out"(tm) and do what
it does best on any port?
Thanks!
No, DPD has two operating heuristics. One heuristic which has been the focus of this thread is the port. The other heuristic is the signatures which current reside here:
http://git.bro-ids.org/bro.git/blob/HEAD:/scripts/base/frameworks/dpd/dpd.sig
Analyzers will be attached to connections with the dpd_config variable and by signatures (multiple analyzers can simultaneously receive the data). Typically if more than one analyzer are instantiated for a connection, one of them will fail and be removed from the connection.
Does that clarify things more? I think that what you want to happen is in fact what's happening.
.Seth
Thanks. You're correct, what I want to happen appears to be happening.
Is it a horrible idea to change the signatures? I was curious about
adding more client verbs in HTTP to detect webdav, and or adding an
additional http client sig that operates on UDP mostly for upnp
detection.
You could just write your own signatures (remembering that we don't recommend modifying scripts in base/) and load it in local.bro. I'll give an example…
In a file named localdpd.sig:
signature my_dpd_http_client {
ip-proto == tcp
payload /^[[:space:]]*(PUT)[[:space:]]*/
tcp-state originator
}
signature my_dpd_http_server {
ip-proto == tcp
payload /^HTTP\/[0-9]/
tcp-state responder
requires-reverse-signature my_dpd_http_client
enable "http"
}
Then in local.bro:
@loads-sigs ./localdpd.sig
If you find that some of your signature additions are valuable, then we would certainly be willing to integrate them into Bro. I think this provides us a good way of trying things out first. 
.Seth
Perfect, thanks!