Firewall

Настоящей статьей начинаем цикл статей, посвященных траблшутингу (решению проблем) и анализу работы межсетевых экранов производства Palo Alto Networks одного из мировых лидеров в сфере разработки оборудования для обеспечения информационной безопасности. В основе статьи лежит многолетний опыт работы с продуктами вендора экспертов сервис-провайдера Angara Professional Assistance, который обладает статусом авторизованного сервисного центра (ASC) Palo Alto Networks.

Что такое сессия?

Для начала давайте разберемся, что такое сессия, и как она работает в разрезе межсетевого экрана Palo Alto Networks.

Каждая сессия это набор из двух ключей потока (Client-to-Server и Server-to-Client). Каждый ключ потока это хэш следующих параметров:

1. IP protocol identifier (TCP, UDP, ICMP) (протокол);

2. Source IP address (IP-адрес источника);

3. Destination IP address(IP-адрес назначения);

4. Source port number (порт источника);

5. Destination port number(порт назначения);

6. Ingress zone ID (уникальный ID для каждой входящей зоны на межсетевом экране).

У Palo Alto Networks можно встретить термин 6-tuple. Это уникальный идентификатор, полученный из перечисленных выше шести параметров.

Для каждого полученного пакета межсетевой экран хэширует данные 6-tuple, чтобы получить соответствующий ключ потока. После чего межсетевой экран сверяет ключ потока для каждого нового пакета, чтобы сопоставить его с нужной сессией.

На данном рисунке приведен пример частичного вывода команды >show session id 52975, где мы можем видеть каждый из 6 параметров ключа потока. Стоит отметить, что хэшируются 6-tuple только у входящих пакетов. То есть это всегда будет именно ingress-зона.

Итак, получается, что сессия это связанный ключом потока набор однонаправленных потоков данных между клиентов и сервером.

С этим разобрались, поехали дальше. Давайте теперь разберем вывод команды >show session info:

В первой части вывода данной команды мы можем видеть общее доступное число одновременных сессий для текущей платформы, на сколько процентов использована таблица сессий, количество пакетов в секунду, пропускную способность (за исключением аппаратно-разгруженных пакетов (offloaded traffic)), а также информацию о новых соединениях в секунду (CPS).

Далее мы можем видеть различные настройки таймаутов, которые, при желании, можно менять.

Далее идет информация о том, насколько быстро наступит таймаут у сессий при достижении определенного порога утилизации таблицы сессий. На примере скриншота: если таблица сессий будет использована более, чем на 80%, то таймаут у TCP-сессий будет не 3600 секунд, а 1800. Если Scaling factor будет равен 10, то, соответственно, таймаут у сессий будет равен 360 секундам.

Далее идет информация о различных параметрах, которые влияют на установку новых сессий. Например, будет ли использоваться проверка TCP SYN, включена ли аппаратная разгрузка сессий.

В конце приводится информация о хитрой опции Application trickling, которая означает, что если мы превышаем лимит по ресурсам межсетевого экрана (например, пакетного буфера), то запускается механизм сканирования сессий. Если сессия была неактивна более, чем trickling-лимит, то буфер, который был задействован данной сессией, очистится. То есть, по сути, это механизм для дополнительной защиты ресурсов межсетевого экрана.

Состояния сессий

Каждая сессия в любой момент времени находится в одном из шести состояний. Зеленым обозначены состояния, которые мы можем наблюдать в веб-интерфейсе или командной строке (CLI) межсетевого экрана.

• INIT: каждая сессия начинается с состояния инициализации (INIT). Сессия в состоянии INIT является частью пула свободных сессий.

• ACTIVE: любая сессия, которая соответствует потоку трафика, который еще не истек по таймауту, и который активно используется для проверки (например, механизмом App-ID) или для отправки по адресу назначения (destination forwarding).

• DISCARD: трафик, ассоциированный с сессией, которая была заблокирована на основании политик безопасности или в результате обнаружения угрозы. Пакет, на который сработала политика или детектор угроз, был отброшен; все последующие пакеты, принадлежащие к сессии в состоянии DISCARD, будут отброшены без всякой проверки.

Остальные состояния сессии (OPENING, CLOSED, FREE) являются транзитными. Транзитные состояния можно увидеть достаточно редко, так как в данных состояниях сессия надолго не задерживается.

В нормальных условиях каждая сессия пройдет полный цикл, начиная с состояния INIT и заканчивая FREE.

Просмотр информации о сессиях

Посмотреть информацию о сессиях в реальном времени можно как через веб-интерфейс, так и через CLI межсетевого экрана. Session Browser может быть полезным инструментом для траблшутинга без необходимости захвата пакетов или использования debug-логов. Мы можем посмотреть, создает ли ожидаемый трафик соответствующую сессию, как она категорируется механизмом App-ID, и каким образом и из-за чего эта сессия завершается.

Если вы видите сессию в Session Browser, это еще не значит, что далее весь трафик для этой сессии будет разрешен. После того как межсетевой экран создаст сессию, к ней будут применены механизмы App-ID, Content Inspection, вследствие которых сессия может быть отброшена после инспекции полезной нагрузки какого-нибудь пакета.

В данном меню можно применять различные фильтры, например, отфильтровать сессии по названиям правил безопасности, через которые они проходит. Так же мы можем принудительно завершить сессию, нажав на крестик.

Похожую информацию мы можем получить, используя CLI и команду >show session all. Данную команду также можно использовать с различными фильтрами.

Далее мы можем перейти внутрь каждой сессии для получения более расширенной информации, используя команду >show session id <session number>.

c2s flow поток от клиента к серверу. Инициатор потока.

s2c flow поток от сервера к клиенту. Ответный поток.

Детальную информацию о сессии можно также посмотреть через меню Monitor > Traffic > Detailed Log View. По сути, там будет та же информация, которую вы получите через CLI.

Посмотрите, как межсетевой экран переопределяет приложение в рамках одной сессии. Сначала движок определил тип URL, риск, категорию, проверил не блокируется ли сессия согласно политикам URL-filtering. Далее межсетевой экран по первым пакетам определил приложение web-browsing и проверил, разрешено ли оно политиками безопасности. Как только стало приходить больше пакетов с полезной нагрузкой, согласно встроенной (и постоянно обновляемой) базе сигнатур, межсетевой экран увидел приложение google-base, после чего в очередной раз проверил, разрешено ли оно политиками.

Данный механизм очень полезен при траблшутинге и называется application shifting. Более подробно мы его затронем в следующей статье.

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

• threat была обнаружена угроза, и политиками безопасности было применено действие reset, drop или block.

• Policy-deny к сессии была применена политика безопасности с действием deny или drop.

• Decrypt-cert-validation в большинстве случаев означает, что сессия была заблокирована потому, что для ssl-инспекции была настроена проверка сертификатов, которая не была пройдена. Сертификат мог быть просрочен или выдан недоверенным источником, или не смог пройти верификации по таймауту и т.д.

• decrypt-error сессия была заблокирована из-за того, что при настроенной ssl-инспекции межсетевому экрану не удалось расшифровать сессию из-за нехватки ресурсов. Также эта ошибка появляется, когда возникают проблемы с протоколом SSH или любые другие ошибки SSL, помимо тех, которые описаны в пункте decrypt-unsupport-param.

• tcp-rst-from-client клиент отправил tcp-rst в сторону сервера.

• tcp-rst-from-server сервер отправил tcp-rst в сторону клиента.

• resources-unavailable сессия была заблокирована из-за ограничения ресурсов межсетевого экрана. Например, в сессии могло быть превышено количество пакетов с нарушением порядка (out-of-order), разрешенных для одной сессии.

