Bekijk Volledige Versie : Spam niet te traceren
dennis1309
01/07/09, 12:33
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
dennis1309
01/07/09, 12:52
Oke ga ik zeker doornemen met mijn systeembeheerders.
Hebben jullie nog meer tips.
jinxedworld
01/07/09, 13:09
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
dennis1309
01/07/09, 13:15
Oke maar het is in beide oplossing niet te zien.
Iemand verder nog een tip om het probleem op te lossen.
Alvast bedankt.
jinxedworld
01/07/09, 13:20
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.
dennis1309
01/07/09, 13:32
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
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 ;)
dennis1309
01/07/09, 13:40
oke dank je.
En als dit niet lukt nog een andere oplossing?
oke dank je.
En als dit niet lukt nog een andere oplossing?
alleen HTML gaan hosten of een andere systeembeheerder zoeken :innocent:
dennis1309
01/07/09, 13:48
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.
dennis1309
01/07/09, 14:53
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.
Je kunt toch in de headers zien of het via PHP is gestuurd?
dennis1309
01/07/09, 20:30
Beste,
Bedankt voor het aanbod ik neem morgen even contact op.
Beste,
Bedankt voor het aanbod ik neem morgen even contact op.
Morgen? Dan weet je zeker dat je enkele dagen mag besteden aan het delisten :X Zoiets moet je niet tot morgen laten wachten, act now!
dennis1309
01/07/09, 22:00
Beste Ron,
Ik ben al drie dagen bezig
En was juist net klaar met delisten.
Tot er vanochtend weer iemand ging spammen.
Daar baal ik juist van.
We zijn dag en nacht bezig.
Alvast bedankt.
Niet bepaald een effectief beleid wat jullie handteren !
dennis1309
02/07/09, 08:38
Wij doen er juist alles aan om spam tegen te gaan en niet op rbl lijsten te komen.
Wij doen er juist alles aan om spam tegen te gaan en niet op rbl lijsten te komen.
misschien zeg ik het wat bot.. maar je doet alles behalve wat je moet doen.. zorgen dat het gefixt wordt en 3 dagen aan naar een linux doosje kijken en het niet gefixt hebben zegt genoeg over je systeembeheerder.. :rolleyes:
Ik zou zeggen plaats een request voor hulp van iemand hier, Randy zal vast nog wel ergens een half uurtje hebben om er naar te kijken en het op te lossen.
dennis1309
02/07/09, 09:58
Jullie denken dat wij stil zitten en dat wij niet kijken.
Wij kijken juist en het is opgelost.
Wij vroegen alleen wat tips. Dingen die wij over het hoofd zien.
Dus bedankt voor alle reacties.
Mvg,
Dennis
So, the burning question, wat was nu de oorzaak? Slecht scriptje, gehackte account, gebruiker die zich misdroeg, ...? Kan voor anderen misschien ook nuttige info zijn.
Indien je nog hulp nodig hebt, stuur gerust even een PB en help je graag met traceren!