Bescherming SMTP (en nog meer...)

[remko]

Gegroet,

Een klant van mij heeft pas, door onoplettendheid, middels PHPBB een gat gemaakt waardoor iemand erin was geslaagd mijn server als mass-mailer te gebruiken. Zal wel een soort worm zijn geweest want het betrof 99% emailadressen in taiwan. Nu heeft me dat aardig wat energie en tijd gekost + extreme serverloads achteraf door alle bounce-backs van niet bestaande emailadressen.

En toen vroeg ik me dus af hoe andere hosters hiermee omgaan. Is er een manier om je mailserver beter te beschermen tegen dit soort scripts?

Thnx alvast....
Remko

[lifeforms]

Ja, maar dat is in dit geval symptoombestrijding. Als men binnenkomt door (zucht) phpBB is spam niet het enige probleem. Je machine kan ook worden gebruikt voor DoS attacks, je privébestanden liggen op straat, enzovoorts. Dus beter steek je geen energie in de mailserver maar in security.

Dat gezegd hebbende, het is vast mogelijk om rate limiting toe te passen op je mailserver. Het hangt er alleen een beetje vanaf welke mailserver en welk besturingssysteem je gebruikt.

[remko]

Hoi,

Op zich heb ik al een hoop ondernomen qua beveiliging. (en met ingang van vandeweek in phpbb niet meer welkom) maar ik ben er nog niet helemaal achter waar het 'gat' zit wat via phpbb is uitgevoerd.

[XBL]

Verbieden van phpbb zal je niet vrienden laten maken, maar soit. Je kan beter zorgen dat, als phpbb (of elk ander script) een gat heeft, het verder geen nut heeft als dat wordt misbruikt. Bijvoorbeeld chmodden van enkele tools (wget, bijv), zodat ze niet gebruikt kunnen worden door klanten. En ook het gebruiken van een wrapper als suphp, zodat scripts enkel aan bestanden van de klant zelf kunnen rommelen.

Verder weet ik niet hoe je je tegen extreem veel bounces kan beschremen, maar ik neem aan dat de documentatie van je smtpserver dat wel weet.

Met wat skydancer ben ik het overigens niet eens. Of hij moet onder security elke layer die je maakt om je te beschermen, bedoelen. Maar het beveiligen van je mailserver tegen extreem veel bounces, is ook slim. Hoe meer layers, hoe beter. Als dan één of meer layers wegvallen, heb je er altijd nog een aantal over.

Wel ben ik het met skydancer eens dat je eerst preventief aan de gang moet gaan. Voorkomen is immers beter dan genezen.

Jochem

[maxnet]

Rate-limiten van e-mail is erg lastig.
Niet in alle gevallen weet de mailserver namenlijk welke gebruiker de e-mail verstuurd.

Er zijn meerdere manieren waarop een script e-mail kan versturen:

1) door de te versturen e-mail aan de lokale mailserver te leveren met behulp van het "sendmail" programma.

2) door verbinding te maken met de lokale mailserver via TCP/IP (127.0.0.1:25)

3) door rechtstreeks verbinding te maken met de mailserver van de geadreseerde waar de e-mail heen moet.


Bij de eerste methode is bij de mailserver bekend welke gebruiker de e-mail verstuurd, en kan er mogelijk een limiet worden ingesteld.

Bij de twee methode weten de meeste mailservers niet welke gebruiker het is (tenzij ident wordt ondersteund).

De laatste methode is te voorkomen door uitgaande verbindingen naar poort 25 voor gebruikers (anders dan de mailserver) dicht te zetten met pf/iptables.

[fusehost]

Je kan het best ervoor zorgen dat scripts niet langer als de apache-user worden uitgevoerd, maar als de user van wie de scripts zijn. Daardoor kan het script enkel aan de files van die gebruiker (voorbeelden zijn al gegeven, onder andere suphp en aanverwanten).

Verder is het goed om zelf ook de lijsten te volgen waar fouten op gemeld worden, en met behulp van bvb mod_security de boel proberen dicht te zetten voor de exploit gebruikt wordt. Eens je weet welke fout in welk script zit, kan je op de servers alle accounts scannen op de foutieve versie (meestal een search naar een bepaald bestand, en dan een grep naar de juiste strings), en mails sturen naar de klanten.

Uitgaande smtp limiteren is moeilijker, maar kan altijd gedaan worden. Als je stats bijhoudt van je mailsysteem (in en uitgaand), en je monitored die met waarden die hebt uit normaal gebruik, moet je normaal gemakkelijk een bericht/mail/sms/... kunnen krijgen wanneer er iets zich verdacht gedraagd. Zo moet je toch vrij snel kunnen ingrijpen...

[remko]

Bedankt voor de tips in iedere geval. Zal wel even kijken welke dingen op dit moment nog niet zo zijn en dit alsnog doorvoeren.