Hi,

I created a unit test
(https://github.com/inverse-inc/packetfence/pull/1759) and can validate
that the "security_onion" syslog parser still works correctly directly
from the log you previously gave, and that the "detect" violation
trigger still works fine and fires on parsed SIDs.


Clarifications from previous post:

The "detect" violation trigger serves to test upon unified
Snort/Suricata/SecurityOnion outputs and find the SID part of the
message extracted from the different syslog parsers configured on your
system.
The "suricata_event" violation trigger serves to test upon unified
Snort/Suricata/SecurityOnion outputs and find the "message" part of the
message extracted from the different syslog parsers configured on your
system.


Can you validate that you have a "security_onion" syslog parser
configured in the GUI, as define at section 13.1.3 here:

https://packetfence.org/doc/PacketFence_Administration_Guide.html#_blocking_malicious_activities_with_violations


Else I cannot understand why your usage of "detect" violation trigger
was not working previously if you have ran the maintenance. I'm glad it
works, though.

Thierry


On 10/13/2016 10:04 AM, Thierry Laurion wrote:
>
> I investigated a little more with my coworker and you seem to have
> found a bug! :)
>
> You should be able to use the detect trigger with SIDs if the
> SecurityOnion syslog parser is activated, which seems to be the case.
>
> I will return to you once it is fixed; it seems that SecurityOnion
> changed its format or something!
>
> I will reply to the list when done. Thanks for reporting.
>
> Thierry
>
>
> On 10/13/2016 09:48 AM, Morris, Andi wrote:
>>
>> Apologies, I thought I did. I didn’t mean to email you directly. I’ll
>> update the list now.
>>
>>  
>>
>> Cheers,
>>
>> Andi
>>
>>  
>>
>> *From:*Thierry Laurion [mailto:tlaur...@inverse.ca]
>> *Sent:* 13 October 2016 14:47
>> *To:* Morris, Andi <amor...@cardiffmet.ac.uk>
>> *Subject:* Re: [PacketFence-users] Security Onion alerts not triggering
>>
>>  
>>
>>  
>>
>> My pleasure!
>>
>> You should write that to the list, so that the whole community knows
>> it worked.
>>
>> Thanks,
>>
>>  
>>
>> On 10/13/2016 05:44 AM, Morris, Andi wrote:
>>
>>     Thanks Thierry, this fixed my issue.
>>
>>      
>>
>>     Chers,
>>
>>     Andi
>>
>>      
>>
>>     *From:*Thierry Laurion [mailto:tlaur...@inverse.ca]
>>     *Sent:* 07 October 2016 18:09
>>     *To:* packetfence-users@lists.sourceforge.net
>>     <mailto:packetfence-users@lists.sourceforge.net>
>>     *Cc:* Morris, Andi <amor...@cardiffmet.ac.uk>
>>     <mailto:amor...@cardiffmet.ac.uk>
>>     *Subject:* Re: [PacketFence-users] Security Onion alerts not
>>     triggering
>>
>>      
>>
>>     Hi,
>>
>>
>>     The "detect" trigger matches numerical SIDs found in Snort and
>>     Suricata generated "alert" logs, which have a different format
>>     then the "digested" logs of SecurityOnion.
>>
>>     As an exemple, here is the kind of logs that Suricata and Snort
>>     generates when in "alert" mode:
>>     '07/28/2015-09:09:59.431113  [**] [1:2221002:1] SURICATA HTTP
>>     request field missing colon [**] [Classification: Generic
>>     Protocol Command Decode] [Priority: 3] {TCP} 10.220.10.186:44196
>>     -> 199.167.22.51:8000'
>>
>>
>>     You should use "suricata_event" triggers in your SecurityOnion
>>     related violations, which match text and are more generic.
>>
>>     Modify the violation 1500003 for it to match "ET P2P Vuze BT UDP
>>     Connection". That would  be a broader match and would also
>>     generate a violation for the following SIDs:
>>     sid-msg.map:2010140 || ET P2P Vuze BT UDP Connection ||
>>     url,doc.emergingthreats.net/2010140 || url,vuze.com
>>     sid-msg.map:2010141 || ET P2P Vuze BT UDP Connection (2) ||
>>     url,doc.emergingthreats.net/2010141 || url,vuze.com
>>     sid-msg.map:2010142 || ET P2P Vuze BT UDP Connection (3) ||
>>     url,doc.emergingthreats.net/2010142
>>     sid-msg.map:2010143 || ET P2P Vuze BT UDP Connection (4) ||
>>     url,doc.emergingthreats.net/2010143
>>     sid-msg.map:2010144 || ET P2P Vuze BT UDP Connection (5) ||
>>     url,doc.emergingthreats.net/2010144 || url,vuze.com
>>
>>
>>     Regards,
>>     Thierry Laurion
>>
>>         An update, I’m now getting the alerts hitting pfdetect, but
>>         they’re still not triggering the violation with the same ID.
>>
>>         pfdetect.log shows:
>>
>>         Oct 07 15:23:40 pfdetect(11814) INFO: alert received: 'Oct  7
>>         14:23:40 idsman01 securityonion_ids: 14:23:40 pid(24921) 
>>         Alert Received: 0 1 policy-violation idshalls01-eth0-7
>>         {2016-10-07 14:23:39} 21 173773 {ET P2P Vuze BT UDP
>>         Connection} 10.6.198.173 24.122.228.33 17 10600 65344 1
>>         2010140 6 92 92
>>
>>         ' (main::_run_detector)
>>
>>          
>>
>>          
>>
>>         The relevant section of violation.conf is:
>>
>>         [1500003]
>>
>>         trigger=detect::2010140
>>
>>         actions=email_admin,reevaluate_access,log
>>
>>         max_enable=10
>>
>>         desc=P2P Vuze2
>>
>>         enabled=Y
>>
>>         template=p2p
>>
>>         grace=2h
>>
>>          
>>
>>          
>>
>>         *From:*Morris, Andi [mailto:amor...@cardiffmet.ac.uk]
>>         *Sent:* 07 October 2016 14:56
>>         *To:* packetfence-users@lists.sourceforge.net
>>         <mailto:packetfence-users@lists.sourceforge.net>
>>         *Subject:* [PacketFence-users] Security Onion alerts not
>>         triggering
>>
>>          
>>
>>         Hi all,
>>
>>         I have configured my security onion server to send alerts to
>>         my packetfence server (version 6.2.1), and I can see that
>>         they’re getting there through TCPdump.
>>
>>          
>>
>>         IDS server:
>>
>>         13:37:02.260031 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 240
>>
>>         13:37:02.260216 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 243
>>
>>         13:37:12.271539 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 241
>>
>>         13:37:57.325078 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>         13:37:57.326236 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 243
>>
>>         13:38:07.342397 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 243
>>
>>         13:38:37.377503 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 241
>>
>>         13:38:55.401715 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         13:38:55.401858 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         13:38:55.401895 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         13:38:55.401921 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         13:39:03.412383 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 241
>>
>>         13:39:07.418010 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         13:39:07.418098 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         13:39:07.418113 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         13:39:07.418132 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         13:39:07.418153 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>         13:39:07.418172 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>         13:39:22.434608 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>         PF server:
>>
>>         14:37:12.272395 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 241
>>
>>         14:37:57.325970 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>         14:37:57.326980 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 243
>>
>>         14:38:07.343228 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 243
>>
>>         14:38:37.378338 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 241
>>
>>         14:38:55.402550 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         14:38:55.402583 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         14:38:55.402610 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         14:38:55.402632 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 282
>>
>>         14:39:03.413187 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 241
>>
>>         14:39:07.418795 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         14:39:07.418819 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         14:39:07.418836 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         14:39:07.418865 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 284
>>
>>         14:39:07.418922 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>         14:39:07.418927 IP idsserver.internal.domain.35871 >
>>         packetfence.internal.domain.syslog: SYSLOG user.notice,
>>         length: 242
>>
>>          
>>
>>         I’ve configured the rsyslog as per the packetfence docs, and
>>         created the syslog parser and the violations I’d like to
>>         trigger. However the violation isn’t triggering when I can
>>         see from the sguild.log on the IDS server that it’s being
>>         seen. Looking at pfdetect.log I can see the following which
>>         suggests that for some reason the syslogger isn’t sending the
>>         alert to packetfence:
>>
>>         Oct 07 14:46:41 pfdetect(11814) INFO: pfdetect starting and
>>         writing 11814 to /usr/local/pf/var/run/pfdetect.pid
>>         (pf::services::util::createpid)
>>
>>         Oct 07 14:46:41 pfdetect(11814) INFO: initialized (main::)
>>
>>          
>>
>>         /var/log/messages shows:
>>
>>         Oct  7 13:53:09 idsserver sguil_alert: 13:53:09 pid(29886) 
>>         Alert Received: 0 1 policy-violation idsserver-eth0-7
>>         {2016-10-07 13:53:08} 21 173758 {ET P2P Vuze BT UDP
>>         Connection} 10.6.198.173 117.199.69.129 17 10600 10600 1
>>         2010140 6 77 77
>>
>>          
>>
>>         Is the format causing issues?
>>
>>         How about the timestamp? I can see that the IDS server is
>>         using UTC but my PF server is on GMT+1.
>>
>>          
>>
>>         Cheers,
>>
>>         Andi
>>
>>          
>>
>>         -------------------------------------
>>
>>         Andi Morris
>>
>>         IT Security Officer
>>         Cardiff Metropolitan University
>>
>>         T: 02920 205720
>>         E: amor...@cardiffmet.ac.uk <mailto:amor...@cardiffmet.ac.uk>
>>
>>         --------------------------------------
>>
>>          
>>
>>
>>
>> -- 
>> Thierry Laurion
>> tlaur...@inverse.ca <mailto:tlaur...@inverse.ca>  ::  +1.514.447.4918 *120  
>> ::  https://inverse.ca
>> Inverse inc. :: Leaders behind SOGo (https://sogo.nu) and PacketFence 
>> (https://packetfence.org)
>
> -- 
> Thierry Laurion
> tlaur...@inverse.ca  ::  +1.514.447.4918 *120  ::  https://inverse.ca
> Inverse inc. :: Leaders behind SOGo (https://sogo.nu) and PacketFence 
> (https://packetfence.org)

-- 
Thierry Laurion
tlaur...@inverse.ca  ::  +1.514.447.4918 *120  ::  https://inverse.ca
Inverse inc. :: Leaders behind SOGo (https://sogo.nu) and PacketFence 
(https://packetfence.org)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to