Snort fails to start with ETOpen rules after update
-
This might have nothing to do with the updated, but I had a fully working snort with ETOpen Rules, Snort Community and Snort VRT rules. Following the update Snort fails to start with the following errors:
Apr 9 12:23:52 snort[99331]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_39243_em0/rules/snort.rules(8355) : pcre compile of "(obj.data|\object.data).+file\x3A\x2F\x2F127\x2E[0-9]" failed at offset 11 : missing opening brace after \o
Apr 9 12:23:52 php: /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 39243 -D -q -l /var/log/snort/snort_em039243 –pid-path /var/run --nolock-pidfile -G 39243 -c /usr/pbi/snort-i386/etc/snort/snort_39243_em0/snort.conf -i em0' returned exit code '1', the output was ''Disabling ETOpen fixes the problem, so it definitely has something to do with ETOpen rules.
Is this a bug in snort, ETOpen rules or.. ?
-
This might have nothing to do with the updated, but I had a fully working snort with ETOpen Rules, Snort Community and Snort VRT rules. Following the update Snort fails to start with the following errors:
Apr 9 12:23:52 snort[99331]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_39243_em0/rules/snort.rules(8355) : pcre compile of "(obj.data|\object.data).+file\x3A\x2F\x2F127\x2E[0-9]" failed at offset 11 : missing opening brace after \o
Apr 9 12:23:52 php: /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 39243 -D -q -l /var/log/snort/snort_em039243 –pid-path /var/run --nolock-pidfile -G 39243 -c /usr/pbi/snort-i386/etc/snort/snort_39243_em0/snort.conf -i em0' returned exit code '1', the output was ''Disabling ETOpen fixes the problem, so it definitely has something to do with ETOpen rules.
Is this a bug in snort, ETOpen rules or.. ?
I am receiving a very similar error but I believe it is my RAM size. It appears that the new version of Snort uses more base RAM leaving less for all my rules. I was able to start Snort with no ET rules and with some of what I was using prior to this version. As I add more categories, RAM usage goes up. Hope this helps.
EDIT: My initial assessment appears to be incorrect. I have pinpointed the problem down to the ETOpen category "emerging-web_client.rules". Disabling this category allows Snort to start and I still have 250MB of unused RAM. Since this category only has about 200 rules, I doubt that RAM is the issue. Apologies if I pointed you in the wrong direction.
-
Like the error says, there's an issue with one of the rules. Snort is really picky about textual errors in the rules files.
-
@Pummel, was quite sure that was not the case as my box has 2GB ram and is using less than 30%
So what is the solution? Just disable emerging-web_client.rules until this is fixed?
-
Disable the rule until it's fixed. This is up to ET to do.
-
Thanks for this thread, I was able to get my snort back up and running after disabling the ET ruleset. Anyone figure out which rule it was specifically?
-
I have boxes with ET PRO and ET OPEN and neither seem to be having this issue?
However.
Using this error as an example
Apr 9 12:23:52 snort[99331]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_39243_em0/rules/snort.rules(8355) : pcre compile of "(obj.data|\object.data).+file\x3A\x2F\x2F127\x2E[0-9]" failed at offset 11 : missing opening brace after \o
Apr 9 12:23:52 php: /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 39243 -D -q -l /var/log/snort/snort_em039243 –pid-path /var/run --nolock-pidfile -G 39243 -c /usr/pbi/snort-i386/etc/snort/snort_39243_em0/snort.conf -i em0' returned exit code '1', the output was ''Open up the shell and use
vi /usr/pbi/snort-i386/etc/snort/snort_39243_em0/rules/snort.rules
and comment out line 8355
(in vi, click ":" and "8355" will bring you to that line.That should be the rule that is failing. The folder path will be different for each person.
-
I believe this problem has been corrected by the ET OPEN team. I can no longer reproduce the error with ET OPEN WEB CLIENT rules.
Bill
-
I have been following Fragged's advice and waiting for ET to fix this. I have not done any editing of the files. I was hoping this would be fixed by the ET Open group as Bill mentioned. I have been monitoring the updates and have seen several since the error first started occurring. Based on the what I am seeing, this issue has not been fixed. Each time ET has updated the file I have re-enabled (emerging-web_client.rules) and each time I am still getting:
snort[86149]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_34714_bge0/rules/snort.rules(9228) : pcre compile of "(obj.data|\object.data).+file\x3A\x2F\x2F127\x2E[0-9]" failed at offset 11 : missing opening brace after \o
However, reading the previous posts, the offending line keeps changing. Here it is 9228, however previous failures are at 9173, 9106, 9324, 9333, etc… Which is understandable.
My concern is whether commenting out the offending line is a "fix"or just a "band-aide" until the next update comes along?
Is there a process to purge the Snort rules and/or force them to reload?Rick
-
Hi Rick,
ET is adding and removing rules on a daily basis, you shouldn't be looking at line numbers and expect them to be consistent across rule updates.
This could vary well be the same rule that is failing on each rule update/restart.
Try to go to a shell terminal and vi that rule file and see what rule this actually is. Disable that particular rule and then see if the issue re-occurs.
-
I have been following Fragged's advice and waiting for ET to fix this. I have not done any editing of the files. I was hoping this would be fixed by the ET Open group as Bill mentioned. I have been monitoring the updates and have seen several since the error first started occurring. Based on the what I am seeing, this issue has not been fixed. Each time ET has updated the file I have re-enabled (emerging-web_client.rules) and each time I am still getting:
snort[86149]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_34714_bge0/rules/snort.rules(9228) : pcre compile of "(obj.data|\object.data).+file\x3A\x2F\x2F127\x2E[0-9]" failed at offset 11 : missing opening brace after \o
However, reading the previous posts, the offending line keeps changing. Here it is 9228, however previous failures are at 9173, 9106, 9324, 9333, etc… Which is understandable.
My concern is whether commenting out the offending line is a "fix"or just a "band-aide" until the next update comes along?
Is there a process to purge the Snort rules and/or force them to reload?Rick
I have the ET-OPEN Web Client rules enabled in a VM and am not seeing a problem using the "default enabled" sets of rules. By that I mean I just enabled the category, but then left the individual rules within the category at their defaults (the ones ET sent as enabled are enabled, and the ones they sent as disabled are disabled). Are you guys having problems enabling ALL the rules in the category?
EDIT: Ok, I tried enabling all the rules in the category and the problem is with the rule having SID 2011695. Here is the complete rule text –
#alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Possible Microsoft Internet Explorer Dynamic Object Tag/URLMON Sniffing Cross Domain Information Disclosure Attempt"; flow:established,to_client; content:"obj"; nocase; content:"data"; nocase; within:10; content:"file|3A|//127."; nocase; within:20; pcre:"/(obj.data|\object.data).+file\x3A\x2F\x2F127\x2E[0-9]/si"; reference:url,tools.cisco.com/security/center/viewAlert.x?alertId=19873; reference:url,tools.cisco.com/security/center/viewAlert.x?alertId=20610; reference:url,www.microsoft.com/technet/security/bulletin/ms10-035.mspx; reference:url,www.coresecurity.com/content/internet-explorer-dynamic-object-tag; reference:cve,2010-0255; reference:url,doc.emergingthreats.net/2011695; classtype:attempted-user; sid:2011695; rev:4;)So for now, go to the RULES tab, select the ET Web Client category, and make sure SID 2011695 is disabled. It is disabled by default, so the only folks likely seeing the error are those that have forced this rule to the "enabled" state. Has anyone logged this with the Emerging Threats team?
Bill
-
I contacted one of the Emerging Threats guys offline and supplied him with the errant rule. He promised to get it fixed. SID 2011695 does indeed have an improper regular expression (pcre) in it.
Bill
-
Thanks Bill. I knew there had to be more to it.
I'm just surprised the ET team hadn't more complaints before you brought it up to them.rick
-
Thanks Bill. I knew there had to be more to it.
I'm just surprised the ET team hadn't more complaints before you brought it up to them.rick
So was I. I Googled the error first and found only one other post about it with a commercial firewall using the ET OPEN rules. They were advising their users to disable that particular SID. It could be that because the rule is by default disabled, and many folks don't customize the rule categories very much, this error was going unnoticed. I am one of those folks who generally take the defaults with the rule packages (on my home firewall anyway), and so I had not seen the error.
I have a quasi-business relationship with one of the ET guys, and so I dropped him a note detailing the error. He responded back rather quickly and acknowledged the error. It may take them a day or two to get it fixed.
Bill
-
Well, it looks like the ET team still hasn't fixed this. Funny that this is an IE exploit based rule and with all the recent uproar over IE…. coincidence or conspiracy? :-X
Rick
-
Well, it looks like the ET team still hasn't fixed this. Funny that this is an IE exploit based rule and with all the recent uproar over IE…. coincidence or conspiracy? :-X
Rick
I'm surprised. I have not retested since my last post, though. The gentleman I corresponded with is quite high up in the ET management hierarchy, and he acknowledged the problem with the pcre in the rule. He did say he was, at that time, on the road. He may still be out of the office.
Bill
-
I'm surprised. I have not retested since my last post, though. The gentleman I corresponded with is quite high up in the ET management hierarchy, and he acknowledged the problem with the pcre in the rule. He did say he was, at that time, on the road. He may still be out of the office.
Bill
Bill, he's either on a real long trip or forgot your conversation. It's still broken. :(
Rick
-
I'm surprised. I have not retested since my last post, though. The gentleman I corresponded with is quite high up in the ET management hierarchy, and he acknowledged the problem with the pcre in the rule. He did say he was, at that time, on the road. He may still be out of the office.
Bill
Bill, he's either on a real long trip or forgot your conversation. It's still broken. :(
Rick
Sorry. I don't know if he forgot or if they decided that since the rule was default disabled anyway, to let it slide. I think there is a link for support on the Emerging Threats web site. You can give that a try if you like. Maybe you will have better luck than I did.
Bill
