Мэйл-бомбінг з'яўляецца адной з найбольш старых разнавіднасцяў кібер-нападаў. Па сваёй сутнасці яна нагадвае звычайную DoS-напад, толькі замест хвалі запытаў з розных ip-адрасоў, на сервер адпраўляецца вал электронных лістоў, якія ў велізарных колькасцях прыходзяць на адзін з паштовых адрасоў, за кошт чаго нагрузка на яго значна ўзрастае. Такі напад можа прывесці да немагчымасці выкарыстоўваць паштовую скрыню, а часам нават здольная прывесці да адмовы ўсяго сервера. Шматгадовая гісторыя такога віду кібератак прывяла да шэрагу пазітыўных і негатыўных для сістэмных адміністратараў наступстваў. Да пазітыўных фактараў можна аднесці добрую вывучанасць мэйл-бомбінга і наяўнасць простых спосабаў абараніцца ад такой атакі. Да негатыўных жа фактараў можна аднесці вялікую колькасць агульнадаступных праграмных рашэнняў для правядзення такіх выглядаў нападаў і магчымасць для зламысніка надзейна абараніцца ад выяўлення.
Немалаважнай асаблівасцю дадзенай кібератакі з'яўляецца тое, што яе практычна немагчыма выкарыстоўваць для атрымання прыбытку. Ну накіраваў зламыснік на адну з паштовых скрынь вал электронных лістоў, ну не даў чалавеку нармальна выкарыстоўваць электронную пошту, ну ўзламаў зламыснік чыю-небудзь карпаратыўную пошту і пачаў масава рассылаць па ўсім GAL тысячы лістоў, з-за чаго сервер або крахнуўся, або пачаў тармазіць так, што карыстацца ім стала немагчыма, і што далей? Канвертаваць падобнае кіберзлачынства ў жывыя грошы амаль немагчыма, таму проста мэйл-бомбінг у цяперашні час з'яўляецца даволі рэдкай з'явай і сістэмныя адміністратары пры праектаванні інфраструктуры могуць проста не ўспомніць аб неабходнасці абароны ад падобнай кібератакі.
Тым не менш, нягледзячы на тое, што сам па сабе мэйл-бомбінг з'яўляецца даволі бессэнсоўным з камерцыйнага пункта гледжання заняткам, ён часта з'яўляецца складовай часткай іншых, больш складаных і шматступенных кібератак. Напрыклад, пры ўзломе пошты і выкарыстанні яе для згону акаўнта ў якім-небудзь публічным сэрвісе, зламыснікі часта «бамбяць» паштовую скрыню ахвяры якія не маюць сэнсу лістамі, каб ліст з пацверджаннем згубілася ў іх струмені і застаўся незаўважаным. Таксама мэйл-бомбінг можа выкарыстоўвацца як сродак эканамічнага ціску на прадпрыемства. Так, актыўнае бамбаванне публічнай паштовай скрыні прадпрыемства, на якую паступаюць заяўкі ад кліентаў, можа сур'ёзна ўскладніць працу з імі і, як следства, можа прывесці да простага абсталявання, нявыкананых заказаў, а таксама страты рэпутацыі і ўпушчанай выгадзе.
Менавіта таму сістэмнаму адміністратару не варта забываць аб верагоднасці правядзення мэйл-бомбінга і заўсёды прымаць неабходныя меры для абароны ад гэтай пагрозы. Калі ўлічыць тое, што гэта можна зрабіць яшчэ на этапе пабудовы паштовай інфраструктуры, а таксама тое, што гэта адымае ў сістэмнага адміністратара зусім няшмат часу і працы, аб'ектыўных прычын для таго, каб не забяспечыць сваю інфраструктуру абаронай ад мэйл-бомбінга, папросту не застаецца . Давайце ж паглядзім на тое, як рэалізавана абарона ад дадзенай кібератакі ў Zimbra Collaboration Suite Open-Source Edition.
У аснове Zimbra ляжыць Postfix – адзін з самых надзейных і функцыянальных Mail Transfer Agent з адкрытым зыходным кодам на дадзены момант. І адной з галоўных пераваг яго адкрытасці з'яўляецца тое, што ён падтрымлівае самыя разнастайныя іншыя рашэнні для пашырэння функцыянальнасці. У прыватнасці, Postfix паўнавартасна падтрымлівае cbpolicyd – прасунутую ўтыліту для забеспячэння кібербяспекі паштовага сервера. Апроч абароны ад спаму і стварэння белых, чорных і шэрых спісаў, cbpolicyd дазваляе адміністратару Zimbra наладзіць праверку SPF-подпісы, а таксама ўсталяваць абмежаванні на прыём і адпраўку электронных лістоў ці дадзеных. Яны могуць як забяспечыць надзейную абарону ад спаму і фішынгавых лістоў, так і абараніць сервер ад мэйл-бомбінга.
Першае, што запатрабуецца ад сістэмнага адміністратара – гэта актывацыя модуля cbpolicyd, які прадусталяваны ў Zimbra Collaboration Suite OSE на MTA-серверы інфраструктуры. Робіцца гэта пры дапамозе каманды zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Пасля гэтага неабходна будзе актываваць вэб-інтэрфейс, каб мець магчымасць камфортна кіраваць cbpolicyd. Для гэтага неабходна дазволіць злучэнні на вэб-порце нумар 7780, стварыць знакавую спасылку пры дапамозе каманды ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, а затым адрэдагаваць файл з наладамі пры дапамозе каманды nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, дзе неабходна прапісаць наступныя радкі:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX=»»;
Пасля гэтага застанецца толькі перазапусціць сэрвісы Zimbra і Zimbra Apache з дапамогай каманд zmcontrol restart і zmapachectl restart. Пасля гэтага вам адкрыецца доступ да вэб-інтэрфейсу па адрасе :7780/webui/index.php. Галоўным нюансам з'яўляецца тое, што ўваход у гэты вэб-інтэрфейс пакуль ніяк не абаронены і для таго, каб выключыць трапленне ў яго старонніх асоб, можна пасля кожнага ўваходу ў вэб-інтэрфейс проста зачыняць падлучэнні на порце 7780.
Абараніцца ад струменя лістоў, выходнага з унутранай сеткі, дазваляюць квоты на адпраўку электронных лістоў, якія можна ўсталяваць дзякуючы cbpolicyd. Такія квоты дазваляюць усталяваць абмежаванне на максімальную колькасць лістоў, якое можа быць адпраўлена з адной паштовай скрыні ў адну адзінку часу. Напрыклад, калі менеджэры вашага прадпрыемства ў сярэднім адпраўляюць па 60-80 электронных лістоў за гадзіну, то можна, з улікам невялікага запасу, усталяваць ім квоту ў 100 электронных лістоў за гадзіну. Для таго, каб вычарпаць такую квоту, менеджэрам давядзецца адпраўляць па адным лісце раз у 36 секунд. З аднаго боку гэтага дастаткова для таго, каб паўнавартасна працаваць, а з іншага боку, з такой квотай зламыснікі, якія атрымалі доступ да пошты аднаго з вашых мэнэджараў не задаволяць мэйл-бомбінг або масавую спам-атаку на прадпрыемстве.
Для таго, каб усталяваць падобную квоту, неабходна ў вэб-інтэрфейсе стварыць новую палітыку абмежавання адпраўкі лістоў і паказаць, каб яна дзейнічала як на лісты адпраўленыя ўсярэдзіне даменаў, так і на лісты, якія дзейнічаюць на вонкавыя адрасы. Робіцца гэта наступным чынам:
Пасля гэтага можна будзе больш дэталёва ўказаць абмежаванні, звязаныя з адпраўкай лістоў, у прыватнасці задаць часовы інтэрвал, па сканчэнні якога абмежаванні будуць абнаўляцца, а таксама паведамленне, якое будзе атрымліваць карыстальнік, які перавысіў свой ліміт. Пасля гэтага можна ўстанавіць і само абмежаванне на адпраўку лістоў. Яго можна задаць як у выглядзе колькасці выходных лістоў, так і ў выглядзе колькасці байтаў перадаванай інфармацыі. Пры гэтым з лістамі, якія адпраўляюцца звыш пазначанага ліміту, абыходзіцца па-рознаму. Так, напрыклад, можна іх проста адразу ж выдаляць, а можна захоўваць, каб яны адправіліся адразу пасля абнаўлення ліміту на адпраўку паведамленняў. Другой опцыяй можна скарыстацца падчас выяўлення аптымальнага значэння мяжы на адпраўку электронных лістоў супрацоўнікамі.
Апроч абмежаванняў на адпраўку лістоў, cbpolicyd дазваляе наладзіць ліміт на атрыманне лістоў. Такое абмежаванне, на першы погляд, з'яўляецца выдатным рашэннем для абароны ад мэйл-бомбінга, аднак па факце ўстаноўка такога ліміту, хай нават вялікага, багатая тым, што ў пэўных умовах да вас можа не дайсці важны ліст. Менавіта таму ўключаць якія-небудзь абмежаванні для ўваходнай пошты вельмі не рэкамендуецца. Аднак калі вы ўсё ж вырашылі рызыкнуць, падыходзіць да налады ліміту ўваходных паведамленняў трэба падыходзіць з асаблівай увагай. Напрыклад, можна абмежаваць колькасць уваходных лістоў ад давераных контрагентаў, каб у выпадку, калі іх паштовы сервер быў скампраметаваны, з яго не праводзілася спам-атака на ваша прадпрыемства.
Для таго, каб абараніцца ад вала ўваходных паведамленняў пры мэйл-бомбінгу, сістэмнаму адміністратару варта зрабіць нешта разумнейшае, чым простае абмежаванне ўваходнай пошты. Такім рашэннем можа стаць выкарыстанне шэрых спісаў. Прынцып іх дзеяння складаецца ў тым, што пры першай спробе даставіць паведамленне ад ненадзейнага адпраўніка, злучэнне з серверам рэзка перарываецца, з-за чаго дастаўка ліста заканчваецца няўдачай. Аднак, калі ў вызначаны перыяд ненадзейны сервер ізноў прадпрымае спробу адправіць тое ж самае ліст, сервер не абрывае злучэнне і яго дастаўка праходзіць паспяхова.
Сэнс усіх гэтых дзеянняў у тым, што праграмы для аўтаматычнага масавага рассылання электронных лістоў звычайна не правяраюць паспяховасць дастаўкі адпраўленага паведамлення і не прадпрымаюць спробы адправіць яго ў другі раз, тады як чалавек напэўна пераканаецца, ці быў адпраўлены яго ліст па адрасе, ці не.
Уключыць шэрыя спісы можна таксама ў вэб-інтэрфейсе cbpolicyd. Для таго, каб усё працавала, неабходна стварыць палітыку, у якую пападалі б усе ўваходныя лісты, адрасаваныя карыстачам на нашым серверы, а затым на аснове гэтай палітыкі стварыць правіла Greylisting, дзе можна наладзіць інтэрвал, падчас якога cbpolicyd будзе чакаць паўторнага адказу ад незнаёмага. адпраўніка. Звычайна ён складае 4-5 хвілін. Пры гэтым шэрыя спісы можна наладзіць так, каб усе паспяховыя і няўдалыя спробы даставіць лісты ад розных адпраўнікоў улічваліся і на падставе іх колькасці прымалася рашэнне аб аўтаматычным даданні адпраўніка ў белы ці чорны спісы.
Звяртаем вашу ўвагу на тое, што да выкарыстання шэрых спісаў варта быць падобным з максімальнай адказнасцю. Лепш за ўсё будзе, калі выкарыстанне гэтай тэхналогіі будзе ісці рука ў руку з пастаянным вядзеннем белых і чорных спісаў, каб выключыць магчымасць страты сапраўды важных для прадпрыемства лістоў.
Акрамя таго, абараніцца ад мэйл-бомбінга можа дапамагчы даданне праверак SPF, DMARC і DKIM. Часцяком лісты, якія паступаюць падчас мэйл-бомбінга такія праверкі не праходзяць. Пра тое, як гэта зрабіць, расказвалася .
Такім чынам, абараніцца ад такой пагрозы як мэйл-бомбінг, даволі проста, і зрабіць гэта можна яшчэ на этапе будаўніцтва інфраструктуры Zimbra для вашага прадпрыемства. Аднак важна ўвесь час сачыць за тым, каб рызыкі ад выкарыстання такой абароны ніколі не перавышалі атрымоўваныя вамі перавагі.
Крыніца: habr.com