Linux контейнери срещу виртуални машини: Сравнение на сигурността

Разработчиците обичат контейнерите. Те са лесни за използване и бързи за стартиране. Можете да стартирате много от тях дори на прост хардуер. Резервните разходи при стартиране винаги са били склонност към разработване и тестване и тези режийни разходи се увеличават само с архитектурите на микроуслугите. Ако разработчикът се нуждае от половин дузина услуги, той може лесно да загуби ден или два с настройка - конфигуриране на хардуер, стартиране на инсталатори, борба с несъвместимостта.

С контейнери това се свива до минути или секунди и може да се изпълнява на една работна станция за разработка. Лесно достъпните хранилища на полезни изображения на контейнери умножават производителността на разработчиците, подобно на отворения код, но без да се затрудняват да правят компилация. Оперативните екипи по-бавно приемат контейнери. Една от причините е, че много приложения, които трябва да поддържат, все още не са в контейнери. Друга причина е нежеланието да се отдалечава от виртуалните машини.

За операционните системи преминаването от гол метал към виртуални машини беше естествено. Отделните виртуални машини изглеждат и могат да се управляват като отделни системи, като се използват едни и същи инструменти и процеси. Ранните опасения относно сигурността на виртуалната машина бяха успокоени от дългата производствена история на виртуалните машини в света на мейнфреймите, от възможността да се прилагат същите контроли, използвани за голи метални системи, от поддръжката на хардуерна виртуализация и от променящата се зрелост на инструментите за управление на виртуалната машина.

Много от ранните притеснения за сигурността се свеждаха до един въпрос: бяха ли виртуалните машини толкова сигурни, колкото голия метал? Сега се повдигат подобни въпроси относно контейнерите. Колко защитени са контейнерите и как се сравняват с виртуалните машини? Със сигурност, ако сравним услугите, изпълнявани в контейнери, със същите услуги, изпълнявани като отделни процеси в една и съща система, версията на контейнера е по-сигурна. Разделянето, осигурено от пространства от имена на Linux и cgroups, осигурява бариери, които не съществуват между обикновените процеси. Сравнението с виртуалните машини е по-малко ясно. Нека да разгледаме виртуалните машини и контейнерите от гледна точка на сигурността.

В тази статия ще използвам два различни подхода за сравняване на виртуалната машина и сигурността на контейнера. Първият подход ще бъде по-структурен или теоретичен, като се разглеждат характеристиките на всеки от гледна точка на сигурността. След това ще приложа по-практичен анализ, като разгледам какво се случва при типично нарушение и как може да бъде повлияно от архитектурите на контейнери и VM.

Структурен изглед

За структурния подход ще сравня повърхността на атака и на двете системи. Атакуващата повърхност представлява броя точки, в които дадена система може да бъде атакувана. Той не е точно дефиниран (например като число), но е полезен за сравнения. За крадец къща с 10 врати има по-голяма атакуваща повърхност от къща с една врата, дори ако вратите са идентични. Една врата може да остане отключена; една ключалка може да е дефектна; вратите на различни места могат да предложат на нарушителя повече поверителност и т.н.

В компютърните системи повърхността за атака включва всичко, където нападателят (или софтуерът, действащ от негово име) може да „докосне“ целевата система. Мрежовите интерфейси, хардуерните връзки и споделените ресурси са всички възможни точки за атака. Имайте предвид, че повърхността на атаката не означава, че съществува действителна уязвимост. Всички 10 врати може да са напълно сигурни. Но по-голямата повърхност за атака означава повече места за защита и по-голямата вероятност нападателят да намери слабост поне в едно.

Общата повърхност на атаката зависи от броя на различните допирни точки и сложността на всяка от тях. Нека разгледаме един прост пример. Представете си старомодна система, която обслужва котировките на фондовия пазар. Той има един интерфейс, обикновена серийна линия. Протоколът на този ред също е прост: Символ за акции с фиксирана дължина, да речем пет знака, се изпраща до сървъра, който отговаря с ценова оферта с фиксирана дължина - да речем, 10 знака. Няма Ethernet, TCP / IP, HTTP и т.н. (Всъщност работех по такива системи отдавна в далечна, далечна галактика.)

Атакуващата повърхност на тази система е много малка. Нападателят може да манипулира електрическите характеристики на серийната линия, да изпраща неправилни символи, да изпраща твърде много данни или по друг начин да променя протокола. Защитата на системата би включвала прилагане на подходящ контрол срещу тези атаки.

