On Sat, Apr 2, 2016 at 5:36 PM, theresa mic-snare <[email protected]> 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]. > 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.
