Zimbra och skydd mot mailbombning

Mail bombing är en av de äldsta formerna av cyberattacker. I sin grundform liknar den en vanlig DoS-attack, men istället för en våg av förfrågningar från olika ip-adresser, skickas en stor mängd e-postmeddelanden till en specifik e-postadress, vilket leder till en kraftig ökning av belastningen på den. En sådan attack kan resultera i att e-postlådan blir obrukbar och kan ibland till och med orsaka ett totalavbrott av hela servern. Den långa historien av denna typ av cyberattacker har lett till både positiva och negativa konsekvenser för systemadministratörer. De positiva aspekterna inkluderar en god förståelse för mail bombing och förekomsten av enkla metoder för att skydda sig mot denna attack. De negativa faktorerna inkluderar ett stort antal offentligt tillgängliga programvarulösningar för att genomföra sådana attacker och möjligheten för angriparen att effektivt skydda sig mot upptäckten.

En viktig egenskap hos denna cyberattack är att den är praktiskt taget omöjlig att använda för att generera vinster. Nåväl, angriparen skickade en stor mängd e-postmeddelanden till en av e-postlådorna, han hindrade helt enkelt personen från att använda sin e-post normalt, eller så hackade angriparen någon företags-e-post och började massutskicka tusentals meddelanden till hela GAL, vilket ledde till att servern antingen kraschade eller började lagga så mycket att den blev obrukbar, och vad händer sedan? Att omvandla en sådan cyberbrottslighet till riktiga pengar är nästan omöjligt, därför är mail bombing i dagsläget ett ganska sällsynt fenomen och systemadministratörer kan helt enkelt glömma att skydda sig mot denna typ av cyberattack när de planerar sin infrastruktur.

Trots att mailbombning i sig är en ganska meningslös sysselsättning ur kommersiell synvinkel, är det ofta en komponent i andra, mer komplexa och flerstegade cyberattacker. Till exempel, när e-posten hackas och används för att ta över ett konto på någon offentlig tjänst, bombar angriparna ofta offrets inkorg med meningslösa e-postmeddelanden så att ett bekräftelsemeddelande går förlorat bland dessa och förblir obemärkt. Mailbombning kan också användas som ett medel för ekonomiskt tryck mot ett företag. Aktiv bombardering av företagets offentliga e-postadress, som tar emot förfrågningar från kunder, kan allvarligt försvåra arbetet med dessa och kan som en konsekvens leda till stillestånd av utrustning, ouppfyllda beställningar, samt förlust av rykte och missad vinst.

Det är just därför systemadministratören inte bör glömma risken för mailbombning och alltid vidta nödvändiga åtgärder för att skydda sig mot detta hot. Med tanke på att detta kan göras redan i samband med uppbyggnaden av e-postinfrastrukturen, och det faktum att det tar systemadministratören mycket lite tid och ansträngning, finns det helt enkelt inga objektiva skäl att inte skydda sin infrastruktur mot mailbombning. Låt oss ta en titt på hur skyddet mot denna cyberattack är implementerat i Zimbra Collaboration Suite Open-Source Edition.

I grunden ligger Zimbra på Postfix — en av de mest pålitliga och funktionella Mail Transfer Agents med öppen källkod för närvarande. En av de största fördelarna med dess öppenhet är att den stöder en mängd olika tredjepartslösningar för att utöka funktionaliteten. Särskilt stöder Postfix fullt ut cbpolicyd — en avancerad verktyg för att säkerställa cybersäkerheten hos e-postservern. Förutom skydd mot skräppost och skapande av vita, svarta och grå listor, gör cbpolicyd det möjligt för Zimbra-administratören att ställa in en SPF-signaturkontroll och att ålägga begränsningar för mottagande och sändning av e-post eller data. De kan både ge ett tillförlitligt skydd mot skräppost och phishing-e-post, samt skydda servern mot mailbombning.

Det första som krävs av systemadministratören är aktivering av modulen cbpolicyd, som är förinstallerad i Zimbra Collaboration Suite OSE på MTA-servern i infrastrukturen. Detta görs med kommandot zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Efter detta måste webbgränssnittet aktiveras för att kunna hantera cbpolicyd på ett bekvämt sätt. För detta krävs att anslutningar till webport nummer 7780 tillåts, skapa en symbolisk länk med hjälp av kommandot ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, och sedan redigera konfigurationsfilen med hjälp av kommandot nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, där följande rader måste anges:

$DB_DSN='sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb';
$DB_USER='root';
$DB_TABLE_PREFIX='';

Efter detta återstår det bara att starta om Zimbra och Zimbra Apache-tjänsterna med kommandona zmcontrol restart och zmapachectl restart. Efter detta får du tillgång till webbgränssnittet på adressen example.com:7780/webui/index.php. Den huvudsakliga punkten är att inloggningen till detta webbgränssnitt hittills inte är skyddad, och för att förhindra obehörig åtkomst kan du stänga anslutningarna på port 7780 efter varje inloggning till webbgränssnittet.