• tcp-fin оба хоста отправили tcp-fin для завершения сессии.

• tcp-reuse сессия используется повторно, и межсетевой экран закрыл предыдущую сессию.

• Decoder декодер обнаружил новое соединение в рамках протокола и завершает предыдущее соединение.

• Unknown применяется в следующих ситуациях:

  • Сессия завершилась из-за причин, не указанных до этого. Например, кто-то завершил сессию вручную командой >clear session all.

  • Устаревшая версия PAN-OS (ниже 6.1), в которой не поддерживается функционал определения причин завершения сессий.

• n/a статус, который присваивается, когда сессия еще не была завершена, то есть, когда тип лога не в значении end.

Информацию, аналогичную разделу Monitor > Traffic, можно посмотреть и через CLI. Делается это командой >show traffic log direction equal backward. Под direction equal backward подразумевается, что вы будете просматривать логи с конца.

Cli лайфхаки

Напоследок упомянем пару лайфхаков и фишек использования CLI.

Вот основной список команд, разбитых на разные категории:

• Network:

  • Ssh подключение к другим хостам;

  • Scp, tftp, ftp загрузка и выгрузка файлов;

• Monitoring / Troubleshooting:

  • Ping, traceroute базовый траблшутинг;

  • Debug многоцелевая команда (ее мы будем использовать в будущих статьях);

  • Tcpdump для захвата пакетов с management plane межсетевого экрана;

  • Test для проверки работы различного функционала;

• Display:

  • Show для вывода конфигураций, логов и различных системных данных;

  • Tail аналог одноименной команды в юниксе, показывает последние данные из файла;

  • Less, grep также одноименные команды, знакомые многим; позволяют гибко искать информацию в лог-файлах;

• System:

  • Request для использования системных команд типа shutdown;

  • Clear используется для удаления и очистки различных параметров;

• CLI navigation:

  • Configure вход в режим редактирования конфигурации;

  • Exit выход из режима редактирования конфигурации.

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

Синтаксис выглядит следующим образом: >find command keyword <keyword>

Предположим, вам нужно посмотреть какую-то информацию относительно маршрутизации OSPF, но вы забыли, с помощью какой команды это делается. Вводим >find command keyword ospf.

Мы получим приблизительно такой список (полный список на скриншоте не уместится), где будут приведены примеры всех команд, в которых есть слово OSPF.

Или мы хотим перезагрузить межсетевой экран, но забыли, как это делать. Пробуем >find command keyword restart.

В полученном списке можно найти нужную нам команду: >request restart system.

Заключение

В этой части цикла статей мы разобрали, что такое сессия с точки зрения межсетевого экрана, рассмотрели различные ее настройки и способы просмотра информации о сессиях.

В следующей статье мы постараемся разобраться, как и в какой последовательности сессии и потоки (packet flow) обрабатываются движками межсетевого экрана, а также рассмотрим логику всего этого процесса.

Введение

Базы данных это Святой Грааль для хакеров, поэтому их необходимо защищать с особой тщательностью. Это первая из серии статей, в которых мы дадим обзор best practice в обеспечении безопасности баз данных. Мы начнем с одной из самых популярных СУБД с открытым исходным кодом, PostgreSQL, и рассмотрим несколько уровней безопасности, о которых стоит задуматься:

• Безопасность на сетевом уровне

• Безопасность на транспортном уровне

• Безопасность на уровне базы данных

Безопасность на сетевом уровне

Файрволы

В идеале ваш сервер PostgreSQL должен быть полностью изолированным и не допускать никаких входящих подключений, SSH или psql. К сожалению, PostgreSQL не поддерживает стандартную настройку такого типа.

Следующий способ, который можно предпринять для повышения безопасности сервера базы данных, это заблокировать доступ к узлу, на котором работает база данных, на уровне порта, с помощью брандмауэра. По умолчанию, PostgreSQL прослушивает TCP-порт 5432. В зависимости от операционной системы существуют разные способы блокировки других портов. В Linux можно использовать iptables - наиболее доступную утилиту для управления файрволом:

# Make sure not to drop established connections.iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT# Allow SSH.iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT# Allow PostgreSQL.iptables -A INPUT -p tcp -m state --state NEW --dport 5432 -j ACCEPT# Allow all outbound, drop everything else inbound.iptables -A OUTPUT -j ACCEPTiptables -A INPUT -j DROPiptables -A FORWARD -j DROP

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

Приведенное выше правило PostgreSQL позволит любому подключаться к порту 5432. Его можно сделать более строгим, принимая подключения только с определенных IP-адресов или подсетей:

# Only allow access to PostgreSQL port from the local subnet.iptables -A INPUT -p tcp -m state --state NEW --dport 5432 -s 192.168.1.0/24 -j ACCEPT

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

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

ssh -f -N -T -R 5432:localhost:5432 user@<client-host>

Конечно, <client-host> должен быть доступным из узла PostgreSQL и иметь запущенного SSH-демона. Команда перенаправит порт 5432 на сервере базы данных на порт 5432 на клиентском компьютере, и вы сможете подключиться к базе данных через туннель:

psql "host=localhost port=5432 user=postgres dbname=postgres" 

Прослушивание адресов

Хорошей практикой является ограничение адресов, которые прослушивает сервер для клиентских подключений, с помощью параметра listen_addresses файла конфигурации. Если узел, на котором работает PostgreSQL, имеет несколько сетевых интерфейсов, используйте этот параметр, чтобы убедиться, что сервер прослушивает только те интерфейсы, через который клиенты будут подключаться к нему:

listen_addresses = 'localhost, 192.168.0.1' 

Если клиенты, подключающиеся к базе данных, всегда находятся на одном и том же узле (или, скажем, совместно расположены в одном поде Kubernetes с PostgreSQL, работающим в качестве дополнительного контейнера), отключение прослушивания сокетов TCP может полностью исключить сеть из рассматриваемой картины. Запись пустой строки в параметр прослушиваемых адресов заставляет сервер принимать только соединения сокетов домена Unix:

listen_addresses = ''

Безопасность на транспортном уровне

Поскольку большая часть всемирной паутины переходит на HTTPS, найдется мало оправданий тому, чтобы не использовать надежное шифрование для соединений с базой данных. PostgreSQL поддерживает TLS (который по-прежнему называется SSL в документации, конфигурации и CLI по legacy-причинам) и позволяет использовать его для аутентификации как сервера, так и клиента.

Серверный TLS

Для аутентификации сервера сначала необходимо получить сертификат, который сервер будет предоставлять подключающимся клиентам. Let's Encrypt упрощает получение бесплатных сертификатов X.509, например, с помощью инструмента CLI certbot:

certbot certonly --standalone -d postgres.example.com

Учтите, что по умолчанию certbot использует вызов HTTP-01 ACME для проверки запроса сертификата, который требует действительного DNS для запрошенного домена, указывающего на узел, и порт 80, который должен быть открыт.

Если по какой-то причине вы не можете использовать Let's Encrypt и хотите сгенерировать все сертификаты локально, то можно использовать openssl CLI:

# Make a self-signed server CA.openssl req -sha256 -new -x509 -days 365 -nodes \    -out server-ca.crt \    -keyout server-ca.key# Generate server CSR. Put the hostname you will be using to connect to# the database in the CN field.openssl req -sha256 -new -nodes \    -subj "/CN=postgres.example.com" \    -out server.csr \    -keyout server.key# Sign a server certificate.openssl x509 -req -sha256 -days 365 \    -in server.csr \    -CA server-ca.crt \    -CAkey server-ca.key \    -CAcreateserial \    -out server.crt

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

