ntop / nProbe

Open source components and extensions for nProbe

Home Page:http://ntop.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

nProbe IPS: block traffic by FQDN

dimalev01 opened this issue · comments

Hello ,

Is it possible to block traffic for specific fqdn's with nprobe in traffic policies?
We tried to do it in "Host Rules" but it doesn't work.

Br ,

Dima Lev.

ntopng seems to propagate the policy to nProbe as expected:

{"policy":{"id":3,"default_marker":"pass","markers":{"continents":[],"categories":[],"countries":[],"hostnames":{"test.com":"drop"},"protocols":[]},"name":"Pool 2 rules","flow_risk":{"marker":"drop","bitmap":0},"root":0}}

we need to check on the nProbe side if this is honoured

We will wait for your update.

@dimalev01 sure this is in queue, I will update you as soon as we complete the tests

Can you please report your netfilter configuration? I would like to check whether the problem is due to netflter or nprobe.

Can you please try again as see no netfilter configuration (please also add the ifconfig configuration and explain what interface does what)

Any updates?

ntopng seems to propagate the policy to nProbe as expected:

{"policy":{"id":3,"default_marker":"pass","markers":{"continents":[],"categories":[],"countries":[],"hostnames":{"test.com":"drop"},"protocols":[]},"name":"Pool 2 rules","flow_risk":{"marker":"drop","bitmap":0},"root":0}}

we need to check on the nProbe side if this is honoured

@cardigliano I know this is an old issue, so maybe this is already known.

It appears the output you put has improper nesting when compared to the documentation. The "hostnames" is outside of "markers" in the documentation. Maybe ntopng is pushing the policy to nprobe incorrectly. This worked for me once I moved that, though I noticed the matches are explicit (e.g. google.com would only block google.com, and not www.google.com; wildcards didn't work).

@l0crian1 hostnames should be inside markers, we just released an update that fixes this.
As of the wildcards, they are not currently supported for hosts defined under "hostnames" (they are supported when using the protos or categories definitions), however we are working for supporting them, I will update the issue once ready.

Thanks @cardigliano! Quick question on both methods for host filter (definitions and rules syntax), is it just blocking DNS requests with those (sub)domains, or will it also block on the CN in a certificate?

It detects the hostname from any supported protocol, it includes DNS, HTTP, TLS CN