Redefine const that does not have "&redef" attribute

I want to redefine Bro’s HTTP ports but I’m not having any luck…

The following code is in base/protocols/http/main.bro

const ports = {
81/tcp, 631/tcp, 1080/tcp, 8000/tcp, 8888/tcp,
redef likely_server_ports += { ports };

Here is what I’ve tried:

redef HTTP::ports = {
81/tcp, 631/tcp, 1080/tcp, 8000/tcp, 8888/tcp,

Which generates error “already defined (HTTP::ports)”… I also tried:

const custom_http_ports = {
81/tcp, 631/tcp, 1080/tcp, 8000/tcp, 8888/tcp,

redef HTTP::likely_server_ports += { custom_http_ports };

Which generates error ““redef” used but not previously defined (HTTP::likely_server_ports)”

A nudge in the right direction would be appreciated.


Without the &redef flag set, you can’t redefine a constant. You would have to modify Bro’s HTTP scripts in order to make the change you are trying to make. That is generally a bad idea.

I suspect that you’re trying to get Bro to detect HTTP on a non-standard port. If this is the case, then you are likely already analyzing the traffic, as Bro dynamically detects HTTP running on any port and analyzes it all the same. Try capturing the non-standard HTTP and running it through Bro to see if it finds it, I’ll bet that it does.

The signatures that enable the HTTP analyzer on non-standard ports are located at bro/scripts/base/protocols/http/dpd.sig ( ) . Don’t modify those either though.

If you truly have found an HTTP traffic pattern that Bro isn’t detecting, you should write a signature similar to these ones, and include ‘enable “http”’ like they have done here. Here’s a link to the documentation on signatures:

Let me know how it goes!

Thanks for the references and tips, that helps… But I’m actually trying to do the opposite - instead of getting more detection, I’m trying to get less. I want to exclude port 80 as our proxy has that covered (essentially causing duplication in SIEM)…

That helps a lot. There are a lot of ways to solve your problem.

If you want to not analyze this traffic at all, I’d go the route of dropping the traffic with either your tap aggregation tool or a bpf in Bro. This would have the benefit of not using resources on traffic you’re not interested in. Documentation here:

If you want to not log this traffic, but still analyze it, you can do this with log filters using the logging framework. The logging framework would also have the option of still logging the traffic, but logging it to a separate log. In this way, you could have pre-proxy-http.log and http.log (just for example). It’s incredibly flexible. Documentation here:

There are probably other ways to accomplish what you want… but those are just a couple. It’s possible someone else will chime in with better solutions.