Timeout Error when running suricata-update while suricata ips is active

Help
, , ,
1

Hi,

I am using Suricata (version 6.0.1 on Debian 11) as IPS in connection with nftables.
It is working greatly!

However, when I run suricata-update while suricata is running, downloading of the rulesets doesn’t work (anymore?). I get the following error: <Error> -- Failed to copy file: The read operation timed out . The download stops somewhere between 85% and 99% of the first ruleset (which is a different one each time).
I found out that this doesn’t happen if suricata is stopped. Hence, there seems to be some rule or some configuration in suricata that hinders suricata-update from updating the rules while suricata is running. In the fast.log, I don’t see any event at the time when I run suricata-update.

What could be the reason? How can I find out which rule is blocking suricata-update?

Furthermore, I wonder how frequently I need to run suricata-update…? Is there any recommendation?

2

First of all 6.0.1 is kinda old, so I would recommend to the last stable version first.

Also share your config and stats.log, there can be several non rule related reasons. Or you could do a test run without any rules loaded.

The rules update should run at least daily, since for example the ET rules are updated mostly every day.

3

Thanks for the reply!
I have now upgraded suricata to version 6.0.8 from the bullseye-backports.
Since the stats.log file is too big to upload it, I have uploaded my suricata configuration and the stats.log and suricata.log files onto 101.89 MB folder on MEGA .
I have also tested it without loading any rules (I commented out the suricata.rules line in the yaml file). The issue remains nevertheless. Hence, it is not rule dependent.

What can I do to troubleshoot?

4

thanks for the awesome information.

5

I have the same problem. I run a hardened ubuntu server as my firewall (iptables) and use NFQUEUE to inject into my ips. I finally just whitelisted the servers (that I get rules from) in iptables before getting to the NFQUEUE rule. It also doesn’t always fail, but when it does it’s around 98-99%. I’m also on 6.08, but have had this issues since I was running 5.0.X versions. It doesn’t log anything in fast.log , I suspected the anomaly detection, but I have not ‘put my finger on it’.

1 Like
6

Good idea with the whitelisting. I will try that.
However, this is only a workaround of course …

7

I have still problems to find out the IP addresses of the sources from which suricata-update loads the rules…
@engdude Which IP addresses have you whitelisted ?

8

It depends which sources you have enabled. I use:

sslbl.abuse.ch
abuse.ch
security.etnetera.cz
openinfosecfoundation.org
rules.emergingthreats.net

I then have a script that runs daily to update the IP address
( something like)
for I in $LIST
do
dig -4 +short $I | grep -v ‘.$’ >>$IP_LIST
done

1 Like
9

ok. I see. I thought there is some way without extra script…
But thanks!