Wat ziet een spam-bot?
- vanaf ipadres X wordt de pagina met formulier opgevraagd.
- 1 seconde later wordt zonder voorgaande actie vanaf ipadres Y een POST gestuurd
Vaak kwam stap 1 vanuit een ander werelddeel dan stap 2. (ipadressen uit de Apache logs)
Dat kan ooit eens toeval zijn, maar dat was een standaard manier van opereren. Er zat ook geen regelmaat in, zoals stap 1 altijd uit Azië of zo.
Ik denk dat het gaat om vele duizenden / miljoenen besmette pc's die centraal aangestuurd worden.
200.000 ipadressen is maar een druppel op de gloeiende plaat. Nog los van de dynamische ipadressen.
Ik zou in elk geval controleren of het POSTende ipadres ook recent de pagina heeft opgevraagd.
en daarnaast of het ipadres een beetje logische herkomst heeft. Als jouw doelgroep in NL zit, kun je al een hoop ipadressen als verdacht markeren. Met diensten als ip2location kun je simpel het land opvragen van een ipadres.
Zo heb ik voor een webshop ingesteld dat alle orders uit Nigeria standaard genegeerd worden. (was toch altijd creditcard fraude)
Wat ik me nog afvraag ... worden alleen contactformulieren gespamt? Dus zoekt zo'n spambot naar de url www.xxx.com/contact? Of naar het woordje 'contact'? Of is ieder formulier (dus ook een bestelformulier) een potentieel doelwit?
Spam via een bestelformulier heb ik zelf nog niet gehad moet ik zeggen, misschien dat dit iets te lastiger wordt om langs alle validatie te komen (Telefoonnummer, Nederlands huis adres bijvoorbeeld, eventueel nog iets in je mandje)
Wel kijkt een bot naar de namen van input velden want hij moet tenslotte toch weten wat erin moet. Zo hebben de meeste input velden voor een e-mailadres wel iets van 'mail' in de naam staan. Je kunt deze namen ook een zinloze naam geven en met een validatie van e-mailadres heb je misschien weer een paar buiten de deur gehouden (Geen idee of de spam-bot ook de labels leest).
De ideeën van Ivo en Ben kun je ook eens meenemen. Een spam-bot toont een bepaald gedrag en dit kan je tegen hem/haar gebruiken. Om te voorkomen dat je een mens buitensluit kun je er nog voor kiezen om wanneer je denkt dat het een bot is (te snel versturen, verschillende ip adressen (wat best wel voor kan komen, maar niet uit 2 landen) om dan alsnog een recapchta te tonen. Zo val je mensen er normaal gesproken niet mee lastig, maar het kan eens voorkomen.
Log dan ook alle pogingen zoals Ivo aangaf. Met wel IP adres komt hij/zij op de pagina en met welk IP adres verstuurt hij/zij uiteindelijk. Waar komt dit IP adres vandaan. Hoe lang duurt het invullen en versturen van zo'n formulier.
De meeste spam die ik via enkele contactformulieren ontvang, lijkt overigens handwerk uit lage-lonenlanden, dus niet van bots.
Voor de aardigheid moet je eens een honeypot op www.example.com/admin zetten. Binnen een paar dagen komt er dan een bot langs die iets met username en password gaat proberen.
Dat lijkt me lastig. Als het 2 IP-adressen zijn, dan zijn het (neem ik aan) ook onafhankelijke requests en weet je dus niet dat ze "bij elkaar" horen.
Toevoeging op 16/09/2016 14:22:57:
>> Voor de aardigheid moet je eens een honeypot op www.example.com/admin zetten. Binnen een paar dagen komt er dan een bot langs die iets met username en password gaat proberen.
Ja, dat zie ik nu al in m'n logs. Alle "standaard" urls worden geprobeerd ... wordpress, phpmyadmin enz. Als je standaardinstellingen gebruikt is het toch allemaal best "kwetsbaar".
Ozzie PHP op 16/09/2016 14:19:55:
Dat lijkt me lastig. Als het 2 IP-adressen zijn, dan zijn het (neem ik aan) ook onafhankelijke requests en weet je dus niet dat ze "bij elkaar" horen.
Als je het IP adres in een onzichtbare input zet, meestuurt met het formulier en vervolgens kijkt of het IP adres overeenkomt met het IP adres in het formulier, weet je dat de aanvraag gedaan is door hetzelfde IP. Althans, dat is hoe ik het heb begrepen.
zo 1x weet je dat niet.
Maar als je bij analyse van "waar komt die spammert vandaan" steeds geen GET request ziet van dát ipadres, maar steeds ervoor een GET van een heel ander ipadres dan is dat wel een patroon.
Gewijzigd op 16/09/2016 14:28:11 door Ivo P
Ozzie PHP op 16/09/2016 14:19:55:
Dat lijkt me lastig. Als het 2 IP-adressen zijn, dan zijn het (neem ik aan) ook onafhankelijke requests en weet je dus niet dat ze "bij elkaar" horen.
Daarvoor voeg ik een random token toe aan een verborgen formulierveld. Bij het eerste request wordt het token gegenereerd, in de sessie opgeslagen en in het formulier gezet. Bij het tweede request moeten de formulierdata vervolgens dus hetzelfde token bevatten. Zo controleer je als het ware of het ontvangen formulier gelijk is aan het uitgereikte formulier.
MAar goed: dit gaat dus om een ooit gezien patroon van spammen.
Het is niet gezegd dat dit de enige werkwijze is
Toevoeging op 16/09/2016 14:31:57:
@Ward
maar als de spammer de (session)cookie meegeeft aan de poster, dan heeft die dus ook dezelfde session inhoud.
Tenzij het een session is die afdwingt bij 1 ip te horen
Toevoeging op 16/09/2016 14:38:16:
By the way ... wat is het voordeel voor een spammer om via het ene IP-adres het formulier op te halen en via een ander IP-adres te posten? Waarom niet gewoon alles via hetzelfde IP-adres?
Ivo P op 16/09/2016 14:30:08:
@Ward
maar als de spammer de (session)cookie meegeeft aan de poster, dan heeft die dus ook dezelfde session inhoud.
Tenzij het een session is die afdwingt bij 1 ip te horen
maar als de spammer de (session)cookie meegeeft aan de poster, dan heeft die dus ook dezelfde session inhoud.
Tenzij het een session is die afdwingt bij 1 ip te horen
Klopt, maar niet alle spambots gebruiken twee IP-adressen.
(Ik herken je scenario overigens wel, maar omdat ik vooral webwinkels bouw, sta ik veranderende IP-adressen doorgaans toe.)
SQL-injectie heeft een vergelijkbaar patroon. Je ziet vaak een paar query-fratsen binnen enkele minuten en daarna is het een paar uur rustig. Daarna volgen er weer enkele pogingen en is het vervolgens weer een tijd stil. Dat houden ze enkele dagen vol, tot ze het opgeven. Lijkt op echt bezoekersgedrag als je niet verder kijkt en dat is waarschijnlijk ook precies de bedoeling.
Maar stel we hebben dan die 'harvester'. Die leest mijn contactformulier in ... en wat gebeurt er dan?
Ik stel even voor dat mijn formulier in een variabele terechtkomt. Vervolgens worden er values toegevoegd aan de inputvelden ... en hoe wordt het zootje vervolgens dan gepost?
In PHP zou ik daarvoor cURL gebruiken, maar een raw HTTP-request is weinig meer dan vrij simpele ASCII-code, dus dat moet op allerlei manieren te produceren zijn. Kijk maar eens in de developer tools van je browser.