«Всегда закрывай за собой двери!»: краткое пособие по работе с портами

Открытые порты — это распахнутые двери в вашу инфраструктуру. Сервис, который слушает по ним запросы, обрабатывает входящие данные и реагирует на них в зависимости от заложенной логики. Из-за ошибок на этом уровне возникают уязвимости, которые хактивист может эксплуатировать для нелегитимного доступа к инфраструктуре.

Самый логичный способ обезопасить себя — ограничить сетевой доступ к сервису или инфраструктуре — например, через порты. Это можно сделать с помощью межсетевого экрана — инструмента для управления трафиком в сети и защиты от несанкционированного доступа. Решение позволяет описать, какие запросы будут проходить через определенные порты, к каким сервисам можно получить доступ и т. д.

Привет! Меня зовут Иван, я ведущий инженер по информационной безопасности в Selectel. Давно хотели научиться настраивать сетевые интерфейсы? Хорошая новость: мы в Selectel запускаем цикл статей по работе с портами в разрезе ИБ. В этом материале разберем, как с помощью различных межсетевых экранов: локальных, облачных и МСЭ в составе NGFW — обеспечить дополнительную защиту сервисов. Подробности под катом!

Используйте навигацию, если не хотите читать текст полностью:

→ Подготовка: в чем нужно разобраться
→ Поверхность атаки и открытые порты
→ Сценарий 1. Белый адрес задан на сетевом интерфейсе
→ Сценарий 2. Дополнительно настроен локальный межсетевой экран
→ Сценарий 3. Дополнительно настроен облачный межсетевой экран
→ Сценарий 4. Сервер заведен на виртуальный NGFW
→ Заключение

Подготовка: в чем нужно разобраться

Про сетевые технологии написано уже много. Как минимум, для работы с портами важно разобраться, как устроена модель TCP/IP, в чем разница между портом и сокетом и т. д. Обо всем этом мы с коллегами уже рассказали в бесплатном курсе «Как работают сетевые протоколы».

Из чего состоит TCP/IP ↓

Модель TCP/IP (Transmission Control Protocol/Internet Protocol) — это основная сетевая архитектура, которая описывает, как данные передаются и принимаются в сети, включая интернет. Модель состоит из четырех уровней, каждый из которых выполняет определенные функции для обеспечения надежной и эффективной передачи информации между устройствами.

1. Уровень сетевого интерфейса (Network Interface Layer) отвечает за физическую передачу данных между устройствами. Включает работу с аппаратным обеспечением: сетевыми картами и кабелями. А также преобразование цифровых данных в сигналы для передачи по каналам связи.

2. Интернет-уровень (Internet Layer) занимается адресацией и маршрутизацией данных. Основной протокол — IP (Internet Protocol). Данные разбиваются на пакеты, которым присваиваются IP-адреса отправителя и получателя. Интернет-уровень определяет оптимальный путь передачи данных через сеть.

3. Транспортный уровень (Transport Layer) управляет передачей данных между хостами. Протоколы TCP (Transmission Control Protocol) и UDP (User Datagram Protocol) обеспечивают передачу данных: TCP — с проверкой ошибок и гарантией доставки, UDP — более простой и быстрый способ передачи без гарантии.

4. Уровень приложений (Application Layer) предоставляет интерфейс для конечных пользователей и приложений, позволяя им взаимодействовать с сетью. Примеры протоколов — HTTP, FTP и SMTP.

Важно: в основном я буду говорить о втором и третьем уровне. Больше подробностей о работе TCP/IP — в Академии Selectel.

Поверхность атаки и открытые порты

Публикация сервисов в интернете означает, что устройство предоставляет определенные услуги — например, веб-сайты — и делает их доступными в интернете. Для этого девайс должен иметь публичный IP-адрес и открытые порты, чтобы другие устройства могли подключиться и использовать предлагаемые сервисы.

Есть несколько вариантов публикации виртуальной машины наружу. Например, вы можете добавить белый адрес на сетевой интерфейс сервера. Или использовать серый адрес и далее настроить NAT 1:1 или Port-Forwarding.

В рамках статья я буду использовать три архитектуры:

Схема 1. Виртуальная машина с веб-сайтом находится в серой сети. Для серого адреса сервера добавлен плавающий IP. Все порты ВМ пробрасываются наружу.

Схема 2. Виртуальная машина с веб-сайтом защищена облачным межсетевым экраном. На ВМ может быть назначен как белый адрес, так и серый с плавающим IP, как это реализовано в первой схеме.

Схема 3. Сервер с веб-сайтом заведен за виртуальный межсетевой экран — отдельную машину с Usergate VE.

Давайте посмотрим, какой будет поверхность атаки для разных способов публикации. Я создам в публичном облаке Selectel виртуальную машину для размещения веб-страницы в одном пуле и сервер для сканирования в другом. Контент сайта в данном случае не играет никакой роли — для нас важна только доступность портов из интернета.

Сценарий 1. Белый адрес задан на сетевом интерфейсе

В рамках этого сценария все будет актуально для схемы, где на сетевом интерфейсе виртуальной машины задан серый адрес и настроен NAT 1:1 (т. е. плавающий IP-адрес).

