Onderwerp: Alles dicht, toch spam...

Sinds enige weken krijg ik abuse-meldingen met het bericht dat er spam wordt verstuurd vanaf één van mijn servers, met de nodige risico's op blacklisting. De e-mailadressen waar de spam naar wordt verzonden eindigen allemaal op 'mail.dk'.

Nu heb ik de volgende maatregelen genomen:
- SMTP Relay helemaal uit, klanten dienen de mailserver van hun provider te gebruiken. Online relay-tests geven allemaal aan dat de server in orde is.
- Het gebruik van de PHP mail() functie wordt gelogd, geeft niks bijzonders
- In Plesk een virtueel domein *.mail.dk aangemaakt met een email-catchall naar /dev/null

En tòch wordt er nog spam ontvangen én doorgestuurd naar een andere mailserver.... De eerste received-headers die we in de abuse-meldingen krijgen zijn als volgt:

Code:

Received: from rehzrgvs (5.79.41.157)
	by server01.mijndomein.nl; Tue, 26 Jan 2010 19:30:48 +0100
Received: from server01.mijndomein.nl ([mijn IP]) by fep27.mail.dk
          (InterMail vG.3.00.04.00 201-2196-133-20080908) with SMTP
          id <redacted@server01.mijndomein.nl>
          for <redacted@mail.dk>; Tue, 26 Jan 2010 19:32:17 +0100

Dus de server lijkt het lokale domein mail.dk te negeren en stuurt de mail toch door naar het 'echte' mail.dk.

Wie-o-wie heeft nog een goede tip?

Alvast bedankt.
CB

Zoek naar losse 'mailservertjes' in de accounts. Wij hebben last gehad van zoiets, doordat de credentials van een klant ergens gecompromitterd waren. Met een cleane ftp login is een mailservertje geupload die vervolgens de spam verstuurde.

Meestal helpt het ook wel de load in de gaten te houden. Mailservertjes zorgen meestal voor spikes in de load en dan heb je een hint waar je moet zoeken.

Maar dan zou de bron van de mail denk ik lokaal moeten zijn, en in dit geval wordt de mail van een externe host ontvangen. (de eerste received header)

Ik heb ook ClamAV gedraaid, die vond wel een aantal foute javascripts in PHP bestanden, maargoed javascript kan geen mail vanaf de server sturen.

Er zal toch ergens een pc'tje/bot zijn die de boel verstuurt? Dat is de eerste.

Klopt, maar de bronnen zijn steeds andere hosts, waarschijnlijk inderdaad PC's met een virus. En als SMTP relaying dicht staat (ook voor lokale gebruikers) dan zou die mail toch helemaal niet moeten worden geaccepteerd?

Oorspronkelijk geplaatst door cyberbrain

Klopt, maar de bronnen zijn steeds andere hosts, waarschijnlijk inderdaad PC's met een virus. En als SMTP relaying dicht staat (ook voor lokale gebruikers) dan zou die mail toch helemaal niet moeten worden geaccepteerd?

Als er een mailservertje in de webspace van een klant staat, kan je aan exim sleutelen wat je wilt, maar dat doet dan niet veel....

Hmm, nee daar heb je gelijk in. (In dit geval is het qmail) Maar als een ClamAV-scan er geen standaardscripts uit plukt, dan wordt het waarschijnlijk greppen op fsockopen etc.?

In elk geval bedankt voor het meedenken.

Als je met top kijkt, zie je geen vreemde dingen in de lijst staan?

cat je ftpd's xferlog eens en grep op alle perl scriptjes (.pl) die worden geupload. Waarschijnlijk hebben ze random namen.

Deze spamruns worden gedaan dmv een hit and run.. de file word geupload op een account van je klanten wiens gegevens gelekt zijn via mail of een virus/trojan die hun pc heeft gescanned naar ftp clients die het wachtwoord op hebben geslagen..
Vervolgens komt er een HTTP request om het perl scriptje uit te voeren.. Soms wordt er ook een PHP scriptje meegestuurd om dmv een exec() het perl scriptje uit te voeren.
Vervolgens worden de files weer via ftp verwijderd om zo geen sporen na te laten.

Het scriptje zelfs zal connecten naar localhost:25 om te spammen.. De geavanceerdere scriptjes hebben soms zelf een SMTP engine draaien.

FTP account dichtgooien en klant op de hoogte stellen is het beste wat je kan doen.

Een blik op 'top' levert geen vreemde processen op, ook de output van 'netstat -na' en 'lsof' ziet er normaal uit.

Onze FTP logs zijn helaas alleen terug te zien van de laatste 24 uur, ik heb het nu aangepast, maar terugkijken wordt dus lastig :-( We wachten de logs nu een paar dagen af...

Ik heb net de oude FTP logs nog terug kunnen vinden, inderdaad is er via een FTP account een hele berg perl scripts geupload, een gigantische lijst met e-mailadressen en een aantal HTML bestanden met de bekende spam termen... medicijnen, horloges en beurskoersen.

Topic kan dicht, bedankt!

Wellicht wil je delen wat de scriptnaam is. Anderen zouden hier een trigger aan kunnen hangen dan. Er vanuitgaande dat het script niet een random naam heeft.

Via FTP was een script chkftp3.pl in de cgi-bin map gezet, als je daarop googelt dan kom je uit op een aantal virussen (onder andere Bagle), dat FTP gegevens onderschept. Vervolgens werd elk uur een .pl bestand met een random bestandsnaam geupload, uitgevoerd en weer verwijderd. Verder stonden er de volgende bestanden in cgi-bin:

config.txt - een eenvoudig php.ini-achtig bestand met e-mailinstellingen
dm.cgi - obfuscated script met smtp-commando's, hits in de apache logs: 37478
from.txt - een lange lijst met e-mailadressen
letter.txt - een lijst met html-bestanden die als spam worden verstuurd
mailbase.txt - nog een lange lijst met e-mailadressen
subject.txt - leeg bestand

En diverse .html bestanden met inhoud van spam-mails: good.html, sex.html, peps.html, sale.html

De useragent die voor alle aanroepen is gebruikt is: ' MDML1[1].6Final '

Heel belangrijk is nu dat je de klant wel op de hoogte brengt en zijn ftp wachtwoorden laat wijzigen!
Laat hem wel eerst zijn pc scannen met mallwarebytes om de besmetting te verwijderen, ALVORENS hij de wachtwoorden wijzigt. Anders is hij/jij zo weer de klos

Klopt. We hebben de FTP toegang tijdelijk uitgezet en we nemen eerst contact op met de klant zodat we er zeker van zijn dat we morgen niet met hetzelfde probleem zitten.