On Tue, Oct 16, 2018 at 4:25 PM 'Brandon' via ossec-list <[email protected]> wrote: > > > > On Tuesday, October 16, 2018 at 3:02:37 PM UTC-4, dan (ddpbsd) wrote: >> >> On Tue, Oct 16, 2018 at 2:58 PM 'Brandon Westover' via ossec-list >> <[email protected]> wrote: >> > >> > We have been testing OSSEC to specifically be used for FIM and have been >> > running into issues that worry about the stability/consistency of the >> > product. Before I go about utilizing alternative Open Source products, I >> > was hoping that the OSSEC gurus could assist me in tracking down why it is >> > behaving the way it is. >> > >> > Our Setup: >> > >> > Server - Ubuntu 14.04.5 LTS >> > Agents - Ubuntu 18.04.1 LTS; Windows 2012 R2 >> > >> > >> > >> > Here are the issues that we have encountered in order of importance: >> > >> > 1) Alerting seems to be inconsistent based on documentation. We have >> > configured /var/ossec/etc/ossec.conf to have: >> > >> > <syscheck> >> > <!-- Frequency that syscheck is executed -- default every 20 hours --> >> > <!-- changed default - blw <frequency>72000</frequency> --> >> > >> > <frequency>180</frequency> >> >> The extremely low frequency will cause issues. Realtime is "turned >> off" during full scans. > > > - I had it running with default for awhile and wasn't seeing what I expected, > so i lowered it based on article that I read > (https://blog.wpscans.com/using-ossec-to-monitor-directory-and-file-changes-in-wordpress/). > Having said that, i put it back to like 1800 and what is not making sense > to me is why if I have all those settings (specifically realtime), why am I > not immediately notified? Based on documentation, if I set the frequency to > be high, but have the settings set to 'monitor' changes for a directory - > what should I expect the timing to be for the alerting? This would be me > adding, editing and deleting files. If you are able to reproduce this > specific example, that would be helpful to tell me what timing you have for > the alerts for this. I just did an example where I added a file, modified > it, and then deleted it within the same minute and it took approximately 10 > minutes for it to alert me on the file added and I still don't have an alert > on the modification or deletion of the file. This is more about a sanity > check of the product to know what to expect so that I can be 100% sure how to > configure it for production systems. >
I don't think realtime works on new file alerting. It was intentionally left out of the original design due to overload concerns. I'm not sure if it's changed since then. A file would have to be scanned during a periodic scan before it'll register for realtime alerts. >> >> > <alert_new_files>yes</alert_new_files> >> > >> > <!-- Directories to check (perform all possible verifications) --> >> > <directories report_changes="yes" realtime="yes" >> > check_all="yes">/etc,/usr/bin,/usr/sbin</directories> >> > <directories report_changes="yes" realtime="yes" >> > check_all="yes">/bin,/sbin,/boot,/test</directories> >> > >> > >> > It seems that this has more impact on the agents than their own >> > /ossec.conf file as I had the local agents file contain the /test and was >> > adding/modifying/deleting files while also having restarting OSSEC both >> > from agent and server and was getting no alerting for /test files. When I >> > put it on the server as shown above, I started to get *some* alerts but >> > not for everything as expected. The issue is that I would create a file, >> > then I would edit the file several times as well as delete it and I would >> > only get some of those messages. I then created another file and tried to >> > simulate again and for this one I got no messages. My expectation with >> > this config is that I should get alerted every time for new files, >> > modifications, and deletes and at most I should have to wait is 3 minutes >> > (this is testing currently just so i don't have to wait). >> > >> > I have also configured /var/ossec/rules/local_rules.xml to alert on new >> > files added: >> > >> > <rule id="554" level="7" overwrite="yes"> >> > <category>ossec</category> >> > <decoded_as>syscheck_new_entry</decoded_as> >> > <description>File added to the system.</description> >> > <group>syscheck,</group> >> > </rule> >> > >> > >> > The next 'issue' will also go into the agent.conf as that was how I wanted >> > to configure it but that doesnt' appear to take effect no matter what I do. >> > >> > If someone could help address to what should be the proper configuration >> > (both from client/server side and which files to achieve what I'm after I >> > would appreciate it). >> > >> > >> > >> > 2) We're trying to do Centralized Agent Configuration and from what I read >> > on numerous sites and from OSSEC itself >> > (https://www.ossec.net/docs/manual/agent/agent-configuration.html), it >> > should be as simple as configuring /var/ossec/etc/shared/agent.conf on >> > the server and then it should take effect for the agents. It doesn't >> > matter what I seem to do here, it does not seem to take effect as I expect >> > for Linux vs Windows. Has anyone got this to work for Ubuntu 14 and if >> > so, can you help share troubleshooting steps for this as it seems like it >> > should be simple but when it's just not working I'm kind of at a loss what >> > to do. >> > >> >> This is extremely vague. > > > I essentially configured the agent.conf to be identical to what I had in the > ossec.conf file from the server except that I told the agent.conf to monitor > for /test directory for changes in realtime, etc. I did this under the LINUX > section and my agent system is Ubuntu so I expected after restarting both > server and agent that it would start alerting on changes from that directory > but it is not doing so. It was not until I configured it in the server's > ossec.conf file that it started alerting me of changes and this is not what I > would expect. I want to be able to say centrally through agent.conf server > file that all Linux machines have a template to check (as well as Windows > machines) and then if I want to be more granular I can add a section for > specific Agent. This is not working for me as I never see alerts. I'm not > sure what to review to understand what is wrong. I think it's "Linux", not "LINUX". I'm also not sure if that actually makes a difference. I rarely use the agent.conf features. When you restarted the agent's ossec processes, had the agent.conf been updated on that agent? The agent's processes have to be restarted after the agent.conf is updated. After that's complete, you should be able to check the agent's ossec.conf to see if "/test" is being monitored. Look for a line like this (your details will be different, and you want to look for '/test' instead of '/etc'): 2018/10/17 06:40:06 ossec-syscheckd: INFO: Monitoring directory: '/etc', with options perm | size | owner | group | sha256sum | genericsum. >> >> >> > >> > 3) The last issue we got around by doing a different installation, but if >> > I take the downloads from OSSEC from here >> > https://github.com/ossec/ossec-hids/archive/3.0.0.tar.gz - it installs >> > itself incorrectly on Ubuntu as 2.9 (which is very far behind). I tried >> > this on almost all versions of Ubuntu as well as Amazon Linux and same >> > issue. The reason why it mattered to us was that when we went to add >> > agents, they could never connect - they always sat there at waiting for >> > server response (even though server already sees the connection and >> > nothing was getting logged to OSSEC log file). We spent a long time >> > troubleshooting this and eventually went the route of automatic install >> > (previously our server did not have internet connection purposely for >> > testing so we had to download the package and copy over) and after doing >> > this - the version showed properly at 3.0 AND the same agents started >> > connecting. This isn't a huge issue for us at the moment, but it is a bit >> > confusing why this is happening so maybe someone can explain that so we >> > understand better. >> > >> >> The version wasn't properly updated in the source. It should be fixed >> in 3.1. I don't think this would cause an agent to not be able to >> connect though. > > > I won't bet my life on it, but this was the only thing that we changed and > the same agents started working. Either way, this is great news. What is ETA > for 3.1 delivery? > Now: https://github.com/ossec/ossec-hids/releases/tag/3.1.0 Packages are in process I guess? I don't mess with those. >> >> > >> > Thanks in advance, >> > ~Brandon >> > >> > -- >> > >> > --- >> > 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/d/optout. > > -- > > --- > 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/d/optout. -- --- 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/d/optout.