Клиентский TLS

Аутентификация клиента по сертификату позволяет серверу проверить личность подключающегося, подтверждая, что сертификат X.509, представленный клиентом, подписан доверенным центром сертификации (CA).

Рекомендуется использовать разные центры сертификации для выдачи сертификатов клиенту и серверу, поэтому давайте создадим клиентский CA и воспользуемся им для подписи сертификата клиента:

# Make a self-signed client CA.openssl req -sha256 -new -x509 -days 365 -nodes \    -out client-ca.crt \    -keyout client-ca.key# Generate client CSR. CN must contain the name of the database role you# will be using to connect to the database.openssl req -sha256 -new -nodes \    -subj "/CN=alice" \    -out client.csr \    -keyout server.key# Sign a client certificate.openssl x509 -req -sha256 -days 365 \    -in client.csr \    -CA client-ca.crt \    -CAkey client-ca.key \    -CAcreateserial \    -out client.crt

Обратите внимание, что поле CommonName (CN) сертификата клиента должно содержать имя учетной записи базы данных, к которой подключается клиент. Сервер PostgreSQL будет использовать его для идентификации клиента.

Конфигурация TLS

Собрав все части вместе, теперь вы можете настроить сервер PostgreSQL для приема соединений TLS:

ssl = onssl_cert_file = '/path/to/server.crt'ssl_key_file = '/path/to/server.key'ssl_ca_file = '/path/to/client-ca.crt'# This setting is on by default but its always a good idea to# be explicit when it comes to security.ssl_prefer_server_ciphers = on# TLS 1.3 will give the strongest security and is advised when# controlling both server and clients.ssl_min_protocol_version = 'TLSv1.3'

Последняя часть настройки обновить файл host-based аутентификации сервера PostgreSQL (pg_hba.conf), чтобы требовать TLS для всех подключений и аутентифицировать клиентов с помощью сертификатов X.509:

# TYPE  DATABASE        USER            ADDRESS                 METHODhostssl all             all             ::/0                    certhostssl all             all             0.0.0.0/0               cert

Теперь пользователи, подключающиеся к серверу, должны будут предоставить действительный сертификат, подписанный клиентским CA:

psql "host=postgres.example.com \      user=alice \      dbname=postgres \      sslmode=verify-full \      sslrootcert=/path/to/server-ca.crt \      sslcert=/path/to/client.crt \      sslkey=/path/to/client.key"

Стоит обратить внимание, что по умолчанию psql не будет выполнять проверку сертификата сервера, поэтому для параметра sslmode необходимо установить значение verify-full или verify-ca, в зависимости от того, подключаетесь ли вы к серверу PostgreSQL, используя то же имя хоста, которое закодировано в поле CN его сертификата X.509.

Чтобы уменьшить размер команд и не вводить пути к сертификатам TLS каждый раз, когда вы хотите подключиться к базе данных, вы можете использовать файл службы подключения PostgreSQL. Он позволяет группировать параметры подключения в службы, на которые затем можно ссылаться в строке подключения через параметр служба.

Создайте ~/.pg_service.confсо следующим содержанием:

[example]host=postgres.example.comuser=alicesslmode=verify-fullsslrootcert=/path/to/server-ca.crtsslcert=/path/to/client.crtsslkey=/path/to/client.key

Теперь при подключении к базе данных вам нужно будет только указать имя службы и имя базы данных, к которой вы хотите подключиться:

  psql "service=example dbname=postgres"  

Безопасность на уровне базы данных

Роли

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

PostgreSQL имеет комплексную систему прав пользователя, основанную на концепции ролей. В современных версиях PostgreSQL (8.1 и новее) роль является синонимом пользователя, поэтому любое имя учетной записи базы данных, которое вы используете, скажем, с psql (например, user = alice), на самом деле является ролью с LOGIN атрибутом, который позволяет ей подключаться к базе данных. Фактически, следующие команды SQL эквивалентны:

CREATE USER alice;CREATE ROLE alice LOGIN;

Помимо возможности входа в систему, роли могут иметь иные атрибуты, позволяющие им обходить все проверки прав доступа (SUPERUSER), создавать базы данных (CREATEDB), создавать другие роли (CREATEROLE) и другие.

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

Предоставление роли прав доступа

В нашем воображаемом примере мы будем отслеживать инвентаризацию серверов:

CREATE TABLE server_inventory (    id            int PRIMARY KEY,    description   text,    ip_address    text,    environment   text,    owner         text,);

По умолчанию, конфигурация PostgreSQL включает роль суперпользователя (обычно называемую postgres), используемую для начальной загрузки базы данных. Использование этой роли для всех операций с базой данных было бы эквивалентно постоянному использованию root в Linux, что никогда не являлось хорошей идеей. Вместо этого давайте создадим непривилегированную роль и при необходимости назначим ей права доступа, следуя принципу наименьших привилегий.

Вместо того, чтобы назначать привилегии/роли каждому новому пользователю индивидуально, можно создать групповую роль и предоставить другим ролям (сопоставление с отдельными пользователями) членство в этой группе. Скажем, вы хотите разрешить вашим разработчикам, Алисе и Бобу, просматривать список серверов, но не изменять его:

-- Create a group role that doesn't have ability to login by itself and-- grant it SELECT privileged on the server inventory table.CREATE ROLE developer;GRANT SELECT ON server_inventory TO developer;-- Create two user accounts which will inherit "developer" permissions upon-- logging into the database.CREATE ROLE alice LOGIN INHERIT;CREATE ROLE bob LOGIN INHERIT;-- Assign both user account to the "developer" group role.GRANT developer TO alice, bob;

Теперь при подключении к базе данных и Алиса, и Боб унаследуют привилегии групповой роли разработчик и смогут выполнять запросы к таблице инвентаризации сервера.

Привилегия SELECT распространяется на все столбцы таблицы по умолчанию, хотя так быть не должно. Скажем, вы всего лишь хотели разрешить своим стажерам просматривать общую информацию об инвентаризации серверов, не позволяя им подключаться, скрывая IP-адрес:

CREATE ROLE intern;GRANT SELECT(id, description) ON server_inventory TO intern;CREATE ROLE charlie LOGIN INHERIT;GRANT intern TO charlie;

Другие наиболее часто используемые привилегии объектов базы данных INSERT, UPDATE, DELETE и TRUNCATE аналогичны соответствующим SQL выражениями. Также вы можете назначить права для подключения к определенным базам данных, создания новых схем или объектов в схеме, выполнения функции и так далее. Взгляните на раздел Privileges документации PostgreSQL, чтобы увидеть весь список.

Безопасность на уровне строк

Одной из наиболее продвинутых функций системы привилегий PostgreSQL является безопасность на уровне строк, которая позволяет вам предоставлять привилегии подмножеству строк в таблице. Сюда входят как строки, которые могут быть запрошены с помощью оператора SELECT, так и строки, которые могут быть результатами операторов INSERT, UPDATE и DELETE.

Чтобы начать использовать безопасность на уровне строк, вам нужны две вещи: включить ее для таблицы и определить политику, которая будет контролировать доступ на уровне строк.

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

ALTER TABLE server_inventory ENABLE ROW LEVEL SECURITY;

Без какой-либо определенной политики PostgreSQL по умолчанию использует политику запретить, что означает, что никакая роль (кроме владельца таблицы, который обычно является ролью, создавшей таблицу) не имеет к ней доступа.

