+++ /dev/null
-File attachments:
-1- Init scripts for linux distributions:
- a. ossec2snorby.sh = Generic
- b. ossec2snorby_ubuntu.sh = Ubuntu init script (training wheels ! :D)
-2- ossec2snorby.pl = script
-3- ossec2snorby_category.sql = needed for script, explained below.
-4- NOT INCLUDED, ossec2snorby.pl still feeds off "ossecmysql.pm" which is already included in OSSEC/contrib. No modifications were made to the file.
-
-
-===============================================================================
-
-
-About this script:
-
- ossec2snorby.pl comes from the original ossec2mysql.pl script, slight modifications were made to adapt it to snorby's requirements and
-as such, thanks must go to the original Author and Co-Author. I would also like to note that this is the first perl script I've made and so it might require tweaking
-based on the environment it will be used in.
-
-Lastly, as any other contributions made to a community, responsibility lies on the person that uses this script and so please run numerous tests
-on a lab before pushing this to your production environment as you will have to tweak it based on your needs.
-
-
-----------------
-DEPENDENCIES:
-
-1- Ossec2snorby.pl depends on the table called "Category" which contains a relation between OSSEC's categories and Snorts signature classes.
-
- import ossec2snorby_category.sql to your Snorby DB.
-
- Follow the steps on this site if you do not know how to do this ( admin privileges are required towards the Snorby DB):
- http://dev.mysql.com/doc/refman/5.0/en/batch-commands.html
-
-2- Follow the installation steps noted on ossec2snorby.pl ( view with your favorite text editor)
-
-
-3-Consider adding the following to your local decoders in OSSEC.
- This will extract the SRCIP from the ossec events related to "Agent disconnected". Without this you'll get
- "0.0.0.1" or "127.0.0.1" as source IP for these events.
-
- <decoder name="ossec-agent2">
- <parent>ossec</parent>
- <type>ossec</type>
- <prematch offset="after_parent">^Agent disconnected:</prematch>
- <regex offset="after_prematch">^ '\S+(\d+.\d+.\d+.\d+)'</regex>
- <order>srcip</order>
- </decoder>
-
-
-
-NOTES:
-
-1- Using ossec2snorby.pl to dump many alerts at once (over 10k+ or 30k+ events) might crash Snorby's workers resulting in
- No events being displayed on the dashboard. Events will still be displayed on the "events" section, but no statistics will be shown.
-
- Possible fix? Clearing out the snorby daily stats might fix things:
-
- Execute the following on your shell:
- mysql -u root -p
- <type password>
-
- Execute: use snorby;
- Execute: truncate table caches;
- Execute: exit
-
- On the portal, go to Administration followed by Worker & Job Queue.
- Search for "--- !ruby/struct:Snorby::Jobs::DailyCacheJob " by clicking on the job handler buttons. Once you find the DailyCacheJob handler click on the associated trash can button.
- Now you'll see a new button below Administration called "Worker Options". click there followed by "Start Daily Cache Job"
- Wait 10 minutes and then check your dashboard again.
-
- If this does not work then you'll have to head over to Snorby's Google group and seek assistance.
-
-
-2- Snorby expects that srcip and dstip be populated by a numeric value greater than "0" otherwise the GUI output will be incorrect. Note that if an entry is added in the DB table "iphdr" for an event where srcip\dstip are NOT populated then its default value will be "0".
-
-2.A- An IP address value of "0.0.0.1" will be shown when the field could not be populated, either for source or destination IP. This will happen if an event had no recognizable SRC\DST IP.
- Note that Snorby should populate "N\A" on the GUI for IPs stated as "0", but it does not...
- Note that "127.0.0.1" will be used for events generated on the OSSEC Server(localhost).
- Note that the same IP address will appear in SRC and DST fields if the event was generated by the same host from where the event was sent from unless this host is the OSSEC server.
-
-4- Events will be categorized as "unknown" when a relation between OSSEC's category could not be matched against Snorby's sig class names. This match is completed using the "category" table. Please keep in mind that only the LAST OSSEC category is used for the match. Its not optimal but its all I could think of.
-
- EXAMPLE:
- In this example, only "authentication_success" will be used, which when looked up on the category table, returns a sig_class_id of "11" which in turn snorby interprets as "successful-user"
-
- example:
- ** Alert 1359725403.1533356: - pam,syslog,authentication_success,
- 2013 Feb 01 09:30:03 (theHost) 192.168.1.1->/var/log/secure
- Rule: 5501 (level 12) -> 'Login session opened.'
- Feb 1 08:30:01 esx001 crond[19884]: pam_unix(crond:session): session opened for user root by (uid=0)
-
-
-5- ossec2snorby.pl depends on DNS resolutions unlike ossec2mysql.pl which allows us to choose whether or not to resolve a host; ossec2snorby.pl will try to resolve computer names(NetBIOS\Flatnames) by appending the domain suffix to them and querying your DNS servers. This only happens if OSSEC could not decode a SRC IP or if an IP address could not be decoded from the log by ossec2snorby.pl. Failure to resolve a host will force ossec2snorby to populate SRCIP as "0.0.0.1" or "127.0.0.1" depending on the event.
-
-=================================================
-Examples on how to use ossec2snorby.pl:
-
-1 - Process a single file:
-gzip -dc <OSSEC HOME>/var/ossec/logs/alerts/2013/Mar/ossec-alerts-07.log.gz | /usr/local/bin/ossec2snorby/ossec2snorby.pl --conf /etc/ossec2snorby.conf --interface manualfeed
-
-2- Process a bunch of files ( CAREFUL!, too many DB inserts at once might cause problems with Snorby's workers):
-gzip -dc <OSSEC HOME>/var/ossec/logs/alerts/2013/Mar/ossec-alerts-*.log.gz | /usr/local/bin/ossec2snorby/ossec2snorby.pl --conf /etc/ossec2snorby.conf --interface manualfeed
-
-3- Something isn't right and you'd like to debug?
-gzip -dc <OSSEC HOME>/var/ossec/logs/alerts/2013/Mar/ossec-alerts-07.log.gz | /usr/local/bin/ossec2snorby/ossec2snorby.pl -v --conf /etc/ossec2snorby.conf --interface manualfeed > debug.log
-
-Now check out debug.log for details on each event.
-
-4- Run ossec2snorby.pl as a daemon:
-/usr/local/bin/ossec2snorby/ossec2snorby.pl --conf /etc/ossec2snorby.conf -d
-
-Confirm everything is running:
-ps auwx |grep ossec2snorby
-lsof |grep alerts:
-tail 2478 root 3r REG 252,0 1394774 2760144 /var/ossec/logs/alerts/alerts.log
-
-Notice how it says "tail" has the file open, careful not to confuse the results with any other tail you might have running on alerts.log...
-
-==================
-Thats it ... I tried my best at making the script as stable as possible, any suggestions, opinions or critics are more than welcome. I hope this helps anyone trying to get Snorby to play nice with OSSEC.
-
projects / ossec-hids.git / blobdiff