Митът DMZ
Уязвимостта на модела е свързана повече със в спокойствието на хората, които го използват, отколкото със самия модел. Ако информацията която пазите е от значително значение за сигурността на компанията или за националната сигурност има начини да подобрите демилитаризираната зона
Едва ли има компания с повече от 100 служители, която да не използва DMZ като метод за защита. Демилитаризираната зона (DMZ) – това е зоната между две защитни стени, в която се намират сървъри за уеб, мейл, или application услуги, като чак след втората защитна стена се намират потребителите от вътрешната мрежа.
Няма нищо лошо в този модел – ако някой атакува външните сървъри, това ще го забави. Разбира се, никой няма да го прави освен ако няма 0-day (уязвимост която все още не е затворена от производителя на софтуера). Обичам да визуализирам това с крадец, опитващ се да влезе в банка биейки си главата в стената… Очевидно това е идеята на банката когато строи стените си – да се предпази от подобни крадци? Преценете сами.
Например, нека имаме една операционна система за сървърите в DMZ, или няколко. Тези сървъри се считат за особено критични, пачват се възможно най-често и биват конфигурирани за сигурност възможно най-усърдно. И ако въпреки всички мерки за сигурност, някой притежава непубличен exploit (това е заплаха, използваща някоя дупка в сигурността, произтичаща от неразкрита до момента уязвимост) за точно тази система – какъв е шансът след пробив на този DMZ съврър, вътрешните сървъри да са по-защитени, с по-нови версии на софтуера и следени по-отблизо (логове, и т.н.)? Не е много голям.
Какво става когато организацията има повече от 1000 служители, а всеки patch изисква да се спазва процедура по тестване в 3 различни обкръжения (test, pre-production и production)? Колко време отнема един такъв тест, дори за критична уязвимост за която току-що е излязла кръпка?
Ако някой проверява точно тези съвръри всеки ден и чака за такава уязвимост с месеци (а ако информацията към която се стреми е достатъчно ценна си струва да се проверява и с години), колко време ще му отнеме да разбере че сървърите все още не са пачнати и си чакат реда по процедура?
Следва да се запитаме, доколко ефективен е този модел за защита на мрежи. Лично моето мнение е, че имаме нужда или от подобряване на този модел, или от друг, когато информацията която пазим е от значително значение за сигурността на компанията а понякога и за националната сигурност. Намесвам термина „национална сигурност” не случайно – виждал съм провала на DMZ модела в чуждестранни агенции за сигурност и това е още едно доказателство за неефективността му.
Уязвимостта на модела
Тя е свързана повече със в спокойствието на хората, които го използват, отколкото със самия модел. Ако нямате друг избор и трябва да продължите да разчитате на демилитаризираната зона, има начини да я подобрите.
На първо място, преборвайки се със спокойствието и събуждайки се от сладък сън, получаваме така необходимата мотивация за действие. Действие в следните насоки:
-
Защита на DMZ съврърите с презумцията за това, че рано или късно ще бъдат компрометирани.
-
Разширяване функционалността на двете защитни стени отделящи DMZ от Интернет и от вътрешната мрежа, чрез добавяне на IPS/IDS системи следящи за наличието на зловредни пакети в трафика между двете защитни стени.
-
Защита на всеки вътрешен сървър и потребителски компютър с разбирането че това е т.нар. Internet-facing ресурс, а не вътрешен неуязвим терминал!
Ще се спра по-детайлно върху всяка от горните точки.
Защита на DMZ съврърите
Като първа точка в този списък, и не задължително първа на практика, приемаме че сървърите в DMZ са компрометирани – какви са следващите ни стъпки? Ако няма изградена процедура за такива случаи, имаме много сериозен проблем. Първата стъпка винаги ще е да сме сигурни че тези сървъри са „чисти” – за целта трябва да сме сигурни кога точно се е случил пробива, иначе не можем да възстановим от backup. Инсталация на чисто и закърпване с най-новите кръпки също не е гарант за успех ако имаме предвид вече споменатите уязвимости в техния нулев ден (0-day). Именно затова, за да сме сигурни в целостта на най-важните си данни, винаги, по всяко време приемаме тези сървъри за пробити – така ще изградим независими криптирани канали за данни независещи от сигурността на internet-facing сървърите.
Разширяване функционалността на защитните стени
Точка 2 от списъка приема, че първата е вярна и имаме пробив в сигурността – той трябва да бъде незабавно засечен и изолиран, при възможност ще затворим дупката от която е потекла информация и в някои случаи ще предприемем офанзивни действия – но това не е част от тази статия.
IDS/IPS системи трябва да имаме както на входа и изхода от DMZ, така и във вътрешната мрежа. Тоест имаме следната схема: Интернет – Firewall (с IDS/IPS) – DMZ – Firewall (с IDS/IPS) – вътрешна мрежа (с IDS/IPS).
Защита на всеки вътрешен сървър и потребителски компютър
Точка 3 е най-интересна, и тя е свързана с друг модел който искам да ви предложа. Първо обаче, приели сме че не можем да използваме друг модел и оставаме с DMZ – нека го защитим възможно най-добре. По подразбиране, използвайки DMZ вътрешната мрежа е защитена от външни атаки. Не! Това е най-опасната мисъл, която може да мине през главата на някой занимаващ се сериозно с ИТ сигурност. При защита на вътрешната мрежа, добра идея е да се използва отделна IDS/IPS система – още преди да се заемем с укрепване защитата на всеки хост в мрежата, приемайки по подразбиране, че той е външна част от мрежата достъпна от Интернет, а не вътрешна защитена система.
Но…
Все още имам усещането, че заглавието на статията е недоказано, затова преминавам и към същността и – защо DMZ e мит? Крадецът, който споменах в началото, освен ако не е току-що избягал от специализирано психиатрично заведение, едва ли ще се опита да влезе през стената на банката блъскайки главата си в нея. Изхождайки от тази аналогия, много малко хора биха рискували да бъдат засечени, атакувайки вашата DMZ зона директно.
Хората занимаващи се професионално с пробиви в ИТ сигурността, не поставят на първо място в списъка от своите цели сървърите в DMZ средата.
На първо място във всеки обир е бил винаги човешкият фактор – в нашия случай, това е редовият компютърен потребител във вътрешната мрежа. Той, браузвайки какви ли не странички всеки ден, представлява един невероятно удобен тунел преминаващ през всички защитни стени от DMZ и даващ директен достъп на атакуващия до вътрешната мрежа… погазвайки безцеремонно всичките ни досегашни многомесечни и многохилядни усилия да защитим DMZ модела.
Решението?
Няма такова. Можем обаче да затрудним атакуващите толкова много, че да нямат друг избор освен да си изберат друга цел. Това е така, в случай че пазената от нас информация не е жизненоважна за тях разбира се. И единственият начин да им затрудним живота толкова много, е да защитим всяка точка от мрежата така, все едно е Internet-facing ресурс незащитен от никакви защитни стени или други системи за сигурност. Това на практика изисква изолация на сървърите които досега са били в DMZ и преместването им в напълно независима мрежа, с различна IP адресация, препоръчително намиращи се в друга сграда или друг хостинг център.
Също така всеки потребител имащ достъп до Интернет, трябва да бъде смятан за потенциална жертва на атака и потенциална точка за достъп до всички останали ресурси в мрежата, като информацията на неговия личен компютър вече може да бъде смятана за публично достъпна, ако имаме налице пробив в сигурността. Не мога да подчертая достатъчно, колко важно е да защитим редовия компютър имащ достъп до Интерент – както и колко е важно да научим този потребител как да се държи в мрежата – защото това в почти всички случаи е най-слабата връзка от веригата, и ние можем да я подсилим, ако приложим достатъчно усилия.
Задължителните мерки
Най-чувствителните данни независимо от тяхното местоположение (на сървър или на диска на Изпълнителния Директор) трябва да бъдат криптирани. IDS/IPS системи следящи за подозрителен трафик най-вече насочен навън, но и между отделните точки във вътрешната мрежа са абсолютно задължителни. Не на последно място, от момента на излизане на дадена кръпка за сигурността, на която и да е операционна система, за която и да е точка в мрежата, до нейното инсталиране в продукционна среда не трябва да минават повече от няколко часа. Ако е абсолютно необходимо това време да се удължи, приемаме че сървърите ни са под атака и ги следим с три пъти по-голямо усърдие, докато кръпката бъде приложена.
И така, от поне 2 години средният Интернет потребител в интранет мрежата вече е точката за достъп отвън навътре – като изключим некоректните служители изнасящи информация по свое желание. Откакто съществува XSS (Cross Site Scripting) всеки посетил заразен сайт, може неволно да извърши portscan на вътрешната мрежа само чрез браузъра си. Ако служител посети сайт уязвим на XSS, сигурността на клиентския компютър няма абсолютно никакво значение – JavaScript енджина във всеки браузър започва да изпълнява каквото му се каже, и това е съвсем “в реда на нещата”.
Ако вашето уеб приложение подлежи на SQL injection, не става въпрос само за това, че данните от базата изтичат – имайки достъп до SQL сървъра, само чрез SQL команди е възможно да се върши какво ли не, като използваме отново баналния portscan. Затова DMZ сървърите не трябва да са част от корпоративната мрежа, а да бъдат напълно изолирани от нея, доколкото е възможно.
Колко са начините за преодоляване на защитата в една компания?
Замисляли ли сте се, че можете да бъдете обект на такава атака и как да се защитите от нея? За илюстрация, ще ви дам един пример.
Пред офиса ви някой изпуска една USB флашка, пълна с игри и интересни, безплатни програми, като нови версии на браузъри, разни интересни документи, истории.. някои от документите, и някои от приложенията, са заразени с вирус. Вирусът е кодиран специално за вас – и тъй като няма кой да прати sample на антивирусната компания, за тях този вирус не съществува. Вирусът не прави кой знае какво – дори няма нужда да заразява нищо на клиенския компютър – дори няма нужда да прави промени в системните файлове. Той просто достъпва даден IP адрес някъде в Интернет, и създава криптиран тунел за данни. Прави го на порт 443 или дори 80 – всички позволяват достъп до тези портове отвътре навън… Както обичам да казвам, GAME OVER. Единствения начин за борба с такива атаки, е позволяване на достъп само до определени IP адреси и уеб ресурси, предварително одобрени от отдела за ИТ сигурност.
Знам, че цензурата е много неприятна за всички нас – и на мен би ми било много неприятно ако не ми се дава достъп до дори едно кътче в Интернет пространството – но ако обясните на служителите си защо им давате достъп само до доказани със сигурността си уеб ресурси, съм сигурен че по-голямата част от тях ще ви разберат.
Също така, не е съвсем невъзможно да предоставите пълен Интернет достъп от изолирана среда, като например кухнята, кафето, или пушилнята – сложете няколко „bastion” терминала, напълно изолирани от вътрешната мрежа за да могат хората в обедната си почивка или в почивката за пушене да браузват където си искат – и вълкът цял, и агнето сито… Дори може да използвате VNC достъп до виртуални изолирани машини – въображението е единственият лимит, когато защитавате мрежата си. А за всички останали уеб ресурси – непознати сайтове, страници хоствани от неизвестно кой, неизвестно защо – достъпът би трябвало да е забранен. По обяснени на всички причини, и защото няма логична бизнес причина хората да се ровят къде ли не, в работно време.
Освен всичко останало, блокиране на връзки към непознати http и IP адреси, ще ви предпази от горния сценарий с вируси разпространявани по „алтернативни” методи – дори компютър да бъде заразен чрез намерена на улицата флаш памет, вирусът няма да може да се свърже със създателя си. Светът е спасен отново.
В заключение
DMZ беше добра за времето си –преди около 10 години да речем – но от доста време е тотално недостатъчна и измамно успокояваща защита – борбата се премести на клиентския компютър, и ако ние не я водим там, вече губим битката. Крайно време е за промяна на ИТ политиките за сигурност и реални действия, за да можем да сме адекватен противник във войната за информация.
