Onderwerp: Spam niet te traceren

Beste Whters,

Sinds enkele dagen hebben wij last van spam op 1 server.
Wij kunnen als wij in de logs kijken niet zien welke user dit is.

Wij schatten in dat er natuurlijk een site gehackt is van een klant en die is spam aan het sturen.

Het vervelende is dat wij met ons server ip snel op een blacklist komen, waardoor mailen moeilijker wordt.

Onze systeembeheerders kunnen namelijk niks vinden. we zien wel waar het naartoe gaat maar niet van welke user dit af komt.

Mijn vraag is hoe verkom je dit en hoe zoek je uit welke user spamt?
Hier moeten toch scripts voor te installeren zijn?

Wij hebben een linux server met debian en da.

Alle tips en hulp is welkom.

Ik hoor graag van jullie.

Alvast bedankt.

Mvg,

Dennis

weet niet hoe het met DA zit. Maar wij draaien mod_ruid op onze webservers waardoor een script wat uitgevoerd wordt het uid van de user meekrijgt. Daardoor zie je in postfix:

Jul 1 12:41:27 web46 postfix/pickup[11211]: 9B1F718E027: uid=1006 from=<X>

en aan de hand van de uid kun je dan weer de user vinden

kan me niet indenken dat dat voor DA ook niet te fixen valt

Oke ga ik zeker doornemen met mijn systeembeheerders.
Hebben jullie nog meer tips.

Als de klant brakke scriptjes heeft kan je er donder op zeggen dat het mail() command word misbruikt. Dit word standaard niet echt lekker gelogd onder linux (weet zo niet of DA daar hooks voor heeft ingebouwd).

Het mail() commando onder Linux spreekt direct de sendmail binary aan die de handel de deur uitstuurt. Dit wil je graag loggen omdat je dan weet wat waarvandaan komt. Dit kan je doen met bijvoorbeeld een sendmail wrapper. Op de volgende pagina vind je een how-to hiervoor.

Let er wel op dat het voor jouw specifieke situatie misschien wat anders moet worden opgebouwd maar daar komen je systeembeheers vast en zeker wel prima uit!

http://www.iezzi.ch/archives/217

Je zou eventueel ook nog extended logging in Exim aan kunnen zetten:

log_selector = +arguments +subject +received_recipients

Oke maar het is in beide oplossing niet te zien.
Iemand verder nog een tip om het probleem op te lossen.

Alvast bedankt.

Oorspronkelijk geplaatst door dennis1309

Oke maar het is in beide oplossing niet te zien.
Iemand verder nog een tip om het probleem op te lossen.

Alvast bedankt.

Weet je zeker dat ze die oplossing goed hebben uitgerold? Werkt bij ons dikke prima. Geen DA, maar plesk, wel op Debian omgevingen.

ja dat weet ik helaas zeker
dit is de reactie van mijn systeembeheerder.

Nee, dit soort dingen hebben we al maar het wordt waarschijnlijk niet via een php script uitgevoerd.
maar deze is iets lastiger dan normaal.

Nog meer tips
Zou heel erg welkom zijn.

We staan alweer helaas op zo rbl lijst.
En je komt er niet zomaar vanaf.

Mvg,

Dennis

Oorspronkelijk geplaatst door dennis1309

Nee, dit soort dingen hebben we al maar het wordt waarschijnlijk niet via een php script uitgevoerd.

dan is het dus cgi/perl en zou je het alsnog op die manier moeten kunnen zien (suexec suphp mod_ruid) dus laat hem nog maar een keer kijken

oke dank je.
En als dit niet lukt nog een andere oplossing?

Oorspronkelijk geplaatst door dennis1309

oke dank je.
En als dit niet lukt nog een andere oplossing?

alleen HTML gaan hosten of een andere systeembeheerder zoeken

oke duidelijk ik hou je op de hoogte.
dit is een hele goede systeembeheerder dus we gaan het uitgebreid testen.

Staat er niets in je /var/log/exim/mainlog?
Als je daar niets verdachts ziet staan, dan is het misschien niet exim die je mail verstuurd.

Probeer anders ook eens
netstat --tcp -p

Die laat je zien de openstaande verbindingen zien, en welk process die verbinding heeft. Daar kan je dus normaal gezien zien welk process verantwoordelijk is voor eventuele uitgaande SMTP verbinding.

oke dank je gaan we doen.

Als je alle uitgaande email met een smarthost via onze uitgaande filter kan relayen wil ik ook best wel even helpen troubleshooten.