Yes, I'm 100% positive, Dan! I've just reproduced my steps, and it seems that whenever I run the rootcheck update (rootcheck_control -u 000) and wait for a rootcheck run to complete (Ending rootcheck scan.)
I don't see any log entries similar to the syscheck can like this 2016/04/05 08:24:50 ossec-syscheckd: INFO: Finished creating syscheck database (pre-scan completed). 2016/04/05 08:25:02 ossec-syscheckd: INFO: Ending syscheck scan (forwarding database). does this mean that rootcheck does not forward its results to the database? maybe I am doing something fundamentally wrong here, but at the moment rootcheck does not write its results into the database unless I restart OSSEC manually. rootcheck frequency is set to 300 (5 minutes) syscheck frequency is set to 79200 (22 hours) does rootcheck rely on syscheck in order to update the events in the database? Am Montag, 4. April 2016 14:41:56 UTC+2 schrieb dan (ddpbsd): > > On Sat, Apr 2, 2016 at 5:36 PM, theresa mic-snare > <[email protected] <javascript:>> wrote: > > Hi, > > > > I have to say I'm particularly unfortunate with the rootcheck > daemon...am I > > the only one who keeps running into those problems? > > > > On my manager I was checking against the system_audit_ssh.txt that > checks > > the sshd_config. > > I first started with the following unresolved issues > > > > [root@manager bin]# ./rootcheck_control -q -i 000 > > > > Policy and auditing events for local system 'manager - 127.0.0.1': > > > > Outstanding events: > > > > 2016 Apr 02 18:31:43 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 5: Password Authentication > > {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. Reference: 5 . > > > > 2016 Apr 02 18:31:43 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 7: Rhost or shost used for > > authentication {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. Reference: > 7 . > > > > 2016 Apr 02 18:31:43 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 8: Wrong Grace Time > {PCI_DSS: > > 2.2.4}. File: /etc/ssh/sshd_config. Reference: 8 . > > > > 2016 Apr 02 18:31:43 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 9: Wrong Maximum number of > > authentication attempts {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. > > Reference: 9 . > > > > > > So far, so good. > > I set the correct values inside sshd_config, restarted the sshd service > > and waited until the rootcheck run ran again... For the troubleshooting > sake > > I set the interval to 5 minutes. > > > > But for some reason it didn't update the Outstanding events..... only > > updated the time. > > > > [root@manager bin]# ./rootcheck_control -q -i 000 > > > > Policy and auditing events for local system 'manager - 127.0.0.1': > > > > Outstanding events: > > > > 2016 Apr 02 18:56:36 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 5: Password Authentication > > {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. Reference: 5 . > > > > 2016 Apr 02 18:31:43 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 7: Rhost or shost used for > > authentication {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. Reference: > 7 . > > > > 2016 Apr 02 18:56:36 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 8: Wrong Grace Time > {PCI_DSS: > > 2.2.4}. File: /etc/ssh/sshd_config. Reference: 8 . > > > > 2016 Apr 02 18:31:43 (first time detected: 2016 Apr 02 18:31:43) > > System Audit: System Audit: SSH Hardening - 9: Wrong Maximum number of > > authentication attempts {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. > > Reference: 9 . > > > > > > I checked the syntax of the system_audit_ssh.txt but this seemed good to > me > > For instance the MaxAuthTries has this syntax > > > > # MaxAuthTries 3 > > # The MaxAuthTries parameter specifices the maximum number of > authentication > > attempts permitted per connection. Once the number of failures reaches > half > > this value, additional failures are logged. > > # This should be set to 3. > > [SSH Hardening - 9: Wrong Maximum number of authentication attempts > > {PCI_DSS: 2.2.4}] [any] [9] > > f:$sshd_file -> !r:^# && r:MaxAuthTries && !r:3\s*$; > > f:$sshd_file -> r:^#\s*MaxAuthTries; > > f:$sshd_file -> !r:MaxAuthTries; > > > > my sshd_config has exact this value set "MaxAuthTries 3" > > > > At the end I simply ran > > [root@manager bin]# ./rootcheck_control -u 000 > > > > and waited for another rootcheck run. > > Unfortunately it needed a full ossec restart, because simply running > > returned nothing except an empty database > > > > [root@manager bin]# ./rootcheck_control -L -i 000 > > > > Policy and auditing events for local system 'manager - 127.0.0.1': > > > > Can someone maybe explain this behavior to me? > > Why does it need an ossec restart, when a regular rootcheck run is not > able > > Are you sure a scan ran after clearing the db? My guess would be that > you cleared the db, but didn't give the system enough time to run > another scan. Restarting OSSEC just triggered a full scan. > > > to update the Outstanding events successfully > > or in other words: > > Why is OSSEC not able to update the database even after it was flushed > using > > rootcheck_control - u 000 > > leaving the database empty until I restart OSSEC completely?? > > > > Maybe this is just another "Pebkac" error and me being just too stupid > to > > get it properly working... > > anyway, I would love to hear your experiences with rootcheckd and > > rootcheck_control > > > > I'm using VERSION="v2.9.0" at the moment, pulled from github. > > > > -- > > > > --- > > 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] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