Политика безопасности строк это логическое выражение, которое PostgreSQL будет применять для каждой строки, которая должна быть возвращена или обновлена. Строки, возвращаемые оператором SELECT, проверяются на соответствие выражению, указанному в разделе USING, в то время как строки, обновленные операторами INSERT, UPDATE или DELETE , проверяются на соответствие с WITH CHECK выражением.

Давайте определим пару настроек, которые позволяют пользователям видеть все серверы, но обновлять только свои собственные, определенные полем владелец:

CREATE POLICY select_all_servers    ON server_inventory FOR SELECT    USING (true);CREATE POLICY update_own_servers    ON server_inventory FOR UPDATE    USING (current_user = owner)    WITH CHECK (current_user = owner);

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

Аудит

До сих пор мы в основном говорили о превентивных мерах безопасности. Следуя краеугольным принципам безопасности defence in depth, мы рассмотрели, как они накладываются друг на друга, чтобы замедлить продвижение гипотетического злоумышленника через систему.

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

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

; Log successful and unsuccessful connection attempts.log_connections = on; Log terminated sessions.log_disconnections = on; Log all executed SQL statements.log_statement = all

К сожалению, это практически всё, что можно сделать с помощью стандартной self-hosted установки PostgreSQL из коробки. Конечно, это лучше, чем ничего, но данный метод не масштабируется дальше нескольких серверов баз данных и простого grepping.

Для более продвинутого аудита PostgreSQL вы можете использовать сторонние решения, такие как pgAudit . Если вы используете self-hosted экземпляр PostgreSQL, вам придется установить расширение вручную. Некоторые размещенные версии, такие как AWS RDS, поддерживают его прямо из коробки, поэтому вам просто нужно включить его.

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

Заключение

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

В этой статье мы рассмотрели best practices в обеспечении безопасности базы данных PostgreSQL на нескольких уровнях, начиная с сетевой и транспортной безопасности, и изучили, как использовать гибкую систему привилегий пользователей PostgreSQL.

В первой части мы рассказали про наиболее популярные пассивные средства ИБ, которые применяются для мониторинга и анализа трафика в сети. Возникает логичный вопрос: если системы умеют выявлять угрозы, то почему бы не блокировать их? Сегодня предлагаем Вам поговорить про активные средства ИБ, их применение и проблемы внедрения в современную сетевую инфраструктуру.

Активные средства безопасности

Средства активной безопасности, подключаемые в разрыв (in-line), не только обнаруживают угрозы, но и блокируют их в режиме реального времени. При внедрении активных средств специалисты сталкиваются с проблемами обеспечения отказоустойчивости сети, дальнейшей масштабируемости средств безопасности, а также с необходимостью уменьшения задержек передачи пакетов при увеличении объёма трафика в сети.

Среди наиболее популярных активных средств информационной безопасности остановимся на IPS, NGFW, SWG, AMP, DLP и Anti-DDoS, а также рассмотрим способы их развёртывания на базе Bypass и брокеров сетевых пакетов для обеспечения гарантированной безопасности сети.

Системы предотвращения вторжений (IPS)

Системы предотвращения вторжений (Intrusion Prevention Systems - IPS) это программные и аппаратные средства, предназначенные для обнаружения и предотвращения попыток несанкционированного доступа к конфиденциальным данным, повышения привилегий, использования уязвимостей программного обеспечения и вывода из строя компьютерных систем. Такие попытки вторжений осуществляются главным образом через Интернет или локальную сеть, могут иметь форму атак хакеров/инсайдеров или же быть результатом действий вредоносных программ.

IPS это логическая эволюция IDS. Однако если IPS заблокировала хороший трафик, который, как она подозревала, был плохим (ложное срабатывание), или же физически вышла из строя, нарушив целостность сети, то важные бизнес-процессы компании нарушатся. Таким образом, специалисты по ИБ должны тщательно выбирать и развёртывать IPS с большой осторожностью.

В настоящее время системы IPS активно развиваются в части сокращения числа ложных срабатываний и увеличения эффективности решения. Результатом усовершенствования можно считать так называемые IPS-системы нового поколения - NGIPS, которые выполняют все функции в режиме реального времени, никак не влияя на сетевую активность организации, и, помимо всего прочего, предоставляют возможности мониторинга приложений и использования информации из сторонних источников (например, баз уязвимостей).

В России требования к системам обнаружения вторжений (под понятием СОВ подразумеваются как пассивные IDS системы, так и активные IPS системы) появились еще в 2011 году, тогда ФСТЭК России поделила СОВ на 6 классов защиты. Отличия между классами заключаются в уровне информационных систем и непосредственно информации, которая подлежит обработке (персональные данные, конфиденциальная информация, государственная тайна). Соответствие требованиям регулятора является важным фактором при выборе СОВ, в то же время это положительно сказывается на развитии отечественного рынка IPS/IDS решений.

В пространстве IPS решений представлены продукты следующих производителей: Positive Technologies, Код Безопасности, Smart-Soft, Info Watch, Инфотекс, Stonesoft, Trend Micro, Fortinet, Cisco, HP, IBM, Juniper, McAfee, Sourcefire, Stonesoft, Trend Micro, Check Point, Palo Аlto Networks.

Межсетевые экраны нового поколения (NGFW)

Межсетевые экраны нового поколения (Next-Generation Firewall - NGFW) это эволюция типовых межсетевых экранов с возможностью отслеживания состояния соединений. Поскольку всё большее число компаний сейчас используют онлайн-приложения и службы SaaS, то классический контроль портов и протоколов уже недостаточен для обеспечения эффективной сетевой безопасности. В отличие от предыдущего поколения, в новых устройствах добавлена тесная интеграция дополнительных возможностей, таких как встроенная глубокая проверка пакетов (DPI), предотвращение вторжений (IPS) и проверка трафика на уровне приложений (Web Application Firewall). Некоторые NGFW также включают проверку зашифрованного трафика TLS/SSL, фильтрацию веб-сайтов, управление пропускной способностью, QoS, антивирусную проверку и интеграцию со сторонними системами управления идентификацией (LDAP, RADIUS и Active Directory). Решения NGFW в скором времени заменят традиционные межсетевые экраны, предотвращая вторжения и контролируя приложения как по периметру, так и внутри сети.

Производители NGFW решений: UserGate, Континент, Huawei, Check Point, Сisco, Fortinet, McAfee, Palo Alto Networks и Sourcefire.

Шлюзы информационной безопасности (SWG)

Прокси-серверы с функциями информационной безопасности (Security Web Gateway SWG), также известные как веб-фильтры это программно-аппаратные комплексы (ПО + сервер), разработанные и оптимизированные для соблюдения политик веб-безопасности компании и контроля доступа пользователей к веб-сайтам. Веб-сайты, которые содержат вредоносное ПО или неприемлемый контент (например, порнографию или азартные игры), блокируются на SWG, тем самым повышая производительность труда сотрудников, ограничивая ответственность компании и защищая компьютерные устройства пользователей от вреда.

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

Производители SWG решений: Ростелеком-Солар, Smart-Soft, UserGate, ESET, Kaspersky, Sophos, TRENDmicro, Huawei, Blue Coat, Cisco, McAfee, Trustwave и Websense.

Advanced malware protection (AMP)

Традиционные решения безопасности, такие как системы предотвращения вторжений, антивирусные продукты и шлюзы информационной безопасности предназначены для обнаружения известных угроз и эксплойтов, нацеленных на определённые уязвимости операционных систем и приложений. Однако сегодня уязвимости нулевого дня (Zero-Day Exploit - атаки, нацеленные на уязвимости, для которых ещё не разработана защита) вызывают наибольшую озабоченность компаний и правительственных учреждений.

