SNORT - FATAL ERROR! Unable to process the IP address:

humps

Hi All I'm running Pfsense 2.1 (x64) with Snort 2.9.4.6 pkg v. 2.6.0.
Pfsense and snort have been running good up until yesterday when some signature updates came in for Snort from ET and GPL Community Rules Repository and crashed it! :(

Each time i try to start snort it says "Fatal Error! Unable to process the IP address:
[94.102.58.13,94.103.36.55,94.199.200.160,95.55.177.157,96.127.169.2,98.131.185.136]".

When i check the System Logs and check the "snort.rules" (/usr/pbi/snort-amd64/etc/snort/snort_64427_em0/rules/snort.rules(724)) i found out that its one rule that is causing it to crash;

See rule (suspected to be causing the issue) below:

alert tcp $HOME_NET any -> [94.102.58.13,94.103.36.55,94.199.200.160,95.
55.177.157,96.127.169.2,98.131.185.136 ] any (msg:"ET CNC Zeus Tracker Reported
CnC Server TCP (group 25)"; flags:S; reference:url,doc.emergingthreats.net/bin/v
iew/Main/BotCC; reference:url,zeustracker.abuse.ch; threshold: type limit, track
by_src, seconds 3600, count 1; classtype:trojan-activity; flowbits:set,ET.Evil;
flowbits:set,ET.BotccIP; sid:2404198; rev:3240;)

See System Log below:

Oct 16 11:21:58 php: /snort/snort_download_rules.php: [Snort] EmergingThreats rules file update downloaded successfully
Oct 16 11:21:59 php: /snort/snort_download_rules.php: [Snort] Updating rules configuration for: ISP1 …
Oct 16 11:22:01 php: /snort/snort_download_rules.php: [Snort] Building new sig-msg.map file for ISP1…
Oct 16 11:22:01 php: /snort/snort_download_rules.php: [Snort] Updating rules configuration for: LAN …
Oct 16 11:22:03 php: /snort/snort_download_rules.php: [Snort] Building new sig-msg.map file for LAN…
Oct 16 11:22:03 php: /snort/snort_download_rules.php: [Snort] Updating rules configuration for: ISP2 …
Oct 16 11:22:05 php: /snort/snort_download_rules.php: [Snort] Building new sig-msg.map file for ISP2…
Oct 16 11:22:05 php: /snort/snort_download_rules.php: [Snort] The Rules update has finished.
Oct 16 11:22:23 SnortStartup[75401]: Snort START for ISP1 WAN INTERNET(64427_em0)…
Oct 16 11:22:23 snort[75641]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_64427_em0/rules/snort.rules(724) Unable to process the IP address: [94.102.58.13,94.103.36.55,94.199.200.160,95.55.177.157,96.127.169.2,98.131.185.136.
Oct 16 11:22:25 SnortStartup[76417]: Snort START for COMPANY LAN(46633_re0)…
Oct 16 11:22:26 snort[76605]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_46633_re0/rules/snort.rules(507) Unable to process the IP address: [94.102.58.13,94.103.36.55,94.199.200.160,95.55.177.157,96.127.169.2,98.131.185.136.
Oct 16 11:22:28 SnortStartup[77513]: Snort START for ISP2 WAN INTERNET(52789_rl0)…
Oct 16 11:22:28 snort[77592]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_52789_rl0/rules/snort.rules(724) Unable to process the IP address: [94.102.58.13,94.103.36.55,94.199.200.160,95.55.177.157,96.127.169.2,98.131.185.136.

How can i disable this One troublesome rule/signature, i need to start Snort and i cant afford for one rule to be stopping it from start.

Any Help Appreciated
Thanks in advance

Supermule

Update the rules and its fine again!

humps

@Supermule:

Update the rules and its fine again!

Hey Thanks much i updated the rules and manually start Snort and it worked! :)
The funny thing is that i did the same thing (update rules) and try start Snort manually this morning and it didn’t work!
Also sid:2404198 that was causing the issue is now missing from the rules in "emerging-botcc.rules"
Guess the update fixed whatever issue it had

Thanks Again

bmeeks

@humps:

@Supermule:

Update the rules and its fine again!

Hey Thanks much i updated the rules and manually start Snort and it worked! :)
The funny thing is that i did the same thing (update rules) and try start Snort manually this morning and it didn’t work!
Also sid:2404198 that was causing the issue is now missing from the rules in "emerging-botcc.rules"
Guess the update fixed whatever issue it had

Thanks Again

Don't know what happened exactly, but the Emerging Threats folks had multiple syntax errors in their emerging-botcc file. The problems started late yesterday (Tuesday) and continued until late Wednesday afternoon when everything was finally fixed. This issue impacted their paid ETPro rules as well. The issue was with their rules update itself. And since it was a rules file problem, everybody's setup broke as soon as they updated Emerging Threats rules.

The first problem was in the very first two rules in the file. The list of IP addresses in the brackets [] had spaces after each comma. That's a no-no for Snort. The second problem was way down in the file with one of the Zeus tracker rules. There was a space between the last IP address and the closing bracket. Snort is very picky about rule syntax. I am talking about the underlying binary file itself and not the GUI interface.

Bill

Nadrek

I also found this out by checking my firewall, and seeing that SNORT had simply stopped.

May I suggest one of the following options as a worthwhile SNORT update? 1 is the best, downhill from there.

Whenever it's time to update rules
1a) Check new rules (already)
1b) Download changes (already)
1c) Back up the existing rules (new?)
1d) Test new rules (new)
1e) For each ruleset that failed, rollback to the backup for that ruleset from 1c)
Whenever loading a new/updated ruleset
2a) BEFORE loading and restarting the new ruleset, test the parsing of each line. Any lines failing get a big warning on the main SNORT page and in the system log, and are disabled/commented out/whatever (and the previous state is marked)
2b) The next time any failed line is updated, repeat the testing. If it passes parsing, then set it to whatever state it was in before the failure to parse, or the default state if it was a new rule.
Whenever a ruleset fails
3a) Disable the ruleset and throw a big red warning on the main SNORT page and in the system log, then repeat.
Note that as an ET + GPL ruleset user, I feel that losing one ruleset is still more protection than losing every ruleset.
3b) The next time any failed ruleset is updated, get the new one, re-enable the ruleset to whatever state it was in before, and try again.