Att skydda sig mot flödet av e-post som kommer från det interna nätverket möjliggör kvoter för utskick av e-post, som kan ställas in via cbpolicyd. Dessa kvoter gör det möjligt att ställa in ett tak för det maximala antalet e-postmeddelanden som kan skickas från en e-postlåda per tidsenhet. Till exempel, om cheferna på ditt företag i genomsnitt skickar 60-80 e-postmeddelanden i timmen, kan man, med hänsyn till en liten marginal, ställa in en kvot på 100 e-postmeddelanden i timmen. För att förbruka en sådan kvot måste cheferna skicka ett meddelande var 36:e sekund. Å ena sidan är detta tillräckligt för att arbeta effektivt, å andra sidan förhindrar en sådan kvot att illvilliga aktörer som fått tillgång till en av dina ledares e-postmeddelanden orsakar e-postbombning eller massiva spamattacker mot företaget.

För att ställa in en sådan kvot måste du i webbgränssnittet skapa en ny policy för begränsning av e-postutskick och ange att den ska gälla både för meddelanden som skickas inom domänen och för meddelanden som är riktade till externa adresser. Detta görs på följande sätt:

Efter detta kan man mer detaljerat ange begränsningar för utskick av e-post, särskilt ställa in en tidsperiod efter vilken begränsningarna kommer att uppdateras, samt meddelandet som användaren får när de överskrider sin gräns. Efter det kan man också ställa in själva begränsningen för utskick av e-post. Den kan anges antingen som ett antal utgående e-postmeddelanden eller som en mängd överförd information i byte. När det gäller e-postmeddelanden som skickas över den angivna gränsen kan man agera på olika sätt. Man kan exempelvis välja att radera dem direkt, eller spara dem så att de skickas när begränsningen för utskick av meddelanden har uppdaterats. Den andra alternativet kan utnyttjas vid fastställandet av det optimala värdet för begränsningen av e-postutskick av anställda.

Förutom begränsningarna för utskick av e-post möjliggör cbpolicyd att ställa in en gräns för mottagning av e-post. En sådan begränsning verkar vid första anblicken vara en utmärkt lösning för att skydda mot e-postbombning, men i praktiken kan installationen av en sådan gräns, även om den är stor, leda till att viktiga meddelanden inte når fram under vissa förhållanden. Just därför rekommenderas det starkt att inte införa några begränsningar för inkommande e-post. Men om du trots allt har bestämt dig för att ta risken, måste du vara särskilt noggrann när du ställer in begränsningen för inkommande meddelanden. Till exempel kan man begränsa antalet inkommande e-postmeddelanden från betrodda partner, så att om deras e-postserver skulle bli komprometterad, inte kan genomföra en spamattack mot ditt företag.

För att skydda sig mot en översvämning av inkommande meddelanden vid e-postbombning bör systemadministratören vidta smartare åtgärder än att bara begränsa inkommande e-post. En sådan lösning kan vara att använda grålistor. Principen bakom grålistor är att vid det första försöket att leverera ett meddelande från en opålitlig avsändare avbryts anslutningen till servern, vilket gör att leveransen misslyckas. Men om en opålitlig server återigen försöker skicka samma meddelande efter en viss period, bryter servern inte anslutningen och leveransen går igenom.

Syftet med alla dessa åtgärder är att program för automatisk massutskick av e-post vanligtvis inte kontrollerar om ett meddelande har levererats framgångsrikt och gör inga försök att skicka det igen, medan en människa säkerligen skulle kontrollera om hennes meddelande har nått sin destination eller inte.

Grålistor kan också aktiveras i webbgränssnittet för cbpolicyd. För att allt ska fungera måste en policy skapas som omfattar alla inkommande meddelanden riktade till användare på vår server, och baserat på denna policy skapa en regel för Grålistning, där intervallet kan ställas in under vilket cbpolicyd kommer att vänta på ett svar från en okänd avsändare. Vanligtvis sträcker sig detta över 4-5 minuter. Under tiden kan grålistorna konfigureras så att alla framgångsrika och misslyckade försök att leverera meddelanden från olika avsändare beaktas och baserat på deras antal tas beslut om automatisk inkludering av avsändaren i vit eller svart lista.

Vi uppmanar er att använda grålistor med största ansvar. Det är bäst om användningen av denna teknik går hand i hand med kontinuerlig hantering av vita och svarta listor för att utesluta risken för att verkligen viktiga meddelanden för företaget går förlorade.

Dessutom kan skydd mot mailbombing underlättas genom att lägga till SPF-, DMARC- och DKIM-kontroller. Ofta passerar inte e-postmeddelanden som kommer i samband med mailbombing dessa kontroller. Hur man gör detta har beskrivits. i en av våra tidigare artiklar.

Således är det ganska enkelt att skydda sig mot ett hot som mailbombing, och detta kan göras redan i byggskedet av Zimbra-infrastrukturen för ert företag. Det är dock viktigt att ständigt övervaka så att riskerna med att använda ett sådant skydd aldrig överstiger de fördelar ni får.

Källa: habr.com