Spammers achterhalen en voorkomen op webserver?*

[Boudewijn]

Hoihoi

Ik heb een servertje draaien als mailserver en een server als web\access server.
web\access server: daar hebben wat klanten van me SSH toegang tot (is nodig ja) en draait apache+mysql op.

Nu was het tot vanavond zo dat de mailserver alle mail van de webserver accepteert (postfix had de webserver in $mynetworks). Prima.... gaat al lang goed.

Tot vandaag, een of andere joker heeft het voor elkaar gekregen om 25k emails te sturen, echter weet ik niet wie of wat.
Op de mailserver zie ik alleen dat het de webserver is.

Weet iemand hoe ik dit kan achterhalen?

Als het niet mogelijk is, hoe kan ik ervoor zorgen dat ik het volgende keer WEL kan achterhalen.

OS is debian voor de webserver, freebsd voor de mailserver trouwens.

[berties]

Misschien begrijp ik het niet helemaal maar je wil de spammer op de mailserver achterhalen zonder dat je toegang hebt tot de webserver? Als deze van jouw is heb je toch toegang, en zo ja, wat geven de logfiles van apache aan?

[TeeDee]

Misschien een lek contact formulier op je/een website waarmee middels mime-injection je webserver 25k emails verzonden heeft?

[Verwijderd]

Ik wou net zeggen. Loop even alle contactforms na en controleer deze op code. Vooral CGI-bin gebaseerde contactformulieren lopen het risico misbruikt te worden.

[Boudewijn]

Uiteraard heb ik op beide machines root xs.

Tsja ik wil het graag kunnen loggen ipv dat ik alle code moet checken; ik weet nu namelijk niet waar het vandaan komt.
Veel standaard dingen (tikiwiki, phpbb, uiteraard geupdate) en ook wat custom code van klanten.
Dus checken gaat HEEL veel tijd kosten.

Ik log het liever ,is dat mogelijk?

[soulrider]

inderdaad: logfiles van je webserver doorspitten, kan een script zijn dat een van je klanten erop heeft gezet voor zijn spamrun, of het kan een 'contact-formulier + script' zijn dat misbruikt wordt door anderen...
(exploit door code-injectie ? vooral als er server-zijde geen goede controle is in het 'verzend contact-mail'-script.)

allemaal te achterhalen door je apache logs te doornemen. (get,post-info en vanaf welke ip-adressen in hoeveel seconden) Je hebt de tijdstippen al van je mail-server, cross-vergelijk die met apache-lgos en ev. met ssh-access-logs.

Limiteer ev. ook het max. aantal mails op een paar honderd per minuut (met een drop van alle mail-requests die erover gaan) en laat klanten die grote mail-runs willen uitvoeren contact met je opnemen om dit apart te voorzien... (door bv een apart 'newsletter'-script voor je klanten te voorzien dat gebruik maakt van een vaste database aan ontvangers, en op vaste tijdstippen zijn run doet mbv een cronjob, en dan kan je dat ev. ook opdelen per 'zoveel mails per minuut')

en op je mailserver moet je toch ook kunnen zien welke user de mails verstuurde ?
(anders ev. smtp met authenticatie gaan gebruiken ipv simpele smtp)

[TeeDee]

Kan je niet de Access logs van Apache checken? Als het er 25K zijn moet je volgens mij toch wel een patroon in de logs kunnen vinden. </understatement>

[burne]

Boudewijn schreef op dinsdag 10 februari 2009 @ 21:52:
Op de mailserver zie ik alleen dat het de webserver is.

Nu, achteraf, ga je het niet meer achterhalen, tenzij je nog een apache logfile hebt waaruit je kunt halen wat er 25K keer aangeroepen is en dat je naar de schuldige kan sturen. Je mailserver weet van niets, die heeft enkel mail van root gezien.

Zorgen dat je mod_suexec aan de praat krijgt. Dan draait ieder script onder het user-id van een gebruiker (je hebt toch wel aparte gebruikers voor iedere website?) en daarmee kun je dingen doen, van beperken van resource-gebruik (geheugen en CPU-tijd) tot het loggen van user-id's door je mailserver.

[ Voor 20% gewijzigd door burne op 10-02-2009 22:40 ]

[berties]

