Ubuntu server 18.04: suricata rule blocks dwservice, but not teamviewer or anydesk

Help
1

Hi,
I have a problem with suricata IDS/IPS. I’m using ubuntu server 18.04.5 with linux kernel 5.4.0 and suricata 3.2.
I’m just logging all the information without blocking any service. I found that suricata added two rules to my firewall:
-A iaccept -i eth0 -j NFQUEUE --queue-num 0
-A faccept -i eth0 -j NFQUEUE --queue-num 0
I would like to use the open source remote desktop service dwservice, but it does not work if I leave the first rule uncommented while both teamviewer and anydesk work well.
Otherwise, if I comment such rule, dwagent is not blocked and works well. I already contact the support of dwservice and they think that it could be something related to suricata.
Do you have any hint?
Thank you

2

Suricata 3.2 is no longer supported, and hasn’t been for a long time. I would suggest upgrading to 5.0.3 (using our PPA, or from source) and trying again.

3

Hi,
in order to add the repository, I had to disable the same rule otherwise the machine was not able to connect.
sudo add-apt-repository ppa:oisf/suricata-stable
After the upgrade to latest version 5.0.3, with the rule enabled even teamviewer and anydesk do not work, moreover even other services stopped to work (web server).
So is it the rule necessary?
Thank you

4

Hard to say. Did you enable the drop log facility in EVE? It should tell you more about what rules lead to what drop.

        - drop:
            alerts: yes      # log alerts that caused drops
            flows: all       # start or all: 'start' logs only a single drop
                             # per flow direction. All logs each dropped pkt.
5

No. Should I? I’m not expert of suricata
I have several machines with similar software component. Only in this particular machine, suricata has that rules that I do not remember to have added. So since the first rule is the origin of all problem, is it useful? Or I can just log the various event related to the different source of attack?

6

The rule you mention is no Suricata rule but a netfilter iptables rule. So if you remove it, packets passing that filter table won’t be forwaded to NFQUEUE and thus not to Suricata. So if you forward those packets there and see them blocked you need to check the drop section in the logs.

I would recommend reading this section: https://suricata.readthedocs.io/en/latest/setting-up-ipsinline-for-linux.html#setting-up-ips-with-netfilter

7

Right, so is suricata without that rule useless? Can you explain me why in different machine with the same OS and software components some have that rules and some not?
I checked and I did not add them.

8

I wouldn’t say useless but you need to ensure that the traffic you want to be inspected by Suricata is passed to Suricata. So in generall the recommendation is to use the -j NFQUEUE for all chains or at least for forward if you run it on a gateway.