У цій статті ми розглянемо процес організації та налаштування простого інтернет-шлюзу на базі CentOS 7.x. Даний шлюз дозволить користувачам з локальної мережі виходити в Інтернет, а також отримувати доступ до серверів або комп'ютерів у внутрішній мережі зовні. Для організації маршрутизації і пересилання пакетів ми будемо використовувати технологію NAT на базі брандмауера iptables. Також розглянемо, як вести і аналізувати логи підключень на інтернет-шлюзі при доступі зовнішніх користувачів в локальну мережу.
зміст:
- Схема локальної мережі зі шлюзом доступу в Інтернет, типи NAT
- Налаштування Source NAT: доступ з локальної мережі в Інтернет
- Налаштування Destination NAT і port forwarding: доступ з Інтернету в локальну мережу
- Аналіз логів здійснювати підключення до мережі NAT в Linux
Схема локальної мережі зі шлюзом доступу в Інтернет, типи NAT
NAT (Network Address Translation) - трансляція IP адрес, це механізм, що дозволяє підміняти адресу джерела і призначення в заголовку IP пакетів, при їхньому проходженні через маршрутизатор, тобто між різними мережами.
Налаштовувати NAT будемо між внутрішньою мережею з адресацією 10.2.0.0/24 і зовнішньою мережею Інтернет, двох видів:
- source NAT - це підміна IP адреси джерела, в нашому випадку, для організації виходу в Інтернет через один публічний IP адресу кількох клієнтів.
- destination NAT - підміна IP адреси призначення, в нашому випадку, для забезпечення доступу з зовнішньої мережі Інтернет через публічний IP адреса до серверів внутрішньої мережі.
Визначимо елементи мережі (рисунок 1), між якими буде організовано NAT:
- gw-server - сервер шлюз, тобто наш CentOS Linux сервер, який надає доступ за межі внутрішньої мережі. У нього два інтерфейси, перший eth1 (10.2.0.1) у внутрішній мережі, другий eth0 (84.201.168.122) з публічним IP адресою і доступом в Інтернет;
- web-server01 - веб сервер внутрішньої мережі, IP адреса 10.2.0.11;
- my-server01 - особистий сервер внутрішньої мережі, IP адреса 10.2.0.12.
Налаштування Source NAT: доступ з локальної мережі в Інтернет
При source NAT для серверів зовнішньої мережі, запити від наших клієнтів з внутрішньої мережі будуть виглядати так, як ніби з ними спілкується безпосередньо сервер шлюз - gw-server01.
У минулій статті "Базова настройка брандмауера Linux за допомогою iptables" ми розглянули ази використання iptables. Цього разу, працювати в iptables будемо не тільки з таблицею filter, але і з таблицею nat. На відміну від таблиці для фільтрації трафіку filter, таблиця nat містить наступні chains (ланцюжки):
- PREROUTING - в цьому ланцюжку обробляються входять IP пакети, до їх поділу на призначені для самого сервера або для передачі іншому, тобто до прийняття рішення про вибір маршруту для IP пакета;
- OUTPUT - ланцюжок призначена для обробки IP пакетів, які згенеровані локально додатком на сервері. Локально згенеровані IP пакети не проходять цілий ряд PREROUTING;
- POSTROUTING - в цьому ланцюжку обробляються всі вихідні IP пакети, вже після прийняття рішення про маршрут для IP пакета.
Відрізняються і дії, що виконуються для IP пакетів, в цій таблиці:
- MASQUERADE і SNAT- виробляє підміну IP адреси джерела для вихідних пакетів. Відмінністю цих дій є те, що SNAT дає можливість задати конкретний IP адресу нового джерела, а в разі MASQUERADE це відбувається динамічно;
- DNAT - виробляє підміну IP адреси призначення для вхідних пакетів.
На малюнку 2 зображені етапи обробки IP пакета з внутрішньої мережі на шлюзі gw-server01 при SNAT на iptables. IP адреса і порт призначення при цьому залишаються незмінними.
малюнок 2
- IP пакет надійшов на внутрішній інтерфейс eth1 сервера gw-server01. Так як IP призначення не належить сервера gw-server01, IP пакет переходить до обробки ланцюжком FORWARD.
- Після проходження ланцюжка FORWARD, для IP пакета визначається вихідний мережевий інтерфейс, з якого він повинен бути відправлений, це відзначено жовтим кольором
- В кінці IP пакет проходить ланцюжок POSTROUTING, в якій відбувається підміна IP адреси джерела, на IP адреса зовнішнього інтерфейсу eth0 сервера gw-server01
Приступимо до налаштування. Спочатку потрібно встановити параметр ядра, який дозволяє передавати пакети між інтерфейсами сервера. Для цього в файл /etc/sysctl.conf додамо змінну:
net.ipv4.ip_forward = 1
Щоб застосувати зміни, виконаємо команду
sysctl -p /etc/sysctl.conf
тут sysctl це команда, яка дозволяє управляти параметрами ядра, ключ -p означає, що потрібно вважати параметри з файлу.
Створимо правило в iptables, що дозволяє передачу пакетів між внутрішнім (eth1) і зовнішнім (eth0) інтерфейсом:
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
і дозволимо передавати між інтерфейсами пакунки пов'язані з уже встановленим з'єднанням.
iptables -A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT
Попередні два правила має сенс створювати, тільки якщо для ланцюжка FORWARD за замовчуванням встановлена політика DROP:
iptables -P FORWARD DROP
Включення SNAT:
iptables -t nat -A POSTROUTING -s 10.2.0.0/24 -o eth1 -j SNAT --to-source 84.201.168.122
- -to-source повинен бути адресою на інтерфейсі, з якого планується випускати в зовнішню мережу IP пакети;
- -s 10.2.0.0/24 задано з розрахунку, що внутрішня мережа 10.2.0.0/24, але це необов'язковий параметр, якщо його не вказати, обмежень на джерело взаємодія не буде.
Подивимося вийшла конфігурацію для таблиці filter і ланцюжки FORWARD (Висновок обрізаний):
iptables -L -n -v
і конфігурацію для таблиці nat і ланцюжки POSTROUTING (Висновок обрізаний):
iptables -t nat -L -n -v
Для перевірки, що наш веб-сервер у внутрішній мережі отримав доступ в Інтернет, спробуємо підключитися через telnet на адресу 1.1.1.1 (Cloudflare DNS) порт 80:
telnet 1.1.1.1 80
висновок команди Connected 1.1.1.1, показує, що підключення пройшло успішно.
Налаштування Destination NAT і port forwarding: доступ з Інтернету в локальну мережу
Тепер розглянемо зворотну ситуацію. Ми хочемо, щоб клієнти зовні мали можливість потрапляти на наш сайт у внутрішній мережі. А також нам потрібно заходити на свій особистий сервер (або робочу станцію) з Інтернету. Відмінність цього випадку не тільки в напрямку взаємодії, але ще і в тому, що потрібно перенаправити запити на окремі порти, 80 (TCP) і 3389 (TCP), при цьому підміняти сервер призначення і можливо, порт призначення. Ця техніка називається port forwarding (Кидок портів).
Порт форвардного в Windows можна організувати за допомогою командиnetsh interface portproxy.Спочатку вирішимо передачу пакетів з зовнішнього інтерфейсу (eth0) на внутрішній (eth1) інтерфейс:
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
Це правило дозволяє передавати IP пакети між інтерфейсами незалежно від джерела. Але можна окремим правилом заборонити підключення через NAT для окремих IP адрес або підмереж:
iptables -I FORWARD 1 -o eth1 -s 167.71.67.136 -j DROP
Тепер переспрямуємо всі з'єднання на порт 80 інтерфейсу зовнішньої мережі (eth0) на IP адреса веб сервера внутрішньої мережі web-server01:
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.0.11
-to-destination - повинен бути IP адресою, на який потрібно замінити IP адреса призначення.
Для перевірки, спробуємо підключитися з мережі Інтернет через telnet на публічний IP адреса сервера gw-server на порт 80:
telnet 84.201.168.122 80
Результатом буде відповідь веб сервера web-server01 з нашої внутрішньої мережі:
HTTP / 1.1 400 Bad Request Server: nginx / 1.14.2 Date: Wed, 31 Jul 2019 10:21:21 GMT Content-Type: text / html Content-Length: 173 Connection: close
Аналогічно можна налаштувати доступ з інтернету на свою робочу станцію по RDP. Так як доступ по RDP буде потрібен обмеженій кількості осіб, безпечніше буде використовувати при підключенні нестандартний порт, наприклад 13389, а вже з нього перенаправляти на порт 3389 сервера внутрішньої мережі (або змінити номер RDP порту на Windows комп'ютері). Змінений порт призначення вказується через двокрапку після IP адреси:
iptables -t nat -A PREROUTING -p tcp --dport 13389 -i eth0 -j DNAT --to-destination 192.168.0.12:3389
Для перевірки, спробуємо підключитися з мережі Інтернет через telnet (або командлет PowerShell Test-NetConnection) на публічний IP адреса сервера gw-server на порт 13389:
telnet 84.201.168.122 13389
У відповідь отримаємо порожній екран і курсор, це говорить про те, що з'єднання працює.
Аналіз логів здійснювати підключення до мережі NAT в Linux
Одним з моментів, для підвищення рівня безпеки після настройки port forwarding на наш особистий сервер із зовнішньої мережі, буде збірка і аналіз логів зовнішній підключень. Адже крім нас, цим доступом може спробувати скористатися зловмисник.
Спочатку включимо запис в лог файл /var/ Log / messages всі спроби з'єднань на використовуваний нами нестандартний RDP порт:
iptables -I INPUT 1 -p tcp --dport 13389 -m state --state NEW -j LOG --log-prefix "NEW RDP SESSION"
Підключимося до нашого особистого сервера, щоб в балці з'явився запис. Тепер Отфильтруем всі записи в лог файлі, які нам потрібні:
cat / var / log / messages | grep "NEW RDP SESSION"
kernel: NEW RDP SESSION IN = OUT = eth1 SRC = 167.71.67.79 DST = 84.201.168.122 LEN = 60 TOS = 0x00 PREC = 0x00 TTL = 64 ID = 16270 DF PROTO = TCP SPT = 60836 DPT = 13389 WINDOW = 29200 RES = 0x00 SYN URGP = 0
Читати такий лог не дуже зручно, тим більше кожен день. Тому, наступним кроком, автоматизуємо аналіз логів, щоб регулярно отримувати звіти, на основі нашого фільтра. Для цього скористаємося утилітою Logwatch, її установка через стандартний менеджер пакетів yum:
yum install logwatch
Спочатку спробуємо згенерувати звіт вручну:
/ Usr / sbin / logwatch --detail low --service iptables --range today
тут,
- -service - задає конкретний сервіс, повідомлення від якого потрібно аналізувати, в нашому випадку, тільки від iptables;
- -range - вказує період вибірки даних, today - всі події за сьогодні;
- -detail - ступінь деталізація звіту (high, med, low).
За замовчуванням logwatch відобразить звіт на екран, отримаємо приблизно такий висновок:
--------------------- iptables firewall Begin ------------------------ Listed by source hosts: Logged 2 packets on interface eth1 From 167.71.45.65 - 2 packets to tcp (13389) ---------------------- iptables firewall End -------------------------
Звіт працює, залишилося виконувати його за розкладом, раз день і відправляти собі на email, для цього оновимо команду і запишемо її в файл /etc/cron.daily/00logwatch:
/ Usr / sbin / logwatch --output mail --mailto [email protected] --detail low --service iptables --range yesterday
Тут додалися опції:
-output - вказує спосіб виведення звіту, mail - відправити на пошту;
-mailto - e-mail адресу одержувача звіту.
При прокинув RDP всередину локальної мережі додатково потрібно вміти аналізувати логи RDP підключень безпосередньо в Windows.