TeeDee schreef op dinsdag 10 februari 2009 @ 22:36:
Kan je niet de Access logs van Apache checken? Als het er 25K zijn moet je volgens mij toch wel een patroon in de logs kunnen vinden. </understatement>

cat/grep/awk/sed de logfiles van je webserver even door, en zoals TeeDee al zegt, als het er 25k zijn moet een cat al heel snel een duidelijk beeld geven van de boosdoener. Kijk ook even waar je webserver writeaccess heeft, misschien in /tmp en kijk of je daar vreemde code vindt die gebruikt wordt, maar dat zal waarschijnlijk niet. Anders zou die hack wel gebruikt worden om direct vanaf je webserver te mailen ipv via de mailserver. Ik denk dan ook eerder dat het in slecht geschreven mailforms zit of in niet geupdate webpakketten waar een exploit in zit.

De verwachting is dat je wel terug kunt vinden wie de mails verzonden heeft, maar dat ip adres zal wel een proxy of dynamisch adres zijn waar je vervolgens weinig mee kunt dan het als leermoment zien..

[ Voor 11% gewijzigd door berties op 10-02-2009 22:47 ]

[Boudewijn]

Apache logs bieden geen soelaas.
Mail limiteren is een goed idee.


@burne, inderdaad. su_exec is een heel mooi idee voor mijn nieuwe server (vandaag geplaatst...).
Goed plan.


Deze actie is voroal bedoeld om het foute script te vinden en dat op te lossen, zodat ik die host weer kan vertrouwen op de maildoos. Is nu niet het geval.

[TeeDee]

En mag ik vragen waarom de apache logs geen soelaas bieden?

Je wil het foute script vinden, daar ben je nu in feite te laat mee. Je dient nu te vertrouwen op je logs.

[berties]

Boudewijn schreef op dinsdag 10 februari 2009 @ 23:00:
Apache logs bieden geen soelaas.
Mail limiteren is een goed idee.


@burne, inderdaad. su_exec is een heel mooi idee voor mijn nieuwe server (vandaag geplaatst...).
Goed plan.


Deze actie is voroal bedoeld om het foute script te vinden en dat op te lossen, zodat ik die host weer kan vertrouwen op de maildoos. Is nu niet het geval.

Blijf het raar vinden, als het misbruik is van code of een pakket onder apache moet het toch echt wel te vinden zijn in de logs, misschien is het iet wat moeilijk zoeken maar het zou te vinden moeten zijn (zeker met 25k+ mails). Als er echt niets te vinden is lijkt het me een exploit die het eea in bijvoorbeeld /tmp heeft gezet om vanaf daar het eea te draaien. Heeft apache write access in /tmp of ergens anders? en staan daar vreemde files/ is de load van je webserver ook hoog of was deze hoog gedurende de 25k+ mails?

[Boudewijn]

Nee de load was niet hoog.

Ik heb het aantal regels op 10 Feb vergeleken met die op 8 en 9 feb, en nergens wijkt het signifcant (meer dan 10% af). Business as usual dus voor apache.

Idem voor de load.

Load is destijds wel wat hoger geweest, maar niet voor apache.

Ook in de munin grafieken zie ik zowel bij apache-load als apache-traffic weinig geks.

Zal zo tmp eens uitspitten.

[ Voor 4% gewijzigd door Boudewijn op 10-02-2009 23:12 ]

[TeeDee]

Als het mime-injection is geweest met 25K mails zou je misschien wel eens een absurd grote request voorbij zien komen. Die headers moeten immers ergens in een POST (of in een erger geval een GET, maar dan kunnen het er geen 25K zijn) gezet zijn.

Verder zou ik die host gewoon helemaal niet meer vertrouwen. Probeer, ondanks dat dat de insteek is van je topic, de boosdoener te traceren. Fix dit, en er zit waarschijnlijk niks anders op dan alles vervolgens na te lopen.

[Boudewijn]

Ja de host gaat toch al down binnenkort (oude server).
Maar goed, ik ga zo ook even naar absurd grote post-sizes enzo zoeken.


Verder nog usual suspects?

[TeeDee]

Bedenk me net:
Je hebt toch logs van de mail en webserver? En in de logs van de mailserver staat het e.e.a. over wanneer dit gedaan is. Kan je niet je zoektocht minimaliseren naar een tijdspanne en vergelijk dit met je apache logs. Je kan dan vervolgens gerichter naar andere zaken gaan zoeken.

