General questions.
-
JonM
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » September 27th, 2018, 3:02 am
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
Last edited by
JonM on October 16th, 2018, 6:31 pm, edited 1 time in total.
Production:
Testing Raspi 3B+:

-
TimF
- Posts: 83
- Joined: June 10th, 2017, 7:27 pm
Post
by TimF » September 27th, 2018, 7:12 pm
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
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » September 27th, 2018, 8:17 pm
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.
Production:
Testing Raspi 3B+:

-
TimF
- Posts: 83
- Joined: June 10th, 2017, 7:27 pm
Post
by TimF » September 28th, 2018, 3:18 pm
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
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » September 28th, 2018, 5:49 pm
TimF wrote: ↑September 28th, 2018, 3:18 pm
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?!?
TimF wrote: ↑September 28th, 2018, 3:18 pm
Also look at /etc/snort/rules/emerging-exploit.rules, around line 75 and check that it looks OK.
All seems OK. No odd characters.
Production:
Testing Raspi 3B+:

-
TimF
- Posts: 83
- Joined: June 10th, 2017, 7:27 pm
Post
by TimF » September 29th, 2018, 2:42 pm
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
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » September 29th, 2018, 6:48 pm
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 ??
Production:
Testing Raspi 3B+:

-
Hellfire
- Posts: 697
- Joined: November 8th, 2015, 8:54 am
Post
by Hellfire » September 29th, 2018, 7:17 pm
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
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » September 29th, 2018, 9:32 pm
under the menu
Logs ->
IDS Update Logs. It is not hidden.
Production:
Testing Raspi 3B+:

-
Hellfire
- Posts: 697
- Joined: November 8th, 2015, 8:54 am
Post
by Hellfire » September 30th, 2018, 11:08 am
I must be using a different version of IPFire / IDS then:
-
JonM
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » September 30th, 2018, 7:42 pm
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.
Production:
Testing Raspi 3B+:

-
Hellfire
- Posts: 697
- Joined: November 8th, 2015, 8:54 am
Post
by Hellfire » October 1st, 2018, 10:39 am
JonM wrote: ↑September 30th, 2018, 7:42 pm
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
- Posts: 83
- Joined: June 10th, 2017, 7:27 pm
Post
by TimF » October 5th, 2018, 5:49 pm
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
- Posts: 144
- Joined: August 4th, 2017, 5:49 pm
- Location: US
Post
by JonM » October 5th, 2018, 8:20 pm
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?
Production:
Testing Raspi 3B+:

-
TimF
- Posts: 83
- Joined: June 10th, 2017, 7:27 pm
Post
by TimF » October 6th, 2018, 11:58 am
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.