Snort - rules update fails daily
-
So after leaving my pfSense box alone for a while, I went to the logs today and found the following…
Jul 21 01:05:07 php: snort_check_for_rule_updates.php: [Snort] There is a new set of Snort VRT rules posted. Downloading snortrules-snapshot-2973.tar.gz... Jul 21 03:13:22 php: snort_check_for_rule_updates.php: [Snort] Rules download error: SSL read: error:00000000:lib(0):func(0):reason(0), errno 54 Jul 21 03:13:22 php: snort_check_for_rule_updates.php: [Snort] Will retry in 15 seconds... Jul 21 03:13:37 php: snort_check_for_rule_updates.php: File 'snortrules-snapshot-2973.tar.gz' download attempts: 2 ... Jul 21 03:13:37 php: snort_check_for_rule_updates.php: [Snort] Snort VRT rules file download failed... server returned error '403'... Jul 21 03:13:37 php: snort_check_for_rule_updates.php: [Snort] The Rules update has finished.That bit of log entry has appeared every day since July 17. Manually trying to do the update doesn't seem to help much… it gets through anywhere between 25-50% of the download, stalls out, and sits there. I'm guessing that the same is happening overnight, causing the problem with updating.
The last successful rules update I had was July 15.
Additionally, the last time I had to reinstall the package (after updating to 2.2.3-RELEASE), it was a royal pain because the install process kept getting hung up at the downloading rules step. I had to manually disable the rule downloads in the config.xml in order to get Snort to reinstall, then re-enable them and experiment through the web gui to get the rules re-downloaded and installed. It took a LOT longer than it should have to get them installed and working because it would always stall somewhere between 25 and 50%. After a few attempts, I would need to restart php-fpm in order to regain access to the web gui.
Once in a while, I might hit a streak of luck and it'll download all the way through... but this is something that I would think should work properly a lot more often than it seems to be working.
I have a 150/10 cable connection through Comcast, so there shouldn't be any problems downloading the VRT rules in a very quick manner.
Any thoughts on how I can make the rules download process more reliable?
-
errno 54 is connection reset by peer and 403 is forbidden. Looks like you managed to get your IP temporarily banned.
-
The dok could be right. It might also be that for some strange reason Snort is triggering a block during the rules download. Look on the ALERTS tab and see if any alerts were triggered at the same time as the rule download, then look at the IP addresses alerted on to see if any match the Snort rules URLs.
I've only occasionally seen the odd failure to download rules, and it is usually due to issues at the VRT site. These are very rare, though. I can remember maybe like 2 or 3 times in an entire year.
Bill
-
Ok, so the connection reset error I understand… the download stalls, and eventually the connection/state expires, whether on pfSense or on the server side. But the fact that I get a 403 error on the second attempt is very unusual. Why would I not get a 403 the first time then? Maybe it's related to the time I'm checking? Possible daily server maintenance tasks? I changed the time of the automatic update check just to see if that changes anything.
Snort isn't blocking anything... No new alerts during the update period.
Last night at about 10p Eastern I was able to get it to download the update manually... it took three attempts at the manual update process. The first time hung at between 15-20%, the second time at about 70%, and the third time it completed.
I guess I'm just trying to figure out why the rules download stalls in the first place, and with amazing regularity too. It ends up affecting pfSense updates as well (since the package reinstall includes downloading the rules file) so it's something I'd like to get figured out. Any way to turn on some additional debugging or logging of the update process?
-
I honestly don't think the Snort package is at issue here. If it was, then I would expect many complaints here of similar nature. My personal experience is that you do generally want to avoid the period around midnight U.S. Eastern Time. I would frequently encounter errors then on the nightly downloads. I moved the update time to 0130 Eastern and no more issues. I suspected the VRT folks had some kind of server maintenance task running at midnight, but that was just a guess.
Since you have problems even with manual downloads, I would look at other basic connectivity problems somewhere. Is there anything else in the chain like a proxy (Squid perhaps?), another upstream firewall, etc.?
Bill
