Ви дізнаєтесь. як влаштована it-інфраструктура.
298 
Розповідається про поділ інфраструктури на зони з точки зору інформаційної безпеки в GNU/Linux. Обговорюється важливість відокремлення систем, що доступні з інтернету, до окремої зони, званої DMZ (демілітаризована зона), для зниження ризику поширення вразливостей. Подано технічні рекомендації щодо налаштування зон та використання засобів Linux для цих цілей.
Перш ніж почнемо, варто згадати, що ми вирішили замість VirtualBox-а використовувати Qemu. Не тому що Virtualbox чимось поганий, просто у GNS є функціонал снапшотів, коли він може зберегти стан всієї топології, в тому числі віртуалок. Але це працює тільки з Qemu. Мені цей функціонал потрібний для запису курсу, а вам він у принципі не обов’язковий, тому можете продовжувати використовувати віртуалбокс.
Самі віртуалки потрібно створювати у GNS. Це робиться приблизно там же, де ми пов’язували VirtualBox та GNS: Edit – Preferences – Qemu VMs.
Попередньо перетворив образ дисків VDI від VirtualBox на qcow2, який потрібний для Qemu і поклав у потрібну директорію.
За налаштуваннями віртуалки, було виділено всього 512 мегабайт оперативної пам’яті. Для підключення до консолі використовуватиму vnc, це все робиться через GNS, без необхідності щось змінювати в самій віртуалці.
У вкладці Network все також виділив віртуалці чотири мережеві адаптери.
Ну і у вкладці Advanced потрібно переконатися, що стоїть галочка “Use as a linked base VM”, щоб ми простим перетягуванням створювали нові віртуалки.
Для підключення до консолі віртуалки потрібно натиснути правою кнопкою миші на ній і вибрати Console. Для цього в системі має бути якийсь VNC клієнт.
Ну і врахуйте, що тут імена мережевих інтерфейсів будуть відрізнятися, але ви завжди можете дізнатися їх з висновку команди:
ip a
І за вимкнених віртуалках тепер можна робити снапшоти всієї топології. Якщо ви чомусь теж вирішили перейти на Qemu і у вас щось не вийшло, напишіть, розберемося. Це був невеликий вступ, тепер перейдемо до самої теми.
Минулого разу ми створили jumphost, через який ми можемо логінитися на внутрішні машинки з інтернету. На сам jumphost ми можемо потрапити безпосередньо з інтернету, тому що на роутері ми прокинули порт. Через те, що це не дуже безпечно, ми вжили якихось заходів безпеки – використовували нестандартний порт, відключили аутентифікацію по паролях і заборонили руту логінуватися. Але уявіть, що у SSH є якась вразливість, про яку поки що ніхто не знає – вразливість нульового дня. Умовно вона дозволяє зайти на сервер навіть не знаючи логіна і пароля. І ось якісь злодії знайшли її і спробували зламати наш jumphost, через який вони зможуть потрапити на інші наші сервери. За певних умов нас міг би врятувати selinux, але з якихось причин це не сталося. І ось зломщики отримали доступ на джамп хост, просканували мережу та побачили всі наші сервери, які вони далі ламатимуть.
Тому, будуючи систему захисту, з одного боку, потрібно намагатися зробити її невразливою, з іншого – розуміти, що це неможливо. А значить думати про наступний крок – «нас уже зламали». Що далі? Потрібно пом’якшити шкоду. В інфобез це називається «mitigation». Якщо хтось потрапив однією сервер – зробіть те щоб він із цього сервера було потрапити інші. Якщо зламають одну систему – зробіть так, щоб це не поширилось на інші. Потрапив у вашу мережу шифрувальник, зашифрував якісь сервери – потрібно зробити так, щоб це не торкнулося інших, щоб не перекинулося в інші мережі.
Чим сильніше ви ускладните хакерам роботу, чим більше усіляких перешкод ви їм поставите – тим складніше їм буде дістатися важливих даних. А поки вони з усім цим возитимуться, можливо, ви встигнете щось помітити та зреагувати.
Загалом, повертаючись до джамп-хосту. Він у нас доступний з інтернету та один із перших претендентів на злом. А отже, його треба якось відокремити від інших систем. Ми говорили про ізоляцію на рівні вланів та підмереж, а з погляду інформаційної безпеки вводиться ще одне поняття – зони. Ми вже знайомі з цим поняттям завдяки файрволу – firewalld у нас zone-based firewall. Так ось, зона – це більший логічний поділ, одна зона може складатися як з однієї волана з однією підмережею, так і з безлічі ланів і підмереж.
Наприклад, ми можемо для кожної аудиторії в універі виділити окремий лан з окремою підмережею. Але з погляду зон – всі аудиторії перебувають у одній зоні, оскільки за рівнем доступу студенти однієї зони аудиторії нічим не від студентів іншої аудиторії. Тобто. поділ по зонах – це в основному доступи. Скажімо, студентам можна на такі сервери – значить усі студенти в одній зоні, сервери в іншій – і ми пишемо правила, що зоні «студенти» дозволений доступ до зони «сервера для студентів» по порту 80. Насправді зазвичай налаштовується більше гранулярний доступ, мовляв, на ці сервери по 80 порту, а на ці по 443 на ці взагалі не можна і т.п. Загалом усе починається із зон, але ними не обмежується.
Так ось, системи, які доступні з інтернету, з точки зору безпеки відокремлюють в одну зону, яка називається DMZ – демілітаризована зона. Зазвичай тут знаходяться вебсервера, джамп хости та інші системи, до яких найменше довіри. Чим сильніше ми ізолюємо цю зону, чим менше доступів ми дамо з цієї зони – тим краще. Зрозуміло, що джамп хост на те і джамп хост, що ми з нього повинні мати можливість потрапити на інші сервери.
Але, припустимо, ми можемо дозволити джампхосту підключатися лише до одного сервера у внутрішній зоні. І використовувати цей сервер як другий джампхост, у якого вже буде доступ до інших систем. Це скоротить площу атак.
У нашій схемі окрім джампхосту в інтернет дивиться ще один пристрій – роутер1. Так, ми його убезпечили, туди не можна потрапити з інтернету, ми навіть можемо заборонити доступ із джампхосту та заборонити пінги. Проте він підключений в інтернет, як мінімум, його можуть вивести з ладу DDOS атакою. Та й шанс злому, хоч і мізерний, ніколи не варто виключати. І якщо наш роутер вийде з ладу, або почне гальмувати – ляже вся наша мережа, користувачі не зможуть заходити на сервери, а сервери не зможуть обмінюватися даними для роботи. Пофіг на інтернет, але порушення внутрішньої роботи мережі – у середній чи великій компанії велика проблема.
Тому внутрішня мережа розташовується на іншому роутері. Давайте трохи змінимо нашу мережу. router1 у нас буде зовнішнім роутером, що дивиться в інтернет. З нього буде прокидання портів на різні сервіси, які мають бути доступні в інтернеті, наприклад, на джампхост. Поки що для DMZ відокремимо другий влан. Роутеру також потрібен інший влан, наприклад, влан1, щоб він міг спілкуватися з внутрішнім роутером. Його ми назвемо router3. Він уже пов’язуватиме внутрішню мережу – користувачів, внутрішні сервери та інше. На ньому нам потрібен перший влан, щоб спілкуватися з роутером1, а також 3 і 4 влани для користувачів та серверів відповідно. Надалі можливо будуть додаткові зони, але поки що цього достатньо.
Оскільки тепер наші роутери не лише пов’язуватимуть підмережі, а й розділятимуть мережу на зони, тобто. виступати мережевими файрволами, для автентичності поміняємо іконку у роутерів. Так як тепер на джампхост і юзер1 приходить тільки один влан, на свитчах в їхній бік налаштуємо нетеговані лани, і тільки до роутерів і серверу будемо використовувати транки. Пропустимо етап налаштування адрес та вланів, тому що ми це робили раніше, а для вас це буде невеликим завданням на повторення. Проте з маршрутизацією початківцям може бути складно, тож це покажу.
Для початку підключимося у внутрішню мережу. Запускаємо ssh agent:
eval $(ssh-agent)
І додаємо ключі:
ssh-add .ssh/jumphost .ssh/servers
Далі підключаємося до роутера:
ssh router1
Для початку подивимося дефолтну зону на файрволі:
sudo firewall-cmd --list-all
Зараз у нас інтерфейси, які дивляться в різні влади – team0 та team0.2 – знаходяться в одній зоні.
team0.2 – це інтерфейс, який дивиться у другий лан – а він у нас для DMZ. Тому варто перенести цей інтерфейс до іншої зони. На файрволі вже є зона з такою назвою, тому одразу перемістимо до цієї зони:
sudo firewall-cmd --change-interface=team0.2 --zone=dmz --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=dmz
Інтерфейс перемістився в цю зону, але, як бачите, є сервіс ssh.
Це означає, що з DMZ зони можна буде підключитися по ssh до роутера. Оскільки ми не дуже довіряємо DMZ, то краще прибрати цю можливість:
sudo firewall-cmd --remove-service=ssh --zone=dmz --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=dmz
Це не вплине на поточне підключення, але більше з джампхосту ми не зможемо зайти на роутер.
Тепер подивимося маршрути:
ip ro sh
Роутер 1 знає про мережі 1.0 та 2.0. І все невідоме він надсилає в інтернет через провайдера. Але за роутером 3 у нас є ще 3 мережі – 3.0, 4.0 та 5.0. Якщо якийсь пакет прийде з мережі 3.0 на роутер1, то роутер 1 відповідь надсилатиме на свій default gateway.
Нас це не влаштовує, ми хочемо, щоб для відповіді у 3, 4 та 5 мережі роутер1 звертався до роутера 3. І ось для цього нам потрібні статичні маршрути. Умовно ми повинні сказати роутеру1, що мережа 10.0.4.0 знаходиться за роутером3. Адреса роутера3 для першого роутера – 10.0.1.254.
Тому на роутері1 прописуємо статичні маршрути:
sudo nmcli connection modify team +ipv4.routes "10.0.3.0/24 10.0.1.254"
sudo nmcli connection modify team +ipv4.routes "10.0.4.0/24 10.0.1.254"
sudo nmcli connection modify team +ipv4.routes "10.0.5.0/24 10.0.1.254"
Ми через nmcli додаємо статичний маршрут, у якому пишемо, що мережі 3.0, 4.0 та 5.0 знаходяться за адресою 10.0.1.254. Після змін піднімаємо інтерфейс, щоб він застосував налаштування:
nmcli con up team
Ну і перевіримо таблицю маршрутизації:
ip ro sh
Тепер у нас є додаткові маршрути. Без них роутер1 не зміг би відповісти серверам у цих вланах, а отже, як мінімум, у них не було б інтернету.
Що стосується роутера3:
ssh 10.0.1.254
То тут у нас два тимінг інтерфейсу по 2 слейви:
nmcli con sh
Один інтерфейс – team0 – дивимося у бік першого роутера, другий – team1 – дивиться у внутрішню мережу, там де користувачі та сервери. На другому тимінг інтерфейсі ми створюємо владу 3, 4 і 5.
Що стосується маршрутів:
ip ro sh
То тут все набагато простіше. Тут default gateway є роутер1. І так вся внутрішня мережа підключена до цього роутера, а якщо він щось не знає – скажімо, інтернет адреси, то він пошле на перший роутер, а той уже в інтернет.
Що стосується поділу на зони, то тут у нас 4 зони:
sudo firewall-cmd --list-all
По-перше – team0 – він у нас дивиться у бік першого роутера.
По-друге – влада 3, 4 і 5 – для кожного з них ми виділимо окрему зону.
Можна було б використовувати шаблонні зони, але краще створити свої з більш відповідними назвами:
sudo firewall-cmd --permanent --new-zone=routers
sudo firewall-cmd --permanent --new-zone=users
sudo firewall-cmd --permanent --new-zone=servers
sudo firewall-cmd --permanent --new-zone=management
routers – зона між першим та третім роутером
users – зона для локальних користувачів
servers – зона для серверів
management – зона для управління серверами. Про неї ми поговоримо трохи згодом.
Далі перемістимо інтерфейси у відповідні зони:
sudo firewall-cmd --permanent --change-interface=team0 --zone=routers
sudo firewall-cmd --permanent --change-interface=team1.3 --zone=users
sudo firewall-cmd --permanent --change-interface=team1.4 --zone=servers
sudo firewall-cmd --permanent --change-interface=team1.5 --zone=management
team0 у зону routers, team1.3 у зону users, team1.4 у зону servers і team1.5 у зону management.
Потім перезапустимо файрвол, щоб застосували налаштування:
sudo firewall-cmd --reload
Ну і можемо перевірити налаштування:
sudo firewall-cmd --list-all --zone=routers
Начебто зона є, інтерфейс у зоні і, за замовчуванням, жодних налаштувань, жодних сервісів у зоні. Отже ніхто з зони не зможе підрубатися до самого роутера.
Ви запитаєте – а як нам тоді керувати роутерами, якщо до них нізвідки підрубатися не можна? Тут уже у справу вступає management vlan.
Як ми говорили, у локальній мережі буває велика кількість різного обладнання – свитчі, роутери, сервери, стораджі тощо. Більшість цього устаткування є окремий виділений фізичний порт управління – management port. Ці порти призначені для адміністраторів – за допомогою них можна підключатися по веб-інтерфейсу, або по ssh і виконувати будь-які адміністративні завдання. Це дозволяє відокремити керуючу частину даних. Умовно, якщо хтось отримає доступ до віртуалки, він не зможе по мережі достукатися до сервера, через який можна отримати доступ над усіма віртуалками. З одного боку, весь адміністративний доступ до різних систем виноситься в одну влан – management vlan – що трохи сумнівно з точки зору безпеки. Але з іншого боку ми знаємо, що це єдиний шлях до адмінки – отже, в цю зону ми не пускаємо нікого зайвого, крім адміністраторів.
Найчастіше на обладнанні тільки 1 адміністративний порт, а значить його не підключиш до двох свитчів. Але зазвичай це не проблема – навіть якщо вийде з ладу свитч, це не вплине на користувачів – максимум адміни втратять доступ до управління. Плюс нерідко всі ці підключення тримають на окремому світчі – management switch. За хорошим на схемі повинені були роутер3 окремо підключити до цього світчу, світчі окремо, сервера окремо – але, світчі у нас тупі, а на роутері у мене не залишилося портів. Тому роутер3 підключатимимо через 5 влан, а сервер1 підключу через окремий адаптер, як і належить. Роутер1 і джампхост не підключатимемо до менеджменту свитчу, оскільки до них у нас найменше довіри.
Наприклад, у нас на роутер3 цілих 4 адреси в 4 мережах. А ми хочемо, щоб керувати ним можна було лише з менеджменту мережі. Для цього в налаштуваннях sshd – /etc/ssh/sshd_config – виставимо як ListenAddress тільки адресу з Management влада:
...
ListenAddress 10.0.5.1
...
І перезапустимо sshd:
sudo systemctl restart sshd
Для перевірки можемо підрубатися до себе. За адресою 4.1:
ssh 10.0.4.1
відразу бачимо помилку. А за адресою 5.1:
ssh 10.0.5.1
можна зрозуміти, що підключення працює.
Не забудемо в зоні management дозволити сервіс ssh:
sudo firewall-cmd --zone=management --add-servic=ssh --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=management
Ну і перезапустити файрвол. По-доброму варто прибрати з інших зон ssh, але все одно в інших зонах немає активних інтерфейсів з айпі адресою. А там де є – не дозволено ssh.
Тепер підрубаємося до сервера1:
ssh 10.0.4.101
Тут у нас є тимінг інтерфейс для 4 влана:
ip ro sh
А також 5 лан, підключений окремо через інтерфейс ens5.
Давайте і тут у sshd замінимо ListenAddress на адресу з влана5:
...
ListenAddress 10.0.5.101
...
і перезапустимо sshd:
sudo systemctl restart sshd
Ну і зробимо зміни на файрволі. По-перше, створимо нову зону management, перемістимо туди інтерфейс і дозволимо там ssh:
sudo firewall-cmd --new-zone=management --permanent
sudo firewall-cmd --change-interface=ens5 --zone=management --permanent
sudo firewall-cmd --add-service=ssh --zone=management --permanent
У цьому, з дефолтної зони, тобто. з public, приберемо ssh і перезапустимо firewall:
sudo firewall-cmd --remove-service=ssh --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-services
sudo firewall-cmd --list-interfaces
sudo firewall-cmd --list-services --zone=management
sudo firewall-cmd --list-interfaces --zone=management
Те, що ми зараз робимо на рівні віртуалки – не має сенсу. Але просто уявіть, що це фізичний сервер, у нього на одних фізичних портах ходять дані, а через виділений – management – ми керуємо. І те, що ми винесли ssh на окремий інтерфейс і файрволом налаштували до нього доступ – це лише умовність. Але і з цієї умовності можна винести щось корисне – принаймні ми вчимося працювати із зонами.
І так ми розділили нашу мережу на зони. Десь залишилися дрібниці, умовно, прибрати зайві сервіси та інтерфейси із зон на роутерах та кінцевих пристроях.
Всі наші з’єднання зараз тримаються завдяки тому, що зміни на файрволі не впливають на поточні сесії ssh. Якщо ми спробуємо знову підключитися:
ssh jumphost
хоч пінг і працюватиме:
ping 10.0.3.101
але ssh та будь-які інші з’єднання працювати не будуть:
ssh 10.0.3.101
Просто тому, що мережевий файрвол блокує трафік між зонами.
А ось як гранулярно дозволити трафік між зонами і як із джампхосту потрапити на сервер1 по ssh – поговоримо наступного разу. Інформації і так вийшло багато, схема стала комплекснішою, але нічого страшного в ній немає. Постарайтеся побудувати таку мережу, все має пінгувати одне одного, крім адреси 5.101. Чому так – розберемо наступного разу.
Давайте підіб’ємо підсумки. Сьогодні ми з вами поговорили про безпеку, торкнулися необхідності внутрішнього та зовнішнього файрволів, розділили нашу мережу на зони, створили DMZ та додали кілька ланів та підмереж.
298 
134 
98 
94 
105 
122 
109