У цій статті ми розглянемо процес організації та налаштування простого інтернет-шлюзу на базі CentOS 7.x. Даний шлюз дозволить користувачам з локальної мережі виходити в Інтернет, а також отримувати доступ до серверів або комп’ютерів у внутрішній мережі зовні. Для організації маршрутизації і пересилання пакетів ми будемо використовувати технологію NAT на базі брандмауера iptables. Також розглянемо, як вести і аналізувати логи підключень на інтернет-шлюзі при доступі зовнішніх користувачів в локальну мережу.

Схема локальної мережі зі шлюзом доступу в Інтернет, типи NAT

NAT (Network Address Translation) – трансляція IP адрес, це механізм, що дозволяє підміняти адресу джерела і призначення в заголовку IP пакетів, при їхньому проходженні через маршрутизатор, тобто між різними мережами.

Налаштовувати NAT будемо між внутрішньою мережею з адресацією 10.2.0.0/24 і зовнішньою мережею Інтернет, двох видів:

  • джерело NAT – це підміна IP адреси джерела, в нашому випадку, для організації виходу в Інтернет через один публічний IP адресу кількох клієнтів.
  • пункт призначення NAT – підміна IP адреси призначення, в нашому випадку, для забезпечення доступу з зовнішньої мережі Інтернет через публічний IP адреса до серверів внутрішньої мережі.

Визначимо елементи мережі (рисунок 1), між якими буде організовано NAT:

  • gw-сервер – сервер шлюз, тобто наш CentOS Linux сервер, який надає доступ за межі внутрішньої мережі. У нього два інтерфейси, перший eth1 (10.2.0.1) у внутрішній мережі, другий eth0 (84.201.168.122) з публічним IP адресою і доступом в Інтернет;
  • веб-сервер01 – веб сервер внутрішньої мережі, IP адреса 10.2.0.11;
  • my-server01 – особистий сервер внутрішньої мережі, IP адреса 10.2.0.12.

схема мережі з NAT шлюзом доступу в інтернет на базі Linux CentOS

Примітка: Для серверів внутрішньої мережі веб-сервер01 і myserver01 маршрут за замовчуванням встановлений на інтерфейс eth1 (10.2.0.1) сервера gw-сервер01.

Налаштування Source NAT: доступ з локальної мережі в Інтернет

При source NAT для серверів зовнішньої мережі, запити від наших клієнтів з внутрішньої мережі будуть виглядати так, як ніби з ними спілкується безпосередньо сервер шлюз – gw-сервер01.

У минулій статті “Базова настройка брандмауера Linux за допомогою iptables” ми розглянули ази використання iptables. Цього разу, працювати в iptables будемо не тільки з таблицею фільтр, Але і з таблицею нац. На відміну від таблиці для фільтрації трафіку фільтр, таблиця nat містить наступні chains (ланцюжки):

  • ПЕРЕДАГРАФІЯ – в цьому ланцюжку обробляються входять IP пакети, до їх поділу на призначені для самого сервера або для передачі іншому, тобто до прийняття рішення про вибір маршруту для IP пакета;
  • ВИХІД – ланцюжок призначена для обробки IP пакетів, які згенеровані локально додатком на сервері. Локально згенеровані IP пакети не проходять цілий ряд PREROUTING;
  • POSTROUTING – в цьому ланцюжку обробляються всі вихідні IP пакети, вже після прийняття рішення про маршрут для IP пакета.

Відрізняються і дії, що виконуються для IP пакетів, в цій таблиці:

  • МАСКАРАД і СНАТ– виробляє підміну IP адреси джерела для вихідних пакетів. Відмінністю цих дій є те, що SNAT дає можливість задати конкретний IP адресу нового джерела, а в разі MASQUERADE це відбувається динамічно;
  • ДНАТ – виробляє підміну IP адреси призначення для вхідних пакетів.

важливо: Дія MASQUERADE і SNAT задається тільки для ланцюжка POSTROUTING, а дія DNAT тільки для ланцюжків PREROUTING або ВИХІД.

На малюнку 2 зображені етапи обробки IP пакета з внутрішньої мережі на шлюзі gw-server01 при SNAT на iptables. IP адреса і порт призначення при цьому залишаються незмінними.

