Onderwerp: SPAM Bestrijding

Wij beheren op dit moment 9 Live servers (VPS) met Directadmin, maar wij worden regelmatig met onze neuzen op de feiten gedrukt dat wij de mail afhandeling nog niet goed op orde hebben.

We draaien over het algemeen DirectAdmin op 2 servers na welke gewoon kale linux servers zijn.

Het Probleem:

Regelmatig wordt er een website gehackt, meestal als ze outdated zijn (Klant heeft dan geen service contract met ons voor het up to date houden), maar het komt sporadisch ook voor dat up to date sites gehackt worden. Het betreft meestal de Joomla sites, maar soms ook Wordpress.

Overigens bij onze Django, Typo3 en Magento sites hebben we nog geen hacks meegemaakt.

Wat gebeurd er na een hack? De website wordt geïnfecteerd met rotzooi en gaat lopen spammen.
Deze spam wordt eigenlijk altijd uitgestuurd d.m.v. de PHP Mail functie.

Onze filosofie
Wij zijn van mening dat we een hoop gezeur kunnen voorkomen door de reguliere mail (Fysieke mailboxen) te scheiden van de door PHP gestuurde mail.
Ons idee is dan om de PHP mail te forwarden naar een low budget mailserver welke dusdanig is geconfigureerd dat deze max 1 bericht per domein per 2 seconden verstuurd, verder moet er een check op komen dat er per domein bijvoorbeeld maximaal 200 mails verzonden mogen worden elke dag.

Worst Case Scenario zou dan zijn dat die mailbox geblacklist wordt en dat er geen mail vanuit de websites meer binnen komt, maar klanten kunnen dan wel zelf blijven mailen met hun relaties, omdat dit door de live server zelf wordt afgehandeld.

Vraag aan jullie

We lopen gewoon steeds achter de feiten aan als het op spam bestrijding aankomt, wat zouden jullie ons adviseren? Is onze filosofie een plan wat zou kunnen werken, of denken we nu heel krom. Ik ben zelf geen serverbeheerder maar een web developer, dus ik heb hier niet heel veel kaas van gegeten al weet ik mij redelijk te redden binnen linux. Al met al wil ik gewoon dingen uitzoeken en met een plan van aanpak komen om dit probleem zo veel mogelijk te bestrijden.

Technische specificatie's
Alle servers zijn voorzien van CSF (firewal) en worden netjes onderhouden wat betreft updates.
Webserver: Apache 2.2.26 zeg ik uit mijn hoofd.
PHP: 5.4.25
MySQL: 5.5.36
Exim: 4.82

Graag hoor ik van jullie, alle hulp is welkom.

Als je de nieuwste exim.conf gebruikt kan je per user de uitgaande mails per dag limiteren.

Het default limiet staat bij ons op 200 uitgaande mails.
Per user kan je deze verhogen

/etc/virtual/limit zet je het default limiet in en in /etc/virtual/limit_username individueel voor 1 user.

Sent from my HTC One using webhostingtalk mobile app

@dennis0162

Bedankt voor de tip, echter staat er zo te zien al een limiet ingesteld van (toevallig) 200 mails per dag.
Maar ik vraag me af of alleen dit afdoende zal zijn, immers als er SPAM uitgegooid wordt, kom je (volgens mij) sowieso op de blacklists ook al zijn dit dan 200 berichten ipv duizenden.

Hier drie opties:

Gratis:
http://sourceforge.net/projects/assp/ & http://www.magicvillage.de/~Fritz_Bo...D91C-8000001C/

http://www.mailscanner.info/

Betaald:
http://www.spamexperts.nl (ook op het forum te vinden, @Dreas )

Oorspronkelijk geplaatst door l.degroot01

@dennis0162

Bedankt voor de tip, echter staat er zo te zien al een limiet ingesteld van (toevallig) 200 mails per dag.
Maar ik vraag me af of alleen dit afdoende zal zijn, immers als er SPAM uitgegooid wordt, kom je (volgens mij) sowieso op de blacklists ook al zijn dit dan 200 berichten ipv duizenden.

De kans dat je er met 200 op komt is kleiner dan bij duizenden. Wel pak je met deze setting alles van een gebruiker en wil het soms fout gaan met mail verzonden via de mail() functie van php en wat rechtstreeks vanuit een script wordt verzonden middels smtp blokkeer je ook niet. Wat wij hebben gedaan (bij een cluster met losse webservers) is alle mail vanaf de webservers via een custom check sturen (een deamon die aangeroepen wordt door Postfix). Deze doet enkele checks (aantal mails kwartier/uur/dag) en als 1 van deze waardes boven een bepaalde waarde komt voor een bepaalde klant dan blokkeert hij de mail tijdelijk (gaat op onhold), vervolgens neemt iemand van ons de beslissing wat de juiste actie is (vrijgeven of verwijderen). De keuze hangt af van het type mails.

Door een getrapte limiet te hanteren beperk je het risico en wij kunnen op deze manier makkelijk uitzonderingen maken voor individuele klanten. Daarnaast hebben we zo de limiet gesplitst (mbt de mail() functie en smtp vanuit php).

Bedoel je de SMTP server lokaal of een externe server?

Via PHP kunnen klanten bij ons sowieso geen verbinding maken met een SMTP server. Alleen localhost.

Mails via de lokale SMTP worden ook gelimit op 200 per dag.

Sent from my HTC One using webhostingtalk mobile app

Bij ons gaat smtp via een andere server. We hebben al wel geblokkeerd dat een verbinding opgezet kan worden middels smtp vanaf de webservers naar een server die niet van ons is. Maar goed je hebt het ene "lek" gedicht en ze vinden weer wat nieuws. Vaak zien wij wel dat er verouderde versies van Joomla!/WordPress/etc. mede de boosdoener lijkt te zijn.

Wat je kunt doen is 2 postfix instanties draaien waarbij de één gewoon een relay is naar de ander. Dan kun je die 2de koppelen aan postfix-policyd en het nodige throttlen dat via de de php mail() functie gaat. Eventueel kun je de boel scannen voor virussen of spam, greylisten, limieten per uur tot per per maand opleggen e.d. (die eerste instantie is gewoon om de mail in een buffer te houden indien hij 'afgekeurd' wordt door de 2de instantie door bv. greylisting, throttling, limiet bereikt e.d.)

Eventueel, maar dat is dan meer voor systemen met een eigen ip, kun je op basis van de uitkomsten het betreffende server ip even onder een subdomein dumpen in rbl formaat ( ip 1.2.3.4 wordt dan bv. 4.3.2.1.rbl.mijndomein.nl ) en dan rbl.mijndomein.nl aan bv. spamassasin configs of je firewalll toevoegen en zo de server tijdelijk op slot gooien totdat je het probleem opgelost hebt.
Wil je dat alleen voor een user doen, dan kun je in plaats van een ip ook een 'naam' gebruiken en dan gewoon alles droppen zolang 'host naam.rbl.mijndomein.nl' een reply geeft.
Dat zou je mooi in de access control plugin van policyd kunnen mikken.

Iedereen bedankt voor alle tips.
Ik ga het morgen even afstemmen met de leidinggevende.

Ik ben in iedergeval weer een hoop wijzer geworden, als we een besluit genomen hebben dan zal ik de resultaten posten.