Mailbombarding is een van de oudste vormen van cyberaanvallen. Het lijkt in wezen op een gewone DoS-aanval, maar in plaats van een vloedgolf van verzoeken vanuit verschillende ip-adressen, wordt er een stroom van e-mails naar de server gestuurd, die in enorme hoeveelheden binnenkomen op een van de e-mailadres, waardoor de belasting aanzienlijk toeneemt. Een dergelijke aanval kan leiden tot het onbruikbaar worden van de e-mailbox en kan in sommige gevallen zelfs leiden tot een volledige serveruitval. Jarenlange ervaring met deze vorm van cyberaanvallen heeft geleid tot een aantal positieve en negatieve gevolgen voor systeembeheerders. Onder de positieve aspecten valt de goede documentatie van mailbombarding en de beschikbaarheid van eenvoudige manieren om jezelf tegen zo'n aanval te beschermen. Negatieve factoren zijn echter het grote aantal algemeen beschikbare software-oplossingen voor het uitvoeren van dergelijke aanvallen en de mogelijkheid voor aanvallers om zich betrouwbaar te verbergen.
Een belangrijk kenmerk van deze cyberaanval is dat het vrijwel onmogelijk is om er winst mee te behalen. Zelfs als een aanvaller een stroom van e-mails naar één van de e-mailboxen stuurt, of iemand de mogelijkheid om normaal gebruik te maken van e-mail ontneemt, of als een aanvaller iemands bedrijfs-e-mail hackt en duizenden berichten door de GAL verstuurt, waardoor de server ofwel crasht of zo traag wordt dat het gebruik ervan onmogelijk is, wat dan? Het omzetten van een dergelijke cybercriminaliteit in contant geld is bijna onmogelijk, daarom is mailbombarding momenteel een vrij zeldzaam fenomeen, en systeembeheerders kunnen simpelweg vergeten om bij het ontwerpen van infrastructuren rekening te houden met de noodzaak om zich tegen een dergelijke cyberaanval te beschermen.
Toch, hoewel mailbombing op zichzelf een vrij zinloze commerciële activiteit is, is het vaak een onderdeel van andere, meer complexe en gelaagde cyberaanvallen. Bijvoorbeeld bij het hacken van e-mail en het gebruiken daarvan voor het overnemen van een account in een publieke service, bombarderen kwaadwillenden vaak de mailbox van het slachtoffer met zinloze berichten, zodat de bevestigingsmail verloren raakt in de stroom en niet opgemerkt wordt. Daarnaast kan mailbombing worden gebruikt als een middel van economische druk op een onderneming. Een actieve bombardement op de publieke mailbox van een bedrijf, waar aanvragen van klanten binnenkomen, kan het werken met deze aanvragen ernstig bemoeilijken, wat kan leiden tot stilstand van de apparatuur, niet-uitgevoerde bestellingen, alsook tot reputatieverlies en gemiste winst.
Dat is precies waarom een systeembeheerder niet moet vergeten dat mailbombing een mogelijkheid is en altijd de nodige maatregelen moet nemen om zich tegen deze bedreiging te beschermen. Als we rekening houden met het feit dat dit al mogelijk is in de fase van het opzetten van de e-mailinfrastructuur, en dat het de systeembeheerder nauwelijks tijd en moeite kost, blijven er objectief gezien geen redenen over om de infrastructuur niet te beschermen tegen mailbombing. Laten we eens kijken naar hoe de bescherming tegen deze cyberaanval is geïmplementeerd in de Zimbra Collaboration Suite Open-Source Edition.
De basis van Zimbra is Postfix — een van de meest betrouwbare en functionele Mail Transfer Agents met open source op dit moment. Een van de belangrijkste voordelen van de openheid is dat het een breed scala aan externe oplossingen voor functionaliteitsuitbreiding ondersteunt. In het bijzonder ondersteunt Postfix volledig cbpolicyd — een geavanceerde tool voor het waarborgen van de cybersecurity van de mailserver. Naast bescherming tegen spam en het opstellen van witte, zwarte en grijze lijsten, stelt cbpolicyd de Zimbra-beheerder in staat om SPF-handtekeningen te controleren en beperkingen in te stellen voor het ontvangen en verzenden van e-mails of gegevens. Deze kunnen zowel zorgen voor een betrouwbare bescherming tegen spam en phishing-e-mails als de server tegen mailbombing beschermen.
Het eerste wat van de systeembeheerder vereist is, is het activeren van de cbpolicyd-module, die is voorgeïnstalleerd in Zimbra Collaboration Suite OSE op de MTA-server van de infrastructuur. Dit gebeurt met het commando zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Daarna moet de webinterface worden geactiveerd, zodat u cbpolicyd comfortabel kunt beheren. Hiervoor moet verbinding op webpoortnummer 7780 worden toegestaan, en moet er een symbolische link worden gemaakt met behulp van het commando ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, en vervolgens moet het configuratiebestand worden bewerkt met het commando nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, waarin de volgende regels moeten worden opgenomen:
$DB_DSN=«sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb»;
$DB_USER=«root»;
$DB_TABLE_PREFIX=»»;
Daarna hoeft u alleen nog maar de Zimbra- en Zimbra Apache-services opnieuw op te starten met de commando's zmcontrol restart en zmapachectl restart. Na dit bedraagt de toegang tot de webinterface op het adres :7780/webui/index.php. Een belangrijk punt is dat de toegang tot deze webinterface momenteel niet beveiligd is, en om te voorkomen dat ongeautoriseerde personen toegang krijgen, kunt u na elke toegang tot de webinterface gewoon de verbinding op poort 7780 sluiten.
Om te beschermen tegen de stroom van e-mails vanuit het interne netwerk, zijn er verzendquota voor e-mails die kunnen worden ingesteld met behulp van cbpolicyd. Deze quota stellen u in staat om een beperking in te stellen voor het maximale aantal e-mails dat vanuit één mailbox gedurende een bepaalde tijd kan worden verzonden. Bijvoorbeeld, als de managers van uw bedrijf gemiddeld 60-80 e-mails per uur verzenden, kunt u, met een kleine marge in gedachten, een quotum van 100 e-mails per uur instellen. Om dat quota te overschrijden, zouden de managers e-mails om de 36 seconden moeten verzenden. Aan de ene kant is dit voldoende om goed te kunnen functioneren, maar aan de andere kant zorgt zo'n quotum ervoor dat aanvallers die toegang hebben gekregen tot de e-mail van een van uw managers, geen mailbombardement of massale spam-aanval op het bedrijf kunnen uitvoeren.
Om zo'n quotum in te stellen, moet er in de webinterface een nieuw beleid voor de beperking van het verzenden van e-mails worden gemaakt, en moet worden aangegeven dat dit zowel voor e-mails die binnen het domein worden verzonden, als voor e-mails die naar externe adressen worden verzonden, geldt. Dit gebeurt als volgt:
Hierna kan je de beperkingen met betrekking tot het verzenden van e-mails meer in detail specificeren, in het bijzonder de tijdsperiode instellen waarna de beperkingen worden bijgewerkt, evenals het bericht dat de gebruiker ontvangt wanneer hij zijn limiet overschrijdt. Vervolgens kan je ook de beperking voor het verzenden van e-mails instellen. Deze kan worden gespecificeerd als een aantal uitgaande e-mails of als een aantal bytes aan verzonden informatie. Daarnaast kan men op verschillende manieren omgaan met e-mails die het opgegeven limiet overschrijden. Zo kunnen ze bijvoorbeeld direct worden verwijderd of opgeslagen zodat ze kunnen worden verzonden zodra de limiet voor het verzenden van berichten is bijgewerkt. De tweede optie kan worden gebruikt bij het bepalen van de optimale waarde voor de verzendlimiet van e-mails door medewerkers.
Naast de beperkingen voor het verzenden van e-mails, stelt cbpolicyd ook een limiet in voor het ontvangen van e-mails. Een dergelijke beperking lijkt op het eerste gezicht een goede oplossing om mailbombardementen te beschermen, maar in de praktijk kan het instellen van zo'n limiet, zelfs een hoge, ertoe leiden dat je belangrijke e-mails mist onder bepaalde omstandigheden. Daarom wordt het ten zeerste afgeraden om enige beperkingen voor inkomende e-mails in te schakelen. Maar als je toch het risico wilt nemen, moet je de instelling van de limiet voor inkomende berichten met bijzondere aandacht benaderen. Bijvoorbeeld, je kunt het aantal inkomende e-mails van betrouwbare partners beperken, zodat als hun e-mailserver is gecompromitteerd, er geen spam-aanval op jouw onderneming kan plaatsvinden.
Om jezelf te beschermen tegen een stortvloed aan inkomende berichten bij mailbombardementen, moet de systeembeheerder iets slimmer ondernemen dan alleen een beperking op inkomende e-mail in te stellen. Een mogelijke oplossing kan het gebruik van grijze lijsten zijn. Het principe ervan is dat bij de eerste poging om een bericht van een onbetrouwbare afzender af te leveren, de verbinding met de server abrupt wordt verbroken, waardoor de bezorging van de e-mail mislukt. Echter, als de onbetrouwbare server na een bepaalde tijd opnieuw probeert hetzelfde bericht te verzenden, wordt de verbinding niet verbroken en kan de bezorging succesvol plaatsvinden.
Het doel van al deze acties is dat programma's voor automatische bulk-e-maildistributie meestal de succesvolle aflevering van een verzonden bericht niet controleren en geen pogingen doen om het opnieuw te verzenden, terwijl een persoon zich er zeker van zal zijn of zijn e-mail al dan niet is verzonden.
Grijze lijsten kunnen ook worden ingeschakeld in de webinterface van cbpolicyd. Om alles goed te laten werken, moet je een beleid maken dat alle inkomende berichten omvat die zijn gericht aan gebruikers op onze server, en op basis van dit beleid een grijslijstregel aanmaken, waar je de tijdsduur kunt instellen waarin cbpolicyd een herhalingsantwoord van een onbekende afzender zal afwachten. Dit is meestal 4-5 minuten. Daarnaast kunnen grijze lijsten zo worden ingesteld dat alle succesvolle en onsuccesvolle pogingen om berichten van verschillende afzenders te bezorgen worden geregistreerd, en op basis van hun aantallen een beslissing wordt genomen over de automatische toevoeging van de afzender aan de witte of zwarte lijsten.
We willen benadrukken dat het gebruik van grijze lijsten met de grootst mogelijke ernst moet worden benaderd. Het is het beste als het gebruik van deze technologie hand in hand gaat met een voortdurend beheer van witte en zwarte lijsten, om de kans op het verlies van echt belangrijke berichten voor het bedrijf te minimaliseren.
Bovendien kan het toevoegen van SPF-, DMARC- en DKIM-controles helpen om je te beschermen tegen mailbombardementen. Vaak slagen berichtjes die tijdens een mailbombardement binnenkomen niet voor deze controles. Hoe je dit kunt doen, is beschreven .
Op deze manier is het vrij eenvoudig om jezelf te beschermen tegen de bedreiging van mailbombardementen, en dit kan zelfs al in de fase van het bouwen van de Zimbra-infrastructuur voor jouw bedrijf worden gedaan. Het is echter belangrijk om voortdurend in de gaten te houden dat de risico's van het gebruik van deze bescherming nooit opwegen tegen de voordelen die je ontvangt.
Bron: habr.com
