Answers.Body: <p>How hard this will be depends on how determined the service abuser is to adapt to the defenses you introduce, and how easy a target your site is compared to other sites available to the attacker. If you are seeing a significant level of abuse, this indicates that your site is one of the lower hanging fruit.</p>
  
  <p>Here are a couple of options I've seen have good effect -</p>
  
  <p><strong>fail2ban</strong> - We've used <a href="http://www.fail2ban.org">fail2ban</a> effectively for assorted spam and abuse prevention. An approach to this looks like: </p>
  
  <ul>
  <li>Add a custom form validation hook to your contribute form.</li>
  <li>In this hook, <code>error_log</code> to some logfile.</li>
  <li>Add a fail2ban <em>jail</em> with this logfile which uses iptables to ban addresses that look suspicious.</li>
  </ul>
  
  <p>There is a risk of banning legitimate IPs here, eg a single IP which many supporters sit behind (maybe you are a union and half your members are behind a certain corporation's firewall) or your own head office if they make a large number of transactions. So this is an approach to use with some considerations.</p>
  
  <p>This approach is more effective if you are seeing repeat abuse from the same IP addresses; you can identify this by inspecting your webserver logs for the contributions (grep for POST requests hitting <code>civicrm/contribute/transact</code> then group by IP and count requests).</p>
  
  <p><strong>custom spam checks</strong> - I've seen form abuse drop off entirely simply by adding an additional required question. You can add this to your form, then use JS in your page to hide the field and populate it. This can be more effective than reCaptcha because reCaptcha is common enough to be worth automating for a botnet, but if your form is one of several they are outsourcing their CC checks to, then you only need to make your form less easy to abuse than others. </p>
  
  <p>This approach is effective against abuse where the attacking engine is less sophisticated than a web browser (ie lacks the JS engine in the browser). It's easy to test out.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-30T00:36:19.247Z
Answers.Text: @Chris brilliant!  Do you have source code you can share for this?
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-19T20:15:49.810Z
Answers.Text: @JonG we just struggled with this same issue. Per your request, about year late ;), here is a bit I wrote/installed to deter the current set of fraudsters: https://github.com/elisseck/com.elisseck.civihoneypot. Only works for contribution pages right now but should be pretty easily adaptable to other forms as well.
Answers.UserDisplayName: Eli Lisseck
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-19T14:55:11.073Z
Answers.Text: Thanks, Chris! I am considering implementing the second option here as the attempts are ongoing...
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-14T23:30:44.947Z
Answers.LastActivityDate: 2015-05-14T23:30:44.947Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <p>You can use the flood control extension posted on the CiviCRM blog <a href="https://civicrm.org/blogs/xcf33/civicrm-flood-control-use-case-and-implementation" rel="nofollow">here</a>.</p>
  
  <p>There's an even smaller extension that does the same thing, but is Drupal-specific <a href="http://forum.civicrm.org/index.php/topic,19243.msg90199.html#msg90199" rel="nofollow">here</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-19T14:54:05.527Z
Answers.Text: Also looking at implementing @Coleman's Drupal-based flood control script -- do you know what gets presented to an end-user who may get caught up in the new submission limits? Is there an error message of some kind?
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-08T13:39:43.277Z
Answers.Text: In that example the error message is generated in hook_civicrm_validate: "Sorry, for security reasons we do not allow more than two credit card transactions per day. Please try again later."
Answers.UserDisplayName: John
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-14T23:36:50.417Z
Answers.LastActivityDate: 2015-05-14T23:36:50.417Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>If you are using drupal you can use <a href="https://www.drupal.org/project/httpbl" rel="nofollow">https://www.drupal.org/project/httpbl</a>. One of it settings are: use on all pages (so, including civicrm contribution pages). It is being used on huge sites, among others drupal.org itself.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-19T14:49:36.607Z
Answers.Text: Trying this out now. In your experience does it solve things pretty quickly or take some time to phase the problems out?
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T15:33:00.350Z
Answers.Text: it should work very quickly
Answers.UserDisplayName: Catorghans
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-11T14:05:52.280Z
Answers.Text: httpbl doesn't help much with stopping/reducing fraud. It's more for spammers who will follow the links. Fraud is trying to complete the form. On our client that's getting fraud, they already have httpbl on all pages and it's not helping.
Answers.UserDisplayName: herb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-17T07:34:14.893Z
Answers.LastActivityDate: 2015-05-17T07:34:14.893Z
Answers.UserDisplayName: Catorghans
Body: <p>An org I work with is reporting heavy fraudulent use (at least attempts to use -- it seems many are being declined in Auth.net, although some are getting through) of the CiviContribute form, despite the "I'm not a Robot" reCAPTCHA that is in place.</p>
  
  <p><img src="https://i.sstatic.net/zVw1h.jpg" alt="I&#39;m not a Robot reCAPTCHA"></p>
  
  <p>What are other ways to prevent these types of fraudlent attempts besides the Captcha on a profile? (I thought the Captcha would prevent it from even showing up in Authorize.net)</p>
  
