You’ve been hit by a carding attack, huh? This is when a bot places a ton of orders on your site using a batch of stolen credit card numbers. Normally the attack isn’t to defraud your site, it’s to test the validity of the credit cards and address data they have so they can then sell them or use them elsewhere on high value targets.
Well we’ve got a fail2ban solution for you. As long as your site doesn’t use the rest api that is. If your unsure, you can tail your access logs while browsing your site and look for anything related to rest with a 400 response code. (tail -f access_ssl_log |grep 400)
vi /etc/fail2ban/filter.d/restapi.conf
[INCLUDES]
before = restapi.conf
[Definition]
failregex = ^ - .* "POST.HTTP." 400 .*$
vi /etc/fail2ban/jail.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
fail2ban-client status restapi
Hi,
Thank you for your sharing in Github.
I’m not a pro with Fail2Ban, but as I understand, your solution will only block access from external request right?
I mean, if Magento and is extension payment gateway call the URL /rest//V1/guest-carts//payment-information will it work?
Because if not, that it means the users can’t order any longer in the website…
Hi,
Thanks for writing. Fail2ban monitors the log file we specify. So in this example its an apache log file. The ip address being logged is the users external ip address. If you are behind a proxy, lb, or cdn that mask the users ip address, you will need to setup apache to log the X_FORWARDED header for that proxy/lb/cdn as directed by that vendor. Once you have apache logging the correct external ip, you can trust fail2ban. Additionally in fail2ban conf you can specify an ignore list. You should add the server ip to this ignore list if you think there is a chance of it coming up in the logs for access.
Hope this helps.