Національний університет «Чернігівська політехніка»

Лабораторна робота № 4 (продовження ЛР №1 – №3)

Схема мережі:

Iptables. Налаштовуємо port forwarding для сервісів на vm1 та v2, що

знаходяться за NAT.

Зімітуємо, що S1 – якийсь клієнт з інтернету і він хоче підключитися до VM1 (той

клієнт, до якого немає ні маршруту, ні налаштований маскарад). Нехай це буде спроба
підключитися по ssh. SSH по дефолту висить на 22 порту, але якщо у нас таких серверів буде
більше 1, то як бути? Взагалі по-доброму щоб позбавитися найпростіших сканерів мережі, ssh
потрібно завжди прибирати з 22 порту. Скористаємося портом 30022, наприклад, щоб
звернутися по ssh до VM1.

Як це працює?
S1 відправляє пакет (s.ip=S1.ip, d.ip=R1.ip; s.port=N, d.port=30022) який прилітає на R1.
R1 Переглядає iptables та застосовує правило DNAT, та формує пакет (за нашим
правилом): (s.ip=S1.ip, d.ip=VM1.ip; s.port=N, d.port=22).
Переглядає таблицю маршрутизації та відправляє пакет vm1 через інтерфейс eth0.200.

VM1 у свою чергу приймає пакет, отримує data, та формує відповідь: (s.ip=VM1.ip,
d.ip=S1.ip; s.port=22, d.port=N).
R1 приймає пакет і відновлює вихідний s.ip, до якого спочатку звернувся s1:
(s.ip=R1.ip, d.ip=S1.ip; s.port=22, d.port=N).

Досягти цього можна так:

1
 Національний університет «Чернігівська політехніка»

Пробуємо підключитися:

2
 Національний університет «Чернігівська політехніка»

Отже ми навчилися надавати доступ до сервісів, розташованих на віртуальних машинах

за якимось роутером (інакше можна сказати — до віртуалок за NAT'ом — що саме найчастіше
і потрібно).

Iptables. Налаштовуємо security zones. Вивчаємо tcp сесії.

І останнє, що ми хотіли б розглянути в цьому занятті – tcp сесії та напрямок

встановлення цих сесій. Так, наприклад, розглянемо 2 сегменти: серверний та клієнтський.
Клієнт, наприклад, повинен мати можливість "сходити" в серверний сегмент до контролера
домену. А ось контролеру домену робити на клієнтській машині нічого. Таких прикладів
можна вигадати безліч і ситуації чому з одного сегмента мережі в інший ходити можна, а
навпаки ні — теж. Навіщо може це знадобитися? Наприклад, у нас є веб-сервер, який
«дивиться» в інтернет і ним «заволодів» зловмисник. З цього сервера він цілком може
спробувати постукати в корпоративну мережу. Однак, якщо заборонити встановлювати сесії
із цього сегмента — цього не станеться. Тобто. ми, принаймні, ускладнюємо зловмиснику
життя. Давайте додамо правило, яке заборонить ходити VM2 до VM1, а VM1 до VM2 можна.

Пробуємо ходити з VM1 на VM2:

3
 Національний університет «Чернігівська політехніка»

і у зворотний бік:

Чому так відбувається? У момент встановлення TCP-сесії прилітає пакет TCP SYN (на
нього відповідає SYN ACK, а потім ACK й сесія вважається встановленою). Перше правило,
яке ми записали (c NEW) дозволяє форвардити пакети TCP SYN з мережі 192.168.0.0 в
172.16.0.0.
Коли другий учасник відповідає на цей і будь-який наступний пакет, то підпадає під
дію 2 правила про встановлені сесії і такі пакети з мережі 172.16.0.0 проходять. А от якщо він

4
 Національний університет «Чернігівська політехніка»

сам спробує встановити сесію (або просто пінганути), то не потрапить під перше та друге
правило, а потрапить під 3-тє, яке й дропне цей пакет.

Підіб'ємо підсумки: ми навчилися керувати напрямками установки tcp-сесій для

контролю спрямування трафіку між зонами безпеки.