Mail bombing er en af de ældste former for cyberangreb. I sin kerne minder det om et almindeligt DoS-angreb, men i stedet for en bølge af anmodninger fra forskellige IP-adresser sendes der en strøm af e-mails til en enkelt e-mailadresse, hvilket resulterer i en betydelig stigning i belastningen på denne. Et sådant angreb kan føre til, at det bliver umuligt at bruge postkassen, og nogle gange kan det endda føre til nedbrud af hele serveren. Den mangeårige historie med denne type cyberangreb har givet anledning til en række positive og negative konsekvenser for systemadministratorer. De positive faktorer inkluderer en god forståelse af mail bombing og tilgængeligheden af enkle måder at beskytte sig mod sådanne angreb. På den negative side er der et stort antal offentligt tilgængelige softwareløsninger til udførelse af denne type angreb og muligheden for, at angriberen kan beskytte sig effektivt mod opdagelse.
En væsentlig egenskab ved denne type cyberangreb er, at det næsten ikke er muligt at udnytte det til økonomisk gevinst. Hvis en angriber sender en strøm af e-mails til en af e-mailkasserne, forhindrer det bare personen i at bruge sin e-mail korrekt; det kan være, at angriberen har hacket en eller andens virksomheds-e-mail og begyndt massivt at sende tusindvis af e-mails ud til hele GAL, hvilket får serveren til enten at crashe eller begynde at køre så langsomt, at det bliver umuligt at bruge den. Og hvad så? At konvertere en sådan cyberkriminalitet til rigtige penge er næsten umuligt, så mail bombing er i øjeblikket et ret sjældent fænomen, og systemadministratorer kan simpelthen glemme behovet for at beskytte sig mod denne type cyberangreb, når de designer infrastrukturen.
Selvom mailbombning i sig selv er en temmelig meningsløs aktivitet fra et kommercielt synspunkt, er det ofte en del af andre, mere komplekse og flerskiftede cyberangreb. For eksempel, når en e-mail bliver hacket og bruges til at overtage en konto på en offentlig tjeneste, sender angriberne ofte meningsløse e-mails til ofrets postkasse for at sikre, at bekræftelsesbrevet bliver begravet i deres strøm og forbliver ubemærket. Mailbombning kan også bruges som et middel til økonomisk pres på en virksomhed. En aktiv bombardement af virksomhedens offentlige postkasse, som modtager kundeanmodninger, kan alvorligt vanskeliggøre arbejdet med dem og kan som følge heraf føre til driftsstop, uafsluttede ordrer samt tab af omdømme og tabt indtægt.
Det er netop derfor, at systemadministratoren ikke bør glemme sandsynligheden for mailbombning og altid tage nødvendige skridt for at beskytte sig mod denne trussel. Hvis man overvejer, at dette kan gøres allerede på byggefasen af e-mailinfrastrukturen, og at det kræver meget lidt tid og arbejde fra systemadministratorens side, er der simpelthen ikke nogen objektive grunde til ikke at sikre sin infrastruktur imod mailbombning. Lad os se på, hvordan beskyttelsen mod denne cyberangreb er implementeret i Zimbra Collaboration Suite Open-Source Edition.
Zimbra er baseret på Postfix — en af de mest pålidelige og funktionelle Mail Transfer Agents med open source, der findes i øjeblikket. En af de vigtigste fordele ved dens åbenhed er, at den understøtter de mest forskellige tredjepartsløsninger for at udvide funktionaliteten. Især understøtter Postfix fuldt ud cbpolicyd — et avanceret værktøj til at sikre cybersikkerhed for mailserveren. Udover beskyttelse mod spam og oprettelse af hvid-, sort- og grålister, giver cbpolicyd Zimbra-administratoren mulighed for at konfigurere SPF-certifikatskontrol samt indstille grænser for modtagelse og afsendelse af e-mails eller data. De kan både sikre pålidelig beskyttelse mod spam og phishing-e-mails samt beskytte serveren mod mailbombning.
Det første, som systemadministratoren skal gøre, er at aktivere cbpolicyd-modulet, der er forudinstalleret i Zimbra Collaboration Suite OSE på MTA-serveren i infrastrukturen. Dette gøres med kommandoen zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Derefter skal webgrænsefladen aktiveres for at kunnen administrere cbpolicyd komfortabelt. For at gøre dette skal forbindelser på webport nummer 7780 tillades, og der skal oprettes et symbolsk link med kommandoen ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, og derefter redigeres konfigurationsfilen med kommandoen nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, hvor følgende linjer skal tilføjes:
$DB_DSN='sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb';
$DB_USER='root';
$DB_TABLE_PREFIX='';
Efter dette skal Zimbra- og Zimbra Apache-tjenesterne genstartes med kommandoerne zmcontrol restart og zmapachectl restart. Herefter får du adgang til webgrænsefladen på adressen :7780/webui/index.php. Den væsentlige detalje er, at adgangen til denne webgrænseflade i øjeblikket ikke er beskyttet, og for at forhindre uautoriseret adgang kan forbindelser på port 7780 simpelthen lukkes efter hver indlogging i webgrænsefladen.
At beskytte mod strømmen af e-mails, der kommer fra det interne netværk, muliggør kvoter for sending af e-mails, som kan indstilles ved hjælp af cbpolicyd. Disse kvoter tillader at sætte en grænse for det maksimale antal e-mails, der kan sendes fra én postkasse på et givet tidspunkt. For eksempel, hvis medarbejderne i din virksomhed i gennemsnit sender 60-80 e-mails i timen, så kan man, med lidt margen, sætte dem på en kvote på 100 e-mails om timen. For at udnytte en sådan kvote ville medarbejderne skulle sende én e-mail hvert 36. sekund. På den ene side er dette tilstrækkeligt til at arbejde optimalt, men på den anden side, med en sådan kvote, kan en angriber, der har fået adgang til en af dine medarbejderes e-mail, ikke udføre mailbombing eller en masse spamangreb på virksomheden.
For at indstille en sådan kvote, skal man i webgrænsefladen oprette en ny politik for begrænsning af e-mail sending og angive, at den skal gælde både for e-mails sendt inden for domænet samt for e-mails til eksterne adresser. Dette gøres på følgende måde:
Efter dette vil det være muligt at angive begrænsninger i forbindelse med afsendelse af e-mails mere detaljeret, herunder at fastsætte et tidsinterval, hvorefter begrænsningerne opdateres, samt den besked, som brugeren vil modtage, hvis de overskrider deres grænse. Derefter kan selve begrænsningen for afsendelse af e-mails fastsættes. Denne kan angives som et antal udgående e-mails eller som et antal byte sendt information. E-mails, der overskrider den angivne grænse, kan dog behandles forskelligt. For eksempel kan de straks slettes, eller de kan gemmes, så de kan sendes, så snart grænsen for afsendelse af meddelelser er opdateret. Det er muligt at benytte den anden mulighed, når man finder den optimale værdi for grænsen for sending af e-mails fra medarbejdere.
Ud over begrænsningerne for afsendelse af e-mails, giver cbpolicyd mulighed for at indstille en grænse for modtagelse af e-mails. En sådan begrænsning synes ved første øjekast at være en fremragende løsning til beskyttelse mod mailbombning, men i praksis kan indstillingen af en sådan grænse, selvom den er stor, medføre, at vigtige e-mails ikke når frem til dig under visse omstændigheder. Derfor frarådes det kraftigt at indføre nogen som helst begrænsninger for indgående post. Men hvis du alligevel har besluttet at tage chancen, skal du være meget omhyggelig med at indstille grænsen for indgående meddelelser. For eksempel kan man begrænse antallet af indgående e-mails fra betroede forretningspartnere, så hvis deres mailserver bliver kompromitteret, ikke udføres der spam-angreb mod din virksomhed.
For at beskytte sig mod en bølge af indgående meddelelser under mailbombning, skal systemadministratoren tage nogle mere intelligente skridt end blot at begrænse indgående post. En sådan løsning kan være brugen af grå lister. Principperne bag deres funktion er, at når der første gang forsøges at levere en meddelelse fra en upålidelig afsender, afbrydes forbindelsen til serveren brat, hvilket resulterer i, at leveringen af e-mailen mislykkes. Men hvis den upålidelige server forsøger at sende den samme e-mail igen efter et bestemt tidsrum, afbryder serveren ikke forbindelsen, og leveringen lykkes.
Meningen med alle disse handlinger er, at programmer til automatisk masseudsendelse af e-mails normalt ikke tjekker, om den sendte besked er blevet leveret, og gør ikke noget forsøg på at sende den igen, mens en person helt sikkert vil bekræfte, om deres e-mail er blevet sendt til den rigtige adresse eller ej.
Grålister kan også aktiveres i webgrænsefladen cbpolicyd. For at alt skal fungere korrekt, er det nødvendigt at oprette en politik, der omfatter alle indgående e-mails adresseret til brugere på vores server, og derefter oprette en Greylisting-regel baseret på denne politik, hvor intervallet for, hvor længe cbpolicyd forventer et svar fra en ukendt afsender, kan indstilles. Dette interval er normalt 4-5 minutter. Desuden kan grålister konfigureres, så alle succesfulde og mislykkedes forsøg på at levere e-mails fra forskellige afsendere tages i betragtning, og på baggrund af deres antal træffes der beslutning om automatisk at tilføje afsenderen til hvid- eller sortlisten.
Vi påpeger, at brugen af grålister skal tages med største ansvarlighed. Det er bedst, hvis brugen af denne teknologi går hånd i hånd med konstant vedligeholdelse af hvid- og sortlister for at udelukke risikoen for at miste virkelig vigtige e-mails for virksomheden.
Derudover kan beskyttelse mod mailbombing hjælpes af tilføjelsen af SPF-, DMARC- og DKIM-kontroller. Ofte passerer e-mails, der modtages under mailbombing, ikke disse kontroller. Dette er blevet beskrevet hvilke metoder der kan anvendes. .
Dermed er det ret enkelt at beskytte sig mod en trussel som mailbombing, og dette kan også gøres allerede i opbygningen af Zimbra-infrastrukturen for din virksomhed. Det er dog vigtigt løbende at overvåge, at risiciene ved at anvende sådan beskyttelse aldrig overstiger de fordele, du opnår.
Kilde: habr.com