Подготовка стенда

1. Переходим в панель управления my.selectel.ru и выбираем раздел Облачная платформа.

2. Открываем вкладку Серверы и создаем два сервера в разных пулах. Например, в ru-9a и ru-3b. Будет достаточно минимальных произвольных конфигураций:

Конфигурации виртуальных серверов.

Сканирование

1. После создания виртуальной машины проведем первичное сканирование. На сервере scan необходимо установить сетевой сканер nmap:

$ sudo apt install nmap -y

2. Выполним команду для сканирования портов виртуальной машины srv:

sudo nmap -p 0-65535 <ip srv>

3. Получаем вывод:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-02 14:55 UTC
Nmap scan report for 87.228.25.110
Host is up (0.0011s latency).
Not shown: 65534 closed ports
PORT   STATE	SERVICE
22/tcp open 	ssh
25/tcp filtered smtp

Nmap done: 1 IP address (1 host up) scanned in 3.22 seconds

Как видим, наружу открыт порт 22/TCP, а 25/TCP фильтруется Selectel по умолчанию.

4. Далее на машине srv установим nginx:

$sudo apt install nginx

5. Возвращаемся на сервер scan. Попробуем повторно просканировать порты виртуальной машины srv:

tarting Nmap 7.80 ( https://nmap.org ) at 2024-09-02 15:03 UTC
Nmap scan report for 87.228.25.110
Host is up (0.0011s latency).
Not shown: 65533 closed ports
PORT   STATE	SERVICE
22/tcp open 	ssh
25/tcp filtered smtp
80/tcp open 	http

Nmap done: 1 IP address (1 host up) scanned in 3.18 seconds

Сейчас я могу взаимодействовать со службами, которые работают на этих портах. То есть при дефолтных настройках порты открыты для всего интернета. И можно увидеть, сколько обращений сыпется на порты 22/TCP и 80/TCP. Для этого на сервере srv достаточно выполнить команду:

$ sudo tcpdump -pni eth0 inbound

Сразу после публикации в интернет нашим сервером начинают интересоваться и сканировать порты. О том, как это работает, мы рассказали в отдельной статье.

Сценарий 2. Дополнительно настроен локальный межсетевой экран

Подготовка стенда

Поднимем и настроим стенд, как в первом сценарии.

Сканирование

1. Теперь в ОС самого виртуального сервера разрешим доступ к порту 22/TCP только для доверенных белых IP-адресов. Для этого добавим правило iptables — читайте в Академии, что это такое.

$ sudo iptables -L

Запросы со всех остальных IP-адресов к порту 22/TCP будут отклоняться. В результатах сканирования видим:

Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-02 15:20 UTC
Nmap scan report for 87.228.25.110
Host is up (0.0011s latency).
Not shown: 65533 closed ports
PORT   STATE	SERVICE
22/tcp filtered ssh
25/tcp filtered smtp
80/tcp open 	http

Nmap done: 1 IP address (1 host up) scanned in 3.18 seconds

Видно, что доступным остался только порт 80/TCP. Порт 22/TCP сейчас имеет статус filtered.

Сценарий 3. Дополнительно настроен облачный межсетевой экран

Подготовка стенда

Как в первом и втором сценариях, поднимем и настроим стенд, но вместо сервера scan будет использовать межсетевой экран. Предварительно также нужно удалить iptables на сервере srv, если он есть:

$ sudo iptables -F INPUT

Настроим то же самое на базе облачного межсетевого экрана Selectel.

1. Переходим в панель управления my.selectel.ru и выбираем раздел Облачная платформа.

2. Открываем вкладку Файрволы и создаем файрвол. Выбираем пул, в котором расположен сервер srv, и указываем сеть, для которой будет настроен межсетевой экран:

Настройка файрвола в облаке.

2. Создаем правило входящего трафика, разрешающее доступ по 22/TCP к серверу srv только для доверенного белого адреса. А также — правило, которое разрешает исходящий трафик от сервера srv в интернет:

Настройка правил файрвола.

Сканирование

Сканируем порты сервера srv:

$ sudo nmap -p 0-65535 <ip>
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-02 15:38 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds

Как видно из результата сканирования, все порты сервера недоступны.

Если на облачном межсетевом экране разрешить входящий трафик на 80/TCP для всего интернета, то и со сканера будет доступен порт:

$ sudo nmap -p 0-65535 <ip>
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-02 15:40 UTC
Nmap scan report for 87.228.25.110
Host is up (0.0012s latency).

PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds

Облачным межсетевым экраном можно управлять не только через веб-интерфейс панели my.selectel.ru, но и через API OpenStack. Подробнее рассказали в документации.

Сценарий 4. Сервер заведен на виртуальный NGFW

Подготовка стенда

1. Переходим в панель управления my.selectel.ru и выбираем раздел Облачная платформа.

2. В разделе Образы загружаем предварительно установленный образ диска Usergate VE.

3. Открываем вкладку Серверы и создаем виртуальную машину с Usergate VE. Будет достаточно 2 vCPU и 4 ГБ RAM.

4. Далее осуществляем первичную настройку сервера по инструкции.

5. После установки Usergate VE изменим конфигурацию сети, чтобы она соответствовала третьей схеме. В результате настройки интерфейсов будут выглядеть следующим образом:

Admin@aleasaageeas# show network interface

adapter:
    port0
        type               : adapter
        interface-name     : port0
        node-name          : utmcore@aleasaageeas
        zone               : Untrusted
        enabled            : on
        ip-addresses       : 192.168.0.3/24
        iface-mode         : static
        mac                : fa:16:3e:95:58:c0
        mtu                : 1500
        running            : on
        master             : off
        dhcp-relay         :
            enabled        : off
            utm-address    : undefined
        iface-type         : l3
        netflow-profile    : Undefined
        lldp-profile       : Undefined

    port1
        type               : adapter
        interface-name     : port1
        node-name          : utmcore@aleasaageeas
        zone               : Trusted
        enabled            : on
        ip-addresses       : 192.168.100.3/24
        iface-mode         : static
        mac                : fa:16:3e:b3:34:4a
        mtu                : 1500
        running            : on
        master             : off
        dhcp-relay         :
            enabled        : off
            utm-address    : undefined
        iface-type         : l3
        netflow-profile    : Undefined
        lldp-profile       : Undefined

6. Добавим на зону внешнего интерфейса более жесткие условия защиты от DoS:

Admin@aleasaageeas# set network zone Untrusted dos-protection-syn alert-threshold 100
Admin@aleasaageeas# set network zone Untrusted dos-protection-syn drop-threshold 150
Admin@aleasaageeas# show network zone Untrusted dos-protection-syn

enabled            : on
aggregate          : off
alert-threshold    : 100
drop-threshold     : 150

7. Настроим Port Forwarding на Usergate для публикуемого сервиса:

# create network-policy nat-routing 1 upl-rule 
…OK \
... src.zone = Untrusted \
... dst.ip = lib.network(Uplink) \
... target_ip("192.168.100.2") \
... port_map(80) \
... name(SRV) \
…src.geoip = RU\
... port_mapping \
... 

Для данной публикации можно добавить разрешение доступа только для src ip, входящих в список GeoIP = RU. То есть сервис будет доступен только IP AS, зарегистрированных в РФ.

Дополнительные настройки

Кроме того, можно опубликовать сервис с помощью Reverse Proxy — в этом случае будет возможность дополнительно анализировать HTTP-запрос.

1. Сначала создадим Reverse Proxy Server:

#  create global-portal reverse-proxy-servers name SRV address 192.168.100.2 port 

2. Далее через веб-интерфейс или в CLI с помощью UPL создадим правило Reverse-proxy. Для этого понадобится задать GeoIP источников, а также разрешенные Useragent пользовательских браузеров. Получится примерно такое правило:

# show global-portal reverse-proxy-rules

% ----------------- 1 -----------------
OK \
    url.port = 80 \
    src.zone = Untrusted \
    src.geoip = RU \
    request.header.User-Agent = lib.useragent(Chrome, Edge, Firefox, Opera, Safari, "Yandex browser") \
    profile(SRV) \
    rewrite_path("example.com/path1", "example.local/path2") \
    enabled(true) \
    name(SRV)

Вывод

Теперь опубликованный сервис будет доступен только для белых IP, входящих в диапазон GeoIP=RU и с HTTP-заголовками Useragent, значения которых указаны в открытых списках.

Как видим, самый простой способ обезопасить себя — ограничить сетевой доступ к сервису или к инфраструктуре. К тому же, на межсетевых экранах можно задавать белые и черные списки.

Суть белого списка (whitelist) — разрешить доступ только явно указанным доверенным адресам источников. Такой способ можно использовать, если заранее известны адреса легитимных адресов-источников.

Черный список (blacklist) содержит адреса, доступ с которых должен быть запрещен. Для всех остальных доступ будет разрешен. Этот способ, например, позволяет ограничить доступ для IP-адресов с плохой репутацией, которые уже попали в списки блокировок.

Частным случаем белых и черных списков можно считать GeoIP. С помощью него можно разрешить или запретить доступ к сервисам для разных пулов IP-адресов, зарегистрированных в AS определенной страны.

Другим способом выявления аномалий является анализ поведения пользователей. Например, число запросов за единицу времени или количество полученных ошибок от сервера может говорить о попытках нелегитимного доступа или воздействия на сервис. поэтому источник таких запросов необходимо внести в черный список, запретив доступ к защищаемому ресурсу на заранее определенное время.

Заключение

Обеспечение безопасности открытых портов — это ключевой аспект защиты сетевой инфраструктуры. Открытые порты являются потенциальными точкой входа для атак, поэтому важно регулярно проверять их и использовать различные инструменты для минимизации рисков.

Понимание основ работы IP-адресов, портов, сокетов и различных уровней модели TCP/IP позволяет более глубоко осознать риски и методы защиты. А сканирование — выявлять потенциальные уязвимости и реагировать на них.

В следующей статье рассмотрим список наиболее популярных портов. А еще поговорим о том, как открытые порты могут свидетельствовать о взломе сервиса. Еще увидимся!