Mailbombardementen zijn een van de oudste vormen van cyberaanvallen. In de kern lijkt het op een gewone DoS-aanval, alleen wordt er in plaats van een golf van verzoeken van verschillende IP-adressen een golf van e-mails naar de server gestuurd, die in grote hoeveelheden op een van de e-mailadressen aankomen, waardoor de belasting hierop neemt aanzienlijk toe. Een dergelijke aanval kan ertoe leiden dat de mailbox niet meer kan worden gebruikt, en soms zelfs tot het uitvallen van de hele server. De lange geschiedenis van dit soort cyberaanvallen heeft geleid tot een aantal positieve en negatieve gevolgen voor systeembeheerders. Positieve factoren zijn onder meer een goede kennis van postbombardementen en de beschikbaarheid van eenvoudige manieren om uzelf tegen een dergelijke aanval te beschermen. Negatieve factoren zijn onder meer een groot aantal openbaar beschikbare softwareoplossingen voor het uitvoeren van dit soort aanvallen en het vermogen van een aanvaller om zichzelf op betrouwbare wijze tegen detectie te beschermen.
Een belangrijk kenmerk van deze cyberaanval is dat het vrijwel onmogelijk is om er winst mee te maken. Nou, de aanvaller stuurde een golf van e-mails naar een van de mailboxen, nou, hij stond niet toe dat de persoon e-mail normaal gebruikte, nou, de aanvaller hackte iemands zakelijke e-mail en begon duizenden brieven massaal te versturen door de hele GAL, dat is waarom de server crashte of begon te vertragen, zodat het onmogelijk werd om hem te gebruiken, en wat nu? Het is bijna onmogelijk om een dergelijke cybercriminaliteit in echt geld om te zetten, dus het simpelweg bombarderen van e-mails is momenteel een vrij zeldzame gebeurtenis en systeembeheerders kunnen zich bij het ontwerpen van infrastructuur eenvoudigweg niet herinneren aan de noodzaak om zich tegen een dergelijke cyberaanval te beschermen.
Hoewel e-mailbombardementen op zichzelf vanuit commercieel oogpunt tamelijk zinloos zijn, maken ze vaak deel uit van andere, complexere cyberaanvallen die uit meerdere fasen bestaan. Wanneer aanvallers bijvoorbeeld e-mail hacken en deze gebruiken om een account bij een openbare dienst te kapen, 'bombarderen' aanvallers vaak de mailbox van het slachtoffer met betekenisloze brieven, zodat de bevestigingsbrief verloren gaat in hun stroom en onopgemerkt blijft. Postbombardementen kunnen ook worden gebruikt als middel om economische druk uit te oefenen op een onderneming. Het actief bombarderen van de openbare mailbox van een onderneming, die verzoeken van klanten ontvangt, kan het werken met hen dus ernstig bemoeilijken en als gevolg daarvan leiden tot uitval van apparatuur, onvervulde bestellingen, maar ook tot reputatieverlies en winstderving.
Daarom mag de systeembeheerder de waarschijnlijkheid van e-mailbombardementen niet vergeten en altijd de nodige maatregelen nemen om zich tegen deze dreiging te beschermen. Gezien het feit dat dit gedaan kan worden in de fase van het bouwen van de mailinfrastructuur, en ook dat het heel weinig tijd en arbeid kost van de systeembeheerder, zijn er eenvoudigweg geen objectieve redenen om uw infrastructuur niet te voorzien van bescherming tegen mailbombardementen. Laten we eens kijken hoe de bescherming tegen deze cyberaanval is geïmplementeerd in de Zimbra Collaboration Suite Open-Source Edition.
Zimbra is gebaseerd op Postfix, een van de meest betrouwbare en functionele open source Mail Transfer Agents die momenteel beschikbaar zijn. En een van de belangrijkste voordelen van de openheid is dat het een grote verscheidenheid aan oplossingen van derden ondersteunt om de functionaliteit uit te breiden. In het bijzonder ondersteunt Postfix cbpolicyd volledig, een geavanceerd hulpprogramma voor het garanderen van de cyberbeveiliging van mailservers. Naast antispambescherming en het maken van witte lijsten, zwarte lijsten en grijze lijsten, stelt cbpolicyd de Zimbra-beheerder in staat SPF-handtekeningverificatie te configureren en beperkingen in te stellen voor het ontvangen en verzenden van e-mails of gegevens. Ze kunnen zowel betrouwbare bescherming bieden tegen spam en phishing-e-mails als de server beschermen tegen e-mailbombardementen.
Het eerste dat de systeembeheerder moet doen, is het activeren van de cbpolicyd-module, die vooraf is geïnstalleerd in Zimbra Collaboration Suite OSE op de MTA-infrastructuurserver. Dit wordt gedaan met behulp van het commando zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Hierna moet u de webinterface activeren om cbpolicyd comfortabel te kunnen beheren. Om dit te doen, moet u verbindingen op webpoortnummer 7780 toestaan, maak een symbolische link met behulp van de opdracht ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuien bewerk vervolgens het instellingenbestand met de nano-opdracht /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, waar u de volgende regels moet schrijven:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Hierna hoeft u alleen nog maar de Zimbra- en Zimbra Apache-services opnieuw op te starten met behulp van de opdrachten zmcontrol restart en zmapachectl restart. Hierna heeft u toegang tot de webinterface op :7780/webui/index.php. De belangrijkste nuance is dat de toegang tot deze webinterface nog op geen enkele manier beveiligd is en om te voorkomen dat onbevoegden deze betreden, kunt u na elke toegang tot de webinterface eenvoudig de verbindingen op poort 7780 sluiten.
U kunt uzelf beschermen tegen de stroom e-mails die van het interne netwerk komt door quota's te gebruiken voor het verzenden van e-mails, die kunnen worden ingesteld dankzij cbpolicyd. Met dergelijke quota kunt u een limiet instellen op het maximale aantal brieven dat in één tijdseenheid vanuit één mailbox kan worden verzonden. Versturen uw bedrijfsmanagers bijvoorbeeld gemiddeld 60-80 e-mails per uur, dan kunt u een quotum van 100 e-mails per uur instellen, rekening houdend met een kleine marge. Om dit quotum te bereiken, moeten managers elke 36 seconden één e-mail sturen. Aan de ene kant is dit voldoende om volledig te werken, en aan de andere kant zullen aanvallers die toegang hebben gekregen tot de e-mail van een van uw managers met een dergelijk quotum geen mailbombardementen of een enorme spamaanval op de onderneming lanceren.
Om een dergelijk quotum in te stellen, moet u in de webinterface een nieuw beperkingsbeleid voor het verzenden van e-mail maken en specificeren dat dit zowel van toepassing is op brieven die binnen het domein worden verzonden als op brieven die naar externe adressen worden verzonden. Dit gebeurt als volgt:
Hierna kunt u de beperkingen die verband houden met het verzenden van brieven gedetailleerder specificeren, met name het tijdsinterval instellen waarna de beperkingen worden bijgewerkt, evenals het bericht dat een gebruiker die zijn limiet heeft overschreden, zal ontvangen. Hierna kunt u de beperking voor het verzenden van brieven instellen. Het kan zowel worden ingesteld als het aantal uitgaande letters als als het aantal bytes verzonden informatie. Tegelijkertijd moeten brieven die boven de gestelde limiet worden verzonden, anders worden behandeld. U kunt ze bijvoorbeeld eenvoudigweg onmiddellijk verwijderen, of u kunt ze opslaan, zodat ze onmiddellijk worden verzonden nadat de verzendlimiet voor berichten is bijgewerkt. De tweede optie kan worden gebruikt bij het identificeren van de optimale waarde voor de limiet op het verzenden van e-mails door medewerkers.
Naast beperkingen op het verzenden van brieven kunt u met cbpolicyd ook een limiet instellen op het ontvangen van brieven. Een dergelijke beperking is op het eerste gezicht een uitstekende oplossing om te beschermen tegen postbombardementen, maar in feite is het instellen van een dergelijke limiet, zelfs een grote, beladen met het feit dat een belangrijke brief u onder bepaalde omstandigheden mogelijk niet bereikt. Daarom wordt het ten zeerste afgeraden om eventuele beperkingen voor inkomende e-mail in te schakelen. Als u echter toch besluit het risico te nemen, moet u het instellen van de limiet voor inkomende berichten met speciale aandacht benaderen. U kunt bijvoorbeeld het aantal inkomende e-mails van vertrouwde tegenpartijen beperken, zodat als hun mailserver wordt gehackt, er geen spamaanval op uw bedrijf wordt gestart.
Om zich te beschermen tegen de toevloed van inkomende berichten tijdens mailbombardementen, zou de systeembeheerder iets slimmers moeten doen dan simpelweg de inkomende mail beperken. Deze oplossing zou het gebruik van grijze lijsten kunnen zijn. Het principe van hun werking is dat bij de eerste poging om een bericht van een onbetrouwbare afzender te bezorgen, de verbinding met de server abrupt wordt onderbroken, waardoor de bezorging van de brief mislukt. Als een niet-vertrouwde server echter op een bepaald moment opnieuw probeert dezelfde brief te verzenden, verbreekt de server de verbinding niet en is de bezorging succesvol.
Het punt van al deze acties is dat programma's voor het automatisch verzenden van massa-e-mails meestal niet controleren of het verzonden bericht succesvol is afgeleverd en niet proberen het een tweede keer te verzenden, terwijl iemand zeker zal controleren of zijn brief is verzonden naar het adres of niet.
U kunt ook grijze lijsten inschakelen in de cbpolicyd-webinterface. Om alles te laten werken, moet u een beleid maken dat alle inkomende brieven omvat die zijn gericht aan gebruikers op onze server, en vervolgens, op basis van dit beleid, een Greylisting-regel maken, waarin u het interval kunt configureren gedurende welke cbpolicyd zal wachten voor een herhaald antwoord van een onbekende afzender. Meestal is dit 4-5 minuten. Tegelijkertijd kunnen grijze lijsten zo worden geconfigureerd dat alle succesvolle en mislukte pogingen om brieven van verschillende afzenders te bezorgen in aanmerking worden genomen en op basis van hun nummer wordt besloten om de afzender automatisch aan de witte of zwarte lijsten toe te voegen.
Wij vestigen uw aandacht op het feit dat het gebruik van grijze lijsten met de grootst mogelijke verantwoordelijkheid moet gebeuren. Het zou het beste zijn als het gebruik van deze technologie hand in hand gaat met het constante onderhoud van witte en zwarte lijsten om de mogelijkheid te elimineren dat e-mails verloren gaan die echt belangrijk zijn voor de onderneming.
Bovendien kan het toevoegen van SPF-, DMARC- en DKIM-controles helpen beschermen tegen e-mailbombardementen. Brieven die via postbombardementen binnenkomen, passeren vaak deze controles niet. Hoe dit te doen werd besproken .
Jezelf beschermen tegen een bedreiging als e-mailbombardementen is dus vrij eenvoudig, en je kunt dit zelfs doen in de fase van het bouwen van de Zimbra-infrastructuur voor je onderneming. Het is echter belangrijk om er voortdurend voor te zorgen dat de risico's van het gebruik van dergelijke bescherming nooit groter zijn dan de voordelen die u ontvangt.
Bron: www.habr.com