Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-83410

Seperate "Failed Login" PHP error to be independent of Debug level

XMLWordPrintable

    • MOODLE_405_STABLE
    • MDL-83410-failed-login
    • Hide

      1. Configure debugging to be off, i.e. Debug messages = "NONE: Do not show any errors or warnings" in settings
      2. Fail a login against a user in the Moodle
      3. Check your php error log and note the lack of Failed Login line
      4. Configure Moodle like this:

      $CFG->debugfailedlogin = true;

      5. Fail another login
      6. Confirm something matching this is now in your error log despite low debugging level:

       

      [21-Nov-2024 16:08:00] WARNING: [pool www] child 11 said into stderr: "NOTICE: PHP message: [client 192.0.2.1] https://site Failed Login: admin <user-agent>"

       

      Show
      1. Configure debugging to be off, i.e. Debug messages = "NONE: Do not show any errors or warnings" in settings 2. Fail a login against a user in the Moodle 3. Check your php error log and note the lack of Failed Login line 4. Configure Moodle like this: $CFG->debugfailedlogin = true ; 5. Fail another login 6. Confirm something matching this is now in your error log despite low debugging level:   [ 21 -Nov- 2024 16 : 08 : 00 ] WARNING: [pool www] child 11 said into stderr: "NOTICE: PHP message: [client 192.0.2.1] https://site Failed Login: admin <user-agent>"  

      This message is extremely useful when the Moodle instance is monitored by a security service such as a SIEMS. In these cases, the failed login message is extremely useful in detecting attack campaigns such credential stuffing.

      The emitting of this statement into the PHP error logs is currently gated behind a DEBUG_ALL flag check for site debugging, however as this is a security adjacent concern, it should be split into its own config item, seperate from the level of debugging.

      We are attempting to correlate a distributed credential stuffing campaign, however many of our sites are on DEBUG_NORMAL and so are missing these clues in the server logs, and splitting the config out allows us to force these to be logged across the fleet without forcing the debugging levels for all sites.

            jaydn Jaydn Cunningham
            peterburnett Peter Burnett
            Kevin Pham Kevin Pham
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.