Mailbombning är en av de äldsta typerna av cyberattacker. I sin kärna liknar den en vanlig DoS-attack, bara istället för en våg av förfrågningar från olika IP-adresser skickas en våg av e-postmeddelanden till servern, som anländer i enorma mängder till en av e-postadresserna, på grund av vilken belastningen på den ökar markant. En sådan attack kan leda till oförmåga att använda brevlådan, och ibland kan det till och med leda till att hela servern misslyckas. Den här typen av cyberattacks långa historia har lett till en rad positiva och negativa konsekvenser för systemadministratörer. Positiva faktorer inkluderar goda kunskaper om postbombning och tillgången till enkla sätt att skydda sig mot en sådan attack. Negativa faktorer inkluderar ett stort antal allmänt tillgängliga mjukvarulösningar för att utföra dessa typer av attacker och förmågan för en angripare att på ett tillförlitligt sätt skydda sig mot upptäckt.
Ett viktigt inslag i denna cyberattack är att det nästan är omöjligt att använda den för vinst. Tja, angriparen skickade en våg av e-postmeddelanden till en av brevlådorna, ja, han tillät inte personen att använda e-post normalt, ja, angriparen hackade sig in i någons företags-e-post och började masssända tusentals brev i hela GAL, vilket är varför kraschade servern eller började sakta ner så att det blev omöjligt att använda den, och vad sedan? Det är nästan omöjligt att omvandla en sådan cyberbrottslighet till riktiga pengar, så helt enkelt mailbombning är för närvarande en ganska sällsynt företeelse och systemadministratörer, när de designar infrastruktur, kanske helt enkelt inte kommer ihåg behovet av att skydda mot en sådan cyberattack.
Men även om e-postbombning i sig är en ganska meningslös övning ur kommersiell synvinkel, är det ofta en del av andra, mer komplexa och flerstegs cyberattacker. Till exempel, när man hackar e-post och använder den för att kapa ett konto i någon offentlig tjänst, "bombar" angripare ofta offrets brevlåda med meningslösa brev så att bekräftelsebrevet försvinner i deras ström och går obemärkt förbi. Postbombningar kan också användas som ett medel för ekonomisk press på ett företag. Således kan aktiv bombardering av ett företags offentliga brevlåda, som tar emot förfrågningar från kunder, allvarligt komplicera arbetet med dem och som ett resultat kan leda till utrustningsavbrott, ouppfyllda beställningar, såväl som förlust av rykte och förlorad vinst.
Det är därför systemadministratören inte bör glömma sannolikheten för e-postbombning och alltid vidta nödvändiga åtgärder för att skydda mot detta hot. Med tanke på att detta kan göras vid uppbyggnaden av e-postinfrastrukturen, och även att det tar mycket lite tid och arbete från systemadministratören, finns det helt enkelt inga objektiva skäl för att inte förse din infrastruktur med skydd mot e-postbombning. Låt oss ta en titt på hur skyddet mot denna cyber-attack implementeras i Zimbra Collaboration Suite Open-Source Edition.
Zimbra är baserat på Postfix, en av de mest pålitliga och funktionella postöverföringsagenterna med öppen källkod som finns idag. Och en av de största fördelarna med dess öppenhet är att den stöder ett brett utbud av tredjepartslösningar för att utöka funktionaliteten. I synnerhet stöder Postfix fullt ut cbpolicyd, ett avancerat verktyg för att säkerställa e-postserverns cybersäkerhet. Förutom anti-spam-skydd och skapandet av vitlistor, svartlistor och grålistor tillåter cbpolicyd Zimbra-administratören att konfigurera SPF-signaturverifiering, samt ställa in begränsningar för att ta emot och skicka e-postmeddelanden eller data. De kan både ge tillförlitligt skydd mot spam och nätfiske-e-post, och skydda servern från e-postbombning.
Det första som krävs av systemadministratören är att aktivera modulen cbpolicyd, som är förinstallerad i Zimbra Collaboration Suite OSE på infrastrukturens MTA-server. Detta görs med kommandot zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Efter detta måste du aktivera webbgränssnittet för att bekvämt kunna hantera cbpolicyd. För att göra detta måste du tillåta anslutningar på webbportnummer 7780, skapa en symbolisk länk med kommandot ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, och redigera sedan inställningsfilen med nano-kommandot /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, där du måste skriva följande rader:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Efter detta återstår bara att starta om Zimbra- och Zimbra Apache-tjänsterna med hjälp av kommandona zmcontrol omstart och zmapachectl omstart. Efter detta har du tillgång till webbgränssnittet på :7780/webui/index.php. Huvudnyansen är att ingången till detta webbgränssnitt ännu inte är skyddad på något sätt och för att förhindra obehöriga från att komma in i det kan du helt enkelt stänga anslutningar på port 7780 efter varje ingång till webbgränssnittet.
Du kan skydda dig från floden av e-postmeddelanden som kommer från det interna nätverket genom att använda kvoter för att skicka e-postmeddelanden, som kan ställas in tack vare cbpolicyd. Sådana kvoter låter dig sätta en gräns för det maximala antalet brev som kan skickas från en brevlåda under en tidsenhet. Till exempel, om dina företagschefer skickar i genomsnitt 60-80 e-postmeddelanden per timme, då kan du sätta en kvot på 100 e-postmeddelanden per timme, med hänsyn till en liten marginal. För att nå denna kvot måste chefer skicka ett e-postmeddelande var 36:e sekund. Å ena sidan räcker detta för att fungera fullt ut, och å andra sidan, med en sådan kvot, kommer angripare som har fått tillgång till e-post från en av dina chefer inte att starta e-postbombningar eller en massiv skräppostattack mot företaget.
För att sätta en sådan kvot måste du skapa en ny begränsningspolicy för e-postsändning i webbgränssnittet och ange att den gäller både för brev som skickas inom domänen och för brev som skickas till externa adresser. Detta görs på följande sätt:
Efter detta kan du specificera mer i detalj begränsningarna för att skicka brev, i synnerhet ställa in tidsintervallet efter vilket begränsningarna kommer att uppdateras, samt meddelandet som en användare som har överskridit sin gräns kommer att få. Efter detta kan du ställa in begränsningen för att skicka brev. Det kan ställas in både som antalet utgående bokstäver och som antalet byte av överförd information. Samtidigt måste brev som skickas utöver den angivna gränsen hanteras annorlunda. Så, till exempel, kan du helt enkelt ta bort dem omedelbart, eller så kan du spara dem så att de skickas direkt efter att gränsen för meddelandesändning har uppdaterats. Det andra alternativet kan användas när man bestämmer det optimala värdet för gränsen för att skicka e-postmeddelanden från anställda.
Förutom begränsningar för att skicka brev, låter cbpolicyd dig sätta en gräns för att ta emot brev. En sådan begränsning är vid första anblicken en utmärkt lösning för att skydda mot postbombning, men att sätta en sådan gräns, även en stor, är i själva verket fylld av det faktum att under vissa förhållanden kanske ett viktigt brev inte når dig. Det är därför det starkt inte rekommenderas att aktivera några begränsningar för inkommande post. Men om du ändå bestämmer dig för att ta risken måste du närma dig att sätta gränsen för inkommande meddelanden med särskild uppmärksamhet. Du kan till exempel begränsa antalet inkommande e-postmeddelanden från betrodda motparter så att om deras e-postserver äventyras kommer den inte att starta en skräppostattack mot ditt företag.
För att skydda mot inflödet av inkommande meddelanden under e-postbombning bör systemadministratören göra något smartare än att bara begränsa inkommande e-post. Denna lösning kan vara användningen av grålistor. Principen för deras funktion är att vid det första försöket att leverera ett meddelande från en opålitlig avsändare, avbryts anslutningen till servern abrupt, varför leveransen av brevet misslyckas. Men om en opålitlig server vid en viss period försöker skicka samma brev igen, stänger inte servern anslutningen och leveransen lyckas.
Poängen med alla dessa åtgärder är att program för att automatiskt skicka massmail vanligtvis inte kontrollerar framgången för leveransen av det skickade meddelandet och inte försöker skicka det en andra gång, medan en person säkerligen kommer att se till om hans brev skickades till adressen eller inte.
Du kan också aktivera grålistning i webbgränssnittet cbpolicyd. För att allt ska fungera måste du skapa en policy som inkluderar alla inkommande brev adresserade till användare på vår server, och sedan, baserat på denna policy, skapa en Greylisting-regel, där du kan konfigurera intervallet under vilket cbpolicyd väntar för ett upprepat svar från en okänd avsändare. Vanligtvis är det 4-5 minuter. Samtidigt kan grålistor konfigureras så att alla lyckade och misslyckade försök att leverera brev från olika avsändare beaktas och utifrån deras antal tas ett beslut om att automatiskt lägga till avsändaren på den vita eller svarta listan.
Vi uppmärksammar dig på att användningen av grålistor bör ske med största ansvar. Det skulle vara bäst om användningen av denna teknik går hand i hand med det ständiga underhållet av vita och svarta listor för att eliminera möjligheten att förlora e-postmeddelanden som verkligen är viktiga för företaget.
Att lägga till SPF-, DMARC- och DKIM-kontroller kan dessutom hjälpa till att skydda mot e-postbombning. Ofta klarar inte brev som kommer genom postbombningen sådana kontroller. Hur man gör detta diskuterades .
Därför är det ganska enkelt att skydda dig från ett sådant hot som e-postbombning, och du kan göra detta till och med när du bygger Zimbra-infrastrukturen för ditt företag. Det är dock viktigt att hela tiden se till att riskerna med att använda ett sådant skydd aldrig överstiger de förmåner du får.
Källa: will.com