Сега си представете същата услуга, но в модерна архитектура. Услугата е достъпна в Интернет и предлага RESTful API. Електрическата страна на атаката е изчезнала - всичко, което ще направите, е да изпържи собствения рутер или превключвател на нападателя. Но протоколът е изключително по-сложен. Той има слоеве за IP, TCP, вероятно TLS и HTTP, всеки от които предлага възможност за уязвимост, която може да се използва. Съвременната система има много по-голяма повърхност за атака, макар че все още изглежда на нападателя като една точка на интерфейс.

Гола метална повърхност за атака

За нападател, който не присъства физически в центъра за данни, първоначалната повърхност за атака е мрежата към сървъра. Това доведе до „периметров изглед“ на сигурността: Защитете входните точки в центъра за данни и нищо не влиза. Ако нападателят не може да влезе, няма значение какво се случва между системите отвътре. Работеше добре, когато периметърните интерфейси бяха прости (помислете за комутируем достъп), но насърчаваше слабостите на вътрешните интерфейси. Атакуващите, които откриват дупка в периметъра, често откриват, че вътрешната повърхност за атака на сървърната ферма е много по-голяма от външната и могат да нанесат значителни щети, щом са вътре.

Тази вътрешна повърхност за атака включва мрежови връзки между сървъри, но също така и взаимодействия между процесите в рамките на един сървър. По-лошо, тъй като много услуги се изпълняват с повишени привилегии („root“ потребител), успешното проникване в такава би означавало на практика неограничен достъп до нещо друго в тази система, без да се налага да се търсят допълнителни уязвимости. Цяла индустрия израсна около защитата на сървърите - защитни стени, антималуер, откриване на проникване и още и още - с по-малко от перфектни резултати.

Има и интересни атаки на „страничен канал“ срещу сървъри. Изследователите са показали примери за използване на консумация на енергия, шум или електромагнитно излъчване от компютри за извличане на информация, понякога много чувствителни данни като криптографски ключове. Други атаки са използвали открити интерфейси като безжични клавиатурни протоколи. Като цяло обаче тези атаки са по-трудни - може да се наложи близост до сървъра, например - така че основният път на слизане „по кабела“ е по-често срещан.

VM атака повърхност

Когато виртуалните машини се използват по същия начин като голия метал, без никаква разлика в архитектурата на приложението (както често се случва), те споделят повечето от същите точки за атака. Една допълнителна повърхност за атака е потенциален отказ в хипервизора, операционната система или хардуера за правилно изолиране на ресурси между виртуални машини, което позволява на виртуална машина да чете по някакъв начин паметта на друга виртуална машина. Интерфейсът между виртуалната машина и хипервизора също представлява точка на атака. Ако VM може да пробие и да получи произволен код, работещ в хипервизора, тогава тя може да има достъп до други VM в същата система. Самият хипервизор представлява точка на атака, тъй като излага интерфейси за управление.

Има допълнителни точки за атака в зависимост от вида на VM системата. VM системите от тип 2 използват хипервизор, работещ като процес в основната ОС на хост. Тези системи могат да бъдат атакувани чрез атака на хост ОС. Ако нападателят може да получи код, работещ в хост системата, той може потенциално да повлияе на хипервизора и виртуалните машини, особено ако може да получи достъп като привилегирован потребител. Наличието на цяла операционна система, включително помощни програми, инструменти за управление и евентуално други услуги и входни точки (като SSH) предоставя редица възможни точки за атака. VM системи тип 1, при които хипервизорът работи директно върху основния хардуер, елиминират тези входни точки и следователно имат по-малка повърхност за атака.

Повърхност за атака на контейнер

Както при виртуалните машини, контейнерите споделят основните точки за влизане в мрежата на голи метални системи. В допълнение, подобно на виртуални машини тип 2, контейнерните системи, които използват „напълно заредена“ хост ОС, са обект на всички едни и същи атаки, налични срещу помощните програми и услугите на тази хост ОС. Ако нападателят може да получи достъп до този хост, той може да опита да осъществи достъп или да повлияе по друг начин на работещите контейнери. Ако получи привилегирован („корен“) достъп, нападателят ще може да получи достъп или да контролира всеки контейнер. „Минималистична“ ОС (като KurmaOS на Apcera) може да помогне за намаляване на тази повърхност на атака, но не може да я премахне изцяло, тъй като за управлението на контейнери е необходим известен достъп до хост ОС.