Для защиты от этих угроз существует категория решений сетевой безопасности - AMP (Advanced Malware Protection). Основная задача AMP проверка файла, пересылаемого через сетевое устройство и/или записываемого на конечное оборудование, на наличие вредоносного кода. Система AMP осуществляет ретроспективный анализ и обеспечивает защиту не только до момента атаки или во время атаки, но и после того, как атака прошла. Кроме того, это решение позволяет отследить все пути распространения файла и может заблокировать файл на уровне сети.

Производители AMP решений: Kaspersky, Malwarebytes, Cisco, Damballa, FireEye и Palo Alto Networks.

Системы предотвращения утечки данных (DLP)

Системы предотвращения утечки данных (Data Loss Prevention или Data Leakage Prevention - DLP) это программно-аппаратные комплексы (ПО + сервер), которые предназначены для обнаружения и предотвращения потенциальных нарушений конфиденциальности данных и личной информации (номера кредитных карт, номера телефонов, данные паспорта и т. д.) путём мониторинга данных в нескольких состояниях:

• при использовании (Data-inUse) на рабочем месте пользователя

• при передаче (Data-inMotion) в сети компании

• при хранении (Data-atRest) на серверах и рабочих станциях компании

Производители DLP решений: InfoWatch, Инфосистемы Джет, SmartLine Inc, Гарда Технологии, Zecurion, Ростелеком-Солар, Falcongaze, Атом Безопастность, ESET, SearchInform, CoSoSys, Blue Coat, Check Point, Cisco (IronPort), Fidelis, McAfee, RSA, Verdasys, Symantec, Websense.

Системы предотвращения распределённого отказа в обслуживании (DDoS Protection, Anti-DDoS)

Системы предотвращения распределённого отказа в обслуживании (Distributed Denial of Service (DDoS) Protection или Anti-DDoS) это специализированные программно-аппаратные и программные средства, предназначенные для защиты веб-серверов/сайтов компании от распределённых атак типа Отказ в обслуживании.

Атака типа отказ в обслуживании (DoS) - это попытка одного компьютера сделать другой компьютер недоступным для его предполагаемых пользователей путём забивания его полосы пропускания и/или вычислительных ресурсов паразитным трафиком, часто через поток пакетов SYN или ICMP. Распределённый отказ в обслуживании (DDoS) это DoS-атака, инициируемая ботнетом (совокупностью компьютеров, называемых ботами, которые заражены зомби-агентами или троянами), обычно используется для атак на целевые веб-сайты. Все боты в данном ботнете запрограммированы на выполнение действий в точно согласованное время, как это предписано центральной системой управления и контроля (Сommand and Сontrol - С&C), управляемой преступником.

На предприятиях системы Anti-DDoS помогают выявлять и предотвращать DDoS-атаки путём использования проприетарных алгоритмов и оценки механизмов защиты.

Средства безопасности в этой области производят компании: DDOS-GUARD, СТОРМ СИСТЕМС, Variti, Гарда Технологии, Kaspersky, Inoventica Technologies, Qrator Labs, Akamai Technologies, CloudFlare, Imperva, Sucuri, F5 Networks, Arbor Networks, Cisco, Corero и VeriSign.

Типичные проблемы развёртывания систем сетевой безопасности

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

Кейс 1 Развёртывание нескольких копий активных средств безопасности для обработки трафика в современных высоконагруженных сетях 40G/100G

В настоящее время широко распространяются стандарты 40G/100G. Производители активных средств безопасности стараются не отставать и предлагают высокопроизводительные инструменты для обеспечения защиты сетей данных стандартов. К сожалению, далеко не все предлагаемые современные инструменты могут обработать трафик высоконагруженных сетей стандартов 40G/100G. А те немногие, которые способны, имеют высокую стоимость и делают это с ограничениями.

Задача: Сеть компании построена по стандарту 40G. Существующая система NGFW имеет интерфейсы 40G, но её производительности хватает только при нагрузке в сети до 30%. При повышении нагрузки в сети установленная NGFW уже не справляется и начинает терять трафик. Необходимо внедрить решение, которое будет обеспечивать работоспособность сети с использованием существующей активной системы NGFW и минимально возможными инвестициями.

Решение: Для решения данной задачи необходимы: брокер сетевых пакетов и дополнительная единица NGFW (в некоторых случаях даже менее производительная). Существующую и вновь приобретённую NGFW нужно подключить к брокеру сетевых пакетов, который, в свою очередь, подключить через Bypass к сети компании. Пакетный брокер будет балансировать получаемый из cети трафик на входы NGFW с сохранением целостности сессий и агрегировать трафик с выходов NGFW для дальнейшей передачи. Таким образом, нагрузка будет равномерно распределяться на две системы NGFW, что позволит поддерживать необходимую пропускную способность и быстродействие сети компании.

Кейс 2 Безопасное развёртывание нескольких активных средств безопасности последовательно

Многие компании для достижения более глубокой защиты корпоративной сети последовательно развёртывают несколько активных средств безопасности. Таким образом, прежде чем трафик из интернета попадёт в корпоративную сеть, он должен пройти через системы IPS, Firewall, SWG и др. и получить разрешение на дальнейшее распространение по сети. Для минимизации рисков простоя сети компании нуждаются в эффективном и безопасном способе последовательного развёртывания активных средств ИБ.

Задача: В компании, в сетевой инфраструктуре которой развёрнута система межсетевого экрана, планируется внедрить активные системы IPS и Anti-DDoS. При этом необходимо обеспечить бесперебойность работы сети при выходе из строя средств ИБ.

Решение: Для обеспечения бесперебойной работы сети наиболее эффективным вариантом будет подключение активных средств безопасности к сети через Bypass и брокер сетевых пакетов. В таком случае пакетный брокер будет маршрутизировать трафик через каждую последовательно подключённую активную систему, и если какая-либо система выйдет из строя, то брокер исключит её из последовательности. Таким образом, простоя сети не происходит, а инфраструктура по обеспечению информационной безопасности продолжает функционировать. В свою очередь, Bypass, при выходе из строя брокера сетевых пакетов, позволит сохранить целостность сети путём исключения последнего из схемы соединения.

Кейс 3 Поддержка отказоустойчивых сетевых конфигураций и активных систем информационной безопасности

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

Отказоустойчивые сетевые архитектуры требуют избыточных компонентов сетевой инфраструктуры и дополнительных единиц активных средств ИБ. Чтобы избыточность свести к минимуму и в то же время обеспечить максимальную отказоустойчивость, необходимо проектировать сеть с использованием брокера сетевых пакетов и Bypass.

Задача: В компании поставлена задача по организации отказоустойчивой конфигурации сети с активными средствами ИБ. Необходимо обеспечить бесперебойное функционирование системы ИБ в случае отказа группы систем и/или одного из элементов группы. Построенный сегмент активных средств ИБ не должен влиять на работоспособность общей сетевой инфраструктуры компании. Также требуется предусмотреть возможность дальнейшей масштабируемости и повышения производительности активных систем ИБ без изменения общей конфигурации сети.

