Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list (SOLVED)

[zgtc]

@steveits said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

@zgtc What does View List show?

It shows the IPs for the default pass list

[zgtc]

@steveits said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

I have not tried the new feature to add IPs in Suricata. In the past we set up an alias, then put the alias in a Suricata pass list

I tried to add the IPs to the Firewall aliases, but got this message.
162.125.0.0/16
108.160.160.0/20
I don't expect to have to expand the whole range of IPs...

[SteveITS]

@zgtc The pass list in your message shows "default" is selected and you'd need to select "dropbox" to pick up your aliases, then restart Suricata on the interface.

When editing a pass list the "Auto-Generated IP Addresses" checkboxes basically comprise the default list.

Are you creating your alias as type Network? It works for me:

[zgtc]

@steveits OK I selected the custom list and restarted the service on the interface, you are right, it mixes the default + custom IPs

But Dropbox is still being blocked

[zgtc]

@zgtc OK, sorry. I restarted the whole service and then the computer that runs the dropbox daemon. It now works!

Well it logs in to the dropbox account, but still does not sync the files. Weird.

Thank you so much for the help anyway. Will keep trying.

[SteveITS]

@zgtc You're sure it wasn't blocked from before?

At any rate these are all Dropbox IPs? You could disable the Dropbox rule. I'm trying to remember what the X in a yellow circle icon is, normally it's a red X to disable the rule. Then it doesn't bother checking the rule at all, and doesn't need to run every packet through those entries on the pass list either.

The maintainer has posted in other threads but "policy" and "info" rulesets are intended more for informational tracking and not necessarily a list of things to block.

[zgtc]

@steveits said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

@zgtc You're sure it wasn't blocked from before?

These rules were red before, I clicked the red X and then they were converted into the yellow background X.

At any rate these are all Dropbox IPs? You could disable the Dropbox rule. I'm trying to remember what the X in a yellow circle icon is, normally it's a red X to disable the rule. Then it doesn't bother checking the rule at all, and doesn't need to run every packet through those entries on the pass list either.

The maintainer has posted in other threads but "policy" and "info" rulesets are intended more for informational tracking and not necessarily a list of things to block.

I really dont understand. In theory, if I understood correctly, you can manually remove a rule but clicking those red X in the Alerts list. But even if that was not the method, adding the IPs as I did with your help should be enough, no?

I'm lost :)

[SteveITS]

@zgtc If you're new to Suricata consider turning off blocking and just monitor Alerts until you weed out the incorrect ones. :) Then enable blocking later.

If you hover over the icons it will tell you what it will do:

If clicked this would disable the rule and it won't trigger anymore. A disabled rule isn't checked at all, saves CPU.

If the IP had already been blocked it would still be on the Blocked tab from that prior blocking, until it expires and is automatically removed.

[zgtc]

@steveits said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

@zgtc If you're new to Suricata consider turning off blocking and just monitor Alerts until you weed out the incorrect ones. :) Then enable blocking later.

As a last resort I will, of course. But I'd like to understand how the system works.

If you hover over the icons it will tell you what it will do:

If clicked this would disable the rule and it won't trigger anymore. A disabled rule isn't checked at all, saves CPU.

You are suggesting in the capture that I should click the red cross to force disable a rule. This is what I did in the first place, and that is why the rules show a yellow cross instead, as we have mentioned above.

If the IP had already been blocked it would still be on the Blocked tab from that prior blocking, until it expires and is automatically removed.

Weirdly enough, the block list is not updated in the past 30 min, since I added the custom pass, but Dropbox still won't sync.

Thank you again for your patience

[zgtc]

@zgtc This is getting even more weird. I disabled the IPS:

Then restarted both the interface service and the whole suricata daemon, and I still get blocks in the firewall logs!

Will try stopping the whole daemon instead...

Same even with daemon stopped. I don't really understand it.

[SteveITS]

@zgtc Depending on timing the IP may still be in the blocked table? Suricata puts the IP in the table and then later removes it. pf blocks the IP because of the (hidden/internal) rule using that table. So ensure the Blocks tab is empty.

or possibly https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html

[bmeeks]

