Mailbombning er en af de ældste typer cyberangreb. I sin kerne ligner det et almindeligt DoS-angreb, men i stedet for en bølge af anmodninger fra forskellige IP-adresser sendes en bølge af e-mails til serveren, som ankommer i enorme mængder til en af e-mailadresserne, hvorved belastningen på det stiger markant. Et sådant angreb kan føre til manglende evne til at bruge postkassen og nogle gange endda føre til fejl på hele serveren. Den lange historie med denne type cyberangreb har ført til en række positive og negative konsekvenser for systemadministratorer. Positive faktorer inkluderer det gode kendskab til postbombning og tilgængeligheden af enkle måder at beskytte dig selv mod et sådant angreb. De negative faktorer omfatter et stort antal offentligt tilgængelige softwareløsninger til at udføre sådanne typer angreb og muligheden for en angriber til pålideligt at beskytte sig mod opdagelse.
Et vigtigt træk ved dette cyberangreb er, at det næsten er umuligt at bruge det til profit. Nå, angriberen sendte en bølge af e-mails til en af postkasserne, ja, han lod ikke personen bruge e-mail normalt, ja, angriberen hackede sig ind i en andens firmamail og begyndte at masseudsende tusindvis af breve i hele GAL, pga. som serveren enten gik ned eller begyndte at bremse, så det blev umuligt at bruge den, og hvad så? Det er næsten umuligt at konvertere sådan cyberkriminalitet til rigtige penge, så mailbombning er nu ret sjældent, og systemadministratorer husker måske simpelthen ikke behovet for at beskytte mod et sådant cyberangreb, når de designer infrastruktur.
Men på trods af at mailbombning i sig selv er en ret meningsløs aktivitet fra et kommercielt synspunkt, er det ofte en integreret del af andre, mere komplekse og flertrins cyberangreb. For eksempel, når man hacker mail og bruger den til at kapre en konto i en offentlig tjeneste, "bomber" angribere ofte ofrets postkasse med meningsløse breve, så bekræftelsesbrevet går tabt i deres stream og forbliver ubemærket. Postbombning kan også bruges som et middel til økonomisk pres på en virksomhed. For eksempel kan et aktivt bombardement af en virksomheds offentlige postkasse, som modtager ansøgninger fra kunder, alvorligt hindre arbejdet med dem og kan som følge heraf føre til nedetid på udstyr, uopfyldte ordrer samt tab af omdømme og tabt fortjeneste.
Derfor bør systemadministratoren ikke glemme muligheden for postbombning og altid tage de nødvendige foranstaltninger for at beskytte mod denne trussel. I betragtning af at dette kan gøres selv på stadiet af opbygningen af mail-infrastrukturen, og også at det tager meget lidt tid og kræfter fra systemadministratoren, er der simpelthen ingen objektive grunde til ikke at give din infrastruktur beskyttelse mod mailbombning. . Lad os tage et kig på, hvordan beskyttelse mod dette cyberangreb er implementeret i Zimbra Collaboration Suite Open-Source Edition.
Zimbra er baseret på Postfix, en af de mest pålidelige og funktionelle open source Mail Transfer Agents i øjeblikket. Og en af hovedfordelene ved dens åbenhed er, at den understøtter en lang række tredjepartsløsninger for at udvide funktionaliteten. Postfix understøtter især cbpolicyd, et avanceret cybersikkerhedsværktøj til mailserver. Ud over spambeskyttelse og hvidlistning, sortlistning og grålisting giver cbpolicyd Zimbra-administratoren mulighed for at opsætte SPF-signaturbekræftelse samt sætte grænser for modtagelse og afsendelse af e-mails eller data. De kan både give pålidelig beskyttelse mod spam og phishing-e-mails, samt beskytte serveren mod e-mailbombning.
Det første, der kræves af systemadministratoren, er aktiveringen af cbpolicyd-modulet, som er forudinstalleret i Zimbra Collaboration Suite OSE på infrastrukturens MTA-server. Dette gøres ved at bruge zmprov ms `zmhostname` + zimbraServiceEnabled kommandoen cbpolicyd. Derefter skal du aktivere webgrænsefladen for komfortabelt at kunne administrere cbpolicyd. For at gøre dette skal du tillade forbindelser på webport nummer 7780, oprette et symbolsk link ved hjælp af kommandoen ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, og rediger derefter indstillingsfilen med nano-kommandoen /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, hvor du skal skrive følgende linjer:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Derefter er det kun tilbage at genstarte Zimbra- og Zimbra Apache-tjenesterne ved hjælp af kommandoerne zmcontrol genstart og zmapachectl genstart. Herefter har du adgang til webgrænsefladen kl :7780/webui/index.php. Hovednuancen er, at indgangen til denne webgrænseflade endnu ikke er beskyttet på nogen måde, og for at forhindre uvedkommende i at komme ind i den, kan du blot lukke forbindelser på port 7780 efter hver adgang til webgrænsefladen.
For at beskytte mod oversvømmelsen af e-mails, der kommer fra det interne netværk, kan du bruge kvoter til afsendelse af e-mails, som kan indstilles takket være cbpolicyd. Sådanne kvoter giver dig mulighed for at sætte en grænse for det maksimale antal breve, der kan sendes fra én postkasse på én tidsenhed. For eksempel, hvis ledere i din virksomhed sender et gennemsnit på 60-80 e-mails i timen, kan du sætte en kvote på 100 e-mails i timen med en lille frihøjde. For at opbruge denne kvote skal ledere sende et brev hvert 36. sekund. På den ene side er dette nok til at fungere fuldt ud, og på den anden side, med en sådan kvote, vil angribere, der har fået adgang til en af dine lederes post, ikke arrangere en mailbombning eller et massivt spam-angreb på virksomheden .
For at sætte en sådan kvote skal du oprette en ny begrænsningspolitik for afsendelse af e-mails i webgrænsefladen og angive, at den gælder for både e-mails sendt inden for domænet og e-mails sendt til eksterne adresser. Dette gøres som følger:
Herefter vil det være muligt mere detaljeret at specificere restriktionerne i forbindelse med afsendelse af breve, især indstille tidsintervallet, hvorefter restriktionerne opdateres, samt beskeden, som den bruger, der har overskredet sin grænse, vil modtage. Derefter kan du indstille selve begrænsningen for at sende breve. Det kan indstilles både som antallet af udgående beskeder og som antallet af bytes af transmitteret information. Samtidig handler det anderledes med breve, der sendes ud over den angivne grænse. Så du kan for eksempel blot slette dem med det samme, eller du kan gemme dem, så de går umiddelbart efter, at grænsen for afsendelse af beskeder er opdateret. Den anden mulighed kan bruges til at bestemme den optimale værdi for grænsen for afsendelse af e-mails til medarbejdere.
Ud over at sende e-mail-grænser giver cbpolicyd dig mulighed for at sætte en grænse for modtagelse af e-mails. En sådan grænse er ved første øjekast en glimrende løsning til at beskytte mod postbombning, men faktisk er det at sætte en sådan grænse, selvom den er stor, behæftet med det faktum, at et vigtigt brev under visse forhold muligvis ikke når dig . Det er grunden til, at det stærkt frarådes at aktivere eventuelle begrænsninger for indgående post. Men hvis du alligevel beslutter dig for at tage en chance, skal du nærme dig indstillingen af grænsen for indgående beskeder med særlig opmærksomhed. Du kan f.eks. begrænse antallet af indkommende e-mails fra betroede modparter, så hvis deres mailserver er kompromitteret, vil den ikke spamme din virksomhed.
For at beskytte mod strømmen af indgående meddelelser fra mailbombning bør systemadministratoren gøre noget mere smart end blot at begrænse indgående mail. En sådan løsning kunne være brugen af grå lister. Princippet for deres drift er, at ved det første forsøg på at levere en besked fra en upålidelig afsender, bliver forbindelsen til serveren brat afbrudt, på grund af hvilken beskedleveringen mislykkes. Men hvis en server, der ikke er tillid til, forsøger at sende den samme e-mail igen inden for en vis periode, afbryder serveren ikke forbindelsen, og leveringen lykkes.
Pointen med alle disse handlinger er, at automatiske bulk-e-mail-programmer normalt ikke kontrollerer succesen af den sendte besked og ikke forsøger at sende den en anden gang, mens personen helt sikkert vil sikre sig, om hans brev blev sendt til adressen eller ej. .
Du kan også aktivere grålister i cbpolicyd-webgrænsefladen. For at alt kan fungere, skal du oprette en politik, der vil inkludere alle indgående breve adresseret til brugere på vores server, og derefter, baseret på denne politik, oprette en grålisteregel, hvor du kan konfigurere det interval, hvor cbpolicyd vil vente for et andet svar fra en ukendt afsender. Normalt er det 4-5 minutter. Samtidig kan grå lister konfigureres, så der tages højde for alle vellykkede og mislykkede forsøg på at levere breve fra forskellige afsendere, og på baggrund af deres antal besluttes der automatisk at tilføje afsenderen til den hvide eller sorte liste.
Vi gør opmærksom på, at brugen af grå lister bør gribes an med største ansvar. Det ville være bedst, hvis brugen af denne teknologi går hånd i hånd med den konstante vedligeholdelse af hvide og sorte lister for at udelukke muligheden for at miste bogstaver, der er virkelig vigtige for virksomheden.
Derudover kan tilføjelse af SPF-, DMARC- og DKIM-tjek hjælpe med at beskytte mod e-mailbombning. Ofte passerer breve, der kommer i færd med postbombning, ikke sådan kontrol. Hvordan man gør dette blev forklaret .
Det er således ret simpelt at beskytte dig selv mod en sådan trussel som postbombning, og du kan gøre dette selv på tidspunktet for opbygningen af Zimbra-infrastrukturen til din virksomhed. Det er dog vigtigt hele tiden at sikre, at risiciene ved at bruge en sådan beskyttelse aldrig opvejer de fordele, du modtager.
Kilde: www.habr.com