През 2010 година компанията имаше 50 сървъра и проста мрежова модел: бекенд, фронтенд и фаервол. Броят на сървърите нарастваше, моделът се усложняваше: стейджинги, изолирани VLAN с ACL, след това VPN с VRF, VLAN с ACL на L2, VRF с ACL на L3. Завъртя ли се главата? По-нататък ще бъде още по-интересно.
Когато сървърите станаха 16 000, работата с толкова много хетерогенни сегменти стана невъзможна. Затова измислихме друго решение. Взехме стека Netfilter, добавихме към него Consul като източник на данни, и получихме бърз разпределен фаервол. С него заменихме ACL на рутерите и го използвахме както за външен, така и за вътрешен фаервол. За динамично управление на инструмента разработихме системата BEFW, която приложихме навсякъде: от управление на достъпа на потребителите до продуктовата мрежа до изолацията на мрежовите сегменти един от друг.
Как всичко това работи и защо трябва да обърнете внимание на тази система, ще разкаже Иван Агарков () — ръководител на група инфраструктурна сигурност в подразделението Maintenance в Минския център за разработка на компанията. Иван е фен на SELinux, обича Perl, пише код. Като ръководител на група ИБ, редовно работи с логове, бекъпи и R&D, за да защитава Wargaming от хакери и да осигурява работата на всичките игрови сървъри в компанията.
Историческа справка
Преди да разкажа как го направихме, ще разкажа как изобщо стигнахме до това и защо беше необходимо. За това ще се пренесем 9 години назад: 2010 година, когато едва започнаха World of Tanks. Компанията Wargaming имаше около 50 сървъра.
Графика на растежа на сървърите на компанията.
Имахме мрежова модел. За времето тогава тя беше оптимална.
Мрежова модел през 2010.
На фронтенда живеят лошите момчета, които искат да ни разрушат, но там има фаервол. На бекенда фаервол няма, но там са 50 сървъра, ние всички ги знаем. Всичко работи добре.
За 4 години броят на сървърите нарасна 100 пъти, до 5000. Появиха се първите изолирани мрежи — стейджинги: те не могат да се свържат с продукцията, а там често се случваше да се върти нещо, което може да бъде опасно.
Мрежова модел през 2014.
По инерция използвахме същите устройства и цялата работа се извършваше на изолирани VLAN: на VLAN се пишат ACL, които разрешават или забраняват определена връзка.
През 2016 година броят на сървърите достигна 8000. Wargaming пое други студиа, появиха се допълнителни партньорски мрежи. Те изглеждат наши, но не съвсем: за партньорите VLAN често не работи, трябва да се използва VPN с VRF, изолацията се усложнява. Смесицата от изолации ACL нарасна.
Мрежов модел през 2016.
В началото на 2018 година паркът от машини нарасна до 16000. Имаше 6 сегмента, а останалите не ги брояхме, включително затворените, в които се съхраняваха финансови данни. Появиха се контейнерни мрежи (Kubernetes), DevOps, облачни мрежи, свързани чрез VPN, например от ИВС. Правилата бяха много — беше болезнено.
Мрежов модел и методи на изолация през 2018.
За изолация използвахме: VLAN с ACL на L2, VRF с ACL на L3, VPN и много други неща. Прекалено много.
Проблеми
Всички живеят с ACL и VLAN. Какво не е наред? На този въпрос ще отговори Харолд, скриващ болката.
Имаше много проблеми, но масови — пет.
- Геометричен растеж на цената за новите правила. Всяко ново правило се добавяше по-дълго от предишното, защото първо трябваше да се провери дали вече не съществува такова правило.
- Няма защитна стена в сегментите. Сегментите са отделени помежду си, но вътре вече няма достатъчно ресурси.
- Правилата се прилагаха дълго. С ръка едно локално правило операторите можеха да напишат за час. Глобално отнемаше няколко дни.
- Трудности с одита на правилата. По-точно, той беше невъзможен. Първите правила бяха написани още през 2010 година и голяма част от авторите им вече не работеха в компанията.
- Нисък контрол върху инфраструктурата. Това е основния проблем — бяхме слабо информирани за това, което наистина се случва.
Така изглеждаше мрежовият инженер през 2018 година, когато чу: „Нужни са още малко ACL“.
Решения
В началото на 2018 година беше решено нещо да се направи по този въпрос.
Цената на интеграциите непрекъснато нараства. Отправната точка стана това, че големите датацентрове спряха да поддържат изолирани VLAN и ACL, защото паметта на устройствата свърши.
Решение: премахнахме човешкия фактор и максимално автоматизирахме предоставянето на достъп.
Новите правила се прилагат дълго. Решение: да се ускори приложението на правилата, да стане разпределено и паралелно. За това е необходима разпределена система, за да се доставят правилата сами, без rsync или SFTP на хиляда системи.
Липса на защитна стена вътре в сегментите. Файрволът в сегментите започна да ни пречи, когато в рамките на една и съща мрежа се появиха различни услуги. Решение: да използваме защитна стена на ниво хост — host-based firewalls. Практически навсякъде имаме Linux, и навсякъде има iptables, това не е проблем.
Трудности с одита на правилата. Решение: да съхраняваме всички правила на едно място за преглед и управление, така ще можем да извършваме одит на всичко.
Ниско ниво на контрол над инфраструктурата. Решение: да извършим инвентаризация на всички услуги и достъпи между тях.
Това е повече административен процес, отколкото технически. Понякога имаме 200-300 нови релиза на седмица, особено по време на промоции и празници. Това е само за един екип от нашите DevOps. С такова количество релиза е невъзможно да се видят и разберат нужните портове, IP адреси и интеграции. Затова ни трябваха специално обучени мениджъри на услуги, които да разпитват екипите: "Какво има изобщо и защо сте го създали?"
След всичко, което стартирахме, мрежовият инженер през 2019 година вече изглеждаше така.
Consul
Решихме, че всичко, което намерихме с помощта на мениджърите на услуги, ще поставим в Consul и оттам ще пишем правилата за iptables.
Как решихме да го направим?
- Съберем всички услуги, мрежи и потребители.
- Ще формулираме на тяхна основа правила за iptables.
- Автоматизираме контрола.
- ….
- ПЕЧАЛБА.
Consul не е отдалечен API, той може да работи на всеки възел и да записва в iptables. Остава само да измислим автоматични средства за контрол, които ще почистват ненужното, и голяма част от проблемите ще се решат! Останалото ще доработим в процеса.
Защо Consul?
Доказано е, че е надежден. През 2014-15 година го използвахме като бекенд за Vault, където съхраняваме пароли.
Не губи данни. По време на използването на Consul не е загубил данни нито веднъж по време на авария. Това е огромно предимство за системата за управление на защитната стена.
P2P свързванията ускоряват разпространението на промени. При P2P всички промени пристигат бързо, не е нужно да чакаме с часове.
Удобен REST API. Също така разглеждахме Apache ZooKeeper, но той няма REST API, ще трябва да поставим временни решения.
Работи както като хранилище на ключове (KV), така и като каталог (Service Discovery). Може да съхранява буквално услуги, каталози, дата-центрове. Това е удобно не само за нас, но и за съседните екипи, тъй като създаването на глобална услуга ни кара да мислим мащабно.
Написан е на Go, който е част от стека на Wargaming. Ние обожаваме този език, имаме много Go разработчици.
Мощна система ACL. С помощта на ACL в Consul можем да управляваме кой и какво може да пише. Гарантираме, че правилата на защитната стена няма да се пресекат с нищо и няма да изпитваме проблеми с това.
Но Consul има и недостатъци.
- Не мащабира в рамките на дата центъра, ако нямате бизнес версия. Той се мащабира само чрез федерация.
- Много е зависим от качеството на мрежата и натоварването на сървърите. Consul не работи правилно като сървър на натоварен сървър, ако в мрежата има забавяния, например, неравномерна скорост. Свързано е с P2P свързванията и моделите за разпространение на актуализации.
- Трудности с мониторинга на наличността. В статуса на Consul може да показва, че всичко е наред, а той вече е спрял.
Голяма част от тези проблеми решихме в процеса на експлоатация на Consul, затова и го избрахме. В компанията има планове за алтернативен бекенд, но научихме се да се справяме с проблемите и все още живеем с Consul.
Как работи Consul
В условен дата център инсталираме сървъри - от три до пет. Един или два сървъра не са подходящи: те няма да могат да организират кворум и да решат кой е прав, кой не, когато данните не съвпадат. Повече от пет няма смисъл, производителността ще спадне.
Към сървърите в произволен ред се свързват клиентите: същите агенти, само с флаг server = false.
След това клиентите получават списък с P2P свързвания и изграждат връзки помежду си.
На глобално ниво свързваме няколко дата центъра помежду си. Те също се свързват P2P и общуват.
Когато искаме да получим данни от друг дата център, заявката преминава от сървър към сървър. Тази схема се нарича протокол на Serf. Протоколът Serf, както и Consul, е разработка на HashiCorp.
Няколко важни факта за Consul
Consul има документация, описваща работата му. Ще изброя само избрани факти, които си струва да знаете.
Сървърите на Consul избират майстор от гласуващите. Consul избира майстор от списъка със сървъри за всеки дата център, и всички искания отиват само при него, независимо от броя на сървърите. Засядането на майстора не води до повторни избори. Ако майстор не е избран, исканията няма да бъдат обслужвани.
Искали ли сте хоризонтално мащабиране? Съжалявам, не.
Запитът към другия дата-център минава от майстор към майстор, независимо на кой сървър е дошъл. Избраният майстор получава 100% натоварване, освен натоварването от пренасочването на запитванията. Актуалната копия на данните е налична на всички сървъри в дата-центъра, но само един отговаря.
Единственият начин за мащабиране е да се включи режим stale на клиента.
В режима stale е възможно да се отговаря без кворум. Това е режим, в който се отказваме от последователността на данните, но четем малко по-бързо от обикновено, и всеки сървър може да отговаря. Разбира се, записването е само през майстора.
Consul не копира данни между дата-центровете.При събиране на федерация всеки сървър ще има само своите данни. За другите той винаги се обръща към някой друг.
Атомарността на операциите не е гарантирана извън транзакция.Запомнете, че не само вие можете да променяте нещо. Ако искате по различен начин, провеждайте транзакцията с блокировка.
Блокиращите операции не гарантират блокировка.Запитването отива от майстор към майстор, а не директно, затова няма гаранции, че блокировката ще работи когато правите блокировка, например, в друг дата-център.
ACL също не гарантира достъп (в много случаи).ACL може да не сработи, защото се съхранява в един дата-център на федерацията — в дата-центъра на ACL (Primary DC). Ако дата-центърът не ви отговори, ACL няма да работи.
Един зависнал майстор ще доведе до зависване на цялата федерация.Например, в федерация с 10 дата-центъра, а в един лоша мрежа, един майстор пада. Всички, които комуникират с него, ще се зависнат: запитване, няма отговор, нишката засяда. Не можете да разберете кога ще се случи, просто след час или два цялата федерация ще падне. Нищо не можете да направите по въпроса.
Статусът, кворумът и изборите се обработват от отделен поток. Повторни избори няма да се случат, статусът няма да покаже нищо. Вие мислите, че имате жив Consul, искате запитване, и нищо не се случва — няма отговор. В същото време статусът показва, че всичко е наред.
Срещали сме тази проблема, е трябвало да преизграждаме конкретни части от дата-центровете, за да я избегнем.
В бизнес версията Consul Enterprise няма някои от недостатъците, споменати по-горе.. В него има много полезни функции: избор на гласуващи, разпределение, мащабиране. Има само едно "но" — системата за лицензиране на разпределена система е много скъпа.
Лайфхак: rm -rf /var/lib/consul — лекарството за всички болести на агента. Ако нещо не работи, просто изтрийте данните си и заредете данни от копие. Най-вероятно, Consul ще заработи.
BEFW
Сега да поговорим за това, което добавихме към Consul.
— това е акроним от БackEndFireWall. Трябваше да назова продукта по някакъв начин, когато създавах репозитория, за да вмъкна първите тестови комити. Такова име и остана.
Шаблони за правила
Правилата са написани в синтаксиса на iptables.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -i lo -j ACCEPT
- -A INPUT -j BEFW
Всичко при нас отива в веригата BEFW, освен ESTABLISHED, RELATED и localhost. Шаблонът може да бъде какъвто и да е, това е само пример.
Каква полза има от BEFW?
Услуги
Имаме услуга, в която винаги има порт, възел, на който работи. От своя възел можем локално да питаме агента и да разберем, че имаме някаква услуга. Също така може да се поставят тагове.
Всяка услуга, която е стартирана и регистрирана в Consul, се превръща в правило iptables. Имаме SSH — отваряме порт 22. Bash-скриптът е прост: curl и iptables, повече нищо не е нужно.
Клиенти
Как да отворим достъп не на всички, а избирателно? По име на услугата да се събира в KV-склад IP-списъци.
Например, искаме да позволим на всички от десета мрежа да имат достъп до услугата SSH_TCP_22. Добавяме едно малко поле TTL? и сега имаме времени разрешения, например, за един ден.
Достъпи
Свързваме услуги и клиенти: имаме услуга, за всяка е готов KV-склад. Сега даваме достъп не на всички, а избирателно.
Групи
Ако всеки път пишем хиляди IP за достъпи, ще се уморим. Ще измислим групировки — отделен подгрупа в KV. Нека го наречем Alias (или групи) и ще съхраняваме там групи по същия принцип.
Свързваме: сега можем да отворим SSH не конкретно на P2P, а на цяла група или няколко групи. По същия начин има TTL — можем да добавяме в група и да премахваме от група временно.
Интеграция
Нашият проблем е човешкият фактор и автоматизацията. Засега го решихме така.
Работим с Puppet и переносим туда все, что связано с системой (код приложений). В puppetdb (обычный PostgreSQL) хранится список сервисов, которые запущены, и их можно найти по типу ресурса. Там же видно, кто куда обращается. У нас также есть система pull request и merge request для этого.
Мы разработали befw-sync — простейшее решение для переноса данных. Сначала sync cookies обращаются к puppetdb. Там настроен HTTP API: запрашиваем, какие сервисы у нас есть и что нужно сделать. Затем делаем запрос в Consul.
Интеграция есть? Есть: мы написали правила, разрешили принимать Pull Request. Нужен какой-то порт или нужно добавить хост в определённую группу? Pull Request, ревью — больше никаких "Найди 200 других ACL и попробуй что-нибудь с этим сделать."
Оптимизация
Пинг localhost с пустой цепочкой правил занимает 0,075 мс.
Добавим в цепочку 10 000 адресов iptables. В результате пинг увеличится в 5 раз: iptables полностью линейный, обработка каждого адреса занимает какое-то время.
Для файрвола, в который мы мигрируем тысячи ACL, у нас много правил, и это вызывает задержку. Для игровых протоколов это плохо.
Но если мы поместим 10 000 адресов в ipset, пинг даже уменьшится.
Смысл в том, что "O" (сложность алгоритма) для ipset всегда равно 1, вне зависимости от количества правил. Хотя есть ограничение — правил не может быть больше 65535. На данный момент живём с этим: можно их комбинировать, расширять, делать два ipset в одном.
Хранение
Логичное продолжение процесса итераций — хранение информации о клиентах для сервиса в ipset.
Теперь у нас есть тот же самый SSH, и мы не пишем сразу 100 IP, а задаем имя ipset, с которым нужно поработать, и следующее правило DROP. Можно переделать в одно правило "Кто не тут, тот DROP", но так наглядней.
Теперь у нас есть правила и сеты. Основная задача — создать сет до написания правила, потому что иначе iptables не запишет правило.
Общая схема
В виде схемы всё, что я рассказал, выглядит так.
Коммитим в Puppet, всё отправляется на хост, сервисы здесь, ipset там, а кто не прописан — того не пускают.
Permit & deny
Чтобы быстро реагировать на ситуации или отключать кого-то, в начале всех цепочек мы создали два ipset: rules_allow и rules_deny. Как это работает?
Например, някой генерира натоварване на нашия уебсайт с ботове. Преди трябваше да намерим IP адреса му по логовете, да го предоставим на мрежовите инженери, за да намерят източника на трафика и да го блокират. Сега е различно.
Изпращаме до Consul, чакаме 2.5 секунди и е готово. Понеже Consul бързо разпределя с P2P, той работи навсякъде, във всяка част на света.
Веднъж напълно спрях WOT, като сбърках с фаервола. rules_allow — това е нашата застраховка от подобни ситуации. Ако сгрешим с фаервола и нещо бъде блокирано, винаги можем да изпратим условно 0.0/0, за да възстановим всичко бързо. После можем да поправим всичко на ръка.
Други комплекти
Можем да добавяме всякакви други комплекти в пространството $IPSETS$.
Защо? Понякога на някой му трябват ipset, например, за да еймулира деактивирането на някоя част от кластера. Всеки може да донесе всякакви комплекти, да ги наименува и те ще бъдат взимани от Consul. Комплектите могат както да участват в правилата iptables, така и да бъдат просто команда NOOP: последователността ще бъде поддържана от демона.
Потребители
Преди беше така: потребителят се свързваше с мрежата и получаваше параметри чрез домейн. До появата на ново поколение фаерволи Cisco не можеше да разбере къде е потребителят, а къде IP адрес. Поради това достъпът се предоставяше само чрез hostname на машината.
Какво направихме ние? Включихме се в момента на получаване на адреса. Обикновено това е dot1x, Wi-Fi или VPN — всичко минава през RADIUS. За всеки потребител създаваме група по име и я поставяме с IP с TTL, равен на неговия dhcp.lease — щом изтече, правилото изчезва.
Сега можем да отворим достъп до услуги, както и в други групи, по username. Освободихме се от проблема с hostname, когато те се променят, и облекчихме натоварването на мрежовите инженери, тъй като им повече не им е нужно Cisco. Сега инженерите сами задават достъпите на своите сървъри.
Изолация
Паралелно започнахме да разглеждаме изолацията. Мениджърите на услугите направиха инвентаризация, а ние анализирахме всичките ни мрежи. Разделяме ги на подобни групи, а на нужните сървъри добавихме групи, например в deny. Сега същата изолация на стейджинг попада в rules_deny на продукцията, но не и в самата продукция.
Схемата работи бързо и лесно: отстраняваме всички ACL от сървърите, облекчаваме оборудването, намаляваме количеството изолирани VLAN.
Контрол на целостта
Преди имахме специален тригер, който сигнализираше, когато някой промени правилото на защитната стена. Написах огромен линтер за проверка на правилата на защитната стена, което беше трудно. Сега целостта се контролира от BEFW. Той наблюдава строго, за да се увери, че правилата, които създава, не се променят. Ако някой промени правилата на защитната стена, той ще възстанови всичко обратно. „Бързо създадох прокси, за да работя от вкъщи“ — такива опции вече няма.
BEFW контролира ipset от услугите и списъка в befw.conf, правилата на услугите в веригата на BEFW. Но не следи за други вериги и правила и други ipset.
Защита от аварии
BEFW винаги запазва последното успешно състояние директно в бинарната структура state.bin. Ако нещо се обърка, той винаги се върти назад на този state.bin.
Това е застраховка срещу нестабилна работа на Consul, когато не е изпратил данни или някой е направил грешка и е използвал правила, които не могат да бъдат приложени. За да не останем без защитна стена, BEFW ще се върне към последното си състояние, ако в някакъв момент възникне грешка.
В критични ситуации това е гаранция, че ще останем с работеща защитна стена. Отваряме всички сиви мрежи в надеждата, че администраторът ще дойде и ще поправи. Някога ще го включа в конфигурациите, но в момента имаме просто три сиви мрежи: 10/8, 172/12 и 192.168/16. В рамките на нашия Consul това е важна характеристика, която помага да се развиваме напред.
Демо: по време на доклада Иван демонстрира демо-режима на BEFW. Демонстрацията е по-удобна за гледане на . Изходният код на демото е достъпен .
Подводни камъни
Ще разкажа за бъговете, с които се сблъскахме.
ipset add set 0.0.0.0/0. Какво ще се случи, ако добавим в ipset 0.0.0.0/0? Ще се добавят всички IP? Ще се отвори достъп до интернет?
Не, ще получим бъг, който ни струва два часа престой. И забележете, бъгът не работи от 2016 година, лежи в RedHat Bugzilla под номер #1297092, а го открихме случайно — от отчета на разработчика.
Сега в BEFW има строго правило, че 0.0.0.0/0 се превръща в два адреса: 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < file. Какво прави ipset, когато му кажете restore? Вы думаете, он работает также, как iptables? Восстановит данные?
Нищо подобно — той прави сливане, и старите адреси никъде не изчезват, достъпът не се затваря.
Открихме бъга, когато тестваме изолацията. Сега там има доста сложна система — вместо restore се провежда create temp, после restore flush temp и restore temp. В края накрая swap: за атомарност, тъй като ако първо извършите flush И в този момент, ако дойде някакъв пакет, той ще бъде отхвърлен и нещо ще се обърка. Затова там има малко черна магия.
consul kv get -datacenter=other. Както вече споменах, смятаме, че запитваме за някакви данни, но ще получим или данни, или грешка. Можем да направим това чрез Consul локално, но дори и тогава и двете ще замръзнат.
Локалният Consul клиент е обвивка около HTTP API. Но просто замръзва и не отговаря нито на Ctrl+C, нито на Ctrl+Z, ни на нищо, само на kill -9 в съседния терминал. С това се сблъскахме, когато изграждахме голям клъстер. Но засега нямаме решение, подготвяме се за корекция на тази грешка в Consul.
Consul лидерът не отговаря. Мастърът в дата центъра не отговаря, мислим: "Вероятно сега алгоритъмът за повторно избиране ще заработи?"
Не, няма да заработи, и мониторингът нищо не ще покаже: Consul ще каже, че commitment index е наличен, лидер е намерен, всичко е добре.
Как се справяме с това? service consul restart в cron всеки час. Ако имате 50 сървъра — не е страшно. Когато станат 16 000, ще разберете как работи.
Заключение
В крайна сметка получихме следните предимства:
- 100% покритие на всички Linux машини.
- Скорост.
- Автоматизация.
- Освободихме хардуера и мрежовите инженери от робството.
- Появиха се възможности за интеграции, които са практически безгранични: било с Kubernetes, било с Ansible, било с Python.
Недостатъци: Consul, с който сега живеем, и много висока цена на грешката. Например, веднъж в 6 вечерта (пик в Русия) правех нещо в мрежовите списъци. Тогава изграждахме изолация на BEFW. Някъде сбърках, изглежда, посочих не онзи маска, но всичко падна за две секунди. Запалва се мониторинга, идва дежурният от поддръжка: "Всичко при нас е паднало!" Началникът на отдела посивя, когато обясняваше на бизнеса защо се е случило така.
Цената на грешката е толкова висока, че измислихме собствена сложна процедура за профилактика. Ако ще прилагате това в голямо производство, не давайте master token на Consul на всеки. Това ще завърши зле.
Разходи. Написах код 400 часа сам. За поддръжка моят екип от 4 души отделя 10 часа на месец за всички. В сравнение с цената на всеки ново поколение firewall, това е безплатно.
Планове. Дългосрочният план е да се търсят алтернативни транспортни средства вместо или допълнително към Consul. Возможно, това ще бъде Kafka или нещо подобно. Но през ближайшите години ще живеем с Consul.
Ближайшите планове: интеграция с Fail2ban, мониторинг, nftables, възможно, с други дистрибуции, метрики, разширен мониторинг, оптимизация. Поддръжката на Kubernetes също е в плановете, тъй като в момента разполагаме с няколко клъстера и желание.
Още от плановете:
- търсене на аномалии в трафика;
- управление на мрежовата карта;
- поддръжка на Kubernetes;
- сглобяване на пакети за всички системи;
- Web-UI.
Постоянно работим над разширяване на конфигурацията, увеличаване на метриките и оптимизация.
Присъединете се към проекта. Проектът се получи страхотно, но, за съжаление, засега е проект на един човек. Елате на и опитайте да направите нещо: да закомитите, да тествате, да предложите нещо, да дадете своето мнение.
В същото време се подготвяме за , който ще се проведе на 6 и 7 април в Санкт Петербург, и каним разработчици на високо натоварени системи . Опитни лектори така или иначе знаят какво да правят, а на начинаещите в изказванията препоръчваме поне . Участието в конференцията като лектор има редица предимства. Какви, можете да прочетете, например, в края на .
Източник: habr.com
