Frage:
Umgang mit übermäßigen "Kardier" -Versuchen
jkphl
2012-08-29 18:50:34 UTC
view on stackexchange narkive permalink

Wir richten derzeit Magento auf einem LAMP-Stack für unsere E-Commerce-Plattform ein. Seit ein oder zwei Monaten bemerken wir viele Kardierversuche gegen unsere Website. Alle versuchten Transaktionen würden für einen kleinen Betrag durchgeführt, nur um zu überprüfen, ob ihre Kreditkarte gültig ist. Wenn einer abgelehnt wird, versuchen sie es normalerweise wiederholt, indem sie die Kartennummer wiederholt um 1 oder 2 Nummern ändern. Diese Versuche erfolgen sehr schnell nacheinander. Wie Sie sich vorstellen können, summiert sich dies schnell in unserem Kreditkartenprozessorsystem und oft werden wir für einen kurzen Zeitraum heruntergefahren, um weitere Versuche zu verhindern.

Die meisten Angriffe kamen von außerhalb des USA und wir sind ein reines US-Unternehmen, daher haben wir mod_geoip verwendet, um den gesamten Datenverkehr von außerhalb des Landes abzulehnen. Dies hat bei den Massenangriffen geholfen, aber wir bekommen immer noch Leute, die aus den USA stammen. Ich bin wirklich daran interessiert zu wissen, was hier los ist. Wie richten sie Skripte für solche Massenversuche ein? Kann ich wirklich noch etwas tun, um das auszumerzen? Jeder Einblick in diese Art von Angriffen ist willkommen!

Diese Frage war IT-Sicherheitsfrage der Woche .
Lesen Sie die 14. September 2012 Blogeintrag für weitere Details oder Senden Sie Ihre eigene Frage der Woche.

Benötigen Sie eine Benutzeradresse als Teil Ihrer Transaktionsinformationen?
"Wenn man abgelehnt wird, versucht man es normalerweise wiederholt, indem man die Kartennummer wiederholt um 1 oder 2 Nummern ändert" - Das klingt nicht richtig. CC-Nummern werden mit dem Luhn-Algorithmus selbst überprüft. Ich denke, Sie müssten mehr als eine oder zwei Ziffern ändern, um eine gültige Nummer zu erhalten. In jedem Fall können Sie diese Versuche einschränken, indem Sie von Ihrer Site auch eine Prüfsummenvalidierung für jede eingegebene Karte durchführen lassen. Dies hilft auch bei der Benutzerfreundlichkeit. Dies soll verhindern, dass eine Nummer falsch eingegeben wird.
Acht antworten:
Jeff Ferland
2012-08-29 21:32:28 UTC
view on stackexchange narkive permalink

Angesichts der starken Überprüfung von Name / Adresse usw. ist es sehr wahrscheinlich, dass Ihre Site unterschiedliche Werte für verschiedene Fehlertypen zurückgibt. Das Beste, was Sie tun können, um Kartentests zu verhindern, ist sicherzustellen, dass abgelehnte Transaktionen das gleiche Ergebnis liefern, unabhängig davon, aus welchem ​​Grund der Prozessor Ihnen mitgeteilt hat, dass sie abgelehnt wurden.

Auf Kosten ärgerlicher legitimer Kunden, die ihre Kreditkartendaten falsch eingegeben haben, nicht bemerkt haben, dass ihre Karte abgelaufen ist, versehentlich ihr Limit überschritten haben usw.
@Gilles Nun, ich nehme an, wenn die Adresse übereinstimmt, dann vielleicht mehr Informationen. Im Moment schätze ich, ob eine Karte überhaupt registriert ist, unabhängig davon, ob etwas dazu passt.
Ich stimme @Gilles, zu. Es war sehr ärgerlich, nur eine "nicht funktionierende" Nachricht von PayPal zu erhalten (ich habe für einen Computer bezahlt und trotz all meiner zuvor erfolgreichen Zahlungen wurde ich anscheinend nicht als vertrauenswürdig genug angesehen, um für die nächsten vier Wochen etwas anderes zu kaufen ), insbesondere wenn die Antworten vom Support kopiert und eingefügt werden ...
w.c
2012-08-29 19:49:45 UTC
view on stackexchange narkive permalink

Sie können einen " CAPTCHA" - Mechanismus verwenden, um Brute-Force-Angriffe zu begrenzen. Abhängig vom Produkt können Sie CAPTCHA so konfigurieren, dass ein Benutzer nach einigen fehlgeschlagenen Versuchen daran gehindert wird, eine andere Transaktion zu senden. und oder ein Zeitlimit (z. B. 15 bis 20 Sekunden) zwischen Transaktionen einführen.

