Thanks for the contribution! I've added it under contrib/ossec2snorby.
I can't think of a reason it can't go into 2.7.1.

On Fri, Mar 15, 2013 at 9:54 AM, Jean-Pierre Zurbrugg
<[email protected]> wrote:
> Hello,
>
> Dan, I've never worked with bitbucket or anything related so I'll post it
> all here, sry bout that. Let me know if you require anything else, Its my
> first time contributing something like this.
>
> I've been using the script on my prod environment for over a month and I've
> tried to clear out all the major bugs as much as possible. Its been a week
> since I've noticed the last bug.
>
> Here is the documentation for the script along with a few notes:
>
> 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.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to