[Boudewijn]

Hmm nee ik heb al gericht naar 18:25 vandaag gekeken (toen begon het, tot ik het een goed uur later de nek omdraaide).
Greppen op webserver-logs heb ik al in die tijdsspanne gedaan, weinig interessants.
Verder zag ik dat een raar alias in mijn /etc/network/interfaces stond.... ik vertrouw het niet echt meer.

Bah.

[berties]

Boudewijn schreef op dinsdag 10 februari 2009 @ 23:14:
Nee de load was niet hoog.

Ik heb het aantal regels op 10 Feb vergeleken met die op 8 en 9 feb, en nergens wijkt het signifcant (meer dan 10% af). Business as usual dus voor apache.

Idem voor de load.

Load is destijds wel wat hoger geweest, maar niet voor apache.

Ook in de munin grafieken zie ik zowel bij apache-load als apache-traffic weinig geks.

Zal zo tmp eens uitspitten.

Bedoel je met het aantal regels; cat apache.log |wc -l ??? want dat lijkt me wel een te minimale inspectie van je logfiles. Ik zou zeggen cat eens op de apache.log haal deze door awk om alleen het ip en het de url er uit te filteren, sorteer de output en bekijk die met less dan zie je mogelijk toch ergens een grote hoeveelheid ips met de zelfde request. Kun je de log niet ergens posten?

[Boudewijn]

Nee ik heb de log gescand op 10 februari. Vervolgens op 9 februari.

Vervolgens vergeleken, daar zitten dus niet veel meer requests op.
Kan het logje posten ja,maar doe ik liever niet ivm privacy van klanten.

Er heeft iemand wel fors nikto ofzo los gelaten op mijn doos, heel veel van die filenames gegokt. Wel allemaal 404's gekregen trouwens.

[ Voor 32% gewijzigd door Boudewijn op 10-02-2009 23:59 ]

[berties]

Boudewijn schreef op dinsdag 10 februari 2009 @ 23:46:
Hmm nee ik heb al gericht naar 18:25 vandaag gekeken (toen begon het, tot ik het een goed uur later de nek omdraaide).
Greppen op webserver-logs heb ik al in die tijdsspanne gedaan, weinig interessants.
Verder zag ik dat een raar alias in mijn /etc/network/interfaces stond.... ik vertrouw het niet echt meer.

Bah.

Die rare alias in interfaces lijkt me geen goed teken... wat was het precies?

[Boudewijn]

Een 82.94 ip, komt bij xs4all vandaan.

Geen apache vhosts omtrend dat ip.


Duidelijk niet mijn ding; ik heb alleen 194.109 ip's, dus geen rare typo van mij .


Update: apache lijkt ook fors over de zeik te zijn gegaan. Heeeeel traag ladende sites. Weinig raars in top trouwens.

[ Voor 27% gewijzigd door Boudewijn op 11-02-2009 00:04 ]

[Verwijderd]

Je kan ook met 1 IP 1 request doen van 25k aan mailtjes.

Dat was met een website van mij ooit het geval. Zet bijv PHP-mailer uit, en laat iedereen SMTP-based werken op je webserver. Zo sluit je lekke scripts ook uit die dmv php-mailer functioneren.

[Boudewijn]

Ja smtp based werken heb ik dus nu enabled, door per se te laten authenticeren.
Ik neem aan dat je dat in je php.conf regelt?

[berties]

Boudewijn schreef op woensdag 11 februari 2009 @ 00:01:
Een 82.94 ip, komt bij xs4all vandaan.

Geen apache vhosts omtrend dat ip.


Duidelijk niet mijn ding; ik heb alleen 194.109 ip's, dus geen rare typo van mij .

hmm daar heb je wel een aanknopingspunt ik zou overwegen dit bij xs4all te melden, voor zover ik weet maken ze voornamelijk gebruik van vaste ip's dus dat moet eenvoudig te checken zijn.

En als er veel nikto scans zijn geweest is de kans groot dat daar het lek mee gevonden werd. Ik zou zeggen installeer zelf nikto en voer een scan uit, dan heb je een redelijke kans dat je kunt zien waar het mis gaat/is gegaan.

[Verwijderd]

Boudewijn schreef op woensdag 11 februari 2009 @ 00:06:
Ja smtp based werken heb ik dus nu enabled, door per se te laten authenticeren.
Ik neem aan dat je dat in je php.conf regelt?

