Answers.Body: <p>For future reference, here is how we solved this issue:</p>
  <p>We implemented the below changes, which have successfully deterred a card testing attack since:</p>
  <ul>
  <li><p>Installed the Civi Firewall extension (<a href="https://lab.civicrm.org/extensions/firewall" rel="nofollow noreferrer">https://lab.civicrm.org/extensions/firewall</a>). This extension works alongside the Stripe extension to automatically block IP addresses whose payment attempts return fraudulent or blocked status from Stripe. Highly recommend this as a first step.</p>
  </li>
  <li><p>Worked with MJW Consulting to add and install a function to the Stripe Extension which sets a global minimum payment amount for the Stripe Extension (in our case, a $10 limit, as all testing transactions were less than that). This prevents the payment requests from ever reaching Stripe, if under the limit. I am not 100% sure if this feature will be included in Stripe Extension 6.8 for all users, but it is a really great feature.</p>
  </li>
  <li><p>Enabled Stripe's Radar feature temporarily to identify IP addresses carrying out the attack that weren't rotating and block at the web server firewall (had a few Microsoft Azure IPs in the mix that were being heavily reused).</p>
  </li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-12-16T01:08:40.847Z
Answers.LastActivityDate: 2022-12-16T01:08:40.847Z
Answers.UserDisplayName: MattEMBA
Answers.Body: <p>Welcome to SE!  Are you using <a href="https://lab.civicrm.org/extensions/firewall" rel="nofollow noreferrer">https://lab.civicrm.org/extensions/firewall</a> ?  Not sure whether it will help with rotating IP's but worth looking at.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-30T23:50:15.787Z
Answers.Text: Thanks! We will check that out. We do use the Joomla Extension "Admin Tools Professional" https://www.akeeba.com/products/admin-tools.html, which includes a firewall feature we do have deployed. However, we aren't aware of any features in that extension that would help in this situation, as the attacker was rotating multiple-thousand IPs per hour.
Answers.UserDisplayName: MattEMBA
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-30T21:18:25.947Z
Answers.LastActivityDate: 2022-09-30T21:18:25.947Z
Answers.UserDisplayName: Aidan
Answers.Body: <p>This does not help your situation but for Drupal users, if you use CiviWebform Integration for your contribution pages. You can set it so that the user/ip cannot process the form more than Xs in an hour.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-30T23:51:53.903Z
Answers.Text: Good to know! Even if we were Drupal and used the CiviWebform Integration, I suspect that type of user/IP blocking would not have worked in this case, as the page does not require login and the user was rotating IPs with each request. Seems like we need a solution that isn't IP-based.
Answers.UserDisplayName: MattEMBA
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-01T17:43:46.503Z
Answers.Text: Rate limiting is the key here, as Iowa Boy says. I'm unfamiliar with how to do this on Joomla! forms, but there will be a way and this approach will save you this kind of headache in the future.
Answers.UserDisplayName: JohnFF
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-03T17:36:45.043Z
Answers.Text: I will look into options to rate-limit the frequency which the page can be served all-together. This will need to be purely based on page loads, since we don't want to require login and the attackers rotated IPs. That may prove a little blunt but we don't receive a high frequency of simultaneously donations anyway. Thank you!
Answers.UserDisplayName: MattEMBA
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-30T23:22:37.483Z
Answers.LastActivityDate: 2022-09-30T23:22:37.483Z
Answers.UserDisplayName: Iowa Boy
Answers.Body: <p>One of the easiest ways to prevent your site from being used for credit card tumbling is to set a minimum amount on your donation form. The reason card tumbling is always with small $ amounts is b/c they are trying to stay under the radar from a card holder’s perspective (until they find a set of credentials that works - and then go big).</p>
  <p>Re: <a href="https://home.iatspayments.com/blog/why-credit-card-processing-matters-for-your-business/" rel="nofollow noreferrer">https://home.iatspayments.com/blog/why-credit-card-processing-matters-for-your-business/</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-02T00:07:39.207Z
Answers.Text: is there a magic # that you suggest going above? Does it have to be above $X to get into the CC radar?
Answers.UserDisplayName: Iowa Boy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-02T13:54:28.850Z
Answers.Text: Added a reference -> suggestion there is $15 minimum
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-03T17:31:38.727Z
Answers.Text: Setting a minimum donation is a great idea, had not considered that but every charge was exactly $2, so that would have helped at least prevent the transactions from reaching Stripe. Thank you!
Answers.UserDisplayName: MattEMBA
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-03T21:46:54.967Z
Answers.Text: I recommend you read the Re I attached in my answer. It explains Fraud and has more tips on how to prevent it (setting a minimum is just one of them).
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-08-10T22:44:22.530Z
Answers.Text: noting a site we support just got hit with thousands of $35 ones
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-01T23:02:45.790Z
Answers.LastActivityDate: 2022-10-02T13:53:59.090Z
Answers.LastEditDate: 2022-10-02T13:53:59.090Z
Answers.UserDisplayName: KarinG - Semper IT
Answers.Body: <p>I wanted to point out a recent question/answer I had
  <a href="https://civicrm.stackexchange.com/questions/42645/server-access-error-for-event-registration-with-credit-card/42690#42690">Server access error for event registration with credit card</a></p>
  <p>Where in order to make event registration work I had to change the ACL for the  ajax api &quot;public&quot; which I never had needed before.  I think that is a bug that was somehow introduced somewhere in the interaction of Joomla and Civicrm.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-10-30T19:03:23.333Z
Answers.LastActivityDate: 2022-10-30T19:03:23.333Z
Answers.UserDisplayName: Elin
Body: <p>We have experienced recent malicious credit card testing attacks against our Civi/Joomla/Stripe site's Contribute pages. How have others successfully deterred such attacks?</p>
  <p><strong>Our site:</strong></p>
  <ul>
  <li>CiviCRM 5.52.2</li>
  <li>Joomla! 3.10.11</li>
  <li>Stripe Processor 6.7.10</li>
  </ul>
  <p>We use a publicly accessible Civi Contribute page for donations. Up until these attacks yesterday, Joomla login was not required for a user to submit a donation payment on this page. Ideally, we would like to remove the login requirement again to provide a seamless path to donation for non-members.</p>
  <p><strong>What happened:</strong></p>
  <p>Our publicly accessible Civi Contribute donation page started receiving invalid $2 charge attempts at a frequency of ~1 charge per second. Stripe successfully identified these as spam and thankfully blocked every charge (10k+ individual charges).</p>
  <p>The frequency of requests to the web server brought the site to a crawl. Accessing the web GUI for Civi and Joomla was nearly impossible. The database also spun up to consume 95% of our available CPU while attempting to handle the queries associated with each malicious charge attempt.</p>
  <p>Using Stripe Radar and the Apache access logs, we determined that the attackers were using rotating IP addresses (many hundred per hour).</p>
  <p><strong>What we did (in order):</strong></p>
  <ul>
  <li><p>Blocked some of the recurring malicious IPs addresses using our firewall. This did not help, as the attacker just rotated IPs.</p>
  </li>
  <li><p>Added a reCAPTCHA to the Civi Contribute page. This did not have any effect on the attacks.</p>
  </li>
  <li><p>Blocked access to the Civi AJAX API using an Apache .htaccess RewriteRule. This stopped the invalid charges from reaching Stripe but also expectedly broke legitimate payment requests.</p>
  </li>
  <li><p>In the web GUI, modified the Joomla Access Control setting for &quot;CiviCRM: access AJAX API&quot; to only be allowed for logged-in Joomla users.</p>
  </li>
  </ul>
  <p>After blocking non-logged in users from submitting payments we continued to see attack requests at a high frequency for another 3 hours. All those requests were correctly returned a 403 or 500 error. The database took 3 hours to finish processing the queries for the malicious payment attempts.</p>
  <p>How have others successfully deterred such attacks? What additional mitigation would folks recommend if want to remove the login requirement from the Contribute page?</p>
  <p>Thank you!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-10-30T19:04:39.410Z
Comments.Text: I think this is possibly Joomla specific, but you already have 5 tags.
Comments.UserDisplayName: Elin
Tags: <civicontribute><contributions><contribution-page><stripe><security>
Title: How do we deter malicious Civi Contribute credit card testing?
ThreadText: # How do we deter malicious Civi Contribute credit card testing?
  
  (Asked by: username_0 on 2022-09-30)
  
  We have experienced recent malicious credit card testing attacks against our Civi/Joomla/Stripe site's Contribute pages. How have others successfully deterred such attacks?
  
  **Our site:**
  
  * CiviCRM 5.52.2
  * Joomla! 3.10.11
  * Stripe Processor 6.7.10
  
  We use a publicly accessible Civi Contribute page for donations. Up until these attacks yesterday, Joomla login was not required for a user to submit a donation payment on this page. Ideally, we would like to remove the login requirement again to provide a seamless path to donation for non-members.
  
  **What happened:**
  
  Our publicly accessible Civi Contribute donation page started receiving invalid $2 charge attempts at a frequency of ~1 charge per second. Stripe successfully identified these as spam and thankfully blocked every charge (10k+ individual charges).
  
  The frequency of requests to the web server brought the site to a crawl. Accessing the web GUI for Civi and Joomla was nearly impossible. The database also spun up to consume 95% of our available CPU while attempting to handle the queries associated with each malicious charge attempt.
  
  Using Stripe Radar and the Apache access logs, we determined that the attackers were using rotating IP addresses (many hundred per hour).
  
  **What we did (in order):**
  
  * Blocked some of the recurring malicious IPs addresses using our firewall. This did not help, as the attacker just rotated IPs.
  * Added a reCAPTCHA to the Civi Contribute page. This did not have any effect on the attacks.
  * Blocked access to the Civi AJAX API using an Apache .htaccess RewriteRule. This stopped the invalid charges from reaching Stripe but also expectedly broke legitimate payment requests.
  * In the web GUI, modified the Joomla Access Control setting for "CiviCRM: access AJAX API" to only be allowed for logged-in Joomla users.
  
  After blocking non-logged in users from submitting payments we continued to see attack requests at a high frequency for another 3 hours. All those requests were correctly returned a 403 or 500 error. The database took 3 hours to finish processing the queries for the malicious payment attempts.
  
  How have others successfully deterred such attacks? What additional mitigation would folks recommend if want to remove the login requirement from the Contribute page?
  
  Thank you!
  
  **Tags:** civicontribute, contributions, contribution-page, stripe, security
  
  > **Comments:**
  > **username_1**: I think this is possibly Joomla specific, but you already have 5 tags.  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_0 on 2022-12-16. Score: 2 | Accepted answer
  
  For future reference, here is how we solved this issue:
  
  We implemented the below changes, which have successfully deterred a card testing attack since:
  
  * Installed the Civi Firewall extension (<https://lab.civicrm.org/extensions/firewall>). This extension works alongside the Stripe extension to automatically block IP addresses whose payment attempts return fraudulent or blocked status from Stripe. Highly recommend this as a first step.
  * Worked with MJW Consulting to add and install a function to the Stripe Extension which sets a global minimum payment amount for the Stripe Extension (in our case, a $10 limit, as all testing transactions were less than that). This prevents the payment requests from ever reaching Stripe, if under the limit. I am not 100% sure if this feature will be included in Stripe Extension 6.8 for all users, but it is a really great feature.
  * Enabled Stripe's Radar feature temporarily to identify IP addresses carrying out the attack that weren't rotating and block at the web server firewall (had a few Microsoft Azure IPs in the mix that were being heavily reused).
  
  
  ---
  
  ### Answer by username_2 on 2022-09-30. Score: 1
  
  Welcome to SE! Are you using <https://lab.civicrm.org/extensions/firewall> ? Not sure whether it will help with rotating IP's but worth looking at.
  
  > **Comments:**
  > **username_0**: Thanks! We will check that out. We do use the Joomla Extension "Admin Tools Professional" https://www.akeeba.com/products/admin-tools.html, which includes a firewall feature we do have deployed. However, we aren't aware of any features in that extension that would help in this situation, as the attacker was rotating multiple-thousand IPs per hour.  
  
  ---
  
  ### Answer by username_3 on 2022-09-30. Score: 1
  
  This does not help your situation but for Drupal users, if you use CiviWebform Integration for your contribution pages. You can set it so that the user/ip cannot process the form more than Xs in an hour.
  
  > **Comments:**
  > **username_0**: Good to know! Even if we were Drupal and used the CiviWebform Integration, I suspect that type of user/IP blocking would not have worked in this case, as the page does not require login and the user was rotating IPs with each request. Seems like we need a solution that isn't IP-based.  
  > **username_4**: Rate limiting is the key here, as username_3 says. I'm unfamiliar with how to do this on Joomla! forms, but there will be a way and this approach will save you this kind of headache in the future.  
  > **username_0**: I will look into options to rate-limit the frequency which the page can be served all-together. This will need to be purely based on page loads, since we don't want to require login and the attackers rotated IPs. That may prove a little blunt but we don't receive a high frequency of simultaneously donations anyway. Thank you!  
  
  ---
  
  ### Answer by username_5 on 2022-10-01. Score: 1
  
  One of the easiest ways to prevent your site from being used for credit card tumbling is to set a minimum amount on your donation form. The reason card tumbling is always with small $ amounts is b/c they are trying to stay under the radar from a card holder’s perspective (until they find a set of credentials that works - and then go big).
  
  Re: <https://home.iatspayments.com/blog/why-credit-card-processing-matters-for-your-business/>
  
  > **Comments:**
  > **username_3**: is there a magic # that you suggest going above? Does it have to be above $X to get into the CC radar?  
  > **username_5**: Added a reference -> suggestion there is $15 minimum  
  > **username_0**: Setting a minimum donation is a great idea, had not considered that but every charge was exactly $2, so that would have helped at least prevent the transactions from reaching Stripe. Thank you!  
  > **username_5**: I recommend you read the Re I attached in my answer. It explains Fraud and has more tips on how to prevent it (setting a minimum is just one of them).  
  > **username_6**: noting a site we support just got hit with thousands of $35 ones  
  
  ---
  
  ### Answer by username_1 on 2022-10-30. Score: 0
  
  I wanted to point out a recent question/answer I had
  [Server access error for event registration with credit card](https://civicrm.stackexchange.com/questions/42645/server-access-error-for-event-registration-with-credit-card/42690#42690)
  
  Where in order to make event registration work I had to change the ACL for the ajax api "public" which I never had needed before. I think that is a bug that was somehow introduced somewhere in the interaction of Joomla and Civicrm.
  
  
  ---
  
  