Suricata blocks in Legacy Mode by adding IP addresses to a special hidden pf table called snort2c. Any IP address placed in that table is blocked by the firewall. The IP remains in the table until one of three things happen:

1. the admin manually deletes the block using the option next to the IP on the BLOCKS tab;
2. the periodic cron task (if enabled) removes the IP from the table after a set period of no further activity from that IP;
3. or the firewall is rebooted. This clears the table because it is a RAM construct.

You need to use the BLOCKS tab to see what IPs are currently in the table and thus are being blocked. You can clear the entire table, or remove specific IP addresses using the icons and buttons on that tab.

Stopping or restarting the Suricat daemon has zero impact on the content of the snort2c table, thus it will not remove an existing block.

[zgtc]

@steveits said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

@zgtc Depending on timing the IP may still be in the blocked table? Suricata puts the IP in the table and then later removes it. pf blocks the IP because of the (hidden/internal) rule using that table. So ensure the Blocks tab is empty.

@bmeeks said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

Suricata blocks in Legacy Mode by adding IP addresses to a special hidden pf table called snort2c. Any IP address placed in that table is blocked by the firewall. The IP remains in the table until one of three things happen:

1. the admin manually deletes the block using the option next to the IP on the BLOCKS tab;
2. the periodic cron task (if enabled) removes the IP from the table after a set period of no further activity from that IP;
3. or the firewall is rebooted. This clears the table because it is a RAM construct.

You need to use the BLOCKS tab to see what IPs are currently in the table and thus are being blocked. You can clear the entire table, or remove specific IP addresses using the icons and buttons on that tab.

Stopping or restarting the Suricat daemon has zero impact on the content of the snort2c table, thus it will not remove an existing block.

OK, NOW it started sync'ing! Thank you so much both of you. Man I am so stupid, the Blocks list was always there, I simply didn't think about removing the items. That's in part why I was asking how to make the Pass list more relevant to the Blocks list.

In any case, next question. I disabled all Dropbox related items from the ET Policy file, then removed the items from the block list:

Then restarted the service in the LAN interface... And the Offsite File Backup in use still gets added again to the Blocks list.

And of course blocked by the Firewall

I don't get it.

[bmeeks]

One other possibility is that you have a duplicate Suricata process running on the same interface. If so, that instance would not honor any Pass List changes.

Run this command from a shell prompt on the firewall:

ps -ax | grep suricata

See if it shows any duplicate interfaces. If so, go to the GUI and stop all Suricata instances. Then return to the shell prompt, run the command above again, and if any Suricata processes remain kill them with this command:

kill -9 <pid>

where <pid> is the Process ID of the remaining Suricata process.

You also need to validate that Suricata has actually loaded your Pass List. Go to the LOGS VIEW tab and choose the suricata.log file for the interface. Look through that log and be sure it shows your Dropbox IP networks being added during startup.

[zgtc]

@bmeeks said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

One other possibility is that you have a duplicate Suricata process running on the same interface.

YOU NAILED IT! I would have never guessed by myself, thank you so much!

You also need to validate that Suricata has actually loaded your Pass List. Go to the LOGS VIEW tab and choose the suricata.log file for the interface. Look through that log and be sure it shows your Dropbox IP networks being added during startup.

That part was OK, but thank you again

[zgtc]

Is there a way to edit the title and mark the thread as SOLVED?

[bmeeks]

@zgtc said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

Is there a way to edit the title and mark the thread as SOLVED?

I believe as the creator of the topic you can do that. Go back to your original first post in this thread and click the little 3-dot vertical ellipsis icon on the bottom right corner (next to the thumbs-up icon). When the edit window for the post opens, I think you can edit the title then.

[zgtc]

@bmeeks mmm I think there's a time limit for this

[bmeeks]

@zgtc said in Suricata 6.0.4_1 blocking Dropbox IPs even in the pass list:

@bmeeks mmm I think there's a time limit for this

Oh...did not realize that. I've edited some of my own titles in the past, but guess I just happened to be within the time window.

But, I tried as the moderator of this sub-forum and it let me change it for you! Did not realize I had that power (or at least have never tried it out).

[zgtc]

@bmeeks thank you! I wanted to have Solved in the title because my original problem will probably happen to more people.