Основните механизми за разделяне на контейнери (пространства от имена) също предлагат потенциални точки за атака. Освен това не всички аспекти на процесите в Linux системите са пространства с имена, така че някои елементи се споделят в контейнери. Това са природни зони за разследване на нападателите. И накрая, процесът към интерфейса на ядрото (за системни повиквания) е голям и изложен във всеки контейнер, за разлика от много по-малкия интерфейс между VM и хипервизора. Уязвимостите в системните повиквания могат да предложат потенциален достъп до ядрото. Един пример за това е наскоро докладваната уязвимост в ключовия пръстен на Linux.

Архитектурни съображения

Както за виртуалните машини, така и за контейнерите, размерът на повърхността на атаката може да бъде повлиян от архитектурата на приложението и от начина, по който се използва технологията.

Много стари приложения на VM третират VM като голи метали. С други думи, те не са приспособили своите архитектури специално за виртуални машини или за модели за сигурност, които не се основават на периметрова защита. Те могат да инсталират много услуги на една и съща виртуална машина, да стартират услугите с root права и да имат малко или никакви контроли за защита между услугите. Преархитектирането на тези приложения (или по-вероятно замяната им с по-нови) може да използва виртуални машини за осигуряване на разделяне на сигурността между функционалните единици, а не просто като средство за управление на по-голям брой машини.

Контейнерите са подходящи за архитектури на микроуслуги, които „нанизват“ голям брой (обикновено) малки услуги, използвайки стандартизирани API. Такива услуги често имат много кратък живот, когато контейнеризирана услуга се стартира при поискване, отговаря на заявка и се унищожава или където услугите бързо се увеличават и намаляват въз основа на търсенето. Този модел на използване зависи от бързата инстанция, която контейнерите поддържат. От гледна точка на сигурността тя има както предимства, така и недостатъци.

По-големият брой услуги означава по-голям брой мрежови интерфейси и следователно по-голяма повърхност за атака. Той обаче позволява и повече контроли на мрежовия слой. Например в платформата Apcera целият трафик от контейнер към контейнер трябва да бъде изрично разрешен. Измамен контейнер не може произволно да достига до никоя крайна точка на мрежата.

Краткият живот на контейнера означава, че ако нападателят все пак влезе, времето, което трябва да направи, е ограничено, за разлика от прозореца на възможностите, предоставен от дългосрочна услуга. Недостатъкът е, че криминалистиката е по-трудна. След като контейнерът изчезне, той не може да бъде изследван и изследван, за да се намери зловредният софтуер. Тези архитектури също затрудняват атакуващия да инсталира зловреден софтуер, който оцелява след унищожаване на контейнера, тъй като може да го направи на гол метал, като инсталира драйвер, който се зарежда при зареждане. Контейнерите обикновено се зареждат от надеждно хранилище, само за четене, и те могат да бъдат допълнително защитени с криптографски проверки.

Сега нека разгледаме какво се случва по време на нарушение.

Защита срещу пробиви

Обикновено атакуващите имат една или две цели при проникване в сървърна система. Те искат да получат данни или да нанесат щети.

Ако търсят данни, те искат да проникнат във възможно най-много системи с възможно най-високите привилегии и да поддържат този достъп възможно най-дълго. Постигането на това им дава време да намерят данните, които може би вече са налице - например лошо защитена база данни - или може да се наложи бавно събиране с течение на времето, когато се стича, като например събиране на транзакции, когато идват от потребителите. Поддържането на достъп за дълго време изисква стелт. Атаката изисква и начин за извличане на данните.

Ако нападателят се опитва просто да нанесе щети, целта отново е достъп до колкото се може повече системи и привилегии. Но има балансиращ акт: След като повредата започне, вероятно ще бъде забелязана, но колкото по-дълго атакуващият чака да стартира (докато зловредният софтуер филтрира от система към система), толкова по-голям е шансът да бъде открит. Извличането на данни е по-малко важно от координирания контрол на зловредния софтуер. Идеята е да се заразят възможно най-много системи, след което да се повредят в синхронизирана точка, предварително подредена или по команда.

Нарушенията включват редица елементи. Нека да разгледаме всяка от тях и да видим дали виртуалните машини и контейнерните архитектури могат да повлияят на повърхността за атака за всяка.