Missing ossec-hids in logrotate.d

[Scott Wozny]

I'm trying to get off the Atomic repo for a variety of reasons, so I just did a 3.6.0 agent install from the tarball's script on a CentOS 7 minimal machine to test the process and compatibility with my build tweaks.  One of the issues I had with the Atomic repo 3.3.0 package install was /var/ossec/logs was of SELinux fcontext var_t rather than var_log_t which made those files inaccessible on an enforcing machine to logrotate_t.  An easy fix, but I never got around to doing it.  Now I see there is no ossec-hids script in /etc/logrotate.d.  Is this intentional (as in, I need to roll my own) or could something have gone wrong during the install?  I didn't see anything in /var/log/messages or journalctl and /var/ossec/logs/ossec.log (the only file in that directory) is empty.  Is there anywhere that install results are logged or am I just expected to go through the output after ./install.sh?

Any assistance or suggestions would be appreciated.

Thanks,

Scott

[dan (ddp)]

On Mon, Jun 15, 2020 at 3:09 PM Scott Wozny <saw...@gmail.com> wrote:
>
> I'm trying to get off the Atomic repo for a variety of reasons, so I just did a 3.6.0 agent install from the tarball's script on a CentOS 7 minimal machine to test the process and compatibility with my build tweaks. One of the issues I had with the Atomic repo 3.3.0 package install was /var/ossec/logs was of SELinux fcontext var_t rather than var_log_t which made those files inaccessible on an enforcing machine to logrotate_t. An easy fix, but I never got around to doing it. Now I see there is no ossec-hids script in /etc/logrotate.d. Is this intentional (as in, I need to roll my own) or could something have gone wrong during the install? I didn't see anything in /var/log/messages or journalctl and /var/ossec/logs/ossec.log (the only file in that directory) is empty. Is there anywhere that install results are logged or am I just expected to go through the output after ./install.sh?
>
> Any assistance or suggestions would be appreciated.
>

We don't include a log rotate script.
We don't log anything in the install.sh (I usually tee it to a file
when I'm curious).
If ossec.log is empty, ossec probably isn't running. Or maybe an selinux issue?

> Thanks,
>
> Scott
>
> --
>
> ---
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/63ff1d8d-3877-48b4-b3c1-d558b4427219o%40googlegroups.com.

[Scott Wozny]

Thanks for the reply, Dan.  I'll probably roll my own logrotate script and use the one from the Atomic repo 3.3.0 install as a base.  And yes, ossec.log was empty because I hadn't started the agent yet.  I had assumed a different purpose for that file, but now that I'm running a few agents reporting to a server it all makes more sense now.  :)

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/CAMyQvMq0y6SB1EHeNaT7hZxh%2BvYaGXnrZRnn6VEQgvXo7vF93A%40mail.gmail.com.

[Scott Wozny]

OK, so after a little more digging, I see now why there is no logrotate script that comes with the build from source since the files in /var/ossec/logs/alerts, archives and firewall are managed and compressed by ossec, itself.  :)

This leaves me with a couple questions, though.

1) Is the size of ossec.log managed in the same way or should I have a plan for handling that file as it grows (logrotate or whatever)?  I didn't see a date based storage structure like with the other 3 log subdirectories (and the ossec.log has more than a day's worth of data, unlike the other 3), but I wanted to confirm. 

2) Can / should I be monitoring /var/ossec/logs/ossec.log?  My only concern is creating some sort of infinite loop situation where I create a line in the file that causes an alert that causes another line to be created in the file that causes another alert etc... until the disk fills up.

3) This is a little off-topic, but what is the purpose of firewall.log?  I can't seem to find any reference in the documentation.

Thanks,

Scott

[dan (ddp)]

On Wed, Jun 17, 2020 at 5:06 PM Scott Wozny <saw...@gmail.com> wrote:
>
> OK, so after a little more digging, I see now why there is no logrotate script that comes with the build from source since the files in /var/ossec/logs/alerts, archives and firewall are managed and compressed by ossec, itself. :)
>
> This leaves me with a couple questions, though.
> 1) Is the size of ossec.log managed in the same way or should I have a plan for handling that file as it grows (logrotate or whatever)? I didn't see a date based storage structure like with the other 3 log subdirectories (and the ossec.log has more than a day's worth of data, unlike the other 3), but I wanted to confirm.

OSSEC does not manage the ossec.log file.

> 2) Can / should I be monitoring /var/ossec/logs/ossec.log? My only concern is creating some sort of infinite loop situation where I create a line in the file that causes an alert that causes another line to be created in the file that causes another alert etc... until the disk fills up.

I think that's why it isn't monitored by default. I'd be wary of
monitoring it with itself. Not to say it can't be done, but you'd have
to be careful.

> 3) This is a little off-topic, but what is the purpose of firewall.log? I can't seem to find any reference in the documentation.
>

I don't know. I think the idea was that firewalls log a lot of stuff
all the time, and you don't necessarily want them clogging up the
usual log files. But that's just a guess.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/CACUKT_rS8KZL_GHTBQCSARCa%3D-tQ4f4XtTkZxoSzfcV4sXZwbQ%40mail.gmail.com.

[Scott Wozny]

Cool! Thanks again for the feedback. :)

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/CAMyQvMqwcZdzJDYEtUQ%2B-a0EdxDmvwJD_O8zr0fLpYn07ykxSQ%40mail.gmail.com.