Tags: <civicontribute><security><authorize.net>
Title: How to prevent fraud attempts on Contribution pages?
ThreadText: # How to prevent fraud attempts on Contribution pages?
  
  (Asked by: username_0 on 2015-05-14)
  
  An org I work with is reporting heavy fraudulent use (at least attempts to use -- it seems many are being declined in Auth.net, although some are getting through) of the CiviContribute form, despite the "I'm not a Robot" reCAPTCHA that is in place.
  
  ![I'm not a Robot reCAPTCHA](https://i.sstatic.net/zVw1h.jpg)
  
  What are other ways to prevent these types of fraudlent attempts besides the Captcha on a profile? (I thought the Captcha would prevent it from even showing up in Authorize.net)
  
  **Tags:** civicontribute, security, authorize.net
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2015-05-14. Score: 7
  
  How hard this will be depends on how determined the service abuser is to adapt to the defenses you introduce, and how easy a target your site is compared to other sites available to the attacker. If you are seeing a significant level of abuse, this indicates that your site is one of the lower hanging fruit.
  
  Here are a couple of options I've seen have good effect -
  
  **fail2ban** - We've used [fail2ban](http://www.fail2ban.org) effectively for assorted spam and abuse prevention. An approach to this looks like:
  
  * Add a custom form validation hook to your contribute form.
  * In this hook, `error_log` to some logfile.
  * Add a fail2ban *jail* with this logfile which uses iptables to ban addresses that look suspicious.
  
  There is a risk of banning legitimate IPs here, eg a single IP which many supporters sit behind (maybe you are a union and half your members are behind a certain corporation's firewall) or your own head office if they make a large number of transactions. So this is an approach to use with some considerations.
  
  This approach is more effective if you are seeing repeat abuse from the same IP addresses; you can identify this by inspecting your webserver logs for the contributions (grep for POST requests hitting `civicrm/contribute/transact` then group by IP and count requests).
  
  **custom spam checks** - I've seen form abuse drop off entirely simply by adding an additional required question. You can add this to your form, then use JS in your page to hide the field and populate it. This can be more effective than reCaptcha because reCaptcha is common enough to be worth automating for a botnet, but if your form is one of several they are outsourcing their CC checks to, then you only need to make your form less easy to abuse than others.
  
  This approach is effective against abuse where the attacking engine is less sophisticated than a web browser (ie lacks the JS engine in the browser). It's easy to test out.
  
  > **Comments:**
  > **username_0**: Thanks, username_1! I am considering implementing the second option here as the attempts are ongoing...  
  > **username_2**: @username_1 brilliant!  Do you have source code you can share for this?  
  > **username_3**: @JonG we just struggled with this same issue. Per your request, about year late ;), here is a bit I wrote/installed to deter the current set of fraudsters: https://github.com/elisseck/com.elisseck.civihoneypot. Only works for contribution pages right now but should be pretty easily adaptable to other forms as well.  
  
  ---
  
  ### Answer by username_2 on 2015-05-14. Score: 3
  
  You can use the flood control extension posted on the CiviCRM blog [here](https://civicrm.org/blogs/xcf33/civicrm-flood-control-use-case-and-implementation).
  
  There's an even smaller extension that does the same thing, but is Drupal-specific [here](http://forum.civicrm.org/index.php/topic,19243.msg90199.html#msg90199).
  
  > **Comments:**
  > **username_0**: Also looking at implementing @Coleman's Drupal-based flood control script -- do you know what gets presented to an end-user who may get caught up in the new submission limits? Is there an error message of some kind?  
  > **username_4**: In that example the error message is generated in hook_civicrm_validate: "Sorry, for security reasons we do not allow more than two credit card transactions per day. Please try again later."  
  
  ---
  
  ### Answer by username_5 on 2015-05-17. Score: 2
  
  If you are using drupal you can use <https://www.drupal.org/project/httpbl>. One of it settings are: use on all pages (so, including civicrm contribution pages). It is being used on huge sites, among others drupal.org itself.
  
  > **Comments:**
  > **username_0**: Trying this out now. In your experience does it solve things pretty quickly or take some time to phase the problems out?  
  > **username_5**: it should work very quickly  
  > **username_6**: httpbl doesn't help much with stopping/reducing fraud. It's more for spammers who will follow the links. Fraud is trying to complete the form. On our client that's getting fraud, they already have httpbl on all pages and it's not helping.  
  
  ---
  
  