anyone? rootcheck is still an unresolved mystery to me.... Am Dienstag, 5. April 2016 12:07:40 UTC+2 schrieb theresa mic-snare: > > 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]> 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.