Решение: Все требования поставленной задачи выполняются с помощью использования брокера сетевых пакетов и Bypass для подключения активных средств ИБ. Такое решение позволит уменьшить избыточность компонентов сетевой инфраструктуры, а также обеспечить более высокую отказоустойчивость системы. Брокер сетевых пакетов может эффективно маршрутизировать трафик как через каждый последовательно подключённый активный инструмент, так и через группу активных инструментов с балансировкой нагрузки. Балансировка нагрузки позволяет равномерно распределять трафик между отдельными инструментами безопасности, тем самым обеспечивая их оптимальную загрузку и повышая отказоустойчивость сети. Если какой-либо инструмент выходит из строя, то брокер сетевых пакетов исключает его из последовательности и балансирует нагрузку на оставшиеся рабочие средства безопасности. Использование Bypass в данном случае аналогично первому кейсу и, при выходе из строя брокера сетевых пакетов, позволит сохранить целостность сети путём исключения последнего из схемы соединения. Подключение активных средств безопасности через брокер сетевых пакетов также позволяет осуществлять дальнейшую масштабируемость и внедрение новых систем ИБ с минимальными затратами и простой реализацией.

Приведённые выше кейсы наглядно показывают, как брокеры сетевых пакетов и Bypass упрощают подключение активных систем ИБ к сетевой инфраструктуре и повышают надёжность работы таких сетевых конфигураций.

Резюмируя, хочется выделить преимущества применения брокеров сетевых пакетов:

• Простота интеграции, надёжность и отказоустойчивость сети

• Масштабируемость активных средств контроля трафика без усложнения топологии сети

• Постоянный мониторинг доступности каждого активного устройства ИБ и различные сценарии реагирования на аварии

• Один Bypass для нескольких активных средств

• Вариативность пропускания трафика через активные системы ИБ

• Простота внедрения новых решений в инфраструктуру

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

Кратко напомним основные тезисы:

• В CDN низкая задержка в трансляциях обеспечивается использованием технологии WebRTC для передачи видеопотока от Origin сервера к Edge серверам, которые, в свою очередь, позволяют подключить большое количество зрителей.

  

• Если постоянно держать включенными некоторое количество серверов в расчете на большой наплыв зрителей, то, в то время, когда наплыва нет, деньги на аренду серверов расходуются зря. Оптимальным вариантом было бы запускать дополнительные Edge при увеличении потока зрителей и гасить их при уменьшении.

  

Google Cloud Platform - это стек облачных сервисов, которые выполняются на той же самой инфраструктуре, которую Google использует для своих продуктов. То есть, получается, что пользовательские приложения запущенные в среде Google Cloud Platform, крутятся на тех же серверных мощностях, что и сам "великий и ужасный" Google. Поэтому, можно, с большой вероятностью, ожидать бесперебойной работы серверной инфраструктуры.

Инфраструктура Google Cloud Platform, как и в случае с AWS, поддерживает автоматическое масштабирование и балансировку распределения нагрузки, поэтому не приходится беспокоиться о лишних расходах на оплату виртуальных серверов вы платите только за то, что используете.

На момент написания статьи образа для быстрого развертывания WCS в GCP Marketplace не было. Но есть возможность автоматического развертывания WCS из образа виртуальной машины, который был подготовлен вручную. В этом случае, для WCS используется стандартная ежемесячная лицензия.

Теперь рассмотрим, как развернуть WCS CDN с балансировщиком и автоматическим масштабированием и процесс тестирования развернутой системы.

Разворачиваем WebRTC CDN с балансировщиком и автоматическим масштабированием на Google Cloud Platform

Конфигурация CDN будет следующей:

• один Origin сервер;

• один Edge в составе балансировщика нагрузки, который позволяет во время пиковой нагрузки увеличить число Edge серверов до трех.

Для развертывания потребуется настроить следующие компоненты в консоли Google Cloud Platform:

• глобальный файрволл на уровне проекта Google Cloud;

• виртуальные машины WCS CDN Origin и WCS CDN Edge;

• шаблон развертывания на основе образа диска WCS CDN Edge;

• группу масштабирования;

• балансировщик нагрузки.

Итак, приступим.

Настраиваем глобальный файрволл на уровне проекта Google Cloud для прохождения WebRTC трафика

Настройка межсетевого экрана действует на все запущенные в вашем проекте сервера, поэтому начнем развертывание с нее.

В основном меню консоли Google Cloud откройте раздел "VPC networks" и выберите пункт "Firewall":

На открывшейся странице нажмите кнопку "Create Firewall Rule" :

В открывшемся мастере задайте имя правила:

Ниже на странице разрешите входящий трафик с любых компьютеров:

Еще ниже в секции "Protocols and ports" укажите порты для работы WCS и нажмите кнопку "Create":

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

Разворачиваем WCS сервер с ролью Origin для WebRTC CDN

В консоли Google Cloud откройте раздел "Compute Engine" и выберите из меню в левой части пункт "VM instances". Нажмите кнопку "Create" в диалоге создания нового экземпляра сервера:

В открывшемся мастере укажите имя сервера, выберите регион и зону расположения датацентра, а также конфигурацию сервера. Выбор конфигурации сервера зависит от планируемых целей использования WCS, бюджета, региона и зоны расположения датацентра GCP. Для тестирования в рамках этой статьи мы используем минимальные технические характеристики виртуальных машин:

Ниже на странице в секции "Boot disk" нажмите кнопку "Change" и выберите образ "CentOS 7":

Разверните секцию "Management, security, disks, networking, sole tenancy":

На вкладке "Security" добавьте публичный ключ для доступа к серверу по SSH:

На вкладке "Networking" в секции "Network interfaces" настройте внешний и внутренний IP адреса для сервера. Для работы в составе CDN серверу нужно назначить статический внутренний IP адрес:

После всех настроек нажмите кнопку "Create" для создания нового экземпляра WCS сервера с ролью CDN Origin:

Спустя пару минут сервер будет создан и запущен. Подключаемся к нему по ssh и устанавливаем WCS. Все действия - установка, изменение настроек, запуск или перезапуск WCS - должны выполняться с root правами, либо через sudo.

1.Установите Wget, Midnight Commander и дополнительные инструменты и библиотеки

sudo yum -y install wget mc tcpdump iperf3 fontconfig

2.Установите JDK. Для работы в условиях больших нагрузок рекомендуется JDK 12 или 14. Удобнее провести установку при помощи скрипта на bash. Текст скрипта:

#!/bin/bashsudo rm -rf jdk*curl -s https://download.java.net/java/GA/jdk12.0.2/e482c34c86bd4bf8b56c0b35558996b9/10/GPL/openjdk-12.0.2_linux-x64_bin.tar.gz | tar -zx[ ! -d jdk-12.0.2/bin ] && exit 1sudo mkdir -p /usr/java[ -d /usr/java/jdk-12.0.2 ] && sudo rm -rf /usr/java/jdk-12.0.2sudo mv -f jdk-12.0.2 /usr/java[ ! -d /usr/java/jdk-12.0.2/bin ] && exit 1sudo rm -f /usr/java/defaultsudo ln -sf /usr/java/jdk-12.0.2 /usr/java/defaultsudo update-alternatives --install "/usr/bin/java" "java" "/usr/java/jdk-12.0.2/bin/java" 1sudo update-alternatives --install "/usr/bin/jstack" "jstack" "/usr/java/jdk-12.0.2/bin/jstack" 1sudo update-alternatives --install "/usr/bin/jcmd" "jcmd" "/usr/java/jdk-12.0.2/bin/jcmd" 1sudo update-alternatives --install "/usr/bin/jmap" "jmap" "/usr/java/jdk-12.0.2/bin/jmap" 1sudo update-alternatives --set "java" "/usr/java/jdk-12.0.2/bin/java"sudo update-alternatives --set "jstack" "/usr/java/jdk-12.0.2/bin/jstack"sudo update-alternatives --set "jcmd" "/usr/java/jdk-12.0.2/bin/jcmd"sudo update-alternatives --set "jmap" "/usr/java/jdk-12.0.2/bin/jmap"

3.Загрузите архив для установки самой свежей стабильной версии WebCallServer:

