Serverlogs lezen om gedrag van spambots na te gaan

[Verwijderd]

Ik heb een website waar spambots de overhand hebben gekregen.

De website beschikt over een functie om een reactie per artikel achter te laten. De verouderde reCAPTCHA v1 techniek wordt gebruikt om reacties al dan niet door te laten. Sinds enige tijd is er een stormvloed aan "reacties" vol met spam, ergo: ze komen door de "beveiliging" heen...

Nu heb ik het logische vermoeden dat bij de verouderde reCAPTACHa het euvel ligt, maar ik wil er zeker van zijn dat deze spambots niet via een of ander lek de database aan het injecten zijn met reacties

De website draait op een CentOS server met Apache versie 2.2.22, waar ik toegang toe heb.

Hoe zou ik kunnen zien via welke requests deze bots hun ding doen?
Welke logs zou ik daarvoor kunnen analyseren?
Welke logs zijn überhaupt nuttig om aan te hebben staan?

^{Het internet staat vol met antwoorden als "check de server logs", maar niemand vertelt fatsoenlijk waar deze zitten en wat iedere log exact bijhoudt}

[DiedX]

Wie zegt dat het bots zijn? Chinese kinderhandjes zijn goedkoop!

[Verwijderd]

DiedX schreef op vrijdag 7 juni 2019 @ 22:52:
Wie zegt dat het bots zijn? Chinese kinderhandjes zijn goedkoop!

Het zijn er tientallen per minuut. Maar of het nou bots zijn of niet doet er weinig toe. Mijn wens is om te weten via waar deze specifieke reacties worden geplaatst.

[jvanhambelgium]

Op zoek gaa in de access.log ??

Kijk eens in /var/log/apache/access.log of /var/log/apache2/access.log of /var/log/httpd/access.log

[Room42]

@Verwijderd Je kunt inderdaad beginnen in de Apache Accesslogs. Ik weet niet hoe erg bekend je bent met de taal waarin de website geschreven is (PHP?) maar dan zou je ook een extra logging kunnen toevoegen op het moment dat de reactie geplaatst wordt. En misschien dat de comment module zelf al (meer) logging ondersteunt.

Ook zou je nog uitgebreidere logging op Apache kunnen instellen, zodat je ook de POST-request logt maar dan moet je wel rekening houden dat de logs gigantisch worden en dat mogelijk impact op de performance van de site heeft.

[Verwijderd]

jvanhambelgium schreef op vrijdag 7 juni 2019 @ 23:10:
Op zoek gaa in de access.log ??

Kijk eens in /var/log/apache/access.log of /var/log/apache2/access.log of /var/log/httpd/access.log

Room42 schreef op vrijdag 7 juni 2019 @ 23:15:
@Verwijderd Je kunt inderdaad beginnen in de Apache Accesslogs. Ik weet niet hoe erg bekend je bent met de taal waarin de website geschreven is (PHP?) maar dan zou je ook een extra logging kunnen toevoegen op het moment dat de reactie geplaatst wordt. En misschien dat de comment module zelf al (meer) logging ondersteunt.

Ook zou je nog uitgebreidere logging op Apache kunnen instellen, zodat je ook de POST-request logt maar dan moet je wel rekening houden dat de logs gigantisch worden en dat mogelijk impact op de performance van de site heeft.

Dank beiden, hier kan ik wat mee! Ik ben nu bezig met het analyseren van de access logs. Ik zie dat mijn server slechts voor één dag de access log heeft bijgehouden, ik probeer nu uit te vogelen hoe ik dat kan extended.

Zijn er overigens geen monitoring tools die via ssh de noodzakelijke log bestanden ophalen van de server en alerts op kunnen genereren? Bij de die tools die ik heb gevonden diende je altijd handmatig het log-bestand in te laden.

[AW_Bos]

Gebruik je een bepaalde platform zoals plesk of directadmin?
Van DirectAdmin weet ik dat die de logs 's nachts archiveert.

Je kan mogelijk wel wat maken die de logs uitleest, maar de vraag is: waar moet je op zoeken om bots te detecteren? Misschien op bepaalde useragents of IP's, maar als die wisselend zijn.... In ieder geval zie je wel welke file het is, die ze benaderen, en via welke methode.

Je kan proberen om een extra beveiliging te maken, met een site-gerichte vraag (Wat verkopen wij? Welke kleur is ons logo?).
Als die in no-time gepasseerd wordt, dan heb je mogelijk ergens een lek. Maar ik ga er niet vanuit dat spambotjes een SQL-injectie gebruiken, dat is niet triviaal voor een script waarmee ze tientallen contactsites volspammen.

