Гэты артыкул з'яўляецца чацвёртым у цыкле артыкулаў "Як узяць сеткавую інфраструктуру пад свой кантроль". Змест усіх артыкулаў цыклу і спасылкі можна знайсці .
В гэтай главы мы разгледзелі некаторыя аспекты сеткавай бяспекі сегмента "Data Center". Гэтая частка будзе прысвечана "Internet Access" сегменту.
Доступ у інтэрнэт
Тэма бяспекі несумненна з'яўляецца адной з найбольш складаных тэм свету сетак перадачы даных. Як і ў папярэдніх выпадках, не прэтэндуючы на глыбіню і паўнату, я разгледжу тут дастаткова простыя, але, на мой погляд важныя пытанні, адказы на якія, спадзяюся, дапамогуць падняць узровень абароненасці вашай сеткі.
Пры аўдыце гэтага сегмента звернеце ўвагу на наступныя аспекты:
- дызайн
- налады BGP
- DOS/DDOS абарона
- фільтраванне трафіку на фаерволе
Дызайн
У якасці прыкладу дызайну гэтага сегмента для сеткі прадпрыемства я б парэкамендаваў ад Cisco у рамках .
Вядома, магчыма, рашэнне іншых вендараў здасца вам больш прывабным (гл. ), але, не заклікаючы вас прытрымлівацца ў дэталях гэтага дызайну, я ўсё ж лічу карысным разабрацца ў прынцыпах і ідэях, якія ляжаць у яго аснове.
заўвагу
У SAFE сегмент "Remote Access" з'яўляецца часткай "Internet Access". Але ў дадзеным цыкле артыкулаў мы будзем разглядаць яго асобна.
Стандартным наборам абсталявання ў гэтым сегменце для сеткі прадпрыемствы (enterprise network) з'яўляюцца
- гранічныя маршрутызатары (border routers)
- фаервалы
заўвага 1
У дадзеным цыкле артыкулаў, калі я кажу пра фаервалы, я маю на ўвазе .
заўвага 2
Я апускаю разгляд рознага роду L2/L1 або оверлейных L2 over L3 рашэнняў неабходных для забеспячэння L1/L2 складнасці і абмяжоўваюся толькі пытаннямі ўзроўня L3 і вышэй. Часткова пытанні L1/L2 былі разгледжаны ў раздзеле ««.
Калі вы не выявілі фаервала ў гэтым сегменце, тое не варта спяшацца з высновамі.
Давайце, як і ў , пачнем з пытання, а ці з'яўляецца неабходным выкарыстанне фаервала ў дадзеным сегменце ў вашым выпадку?
Магу сказаць, што, падобна, гэта найболей апраўданае месца для выкарыстання фаервалаў і для ўжывання складаных алгарытмаў фільтрацыі трафіку. У мы згадвалі 4 фактары, якія могуць перашкодзіць выкарыстанню фаервалаў у дата-цэнтр сегменце. Але тут яны ўжо не такія істотныя.
Прыклад 1. затрымка
У тым, што тычыцца інтэрнэту, няма сэнсу казаць пра затрымкі нават каля 1 мілісекунды. Таму затрымка ў дадзеным сегменце не можа з'яўляцца фактарам, якія абмяжоўваюць выкарыстанне фаеравала.
Прыклад 2. Proizvoditelnost
У некаторых выпадках гэты фактар па-ранейшаму можа быць значным. Таму, магчыма, частка трафіку (напрыклад, трафік балансавальнікаў нагрузкі) вам давядзецца пусціць у абыход фаервала.
Прыклад 3. Надзейнасць
Гэты фактар па-ранейшаму трэба прымаць да ўвагі, але ўсё ж, з улікам ненадзейнасці самога інтэрнэту, яго значэнне для гэтага сегмента не такое значнае, як для дата-цэнтра.
Так, выкажам здагадку, што ваш сэрвіс жыве па-над http/https (з кароткімі сесіямі). У гэтым выпадку вы можаце выкарыстоўваць дзве незалежныя скрынкі (без HA) і пры праблеме з адной з іх па роўтынгу пераводзіць увесь трафік на другую.
Ці вы можаце выкарыстоўваць фаервалы ў трансперэнт модзе і пры выхадзе іх са строю на час вырашэння праблемы пускаць трафік у абыход фаервалаў.
Таму, хутчэй менавіта толькі кошт можа быць тым фактарам, які прымусіць вас адмовіцца ад ужывання фаервалаў у гэтым сегменце.
Важна!
Узнікае спакусу сумясціць гэты фаервал з фаервалам дата-цэнтра (выкарыстоўваць адзін фаервал для гэтых сегментаў). Рашэнне, у прынцыпе, магчымае, але пры гэтым трэба разумець, што т.я. "Internet Access" фаервол фактычна стаіць на пярэднім краі вашай абароны і "прымае на сябе", прынамсі, частка шкоднаснага трафіку, то, вядома, трэба ўлічваць падвышаную рызыку таго, што дадзены фаервол будзе выведзены з ладу. Гэта значыць, выкарыстоўваючы адны і тыя ж прылады ў двух гэтых сегментах, вы істотна панізіце availability вашага дата-цэнтр сегмента.
Як звычайна, трэба разумець, што ў залежнасці ад сэрвісу, які кампанія падае, дызайн гэтага сегмента можа моцна адрознівацца. Вы, як звычайна, можаце абраць розныя падыходы ў залежнасці ад патрабаванняў.
Прыклад
Калі вы – кантэнт правайдэр, з сеткай CDN (гл., напрыклад, ), то вы можаце не захацець ствараць у дзясятках, а то і сотнях кропак прысутнасці інфраструктуры з выкарыстаннем асобных прылад для маршрутызацыі і фільтрацыі трафіку. Гэта будзе дорага, ды і проста можа быць залішнім.
Для BGP вам зусім не абавязкова мець выдзеленыя маршрутызатары, вы можаце выкарыстоўваць open-source прылады, напрыклад, . Таму, магчыма, усё, што вам трэба - гэта сервер або некалькі сервераў, камутатар і BGP.
У гэтым выпадку ваш сервер ці некалькі сервераў могуць гуляць ролю не толькі CDN сервера, але таксама і маршрутызатара. Вядома, тут яшчэ шмат дэталяў (напрыклад, як забяспечыць балансаванне), але гэта рэалізуема, і гэты падыход мы паспяхова прымянілі для аднаго з нашых партнёраў.
Вы можаце мець некалькі дата-цэнтраў з паўнавартаснай абаронай (фаервалы, сэрвісы па абароне ад DDOS, якія прадстаўляюцца вашымі інтэрнэт правайдэрамі) і дзясяткі ці сотні «спрошчаных» кропак прысутнасці толькі з L2 камутатарамі і серверамі.
А як жа абарона ў дадзеным выпадку?
Давайце разгледзім, напрыклад, папулярную ў апошні час . Яе небяспека заключаецца ў тым, што генеруецца вялікая колькасць трафіку, які проста "забівае" на 100% усе вашыя аплінкі.
Што мы маем у выпадку нашага дызайну.
- калі вы карыстаецеся AnyCast то, трафік размяркоўваецца паміж вашымі кропкамі прысутнасці. Калі сумарная паласа прапускання ў вас тэрабіты, тое гэта само па сабе фактычна (усё ж у апошні час было некалькі нападаў з шкоднасным трафікам парадку тэрабіту) засцерагае вас ад «перапаўнення» аплінкаў.
- калі ўсё ж нейкія аплінкі «забіліся», тыя вы проста выводзьце дадзеную пляцоўку з абслугоўвання (перастаеце анансаваць прэфікс)
- вы таксама можаце павялічыць долю трафіку, які аддаецца з вашых “паўнавартасных” (і, адпаведна, абароненых) дата-цэнтраў, такім чынам, прыбраўшы істотную частку шкоднаснага трафіку з неабароненых кропак прысутнасці
І яшчэ невялікая заўвага да гэтага прыкладу. Калі дастатковую колькасць трафіку вы аддаяце праз IX-ы, тое гэта таксама змяншае вашу схільнасць падобным нападам
Настройка BGP
Тут дзве тэмы.
- Сувязь
- Настройка BGP
Аб складнасці мы ўжо трохі казалі ў . Сутнасць у тым, каб трафік да вашых кліентаў хадзіў аптымальным шляхам. Хоць, аптымальнасць - гэта не заўсёды толькі аб затрымцы, але звычайна менавіта нізкая затрымка з'яўляецца асноўным паказчыкам аптымальнасці. Для нейкіх кампаній гэта больш важна, для іншых - менш. Усё залежыць ад сэрвісу, які вы дае.
Прыклад 1
Калі вы - біржа, і для вашых кліентаў важныя інтэрвалы часу менш чым мілісекунды, то, зразумела, ні аб якім інтэрнэце наогул гаворкі ісці не можа.
Прыклад 2
Калі вы - гульнявая кампанія, і для вас важныя дзясяткі мілісекунд, то, вядома, складнасць для вас вельмі важная.
Прыклад 3
Гэтак жа трэба разумець, што, у сілу ўласцівасцяў пратаколу TCP, хуткасць перадачы дадзеных у рамках адной TCP сесіі таксама залежыць ад RTT (Round Trip Time). CDN сеткі будуюцца ў тым ліку і для вырашэння гэтай праблемы, выносячы сервера раздачы кантэнту бліжэй да спажыўца гэтага кантэнту.
Даследаванне складнасці - гэта асобная цікавая тэма, вартая асобнага артыкула або серыі артыкулаў і патрабуе добрага разумення, як "уладкованы" інтэрнэт.
Карысныя рэсурсы:
Прыклад
Прывяду толькі адзін невялікі прыклад.
Выкажам здагадку, што ваш дата-цэнтр знаходзіцца ў Маскве, і ў вас ёсць адзіны аплінк – Ростелеком (AS12389). У гэтым выпадку (single homed) BGP вам не патрэбен, і ў якасці публічных адрасоў вы, хутчэй за ўсё, карыстаецеся адрасны пул ад Растэлекама.
Выкажам здагадку, што вы дае нейкі сэрвіс, і ў вас дастатковая колькасць кліентаў з Украіны, і яны скардзяцца на вялікія затрымкі. Пры даследаванні вы высветлілі, што IP адрасы некаторых з іх знаходзяцца ў сетцы 37.52.0.0/21.
Выканаўшы traceroute, вы ўбачылі, што трафік ідзе праз AS1299 (Telia), а выканаўшы ping, вы атрымалі сярэдні RTT 70 – 80 мілісекунд. Вы можаце ўбачыць гэта таксама на .
Утылітай whois (на сайце ripe.net або лакальнай утылітай) вы лёгка можаце вызначыць, што блок 37.52.0.0/21 належыць AS6849 (Ukrtelecom).
Далей, зайшоўшы на вы бачыце, што ў AS6849 няма адносін з AS12389 (яны не з'яўляюцца ні кліентамі, ні аплінкамі адзін аднаму, гэтак жа ў іх няма і пірынгу). Але калі вы паглядзіце на для AS6849, то вы ўбачыце, напрыклад, AS29226 (Mastertel) і AS31133 (Megafon).
Знайшоўшы looking glass гэтых правайдэраў, вы можаце параўнаць шлях і RTT. Напрыклад, для Mastertel RTT будзе ўжо каля 30 мілісекунд.
Так што, калі розніца паміж 80 і 30 мілісекундамі істотная для вашага сэрвісу, то, магчыма, вам трэба задумацца аб складнасці, атрымаць у RIPE свой нумар AS, свой пул адрасоў і падлучыць дадатковыя аплінкі і/ці стварыць кропкі прысутнасці на IX-ах.
Пры выкарыстанні BGP вы не толькі маеце магчымасць палепшыць складнасць, але таксама рэзярвуеце сваё падлучэнне да інтэрнэту.
змяшчае рэкамендацыі па наладзе BGP. Нягледзячы на тое, што гэтыя рэкамендацыі былі выпрацаваны на аснове «best practice» правайдэраў, усё ж (калі вашы BGP налады не зусім ужо элементарныя) яны з'яўляюцца несумненна карыснымі і фактычна павінны быць часткай hardening-а, які мы абмяркоўвалі ў .
DOS/DDOS абарона
Цяпер DOS/DDOS напады сталі паўсядзённай рэальнасцю для шматлікіх кампаній. У рэчаіснасці, у тым ці іншым выглядзе, вас атакуюць даволі часта. Тое, што вы пакуль не заўважаеце гэтага, кажа толькі аб тым, што пакуль не была арганізавана мэтанакіраваная атака супраць вас, і што тыя сродкі абароны, якімі вы карыстаецеся, нават, магчыма, не падазраючы пра гэта (розныя ўбудаваныя абароны аперацыйных сістэм), дастатковыя, каб дэградацыя які прадстаўляецца сэрвісу была мінімізаваная для вас і вашых кліентаў.
Існуюць інтэрнэт-рэсурсы, якія, на аснове логаў з абсталявання, у рэжыме рэальнага часу малююць прыгожыя карты нападаў.
можна знайсці спасылкі на іх.
Мая каханая ад CheckPoint.
Абарона ад DDOS/DOS звычайна з'яўляецца эшаланаванай. Каб зразумець чаму, трэба разумець якія тыпы DOS/DDOS нападаў існуюць (гл. напрыклад, або )
Гэта значыць, мы маем тры тыпы нападаў:
- volumetric attacks
- protocol attacks
- application attacks
Калі ад апошніх двух тыпаў нападаў вы можаце абараніцца самастойна з выкарыстаннем, напрыклад, фаервалаў, то ад нападаў, накіраваных на «перапаўненне» вашых аплінкаў вы самі не абараніцеся (вядома, калі ваша сумарная ёмістасць інтэрнэт-каналаў не вылічаецца тэрабітамі, а лепш, дзясяткамі тэрабіт).
Таму, першая лінія абароны - гэта абарона ад «volumetric» нападаў і забяспечыць гэтую абарону вам павінен ваш правайдэр або правайдэры. Калі вы гэтага яшчэ не ўсвядомілі, то пакуль вам проста шанцуе.
Прыклад
Выкажам здагадку, што ў вас ёсць некалькі аплінкі, але толькі адзін з правайдэраў можа даць вам гэтую абарону. Але калі ўвесь трафік будзе ісці праз аднаго правайдэра, то як жа складнасць, якую мы коратка абгаварылі крыху раней?
На час нападу вам прыйдзецца ў гэтым выпадку збольшага ахвяраваць складнасцю. Але
- гэта толькі на час нападу. Вы можаце ў выпадку нападу ўручную ці аўтаматычна пераналаджваць BGP, такім чынам, каб трафік ішоў толькі праз правайдэра, які прадстаўляе вам «парасон». Пасля заканчэння атакі вы можаце вярнуць роўтынг у ранейшы стан.
- не абавязкова пераводзіць увесь трафік. Калі вы, напрыклад, бачыце, што праз нейкія аплінкі ці пірынг не ідзе атакі (ці трафік не істотны) вы можаце працягваць анансаваць прэфіксы з канкурэнтнымі атрыбутамі ў бок гэтых BGP суседзяў.
Абарону ад "protocol attacks" і "application attacks" вы таксама можаце аддаць на водкуп партнёрам.
Вось вы можаце пачытаць добрае даследаванне (). Праўда, артыкул двухгадовай даўнасці, але гэта дасць вам уяўленне аб падыходах, як вы можаце абараніцца ад DDOS нападаў.
У прынцыпе, вы можаце гэтым і абмежавацца, цалкам аддаўшы вашу абарону на аўтсорс. У гэтым рашэнні ёсць плюсы, але ёсць і відавочны мінус. Справа ў тым, што гаворка можа ісці (ізноў-ткі ў залежнасці ад таго, чым ваша кампанія займаецца) аб выжыванні бізнэсу. І давяраць такія рэчы іншым арганізацыям…
Таму давайце разгледзім, як арганізаваць другую і трэцюю лініі абароны (як дадатак да абароны ад правайдэра).
Такім чынам, другая лінія абароны гэта фільтраванне і абмежавальнікі трафіку (policers) на ўваходзе ў вашу сетку.
Прыклад 1
Выкажам здагадку, што вы "закрыліся парасонам" ад DDOS з дапамогай аднаго з правайдэраў. Выкажам здагадку, што гэты правайдэр выкарыстоўвае Arbor для фільтрацыі трафіку і фільтры на мяжы сваёй сеткі.
Паласа, якую можа "апрацоўваць" Arbor абмежавана, і правайдэр, вядома, не можа ўвесь час прапускаць трафік усіх сваіх партнёраў, якія замовілі гэтую паслугу, праз якое фільтруе абсталяванне. Таму ў звычайных умовах трафік не фільтруецца.
Выкажам здагадку, што ідзе напад SYN flood. Нават калі вы замовілі паслугу, пры якой у выпадку нападу трафік аўтаматычна пераводзіцца на фільтраванне, гэта не адбываецца імгненна. На працягу хвіліны ці больш вы застаяцеся пад атакай. І гэта можа прывесці да выхаду са строю вашага абсталявання або дэградацыі сэрвісу. У гэтым выпадку абмежаванне трафіку на межавым маршрутызацыі, хоць, і прывядзе да таго, што некаторыя TCP сесіі на працягу гэтага часу не будуць усталёўвацца, але выратуе вашу інфраструктуру ад больш маштабных праблем.
Прыклад 2
Анамальна вялікая колькасць SYN пакетаў можа быць не толькі вынікам SYN flood нападу. Давайце выкажам здагадку, што вы падаеце сэрвіс, пры якім у вас адначасова можа быць каля 100 тысяч TCP канэкцый (у адзін дата-цэнтр).
Выкажам здагадку, што ў выніку кароткачасовай праблемы з адным з вашых асноўных правайдэраў у вас "кікнулася" палова сесій. Калі ваша прыкладанне ўладкована такім чынам, што яно, "нядоўга думаючы", адразу (ці праз нейкі аднолькавы для ўсіх сесій інтэрвал часу) спрабуе пераўсталяваць злучэнне, то вы прыблізна адначасова атрымаеце як мінімум 50 тысяч SYN пакетаў.
Калі ж па-над гэтымі сесіямі ў вас, напрыклад, павінен працаваць ssl/tls handshake, што мяркуе абмен сертыфікатамі, то з пункта гледжання вычарпання рэсурсаў для вашага балансавальніка нагрузкі гэта будзе значна мацнейшы «DDOS» чым просты SYN flood. Здавалася б, балансавальнікі павінны адпрацоўваць такія падзеі, але… на жаль, мы сутыкнуліся ў поўны рост з такой праблемай.
І, вядома, policer на межавым маршрутызатары выратуе вашае абсталяванне і ў гэтым выпадку.
Трэці ўзровень абароны ад DDOS/DOS - гэта налады вашага фаервала.
Тут вы можаце купіраваць як напады другога, так і трэцяга тыпу. Увогуле, усё, што даляціць да фаервала можна будзе адфільтраваць тут.
Савет
Паспрабуйце даць фаервалу як мага менш працы, адфільтраваўшы як мага больш на першых двух лініях абароны. І вось чаму.
З вамі не адбывалася такога, што выпадкова, генеруючы трафік, каб праверыць, напрыклад, наколькі аперацыйная сістэма вашых сервераў устойлівая да DDOS нападам, вы "забівалі" свой фаервол, загружаючы яго на 100 адсоткаў, пры гэтым трафікам са звычайнай інтэнсіўнасцю? Калі не, то, можа быць, проста таму, што вы не спрабавалі?
Увогуле, фаервол, як я ўжо казаў - складаная штука, і ён добра працуе з вядомымі ўразлівасцямі і адтэставанымі рашэннямі, але калі вы пашле нешта незвычайнае, проста нейкі смецце ці пакеты з няправільнымі загалоўкамі, то вы з некаторай, не такой ужо маленькай (зыходзячы з майго досведу) верагоднасцю можаце ўвесці ў ступар і топавае абсталяванне. Таму, на этапе 2 з дапамогай звычайных ACL (на ўзроўні L3/L4) пускайце ў вашу сетку толькі той трафік, які павінен туды ўваходзіць.
Фільтраванне трафіку на фаерволе
Працягваем размову пра фаервал. Трэба разумець, што DOS/DDOS напады – гэта толькі адна з разнавіднасцяў кібер-нападаў.
Акрамя DOS/DDOS protection мы можам яшчэ мець нешта накшталт наступнага спісу магчымасцяў:
- application firewalling
- threat prevention (antivirus, anti-spyware, and vulnerability)
- Фільтрацыя URL
- data filtering (content filtering)
- file blocking (file types blocking)
Вы павінны вырашаць, што з гэтага спісу вам трэба.
Працяг варта
Крыніца: habr.com