sudo wget https://flashphoner.com/download-wcs5.2-server.tar.gz

4.Распакуйте архив и запустите скрипт установки WCS и следуйте указаниям мастера установки. Для запуска WCS вам потребуется действительная лицензия. Для правильной работы команды, укажите номер сборки скачанного вами архива:

sudo tar -xvzf FlashphonerWebCallServer-5.2.714.tar.gz && cd FlashphonerWebCallServer-5.2.714 && ./install.sh

5.Для активации лицензии запустите скрипт "./activation.sh" из каталога установки WCS. Этот шаг, при желании, можно пропустить и активировать лицензию позже через веб-интерфейс:

sudo cd /usr/local/FlashphonerWebCallServer/bin && sudo ./activation.sh

6.Отключите firewalld и SELinux. Сетевой экран мы ранее настроили на уровне Google Cloud Platform, поэтому нет необходимости закрывать порты в операционной системе:

sudo systemctl stop firewalld && systemctl disable firewalld && setenforce 0

7.Откройте любым удобным редактором файл flashphoner.properties, который можно найти по пути:

/usr/local/FlashphonerWebCallServer/conf/flashphoner.properties

и внесите в него настройки для запуска CDN. В параметре "cdn_ip" укажите внутренний IP адрес вашей виртуальной машины с ролью CDN Origin:

cdn_enabled=truecdn_ip=10.128.0.3 # Local IP address CDN Origincdn_nodes_resolve_ip=falsecdn_role=origin

На скриншоте ниже примерный вид файла flashphoner.properties для WCS с ролью CDN Origin:

После изменения настроек запустите (или перезапустите) Web Call Server:

systemctl start webcallserver

На этом запуск и настройка Origin закончены. Перейдем к настройке балансировщика нагрузки и автоматического масштабирования.

Запускаем балансировщик нагрузки и автоматическое масштабирование в Google Cloud для WebRTC CDN

Для запуска балансировщика и автоматического масштабирования нужны следующие компоненты:

• образ диска, который будет использоваться в шаблоне при создании нового экземпляра WCS;

• шаблон, на основе которого будут создаваться новые экземпляры сервера при масштабировании;

• группа масштабирования;

• балансировщик нагрузки;

• настройки контроля активности сервера.

Создаем образ диска WCS сервера с ролью Edge для WebRTC CDN

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

Повторите инструкцию по подготовке сервера Origin до пункта о внесении настроек в файл flashphoner.properties. Для роли Edge внесите в этот файл следующие настройки:

cdn_enabled=truecdn_ip=10.128.0.4cdn_nodes_resolve_ip=falsecdn_point_of_entry=10.128.0.3cdn_role=edgehttp_enable_root_redirect=false

После внесения и сохранения настроек, остановите в консоли Google Cloud виртуальную машину WCS CDN Edge, выберите из меню в левой части пункт "Images" и нажмите кнопку "Create Image":

В открывшемся мастере укажите имя нового образа, выберите в качестве источника диск виртуальной машины WCS CDN Edge и нажмите кнопку "Create":

После того, как образ диска создан переходим к созданию шаблона развертывания Edge сервера на основе созданного образа.

Создаем шаблон развертывания Edge сервера

Выберите из меню в левой части окна консоли Google Cloud пункт "Instance templates" и нажмите кнопку "Create Instance template":

В открывшемся мастере создания шаблона развертывания укажите имя шаблона и выберите конфигурацию виртуальной машины:

Ниже на странице в секции "Boot disk" нажмите кнопку "Change". в Открывшемся окне перейдите на вкладку "Custom Images" и выберите образ диска WCS CDN Edge, который мы создали ранее. Нажмите кнопку "Select":

Разверните секцию "Management, security, disks, networking, sole tenancy". На вкладке "Security" добавьте публичный ключ для доступа к серверу по SSH и нажмите кнопку "Create":

Шаблон развертывания для WCS с ролью CDN Edge создан. Теперь перейдем к созданию группы масштабирования.

Создаем группы масштабирования для Edge серверов

Из меню в левой части окна консоли Google Cloud выберите пункт "Instance groups" и нажмите кнопку "Create Instance group":

На открывшейся странице выберите регион и зону расположения группы и укажите шаблон развертывания WCS Edge, который мы создали ранее:

В секции "Autoscaling" на этой же странице настройте триггер запуска дополнительных серверов Edge. В качестве триггера будем использовать загрузку процессора более 80% . В поле "Maximum number of instances" укажите максимальное количество виртуальных машин, которые будут запущены при срабатывании триггера:

Затем включите проверку состояния виртуальной машины в секции "Autohealing". Для того, что бы создать настройку проверки сервера выберите из списка в поле "Health check" пункт "Сreate a health check":

В открывшемся мастере создания проверки состояния сервера укажите имя проверки, протокол TCP, порт 8081 и запрос /health-check. Настройте критерии проверки и нажмите кнопку "Save and continue":

Разверните секцию "Advanced creation options" и активируйте чекбокс "Do not retry machine creation". После чего нажмите "Create":

Будет создана группа масштабирования и запущен один WCS с ролью CDN Edge. Последним этапом настройки нашей CDN с балансировщиком нагрузки и автоматическим масштабированием будет настройка балансировщика.

Создаем балансировщик нагрузки

Сначала зарезервируем для балансировщика внешний IP адрес. В главном меню Google Cloud Platform в секции "VPC network" выберите пункт "External IP addresses" и нажмите кнопку "Reserve static address":

На открывшейся странице в поле "Name" задаем имя для зарезервированного IP адреса. Выбираем уровень качества сетевых услуг для адреса и тип распространения. После завершения всех настроек нажимаем кнопку "Reserve":

Затем переходим к настройке балансировщика.

Выбираем пункт "Load balancing" в разделе "Network services" секции "Networking" основного меню Google Cloud Platform:

Нажимаем кнопку "Create load balancer":

Затем выберите тип балансировщика "TCP Load Balancing" и нажмите кнопку "Start configuration":

На открывшейся странице укажите внешний балансировщик "From Internet to my VMs" и регион размещения серверов балансировщика. После выбора настроек нажмите кнопку "Continue":

На следующей странице задайте имя балансировщика, Затем перейдите в раздел настроек "Backend configuration" и укажите в каком регионе будут созданы сервера входящие в состав балансировщика. На вкладке "Select existing instance groups" выберите группу масштабирования Edge серверов, которую мы создали ранее. Затем в поле "Health check"выберите из выпадающего списка пункт "Сreate a health check":

На открывшейся странице укажите параметры для проверки состояния работы балансировщика порт 8081 и запрос /, после чего нажмите кнопку "Save and continue":

Затем перейдите к настройкам раздела "Frontend configuration". В этом разделе нужно создать привязку портов к внешнему IP адресу. Укажите внешний IP адрес для балансировщика, который мы зарезервировали выше и создайте конфигурации для TCP портов 8081, 8080, 8443, 8444 для HTTP(S) и WS(S). После создания необходимых портов нажмите кнопку "Create":

Балансировщик будет запущен. На этом развертывание CDN с балансировщиком и масштабированием можно считать завершенным. Переходим к тестированию.

Тестирование WebRTC CDN с балансировщиком и масштабированием на базе Google Cloud Platform

Методика тестирования

Для проведения нагрузочного тестирования, при создании группы масштабирования мы выставили порог загрузки процессора для срабатывания триггера на 20%. Тестирование будем проводить с использованием браузера Google Chrome и виртуальной вебкамеры для организации трансляции видеопотока. Что бы сымитировать повышение нагрузки на процессор запустим воспроизведение потока с транскодированием с помощью примера "Media Devices".

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