схема ланцюжків forward postrouting в linuc iptables малюнок 2

  1. IP пакет надійшов на внутрішній інтерфейс eth1 сервера gw-server01. Так як IP призначення не належить сервера gw-server01, IP пакет переходить до обробки ланцюжком FORWARD.
  2. Після проходження ланцюжка FORWARD, для IP пакета визначається вихідний мережевий інтерфейс, з якого він повинен бути відправлений, це відзначено жовтим кольором
  3. В кінці IP пакет проходить ланцюжок POSTROUTING, в якій відбувається підміна IP адреси джерела, на IP адреса зовнішнього інтерфейсу eth0 сервера gw-server01

Приступимо до налаштування. Спочатку потрібно встановити параметр ядра, який дозволяє передавати пакети між інтерфейсами сервера. Для цього в файл /etc/sysctl.conf додамо змінну:

net.ipv4.ip_forward = 1

Щоб застосувати зміни, виконаємо команду

sysctl -p /etc/sysctl.conf

тут sysctl це команда, яка дозволяє управляти параметрами ядра, ключ означає, що потрібно вважати параметри з файлу.

Створимо правило в 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

  • —До джерела повинен бути адресою на інтерфейсі, з якого планується випускати в зовнішню мережу IP пакети;
  • -s 10.2.0.0/24 задано з розрахунку, що внутрішня мережа 10.2.0.0/24, але це необов’язковий параметр, якщо його не вказати, обмежень на джерело взаємодії не буде.

Подивимося вийшла конфігурацію для таблиці фільтр і ланцюжки ВПЕРЕД (Висновок обрізаний):

iptables -L -n -v

iptables -L -n -v ланцюг вперед

і конфігурацію для таблиці нац і ланцюжки POSTROUTING (Висновок обрізаний):

iptables -t nat -L -n -v

iptables nat побутовий ланцюг

Для перевірки, що наш веб-сервер у внутрішній мережі отримав доступ в Інтернет, спробуємо підключитися через telnet на адресу 1.1.1.1 (Cloudflare DNS) порт 80:

telnet 1.1.1.1 80

тестувати telnet через iptables nat

висновок команди Підключений 1.1.1.1, Показує, що підключення пройшло успішно.

Налаштування Destination NAT і port forwarding: доступ з Інтернету в локальну мережу

Тепер розглянемо зворотну ситуацію. Ми хочемо, щоб клієнти зовні мали можливість потрапляти на наш сайт у внутрішній мережі. А також нам потрібно заходити на свій особистий сервер (або робочу станцію) з Інтернету. Відмінність цього випадку не тільки в напрямку взаємодії, але ще і в тому, що потрібно перенаправити запити на окремі порти, 80 (TCP) і 3389 (TCP), при цьому підміняти сервер призначення і можливо, порт призначення. Ця техніка називається переадресація портів (Кидок портів).

Спочатку вирішимо передачу пакетів з зовнішнього інтерфейсу (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

Увага: Тут в команді використовується ключ -I замість -A. Ключ -I дозволяє додати правило за вказаним номером в послідовності правил ланцюжка, вказавши індекс. Наприклад, в команді вище, індекс одиниця в ланцюжку FORWARD, тобто, правило буде додано в початок ланцюжка. Якщо це правило буде додано в кінець, воно не спрацює, тому що IP пакет буде оброблений попереднім правилом, що дозволяє будь-які джерела взаємодії, і на цьому його проходження по ланцюжку FORWARD буде завершено.

Тепер переспрямуємо всі з’єднання на порт 80 інтерфейсу зовнішньої мережі (eth0) на IP адреса веб сервера внутрішньої мережі веб-сервер01:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.0.11

—До місця призначення – повинен бути 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-сервер до порту 13389:

telnet 84.201.168.122 13389

У відповідь отримаємо порожній екран і курсор, це говорить про те, що з’єднання працює.

Аналіз логів здійснювати підключення до мережі NAT в Linux

Одним з моментів, для підвищення рівня безпеки після настройки port forwarding на наш особистий сервер із зовнішньої мережі, буде збірка і аналіз логів зовнішній підключень. Адже крім нас, цим доступом може спробувати скористатися зловмисник.

Спочатку включимо запис в лог файл /де/ 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

тут,

  • —Сервіс – задає конкретний сервіс, повідомлення від якого потрібно аналізувати, в нашому випадку, тільки від iptables;
  • —Діапазон – вказує період вибірки даних, today – всі події за сьогодні;
  • —Деталь – ступінь деталізація звіту (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 test@gmail.com --detail low --service iptables --range yesterday

Тут додалися опції:

—Вихід – вказує спосіб виведення звіту, mail – відправити на пошту;

—Поштою – e-mail адресу одержувача звіту.

Leave a Reply

Your email address will not be published. Required fields are marked *