Snort not working [Solved]

[JonM]

Recently I removed the scripts associated with the post Snort Rules Update. And I added the scripts for the post IDS Rule updater - with rule state persistance. I ran the recent Master Branch (updated 5 days ago).

When I click on the RED Network and click Save I get this error in the /var/log/messages file:

Code: Select all

Sep 26 21:54:18 ipfire snort[15883]: FATAL ERROR: /etc/snort/rules/emerging-exploit.rules(75) Unknown ClassType: misc-activity

This error will appear no matter what intrusion detection system rules are check on. Are all of the rules suppose to be left unchecked? And does the policies (I picked Balanced) determine what rules are used?

EDIT: added image

[TimF]

What's happening is that the /etc/snort/rules/classification.config file doesn't contain the information on the classtype misc-activity. I don't know why this is happening since this file should be downloaded with the rules. Can you tell me what the date of this file is and what the contents are. (It should look similar to https://rules.emergingthreats.net/open- ... ion.config).

If the file doesn't look similar to the example, try downloading the file to /etc/snort/rules and see what happens.

It looks like there's an issue with the way that Oinkmaster handles non-rule files when they're not distributed in the rules directory. I'll have to think what to do about it, but hopefully downloading classification.config will enable your system to get running.

[JonM]

Tim - the /etc/snort/rules/classification.config and the https://rules.emergingthreats.net/open- ... ion.config files are identical.

The /etc/snort/rules/classification.config file was modified yesterday after my run of ./install-idsupdate.sh.

The permission and ownership of the classification.config file seems OK.

[TimF]

OK. Can you have a look at /etc/snort/snort.conf and check that it has the line include /etc/snort/rules/classification.config in it. I think there's a bug the the IDS WUI that can corrupt the end of this file under some circumstances.

Also look at /etc/snort/rules/emerging-exploit.rules, around line 75 and check that it looks OK.

It seems strange that it's complaining about a classtype in the middle of a rule file, and not the first rule file it would process either, so can you check the end of snort.conf and see where emerging-exploits is in the list of uncommented includes.

---

I've realised that I don't answer the questions from your first post.

The rulefile and rule checkboxes on the IDS WUI function as normal. Rules will only be used if both the rule and the rulefile containing it are checked.

The policy on the IDS Update WUI determines what happens to new rules; if they're in the selected policy they will be enabled, otherwise they'll be disabled. Note that the rulefile still needs to be checked on the IDS WUI for the rule to be used. The IDS Update Log WUI page will only report on rules in enabled rulefiles. The IDS WUI will reflect the status of new rules as set by the updater script.

In addition, if you've got 'Apply Policy Changes' checked on the IDS Update WUI, the updater will enable or disable any existing rules that have their policy changed.

[JonM]

OK. Can you have a look at /etc/snort/snort.conf and check that it has the line include /etc/snort/rules/classification.config in it. I think there's a bug the the IDS WUI that can corrupt the end of this file under some circumstances.

there is no include /etc/snort/rules/classification.config in this file.

For what it is worth: these two lines are missing from the snort.conf file

Code: Select all

# metadata reference data.  do not modify these lines
include /etc/snort/rules/classification.config
include /etc/snort/rules/reference.config

Is it OK to manually add them back into the file?!?

Also look at /etc/snort/rules/emerging-exploit.rules, around line 75 and check that it looks OK.

All seems OK. No odd characters.

[TimF]

It look like that's the problem. You should be able to juts add the lines to the file.

if you then run:

snort -c /etc/snort/snort.conf -T

it will check the rules for errors; hopefully it will say they're OK. Then do:

/etc/init.d/snort restart

and snort should start working again. The update script should then work OK.

[JonM]

I tried last night and added the the 'include' lines that made things run. Wahoo! Thank you, Tim! No errors with the snort -c /etc/snort/snort.conf -T command.

I looked at the WUI logs and came across the warning below. What are flowbit warnings? Do I fix or ignore or ??

[Hellfire]

JonH,

where did you get this IDS update log overview? I did not find this one page in my WebUI, at leat not in core 123 and some versions lower.
Is this a hidden page?

Michael

[JonM]

under the menu Logs -> IDS Update Logs. It is not hidden.

[Hellfire]

I must be using a different version of IPFire / IDS then:

[JonM]

I am on Core 123 also. Did you install the current version of TimF's ipfidsupdate? The test version moved to a Master branch 9 days ago. See https://github.com/timfprogs/ipfidsupdate/tree/master

Keep an eye on the install with ./install-idsupdate.sh. When I installed a few days ago only the VERSION file was updated by the ./install-idsupdate.sh installer. It looked like this:

I had to delete the ipfidsupdate settings file at /var/ipfire/idsupdate/settings to get ./install-idsupdate.sh to install everything.

[Hellfire]

I am on Core 123 also. Did you install the current version of TimF's ipfidsupdate?

No, of course not! Did not notice while reading from the beginning of the thread, that the rule set updater adds an extra menu item

Thanks for the clarification!
Michael

[TimF]

Sorry for the long wait before replying.

Flowbits are used to convey information between rules. For example there are a number of rules that look for problems with PDF files; rather than duplicate the code that determines whether network traffic represents the download of a PDF file in each of these rules, there are rules that work this out (for example SID:15013 "FILE-IDENTIFY PDF file download request". This rule then sets a flowbit ("files.pdf"). Other rules can just check to see if that flowbit is set; if it is then the traffic is a PDF file (for example SID:46754 "OS-WINDOWS Microsoft Windows win32k NtUserSetImeInfoEx privilege escalation attempt").

It's similar to a subroutine in some ways in that it simplifies rules, however unlike a subroutine it's only executed once. I assume that part of the processing does when it starts up is to work out what order rules have to be executed in so as to ensure that flowbits are set before they're checked.

The problem is when you have a rule enabled that tests a flowbit,but the rule that sets the flowbit isn't enabled - this means that the first rule can never be matched and is therefore wasting resources. The flowbit warning tells you if this occurs. It's OK to ignore the warning, but you will be wasting resources. It's better to look at the rules and either enable the rule(s) that set the flowbit (if you think the rules are useful) or to disable the rule(s) that check the flowbit. If you're enabling a rule you may have to enable the rulefile that it's in as well.

[JonM]

That helps big time!
Using my flowbit warnings from earlier in this post I see a few items disabled such as ET POLICY and ET INFO.

So if I go to the webpage Intrusion Detection System (Services -> Intrusion Detection) and check on emerging-policy.rules and emerging-info.rules then the flowbit warning messages should disappear? Does that sound correct?

I am guessing I have to wait until after midnight to find out for sure... What script updates the flowbit warnings?

[TimF]

Yes, the warnings should disappear - once the warnings have updated (provided the appropriate rules are enabled in the emerging-policy.rules and emerging-info.rules rulefiles).

The warnings are updated whenever the script downloads an update - it gathers the necessary information as part of the processing.

Note it doesn't keep historical information on flowbit warnings, so even if you see the warning when looking through old update logs, it's always referring to the current situation.