Thanks to your help, I was able to help clear up errors when I restarted configuration and then learned more about Centralized configuration here: https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html. I still cannot get the Ubuntu client to take the central server's agent.conf. The file version never changes on the client and I basically gave up on that after reading many articles with people with complaints about how well that worked. I think I will just stick to configuring the OSSEC.conf file on each agent and doing it that way.
I think i'll wait until 3.1 shows up on the downloads section before installing that, but it looks like it solves a lot of bugs so that's promising. On Wednesday, October 17, 2018 at 7:39:19 AM UTC-4, dan (ddpbsd) wrote: > > On Tue, Oct 16, 2018 at 4:25 PM 'Brandon' via ossec-list > <ossec...@googlegroups.com <javascript:>> 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 > >> <ossec...@googlegroups.com> 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 ossec-list+...@googlegroups.com. > >> > 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 ossec-list+...@googlegroups.com <javascript:>. > > 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
