• Resolved jlee2027

    (@jlee2027)


    I’m seeing repeating log attacks with a 499 timeout error. Different IP’s …

    It gets worse and I have to reboot the website because it stops responding.

    How can I stop this?

    2017-08-23 12:00:07 Error 170.150.185.150 499 GET /xmlrpc.php HTTP/1.1
    2017-08-23 12:00:39 Error 170.150.185.150 499 GET /wp-login.php HTTP/1.1
    2017-08-23 12:01:11 Error 170.150.185.150 499 GET /wp-login.php HTTP/1.1
    2017-08-23 12:01:43 Error 170.150.185.150 499 GET /wp-login.php HTTP/1.1
    2017-08-23 12:02:15 Error 170.150.185.150 499 GET /wp-login.php HTTP/1.1

    2017-08-23 11:13:20 Error 189.76.233.145 499 GET /wp-login.php HTTP/1.1
    2017-08-23 11:13:51 Error 189.76.233.145 499 GET /wp-login.php HTTP/1.1
    2017-08-23 11:15:14 Error 65.94.86.78 405 GET /xmlrpc.php HTTP/1.1
    2017-08-23 11:15:14 Error 65.94.86.78 499 GET /wp-login.php HTTP/1.1
    2017-08-23 11:15:14 Error 65.94.86.78 499 GET /wp-login.php HTTP/1.1
    2017-08-23 11:15:14 Error 65.94.86.78 499 GET /wp-login.php HTTP/1.1
    2017-08-23 11:15:15 Error 65.94.86.78 499 GET /wp-login.php HTTP/1.1

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter jlee2027

    (@jlee2027)

    And down again….

    You are running under a Nginx web-server..
    499 is used by Nginx to tell you that the client closed the connection before the web-serve could manage to respond. Which is in itself unusual.

    It could be that the client is ACTUALLY closing, or that you have separate security in front of your web-server that catches the attacks and closes the back-end connection to your site. All depending on your configuration.

    If front-end security is setup correctly though, your web-server should never even see a connection. I do it that way myself. I do NOT want to even waste time “talking” to these hacker-bots, so I simply slam the door (close the connection) on them with no other response. (Same method I use on Tele-Marketers when they call. 🙂 )

    On why NGinx has to be restarted/rebooted, something in your site is stopping your NGinx server from closing the connection probably. Back-end processing in NGinx, a plugin or even WordFence logging that haven’t happened yet, MemCached not responding (if used), got stuck waiting on the DB server, …, … An endless list of things could slow down your server’s response the the remote closure. Need to be debugged.

    If the brute force attack comes in fast enough, the server can end up using up all it’s available TCP connections, and hence cannot respond anymore. No more free rooms (connection entries) at the inn.

    If you do a ‘netstat’ or ‘netstat -a’ from the command line, you will likely see all these open connections.

    Watch the State column.. If the TCP State is ‘CLOSE_WAIT’, that means that the remote end sent a FIN to close the connection, but your operating system is waiting for your local process (Nginx I assume for now) to close it before the records can be freed up.

    Depending on how many available connections are configured, you can as mentioned run out of space for new connections, and you will see that as no response from the server.

    One of the ways to take down a web server if it cannot respond and clean up fast enough. 🙂

    BTW.. I see that you are using PHP-7.0.22.. That version is known to be the default PHP7 and to be acting goofy to down-right failing on some hosting environments.
    You might want to flip up to a later version.
    Probably not related to your 499s, though.

    Hi @jlee2027,

    Indeed, the error code (499) indicates that the client closed the connection before the web server managed to respond.

    Now there are several possible reasons why this is happening.

    It could be something upstream closing the connection; but it could also be caused by the server being too slow to respond or some configuration issue.

    In all cases I strongly advise you get in touch with your hosting provider so they can further investigate and identify the cause of this behaviour.

    Thread Starter jlee2027

    (@jlee2027)

    Ok, the 499 is solved. It was a PHP Pool issue where pm.max.children was 5. Rather silly that the default PHP would set itself to only 5 instances but I digress. When it reached a need for 6, it waited 30 seconds, then NGINX timed it out. I increased the pm.max.children, rebuilt PHP (reboot will not do it, you must rebuild) and the 499 is gone.

    Thank you all for your support Caleb and wfyAnn, definitely helped!

    I’m still getting
    2017-08-26 08:34:47 Error 219.85.235.75 405 GET /xmlrpc.php HTTP/1.1
    2017-08-26 08:34:49 Error 219.85.235.75 503 GET /wp-login.php HTTP/1.1
    2017-08-26 08:34:49 Error 219.85.235.75 503 GET /wp-login.php HTTP/1.1
    2017-08-26 08:34:50 Error 219.85.235.75 503 GET /wp-login.php HTTP/1.1
    2017-08-26 08:34:53 Error 219.85.235.75 503 GET /wp-login.php HTTP/1.1

    Ignore the 405 and 503. I’m telling WordPress what to send them hopefully to discourage them from hitting our server, but regular attempts with different IP’s are still happening.

    Is there a way to block these attempts? TIA.

    • This reply was modified 8 years, 8 months ago by jlee2027.

    Hi @jlee2027,

    Thanks for the feedback.

    In case it applies you could use the Block IP’s who send POST requests with blank User-Agent and Referer feature (Wordfence -> Options -> Other Options section).

    Also if you identify a pattern in the User-Agent you could block requests with such User-Agent by specifying it in the “User-Agent (browser) that matches” field (Wordfence -> Blocking -> Advanced Blocking).

    Let me know if this helps.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘499 error GET wp-login.php errors in logs’ is closed to new replies.