bmeeks

@Nadrek:

I also found this out by checking my firewall, and seeing that SNORT had simply stopped.

May I suggest one of the following options as a worthwhile SNORT update? 1 is the best, downhill from there.

Whenever it's time to update rules
1a) Check new rules (already)
1b) Download changes (already)
1c) Back up the existing rules (new?)
1d) Test new rules (new)
1e) For each ruleset that failed, rollback to the backup for that ruleset from 1c)

Whenever loading a new/updated ruleset
2a) BEFORE loading and restarting the new ruleset, test the parsing of each line. Any lines failing get a big warning on the main SNORT page and in the system log, and are disabled/commented out/whatever (and the previous state is marked)
2b) The next time any failed line is updated, repeat the testing. If it passes parsing, then set it to whatever state it was in before the failure to parse, or the default state if it was a new rule.

Whenever a ruleset fails
3a) Disable the ruleset and throw a big red warning on the main SNORT page and in the system log, then repeat.
Note that as an ET + GPL ruleset user, I feel that losing one ruleset is still more protection than losing every ruleset.
3b) The next time any failed ruleset is updated, get the new one, re-enable the ruleset to whatever state it was in before, and try again.

I agree these are some great ideas, but there are some substantial limits on what the Snort GUI can do. You see, the real guts of the Snort package is the raw binary from snort.org. All the Snort package on pfSense really does is provide a GUI for creating the snort.conf file. It is not responsible for anything related to actually detecting or blocking intrusions. So with that limitation in mind, you see there is only a little bit the GUI package code can do in this regard.

Bill

Nadrek

@bmeeks:

@Nadrek:

I also found this out by checking my firewall, and seeing that SNORT had simply stopped.
3) Whenever a ruleset fails
3a) Disable the ruleset and throw a big red warning on the main SNORT page and in the system log, then repeat.
Note that as an ET + GPL ruleset user, I feel that losing one ruleset is still more protection than losing every ruleset.
3b) The next time any failed ruleset is updated, get the new one, re-enable the ruleset to whatever state it was in before, and try again.

I agree these are some great ideas, but there are some substantial limits on what the Snort GUI can do. You see, the real guts of the Snort package is the raw binary from snort.org. All the Snort package on pfSense really does is provide a GUI for creating the snort.conf file. It is not responsible for anything related to actually detecting or blocking intrusions. So with that limitation in mind, you see there is only a little bit the GUI package code can do in this regard.

Bill

That's a limitation indeed - would it be possible for the GUI to detect (parse the system log, perhaps) a failure to start SNORT, figure out which ruleset it was, and then change the snort.conf file to disable that ruleset while recording the hash of it, and when the hash changes, re-enable and then process normally (including, again, the disable on crash due to ruleset)?

bmeeks

@Nadrek:

That's a limitation indeed - would it be possible for the GUI to detect (parse the system log, perhaps) a failure to start SNORT, figure out which ruleset it was, and then change the snort.conf file to disable that ruleset while recording the hash of it, and when the hash changes, re-enable and then process normally (including, again, the disable on crash due to ruleset)?

No, the GUI can't do this except during manual rule updates. See, the GUI code is not even running once you leave the Snort menus. All those web page sessions in the GUI are essentially stateless. When you exit the page or browse to another menu, that former PHP GUI process shuts down. The automatic rule updates are done entirely via a cron job. Trying to figure out which rule failed is a big effort. I just don't think that is practical. After all, this problem with a corrupted rules file has only happened once in the year I have been quasi-maintaining the Snort package.

A better solution is for someone to create a service monitoring package for pfSense. You could load it with the services you want monitored, and then on some interval it could canvass the running processes (services) to see what is and is not running. It could either attempt a restart of dead services, or raise an alert or alarm if one won't restart. Maybe something like this exists and I'm just not aware of the package?

Bill