[ Voor 75% gewijzigd door AW_Bos op 08-06-2019 00:53 ]

[Krulliebol]

Waarom niet gewoon een nieuwere recaptcha instellen en kijken of dat het probleem oplost?

[F_J_K]

AW_Bos schreef op zaterdag 8 juni 2019 @ 00:48:

(Wat verkopen wij? Welke kleur is ons logo?).

Daar erg mee oppassen. ‘Fietsen’, ‘fietsen’, ‘fiets’, ‘velos’, ‘batavus’, etc en duizend alternatieven wil je allemaal goedkeuren. En als je (kleuren)blinden wilt behouden moet je ver blijven van de vraag naar het logo (en dan nog: is het rood, donkerrood, zalm, andere tint?

Maar inderdaad, beter om gewoon naar een nieuwe versie over te stappen? En de rest van de versies checken. Ook los vd spam.

[Krulliebol]

En dan nog: bij zo'n vraag zullen spambots waarschijnlijk wel door krijgen wat het gewenste antwoord is. Een goede recaptcha geeft juist elke keer een vraag die een ander antwoord verwacht.

[Room42]

Verwijderd schreef op zaterdag 8 juni 2019 @ 00:44:
[...] Ik zie dat mijn server slechts voor één dag de access log heeft bijgehouden, ik probeer nu uit te vogelen hoe ik dat kan extended.

Waarschijnlijk heten je oudere logs *.0, *.1, (of *.3.gz voor de gecomprimeerde varianten), etc.

Zijn er overigens geen monitoring tools die via ssh de noodzakelijke log bestanden ophalen van de server en alerts op kunnen genereren? Bij de die tools die ik heb gevonden diende je altijd handmatig het log-bestand in te laden.

Jawel, zoek maar eens naar (apache) log analyser. Het is de vraag wat je eruit wilt halen (c.q. wat het doel is van de analyse). De meeste tools zullen zich richten op bezoekersanalyse. Misschien het trefwoord 'security' erbij.

Als je overigens een patroon gevonden hebt, kun je wellicht fail2ban inzetten om de spammende IP-adressen in de ban te doen. Dat is natuurlijk wel alleen handig als het steeds dezelfde IP-adressen zijn.

[jeanj]

Stel zsm je logs veilig door ze te kopieren naar een andere locatie. Er staat log rotatie aan, dus op een gegeven moment worden er mogelijk logs weggegooid.

Awstats (of alternatieven) zou je kunnen gebruiken, dan heb je een visueel overzicht o.a. van waar je traffic vandaan komt, of het verder handig om te gebruiken voor dit doel, kan ik niet zeggen.

Kijk ook eens in je error log wat daar langs komt aan foute pogingen, en overweeg idd fail2ban te gebruiken....

Ja kan het acceslog filteren op de post url, in deze lijst ga je met de timestamp van een spampost zoeken of er een corresponderende entry is. Anders om kan ook, bekijk aan de hand van de timestamp van de reactie wat er is gebeurd in de acceslog.

Houdt er alleen rekening mee, als ze de database direct vullen, dat de timestamp in de database ook niet hoeft te kloppen (want die vullen zelf in, of kunnen ze achteraf hebben gemanipuleerd als ze slim zijn). Omdat uit te sluiten moet je in de logs van je database kijken, als die voldoende details bieden (en anders moet je het aanzetten (en dat kost mogelijk performance)) Succes

[DiedX]

Dus: recaptcha2. Je zou ook kunnen laten modereren op basis van IP-Blok

[AW_Bos]

F_J_K schreef op zaterdag 8 juni 2019 @ 02:32:
[...]

Daar erg mee oppassen. ‘Fietsen’, ‘fietsen’, ‘fiets’, ‘velos’, ‘batavus’, etc en duizend alternatieven wil je allemaal goedkeuren. En als je (kleuren)blinden wilt behouden moet je ver blijven van de vraag naar het logo (en dan nog: is het rood, donkerrood, zalm, andere tint?

Maar inderdaad, beter om gewoon naar een nieuwe versie over te stappen? En de rest van de versies checken. Ook los vd spam.

Het zijn niet de meest briljante voorbeelden blijkbaar. Maar je kan ook andere vragen stellen die een mens prima weet, zoals "Wat is ons motto", "Welke kleur is de zee", "Klik hieronder op het konijn (met een reeks van 4 dieren)" of iets in de trant.

Ik zou dan wel zulke veiligheden per drempel instellen. Dus als iemand buiten Nederland of België komt.

[Verwijderd]

jeanj schreef op zaterdag 8 juni 2019 @ 09:21:
Stel zsm je logs veilig door ze te kopieren naar een andere locatie. Er staat log rotatie aan, dus op een gegeven moment worden er mogelijk logs weggegooid.

Awstats (of alternatieven) zou je kunnen gebruiken, dan heb je een visueel overzicht o.a. van waar je traffic vandaan komt, of het verder handig om te gebruiken voor dit doel, kan ik niet zeggen.

Kijk ook eens in je error log wat daar langs komt aan foute pogingen, en overweeg idd fail2ban te gebruiken....

Ja kan het acceslog filteren op de post url, in deze lijst ga je met de timestamp van een spampost zoeken of er een corresponderende entry is. Anders om kan ook, bekijk aan de hand van de timestamp van de reactie wat er is gebeurd in de acceslog.

Houdt er alleen rekening mee, als ze de database direct vullen, dat de timestamp in de database ook niet hoeft te kloppen (want die vullen zelf in, of kunnen ze achteraf hebben gemanipuleerd als ze slim zijn). Omdat uit te sluiten moet je in de logs van je database kijken, als die voldoende details bieden (en anders moet je het aanzetten (en dat kost mogelijk performance)) Succes

Room42 schreef op zaterdag 8 juni 2019 @ 04:34:
[...]
Waarschijnlijk heten je oudere logs *.0, *.1, (of *.3.gz voor de gecomprimeerde varianten), etc.

[...]

Jawel, zoek maar eens naar (apache) log analyser. Het is de vraag wat je eruit wilt halen (c.q. wat het doel is van de analyse). De meeste tools zullen zich richten op bezoekersanalyse. Misschien het trefwoord 'security' erbij.

Als je overigens een patroon gevonden hebt, kun je wellicht fail2ban inzetten om de spammende IP-adressen in de ban te doen. Dat is natuurlijk wel alleen handig als het steeds dezelfde IP-adressen zijn.

Ik heb inmiddels precies de tools gevonden die ik nodig heb, hierbij ook een overzicht voor anderen:

• http://sourceforge.net/projects/phpida/
• http://code.google.com/p/apache-scalp/
• https://sourceforge.net/projects/phpida/
• https://github.com/jensvoid/lorg

Valt allemaal onder de categorie: logfile security analysis and forensics

Alleen jammer dat ze ontiegelijk oud en nauwelijks bijgewerkt zijn Iemand bekend met een vergelijkbare tool, maar dan recenter?

[Room42]

Die laatste (lorg) is in die zin nog onderhouden dat er redelijk recent een fix voor PHP7 is doorgevoerd.

Maar heb je ook zelf al eens door de logs gelopen? Je kunt ze makkelijk 'greppen' naar de 'action'-URL van het formulier waarop de comments geplaatst worden.

[Verwijderd]

Ik denk ik update deze topic even zodat anderen er ook wat aan hebben.

Inmiddels heb ik Wireshark op de server geïnstalleerd en ben ik aan het capturen geweest van HTTP(S)/POST traffic. Met Wireshark kan ik nu dus zien via welke requests de spam comments op de website komen. Dit blijken POST's te zijn waarvan mij nog niet duidelijk is hoe ze door de CAPTCHA komen Daar moet nog een verdiepingsslag op doen.

Ook hoef ik niet langer door logs te spitten, het capturen in Wireshark is veel uitgebreider

Nu heb ik gemerkt dat de spam zo goed als van één subnet afkomstig is Als "oplossing", ben ik van plan om deze range te blokkeren op mijn server, en tevens een Intrusion Detection System (IDS) te installeren.

Voor de mensen die het interessant vinden, dit zijn o.a. de mogelijkheden:

• ModSecurity
• Fail2ban
• UWF

[Room42]

Verwijderd schreef op woensdag 19 juni 2019 @ 17:15:
[...] Dit blijken POST's te zijn waarvan mij nog niet duidelijk is hoe ze door de CAPTCHA komen [...]

Blijkbaar kun je dus een POST doen, zonder dat de CAPTCHA server-side gecontroleerd wordt. Effectief zit je dan alleen je gebruikers te irriteren terwijl de bots gewoon het formulier kunnen versturen.

[The Eagle]

Doe jezelf een lol, kijk even naar logz.io. Is voor tijdelijk gebruik gratis. Daarna krijg je ineens een business developer op je mail maar die kun je negeren Kun je echt superveel mee qua inzichten, tot geolocatie aan toe. En iirc slikt die je apachelogs zo

[raptorix]

Je hebt diverse tools om je logfiles te queryen, zelf gebruik ik meestal de gratis tool van microsoft: https://gallery.technet.m...og-Parser-Studio-cd458765

Wat je kunt doen is een query op IP waar men wel een post op het formulier heeft gedaan, maar nooit een css of js heeft gedownload.