Wenn möglich, können Sie auch einen Authentifizierungsmechanismus für Ihre Benutzer ausprobieren und nur bestimmten Konten erlauben, Transaktionen auszuführen.

Ich würde wirklich von der Idee des "Authentifizierungsmechanismus" abraten, es ist 2012, weit hinter der Zeit, als "Site-Konten" sofort gelöscht werden sollten. CAPTACHA ist eine hervorragende Idee, ebenso wie das Sperren von Benutzern, die es für einen angemessenen Zeitraum mehrmals versagen.
GdD
2012-08-29 19:21:45 UTC
view on stackexchange narkive permalink

Wenn Ihre Angreifer fortlaufende Kontonummern verwenden, ist dies ein Werbegeschenk, mit dem Sie Versuche filtern können. Wenn jemand 001, dann 002, dann 003 versucht, ist es eine ziemlich gute Vermutung, dass er kardiert, und Sie können dann Versuche von dieser IP-Adresse filtern.

Die Sache ist, dass intelligente Angreifer ihre Angriffe dann ändern, indem sie die Kartennummern, die sie versuchen, oder eher über einen Zahlenblock randomisieren. Dann müssen Sie nach anderen Zeichen suchen. Wenn Sie eine Datenbank mit IP-Adressen und Anforderungen erstellen, können Sie nach diesen Zeichen wie einer hohen Anzahl von Transaktionen mit geringem Wert suchen oder einen Algorithmus verwenden, um Blocktransaktionsversuche zu erkennen.

Oder natürlich können sich die Carder anpassen: Sie könnten mehrere Server für Versuche verwenden oder größere Transaktionen, weniger Versuche pro Stunde usw. versuchen. Sie müssen sich jedoch anpassen, um zu behalten Verwenden Sie Ihr System, und einige von ihnen sind möglicherweise nicht dazu in der Lage oder möchten sich nicht darum kümmern. Zumindest müssen sie dafür arbeiten.

@Jeff Ferland - Ja. Keine dieser Transaktionen wird jemals durchgeführt, da wir eine strikte Adress- / Namensüberprüfung haben, aber alle abgelehnten Versuche summieren sich und der CC-Prozessor flippt aus.
Es ist zwar keine sofortige Lösung, aber es hat das Potenzial, Maschinen, die für mehrere Kardierversuche verwendet werden, schnell zu eliminieren. Es geht nur um Muster.
Meine einzige Sorge bei dieser Antwort ist die mögliche Verweigerung des Dienstes für legitime Benutzer aufgrund der gemeinsamen Nutzung von NAT-IP-Adressen. Dies ist insbesondere dann ein Problem, wenn ein Botnetz den Angriff im Gegensatz zu einem einzelnen Client ausführt.
@Phil, Sie haben absolut Recht. Das Problem ist, dass die Carder bereits durch ihre mehrfachen Kardierversuche ein DoS verursachen, sodass etwas getan werden muss.
ajacian81
2012-08-30 03:00:21 UTC
view on stackexchange narkive permalink

Ich glaube nicht, dass diese Person (Personen) sich darum kümmert, ob sie gültige Nummern erhält oder nicht, da Sie, wie Sie sagen, auch mit Adressen validieren und dies nacheinander versuchen. Vom CC-Prozessor blockiert zu werden, könnte tatsächlich ein Ziel sein , insbesondere wenn sie Ihre Konkurrenten sind oder dies für den Lulz tun.

Ich kann einige Optionen hinzufügen Die Liste: Sie können den Namen des Eingabefelds nach dem Zufallsprinzip sortieren und den Namen des Felds in der Sitzung oder an einem sicheren Ort speichern, wenn Sie PHP verwenden:

  <input type = "text" name = "ccnum" / >  

bis:

  <input type = "text" name = "<? php echo $ ccFieldName ;? >" / >  

Sie können Ihre Benutzer auch zwingen, JavaScript zu aktivieren (ungefähr 96% der Benutzer haben JS aktiviert). Es ist wahrscheinlich, dass Ihre Benutzer ein Befehlszeilentool wie wget verwenden zu versuchen, Ihren Server zu treffen, und wenn ja, wäre nicht in der Lage, JS zu analysieren. Sobald Sie Javascript aktiviert haben, können Sie Ihr Eingabefeld für die Kreditkarte hinzufügen, sobald Ihr Dokument fertig ist, mit einem zufälligen Namen wie oben, sodass alle aktuellen Versuche zur Automatisierung von Anforderungen fehlschlagen.

