Postbombing er en av de eldste typene cyberangrep. I kjernen ligner det et vanlig DoS-angrep, bare i stedet for en bølge av forespørsler fra forskjellige IP-adresser, sendes en bølge av e-poster til serveren, som kommer i enorme mengder til en av e-postadressene, på grunn av hvilken belastningen på den øker betydelig. Et slikt angrep kan føre til manglende evne til å bruke postkassen, og noen ganger kan det til og med føre til feil på hele serveren. Den lange historien til denne typen nettangrep har ført til en rekke positive og negative konsekvenser for systemadministratorer. Positive faktorer inkluderer god kunnskap om postbombing og tilgjengeligheten av enkle måter å beskytte deg mot et slikt angrep. Negative faktorer inkluderer et stort antall offentlig tilgjengelige programvareløsninger for å utføre denne typen angrep og muligheten for en angriper til pålitelig å beskytte seg mot oppdagelse.
Et viktig trekk ved dette cyberangrepet er at det er nesten umulig å bruke det for profitt. Vel, angriperen sendte en bølge av e-poster til en av postkassene, vel, han tillot ikke personen å bruke e-post normalt, vel, angriperen hacket seg inn i noens bedrifts-e-post og begynte å massesende tusenvis av brev gjennom hele GAL, som er hvorfor serveren enten krasjet eller begynte å bremse opp slik at det ble umulig å bruke den, og hva videre? Det er nesten umulig å konvertere en slik nettkriminalitet til ekte penger, så ganske enkelt postbombing er for tiden en ganske sjelden forekomst, og systemadministratorer, når de designer infrastruktur, husker kanskje rett og slett ikke behovet for å beskytte mot et slikt nettangrep.
Men selv om e-postbombing i seg selv er en ganske meningsløs øvelse fra et kommersielt synspunkt, er det ofte en del av andre, mer komplekse og flertrinns cyberangrep. For eksempel, når man hacker post og bruker den til å kapre en konto i en offentlig tjeneste, "bomber" angripere ofte offerets postkasse med meningsløse brev slik at bekreftelsesbrevet blir borte i strømmen deres og går ubemerket hen. Postbombing kan også brukes som et middel for økonomisk press på en bedrift. Aktiv bombardement av en bedrifts offentlige postboks, som mottar forespørsler fra kunder, kan derfor komplisere arbeidet med dem alvorlig, og som et resultat kan det føre til nedetid av utstyr, uoppfylte bestillinger, samt tap av omdømme og tapt fortjeneste.
Det er grunnen til at systemadministratoren ikke bør glemme sannsynligheten for e-postbombing og alltid ta de nødvendige tiltakene for å beskytte mot denne trusselen. Tatt i betraktning at dette kan gjøres på stadiet av å bygge e-postinfrastrukturen, og også at det tar svært lite tid og arbeid fra systemadministratoren, er det rett og slett ingen objektive grunner for ikke å gi infrastrukturen din beskyttelse mot e-postbombing. La oss ta en titt på hvordan beskyttelse mot dette cyberangrepet er implementert i Zimbra Collaboration Suite Open-Source Edition.
Zimbra er basert på Postfix, en av de mest pålitelige og funksjonelle postoverføringsagentene med åpen kildekode som er tilgjengelig i dag. Og en av hovedfordelene med åpenheten er at den støtter et bredt utvalg av tredjepartsløsninger for å utvide funksjonaliteten. Spesielt støtter Postfix fullt ut cbpolicyd, et avansert verktøy for å sikre e-postserver cybersikkerhet. I tillegg til anti-spam-beskyttelse og opprettelse av hvitelister, svartelister og grålister, lar cbpolicyd Zimbra-administratoren konfigurere SPF-signaturverifisering, samt sette begrensninger for mottak og sending av e-post eller data. De kan både gi pålitelig beskyttelse mot spam og phishing-e-post, og beskytte serveren mot e-postbombing.
Det første som kreves fra systemadministratoren er å aktivere cbpolicyd-modulen, som er forhåndsinstallert i Zimbra Collaboration Suite OSE på infrastruktur-MTA-serveren. Dette gjøres ved å bruke kommandoen zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Etter dette må du aktivere nettgrensesnittet for å kunne administrere cbpolicyd komfortabelt. For å gjøre dette må du tillate tilkoblinger på nettportnummer 7780, opprette en symbolsk lenke ved å bruke kommandoen ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, og rediger deretter innstillingsfilen ved å bruke nano-kommandoen /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, hvor du må skrive følgende linjer:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Etter dette gjenstår det bare å starte Zimbra- og Zimbra Apache-tjenestene på nytt ved å bruke kommandoene zmcontrol restart og zmapachectl restart. Etter dette vil du ha tilgang til webgrensesnittet på :7780/webui/index.php. Hovednyansen er at inngangen til dette webgrensesnittet ennå ikke er beskyttet på noen måte, og for å forhindre at uvedkommende kommer inn i det, kan du ganske enkelt lukke tilkoblinger på port 7780 etter hver inngang til webgrensesnittet.
Du kan beskytte deg mot flommen av e-poster som kommer fra det interne nettverket ved å bruke kvoter for å sende e-poster, som kan settes takket være cbpolicyd. Slike kvoter lar deg sette en grense for maksimalt antall brev som kan sendes fra én postkasse i løpet av en tidsenhet. For eksempel, hvis bedriftslederne dine sender et gjennomsnitt på 60-80 e-poster i timen, kan du sette en kvote på 100 e-poster i timen, tatt i betraktning en liten margin. For å nå denne kvoten, må ledere sende én e-post hvert 36. sekund. På den ene siden er dette nok til å fungere fullt ut, og på den andre siden, med en slik kvote, vil ikke angripere som har fått tilgang til e-posten til en av dine ledere starte e-postbombing eller et massivt spam-angrep på bedriften.
For å sette en slik kvote, må du opprette en ny e-postbegrensningspolicy i nettgrensesnittet og spesifisere at den gjelder både for brev sendt innenfor domenet og for brev sendt til eksterne adresser. Dette gjøres som følger:
Etter dette kan du spesifisere mer detaljert begrensningene knyttet til sending av brev, spesielt angi tidsintervallet som restriksjonene skal oppdateres etter, samt meldingen som en bruker som har overskredet grensen vil motta. Etter dette kan du sette begrensningen på å sende brev. Det kan settes både som antall utgående bokstaver og som antall byte med overført informasjon. Samtidig skal brev som sendes utover den angitte grensen behandles annerledes. Så for eksempel kan du ganske enkelt slette dem umiddelbart, eller du kan lagre dem slik at de sendes umiddelbart etter at grensen for sending av meldinger er oppdatert. Det andre alternativet kan brukes når du bestemmer den optimale verdien av grensen for å sende e-post fra ansatte.
I tillegg til restriksjoner på å sende brev, lar cbpolicyd deg sette en grense for mottak av brev. En slik begrensning er ved første øyekast en utmerket løsning for å beskytte mot postbombing, men faktisk å sette en slik grense, selv en stor, er full av det faktum at under visse forhold kan det hende at et viktig brev ikke når deg. Derfor anbefales det sterkt ikke å aktivere noen begrensninger for innkommende post. Men hvis du fortsatt bestemmer deg for å ta risikoen, må du nærme deg å sette grensen for innkommende meldinger med spesiell oppmerksomhet. Du kan for eksempel begrense antallet innkommende e-poster fra pålitelige motparter, slik at hvis e-postserveren deres blir kompromittert, vil den ikke starte et spam-angrep på virksomheten din.
For å beskytte mot innstrømming av innkommende meldinger under postbombing, bør systemadministratoren gjøre noe smartere enn å begrense innkommende post. Denne løsningen kan være bruk av grå lister. Prinsippet for deres operasjon er at ved det første forsøket på å levere en melding fra en upålitelig avsender, blir forbindelsen til serveren brått avbrutt, og det er grunnen til at leveringen av brevet mislykkes. Men hvis en ikke-klarert server i en viss periode prøver å sende det samme brevet igjen, lukker ikke serveren forbindelsen og leveringen lykkes.
Poenget med alle disse handlingene er at programmer for automatisk sending av massee-poster vanligvis ikke sjekker suksessen med leveringen av den sendte meldingen og ikke forsøker å sende den en gang til, mens en person vil sikkert sørge for om brevet hans ble sendt til adressen eller ikke.
Du kan også aktivere grålisting i cbpolicyd-nettgrensesnittet. For at alt skal fungere, må du lage en policy som vil inkludere alle innkommende brev adressert til brukere på serveren vår, og deretter, basert på denne policyen, lage en Gråliste-regel, der du kan konfigurere intervallet som cbpolicyd vil vente i. for et gjentatt svar fra en ukjent avsender. Vanligvis er det 4-5 minutter. Samtidig kan grå lister konfigureres slik at alle vellykkede og mislykkede forsøk på å levere brev fra forskjellige avsendere blir tatt i betraktning, og basert på antallet deres tas det en beslutning om å automatisk legge avsenderen til hvit- eller svartelisten.
Vi gjør oppmerksom på at bruk av grå lister bør gjøres med største ansvar. Det ville være best om bruken av denne teknologien går hånd i hånd med konstant vedlikehold av hvite og svarte lister for å eliminere muligheten for å miste e-poster som er virkelig viktige for bedriften.
I tillegg kan det å legge til SPF-, DMARC- og DKIM-sjekker bidra til å beskytte mot e-postbombing. Ofte passerer ikke brev som kommer gjennom prosessen med postbombing, slike kontroller. Hvordan dette gjøres ble diskutert .
Dermed er det ganske enkelt å beskytte deg mot en trussel som e-postbombing, og du kan gjøre dette selv på stadiet av å bygge Zimbra-infrastrukturen for bedriften din. Det er imidlertid viktig å hele tiden sørge for at risikoen ved å bruke slik beskyttelse aldri overstiger fordelene du mottar.
Kilde: www.habr.com