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

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

Привет! Меня зовут Иван, я ведущий инженер по информационной безопасности в 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 позволяет более глубоко осознать риски и методы защиты. А сканирование — выявлять потенциальные уязвимости и реагировать на них.

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

Комментарии (4)


  1. Akina
    04.09.2024 12:19
    +2

    Как-то странно. В первых трёх вариантах вы сканировали порты nmap-ом, а в последнем что же не стали?

    И не очень понятно, зачем было в третьем варианте делать веб-сервер, недоступный из инета вообще.


    1. is113 Автор
      04.09.2024 12:19
      +1

      Спасибо за комментарий.

      Концепция закрытия портов, но с помощью NGFW, сохраняется и в последнем варианте.
      В третьем варианте веб-сервер доступен из Интернета - результат сканирования содержит открытый порт 80/TCP, об открытии его сказано в тексте.


  1. Johan_Palych
    04.09.2024 12:19
    +8

    Для этого добавим правило iptables — читайте в Академии
    Открываем вкладку Серверы и создаем два сервера в разных пулах.

    Создаете серверы на базе Ubuntu 22.04 LTS?
    What’s new in Security for Ubuntu 22.04 LTS?
    "nftables as the default firewall backend"
    https://manpages.ubuntu.com/manpages/jammy/en/man8/iptables-restore-translate.8.html

    You can translate the iptables rules to nft through iptables-translate and ipt6ables-translate. e,g:
    iptables-translate -A INPUT -s x.x.x.x/32 -d y.y.y.y/32 -i eth2 -j DROP


  1. Wesha
    04.09.2024 12:19
    +2

    Вообще не понимаю, что за шум-гам. "Открытый порт" означает, что сервер готов принять на этом порту соединние и передавать полученные данные некоему процессу. Ну так замечательно: теперь главное — чтобы тот процесс, которому передаются данные, был нормально написан и не имел уязвимостей (а если имеет — то это уже медицинский случай, и тут закрывай — не закрывай, трындец подкрадётся незаметно), от закрытия портов в зависит чуть менее чем ничего.

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