Poŝtbombado estas unu el la plej malnovaj specoj de ciberatakoj. En ĝia kerno, ĝi similas al regula DoS-atako, nur anstataŭ ondo de petoj de malsamaj IP-adresoj, ondo de retpoŝtoj estas sendita al la servilo, kiuj alvenas en grandegaj kvantoj al unu el la retadresoj, pro kio la ŝarĝo. sur ĝi signife pliiĝas. Tia atako povas konduki al la malkapablo uzi la leterkeston, kaj foje eĉ povas kaŭzi malsukceson de la tuta servilo. La longa historio de ĉi tiu tipo de ciberatako kaŭzis kelkajn pozitivajn kaj negativajn konsekvencojn por administrantoj de la sistemo. Pozitivaj faktoroj inkluzivas bonan scion pri poŝtbombado kaj la haveblecon de simplaj manieroj protekti vin kontraŭ tia atako. Negativaj faktoroj inkluzivas grandan nombron da publike haveblaj softvarsolvoj por efektivigi ĉi tiujn specojn de atakoj kaj la kapablon por atakanto fidinde protekti sin kontraŭ detekto.
Grava trajto de ĉi tiu ciberatako estas, ke estas preskaŭ neeble uzi ĝin por profito. Nu, la atakanto sendis ondon da retpoŝtoj al unu el la leterkestoj, nu, li ne permesis al la persono uzi retpoŝton normale, nu, la atakanto piratis en ies kompanian retpoŝton kaj komencis amase sendi milojn da leteroj tra la GAL, kio estas kial la servilo aŭ kraŝis aŭ komencis malrapidiĝi tiel ke iĝis neeble uzi ĝin, kaj kio poste? Estas preskaŭ neeble konverti tian ciberkrimon en realan monon, do simple poŝta bombado estas nuntempe sufiĉe malofta okazo kaj sistemaj administrantoj, dum desegnado de infrastrukturo, eble simple ne memoras la bezonon protekti kontraŭ tia ciberatako.
Tamen, dum retpoŝta bombado mem estas sufiĉe sencela ekzerco el komerca vidpunkto, ĝi ofte estas parto de aliaj, pli kompleksaj kaj plurfazaj ciberatakoj. Ekzemple, kiam hakas poŝton kaj uzas ĝin por kaperi konton en iu publika servo, atakantoj ofte "bombas" la leterkeston de la viktimo per sensencaj leteroj tiel ke la konfirmletero perdiĝas en sia fluo kaj iras nerimarkita. Poŝtbombado ankaŭ povas esti utiligita kiel rimedo de ekonomia premo sur entrepreno. Tiel, aktiva bombado de publika leterkesto de entrepreno, kiu ricevas petojn de klientoj, povas serioze malfaciligi laboron kun ili kaj, kiel rezulto, povas konduki al ekipaĵo malfunkcio, neplenumitaj mendoj, kaj ankaŭ perdo de reputacio kaj perditaj profitoj.
Tial la administranto de la sistemo ne forgesu pri la verŝajneco de retpoŝta bombado kaj ĉiam prenu la necesajn rimedojn por protekti kontraŭ ĉi tiu minaco. Konsiderante, ke tio povas esti farita en la stadio de konstruado de la poŝta infrastrukturo, kaj ankaŭ ke necesas tre malmulte da tempo kaj laboro de la administranto de la sistemo, simple ne ekzistas objektivaj kialoj por ne provizi vian infrastrukturon kun protekto kontraŭ poŝtbombado. Ni rigardu kiel protekto kontraŭ ĉi tiu ciber-atako estas efektivigita en Zimbra Collaboration Suite Open-Source Edition.
Zimbra baziĝas sur Postfix, unu el la plej fidindaj kaj funkciaj malfermfontaj Agentoj de Poŝttransigo disponeblaj hodiaŭ. Kaj unu el la ĉefaj avantaĝoj de ĝia malfermiteco estas, ke ĝi subtenas ampleksan varion de triaj solvoj por etendi funkciecon. Aparte, Postfix plene subtenas cbpolicyd, altnivelan ilon por certigi retsekurecon de retservilo. Krom kontraŭ-spamo-protekto kaj la kreado de blankaj listoj, nigraj listoj kaj grizaj listoj, cbpolicyd permesas al la administranto de Zimbra agordi SPF-signaturkontrolon, kaj ankaŭ agordi limigojn pri ricevado kaj sendo de retpoŝtoj aŭ datumoj. Ili povas ambaŭ provizi fidindan protekton kontraŭ retpoŝtoj pri spamado kaj phishing, kaj protekti la servilon kontraŭ retpoŝta bombado.
La unua afero, kiu postulas de la sistemadministranto, estas aktivigi la modulon cbpolicyd, kiu estas antaŭinstalita en Zimbra Collaboration Suite OSE sur la infrastruktura MTA-servilo. Ĉi tio estas farita per la komando zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Post ĉi tio, vi devos aktivigi la retan interfacon por povi komforte administri cbpolicyd. Por fari tion, vi devas permesi konektojn sur la rethaveno numero 7780, krei simbolan ligon per la komando ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, kaj poste redaktu la agordan dosieron per la nano-komando /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, kie vi devas skribi la sekvajn liniojn:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="radiko";
$DB_TABLE_PREFIX="";
Post ĉi tio, restas nur rekomenci la Zimbra kaj Zimbra Apache-servojn uzante la komandojn zmcontrol restart kaj zmapachectl restart. Post ĉi tio, vi havos aliron al la retinterfaco ĉe :7780/webui/index.php. La ĉefa nuanco estas, ke la enirejo al ĉi tiu retinterfaco ankoraŭ ne estas protektita neniel kaj por malhelpi neaŭtorizitajn personojn eniri ĝin, vi povas simple fermi konektojn sur haveno 7780 post ĉiu eniro al la retinterfaco.
Vi povas protekti vin kontraŭ la inundo de retpoŝtoj venantaj de la interna reto uzante kvotojn por sendado de retpoŝtoj, kiujn oni povas agordi danke al cbpolicyd. Tiaj kvotoj permesas al vi agordi limon al la maksimuma nombro da leteroj, kiuj povas esti senditaj de unu leterkesto en unu tempounuo. Ekzemple, se viaj komercaj administrantoj sendas averaĝe 60-80 retpoŝtojn hore, tiam vi povas agordi kvoton de 100 retpoŝtoj hore, konsiderante malgrandan marĝenon. Por atingi ĉi tiun kvoton, administrantoj devos sendi unu retpoŝton ĉiujn 36 sekundojn. Unuflanke, ĉi tio sufiĉas por plene funkcii, kaj aliflanke, kun tia kvoto, atakantoj, kiuj akiris aliron al la poŝto de unu el viaj administrantoj, ne lanĉos poŝtobombadon aŭ amasan spaman atakon kontraŭ la entrepreno.
Por agordi tian kvoton, vi devas krei novan retpoŝtan sendan limigan politikon en la retinterfaco kaj specifi, ke ĝi validas kaj por leteroj senditaj ene de la domajno kaj por leteroj senditaj al eksteraj adresoj. Ĉi tio estas farita jene:
Post ĉi tio, vi povas specifi pli detale la limigojn asociitajn kun sendado de leteroj, precipe, agordi la tempon, post kiu la limigoj estos ĝisdatigitaj, kaj ankaŭ la mesaĝon, kiun ricevos uzanto, kiu superis sian limon. Post ĉi tio, vi povas agordi la limigon pri sendado de leteroj. Ĝi povas esti agordita kaj kiel la nombro da elirantaj leteroj kaj kiel la nombro da bajtoj de transdonitaj informoj. Samtempe, leteroj kiuj estas senditaj pli ol la indikita limo devas esti traktitaj alimaniere. Do, ekzemple, vi povas simple forigi ilin tuj, aŭ vi povas konservi ilin por ke ili estu senditaj tuj post kiam la limo de sendado de mesaĝo estas ĝisdatigita. La dua opcio povas esti uzata kiam oni determinas la optimuman valoron de la limo por sendi retpoŝtojn de dungitoj.
Krom limigoj pri sendado de leteroj, cbpolicyd permesas vin agordi limon pri ricevado de leteroj. Tia limigo, unuavide, estas bonega solvo por protekti kontraŭ poŝtbombado, sed fakte, fiksi tian limon, eĉ grandan, estas plena de tio, ke en certaj kondiĉoj grava letero eble ne atingas vin. Tial estas tre ne rekomendite ebligi iujn ajn restriktojn por envenanta poŝto. Tamen, se vi ankoraŭ decidas riski, vi devas alproksimiĝi al fikso de la envenanta mesaĝlimo kun speciala atento. Ekzemple, vi povas limigi la nombron da envenantaj retpoŝtoj de fidindaj kontraŭpartioj tiel ke se ilia poŝtservilo estas endanĝerigita, ĝi ne lanĉos spaman atakon kontraŭ via komerco.
Por protekti kontraŭ la enfluo de envenantaj mesaĝoj dum poŝtbombado, la sistemadministranto devus fari ion pli lertan ol simple limigi envenantan poŝton. Ĉi tiu solvo povus esti la uzo de grizaj listoj. La principo de ilia funkciado estas, ke ĉe la unua provo transdoni mesaĝon de nefidinda sendinto, la konekto al la servilo estas subite interrompita, tial la livero de la letero malsukcesas. Tamen, se en certa periodo nefidinda servilo provas sendi la saman leteron denove, la servilo ne fermas la konekton kaj ĝia livero sukcesas.
La punkto de ĉiuj ĉi tiuj agoj estas, ke programoj por aŭtomate sendi amasajn retmesaĝojn kutime ne kontrolas la sukceson de livero de la sendita mesaĝo kaj ne provas sendi ĝin duan fojon, dum persono certe certigos, ĉu lia letero estis sendita al. la adreson aŭ ne.
Vi ankaŭ povas ebligi grizan liston en la interfaco de cbpolicyd. Por ke ĉio funkciu, vi devas krei politikon, kiu inkludus ĉiujn envenantajn leterojn adresitajn al uzantoj en nia servilo, kaj tiam, surbaze de ĉi tiu politiko, krei regulon de Greylisting, kie vi povas agordi la intervalon dum kiu cbpolicyd atendos por ripeta respondo de nekonata persono sendinto. Kutime ĝi estas 4-5 minutoj. Samtempe oni povas agordi grizajn listojn tiel, ke ĉiuj sukcesaj kaj malsukcesaj provoj liveri leterojn de malsamaj sendintoj estas konsiderataj kaj, surbaze de ilia nombro, oni decidos aŭtomate aldoni la sendinton al la blankaj aŭ nigraj listoj.
Ni atentigas vin pri tio, ke la uzo de grizaj listoj devas esti farita kun la plej granda respondeco. Plej bone estus, se la uzo de ĉi tiu teknologio iras kune kun la konstanta prizorgado de blankaj kaj nigraj listoj por forigi la eblecon perdi retpoŝtojn, kiuj estas vere gravaj por la entrepreno.
Aldone, aldoni SPF, DMARC, kaj DKIM-ĉekojn povas helpi protekti kontraŭ retpoŝta bombado. Ofte leteroj kiuj alvenas tra la procezo de poŝtbombado ne pasas tiajn kontrolojn. Kiel fari tion oni diskutis .
Tiel, protekti vin kontraŭ tia minaco kiel retpoŝta bombado estas sufiĉe simpla, kaj vi povas fari tion eĉ en la stadio de konstruado de la infrastrukturo Zimbra por via entrepreno. Tamen gravas konstante certigi, ke la riskoj uzi tian protekton neniam superas la profitojn, kiujn vi ricevas.
fonto: www.habr.com