Тестирование

В браузере Google Chrome открываем web интерфейс WCS с ролью CDN Origin Авторизуемся, открываем пример "Two-way Streaming", устанавливаем соединение с сервером по WebSocket и публикуем видеопоток.

Затем, запускаем web интерфейс WCS CDN Edge сервера по IP адресу, который был зарезервирован при создании балансировщика.

Авторизуемся, открываем пример "Media Devices" и устанавливаем соединение с балансировщиком по WebSocket. В правом столбце настроек снимаем чек бокс "default" для параметра "Size" и задаем значения для транскодирования видеопотока. Например, если поток на Origin сервере опубликован с размерами 320х240 задаем значение 640х480. Повторите действия в нескольких вкладках браузера, для имитации большого количества зрителей.

В консоли Google Cloud видим, что были запущены две дополнительные виртуальные машины:

Для того, что бы проверить, что балансировщик распределяет соединения между активными ВМ можно использовать страницу статистики, которая доступна по адресу:

http://<WCS instance IP address>:8081/?action=stat

Откройте страницу статистики для каждой виртуальной машины, запущенной балансировщиком. Значение "connection_websocket" показывает количество активных WebSocket сессий на каждой виртуальной машине.

Как видите на скриншотах наша задача успешно решена. CDN работает, дополнительные Edge сервера запускаются и WebSocket соединения распределяются между ними. В итоге, мы создали CDN в которой при увеличении нагрузки на сервер Edge, автоматически разворачиваются дополнительные виртуальных сервера для распределения нагрузки и сохранения низкой задержки в видеотрансляции.

Хорошего стриминга!

Ссылки

Наш демо сервер

CDN для стриминга WebRTC с низкой задержкой - CDN на базе WCS

Документация по быстрому развертыванию и тестированию WCS сервера

Документация по развертыванию WCS в Google Cloud Platform

Документация по настройке балансировки нагрузки с масштабированием в GCP

Привет, Хабр. В рамках курса Network engineer подготовили авторскую статью.

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

Шифрование это наиболее популярный способ для защиты сетевого взаимодействия. Статья расскажет об актуальных методах расшифровки данных, которые передаются во время взаимодействия с web-приложениями. Будут рассмотрены примеры расшифровки в зависимости от стартовых условий (наличие ключей шифрования, сертификатов и уязвимостей в схеме передачи информации).

Проблематика и история

Разберемся немного с проблематикой и терминологией. На сегодняшний день наиболее популярными технологиями, которые применяются для шифрования данных, передаваемых по сети, являются SSL и TLS. Последняя сейчас является стандартом дефакто для взаимодействия по протоколу HTTPS. Кстати, именно в расшифровке этого протокола и будет заключаться практическая часть данной статьи. Для понимания процесса расшифровки данных мы должны знать такие понятия как:

• Симметричная криптография

• Ассиметричная криптография

• Сертификат

• Хранилище сертификатов

• HSTS или Strict Transport Security технология, которая включена в современных браузерах для контроля над обязательным использованием HTTPS для взаимодействия с сервером.

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

Практика

Практику будем проводить с использованием виртуальной лаборатории. Состав лаборатории:

• Virtual Box;

• Windows 8.1;

• Ubuntu Server 20.04

Также для тестирования способов расшифровки трафика будем использовать устройство iPhonе SE.

Все машины должны быть подключены к сети "NAT Network". Именно этот тип подключения позволяет моделировать близкую к реальной топологию сети. В схеме есть хосты, которые могут взаимодействовать друг с другом, и есть хост, который используется как точка доступа в сеть Интернет. Приступим к практике.

Расшифровка трафика с использованием SQUID

Squid программное обеспечение, которая эмулирует функцию кэширующего сервера. Может быть использована для распределения нагрузки и логирования действий пользователей по протоколу HTTP в сети, кстати, и с HTTPS это ПО работать тоже умеет. Воспользуемся этой его функцией. К сожалению, использовать squid из репозитория не получится, необходимо собрать его самостоятельно:

```sh wget http://www.squid-cache.org/Versions/v4/squid-4.5.tar.gztar -xvzf squid-4.5.tar.gzcd squid-4.5./configure --with-openssl --enable-ssl-crtd --prefix=/usr/local/squidmakemake allmake install```

Самый действенный способ расшифровки взаимодействия между сервером и клиентом на сегодня это добавление доверенного корневого сертификата, поэтому перед началом расшифровки нужно его сгенерировать:

```sh cd /etc/squidmkdir ssl_certchown squid:squid -R ssl_certchmod 700 ssl_certcd ssl_certopenssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -extensions v3_ca -keyout myCA.pem  -out myCA.pemopenssl x509 -in myCA.pem -outform DER -out myCA.der```

Файл сертификата myCA.der можно использовать для браузера. Устанавливаем его в локальное хранилище и прописываем в качестве прокси сервер squid.

Настроим ссылку на вновь скомпилированный файл squid:

```shln -s /usr/local/squid/sbin/squid /usr/local/bin/squid```

Проинициализируем директорию для кэша:

```/usr/local/squid/libexec/security_file_certgen -c -s /var/lib/ssl_db -M 4MBchown squid:squid -R /var/lib/ssl_db```

Модифицируем конфиг:

```shnano /usr/local/squid/etc/squid.conf```

Должен получить следующий листинг:

```shacl SSL_ports port 443acl CONNECT method CONNECTacl manager proto cache_objecthttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow localhost managerhttp_access deny managerhttp_access allow localnethttp_access allow localhosthttp_access deny allhttp_port 3128cache_dir ufs /usr/local/squid/var/cache/squid 100 16 256coredump_dir /usr/local/squid/var/cache/squidrefresh_pattern ^ftp:144020%10080refresh_pattern ^gopher:14400%1440refresh_pattern -i (/cgi-bin/|\?) 00%0refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% 432000 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.index.(html|htm)$ 0 40% 10080refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320refresh_pattern -i youtube.com/.* 10080 90% 43200refresh_pattern (/cgi-bin/|\?) 0 0% 0refresh_pattern .020%4320http_port 3128 ssl-bump \  cert=/etc/squid/ssl_cert/myCA.pem \  generate-host-certificates=on dynamic_cert_mem_cache_size=4MBsslcrtd_program /usr/local/squid/libexec/security_file_certgen -s /var/lib/ssl_db -M 4MBacl step1 at_step SslBump1ssl_bump peek allssl_bump stare allssl_bump bump allcache allow allaccess_log stdio:/usr/local/squid/var/logs/access.log combinedcache_store_log stdio:/usr/local/squid/var/logs/store.logcache_log stdio:/usr/local/squid/var/logs/cache.log```

Запускаем squid:

```shsquid -d 10 && tail -f /usr/local/squid/var/logs/access.log```

Результат проксирования:

Расшифровка взаимодействия с использованием CharlesProxy

В этом эксперименте будем использовать настоящую WiFi сеть с подключенным к нему устройством iPhone SE. Для расшифровки сетевого взаимодействия будем использовать специализированные программные продукты. Например charlesProxy. Продукт платный, но предоставляет бесплатный период использования. После запуска нужно выбрать опцию "Proxy > Start SSL Proxying":

После этого станет доступна ссылка на корневой сертификат для браузера или другого сетевого устройства. Установим сертификат на устройство:

После установки в в качестве доверенного в браузере или на устройстве, можно увидеть следующий результат:

Вывод

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

Узнать подробнее о курсе Network engineer.

Смотреть открытый вебинар на тему NAT не Firewall.