книги хакеры / Trabelsi_Setevye-ataki-i-zashchita_RuLit_Me_676546

−− На следующем снимке экрана показано правило фильтрации, реализованное в устройстве Juniper Networks для политики безопасности (SP # 2). Столбец “Action” указывает, что правило использует Deep Inspection:

3.Security Policy #3 (SP#3): Хостам LAN#1 не разрешено отправлять электронные письма, содержащие строку «хакер» в любой строке заголовка электронного письма. Эта политика безопасности связана с проверкой данных полезной нагрузки трафика электронной почты

(SMTP).

−−Для этой политики безопасности (SP # 3) требуется одна подпись атаки. В сигнатуре атаки указывается, что данные полезной нагрузки SMTP-трафика проверяются для проверки того,

содержат ли строки заголовка электронной почты строку «хакер». Следовательно, контекст атаки - «SMTP Any Header Line», а шаблон атаки - “.*hacker.*” (Скриншот ниже)

−− Затем создается группа атак, включающая вышеуказанную сигнатуру атаки, как показано ниже.

На следующем снимке экрана показано правило фильтрации, реализованное на устройстве Juniper Networks для политики безопасности (SP # 3). Столбец «Action» указывает, что правило использует Deep Inspection.

4.Security Policy #4 (SP #4): Хостам LAN#3 не разрешено получать электронные письма, содержащие строку «kill» в строке заголовка темы. Эта политика безопасности связана с проверкой данных полезной нагрузки трафика электронной почты (POP3).

−−Для этой политики безопасности (SP # 4) требуется одна подпись атаки. В сигнатуре атаки указано, что данные полезной нагрузки

трафика POP3 проверяются, чтобы проверить, содержит ли строка заголовка темы электронной почты строку «kill». Следовательно,

контекст атаки - “PO3 Subject Header”, а шаблон атаки - “.*kill.*” (Скриншот ниже).

−− Затем создается группа атак, включающая вышеуказанную сигнатуру атаки, как показано ниже.

−− На следующем снимке экрана показано правило фильтрации, реализованное в устройстве Juniper Networks для политики безопасности (SP#4). Столбец «Action» указывает, что правило использует Deep Inspection.

7.6 Лабораторная работа 7.5: фильтрация пакетов без сохранения состояния и против состояния

7.6.1 Результат

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

7.6.2 Проблемы безопасности с фильтрацией пакетов без сохранения состояния

Интернет-сервисы, основанные на технологии клиент / сервер (например, Интернет, FTP и электронная почта), являются двунаправленными. Очевидно, что правила фильтрации, относящиеся к двунаправленной услуге, должны позволять обоим направлениям трафика пересекать межсетевой экран. Комбинации пакетов, проходящих в обоих направлениях в службах TCP и UDP, называются сеансами TCP и UDP соответственно. У сеанса TCP или UDP есть клиент, который является компьютером, который инициирует сеанс и сервер, который является компьютером, на котором размещается служба. Например, следующее единственное правило фильтрации должно разрешать двунаправленный трафик между веб-клиентами с IP-адресами 192.168.1.1/24 и вебсерверами с IP-адресами 192.168.2.1/24 для прохождения через межсетевой экран:

Сеанс TCP или UDP характеризуется четырьмя атрибутами, а именно: IP-адрес клиента, IP-адрес сервера, порт клиента (известный как порт источника) и порт сервера (известный как порт назначения). Как правило, номер порта сервера позволяет определить характер предлагаемой услуги. Например, веб-сеанс и сеанс Telnet почти всегда находятся на портах TCP 80 и 23 соответственно. Однако клиентский порт обычно выбирается динамически во время выполнения операционной системой клиентского хоста, и он больше 1023. Следовательно, номер клиентского порта по существу непредсказуем. Важно отметить, что, поскольку порт клиента непредсказуем, брандмауэр должен позволять любому потоку сеанса с любым портом источника пересекать брандмауэр. Следовательно, при базовой фильтрации пакетов это привело бы к очень серьезной уязвимости в системе безопасности, которая позволяет вредоносным хостам заполнять целевые серверы нежелательным трафиком, который может вызвать атаку DoS (отказ в обслуживании). Чтобы лучше анатомировать эту проблему безопасности, мы предполагаем следующие две политики безопасности:

*Политика безопасности (SP # 1): Мы хотим, чтобы наши внутренние хосты с IP-адресами 192.168.1.1/24 имели доступ к любому внешнему веб-серверу (прослушивающему порт TCP 80) с

IP-адресами 192.168.2.1/24.

*Политика безопасности (SP # 2): Кроме того, мы хотим запретить любому внешнему хосту (192.168.2.1/24) устанавливать соединения TCP с нашими внутренними хостами (192.168.1.1/24).

Первая политика безопасности (SP # 1) позволяет внутренним хостам устанавливать веб-соединения с любым внешним сервером. Однако вторая политика безопасности (SP # 2) не позволяет внешним хостам устанавливать TCP-соединения на внутренних серверах и, следовательно, защищает внутренние серверы от атак TCP SYN flood. Кроме того, в случае, если внутренние узлы заражены вирусами на основе программ с дистанционным управлением, такими как троянские кони, вторая политика безопасности предотвращает удаленное подключение злоумышленников к зараженному внутреннему узлу. Вирусы на основе программ с дистанционным управлением представляют собой очень серьезную угрозу, поскольку они позволяют злонамеренным пользователям полностью контролировать удаленные хосты-жертвы.

Клиент-серверные пакеты:

Source IP = 192.168.1.1/24, Destination IP = 192.168.2.1/24, Source port = Y, Destination port = 80,

где 192.168.1.1/24 - возможные IP-адреса веб-клиентов, 192.168.2.1/24 -

возможные IP-адреса веб-серверов, а Y - произвольный номер порта, выбранный веб-клиентом.

С другой стороны, возврат трафика с веб-серверов на веб-клиенты (сервер-клиент) меняет местами IP-адреса и номера портов и выглядит следующим образом:

Source IP = 192.168.2.1/24, Destination IP = 192.168.1.1/24, Source port = 80, Destination port = Y.

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

*Клиент отправляет сообщение SYN и переходит в состояние

SYN_ SENT.

*Сервер отправляет сообщение, которое объединяет ACK для SYN клиента, содержит SYN сервера и переходит в состояние SYN_RCVD.

*Клиент отправляет ACK для SYN сервера и переходит в

состояние ESTABLISHED.

* После получения сообщения ACK сервер переходит в состояние

ESTABLISHED.

После установления TCP-соединения все обмениваемые пакеты будут иметь установленный флаг ACK и неустановленный флаг SYN (рисунок ниже).

Поэтому, если мы рассмотрим только флаги SYN и ACK, в TCPсоединении будут передаваться только четыре типа пакетов TCP:

*Пакет клиент-сервер: TCP-пакет с установленным флагом SYN и не установленным флагом ACK.

*Пакет сервер-клиент: TCP-пакет с установленными флагами

SYN и ACK.

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

Например, правила фильтрации для двух вышеуказанных политик безопасности SP#1 и SP#2, соответственно

К сожалению, злоумышленник может использовать правила 2 и 4 для проведения DoS-атак, поскольку эти два правила соответствуют пакетам на основе их исходных портов. Помните, что порт источника находится под контролем отправителя пакета. Злоумышленник на любом хосте с поддельным IP-адресом 192.168.2.1/24 может создать поддельные пакеты с портом источника 80, назначить любой хост с IP-адресом 192.168.1.1/24 и порт назначения по своему выбору. Поддельные пакеты, созданные таким образом, будут проходить через брандмауэр, потому что они соответствуют либо правилу 2, если установлены их флаги SYN и ACK, либо правилу 4, если их флаг SYN не установлен и их флаг ACK установлен. Например, ниже показан пример пакета TCP, который

отклоняется брандмауэром, так как пакет пытается установить вебсоединение с внутренним хостом. Пакет отклоняется по правилу 5 приведенного выше списка правил фильтрации (предыдущий снимок экрана).

Однако ниже приведен пример вредоносного TCP-пакета, который разрешен брандмауэром для прохождения. Вредоносный пакет TCP делает вид, что соединение TCP с исходным портом 9000 уже установлено, поскольку его флаг SYN не установлен и установлен флаг

ACK.

На основании приведенного выше списка правил фильтрации брандмауэр разрешит прохождение вредоносного пакета. Следовательно, заполнение целевого внутреннего хоста такими вредоносными TCPпакетами может создать ситуацию атаки DoS на целевом хосте (см. рисунок ниже).