Vergessen Sie nicht, eine Nachricht "Bitte JavaScript aktivieren" für Benutzer hinzuzufügen, die NoScript bei erstmaligen Besuchen verwenden
Leider funktioniert dies nur gegen sehr einfache Bots, die direkt mit dem Server kommunizieren. Soweit ich das beurteilen kann, ist es durchaus üblich, einen normalen Browser für diese Art von Angriff fernzusteuern. Ich beziehe mich auf einen Ansatz, der so etwas wie [Selenium] (http://seleniumhq.org/) verwendet, eine Software, die zum automatischen Testen von Webanwendungen entwickelt wurde
John Deters
2012-09-10 00:49:57 UTC
view on stackexchange narkive permalink

Als dies einer mir bekannten Organisation passierte, forderten sie ihren Verarbeiter auf, alle Gebührenbeträge unter einen bestimmten Schwellenwert zu senken. Dadurch wurden die Transaktionen mit geringem Wert vollständig gestoppt, und die Carder ließen ihre Website schnell in Ruhe.

Wenn Sie noch nichts dagegen unternommen haben, wenden Sie sich an Ihr lokales FBI-Büro. Sie könnten an dem Fall interessiert sein. Der "Verkostungs" -Prozess des Kontos kommt möglicherweise von einem nachvollziehbaren Ort.

Winston Ewert
2012-08-29 23:21:03 UTC
view on stackexchange narkive permalink

Eine in Betracht zu ziehende Option wäre die Einführung einer künstlichen Verzögerung bei der Kreditkartenprüfung. Legitime Benutzer sollten sich nicht um eine leichte Verzögerung des Prozesses kümmern, aber die Nützlichkeit Ihrer Website für die Kardierskripte erheblich beeinträchtigen.

Bis sie Multithreading starten. . .
ddyer
2012-08-30 00:48:01 UTC
view on stackexchange narkive permalink

Sobald Sie einen verdächtigen Strom von Anforderungen identifiziert haben (vermutlich durch eine Echtzeitmusterübereinstimmung bei kürzlich fehlgeschlagenen Transaktionen). Verweigern Sie zunächst automatisch alle nachfolgenden Anforderungen, die für einen bestimmten Zeitraum (mindestens Stunden) übereinstimmen. Dadurch wird Ihr tatsächliches Transaktionsverarbeitungssystem entlastet, und der Täter wird nicht mehr mit nützlichen Informationen versorgt. Tatsächlich werden ihm Fehlinformationen zugeführt, da auch gültige Anfragen abgelehnt werden. Verlangsamen Sie Ihre Antwort, um die Rate neuer Anfragen zu begrenzen.

lanrosta
2015-08-03 22:24:46 UTC
view on stackexchange narkive permalink

Wir hatten hier das gleiche Problem. Wir haben beschlossen, dass der schnellste und benutzerfreundlichste Weg darin besteht, eine moderne Recaptcha-Erweiterung („Ich bin kein Roboter“) zu implementieren. Wir haben uns für die Google Recaptcha-Erweiterung von Yireo entschieden, da sie schnell und einfach zu implementieren war ( https://www.yireo.com/software/magento-extensions/recaptcha), aber Sie können auch Ihre eigene implementieren hier ( http://www.proxiblue.com.au/blog/magento-recaptcha/).

Für unsere Yireo-Implementierung habe ich die Einstellungen "Kundenregistrierung" und "One Page Checkout Billing" als "Ja" verwendet, alle anderen wurden auf "Nein" gesetzt. Es gibt ein Problem, das mir bei Yireo aufgefallen ist, als ich die Einstellung "One Page Checkout Login" als "Ja" verwendet hatte. Dann hatten unsere registrierten Benutzer Probleme, sich bei ihren Konten anzumelden (aus irgendeinem Grund wurde kein Recaptcha angezeigt und als sie es versuchten Wenn Sie sich anmelden, wird in einem Nachrichtenblock "ungültiges Recaptcha" angezeigt. Also habe ich diese Einstellung auf "Nein" geändert, und jetzt können sich normale Benutzer anmelden, und das Kardieren hat auch aufgehört, unseren Zahlungsprozessor zu pingen. Alle sind jetzt glücklich.

Ein Hinweis zur Yireo-Erweiterung. Es werden kurze PHP-Tags (dumm) verwendet. Wenn Sie also eine PHP-Version unter 5.4 verwenden, müssen Sie die Unterstützung für kurze Tags in Ihrer PHP.ini aktivieren. Stellen Sie sicher, dass Sie die Anforderungen für die Yireo-Erweiterung gelesen haben, bevor Sie sie implementieren!

BEARBEITEN: Recaptcha unternimmt nichts, um die Angriffe zu verhindern. Es ist anscheinend sehr einfach, das System auszutricksen, da das Recaptcha nach dem ersten Versuch nur ein zwischengespeichertes Cookie verwendet, sodass Bots danach ausgeführt werden können, indem nur das Cookie verwendet wird. Schlechtes Design Google. Recaptcha soll Bots verhindern, kann aber im aktuellen Zustand nicht.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...