Snort fails to start with ETOpen rules after update
-
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
