Snort blocking with disabled rule

[awsiemieniec]

System: 2.0.3-RELEASE (amd64)
Package: snort 2.9.4.6 pkg v. 2.5.9

Working on streamlining snort…. still.  I have disabled the following rule:
2000419 ET POLICY PE EXE or DLL Windows file download
but I am still seeing blocked entries with this as the reason.  If a rule is disabled, that means snort isn't checking for that threat, correct?  Am I missing something?

Any ideas?

Thanks.

[A Former User]

Have you restarted the interface after you disabled that rule? Services>snort>click the green arrow and wait until it becomes red, click it again and wait for it to become green.
Check blocked tab just in case the host gets banned under another rule and you didn't notice it.

EDIT:
Just noticed this today on my systems. I had that rule disabled and suppressed as well and thought it was a mistake on my part. Removed the suppression and the rule started firing when updating workstations later in the evening. I'm guessing that this is a bug with snort. I found that if disabled, it also needs a suppression to keep it from firing up.

[awsiemieniec]

Thanks, jflsakfja, for the info.

Yes, I did restart the interface and it didn't help, then restarted the whole system and it didn't help.  I'll add suppression for this rule.  Good idea.  Thanks for the assistance you've been posting.

[bmeeks]

@jflsakfja:

EDIT:
Just noticed this today on my systems. I had that rule disabled and suppressed as well and thought it was a mistake on my part. Removed the suppression and the rule started firing when updating workstations later in the evening. I'm guessing that this is a bug with snort. I found that if disabled, it also needs a suppression to keep it from firing up.

I will have a look at this in the code.  Disabling the rule should be sufficient.  There was a problem about two package revisions ago with the rule disable code, but I fixed it.  Hope the problem didn't slip back in.  I hate regression bugs… >:(

Bill

[bmeeks]

@awsiemieniec:

System: 2.0.3-RELEASE (amd64)
Package: snort 2.9.4.6 pkg v. 2.5.9

Working on streamlining snort…. still.  I have disabled the following rule:
2000419 ET POLICY PE EXE or DLL Windows file download
but I am still seeing blocked entries with this as the reason.  If a rule is disabled, that means snort isn't checking for that threat, correct?  Am I missing something?

Any ideas?

Thanks.

Can you check and report back on the following to help me troubleshoot this?

Login to the firewall console and navigate to the directory for the Snort interface.  It should be /usr/local/etc/snort/ and then a subdirectory under this one with the interface physical NIC driver in the name (such as "em0" for an Intel NIC).  In that interface sub-directory will be a rules subdirectory.  You should see two files in that sub-directory:  snort.rules and flowbit-required.rules.

Use this command to search the snort.rules file for the SID.  It should not find the SID in the file if it was properly disabled by the code.

grep 2000419 snort.rules

Assuming the first command comes up empty, then repeat on the flowbit-required.rules file and see if the SID shows up in there.  My theory is perhaps the auto-flowbit rule logic is coming along and enabling the rule again due to a flowbit dependency.  Right now the flowbit logic is not cross-checking to be sure the rule is not manually disabled.  Please post back with your findings.

Thanks,
Bill

[A Former User]

Ding! Ding! Ding!

Run from Diagnostics>Command prompt (I've checked the em1 directory, it's correct)

$ grep 2000419 /usr/local/etc/snort/snort_7104_em1/rules/snort.rules
(no results so nothing found)

$ grep 2000419 /usr/local/etc/snort/snort_7104_em1/rules/flowbit-required.rules

Category: emerging-policy  GID:1  SID:2000419

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET POLICY PE EXE or DLL Windows file download"; flow:established,to_client; file_data; content:"MZ"; within:2; byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64; within:4; flowbits:set,ET.http.binary; reference:url,doc.emergingthreats.net/bin/view/Main/2000419; classtype:policy-violation; sid:2000419; rev:17;)

The rule indeed looks enabled from my point of view

[bmeeks]

@jflsakfja:

Ding! Ding! Ding!

Run from Diagnostics>Command prompt (I've checked the em1 directory, it's correct)

$ grep 2000419 /usr/local/etc/snort/snort_7104_em1/rules/snort.rules
(no results so nothing found)

$ grep 2000419 /usr/local/etc/snort/snort_7104_em1/rules/flowbit-required.rules

Category: emerging-policy  GID:1  SID:2000419

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET POLICY PE EXE or DLL Windows file download"; flow:established,to_client; file_data; content:"MZ"; within:2; byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64; within:4; flowbits:set,ET.http.binary; reference:url,doc.emergingthreats.net/bin/view/Main/2000419; classtype:policy-violation; sid:2000419; rev:17;)

The rule indeed looks enabled from my point of view

Thanks for the quick feedback.  This confirms my suspicion.  I will put in a fix for this in the upcoming package update (pkg. 2.6.0).  In the meantime a Suppress List Entry is a viable work around.

Bill