Ik geloof van wel ja

Je zal nu wel een regen van klachten krijgen over niet functionerende scripts of pagina's omdat die van de php-mailer gebruik maken (ook forums enzovoorts).

Men krijgt gewoon geen email.

[Boudewijn]

berties schreef op woensdag 11 februari 2009 @ 00:09:
[...]

hmm daar heb je wel een aanknopingspunt ik zou overwegen dit bij xs4all te melden, voor zover ik weet maken ze voornamelijk gebruik van vaste ip's dus dat moet eenvoudig te checken zijn.

Niet officieel , maar in de praktijk wel.
Maar wat is de lol van dat ip op mijn doos draaien? het lijkt me veel leuker om vanaf mijn eigen ip lekker te kloten en te spammen.

En als er veel nikto scans zijn geweest is de kans groot dat daar het lek mee gevonden werd. Ik zou zeggen installeer zelf nikto en voer een scan uit, dan heb je een redelijke kans dat je kunt zien waar het mis gaat/is gegaan.

Ja ik ga zelf effe nikto'en.


Morgen ga ik su_exec uittesten op nieuwe server en zsm dit ding lozen.

Aantal klachten valt mee, ik bied ook netjes smtp authenticatie aan, dus dat is niet veel meer werk voor klanten.


Na het bekijken van het errorlog is het vrij duidelijk, ik heb een IP gevonden dat enorm heeft gescand.

[ Voor 5% gewijzigd door Boudewijn op 11-02-2009 00:18 ]

[berties]

En als het nikto scans zijn, dan komen die van een bepaald ipadres af; als je op dat ip adres grep uitvoert maar dan exclusief de nikto, kom je dan niet uit op de logfileregel(s) die de boosdoener is?
grep x.x.x.x access.log |grep -v nikto

[Boudewijn]

nee niets te vinden in de logjes met dat ip, behalve heel veel errors in het error logje.
user agent is ook niet gespecificeerd.

[Zwerver]

Had je toevallig roundcube op die bak staan? Daar zit een akelige bug in en er is een CVE over.

[Boudewijn]

Nee gelukkig niet.

IP issue is trouwens ontdekt, eigen aliasje waarmee ik heb zitten te prutsen maar niet uitgezet.
Bummer.

[berties]

Boudewijn schreef op woensdag 11 februari 2009 @ 00:17:
Maar wat is de lol van dat ip op mijn doos draaien? het lijkt me veel leuker om vanaf mijn eigen ip lekker te kloten en te spammen.

[...]

Wat ik me voor kan stellen is dat je ergens in een serie zit om de oorspronkelijke dader moeilijker te traceren. Beetje het idee om van proxy naar proxy naar proxy te gaan, wil je dan daadwerkelijk de echte dader vinden....veel succes, dat wordt heel moeilijk. Dat is voor de hacker meer werkt, het moet nogal de moeite zijn om je sporen zo te willen uitwissen..dan heb je het toch niet echt over 25k+ spam-mailtjes lijkt me. ip-issue was opgelost..

[Boudewijn]

Oorzaak gevonden:
Het is geen hack, maar rinetd die is aangegaan (stond default op uit, wtf, staat al maanden uit, ook na reboots) en een oude poortforwarding deed.

Gevolg is dus:

rinetd mapt de poort 25 van mail op www
mail accepteert *alles* van www
je stuurt message naar www, source ip wordt gerewrite naar www en doorgestuurd naar mail.
Dus gewoon een open relay.


rinetd had niet aan moeten gaan (stond ooi uit :roll: ) maar na een reboot toch aangegaan.
Zojuist verwijderd middels apt-get.


Iig gelukkig geen hack, verklaart ook meteen waarom de access logs schoon waren.

[Alain]

En mij de schuld geven omdat ik inlog.

Fijn dat je het gevonden hebt.

[Boudewijn]

AlainS schreef op woensdag 11 februari 2009 @ 19:26:
En mij de schuld geven omdat ik inlog.

Fijn dat je het gevonden hebt.

LOL ik meldde alleen dat jouw inlog bijna gelijk lag met het begin van de spamrun, meer niet .


Iig bedankt voor het meedenken mensen!

[eghie]

Tip, voor de volgende keer.

