Magento Question posted in
The official documentation can be found here.

Carding attack on Magento 2 / Braintree

I am trying to fend off carding attacks on a Magento 2 store.

The attacker manually creates a shopping cart and from it is able to send repeated requests to Braintree and my store to test credit card numbers. Our security measures quickly detect when this behavior happens from a single IP address but have been much less effective when the attack is distributed.

Surprisingly, Magento 2 allows for requests to come from multiple IP address even though they refer to a single session and shopping cart ID (Note: the security settings for validate REMOTE_ADDR, HTTP_VIA, HTTP_X_FORWARDED_FOR, and HTTP_USER_AGENT are all enabled). I am trying to get Magento’s attention to this problem. But in the meantime I am trying to find a workaround.

Take a look at the log below. As you can see these are requests coming from different IP addresses, but they refer to the same shopping cart id (oq2xk8h2h3ghvjrii93o in this case). I would like to create a mechanism that tracks the IP address used for each shopping cart id, and detects if there is an IP address change for an individual cart id. If such change happens, the IP addresses used for the shopping cart get banned, as well as any subsequent IP addresses that try to use the same shopping cart id.

We already have in place: Cloudflare (free), fail2ban, mod_security with OWASP rules. We can leverage and of these.

209.127.191.180, 173.245.52.210, 127.0.0.1 - - [06/Aug/2020:06:05:48 -0400] foobar.com "POST /rest/foobar_view/V1/guest-carts/oq2xk8h2h3ghvjrii93o/payment-information HTTP/1.0" 400 689 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36"
185.164.56.185, 162.158.63.7, 127.0.0.1 - - [06/Aug/2020:06:06:01 -0400] foobar.com "POST /rest/foobar_view/V1/guest-carts/oq2xk8h2h3ghvjrii93o/payment-information HTTP/1.0" 400 689 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36"
45.95.99.226, 162.158.78.135, 127.0.0.1 - - [06/Aug/2020:06:06:15 -0400] foobar.com "POST /rest/foobar_view/V1/guest-carts/oq2xk8h2h3ghvjrii93o/payment-information HTTP/1.0" 400 689 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36"
193.8.127.117, 162.158.62.120, 127.0.0.1 - - [06/Aug/2020:06:06:27 -0400] foobar.com "POST /rest/foobar_view/V1/guest-carts/oq2xk8h2h3ghvjrii93o/payment-information HTTP/1.0" 400 689 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36"

My initial thought was to "watch" the log file, and whenever there is a request that matches the pattern, save the IP address, the shopping cart ID and the timestamp in a separate file. Then generate a separate log file that will contain just the IP addresses I want to ban, and then use fail2ban to read this log file and do the rest.

I have been able to create custom filter/jail/action in fail2ban, the main challenge I have now is the part of "watching" the original server log, and then creating my custom log of bad IP addresses.

Thank you for your help!

Tags:

2

Answers


  1. 0

    You may want to see my fail2ban example Here:

    vi /etc/fail2ban/filter.d/restapi.conf

[INCLUDES]
before = restapi.conf
[Definition]
failregex = ^ - .* "POST.HTTP." 400 .*$

vi /etc/fail2ban/filter.d/restapi.conf

[restapi]
enabled = true
port = http,https
filter = restapi
logpath = /var/www/vhosts/yourdomain.com/logs/access_ssl_log
bantime = 86400
findtime = 1200
maxretry = 5

service fail2ban restart

    In short, fail2ban watches the log file so no need for a separate watcher.

    Login or Signup to reply.
  2. 0

    The only thing that helps is reCaptcha unfortunately.

    Plain attacks via single IP address or single CartID are no longer used.

    Recent attacks include:

    • random IP addresses from all over the world
    • random CartID, generated on Magento 2.3.x sites that are unprotected

    So fail2ban will not actually help.

    reCaptcha is included in Magento 2.4.x, if you have 2.3.x you will need to get a separate plugin – https://swissuplabs.com/magento-google-recaptcha.html. This is a solid plugin.

    If you cant do any of these, just disable Guest Cart and start working towards reCaptcha installation.

    If you use Cloudflare, you can put your site "Under Attack Mode" – that puts a javascript challenge in front of the attackers and stops them.

    I also recommend putting your payment gateway into authorize only mode. This is so you do not get into trouble with payment provider as you wont need to refund the transactions that went through.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search