Re: [ossec-list] OSSEC seems to be dropping alerts...
Yeah, it's on a production server so I can't immediately upgrade that. I just did search for "ossec-maild" under releases and see that this has been touched quite a bit since my version. I'll push to get a newer version installed by next release. Thanks Dan! On Monday, April 8, 2019 at 10:53:21 AM UTC-7, dan (ddpbsd) wrote: > > > >> Version: 2.9.4-5177trusty > > So old > > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: OSSEC seems to be dropping alerts...
Also, I'm aware of the email_maxperhour setting (12 seems low for a default setting?), however, as you can see in the alert info above, the alert was created a week ago and was never delivered. Is there a command to show the ossec email queue, or a file/folder location I can check? Is there a log entry that is created when email_maxperhour has been reached and alerts are getting queued instead of delivered? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] OSSEC seems to be dropping alerts...
I'm trying to figure out why ossec is sometimes not emailing triggered 31122 alerts. Here's a log entry in ossec's alerts log file: ** Alert 1554150564.41683927: mail - web,accesslog,system_error, > 2019 Apr 01 20:29:24 us-web->/log/jetty/2019_04_01.request.log > Rule: 31122 (level 5) -> 'Web server 500 error code (Internal Error).' > Src IP: 1.2.3.4 > 1.2.3.4 username - [01/Apr/2019:20:29:24 +] "POST /update.rest > HTTP/1.1" 500 12369 23 > However, here are two consecutive log entries in ossec.log: 2019/04/01 20:03:43 INFO: Connected to 127.0.0.1 at address 127.0.0.1, port > 25 > 2019/04/01 21:00:06 INFO: Connected to 127.0.0.1 at address 127.0.0.1, > port 25 > this mirrors the mail log entries (Postfix is running just for ossec): Apr 1 20:03:43 us-web postfix/qmgr[4488]: 4438D801A5: removed > Apr 1 21:00:06 us-web postfix/smtpd[127085]: connect from > localhost[127.0.0.1] > I double checked and the details for rule 31122 look correct: > 31120 > ^500 > alert_by_email > Web server 500 error code (Internal Error). > system_error, > > Any idea what could be going on here? I see a for the ossec-maild child process: ossecm 4957 0.0 0.0 16552 2156 ?SApr06 0:04 > /var/ossec/bin/ossec-maild > ossec 4965 0.2 0.0 23176 3552 ?SApr06 7:42 > /var/ossec/bin/ossec-analysisd > root 4969 0.0 0.0 6652 584 ?SApr06 2:25 > /var/ossec/bin/ossec-logcollector > root 4981 0.0 0.0 7708 1924 ?SApr06 1:29 > /var/ossec/bin/ossec-syscheckd > ossec 4986 0.0 0.0 15164 692 ?SApr06 0:00 > /var/ossec/bin/ossec-monitord > ossecm72611 0.0 0.0 0 0 ?Z17:02 0:00 > [ossec-maild] > but from what I can tell when I've ran ossec-maild -ddd -f, showing defunct on the child process is normal -- it will eventually end and a new one will be created the next time an alert needs to be delivered. Communication to postfix seems to be working fine. There are no errors in either the mail log or ossec's logs. Version info: > dpkg -s ossec > dpkg-query: package 'ossec' is not installed and no information is > available > Use dpkg --info (= dpkg-deb --info) to examine archive files, > and dpkg --contents (= dpkg-deb --contents) to list their contents. > root@us-web:/var/ossec/bin# dpkg -s ossec-hids-server > Package: ossec-hids-server > Status: hold ok installed > Priority: extra > Section: admin > Installed-Size: 4516 > Maintainer: Atomicorp > Architecture: amd64 > Version: 2.9.4-5177trusty > Depends: libc6 (>= 2.15), libgeoip1, libmysqlclient18 (>= 5.5.24+dfsg-1), > libssl1.0.0 (>= 1.0.1), expect, debconf > Conflicts: ossec-hids-agent > Conffiles: > /var/ossec/etc/ossec.conf 45e1b4a4e4c9b62fdf4c8788e2579984 > Description: OSSEC Server - Host Based Intrusion Detection System > OSSEC HIDS for log analysis, integrity checking, rootkits detection and > active response. This package includes the server > Homepage: http://www.ossec.net > > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] strange error message from ossec-keepalive
I know this is an old thread but when I Googled, this was the top result, so I figured it would be okay to continue the discussion here. I just received this today: OSSEC HIDS Notification. > 2019 Apr 04 12:31:45 > > Received From: server->ossec-keepalive > Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system." > Portion of the log(s): > > --MARK--: gnetT9ILb_p+LIy(PF!1*#11NrDK!XIzsNS@4[4nwCd7s^c7ou*NbMiO3'GH > /^oq!7KIjiWG;hVl-fATAla^fXx8QmY.]un5]fhT2lHU6KnfQ,Yyhghn3( > D2/JZ'4ughAo0,$P/,[mb;iZq3nxy*X2]WTU.rwezW6Ha]=?=*Z;97?H( > n4lM9vHz%J@a5^z!Po!KfrC-&8h?qO(*0.xEsmlOV-O8nvM2K5VP-F_pVJ > o@GaWaL)(3NM0QCitQ(n0wA3trcV_Y?c*FRI),9oir087,yI[kWd_- > 6iVr3=xk[i.L/*+8?.HhnWRMNMWd.LH3bLCmCZ@!q83obTEO/@V0 > Ubuntu 18.04 LTS dpkg -s ossec-hids-server Version: 3.2.0-6132bionic >From atomiccorp.com repo We're on an upgrade cadence and it looks like there's a 3.3.0-6515bionic package listed as an upgrade, however when I went to the website to check for a change log, it's showing 3.2 as the latest? Did this bug creep back in at some point and get fixed in 3.3.0, or does Dan still need help tracking this down? The system seems to be functioning fine -- nothing notable in dmesg or syslog. The server is mostly idle as we're just using for testing -- it's an m4.4xlarge instance in AWS. Uptime shows 51 days, and this is the first time I've received this from the instance. -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] ossec HIDS 2.9.0 missing "Object Type" field for event it 5140
I saw a strange log entry today that seemed to have the information put into some of the wrong fields: 2018 Apr 16 12:11:14 (workstation) 1.1.1.2->WinEvtLog 2018 Apr 16 05:11:10 > WinEvtLog: Security: AUDIT_FAILURE(5140): > Microsoft-Windows-Security-Auditing: (no user): no domain: > workstation.domain.com: A network share object was accessed. Subject: > Security ID: S-1-5-21-xx-yy-z-8642 Account Name: > CCIS-TS1$ Account Domain: MMIA Logon ID: 0x18bb1672 Network > Information: Source Address: File Source Port: 1.1.1.1 Share Name: > 49318 Looking at the event log itself, it looks like it's not accounting for "Object Type" before "Source Address." It's also not reporting some of the fields after Share Name: Share Path Access Mask Accesses Is this something I can fix myself? This was on a Windows 10.0.15063 workstation. Has the event changed for this flavor of Windows? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] What are others doing to manage false positives?
Say SO is configured to use Suricata with the Emerging Threats ruleset One of the rules is triggered: ET CNC Zeus Tracker Reported CnC Server group 12 for IP address 199.59.242.150. Now, with RC3, I can highlight the destination IP address in Squert and search for it in Kibana. While in Kibana I see that a DNS lookup was done and that the DNS name for that IP address is pixel.ad.mlnadvertising.com. When I add the source IP address to the Kibana search criteria, I'm shown which program is responsible for the traffic: Google Chrome. This tells me enough to know that this particular traffic is probably benign. So knowing all of this the next step is to prevent future versions of this rule with these criteria from polluting Squert. I believe that leaves me with the following choices: 1 - Suppress the "ALL ET CNC Zeus Tracker Reported CnC Server group 12" in threshold.conf -- However this will leave me exposed to true positives for this rule. 2:- Modify that rule in modifysid.conf so that if the IP address 199.59.242.150 is detected as part of that rule, ignore it. However, this IP address may go back into circulation as evil (or it may be shared and is still evil), thus exposing to possible problems in the future. This also won't solve future similar false positives -- there may be multiple IP addresses assigned to pixel.ad.mladvertising.com. Maintaining this modify rule can become unruly. 3 - Add a filter rule to Squert for this rule and this destination IP address -- But that's only as good as #2. What I really need is that third check -- which program is responsible for the traffic. If also Google Chrome and dst port 443, then don't populate Squert as a danger. What I've considered doing instead is write a script that runs on a schedule -- it would query the squert db for these potential false positives, and then run a search to look for the extra criteria I searched for in Kibana before making a decision to update the squertDB and "hide" the event. With the release version of SO, I could use /opt/elsa/contrib/securityonion/contrib/cli.sh to search Elsa. What is recommended for Kibana? What other ideas are there to deal with situations where the only way to make a decision is based on data only found in ELSA or Kibana (Or possibly elsewhere)? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] ossec-logtest verbosity levels...
Dan, Okay, so say I make two rules. 100014 that uses the first match, and 100015 that uses the second. Is there a way to revert back to 18105 if 100014 matches but 100015 doesn't? On Tuesday, March 13, 2018 at 3:31:15 AM UTC-7, dan (ddpbsd) wrote: > > > I think this combined the matches, effectively making it: > pfussmon.exeDestination Address: 192.168.23.255 > > You might need to make 2 rules, and have the parent of the second be > the sid of the first. > > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] ossec-logtest verbosity levels...
Is it possible to crank up the verbosity of ossec-logtest so that I can see if individual lines in a rule match? I'm stuck on something that's got me flustered. I've got what I think is a simple rule, but damn if I can get it to work: This is the log entry: 2018 Mar 12 13:14:22 WinEvtLog: Security: AUDIT_FAILURE(5157): Microsoft-Windows-Security-Auditing: (no user): no domain: computer.domain.test: The Windows Filtering Platform has blocked a connection. Application Information: Process ID: 7812 Application Name: \device\harddiskvolume2\program files (x86)\pfu\scansnap\driver\pfussmon.exe Network Information: Direction: %%14593 Source Address: 192.168.23.1 Source Port: 53885 Destination Address: 192.168.23.255 Destination Port: 52217 Protocol: 17 Filter Information: Filter Run-Time ID: 75813 Layer Name: %%14611 Layer Run-Time ID: 48 msauth_rules.xml will match this under 18105. I've written a rule in local_rules.xml that matches: 18105 pfussmon.exe Harmless Network traffic However, I wanted to add a second match that checks the destination address too: 18105 pfussmon.exe Destination Address: 192.168.23.255 Harmless Network traffic Yet when I pipe that log entry back into logtest: Trying rule: 100014 - Harmless Network traffic Trying rule: 18106 - Windows Logon Failure. Trying rule: 18139 - Windows DC Logon Failure. Trying rule: 18180 - MS SQL Server Logon Failure. Trying rule: 18108 - Failed attempt to perform a privileged operation. **Phase 3: Completed filtering (rules). Rule id: '18105' Level: '5' Description: 'Windows audit failure event.' **Alert to be generated. It's not matching. Running ossec 2.8 (The version that comes with Security Onion) . Was multiple matching enabled in a later version or have I done something foolish here? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: evil ip block rules -- why only look for traffic in one direction?
Sorry -- wrong maillinglist. :) On Tuesday, July 11, 2017 at 11:11:09 AM UTC-7, Ian Brown wrote: > > I've noticed there are lots of rules that look for low reputation ip > addresses .. Rules like this one: > > ET TOR Known Tor Relay/Router (Not Exit) Node Traffic group 385 > alert ip > [45.76.222.6,45.76.32.13,45.76.86.86,45.76.92.117,45.76.95.200,45.77.53.109,45.77.56.43,45.77.56.54,45.77.61.195,45.77.62.230] > > any -> $HOME_NET any (msg:"ET TOR Known Tor Relay/Router (Not Exit) Node > Traffic group 385"; reference:url, > doc.emergingthreats.net/bin/view/Main/TorRules; threshold: type limit, > track by_src, seconds 60, count 1; classtype:misc-attack; > flowbits:set,ET.TorIP; sid:2522768; rev:3019;) > > Why only alert if traffic is going to home_net and not also from home_net? > If a compromised home_net device sends udp packets (C2C / exfiltration) to > any of these ip addresses, this rule won't fire, right? > -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] What is the best method to augment an existing decoder?
Dan, Apparently it isn't compatible: ../bin/ossec-logtest -v 2017/07/07 01:50:33 ossec-analysisd: Invalid element 'accumulate' for decoder 'decoder' 2017/07/07 01:50:33 ossec-testrule(1202): ERROR: Configuration error at '/etc/decoder.xml'. Exiting. On 7/6/2017 6:48 PM, dan (ddp) wrote: On Thu, Jul 6, 2017 at 9:08 PM, Ian Brown <zestys...@gmail.com> wrote: Dan, It's what comes in SecurityOnion's latest iso (securityonion-14.04.5.2.iso). ./ossec-logtest -V OSSEC HIDS v2.8 - Trend Micro Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License (version 2) as published by the Free Software Foundation. For more details, go to http://www.ossec.net/main/license/ I tried "apt-file search /var/ossec/bin/ossec-logtest" to see if a package owns it, but that program returned no results, so I'm going to assume it has been compiled from source. 2.8 is good enough info. I don't have anything that old to test unfortunately. You could backup your decoder.xml and local_decoder.xml files and download the latest decoders. I think they should be compatible, and you can test them quickly with ossec-logtest without restarting OSSEC. On 7/6/2017 5:47 PM, dan (ddp) wrote: On Wed, Jul 5, 2017 at 10:26 PM, Ian Brown <zestys...@gmail.com> wrote: Dan, that matches for the source and destination IP addresses, but if I understand logtest's "Phase 2" output correctly, using those additional decoders drops all the other things that the original windows decoder found: --- # ./ossec-logtest -v 2017/07/06 02:19:12 ossec-testrule: INFO: Reading local decoder file. 2017/07/06 02:19:12 ossec-testrule: INFO: Started (pid: 4227). ossec-testrule: Type one log per line. 2017 Jul 03 11:17:37 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: workstation: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 1.2.3.4 Source Port: 143 Destination Address: 5.6.7.8 Destination Port: 2619 Protocol: 6 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13 **Phase 1: Completed pre-decoding. full event: '2017 Jul 03 11:17:37 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: workstation: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 1.2.3.4 Source Port: 143 Destination Address: 5.6.7.8 Destination Port: 2619 Protocol: 6 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13' hostname: 'securityonion' program_name: '(null)' log: '2017 Jul 03 11:17:37 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: workstation: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 1.2.3.4 Source Port: 143 Destination Address: 5.6.7.8 Destination Port: 2619 Protocol: 6 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13' **Phase 2: Completed decoding. decoder: 'windows' srcip: '1.2.3.4' dstip: '5.6.7.8' **Rule debugging: Trying rule: 6 - Generic template for all windows rules. *Rule 6 matched. *Trying child rules. Trying rule: 7301 - Grouping of Symantec AV rules from eventlog. Trying rule: 18100 - Group of windows rules. *Rule 18100 matched. *Trying child rules. Trying rule: 18101 - Windows informational event. Trying rule: 18102 - Windows warning event. Trying rule: 18104 - Windows audit success event. Trying rule: 18103 - Windows error event. Trying rule: 18105 - Windows audit failure event. **Phase 3: Completed filtering (rules). Rule id: '18100' Level: '0' Description: 'Group of windows rules.' - This is Phase 2 without those additional decoders: **Phase 2: Completed decoding. decoder: 'windows' status: 'AUDIT_FAILURE' id: '5152' extra_data: 'Microsoft-Windows-Security-Auditing' dstuser: '(no user)' system_name: 'workstation' Do your decoders still inherit the matching of those fields and logtest just doesn't show this? It works on mine: **Phase 1: Completed pre-decoding. full event: '2017 Jul 03 11:17:37 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: workstation: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 1.2.
[ossec-list] What is the best method to augment an existing decoder?
There is a decoder that isn't quite handling some log entries the want I need. I want to augment an existing decoder, but apparently I'm not doing this correctly. Here's an example log entry: 2017 Jul 03 11:17:37 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: workstation: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 1.2.3.4 Source Port: 143 Destination Address: 5.6.7.8 Destination Port: 2619 Protocol: 6 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13 Using this as a guild: http://ossec-docs.readthedocs.io/en/latest/manual/rules-decoders/create-custom.html I've created a new decoder that inherits from this existing one: windows ^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: |^WinEvtLog: ^\.+: (\w+)\((\d+)\): (\.+): (\.+): \.+: (\S+): status, id, extra_data, user, system_name name, location, user, system_name I've tried an number of different versions of this -- below was my last attempt: windows The Windows Filtering Platform ^\.+: (\w+)\((\d+)\): (\.+): (\.+): \.+: (\S+): Thee Windows Filtering Platform Source Address: (\S+) Source Port: (\d+) Destination Address: (\S+) Destination Port: (\d+) status, id, extra_data, user, system_name, srcip, srcport, dstip, dstport All I'm trying to do is match for the source and destination information that's in these particular log entries. However, when I added my decoder, it "took over" for all the windows decoder matches instead of just for the log entries I was hoping to match against -- any log entry that contained "The Windows Filtering Platform." On top of that, my decoder's regex doesn't seem to be matching any of the fields -- phase 2 just states: **Phase 2: Completed decoding. decoder: 'windows' instead of at least: **Phase 2: Completed decoding. decoder: 'windows' status: 'AUDIT_FAILURE' id: '5152' extra_data: 'Microsoft-Windows-Security-Auditing' dstuser: '(no user)' system_name: 'workstation' How far off the rails am I in achieving the solution I'm looking for? -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: I'm unclear why my rule is not matching...
I believe I've figured it out -- I think the decoder isn't matching the full log string and is thus stripping the ip address information. Also after looking at the regex in the decoder, I've discovered that it doesn't even match against the first three example strings provided: Here's an example from the comments (After prematch): Security: AUDIT_FAILURE(0x02A9): Security: SYSTEM: NT AUTHORITY: The logon to account: xyz by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from workstation: la failed. The error code was: 3221225572 yet, the regex is: ^\.+: (\w+)\((\d+)\): (\.+): The second (\d+) will only match against numbers, so (0x02A9) will never match. It should be ([0-9A-Fx]+) Also, why is it escaping the period at the beginning and at the end? shouldn't the regex be: ^.+: (\w+)\((\d+)\): (.+): -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: I'm unclear why my rule is not matching...
No effect. I tried dstip too, but I don't think either of those tags contain data due to the decoder used? windows ^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: |^WinEvtLog: ^\.+: (\w+)\((\d+)\): (\.+): (\.+): \.+: (\S+): status, id, extra_data, user, system_name name, location, user, system_name This means the only tags that contain data is status, id, extra_data, user, and system_name, right? Is there a way to dump the data that my rule would have processed? Is the decoder stripping what I'm trying to search for? On Monday, July 3, 2017 at 5:43:39 AM UTC-7, Fredrik Hilmersson wrote: > > What happens if you change using 192.168.1.255? > >> >> -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