Wij gebruiken veel PHP op onze hosting servers en daarbij ook wel eens gehad dat er een script was die spamde. Nu loggen wij dat gewoon.

PHP verstuurd zijn mail via de sendmail executable (tenminste wat verstuurd wordt via mail()). Die heb ik vervolgens gerenamed naar /usr/bin/sendmail.hidden en het volgende scriptje als /usr/bin/sendmail geplaatst:

Perl:

#!/usr/bin/perl

# use strict;
 use Env;
 my $date = `date`;
 chomp $date;
 open (INFO, ">>/var/log/sendmail.log") || die "Failed to open file ::$!";
 my $uid = $>;
 my @info = getpwuid($uid);
 if($REMOTE_ADDR) {
         print INFO "$date - Mail from: $PWD" . $SCRIPT_NAME . "- @info\n";
 }
 else {
        print INFO "$date - $PWD -  @info\n";
 }

 print INFO "\tHost:\n";

 print INFO "\t\tHTTP_HOST=". $HTTP_HOST . "\n";
 print INFO "\t\tSCRIPT_NAME=" . $SCRIPT_NAME . "\n";
 print INFO "\t\tREMOTE_ADDR=" . $REMOTE_ADDR . "\n";
 print INFO "\t\tQUERY_STRING=" . $QUERY_STRING . "\n";;
 print INFO "\t\tHTTP_USER_AGENT=" . $HTTP_USER_AGENT . "\n";
 print INFO "\t\tREQUEST_URI=" . $REQUEST_URI . "\n";
 print INFO "\t\tHTTP_REFERER=" . $HTTP_REFERER . "\n";
 print INFO "\t\tHTTP_X_FORWARDED_FOR=" . $HTTP_X_FORWARDED_FOR . "\n";

#Alleen voor testen
#print INFO "\tBody:\n";

 print INFO "\n";

 my $mailprog = '/usr/sbin/sendmail.hidden';
 foreach  (@ARGV) {
         $arg="$arg" . " $_";
 }

 open (MAIL,"|$mailprog $arg") || die "cannot open $mailprog: $!n";
 while (<STDIN> ) {
        print MAIL;
        chomp;

#Alleen voor testen
#print INFO "\t\t" . "$_" . "\n";
}

 close (INFO);
 close (MAIL);

Dit geeft wel een huge log na een tijdje, dus op 1 regel kan het waarschijnlijk beter, of via een SQL database. Maar het logt iig wat. En spam is zo wel makkelijker terug te traceren.

[Boudewijn]

Cool man, die gaan we eens proberen.
Disk-space is geen issue op die machine.


Dat gaan we van het weekend eens evalueren.

[_JGC_]

Sommige software gebruikt ook mailer classes die rechtstreeks via een SMTP server afleveren helaas.
Overigens gebruik ik suexec met fastcgi, elk domein draait onder een eigen account, die vernoemd is naar het account. Leuke hiervan:
- in de headers komt altijd de accountnaam te staan
- "foute" scripts sturen altijd met returnpath = domeinnaam@webserver

Vooral die laatste is leuk: hang je mailserver die het domein voor je webserver host aan LDAP of MySQL en laat domeinnaam@webserver gewoon rewriten naar het contactadres voor het domein. Daarmee voldoe je aan sender verification, en zorg je dat evt replies op mails verstuurd door "foute" scripts aankomen bij de klant.

[Boudewijn]

Nou die mailer classes met SMTP zijn juist fijn, mi. Domweg omdat die zich *WEL* moeten authenticeeren, waardoor ik zo zie wie de l*l is.

fastcgi: ja leuk, maar 95% van mijn code is gewoon php. Volgens mij gaat dat niet werken met cgi.

[_JGC_]

Bij fastcgi koppel je PHP los uit apache en draait het als standalone applicatie. Je draait dan in feite gewoon PHP in CGI mode, maar dan op een manier dat je niet de overhead van het starten van processen hebt.

Je had het in een eerdere reactie over su_exec, dit werkt alleen voor CGI applicaties of voor modules die er gebruik van kunnen maken zoals mod_fastcgi of mod_fcgid. Andere optie is suPHP, maar dat is vergeleken met fastcgi om te huilen.

[Boudewijn]

Ja daarom, ik vind su_exec mooi, maar dan moet ik php idd las cgi draaien.
fastcgi zal ik er eens voor bekijken.

Dank je voor de tips .