Межсетевое экранирование
Лапонина Ольга Робертовна

Содержание


Лекция 1. Классификация firewall’ов и определение политики firewall’а

Исследуются существующие технологии firewall’ов: пакетные фильтры, stateful inspection firewall’ы, прокси прикладного уровня. Рассматривается также сервис NAT. Приводятся примеры использования firewall’ов различного типа: выделенные прокси-серверы, host-based firewall’ы, персональные firewall’ы.

Введение

Firewall’ы защищают компьютеры и сети от попыток несанкционированного доступа с использованием уязвимых мест, существующих в семействе протоколов ТСР/IP. Дополнительно они помогают решать проблемы безопасности, связанные с использованием уязвимых систем и с наличием большого числа компьютеров в локальной сети. Существует несколько типов firewall’ов, начиная от пакетных фильтров, встроенных в пограничные роутеры, которые могут обеспечивать управление доступом для IP-пакетов, до мощных firewall’ов, которые могут закрывать уязвимости в большом количестве уровней семейства протоколов ТСР/IP, и еще более мощных firewall'ов, которые могут фильтровать трафик на основании всего содержимого пакета.

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

Современные firewall’ы могут работать совместно с такими инструментальными средствами, как системы обнаружения проникновений и сканеры содержимого e-mail или web с целью нахождения вирусов или опасного прикладного кода. Но в отдельности firewall не обеспечивает полной защиты от всех проблем, порожденных Интернетом. Как результат, firewall’ы являются только одной частью архитектуры информационной безопасности. Обычно они рассматриваются как первая линия обороны, однако их лучше воспринимать как последнюю линию обороны в организации; организация в первую очередь должна делать безопасными свои внутренние системы. Для внутренних серверов, персональных компьютеров и других систем должны своевременно выполняться все обновления как самих систем, так и других систем обеспечения безопасности, например, антивирусного ПО.

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

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

Сначала сделаем обзор стека протоколов OSI и покажем, на каком уровне функционируют различные типы firewall’ов, такие как пакетные фильтры, stateful inspection firewall’ы и прикладные прокси.

Затем опишем различные окружения firewall’а, например, комбинации конкретных компонентов обеспечивающие то или иное решение. Приведем примеры расположения firewall’ов и их взаимодействий с другими инструментальными средствами безопасности. Также опишем прочие функции современных firewall’ов, такие как использование их в качестве конечных точек VPN, трансляция IP-адресов, фильтрация содержимого web или e-mail.

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

Классификация firewall’ов

Firewall’ы являются устройствами или системами, которые управляют потоком сетевого трафика между сетями с различными требованиями к безопасности. В большинстве современных приложений firewall’ы и их окружения обсуждаются в контексте соединений в Интернете и, следовательно, использования стека протоколов ТСР/IP. Однако firewall’ы применяются и в сетевых окружениях, которые не требуют обязательного подключения к Интернету. Например, многие корпоративные сети предприятия ставят firewall’ы для ограничения соединений из и во внутренние сети, обрабатывающие информацию разного уровня чувствительности, такую как бухгалтерская информация или информация о заказчиках. Ставя firewall’ы для контроля соединений с этими областями, организация может предотвратить неавторизованный доступ к соответствующим системам и ресурсам внутри чувствительных областей. Тем самым, использование firewall’а обеспечивает дополнительный уровень безопасности, который иначе не может быть достигнут.

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

Стек протоколов модели OSI определяется следующим образом:

Таблица 1.1. Стек протоколов модели OSI
Уровень 7Application
Уровень 6Presentation
Уровень 5Session
Уровень 4Transport
Уровень 3Network
Уровень 2Data Link
Уровень 1Physical

Уровень 1 представляет собой реальную аппаратуру физического соединения и среду, такую как Ethernet. Уровень 2 — уровень, на котором сетевой трафик передается по локальной сети (LAN). Он также является первым уровнем, обладающим возможностью адресации, с помощью которой можно идентифицировать отдельную машину. Адреса назначаются на сетевые интерфейсы и называются МАС (Media Access Control) адресами. Ethernet-адрес, принадлежащий Ethernet-карте, является примером МАС-адреса уровня 2.

Уровень 3 является уровнем, отвечающим за доставку сетевого трафика по WAN. В Интернете адреса уровня 3 называются IP-адресами; адреса обычно являются уникальными, но при определенных обстоятельствах, например, при трансляции сетевых адресов (NAT) возможны ситуации, когда различные физические системы имеют один и тот же IP-адрес уровня 3. Уровень 4 идентифицирует конкретное сетевое приложение и коммуникационную сессию в дополнение к сетевым адресам; система может иметь большое число сессий уровня 4 с другими ОС. Терминология, связанная с семейством протоколов ТСР/IP, включает понятие портов, которые могут рассматриваться как конечные точки сессий: номер порта источника определяет коммуникационную сессию на исходной системе; номер порта назначения определяет коммуникационную сессию системы назначения. Более высокие уровни (5, 6 и 7) представляют приложения и системы конечного пользователя.

Стек протоколов TCP/IP соотносится с уровнями модели OSI следующим образом:

Таблица 1.2. Взаимосвязь уровней стека протоколов TCP/IP и OSI
Уровень 7ApplicationПочтовые клиенты, web-браузеры
Уровень 4TransportТСР-сессии
Уровень 3NetworkIP-адресация
Уровень 2Data LinkEthernet-адресация

Современные firewall’ы функционируют на любом из перечисленных уровней. Первоначально firewall’ы анализировали меньшее число уровней; теперь более мощные из них охватывают большее число уровней. С точки зрения функциональности, firewall, имеющий возможность анализировать большее число уровней, является более совершенным и эффективным. За счет охвата дополнительного уровня также увеличивается возможность более тонкой настройки конфигурации firewall’а. Возможность анализировать более высокие уровни позволяет firewall’у предоставлять сервисы, которые ориентированы на пользователя, например, аутентификация пользователя. Firewall, который функционирует на уровнях 2, 3 и 4, не имеет дело с подобной аутентификацией.

Независимо от архитектуры firewall может иметь дополнительные сервисы. Эти сервисы включают трансляцию сетевых адресов (NAT), поддержку протокола динамической конфигурации хоста (DHCP) и функции шифрования, тем самым являясь конечной точкой VPN-шлюза, и фильтрацию на уровне содержимого приложения.

Многие современные firewall’ы могут функционировать как VPN-шлюзы. Таким образом, организация может посылать незашифрованный сетевой трафик от системы, расположенной позади firewall’а, к удаленной системе, расположенной позади корпоративного VPN-шлюза; firewall зашифрует трафик и перенаправит его на удаленный VPN-шлюз, который расшифрует его и передаст целевой системе. Большинство наиболее популярных firewall’ов сегодня совмещают эти функциональности.

Многие firewall’ы также включают различные технологии фильтрации активного содержимого. Данный механизм отличается от обычной функции firewall’а тем, что firewall теперь также имеет возможность фильтровать реальные прикладные данные на уровне 7, которые проходят через него. Например, данный механизм может быть использован для сканирования на предмет наличия вирусов в файлах, присоединенных к почтовому сообщению. Он также может применяться для фильтрации наиболее опасных технологий активного содержимого в web, таких как Java, JavaScript и ActiveX. Или он может быть использован для фильтрации содержимого или ключевых слов с целью ограничения доступа к неподходящим сайтам или доменам. Тем не менее компонент фильтрации, встроенный в firewall, не должен рассматриваться как единственно возможный механизм фильтрации содержимого; возможно применение аналогичных фильтров при использовании сжатия, шифрования или других технологий.

Установление ТСР-соединения

ТСР является надежным протоколом в сетях, основанных на коммутации пакетов. Так как и пакетные фильтры, и stateful inspection firewall’ы анализируют параметры ТСР-протокола, рассмотрим подробно этот протокол. Стек протоколов TCP/IP выглядит следующим образом:

Таблица 1.3. Стек протоколов TCP/IP
Прикладной уровень
ТСР
IP
Коммуникационная сеть

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

Протокол ТСР обеспечивает надежность и упорядоченность для получателя потока данных, посылаемого по ТСР-соединению.

Надежность обеспечивается с помощью того, что каждый пакет содержит свой последовательный номер и номер полученного пакета. С каждым пакетом данных связывается последовательный номер. Этот номер указывается для первого пакета данных в передаваемом сегменте. Сегменты также содержат номер подтверждения, который является последовательным номером следующего ожидаемого октета данных, передаваемых в обратном направлении. Когда один из концов ТСР-соединения передает сегмент, содержащий данные, он помещает его копию в очередь повторной передачи и запускает таймер; когда подтверждение о получении этих данных получено, сегмент удаляется из очереди. Если подтверждение не получено по истечении таймера, сегмент передается повторно.

Для идентификации начальной и конечной точек ТСР-соединения вводится понятие номера порта. Номера портов выбираются независимо для каждого соединения ТСР, при этом они могут не быть уникальными. Для обеспечения уникальной идентификации внутри каждого соединения ТСР, выполняется конкатенация IP-адреса и номера порта. Эта конкатенация определяет сокет.

Соединение полностью определяется парой сокетов на своих концах. Локальный сокет может участвовать во многих соединениях с различными удаленными сокетами. Соединение используется для пересылки данных в обоих направлениях.

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

Каждый конец ТСР-соединения является либо клиентом, либо сервером. Соединение инициируется клиентом. Сервер ждет установления соединения от клиента. Поэтому ТСР-соединение может быть открыто либо в пассивном режиме — сервером, либо в активном — клиентом.

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

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

Процедура установления соединений использует флаг управления синхронизацией ( SYN ) и включает обмен тремя сообщениями.

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

Очистка соединения включает обмен сегментами, содержащими управляющий флаг FIN.

ТСР-сегменты посылаются в виде датаграмм. Заголовок IP содержит несколько полей, включая адреса хостов источника и получателя. ТСР-заголовок следует за IP-заголовком и содержит информацию, специфичную для ТСР.

Таблица 1.4. Формат заголовка ТСР
Порт источникаПорт получателя
Sequence Number
Acknowledgement Number
Data OffsetReserved
URGACKPSHRSTSYNFIN
Window
ChecksumUrgent Pointer
Options Padding
Данные

Порт источника – 16 бит.

Порт получателя – 16 бит.

Sequence Number – 32 бита. Последовательный номер первого октета данных в данном сегменте. Исключением является случай, когда присутствует флаг SYN. В этом случае последовательный номер есть начальный последовательный номер (Initial Sequence Number — ISN), и номер первого октета данных равен ISN+1.

Acknowledgement Number – 32 бита. Если установлен управляющий бит ACK, то данное поле содержит значение следующего последовательного номера, который ждет получатель. Это значение посылается всегда, если соединение установлено.

Data Offset – 4 бита. Число 32-битных слов в ТСР-заголовке. Оно определяет положение начала данных. Длина ТСР-заголовка всегда кратна 32.

Управляющие биты: 6 бит.

URG — указывает, что сегмент содержит экстренные данные и поле Urgent Pointer заголовка определяет их положение в сегменте.

ACK — указывает, что поле номера подтверждения содержит номер последнего полученного сегмента.

PSH — указывает, что данные из буфера могут быть переданы немедленно.

RST — указывает на необходимость сброса соединения.

SYN — указывает, что выполняется синхронизация последовательных номеров.

FIN — указывает, что от отправителя больше не будут передаваться данные.

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

Checksum – 16 бит. Контрольная сумма всех слов в заголовке и данных.

Urgent Pointer – 16 бит. Данное поле содержит положительное смещение экстренных данных относительно последовательного номера в данном сегменте.

Options – переменной длины. Опции могут быть указаны в конце ТСР-заголовка. Определены два варианта формата опций:

Padding – переменной длины. Данное добавление ТСР-заголовка используется для того, чтобы гарантировать, что ТСР-заголовок кончается, и данные начинаются на 32-битной границе.

Установление ТСР-соединения происходит с использованием так называемого "тройного рукопожатия". Соединение инициирует клиент, посылая сообщение с установленным битом SYN. Сервер отвечает клиенту сообщением с установленными битами SYN и ACK. Сервер также указывает начальный порядковый номер в поле Sequence Number. Наконец, клиент посылает серверу сообщение с установленным битом ACK, в поле Sequence Number указывает свой начальный номер, в поле Acknowledgement Number указывает полученный от сервера начальный порядковый номер, увеличенный на единицу.

В течение своего жизненного цикла соединение проходит через несколько состояний.

На стороне клиента:

CLOSED

SYN-SENT

ESTABLISHED

FIN-WAIT-1

CLOSE-WAIT

CLOSING

LAST-ACK

CLOSED,

На стороне сервера:

CLOSED

LISTEN

SYN-REСEIVED

ESTABLISHED

FIN-WAIT-1

CLOSE-WAIT

CLOSING

FIN-WAIT-2

TIME-WAIT

CLOSED

Рассмотрим смысл каждого состояния.

Состояние CLOSED является фиктивным, потому что оно представляет собой состояние, для которого не существует структуры данных Transmission Control Block (ТСВ) и, следовательно, нет соединения.

LISTEN – состояние сервера, которое представляет собой ожидание запроса соединения от любой удаленной стороны.

SYN-SENT – состояние клиента, которое представляет собой ожидание ответа на запрос соответствующего соединения после того как послан запрос на соединение.

SYN-RECEIVED – состояние сервера, которое представляет собой ожидание подтверждения на запрос соединения после того как и клиент, и сервер получили и послали запрос на соединение.

ESTABLISHED – состояние как клиента, так и сервера, которое представляет собой открытое соединение: полученные данные могут быть доставлены на прикладной уровень. Обычное состояние для фазы пересылки данных по соединению.

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

FIN-WAIT-1 – состояние как клиента, так и сервера, при котором сторона, инициировавшая закрытие (был послан пакет в флагом FIN ), ожидает подтверждения на запрос закрытия соединения.

CLOSE-WAIT – состояние как клиента, так и сервера, при котором было послано подтверждение ACK на запрос закрытия ( FIN ). При этом канал становится симплексным: передача возможна только в одном направлении – от того, кто послал подтверждение ACK. Происходит ожидание закрытия канала от локального процесса.

FIN-WAIT-2 — состояние как клиента, так и сервера, при котором было получено подтверждение ACK запроса закрытия соединения от удаленной стороны. При получении пакета с установленным флагом FIN канал считается окончательно разрушенным.

LAST-ACK – состояние как клиента, так и сервера, представляет собой подтверждение (пакет с установленным флагом FIN ) завершения соединения, ранее посланного удаленной стороне.

CLOSING – представляет собой ожидание подтверждения запроса завершения соединения от удаленной стороны.

TIME-WAIT – представляет собой ожидание определенное время, чтобы быть уверенным, что удаленная сторона получила подтверждение вашего запроса на закрытие соединения.

ТСР-соединение переходит из одного состояния в другое в результате возникновения событий. Событиями являются вызовы функций OPEN, SEND, RECEIVE, CLOSE, ABORT и STATUS, входящие сегменты, содержащие флаги SYN, ACK, RST и FIN, а также таймауты.

Пакетные фильтры

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

Вначале пакетные фильтры функционировали на уровне 3 (Network) модели OSI. Данная функциональность разработана для обеспечения управления сетевым доступом, основываясь на нескольких блоках информации, содержащихся в сетевом пакете. В настоящее время все пакетные фильтры также анализируют и уровень 4 (Transport).

Пакетные фильтры анализируют следующую информацию, содержащуюся в заголовках пакетов 3-го и 4-го уровней:

Пакетные фильтры обычно размещаются в сетевой инфраструктуре, использующей ТСР/IP. Однако они могут также быть размещены в любой сетевой инфраструктуре, которая имеет адресацию уровня 3, например, IPX (Novell NetWare) сети. В современных сетевых инфраструктурах firewall’ы на уровне 2 могут также использоваться для обеспечения балансировки нагрузки и/или в приложениях с высокими требованиями к доступности, в которых два или более firewall’а используются для увеличения пропускной способности или для выполнения восстановительных операций.

Некоторые пакетные фильтры, встроенные в роутеры, могут также фильтровать сетевой трафик, основываясь на определенных характеристиках этого трафика, для предотвращения DoS- и DDoS-атак.

Пакетные фильтры могут быть реализованы в следующих компонентах сетевой инфраструктуры:

Пограничные роутеры

Основным преимуществом пакетных фильтров является их скорость. Так как пакетные фильтры обычно проверяют данные до уровня 3 модели OSI, они могут функционировать очень быстро. Также пакетные фильтры имеют возможность блокировать DoS-атаки и связанные с ними атаки. По этим причинам пакетные фильтры, встроенные в пограничные роутеры, идеальны для размещения на границе с сетью с меньшей степенью доверия. Пакетные фильтры, встроенные в пограничные роутеры, могут блокировать основные атаки, фильтруя нежелательные протоколы, выполняя простейший контроль доступа на уровне сессий и затем передавая трафик другим firewall’ам для проверки более высоких уровней стека OSI.

Использование пограничного роутера с возможностями пакетного фильтра


Рис. 1.1.  Использование пограничного роутера с возможностями пакетного фильтра

На рис. 1.1 показана топология сети, использующая пограничный роутер с возможностями пакетного фильтра в качестве первой линии обороны. Роутер принимает пакеты от недоверяемой сети, которые обычно приходят от другого роутера или от Интернет Сервис Провайдера (ISP). Затем роутер выполняет контроль доступа в соответствии со своей политикой, например, блокирует SNMP, разрешает НТТР и т.п. Затем он передает пакеты более мощному firewall’у для дальнейшего управления доступом и фильтрования операций на более высоких уровнях стека OSI. На рис. 1.1 также показана промежуточная сеть между пограничным роутером и внутреннем firewall’ом, называемая DMZ-сетью.

Преимущества пакетных фильтров:

Недостатки пакетных фильтров:

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

Так как современная технология firewall’а включает много возможностей и функциональностей, трудно найти firewall, который имеет возможности только пакетного фильтра. Примером может являться сетевой роутер, осуществляющий проверку списка контроля доступа для управления сетевым трафиком. Высокая производительность пакетных фильтров также способствует тому, что они реализуются в устройствах, обеспечивающих высокую доступность и особую надежность; некоторые производители предлагают аппаратные и программные решения как высоко доступные, так и особо надежные. Также большинство SOHO (Small Office Home Office) устройства firewall’ов и firewall’ов, встроенных по умолчанию в ОС, являются пакетными фильтрами.

Пример набора правил пакетного фильтра

Предположим, что в организации существует следующая топология (рис. 1.2).

Топология сети с использованием пакетного фильтра


Рис. 1.2.  Топология сети с использованием пакетного фильтра

Таблица 1.5. Набор правил пакетного фильтра
Адрес источникаПорт источникаАдрес назначенияПорт назначенияДействиеОписание
1AnyAny192.168.1.0(рабочая станция)>1023AllowПравило разрешает возвращать ТСР-соединения во внутреннюю подсеть, т.е. пользователи внутренней сети могут выходить в Интернет
2192.168.1.1( пакетный фильтр )AnyAnyAnyDenyЗащищает сам пакетный фильтр от непосредственного соединения с кем-либо
3AnyAny192.168.1.1AnyDenyПредотвращает непосредственный доступ всех пользователей к пакетному фильтру
4192.168.1.0AnyAnyAnyAllowВнутренние пользователи могут иметь доступ к внешним серверам
5AnyAny192.168.1.2(SMTP-сервер)SMTPAllowРазрешает всем (внешним и внутренним) пользователям посылать e-mail внутренним пользователям
6AnyAny192.168.1.3(НТТР-сервер)НТТРAllowРазрешает внешним пользователям иметь доступ к WWW-серверу
7AnyAnyAnyAnyDeny"Запретить все": правило – все, что не разрешено, то запрещено

В таблице приведен пример набора правил пакетного фильтра для вымышленной сети с IP-адресами 192.168.1.0/24, т.е. локальная сеть имеет адреса в диапазоне от 192.168.1.0 до 192.168.1.254. В большинстве случаев набор правил должен быть детальнее. Обычно firewall принимает пакет, просматривает его адреса и порты источника и назначения и определяет используемый прикладной протокол. Далее firewall начинает просматривать правила сверху вниз. Если найдено правило, которое соответствует анализируемой в пакете информации, то выполняется указанное в правиле действие:

В приведенной выше таблице первое правило разрешает, чтобы пакеты от внешних систем возвращались во внутренние системы, тем самым разрешая завершать создание соединения. Таким образом, здесь предполагается, что если инициализация соединения с внешней системой была разрешена, то возвращаемые пакеты от внешней системы должны быть также разрешены для завершения создания ТСР-соединения. Второе правило запрещает firewall’у пересылать любые пакеты с адресом источника firewall’а; данное условие предотвращает возможность атакующего подделать адрес firewall’а, заменив свой адрес на адрес firewall’а, чтобы firewall передал пакет внутреннему получателю. Здесь предполагается, что на данном хосте не установлено никаких других систем, к которым необходим доступ. В этом случае редактирование правил firewall’а возможно только с консоли хоста. Это не всегда бывает возможно. Например, может понадобиться доступ к хосту по протоколу SSH для редактирования правил самого firewall’а. Третье правило просто блокирует все пакеты от непосредственного доступа к firewall’у.

Четвертое правило разрешает внутренним системам соединяться с внешними системами, используя любые внешние адреса и любой протокол. Правила 5 и 6 разрешают внешним пакетам проходить firewall, если они содержат SMTP- или НТТР-данные. Тем самым можно сделать вывод, что политика информационной безопасности для сети следующая:

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

Важным свойством пакетных фильтров является то, что фильтрация может осуществляться как для исходящего, так и для входящего трафика. Организация может выбрать ограничение типов трафика, передаваемых из внутренней сети, например, блокирование всего исходящего FTP-трафика. На практике исходящая фильтрация чаще всего применяется к IP-адресам и приложениям для блокировки возможности соединения всех пользователей, внутренних и внешних, с некоторыми системами, такими как сам пакетный фильтр, backup-серверы и другие чувствительные системы.

Stateful Inspection firewall’ы

Stateful Inspection firewall’ы являются пакетными фильтрами, которые анализируют содержимое 4-го уровня (Transport) модели OSI.

Stateful inspection разрабатывались исходя из необходимости рассматривать основные особенности протоколов TCP/IP. Когда ТСР создает сессию с удаленной системой, также открывается порт на исходной системе для получения сетевого трафика от системы назначения. В соответствии со спецификацией ТСР, данный порт источника клиента будет некоторым числом, большим, чем 1023 и меньшим, чем 16384. Порт назначения на удаленном хосте, как правило, имеет фиксированный номер. Например, для SMTP это будет 25.

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

В таблице 1.6 показана первая строчка набора правил пакетного фильтра из приведенной выше таблицы, которая разрешает любое входящее соединение, если порт назначения больше 1023. Stateful inspection firewall’ы решают эту проблему созданием таблицы для исходящих ТСР-соединений, соответствующих каждой сессии. Эта "таблица состояний" затем используется для проверки допустимости любого входящего трафика. Решение stateful inspection является более безопасным, потому что отслеживать используемые порты каждого клиента лучше, чем открывать для внешнего доступа все порты "с большими номерами".

Таблица 1.6. Правило завершения создания соединения
Адрес источникаПорт источникаАдрес назначенияПорт назначенияДействиеОписание
AnyAny192.168.1.0>1023AllowПравило разрешает возвращать ТСР-соединения во внутреннюю подсеть

В сущности, stateful inspection firewall’ы добавляют понимание уровня 4 в архитектуру пакетного фильтра. Stateful inspection firewall’ы разделяют сильные и слабые стороны пакетных фильтров, но вследствие реализации таблицы состояний stateful inspection firewall’ы обычно считаются более безопасными, чем пакетные фильтры. В таблице 1.7 показан пример таблицы состояний firewall’а stateful inspection.

Таблица 1.7. Таблица состояний соединений stateful inspection firewall’а
Адрес источникаПорт источникаАдрес назначенияПорт назначенияСостояние соединения
192.168.1.1001030210.9.88.2980Establish
192.168.1.1021031216.32.42.12380Establish
192.168.1.1011033173.66.32.12225Establish
192.168.1.1061035177.66.32.12279Establish
223.43.21.2311990192.168.1.680Establish
219.22.123.322112192.168.1.680Establish
210.99.212.183321192.168.1.680Establish
24.102.32.231025192.168.1.680Establish
223.212.2121046192.168.1.680Establish

Преимущества stateful inspection firewall’а:

Недостатки stateful inspection firewall’а:

Host-based firewall’ы

Пакетные фильтры реализованы в некоторых ОС, таких как Unix/Linux; в частности, они могут использоваться только для обеспечения безопасности хоста, на котором они функционируют. Это может быть полезно при совместном функционировании с различными серверами; например, внутренний web-сервер может выполняться на системе, на которой функционирует host-based firewall.

Преимущества host-based firewall’а:

Недостаток host-based firewall’а:

Персональные firewall’ы и персональные устройства firewall’а

Обеспечение безопасности персональных компьютеров дома или в мобильном варианте сейчас становится столь же важным, как и обеспечение безопасности компьютеров в офисе; домашние пользователи, подключающиеся по dial-up к провайдеру, могут обеспечить защиту с помощью небольшого firewall’а, доступного им. Это необходимо, потому что провайдер может иметь много различных политик безопасности, не всегда соответствующих нуждам конкретного пользователя. Тем самым персональные firewall’ы разрабатываются для обеспечения защиты удаленных систем и выполняют во многом те же самые функции, что и большие firewall’ы.

Эти программные продукты обычно реализованы в одном из двух вариантов. Первый вариант представляет собой Personal Firewall, который инсталлируется на защищаемую систему; персональные firewall’ы обычно не предполагают защиту каких-либо других систем или ресурсов. Более того, персональные firewall’ы обычно не обеспечивают управление сетевым трафиком, который проходит через компьютер – они только защищают систему, на которой они инсталлированы.

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

Размещение этих инфраструктурных компонент в устройстве firewall’а позволяет использовать единственное аппаратное устройство для эффективного решения нескольких задач.

Хотя персональные firewall’ы и устройства персональных firewall’ов теряют некоторые преимущества и возможности масштабируемости традиционных firewall’ов, они могут быть достаточно эффективны для обеспечения общей безопасности организации. Персональные firewall’ы и устройства персональных firewall’ов обычно предназначены для филиалов офисов. Тем не менее некоторые организации используют эти устройства для создания Интранета, обеспечивая стратегию обороны вглубь. Персональные firewall’ы и устройства персональных firewall’ов могут также использоваться как конечные точки VPN.

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

Что можно сказать об удаленных пользователях, которые подсоединяются к dial-in серверу организации или к провайдерам? Если политика безопасности провайдера является менее ограничительной, чем в организации, то риск, что компьютер будет инфицирован вирусом или будет выполнена другая атака, будет больше. Существует также проблема, что многие пользователи используют свои персональные компьютеры как для работы, так и для целей, далеких от служебных.

Одно из возможных решений состоит в использовании отдельных компьютеров в офисе и вне офиса.

Если такое решение недоступно, то персональный firewall должен использоваться все время и должен быть сконфигурирован с учетом наиболее ограничительных установок, используемых в организации. Если, например, разделение файлов в Windows запрещено firewall’ом, то это должно оставаться запрещенным, даже если компьютер используется в нерабочих целях. Также, если установки web-безопасности отвергают определенные типы содержимого, данный запрет должен оставаться в силе все время. Такая политика должна быть реализована для dial-in сервера; он, в свою очередь, должен быть размещен таким образом, чтобы firewall и прокси фильтровали входящий трафик от dial-in соединений.

Прокси-сервер прикладного уровня

Прокси прикладного уровня являются более мощными firewall’ами, которые комбинируют управление доступом на низком уровне с функциональностью более высокого уровня (уровень 7 – Application).

Типичные прокси-агенты


Рис. 1.3.  Типичные прокси-агенты

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

Аутентификация пользователя может иметь много форм, например такие:

Прокси-сервер, который анализирует конкретный протокол прикладного уровня, называется агентом прокси.

Firewall’ы прикладного уровня имеют много преимуществ по сравнению с пакетными фильтрами и stateful inspection пакетными фильтрами.

Преимущества прокси-сервера прикладного уровня:

Более развитая функциональность прикладного прокси имеет также несколько недостатков по сравнению с пакетными фильтрами и stateful inspection пакетными фильтрами.

Недостатки прокси-сервера прикладного уровня:

Выделенные прокси-серверы

Выделенные прокси-серверы отличаются от прикладных прокси в том, что они анализируют трафик только конкретного прикладного протокола и не обладают возможностями анализа всего трафика, что все-таки характерно для firewall’а прикладного уровня. По этой причине они обычно развертываются позади firewall’ов прикладного уровня. Типичное использование таково: основной firewall получает входящий трафик, определяет, какому приложению он предназначен, и затем передает обработку конкретного типа трафика соответствующему выделенному прокси-серверу, например, e-mail прокси серверу. Выделенный прокси-сервер при этом выполняет операции фильтрации и логирования трафика и затем перенаправляет его во внутренние системы. Этот сервер может также принимать исходящий трафик непосредственно от внутренних систем, фильтровать трафик и создавать логи, а затем передавать его firewall’у для последующей доставки. Обычно выделенные прокси-серверы используются для уменьшения нагрузки на firewall и выполнения более специализированной фильтрации и создания логов.

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

В дополнение к функциям аутентификации и создания логов, выделенные прокси-серверы используются для сканирования web и e-mail содержимого, включая следующие функции:

Примеры выделенных прикладных прокси-серверов


Рис. 1.4.  Примеры выделенных прикладных прокси-серверов

На рис. 1.4 показан пример топологии сети, которая имеет выделенные прокси-серверы для НТТР и e-mail, расположенные позади основного firewall’а. В этом случае e-mail прокси может быть SMTP-шлюзом организации для входящей почты. Основной firewall будет перенаправлять входящую почту к прокси для сканирования содержимого, после чего почта может становиться доступной внутренним пользователям на SMTP-сервере, например, по протоколам РОР3 или IMAP. НТТР-прокси должен обрабатывать исходящие соединения ко внешним web-серверам и, возможно, фильтровать активное содержимое. Прокси-сервером может выполняться кэширование часто используемых web-страниц, тем самым уменьшая трафик к firewall’у.

Гибридные технологии firewall’а

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

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

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

Трансляция сетевых адресов (NAT)

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

NAT выполняется в трех основных формах: статическая трансляция сетевых адресов, скрытая трансляция сетевых адресов и трансляция портов.

Статическая трансляция сетевых адресов

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

Таблица 1.8. Таблица статической трансляции сетевых адресов
Внутренний IP-адресВнешний (глобально доступный)IP-адрес
192.168.1.100207.119.32.81
192.168.1.101207.119.32.82
192.168.1.102207.119.32.83

Скрытая трансляция сетевых адресов

При скрытой трансляции все системы позади firewall’а разделяют некоторый внешний IP-адрес, к которому выполняется роутинг. Таким образом, при скрытой трансляции сетевых адресов все хосты позади firewall’а будут выглядеть как один хост. Такой тип трансляции является достаточно распространенным, но имеет одно существенное слабое место. Данная технология не позволяет сделать доступными для внешних пользователей те ресурсы, которые размещены позади firewall’а. Отображение от внешних систем во внутренние системы невозможно, следовательно, хосты, которые должны быть доступны внешним системам, не могут применять данное отображение адресов. Другое слабое место данного подхода состоит в том, что firewall в этом случае должен использовать свой собственный внешний интерфейсный сетевой адрес в качестве "заменяемого" или транслируемого адреса для всех систем и ресурсов, которые расположены позади него. Данное требование приводит к уменьшению гибкости данного механизма.

Лекция 2. Различные типы окружений firewall’а

Рассматриваются различные типы окружений, в которых может функционировать firewall. Приведены основные принципы построения окружения firewall’а. Дается определение DMZ-сети. Исследуются различные топологии DMZ-сетей с использованием firewall’ов разного типа. Разбирается взаимное расположение конечных точек VPN и firewall’ов. Вводятся понятия "Интранет", "Экстранет". Задаются принципы создания политики firewall’а.

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

Принципы построения окружения firewall’а

Существует четыре принципа, которым необходимо следовать:

  1. Простота (Keep It Simple)

    Данный принцип говорит о первом и основном, о чем надо помнить при разработке топологии сети, в которой функционирует firewall. Важно принимать наиболее простые решения — более безопасным является то, чем легче управлять. Трудно понимаемые функциональности часто приводят к ошибкам в конфигурации.

  2. Использование устройств по назначению

    Использование сетевых устройств для того, для чего они первоначально предназначались, в данном контексте означает, что не следует делать firewall’ы из оборудования, которое не предназначено для использования в качестве firewall’а. Например, роутеры предназначены для роутинга; возможности фильтрации пакетов не являются их исходной целью, и это всегда надо учитывать при разработке окружения firewall’а. Зависимость исключительно от возможности роутера обеспечивать функциональность firewall’а опасна: он может быть легко переконфигурирован. Другим примером являются сетевые коммутаторы (switch): когда они используются для обеспечения функциональности firewall’а вне окружения firewall’а, они чувствительны к атакам, которые могут нарушить функционирование коммуникатора. Во многих случаях гибридные firewall’ы и устройства firewall’ов являются лучшим выбором, потому что они оптимизированы в первую очередь для функционирования в качестве firewall’ов.

  3. Создание обороны вглубь

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

  4. Внимание к внутренним угрозам

    Наконец, если уделять внимание только внешним угрозам, то это приводит к тому, что сеть становится открытой для атак изнутри. Хотя это и маловероятно, но следует рассматривать возможность того, что нарушитель может как-то обойти firewall и получить свободу действий для атак внутренних или внешних систем. Следовательно, важные системы, такие как внутренние web или e-mail серверы или финансовые системы, должны быть размещены позади внутренних firewall’ов или DMZ-зон.

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

DMZ-сети

Конфигурация с одной DMZ-сетью

В большинстве случаев окружение firewall’а образует так называемую DMZ-сеть или сеть демилитаризованной зоны. DMZ-сеть является сетью, расположенной между двумя firewall’ами.

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

Пример окружения firewall’а с одной DMZ


Рис. 2.1.  Пример окружения firewall’а с одной DMZ

DMZ-сети обычно строятся с использованием сетевых коммутаторов и располагаются между двумя firewall’ами или между firewall’ом и пограничным роутером. Хорошей практикой является размещение серверов удаленного доступа и конечных точек VPN в DMZ-сетях. Размещение этих систем в DMZ-сетях уменьшает вероятность того, что удаленные атакующие будут иметь возможность использовать эти серверы в качестве точки входа в локальные сети. Кроме того, размещение этих серверов в DMZ-сетях позволяет firewall’ам служить дополнительными средствами для контроля прав доступа пользователей, которые получают доступ с использованием этих систем к локальной сети.

Service Leg конфигурация

Одной из конфигураций DMZ-сети является так называемая "Service Leg" конфигурация firewall’а. В этой конфигурации firewall создается с тремя сетевыми интерфейсами. Один сетевой интерфейс соединяется с Интернетом, другой сетевой интерфейс соединяется с внутренней сетью, и третий сетевой интерфейс формирует DMZ-сеть. Такая конфигурация может привести к возрастанию риска для firewall’а при деградации сервиса в течение DoS-атаки, которая будет нацелена на сервисы, расположенные в DMZ-сети. В стандартной конфигурации DMZ-сети DoS-атака для присоединенного к DMZ-ресурса, такого как web-сервер, будет соответствующим образом воздействовать только на этот целевой ресурс. В Service Leg конфигурации DMZ-сети firewall берет на себя основной удар от DoS-атаки, потому что он должен проверять весь сетевой трафик перед тем, как трафик достигнет присоединенного к DMZ-ресурса. Это может влиять на весь трафик организации, если на ее web-сервер выполнена DoS-атака.

Конфигурация Service Leg DMZ


Рис. 2.2.  Конфигурация Service Leg DMZ

Конфигурация с двумя DMZ-сетями

При наличии большого числа серверов с разными требованиями доступа можно иметь firewall пограничного роутера и два внутренних firewall’а и разместить все внешне доступные серверы во внешней DMZ между роутером и первым firewall’ом. Пограничный роутер будет фильтровать пакеты и обеспечивать защиту серверов, первый firewall будет обеспечивать управление доступом и защиту серверов внутренней DMZ в случае, если они атакованы. Организация размещает внутренне доступные серверы во внутренней DMZ, расположенной между основным и внутренним firewall’ами; firewall’ы будут обеспечивать защиту и управление доступом для внутренних серверов, защищенных как от внешних, так и от внутренних атак.

Пример окружения firewall’а с двумя DMZ-сетями


Рис. 2.3.  Пример окружения firewall’а с двумя DMZ-сетями

Окружение firewall’а для данной сети показано на рис. 2.3.

Основной и внутренний firewall’ы должны поддерживать технологию stateful inspection и могут также включать возможности прикладного прокси. Основной firewall должен выполнять следующие действия:

Внутренний firewall должен принимать входящий трафик только от основного firewall’а, прикладного НТТР-прокси и SMTP-сервера. Кроме того, он должен принимать SMTP- и НТТР-трафик только от прокси, но не от основного firewall’а. Наконец, он должен разрешать все исходящие соединения от внутренних систем.

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

Виртуальные частные сети

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

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

Пример совмещения firewall’а и VPN


Рис. 2.4.  Пример совмещения firewall’а и VPN

Технология VPN часто используется для создания безопасных соединений между организациями.

С точки зрения используемого протокола, существует несколько возможных выборов для создания VPN. Наиболее часто используется семейство протоколов IPSec. Другие протоколы VPN: PPTP (Point-to-Point Tunneling Protocol), являющийся стандартом Microsoft, и L2TP (Layer 2 Tunneling Protocol).

Расположение VPN-серверов

В большинстве случаев наиболее приемлемым является совмещение конечной точки VPN и firewall’а. Как правило, firewall использует IPSec для соединения с удаленными системами и передает незашифрованный трафик firewall’а к внутренней сети. При размещении конечной точки VPN позади firewall’а будет требоваться, чтобы VPN-трафик передавался вовне через firewall в зашифрованном виде; при этом firewall не будет иметь возможность анализировать входящий или исходящий трафик, выполнять управление доступом, создавать логи, сканировать на вирусы и т.п. На рис. 2.4 показана VPN, которая заканчивается firewall’ом, обеспечивая логическое расширение внутренней защищенной сети.

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

Интранет

Интранет является сетью, которая выполняет те же самые сервисы, приложения и протоколы, которые присутствуют в Интернете, но без наличия внешнего соединения с Интернетом. Например, сеть предприятия, поддерживающая семейство протоколов TCP/IP, можно рассматривать как Интранет.

Большинство организаций в настоящее время имеет некоторый тип Интранета. Во внутренней сети ( интранет ) могут быть созданы еще меньшие Интранеты, используя внутренние firewall’ы. Например, можно защитить свою собственную персональную сеть внутренним firewall’ом, и получившаяся защищенная сеть может рассматриваться как персональная интранет.

Так как Интранет использует те же самые протоколы и прикладные сервисы, что и Интернет, многие проблемы безопасности, унаследованные из Интернета, также присутствуют в Интранете.

Экстранет

Термин " Экстранет " применяется к сети, логически состоящей из трех частей: две интранет соединены между собой через Интернет с использованием VPN. Экстранет может быть определена как business-to-business Интранет. Эта сеть позволяет обеспечить ограниченный, управляемый доступ удаленных пользователей посредством той же формы аутентификации и шифрования, которые имеются в VPN.

Экстранет имеет те же самые характеристики, что и интранет, за исключением того, что экстранет использует VPN для создания защищенных соединений через публичный Интернет. Целью интранет является предоставление доступа к потенциально чувствительной информации удаленным пользователям или организациям, но при этом запрещая доступ всем остальным внешним пользователям и системам. Экстранет использует протоколы TCP/IP и те же самые стандартные приложения и сервисы, которые используются в Интернете. На рис. 2.5 показан пример топологии сети экстранета.

VPN и экстранет, соединяющие две сети интранета


Рис. 2.5.  VPN и экстранет, соединяющие две сети интранета

Компоненты инфраструктуры: концентраторы и коммутаторы

Дополнительно к роутерам и firewall’ам, связь между системами обеспечивают такие инфраструктурные устройства, как концентраторы (hubs) и коммутаторы (switches). Наиболее простым из них является сетевой концентратор. Концентраторы — это устройства, которые функционируют на уровне 1 модели OSI. Другими словами, они предназначены только для предоставления физического подсоединения сетевых систем или ресурсов.

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

Более развитыми инфраструктурными устройствами являются сетевые коммутаторы. Это устройства уровня 2, то есть они обладают определенной информацией при создании присоединения сетевых систем или компонент. Основное свойство коммутаторов состоит в том, что системы, присоединенные к коммутатору, не могут "подсматривать" трафик друг друга; поэтому они лучше подходят для реализации DMZ-сетей и окружений firewall’ов.

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

Расположение серверов в DMZ-сетях

Где расположить серверы при наличии firewall’ов, зависит от многих факторов, включая количество DMZ, необходимость внешнего и внутреннего доступа к серверам, расположенным в DMZ, интенсивность трафика и чувствительность обрабатываемых данных. Невозможны абсолютно универсальные рекомендации по расположению серверов, но определенные принципы должны учитываться:

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

Внешне доступные серверы

Внешне доступные НТТР-серверы, а также серверы каталога или DNS-серверы, могут быть размещены во внешней DMZ, т.е. между пограничным роутером с функциями пакетного фильтра и основным firewall’ом. Пограничный роутер может обеспечить некоторое управление доступом и фильтрацию трафика для серверов, а основной firewall — предотвратить создание соединений от серверов к внутренним системам, которые могут устанавливаться, если серверы будут взломаны. В случае большого трафика и сильной загруженности серверов может использоваться высокоскоростной пограничный роутер с несколькими присоединенными DMZ для изолирования серверов в индивидуальных DMZ-сетях. Таким образом, если осуществляется DDoS-атака на некоторый сервер, остаток сети не пострадает.

VPN и Dial-in серверы

Эти серверы лучше разместить во внешней DMZ, чтобы их трафик проходил в локальную сеть через основной firewall. Одна из возможных конфигураций состоит в совмещении VPN-сервера и firewall’а, чтобы исходящий трафик мог быть зашифрован после того, как он будет отфильтрован, и входящий трафик может быть дешифрован и затем отфильтрован firewall’ом. Dial-in сервер должен быть размещен во внешней DMZ по тем же причинам.

Внутренние серверы

Внутренне доступные НТТР-серверы, SMTP-серверы и серверы каталога могут быть размещены во внутренней DMZ, т.е. между двумя выделенными firewall’ами, основным и внутренним; при этом внутренний firewall отделяет внутреннюю DMZ от защищенной сети. Размещение этих систем во внутренней DMZ обеспечивает оборону вглубь, защищая как от внешних, так и от внутренних угроз. Если НТТР-прокси используется для исходящего трафика, размещение этих систем во внутренней DMZ обеспечивает большую защиту от внутренних и внешних угроз.

DNS-серверы

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

Пример топологии сети с двумя DNS-серверами


Рис. 2.6.  Пример топологии сети с двумя DNS-серверами

Во-первых, внутренние DNS-серверы должны быть отделены от внешних DNS-серверов. Например, DNS-сервер, который доступен всему миру, не должен содержать записей о системах, которые не должны быть достигнуты извне. Если такие записи о внутренних системах имеются во внешнем DNS-сервере, это даст возможность атакующему определить список целей. Следует поддерживать отдельно внутренний и внешний DNS-серверы либо использовать технологию, известную как split DNS, которая гарантирует, что внутренние системы никогда не смогут быть идентифицированы посторонними.

Во-вторых, также необходимо контролировать разрешенные типы доступа к DNS-серверу. Приложение DNS-сервера может выполняться с использованием двух транспортных протоколов: клиент обращается к серверу по протоколу UDP, а взаимодействие двух серверов DNS, выполняющих зонные пересылки, реализовано с использованием ТСР. Доступ к серверу DNS с использованием ТСР должен быть ограничен только для тех серверов DNS, которые должны выполнять зонные пересылки. Основной риск, который существует при функционировании DNS, состоит в модификации передаваемой информации. Например, если сервер допускает неаутентифицированные запросы и ответы DNS, атакующий может модифицировать информацию, в результате чего сетевой трафик будет перенаправлен на другой хост. На рис. 2.6 показан пример топологии сети с двумя DNS-серверами. Внутренний DNS-сервер должен быть сконфигурирован для разрешения имен внутренних клиентов, чтобы внутренние пользователи могли соединяться с внутренними серверами, всеми серверами в DMZ и Интернетом. Внешний DNS-сервер должен обеспечивать разрешение имен самого DNS-сервера и серверов во внешней DMZ, но не во внутренней сети. Как результат, серверы во внешней DMZ будут видимы в Интернете.

SMTP-серверы

Некоторые firewall’ы могут использоваться для получения e-mail, т.е. установления SMTP-соединений. Наиболее популярная конфигурация включает использование основного firewall’а для:

  1. приема SMTP-соединений;
  2. пересылки их выделенному прокси / e-mail серверу, расположенному во внутренней DMZ.

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

Если пользователям необходим доступ к e-mail из внешних сетей, например, во время командировок, один из методов защиты SMTP-сервера от прямого внешнего доступа состоит в выполнении SSL-прокси на основном firewall’е. Используя web-браузер, внешние пользователи должны соединиться с основным firewall’ом (он может быть сконфигурирован с использованием дополнительных имен для сокрытия своего имени и иметь открытым только порт для НТТРS, но не для НТТР). Основной firewall будет перенаправлять SSL-соединение внутреннему прокси-серверу, который будет обслуживать e-mail поверх НТТР. В этом случае предотвращается прямой внешний доступ к e-mail серверу, но допускается внешний доступ через firewall. Данный подход также может быть использован и для других типов серверов.

Пример топологии сети с двумя DMZ


Рис. 2.7.  Пример топологии сети с двумя DMZ

На рис. 2.7 показан пример окружения firewall’а с внешней и внутренней DMZ и несколькими серверами. В данном примере VPN-сервер совмещен с основным firewall’ом, и dial-in сервер расположен между пограничным роутером с возможностями пакетного фильтра и основным firewall’ом. Другие внешне доступные серверы также расположены во внешней DMZ. Все остальные внутренние серверы расположены во внутренней DMZ и защищены как от внешних, так и от внутренних угроз.

Политика безопасности firewall’а

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

Без наличия политики безопасности администраторы работают "втемную". Firewall’ы могут быть сложными и трудными с точки зрения управления, и инциденты, связанные с безопасностью, могут возникать ежедневно. Без политики, определяющей, кроме всего прочего, управление firewall’ом, он сам может создавать проблемы, связанные с безопасностью.

Политика firewall’а

Политика firewall’а определяет, как firewall должен обрабатывать трафик различных приложений, таких как web, e-mail или telnet. Политика также должна описывать, как сам firewall управляется и модифицируется.

До того, как политика firewall’а может быть создана, должен быть выполнен в той или иной форме анализ риска для приложений, которые требуются для всей деятельности организации. Результаты данного анализа должны включать как список приложений, так и то, каким образом должна обеспечиваться безопасность этих приложений. Процесс создания данного списка здесь не детализирован, но он требует знания уязвимостей, связанных с каждым приложением, и соотношения стоимости и преимуществ для методов, используемых в обеспечении безопасности приложений. Анализ риска информационной инфраструктуры организации должен быть сделан на основе оценки следующих элементов: угроз; уязвимостей и соответствующих контрмер, их уменьшающих; последствия, если чувствительные данные скомпрометированы. Целью является понимание и оценка этих элементов до определения политики firewall’а.

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

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

Реализация набора правил firewall’а

Большинство реализаций firewall’ов используют наборы правил в качестве механизма для реализации управления трафиком. Возможная совокупность этих правил определяет реальную функциональность firewall’а. В зависимости от архитектуры реализации firewall’а набор правил может включать в себя различные блоки информации. Тем не менее все они содержат как минимум следующие поля:

Следует быть готовым к тому, что набор правил firewall’а становится все более сложным.

Набор правил может быть создан после определения трафика приложений. В зависимости от firewall’а это может выполняться с использованием интерфейса в стиле web; в случае пакетных фильтров набор обычно является текстовым файлом. Набор должен быть создан как можно более конкретно в соответствии с трафиком, который он контролирует. Он должен быть как можно более простым, чтобы случайно не появилось "дырок" в firewall’е, которые могут допустить прохождение неавторизованного или нежелательного трафика через firewall.

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

Набор правил firewall’а должен всегда блокировать следующие типы трафика:

Входящий трафик с этими адресами источника обычно указывает на начало DoS-атаки, имеющий TCP SYN флаг:

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

Большинство firewall’ов поддерживают несколько опций для создания логов. Эти опции имеют широкий диапазон, от создания простых записей логов до оповещения администратора о наступлении некоторого события. В зависимости от способа оповещения данное действие может реализовываться различными способами: от посылки уведомления по e-mail до телефонного сообщения соответствующему персоналу.

Тестирование политики firewall’а

Политика firewall’а должна периодически проверяться, по крайней мере, ежеквартально.

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

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

Хотя вторая методика выполняет более строгую проверку, должны применяться обе технологии. Цель состоит в гарантировании того, что firewall’ы (так же как и другие устройства, относящиеся к обеспечению безопасности) сконфигурированы точно так, как это должно быть на основании принятой политики. Важно, чтобы сама система firewall’а тестировалась с использованием безопасных средств оценки. Эти средства должны проверять лежащую в основе ОС, а также ПО и конфигурацию firewall’а.

Возможные подходы к эксплуатации firewall’а

При эксплуатации и определении политики firewall’а следует решить, использовать ли firewall в виде отдельного аппаратно-программного средства (appliance) или в составе ОС. Хотя данное решение в большей степени определяется требованиями организации, должны быть рассмотрены следующие аспекты:

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

Сопровождение firewall’а и управление firewall’ом

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

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

В обоих случаях следует иметь гарантии, что для всего сетевого трафика, предназначенного для системы управления firewall’ом, выполняются требования безопасности. Для интерфейсов, основанных на web, данная безопасность реализуется использованием неанонимного SSL с последующей аутентификацией пользователя по ID и паролю. Для собственных (не-web) интерфейсов обычно реализуется тот или иной способ шифрования транспорта. То, что все функции управления firewall’ом должны выполняться по безопасным каналам с использованием строгой аутентификации и шифрования, должно быть явно указано в политике.

Физическая безопасность окружения firewall’а

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

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

Наконец, firewall должен быть защищен от различных стихийных бедствий.

Администрирование firewall’а

Встраивание firewall’ов в ОС

Другим ключевым фактором успешного управления окружением firewall’а является согласованность платформы. Firewall’ы должны быть реализованы на системах, содержащих встроенные ОС, которые специальным образом урезаны и усилены для приложений безопасности, например, представляют собой так называемый "бастионный хост". Firewall’ы никогда не должны размещаться на системах, которые имеют какие-либо опции, позволяющие проводить инсталляцию.

Конфигурирование ОС firewall’а должно быть основано на принципе оставления минимального множества возможностей. Все ненужные функциональности ОС, особенно компиляторы, редакторы и другие инструментальные средства разработки должны быть удалены до того как firewall начнет функционировать. Все необходимые patches ОС должны быть применены перед инсталляцией компонент firewall’а.

Конфигурирование ОС не должно абсолютно полагаться на модификации, сделанные в процессе инсталляции firewall’а. Программы инсталляции firewall’а основаны на минимально необходимых установках; дополнительные пакеты или модули при инсталляции могут быть не удалены или не запрещены.

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

Стратегии восстановления после сбоев firewall’а

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

Сетевые коммутаторы, которые обеспечивают балансировку загрузки и возможности восстановления после сбоя, представляют собой новейшие и наиболее продвинутые решения, доступные на сегодняшний день. В конфигурации восстановления коммутаторы просматривают ответную реакцию от основного firewall’а и перенаправляют весь трафик на запасной firewall в случае сбоя основного. Основным преимуществом такого решения является то, что коммутатор скрывает оба firewall’а за одним и тем же МАС-адресом. Этим обеспечивается возможность бесшовного восстановления после сбоя; во многих случаях установленные через firewall сессии не замечают сбоя основного firewall’а.

Решения, основанные на пульсации, обычно включают back-end или настраиваемый сетевой интерфейс, используемый для оповещения backup-системы в случае сбоя основного firewall’а. Такие системы реализуют надежную технологию восстановления после сбоя. Основной недостаток данного подхода состоит в том, что сессии, установленные к производственному firewall’у, всегда сбрасываются при перенаправлении на backup-ресурсы.

Решение, при котором реализуется метод восстановления после сбоя, часто имеет меньшую стоимость; решение, основанное на восстановлении на основе коммутаторов, является более дорогостоящим.

Возможности создания логов firewall’а

Практически все системы firewall’а обеспечивают ту или иную функциональность создания логов. Как обсуждалось ранее, логи в прикладном прокси являются более объемными, чем логи пакетных фильтров или firewall’ов stateful inspection. Причина в том, что прикладные фильтры анализируют большее число уровней модели OSI, чем пакетные фильтры.

Общим примером функциональности создания логов является приложение syslog в UNIX. UNIX syslog предназначен для централизованного создания логов, а также имеет много опций для их проверки и обработки. Данная программа создания логов доступна практически во всех основных ОС, включая Windows NT, 2xxx и все разновидности UNIX и Linux.

После того как логи firewall’а будут переданы централизованному серверу логов, могут использоваться различные пакеты для их обработки. Логи, основанные на syslog, могут также подаваться в качестве входа в пакеты анализа проникновения и использоваться для судебного расследования.

Те firewall’ы, которые не поддерживают интерфейса syslog, должны использовать свою собственную внутреннюю функциональность создания логов. В зависимости от платформы firewall’а, существует много инструментальных пакетов третьих фирм для поддержки и обработки логов.

Инциденты безопасности

Не существует простого ответа на вопрос, что такое инцидент безопасности.

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

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

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

В сущности, определение инцидента безопасности определяется политикой безопасности организации.

Firewall’ы могут являться критичными элементами в контексте инцидента безопасности – они указывают на корреляцию событий. Корреляцию событий обеспечивает тот факт, что firewall’ы являются рубежом, который должны пересечь все сетевые атаки, чтобы войти в сеть. Это ставит firewall в уникальное положение по анализу неавторизованной деятельности. По этой причине все firewall’ы и другие системы создания логов, такие как IDS, должны выполнять синхронизацию времени. Наиболее общим механизмом для синхронизации времени является Network Time Protocol (NTP).

Создание backup’ов firewall’ов

Создание и сопровождение backup’ов является ключевой точкой в любой политике администрирования firewall’а. Для всех firewall’ов должен выполняться ежедневный backup.

В принципе, на всех firewall’ах всегда должны выполняться полные backup’ы. В инкрементальных backup’ах нет необходимости.

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

Также желательно (но не всегда возможно) использовать firewall’ы, у которых все критичные конфигурационные файлы расположены на CDROM. Для UNIX это является более реальным; основной директорией, требующей доступа по записи, является директория /var все логи обычно хранятся в данной директории. Развертывание firewall’ов, основанных на Windows, с read-only файловыми системами в настоящее время невозможно.

Лекция 3. Пример пакетных фильтров в ОС FreeBSD 6.0

Рассматриваются пакетные фильтры, реализованные в ОС FreeBSD 6.0: PF IPFILTER (IPF) и IPFW. Рассматривается синтаксис правила для каждого из этих пакетных фильтров и возможности поддержки состояния ТСР-соединения в них. Приводится порядок прохождения пакета через правила пакетного фильтра. Изучается применение функции трансляции сетевых адресов (NAT). Приведены примеры набора правил в IPF и IPFW.

Введение

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

Пакетные фильтры могут использоваться следующим образом:

Рассмотрим следующие проблемы:

Основные характеристики пакетных фильтров в ОС FreeBSD

Существует два основных способа создания набора правил пакетного фильтра: "inclusive" — включающий и "exclusive" — исключающий. Основное различие состоит в том, какое правило применяется по умолчанию к пакетам, не соответствующим всем остальным правилам.

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

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

Дальнейшее усиление безопасности может достигаться использованием stateful firewall. Применение stateful firewall’а означает, что пакетный фильтр отслеживает открытые соединения и разрешает прохождение только того трафика, который либо соответствует существующему соединению, либо открывает новое соединение. Недостатком stateful firewall’а является то, что он уязвим для DoS-атак, если большое количество новых соединений открывается очень быстро. В большинстве случаев можно использовать комбинацию stateful и не-stateful свойств, создавая оптимальный firewall для защиты локальной сети.

ПО пакетных фильтров

FreeBSD имеет три различных пакета ПО firewall’а, встроенных в базовую систему. Это IPFILTER (также известный как IPF), IPFIREWALL (также известный как IPFW ) и PacketFilter из OpenBSD (также известный как PF). FreeBSD также имеет два встроенных пакета ПО для шейпинга ("отслеживания" — "shaping") трафика, обычно используемых для управления используемой шириной пропускания: altq и dummynet. Dummynet традиционно используется с IPFW, а ALTQ — с IPF и PF. IPF, IPFW и PF применяют правила для управления доступом пакетов в систему и из системы, но при этом они делают это разными способами и имеют разный синтаксис правил.

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

Отчасти предпочтительным можно называть IPFILTER, потому что его stateful правила являются менее сложными при использовании в окружении NAT и он имеет встроенный ftp-прокси, что упрощает правила, разрешающие использование безопасного исходящего FTP.

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

OpenBSD Packet Filter (PF) и ALTQ

В 2003 году ПО пакетного фильтра из OpenBSD, известное как PF, было портировано на FreeBSD и доступно во FreeBSD Ports Collections; первой версией, которая содержала PF в качестве составной части базовой системы, была FreeBSD 5.3, выпущенная в ноябре 2004 года. PF является полнофункциональным пакетным фильтром, который имеет дополнительную поддержку для ALTQ (Alternate Queuing). ALTQ обеспечивает качество сервиса (QoS), что позволяет гарантировать ширину пропускания для различных сервисов, указанную в правилах фильтрования.

До версий 4.Х PF не доступен.

Во всех версиях, начиная с 4.Х, PF доступен как часть проекта KAME.

5.Х до 5.3 RELEASE – может использоваться порт security/pf для инсталляции PF.

5.3 RELEASE и более позднее – PF является частью базовой системы. Начиная с этих версий FreeBSD, не следует использовать порт security/pf. Вместо этого следует использовать PF базовой системы.

Указание необходимости использования PF

PF включен в базовую инсталляцию FreeBSD во все версии позднее 5.3 в качестве отдельного загружаемого модуля времени выполнения. Система будет динамически загружать модуль ядра PF, если в rc.conf указано утверждение pf_enable="YES". Загружаемый модуль будет иметь возможность создавать логи pflog.

Замечание. Модуль предполагает наличие опций INET и device bpf.

После того как модуль загружен или ядро статически осуществляет поддержку PF, существует возможность разрешить или запретить pf с помощью команды pfctl:

# pfctl –e

Команда pfctl предоставляет способ работы с пакетным фильтром PF.

Опции ядра

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

Пример конфигурирования ядра можно найти в /usr/src/sys/ conf/NOTES:

device pf
 device pflog
 device pfsync

device pf обеспечивает поддержку пакетного фильтра PF.

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

device pfsync обеспечивает дополнительную поддержку псевдосетевого устройства pfsync, которое используется для мониторинга изменений состояния. Так как оно не является частью загружаемого модуля, оно встраивается в ядро.

Опции rc.conf

Для активации PF следует установить следующие опции в /etc/rc.conf:

pf_enable="YES"                 # необходимость PF
    pf_rules="/etc/pf.conf"      # файл с определениями правил 
                                 # для PF
    pf_flags=""                     # дополнительные флаги для 
                                 # запуска pfctl
    pflog_enable="YES"             # start pflogd
    pflog_logfile="/var/log/pflog" # где pflogd должен хранить 
                                 #logfile
    pflog_flags=""                 # дополнительные флаги для 
                                 # запуска pflogd

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

gateway_enable="YES" # возможность функционирования 
                         # в качестве шлюза

Указание необходимости использования ALTQ

ALTQ доступен только в компилированном в ядро FreeBSD виде. Следует иметь в виду, что ALTQ не поддерживает все существующие драйверы сетевых карт. Для включения возможностей ALTQ следует указать следующие опции:

options ALTQ
    options ALTQ_CBQ # Class Bases Queuing (CBQ)
    options ALTQ_RED # Random Early Detection (RED)
    options ALTQ_RIO # RED In/Out
    options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
    options ALTQ_PRIQ #Priority Queuing (PRIQ)
    options ALTQ_NOPCC # Required for SMP build

options ALTQ обеспечивает возможность функционирования ALTQ.

options ALTQ_CBQ дает возможность делить ширину пропускания соединения на различные классы или очереди для создания приоритетов трафика на основе правил фильтрации.

options ALTQ_RED используется для предотвращения перегрузки сети. RED делает это посредством измерения длины очереди и сравнением ее с минимальным и максимальным порогами для очереди. Если очередь больше максимальной, то все новые пакеты отбрасываются. В соответствии со своим названием RED отбрасывает пакеты из различных соединений случайно.

options ALTQ_RIO передает в первую очередь трафик, который находится в самой верхней очереди.

Создание правил фильтрации

Пакетный фильтр читает правила конфигурации из pf.conf файла и модифицирует, отбрасывает или пропускает пакеты в соответствии с правилами, указанными там. Файл /etc/pf.conf также содержит полезные примеры и объяснения.

Синтаксис точно такой же, как и в OpenBSD.

IPFILTER (IPF) firewall

IPFILTER не зависит от ОС, он является open source приложением, которое портировано на FreeBSD, NetBSD, OpenBSD, SunOS, HP/UX и Solaris. IPFILTER активно развивается, регулярно выходят новые версии.

IPFILTER основан на пакетном фильтре уровня ядра и имеет механизм NAT, который может управляться и просматриваться программами с интерфейсом уровня пользователя. Правила пакетного фильтра могут быть установлены или удалены с помощью утилиты ipf. Правила NAT могут быть установлены или удалены с помощью утилиты ipnat. Утилита ipfstat может показывать в реальном времени статистику, относящуюся к той части IPFILTER, которая функционирует на уровне ядра. Программа ipmon создает в системных файлах логи действий, выполненных IPFILTER.

IPF был написан сперва с использованием логики обработки правил "используется последнее правило, которому соответствует пакет". Первоначально имелись только правила без поддержки состояния. Со временем IPF был усилен включением опции quick и опции поддержки состояния keep state, в результате чего изменилась логика обработки правил. Модернизированные функции включены только в виде дополнительных опций, они дают возможность создавать пакетный фильтр, обеспечивающий большую безопасность.

Рассмотрим использование правил, которые содержат опцию quick и опцию поддержки состояния keep state. Это является основой для создания набора правил включающего пакетного фильтра.

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

Указание необходимости использования IPF

IPF включен в базовую инсталляцию FreeBSD в качестве отдельного модуля, загружаемого во время выполнения. Система динамически загружает модуль ядра IPF, если в rc.conf указано утверждение ipfilter_enable="YES". Загружаемый модуль создается с возможностью создания логов и опцией default pass all. Нет необходимости компилировать IPF в ядро FreeBSD только для того, чтобы изменить умолчание на block all. Это можно сделать, указав блокировку всего трафика в конце набора правил.

Опции ядра

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

Опции, доступные в rc.conf

Для активации IPF во время загрузки следует указать следующие утверждения в /etc/rc.conf:

ipfilter_enable="YES"      # Start ipf firewall
    ipfilter_rules="/etc/ipf.rules" 
       # загрузка текстового файла с определением правил
    ipmon_enable="YES"          # Start IP monitor log
    ipmon_flags="-Ds"          # D = запуск в качестве демона
       # s = создание логов с использованием syslog
       # v = занесение в лог tcp window, ack, seq
          # n = отображение IP и port по именам

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

gateway_enable="YES"      # Enable as LAN gateway
    ipnat_enable="YES"          # Start ipnat function
    ipnat_rules="/etc/ipnat.rules"  # файл с определением правил 
                           # для ipnat

IPF

Команда ipf используется для загрузки файла с правилами. Обычно создается файл с требуемыми правилами и используется данная команда для замены выполняющихся в текущей момент правил:

# ipf –Fa –f /etc/ipf.rules

-Fa означает очистку всех внутренних таблиц правил.

-f означает, что новые правила будут загружены из данного файла.

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

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

Существует способ построения правил IPF с возможностью использовать символьные подстановки.

IPFSTAT

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

IPMON

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

Режим демона используется тогда, когда необходимо сделать файл системного лога доступным для просмотра в более позднее время. Этим способом можно сконфигурировать IPMON и IPFILTER для совместной работы. Во FreeBSD есть встроенная возможность автоматической ротации системных логов. Поэтому выводить информацию с использованием в syslogd лучше, чем в обычный файл. По умолчанию в файле rc.conf используется утверждение ipmon_flags с –Ds флагами:

ipmon_flags="-Ds" # D = start as daemon
                     # s = log to syslog
                     # v = log tcp window, ack, seq
                     # n = map IP & port to names

Построение скрипта правил с использованием символьных подстановок

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

Синтаксис скрипта совместим с sh, csh и tcsh.

Поле символьной подстановки начинается с символа $.

Определение символьного поля не имеет в качестве префикса символ $.

Значение, которое принимает символьное поле, должно быть заключено в двойные кавычки.

Файл правил должен начинаться аналогичным образом:

############# Start of IPF rules script ########################
    oif="dc0"            # name of the outbound interface
    odns="192.0.2.11"    # ISP's DNS server IP address
    myip="192.0.2.7"     # my static IP address from ISP
    ks="keep state"
    fks="flags S keep state"

    # You can choose between building /etc/ipf.rules file
    # from this script or running this script "as is".
    #
    # Uncomment only one line and comment out another.
    #
    # 1) This can be used for building /etc/ipf.rules:
    #cat > /etc/ipf.rules << EOF
    #
    # 2) This can be used to run script "as is":
    /sbin/ipf -Fa -f - << EOF

    # Allow out access to my ISP's Domain name server.
    pass out quick on $oif proto tcp from any to $odns port = 53 $fks
    pass out quick on $oif proto udp from any to $odns port = 53 $ks

    # Allow out non-secure standard www function
    pass out quick on $oif proto tcp from $myip to any port = 80 $fks

    # Allow out secure www function https over TLS SSL
    pass out quick on $oif proto tcp from $myip to any port = 443 $fks
    EOF
    ############### End of IPF rules script ##################

В данном примере правила не важны. Здесь показано, как символьные подстановки обозначаются и как используются. Если приведенный выше пример поместить в файл /etc/ipf.rules.script, можно загрузить эти правила, введя команду

# sh /etc/ipf.rules.script

Данный скрипт можно использовать и другим способом:

Раскомментировать строку, начинающуюся с cat, и закомментировать строку, начинающиюся с /sbin/ipf. Указать, как обычно, ipfilter_enable="YES" в /etc/rc.conf и выполнять скрипт после каждой модификации /etc/ipf.rules.

Набор правил IPF

Набор правил определяет прохождение или блокировку пакетов, основываясь на значениях, содержащихся в пакете. Установление сессии включает в себя двунаправленный обмен пакетами между хостами. Набор правил firewall’а обрабатывает пакет два раза: один раз — когда он поступает из Интернета и второй — когда он возвращается обратно в Интернет. Каждый TCP/IP-сервис (http, smtp, telnet и т.п.) определяется своим протоколом, IP-адресами источника и получателя, номерами портов источника и получателя. Эти значения являются основными критериями, на основе которых разрешаются или блокируют сервисы.

IPF был первоначально написан с использованием логики обработки правил "используется последнее правило, которому соответствует пакет". Правила не поддерживали состояния. Со временем IPF был усилен включением опции quick и опции поддержки состояния keep state, что существенно изменило логику обработки правил.

Далее мы будем рассматривать использование правил, которые включают опцию quick и опцию поддержки состояний keep state. Это общая основа для набора во включающем пакетном фильтре.

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

Синтаксис правила

Синтаксис использует логику "используется первое правило, которому соответствует пакет".

Символ # используется для обозначения начала комментария и может появиться в конце строки правила или в начале всей строки.

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

Общий синтаксис правила следующий:

ACTION IN-OUT OPTIONS PROTO SRC_ADDR,DST_ADDR TCP_FLAG STATEFUL

Где:

ACTION = block | pass
    IN-OUT = in | out
    OPTIONS = log [body | first] | quick | on 
    PROTO = proto <Value;>
    Value = tcp/udp | udp | tcp | icmp
    SRC_ADDR,DST_ADDR = all | from <Object > to <Object>
    Object = <IP-address > [<PORT_NUM >] | any [<PORT_NUM >]
    PORT_NUM = port <number >
    TCP_FLAG = flags <flag-value <
    flag-value = S
    STATEFUL = keep state
Действие (action)

Действие определяет, что будет сделано с пакетом, если он соответствует оставшейся части данного правила. Могут быть определены следующие действия:

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

pass указывает, что пакет должен быть пропущен пакетным фильтром, если он соответствует параметру выбора.

IN-OUT

Обязательное требование состоит в том, что в каждом правиле фильтра должно быть явно указано, пакеты какого направления оно анализирует. Ключевым словом может быть либо in, либо out. Если указано что-либо еще, то правило не пройдет синтаксическую проверку.

in означает, что данное правило применяется для входящего пакета на указанном интерфейсе.

out означает, что данное правило применяется для исходящего пакета на указанном интерфейсе.

Опции

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

log означает, что заголовок пакета будет записан в ipl лог, если пакет соответствует параметрам выбора.

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

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

Когда пакет записывается в лог, заголовки пакета используются пакетом IPL, который создает логи на псевдо-устройстве. Непосредственно за ключевым словом log могут использоваться следующие квалификаторы (в указанном порядке):

body означает, что после заголовков будут записаны первые 128 бит содержимого пакета.

first – если ключевое слово log используется вместе с опцией keep state, рекомендуется, чтобы данная опция также применялась, так как в этом случае только начальный пакет заносится в лог, но не пакеты, которые в дальнейшем соответствуют информации keep state.

SELECTION

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

PROTO

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

tcp/udp | udp | tcp | icmp или название любого другого протокола, которое находится в /etc/protocols. Ключевое слово tcp/udp может использоваться для указания соответствия пакета либо ТСР, либо UDP, и добавлено для удобства.

SRC_ADDR / DST_ADDR

Ключевое слово all является синонимом для from any to any без каких-либо других параметров.

from src to dst: ключевые слова from и to используются для указания соответствующих IP-адресов. В правилах должны быть указаны оба параметра, и источник, и получатель. any является специальным ключевым словом, которое соответствует любому IP-адресу. Примеры использования: from any to any, from 0.0.0.0/0 to any, from 0.0.0.0 to any.

IP-адреса должны быть указаны как в форме dot-нотации с указанием длины маски, так и в форме единственного IP-адреса в dot-нотации.

PORT

Когда проверяется соответствие порта, то может использоваться либо целое число номера порта, либо название сервиса из /etc/services. Когда порт указывается как часть объекта from, он соответствует номеру порта источника; когда он появляется как часть объекта to, он соответствует номеру порта получателя. Использование опции port с объектом to является обязательным требованием для модернизированной логики обработки правил. Пример использования: from any to any port=80.

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

port "=" | "!=" | ">" | ";<" | ";<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge"

Для того чтобы указать диапазон портов, следует использовать

port "<>" | "><"
TCP_FLAG

Флаги устанавливаются только для ТСР-фильтрации. Буквы указывают один из возможных флагов, который может быть установлен в заголовке ТСР-пакета. В модернизированной логике обработки пакетов используется параметр flags S для идентификации запроса начала сессии.

STATEFUL

keep state указывает, что в правиле pass любые пакеты, которые соответствуют параметрам выбора в правиле, должны активизировать stateful возможность фильтрации.

Замечание. Данная опция является обязательной для модернизированной логики обработки правил.

Stateful-фильтрация

Stateful фильтрация обрабатывает трафик как двунаправленный обмен пакетами, при котором выполняется установление сессии. Во время активизации keep state динамически создаются внутренние правила для каждого ожидаемого пакета, которыми обмениваются исходные отправитель и получатель. Любые пакеты, которые не соответствуют образцу установления сессии, автоматически отвергаются как ложные.

Поддержка состояния допускает наличие ICMP-пакетов, относящихся к ТСР- или UDP-сессии. Также пакет, который IPF может рассматривать как часть активной сессии, даже если это другой протокол, будет пропущен.

Рассмотрим, что происходит при установлении сессии.

Исходящий пакет на интерфейсе, во-первых, проверяется в динамической таблице состояний. Если пакет соответствует очередному ожидаемому пакету при установлении сессии, то он пропускается пакетным фильтром и состояние установления сессии в динамической таблице состояния изменяется. Следующие пакеты будут проверяться новым множеством исходящих правил.

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

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

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

Пример включающего набора правил

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

Все UNIX системы, включая FreeBSD, разработаны с возможностью использования интерфейса lo0 и IP-адреса 127.0.0.1 для внутреннего взаимодействия с ОС. Пакетный фильтр должен содержать правила, допускающие свободное беспрепятственное перемещение этих внутренних пакетов.

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

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

Во-первых, правила должны быть разбиты на три основных раздела:

Правила, для которых более часто выполняется соответствие, должны быть написаны выше правил, для которых соответствие выполняется реже. Последнее правило в разделе должно блокировать и заносить в лог все пакеты для данного интерфейса и направления.

Раздел для исходящего трафика в приведенном ниже наборе правил содержит только pass правила, имеющие значения выбора и определяющие сервисы, которым разрешен доступ в Интернет. Все правила имеют опции quick, on, proto, port, keep state. Правила proto tcp имеют опцию flag, установленную для определения стартового пакета запроса сессии для активизации возможности поддержки состояния (stateful).

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

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

Если в правиле указано log first, то сообщение в лог записывается только один раз, независимо от того, сколько раз выполнялось соответствие. Чтобы определить, сколько раз для данного правила выполнялось соответствие, надо выполнить команду ipfstat –hio.

Следует закрыть все номера портов Троянских программ, список которых можно найти по адресу http://www.simovits.com/trojans/trojans.html.

Следующий набор правил определяет включающий тип пакетного фильтра. В реальной системе достаточно раскомментировать правила pass для сервисов, которые необходимо аутентифицировать.

После этого следует просмотреть сообщения в логах и добавить правило block в раздел для входящего трафика.

Необходимо также изменить название интерфейса dc0 в каждом правиле на название интерфейса в вашей системе, который соединяется с Интернетом. Для использования РРР следует указать tun0.

Пример списка правил в /etc/ipf.rules.

#################################################################
    # No restrictions on Inside LAN Interface for private network
    # Not needed unless you have LAN
    #################################################################
    #pass out quick on xl0 all
    #pass in quick on xl0 all

    #################################################################
    # No restrictions on Loopback Interface
    #################################################################
    pass in quick on lo0 all
    pass out quick on lo0 all

    #################################################################
    # Interface facing Public Internet (Outbound Section)
    # Interrogate session start requests originating from behind the
    # firewall on the private network
    # or from this gateway server destine for the public Internet.
    #################################################################

    # Allow out access to my ISP's Domain name server.
    # xxx must be the IP address of your ISP's DNS.
    # Dup these lines if your ISP has more than one DNS server
    # Get the IP addresses from /etc/resolv.conf file
    pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state
    pass out quick on dc0 proto udp from any to xxx port = 53 keep state

    # Allow out non-secure standard www function
    pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state

    # Allow out secure www function https over TLS/SSL
    pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state

    # Allow out send & get email function
    pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state
    pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state

    # Allow out Time
    pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state
    # Allow out gateway & LAN users non-secure FTP ( both passive & 
    # active modes)
    # This function uses the IPNAT built in FTP proxy function coded in
    # the nat rules file to make this single rule function correctly.
    # If you want to use the pkg_add command to install application 
    # packages
    # on your gateway system you need this rule.
    pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state

    # Allow out secure FTP, Telnet, and SCP
    # This function is using SSH (secure shell)
    pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state

    # Allow out non-secure Telnet
    pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state

    # Allow out ping to public Internet
    pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state

    # Block and log only the first occurrence of everything
    # else that's trying to get out.
    # This rule enforces the block all by default logic.
    block out log first quick on dc0 all

    #################################################################
    # Interface facing Public Internet (Inbound Section)
    # Interrogate packets originating from the public Internet
    # destine for this gateway server or the private network.
    #################################################################

    # Block all inbound traffic from non-routable or reserved address
    # spaces
    block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 
     #private IP
    block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 
     #private IP
    block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 
     #private IP
    block in quick on dc0 from 127.0.0.0/8 to any #loopback
    block in quick on dc0 from 0.0.0.0/8 to any #loopback
    block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-
     #config
    block in quick on dc0 from 192.0.2.0/24 to any #reserved 
     #for docs

    ############ Block a bunch of different nasty things. ###########
    # That I do not want to see in the log

    # Block frags
    block in quick on dc0 all with frags

    # Block short tcp packets
    block in quick on dc0 proto tcp all with short

    # block source routed packets
    block in quick on dc0 all with opt lsrr
    block in quick on dc0 all with opt ssrr

    # Block nmap OS fingerprint attempts
    # Log first occurrence of these so I can get their IP address
    block in log first quick on dc0 proto tcp from any to any flags FUP

    # Block anything with special options
    block in quick on dc0 all with ipopts

    # Block public pings
    block in quick on dc0 proto icmp all icmp-type 8

    # Block ident
    block in quick on dc0 proto tcp from any to any port = 113

    # Block all Netbios service. 137=name, 138=datagram, 139=session
    # Netbios is MS/Windows sharing services.
    # Block MS/Windows hosts2 name server requests 81
    block in log first quick on dc0 proto tcp/udp from any to any port = 137
    block in log first quick on dc0 proto tcp/udp from any to any port = 138
    block in log first quick on dc0 proto tcp/udp from any to any port = 139
    block in log first quick on dc0 proto tcp/udp from any to any port = 81

    # Allow in standard www function because I have apache server
    pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state

    # Allow in non-secure Telnet session from public Internet
    #labeled non-secure because ID/PW passed over public Internet as #clear text.
    # Delete this sample group if you do not have telnet server #enabled.
    pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state

    # Allow in secure FTP, Telnet, and SCP from public Internet
    # This function is using SSH (secure shell)
    pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state

    # Block and log only first occurrence of all remaining traffic
    # coming into the firewall. The logging of only the first
    # occurrence stops a .denial of service. attack targeted
    # at filling up your log file space.
    # This rule enforces the block all by default logic.
    block in log first quick on dc0 all
    ################### End of rules file #######################
Пример 3.1. (html, txt)

NAT

С помощью NAT осуществляется трансляция сетевых адресов. Это аналогично Linux, понятию IP Masquerading; NAT и IP Masquerading являются синонимами. Одной из многих функций, которую обеспечивает NAT, является возможность иметь частные адреса в локальной сети, расположенной за пакетным фильтром.

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

Существует специальный диапазон адресов, зарезервированный для NAT-адресов. В соответствии с RFC 1918, для частных сетей можно использовать следующие диапазоны IP-адресов, для которых никогда не будет выполняться роутинг в Интернете:

10.0.0.0 – 10.255.255.255
    172.16.0.0 – 172.31.255.255
    192.168.0.0 – 192.168.255.255

IPNAT

Правила NAT загружаются с помощью команды ipnat. Обычно правила NAT хранятся в /etc/ipnat.rules.

При внесении изменений в правила NAT после того, как NAT запущен, следует отредактировать файл, содержащий правила NAT, затем выполнить команду NAT ipnat с флагами –CF для удаления существующих правил NAT и очистки всех записей в таблице трансляции.

Для перезагрузки правил NAT следует выполнить команду

# ipnat -CF -f /etc/ipnat.rules

Чтобы посмотреть статистику NAT, следует выполнить

# ipnat -s

Чтобы посмотреть список текущих отображений в таблице NAT, следует выполнить

# ipnat -l

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

# ipnat –v

Правила IPNAT

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

Синтаксис, представленный здесь, — упрощенный. Полный синтаксис следует искать в соответствующей man странице.

Синтаксис правила NAT выглядит аналогичным образом:

map IF LAN_IP_RANGE -> PUBLIC_ADDRESS

Правило начинается с ключевого слова map.

Следует заменить IF на внешний интерфейс.

LAN_IP_RANGE – это те IP-адреса, которыми пользуются внутренние клиенты.

PUBLIC_ADDRESS может быть либо внешним IP-адресом, либо специальным значением 0/32, которое означает использование IP-адреса, связанного с IF.

Как работает NAT

Пакет поступает в пакетный фильтр из локальной сети с адресом получателя, расположенным в Интернете. Он пропускается через правила фильтрации для исходящего трафика. Затем получает пакет NAT и просматривает свои правила сверху вниз; применяется первое правило, которому соответствует пакет. NAT проверяет каждое свое правило на соответствие имени интерфейса и IP-адресу источника в пакете. Когда имя интерфейса пакета соответствует правилу NAT, то IP-адрес источника (т.е. в данном случае IP-адрес локальной сети) в пакете проверяется, чтобы выяснить, не попал ли он в диапазон IP-адресов, указанный слева от символа стрелки в правиле NAT. Если это так, то его IP-адрес источника заменяется IP-адресом, указанным справа от стрелки в правиле NAT. При этом NAT создает запись в своей внутренней таблице. Поэтому, когда пакет возвращается из Интернет, он может быть отображен обратно в свой исходный IP-адрес в локальной сети и затем передан правилам фильтрации для дальнейшей обработки.

Запуск NAT

Чтобы указать необходимость NAT, следует добавить определенные утверждения в /etc/rc.conf.

Для запуска роутинга трафика между интерфейсами:

gateway_enable="YES"

Для автоматического запуска IPNAT:

ipnat_enable="YES"

Для указания файла, в котором определены правила:

ipnat_rules="/etc/ipnat.rules"

NAT для очень больших LAN

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

Указание порта

Обычное правило NAT выглядит таким образом:

map dc0 192.168.1.0/24 -> 0/32

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

map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000

Также существует возможность упростить использование этого отображения, указав ключевое слово auto. Это будет означать, что IPNAT сам определит, какие порты доступны для использования:

map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto
Использование пула публичных адресов

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

map dc0 192.168.1.0/24 -> 204.134.75.1

Данное правило отображает все соединения в 204.134.75.1. Это может быть изменено указанием диапазона

map dc0 192.168.1.0/24 -> 204.134.75.1-10

Или можно указать подсеть, используя CIDR-нотацию:

map dc0 192.168.1.0/24 -> 204.134.75.0/24

Port Redirection

Очень распространенной практикой является иметь web-сервер, e-mail сервер, сервер баз данных и DNS-сервер, каждый из которых расположен на отдельной машине в локальной сети. В этом случае трафик от этих серверов также может использовать NAT, но должен существовать способ перенаправить входящий трафик к нужным компьютерам в локальной сети. IPNAT имеет такую возможность перенаправления и может решить данную проблему. Пусть имеется web-сервер в локальной сети с адресом 10.0.10.25 и существует единственный публичный IP-адрес, который равен 20.20.20.5. Следует использовать правило

rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80

или

rdr dc0 0/32 port 80 -> 10.0.10.25 port 80

или, для DNS-сервера, расположенного в локальной сети с адресом 10.0.10.33, которому необходимо получать публичные DNS-запросы,

rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp

FTP и NAT

FTP имеет следующую особенность: он может выполняться в активном и пассивном режиме. Различие состоит в том, как создается канал данных. Пассивный режим является более безопасным, так как канал данных создается тем, кто запрашивает ftp-сессию.

Правила IPNAT

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

Данное правило будет управлять всем трафиком для внутренней локальной сети:

map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp

Данное правило обрабатывает FTP-трафик от шлюза:

map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp

Данное правило обрабатывает весь не-FTP-трафик от внутренней локальной сети:

map dc0 10.0.10.0/29 -> 0/32

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

Правила фильтрации IPNAT FTP

Необходимо только одно правило фильтрации для FTP, если используется NAT FTP-proxy.

Без FTP-прокси необходимы следующие три правила:

# Allow out LAN PC client FTP to public Internet
    # Active and passive modes
    pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state

    # Allow out passive mode data channel high order port numbers
    pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state
    # Active mode let data channel in from FTP server
    pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state

IPFW

IPFIREWALL ( IPFW ) является пакетным фильтром, изначально существовавшем во FreeBSD. Он использует наследуемые правила без поддержки состояния и наследуемую технологию представления правил для получения так называемой Simple Stateful логики.

Множество правил IPFW ( /etc/rc.firewall ) в стандартной инсталляции FreeBSD является скорее примером, и не предполагается, что оно будет непосредственно применяться без модификации. Пример не использует фильтрование с поддержкой состояния, поэтому он рассматривается как базовый в данном разделе.

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

IPFW состоит из семи компонент. Исходной компонентой является процессор правил фильтрования из ядра firewall’а и интегрированная с ним возможность подсчета пакетов, возможность создания логов, правило divert, которое запускает NAT и некоторые дополнительные возможности, возможности шейпинга трафика, возможность перенаправления fwd rule, возможность моста и возможность невидимого ip.

Указание необходимости использования IPFW

IPFW включен в базовую инсталляцию FreeBSD в качестве отдельного загружаемого модуля времени выполнения. Система динамически загружает модуль ядра, если в rc.conf используется утверждение firewall_enable="YES". Нет необходимости компилировать IPFW в ядро FreeBSD, если нет необходимости в функции NAT.

После перезапуска системы с firewall_enable="YES" в rc.conf, на экране высветится следующее сообщение как часть процесса запуска:

ipfw2 initialized, divert disabled, rule-based forwarding disabled, 
      default to deny, logging disabled

Загружаемый модуль не имеет встроенной возможности создания логов. Чтобы включить возможности их создания и установить для них ограничения, следует добавить утверждения в /etc/sysctl.conf:

net.inet.ip.fw.verbose=1
    net.inet.ip.fw.verbose_limit=5

Опции ядра

Не существует требования компилировать IPFW в ядро, если нет необходимости в функции NAT.

options IPFIREWALL

Данная опция дает возможность IPFW функционировать как часть ядра.

options IPFIREWALL_VERBOSE

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

options IPFIREWALL_VERBOSE_LIMIT=5

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

options IPFIREWALL_DEFAULT_TO_ACCEPT

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

options IPV6FIREWALL
 options IPV6FIREWALL_VERBOSE
 options IPV6FIREWALL_VERBOSE_LIMIT
 options IPV6FIREWALL_DEFAULT_TO_ACCEPT

Данные опции аналогичны опциям IPv4, но они предназначены для IPv6. Если IPv6 не используется, IPFW можно использовать без правил для IPv6.

options IPDIVERT

Это дает возможность использовать функциональность NAT.

Замечание. Если не включено IPFIREWALL_DEFAULT_TO_ACCEPT и не установлены правила, разрешающие входящие пакеты, все пакеты к компьютеру и от него будут блокированы.

Опции /etc/rc.conf

Если IPFW скомпилирован в ядро, то необходимо загрузить его с помощью следующего утверждения в /etc/rc.conf:

firewall_enable="YES"

Установка скриптов для активации правил:

firewall_script="/etc/ipfw.rules"

Необходимость создания логов:

firewall_logging="YES"

Замечание. Переменная firewall_logging устанавливает переменную sysctl net.inet.ip.fw.verbose в значение 1. Не существует в rc.conf переменной для установки ограничений логов, но ограничение может быть установлено посредством переменной sysctl вручную или из файла /etc/sysctl.conf.

net.inet.ip.fw.verbose_limit=5

Если компьютер функционирует в качестве шлюза и, в частности, предоставляет сервис NAT, следует использовать дополнительные опции в /etc/rc.conf.

Команды IPFW

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

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

Для того чтобы получить список всех правил, следует выполнить

# ipfw list

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

# ipfw –t list

Для того чтобы получить список информации счетчиков, следует выполнить команду с параметром –a. В первом столбце будет указан номер правила, далее следует количество исходящих пакетов, соответствующих правилу, и количество входящих пакетов, соответствующих правилу, а затем само правило.

# ipfw –a list

Показать последние динамические правила, добавленные к статическим правилам:

# ipfw –d list

Показать истекшие динамические правила:

# ipfw –d –e list

Обнулить счетчики:

# ipfw zero

Обнулить счетчики только для правила с номером NUM:

# ipfw zero NUM

Набор правил IPFW

С помощью правил можно разрешить или запретить прохождение пакета, основываясь на значениях, содержащихся в его заголовках. Понятие сессии означает двунаправленный обмен пакетами между хостами. С точки зрения сессии можно считать, что набор правил пакетного фильтра обрабатывает пакет дважды: один раз — когда тот поступает на внешний интерфейс, и второй — когда покидает хост через данный интерфейс. Каждый tcp/ip сервис (например, telnet, www, mail и т.п.) определяется своим протоколом и номером порта. Это является базовым критерием при создании правил, которые разрешают или запрещают сервис.

Когда пакет поступает в пакетный фильтр, он сравнивается с первым правилом в наборе правил и затем продвигается сверху вниз по набору в порядке возрастания номеров правил. Если пакет соответствует параметрам правила, выполняется действие, указанное в правиле, и для данного пакета обработка завершается. Это называется методом поиска "первое найденное соответствие". Если пакет не соответствует никакому из правил, он обрабатывается правилом по умолчанию, обязательным для IPFW, с номером 65535, которое запрещает все пакеты, т.е. отбрасывает этот пакет без какого-либо ответа отправителю.

Замечание. Поиск продолжается после count, skipto и tee правил.

Инструкции, указанные здесь, являются основой при использовании правил, которые содержат опции поддержки состояния keep state, limit, in или out. Это является основой для создания включающего (inclusive) типа набора правил пакетного фильтра.

Включающий пакетный фильтр разрешает только те сервисы, которые соответствуют правилам.

Синтаксис правил

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

CMD RULE_NUMBER ACTION LOGGING SELECTION STATEFUL
CMD

Каждое новое правило должно начинаться с префикса add для добавления правила во внутреннюю таблицу.

RULE_NUMBER

Каждое правило имеет номер, с помощью которого можно перейти на данное правило.

ACTION

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

allow | accept | pass | permit

Все эти значения являются аналогичными и означают, что пакеты, которые соответствуют правилу, разрешаются. При этом поиск прекращается.

check-state

Выполняется проверка пакета в таблице динамических правил. Если соответствие найдено, выполняется действие, связанное с правилом, которое создается данным динамическим правилом, в противном случае осуществляется переход к следующему правилу. Правило check-state не имеет критерия выбора. Если правило check-state присутствует в наборе правил, таблица динамических правил проверяется на соответствие правилу поддержки состояния или правилу ограничения.

deny | drop

Оба ключевых слова означают, что пакеты, соответствующие правилу, будут отброшены. Поиск завершается.

Создание логов
log [ logamount ]

Когда пакет соответствует правилу с ключевым словом log, сообщение будет записано посредством syslogd с названием SECURITY. Создание лога происходит только тогда, когда номер пакета, для которого создается лог, не превышает значения параметра logamount. Если logamount не указан, ограничение берется из переменной sysctl net.inet.ip.fw.verbose_limit. В обоих случаях значение "нуль" не считается ограничением создания логов. После того как ограничение достигнуто, создание логов может быть возобновлено чисткой счетчика логов или счетчика пакетов для данного правила, с помощью команды reset log для ipfw.

Замечание. Создание лога выполняется после того, как весь остальной пакет, соответствующий условию, будет успешно проверен, и перед выполнением заключительного действия ( accept, deny ) для пакета.

Selection

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

udp | tcp | icmp

Также может быть использовано любое другое название протокола, которое указано в /etc/protocols. Это значение является протоколом, соответствие с которым будет проверяться.

from src to dst

Ключевые слова from и to используются для поиска соответствия с IP-адресами. Правила должны указывать ОБА параметра как источника, так и назначения. any является специальным ключевым словом, которое соответствует любому IP-адресу. me является специальным ключевым словом, которое соответствует любому IP-адресу, сконфигурированному на интерфейсе системы, на которой выполняется пакетный фильтр (например, from me to any или from any to me ). IP-адреса указываются в dot-нотации IP-адреса со "/" и длиной маски. Это — обязательное требование.

port <number>

Используется для протоколов, которые поддерживают номера портов (таких как ТСР и UDP). Вместо значения номера порта может быть указано имя сервиса из /etc/services.

in | out

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

via IF

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

setup

Это является обязательным ключевым словом, которое идентифицирует запрос начала установки сессии для ТСР-пакетов.

keep-state

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

limit { src-addr | src-port | dst-addr | dst-port }

Указывается, что пакетный фильтр разрешает только N соединений с одним и тем же набором параметров. Может быть указано один или более адресов и портов источника и получателя. limit и keep-state не могут быть одновременно указаны в одном и том же правиле. Limit предоставляет определенную возможность поддержки состояния, как и keep-state, но также имеет и дополнительные возможности.

Опции правила Stateful

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

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

Динамические правила уязвимы для исчерпания ресурсов с помощью SYN-flood атаки, при которой создается большое число динамических правил. Для отражения данной атаки во FreeBSD версии 4.5 добавлена новая опция, называемая limit. Эта опция используется для ограничения количества одновременно устанавливаемых сессий с помощью просмотра полей источника или получателя в правиле, которое выполняется, если установлена опция limit. Если значение счетчика больше, чем значение, указанное в опции limit, пакет отбрасывается.

Создание логов

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

Даже при установленной возможности создания логов IPFW не создает логи для каждого своего правила. Администратор пакетного фильтра сам решает, какие правила он хочет записывать в лог, и добавляет признак log в эти правила. Обычно это добавляется только для правил deny, например, для правила deny для входящих ICMP-пакетов. Также признак log добавляется в самое последнее правило. Это позволяет отследить все пакеты, которые не соответствовали ни одному из правил.

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

Опция ядра IPFIREWALL_VERBOSE_LIMIT=5 ограничивает количество последовательных сообщений, посылаемых в syslogd, которые касаются пакета, соответствующего данному правилу. Когда данная опция установлена в ядре, количество последовательных сообщений, относящихся к конкретному правилу, не превышает указанного количества. Никогда не будет создано 200 сообщений лога, говорящих об одном и том же. Например, пять последовательных сообщений, касающихся конкретного правила, будут занесены в syslogd, оставшиеся сообщения будут подсчитаны и занесены в syslogd с помощью примерно такой фразы:

last message repeated 45 times

Все сообщения по умолчанию записываются в файл /etc/log/security, который определяется в файле /etc/syslog.conf.

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

Опытные администраторы IPFW создают файл, содержащий правила и код, который затем выполняется в виде скрипта. Основное преимущество состоит в том, что правила пакетного фильтра могут быть изменены без необходимости перезапуска системы. Этот метод очень удобен при тестировании новых правил, так как данная процедура может быть выполнена много раз. При написании скрипта можно создавать символьные подстановки для обозначения часто используемых значений и затем указывать их в нескольких правилах. Синтаксис скрипта совместим с sh, csh и tcsh shell’ами. Поля символьной подстановки должны начинаться со знака $. Символьные поля не имеют префикса $. Значение, которое принимает символьное поле, должно быть заключено в двойные кавычки.

Файл правил должен начинаться примерно так:

############### start of example ipfw rules script #############
    #
    ipfw -q -f flush  # Delete all rules
    # Set defaults
    oif="tun0"    # out interface
    odns="192.0.2.11"  # ISP's DNS server IP address
    cmd="ipfw -q add " # build rule prefix
    ks="keep-state"  # just too lazy to key this each time
    $cmd 00500 check-state
    $cmd 00502 deny all from any to any frag
    $cmd 00501 deny tcp from any to any established
    $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks
    $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks
    $cmd 00611 allow udp from any to $odns 53 out via $oif $ks
    ################### End of example ipfw rules script ############

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

Если приведенный выше пример находится в файле /etc/ipfw.rules, то эти правила могут быть загружены с помощью следующего ввода в командной строке:

# sh /etc/ipfw.rules

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

# ipfw -q -f flush
    # ipfw -q add check-state
    # ipfw -q add deny all from any to any frag
    # ipfw -q add deny tcp from any to any established
    # ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state
    # ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state
    # ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state
Набор правил Stateful

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

Как и все UNIX-системы, FreeBSD разработана с использованием интерфейса lo0 и IP-адреса 127.0.0.1 для внутреннего взаимодействия с ОС. Правила пакетного фильтра должны разрешать свободную пересылку этих внутренних пакетов.

Будем предполагать, что один интерфейс соединен с Интернетом. Для этого интерфейса должны быть определены правила управления доступом в Интернет и из Интернета. Это может быть РРР tun0 интерфейс или сетевая карта, которая соединяется с Интернетом.

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

Первым делом правила должны быть разбиты на три основных раздела:

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

Раздел для исходящего трафика в следующем наборе правил содержит только правила allow, определяющие значения выбора, которые уникально идентифицируют сервис, разрешенный в Интернете. Все правила имеют proto, port, in/out, via и keep state опции. proto tcp правила имеют опцию setup, определяющую начальный пакет запроса установления сессии для передачи этой информации в таблицу поддержки состояния.

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

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

Пример включающего набора правил

Следующий не содержащий NAT набор правил является полным набором правил включающего типа. Следует изменить название интерфейса dc0 в каждом правиле на название интерфейса сетевой карточки, который используется в системе для соединения с Интернетом. Например, для РРР пользователей следует указать tun0.

Рассмотрим пример, используемый в данных правилах:

Следующие правила указываются в /etc/ipfw.rules.

################ Start of IPFW rules file ######################
# Flush out the list before we begin.
ipfw -q -f flush
# Set rules command prefix
cmd="ipfw -q add"
pif="dc0"   # public interface name of NIC
     # facing the public Internet
#################################################################
# No restrictions on Inside LAN Interface for private network
# Not needed unless you have LAN.
# Change xl0 to your LAN NIC interface name
#################################################################
#$cmd 00005 allow all from any to any via xl0

#################################################################
# No restrictions on Loopback Interface
#################################################################
$cmd 00010 allow all from any to any via lo0

#################################################################
# Allow the packet through if it has previous been added to the
# the "dynamic" rules table by a allow keep-state statement.
#################################################################
$cmd 00015 check-state
#################################################################
# Interface facing Public Internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network or from this gateway server
# destine for the public Internet.
#################################################################
# Allow out access to my ISP's Domain name server.
# x.x.x.x must be the IP address of your ISP.s DNS
# Dup these lines if your ISP has more than one DNS server
# Get the IP addresses from /etc/resolv.conf file
$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state
$cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state

# Allow out non-secure standard www function
$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state

# Allow out secure www function https over TLS SSL
$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state

# Allow out send & get email function
$cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state
$cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state

# Allow out ping
$cmd 00250 allow icmp from any to any out via $pif keep-state

# Allow out Time
$cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state

# Allow out secure FTP, Telnet, and SCP
# This function is using SSH (secure shell)
$cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state

# deny and log everything else that.s trying to get out.
# This rule enforces the block all by default logic.
$cmd 00299 deny log all from any to any out via $pif

#################################################################
# Interface facing Public Internet (Inbound Section)
# Interrogate packets originating from the public Internet
# destine for this gateway server or the private network.
#################################################################

# Deny all inbound traffic from non-routable reserved address spaces
#RFC1918 private IP
$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif  $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif  #RFC 1918 private IP
$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif  
$cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback
$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback
$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif 
#DHCP auto-config
$cmd 00306 deny all from 192.0.2.0/24 to any in via $pif 

# Deny public pings
$cmd 00310 deny icmp from any to any in via $pif

# Deny ident
$cmd 00315 deny tcp from any to any 113 in via $pif

# Deny all Netbios service. 137=name, 138=datagram, 139=session
# Netbios is MS/Windows sharing services.
# Block MS/Windows hosts2 name server requests 81
$cmd 00320 deny tcp from any to any 137 in via $pif
$cmd 00321 deny tcp from any to any 138 in via $pif
$cmd 00322 deny tcp from any to any 139 in via $pif
$cmd 00323 deny tcp from any to any 81 in via $pif
# Deny any late arriving packets
$cmd 00330 deny all from any to any frag in via $pif

# Deny ACK packets that did not match the dynamic rule table
$cmd 00332 deny tcp from any to any established in via $pif
# Allow in standard www function because I have apache server
$cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2

# Allow in secure FTP, Telnet, and SCP from public Internet
$cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2

# Allow in non-secure Telnet session from public Internet
# labeled non-secure because ID & PW are passed over public
# Internet as clear text.
# Delete this sample group if you do not have telnet server 
# enabled.
$cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2

# Reject &Log all incoming connections from the outside
$cmd 00499 deny log all from any to any in via $pif

# Everything else is denied by default
# deny and log all packets that fell through to see what they are
$cmd 00999 deny log all from any to any
################ End of IPFW rules file ########################
Пример 3.2. (html, txt)
Пример совместного использования NAT и Stateful

Существуют некоторые дополнительные конфигурационные утверждения, которые дают возможность активизировать функцию NAT в IPFW. В ядро должно быть добавлено утверждение option divert.

В дополнение к обычным опциям IPFW в /etc/rc.conf необходимо добавить следующее:

natd_enable="YES"   # Enable NATD function
natd_interface="rl0"  # interface name of public Internet NIC
natd_flags="-dynamic -m" # -m = preserve port numbers if possible

Использование правил поддержки состояния вместе с правилом divert natd для трансляции сетевых адресов существенно усложняет логику правил. Взаимное расположение правил проверки состояния и divert natd становится очень критичным. Уже не используется простая логика последовательного прохождения правил. Определено новое действие, называемое skipto. При использовании skipto необходимо знать номер каждого правила, чтобы точно указать номер того правила, на которое следует перейти.

Рассмотрим пример использования NAT и поддержки состояния, чтобы понять последовательность прохождения пакета через наборы правил.

Анализ пакета на соответствие правилам начинается с первого правила в файле правил и продолжается по одному правилу вниз по файлу до тех пор, пока не будет достигнут конец или не будет найдено соответствие пакета критериям выбора. После этого пакет покидает пакетный фильтр. Важно помнить о расположении правил с номерами 100, 101, 450, 500 и 510. Они управляют преобразованием исходящих и входящих пакетов, а именно эти записи в динамической таблице поддержки состояния всегда регистрируют частные IP-адреса локальной сети. Далее, важно помнить, что во всех разрешающих и запрещающих правилах указывается направление прохождения пакета (входящий или исходящий) и интерфейс. Также следует помнить, что все запросы начала исходящей сессии всегда переходят на правило 500 для выполнения трансляции сетевого адреса.

Пусть локальный пользователь использует браузер для получения web-страницы. Web-сервер для взаимодействия использует порт 80 (см. пример набора правил №1). Когда пакет поступает в пакетный фильтр, он не соответствует правилу 100, потому что снабжен заголовком out, а не in. Он передается правилу 101. Этому правилу пакет также не соответствует, потому что это первый пакет и он еще не передается в динамическую таблицу поддержки состояния. Наконец, пакет поступает в правило 125, которому он соответствует. Пакет выходит через сетевую карточку, которая подключена к Интернету. Пакет все еще имеет IP-адрес локальной сети в качестве IP-адреса источника. При обнаружении соответствия данному правилу выполняются два действия. Опция keep-state передает информацию в таблицу динамических правил поддержки состояния. После этого выполняется действие skipto rule 500. Правило 500 применяет NAT для IP-адреса пакета и отправляет его в Интернет. Данный пакет поступает к получателю и возвращается обратно для завершения установления ТСР-соединения. При этом пакет попадает в первое правило из набора правил. В этот момент он соответствует правилу 100, и его IP-адрес получателя преобразуется обратно в IP-адрес локальной сети. Затем он будет передан правилу проверки состояния. При этом он будет найден в таблице как соответствующий открытой сессии и передан в локальную сеть. Пакет передается на рабочую станцию в локальной сети, которая его посылала. Новый пакет посылается для запроса данных от удаленного сервера. В тот момент, когда он получен, он проверяется правилом проверки состояния, и если запись для данного исходящего пакета существует, указанное действие skipto 500 выполняется. Пакет переходит на правило 500, выполняется NAT, и пакет покидает пакетный фильтр.

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

Рассмотрим другой пример. Пусть существует сервер Apache, выполняющийся на том же хосте, что и пакетный фильтр, и мы хотим, чтобы имелся доступ из Интернета к web-сайту. Пакет запроса нового входящего соединения соответствует правилу 100, и его IP-адрес преобразуется в локальный IP-адрес для хоста пакетного фильтра. Затем пакет проверяется снова на соответствие всем опасным признакам, которые следует проверять, и, наконец, определяется, что пакет соответствует правилу 420. После этого происходит следующее. По этому правилу пакет передается в динамическую таблицу поддержки состояния, при этом количество новых запросов создания сессии, исходящих от того же самого IP-адреса источника, не должно превышать двух. Это предохраняет от DoS-атак на сервис, выполняющийся по конкретному номеру порта. Пакет пропускается. При возврате правило проверки состояния распознает пакет как принадлежащий существующему открытию сессии и посылает его правилу 500 для выполнения NAT и передачи на исходящий интерфейс.

Пример набора правил № 1:

#!/bin/sh
cmd="ipfw -q add"
skip="skipto 500"
pif=rl0
ks="keep-state"
good_tcpo="22,25,37,43,53,80,443,110,119"

ipfw -q -f flush

$cmd 002 allow all from any to any via xl0  # exclude LAN traffic
$cmd 003 allow all from any to any via lo0  #exclude loopback traffic

$cmd 100 divert natd ip from any to any in via $pif
$cmd 101 check-state
# Authorized outbound packets
$cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks
$cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks
$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks
$cmd 130 $skip icmp from any to any out via $pif $ks
$cmd 135 $skip udp from any to any 123 out via $pif $ks

# Deny all inbound traffic from non-routable reserved address spaces
$cmd 300 deny all from 192.168.0.0/16 to any in via $pif 
#RFC1918private IP
$cmd 301 deny all from 172.16.0.0/12 to any in via $pif  
#RFC 1918 private IP
$cmd 302 deny all from 10.0.0.0/8  to any in via $pif  
#RFC 1918 private IP
$cmd 303 deny all from 127.0.0.0/8  to any in via $pif  
#loop-back
$cmd 304 deny all from 0.0.0.0/8   to any in via $pif  
#loop-back
$cmd 305 deny all from 169.254.0.0/16 to any in via $pif 
#DHCP auto-config
$cmd 306 deny all from 192.0.2.0/24  to any in via $pif  
#reserved for docs
$cmd 307 deny all from 204.152.64.0/23 to any in via $pif  
#Sun cluster
$cmd 308 deny all from 224.0.0.0/3  to any in via $pif  
#Class D & E multicast

# Authorized inbound packets
$cmd 400 allow udp from xx.70.207.54 to any 68 in $ks
$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1

$cmd 450 deny log ip from any to any

# This is skipto location for outbound stateful rules
$cmd 500 divert natd ip from any to any out via $pif
$cmd 510 allow ip from any to any
 
######################## end of rules  ##################
Пример 3.3. (html, txt)

Следующий пример аналогичен предыдущему, но содержит большее количество комментариев.

Пример набора правил № 2:

#!/bin/sh
################ Start of IPFW rules file #######################
# Flush out the list before we begin.
ipfw -q -f flush
# Set rules command prefix
cmd="ipfw -q add"
skip="skipto 800"
pif="rl0"     # public interface name of NIC
             # facing the public Internet

#################################################################
# No restrictions on Inside LAN Interface for private network
# Change xl0 to your LAN NIC interface name
#################################################################
$cmd 005 allow all from any to any via xl0

#################################################################
# No restrictions on Loopback Interface
#################################################################
$cmd 010 allow all from any to any via lo0

#################################################################
# check if packet is inbound and nat address if it is
#################################################################
$cmd 014 divert natd ip from any to any in via $pif

#################################################################
# Allow the packet through if it has previous been added to the
# the "dynamic" rules table by a allow keep-state statement.
#################################################################
$cmd 015 check-state

#################################################################
# Interface facing Public Internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network or from this gateway server
# destine for the public Internet.
#################################################################
# Allow out access to my ISP's Domain name server.
# x.x.x.x must be the IP address of your ISP's DNS
# Dup these lines if your ISP has more than one DNS server
# Get the IP addresses from /etc/resolv.conf file
$cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state

# Allow out secure www function https over TLS SSL
$cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state

# Allow out send & get email function
$cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state
$cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state

# Allow out ping
$cmd 080 $skip icmp from any to any out via $pif keep-state

# Allow out Time
$cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state

# Allow out secure FTP, Telnet, and SCP
# This function is using SSH (secure shell)
$cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state

# Allow ntp time server
$cmd 130 $skip udp from any to any 123 out via $pif keep-state

#################################################################
# Interface facing Public Internet (Inbound Section)
# Interrogate packets originating from the public Internet
# destine for this gateway server or the private network.
#################################################################

# Deny all inbound traffic from non-routable reserved address 
# spaces
#RFC
$cmd 300 deny all from 192.168.0.0/16 to any in via $pif   
1918 private IP
$cmd 301 deny all from 172.16.0.0/12 to any in via $pif  
$cmd 302 deny all from 10.0.0.0/8  to any in via $pif  
$cmd 303 deny all from 127.0.0.0/8  to any in via $pif  
#loopback
$cmd 304 deny all from 0.0.0.0/8   to any in via $pif  
#loopback
$cmd 305 deny all from 169.254.0.0/16 to any in via $pif  
#DHCP auto-config

# Deny ident
$cmd 315 deny tcp from any to any 113 in via $pif

# Deny all Netbios service. 137=name, 138=datagram, 139=session
# Netbios is MS/Windows sharing services.
# Block MS/Windows hosts2 name server requests 81
$cmd 320 deny tcp from any to any 137 in via $pif
$cmd 321 deny tcp from any to any 138 in via $pif
$cmd 322 deny tcp from any to any 139 in via $pif
$cmd 323 deny tcp from any to any 81  in via $pif

# Deny any late arriving packets
$cmd 330 deny all from any to any frag in via $pif

# Deny ACK packets that did not match the dynamic rule table
$cmd 332 deny tcp from any to any established in via $pif

# Allow in standard www function because I have Apache server
$cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2

# Allow in secure FTP, Telnet, and SCP from public Internet
$cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2

# Allow in non-secure Telnet session from public Internet
# labeled non-secure because ID & PW are passed over public
# Internet as clear text.
# Delete this sample group if you do not have telnet server 
# enabled.
$cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2

# Reject & Log all unauthorized incoming connections from the 
# public Internet
$cmd 400 deny log all from any to any in via $pif

# Reject & Log all unauthorized out going connections to the 
# public Internet
$cmd 450 deny log all from any to any out via $pif
# This is skipto location for outbound stateful rules
$cmd 800 divert natd ip from any to any out via $pif
$cmd 801 allow ip from any to any

# Everything else is denied by default
# deny and log all packets that fell through to see what they are
$cmd 999 deny log all from any to any
################ End of IPFW rules file #######################
Пример 3.4. (html, txt)

Лекция 4. Intrusion Detection Systems (IDS)

Определяется понятие Intrusion Detection Systems (IDS). Рассматриваются причины, по которым следует использовать IDS. Приводятся различные подходы к классификации IDS. Сравниваются возможности network-based, host-based и application-based IDS. Оцениваются преимущества и недостатки IDS, основанных на определении злоупотреблений и на определении аномалий. Перечисляются возможные ответные действия IDS. Также рассматриваются дополнительные инструментальные средства, такие как системы анализа и оценки уязвимостей и проверки целостности файлов.

Что такое IDS

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

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

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

Почему следует использовать IDS

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

Почему следует использовать IDS, особенно если уже имеются firewall’ы, антивирусные инструментальные средства и другие средства защиты?

Каждое средство защиты адресовано конкретной угрозе безопасности в системе. Более того, каждое средство защиты имеет слабые и сильные стороны. Только комбинируя их (данная комбинация иногда называет безопасностью в глубину ), можно защититься от максимально большого спектра атак.

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

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

  1. Возможность иметь реакцию на атаку позволяет заставить атакующего нести ответственность за собственную деятельность. Это определяется следующим образом: "Я могу прореагировать на атаку, которая произведена на мою систему, так как я знаю, кто это сделал или где его найти". Это трудно реализовать в сетях TCP/IP, где протоколы позволяют атакующим подделать идентификацию адресов источника или другие идентификаторы источника. Также очень трудно осуществить подотчетность в любой системе, которая имеет слабые механизмы идентификации и аутентификации.
  2. Возможность блокирования означает возможность распознать некоторую активность или событие как атаку и затем выполнить действие по блокированию источника. Данная цель определяется следующим образом: "Я не забочусь о том, кто атакует мою систему, потому что я могу распознать, что атака имеет место, и блокировать ее". Заметим, что требования реакции на атаку полностью отличаются от возможности блокирования.

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

Объявления о появлении новых уязвимостей являются общедоступными, например, через публичные сервисы, такие как ICAT (http://icat.nist.gov) или CERT (http://www.cert.org), которые созданы для того, чтобы эти уязвимости нельзя было использовать для выполнения атак. Тем не менее существует много ситуаций, в которых использование этих уязвимостей все же возможно:

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

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

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

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

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

  1. Выполнение документирования существующих угроз для сети и систем.

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

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

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

  1. Получение полезной информации о проникновениях, которые имели место, с предоставлением улучшенной диагностики для восстановления и корректирования вызвавших проникновение факторов.

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

  1. IDS помогает определить расположение источника атак по отношению к локальной сети (внешние или внутренние атаки), что важно при принятии решений о расположении ресурсов в сети.

Типы IDS

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

Большинство коммерческих IDS являются real-time network-based системами.

К характеристикам IDS также относятся:

Архитектура IDS

Архитектура IDS определяет, какие имеются функциональные компоненты IDS и как они взаимодействуют друг с другом. Основными архитектурными компонентами являются: Host — система, на которой выполняется ПО IDS, и Target — система, за которой IDS наблюдает.

Совместное расположение Host и Target

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

Разделение Host и Target

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

Современные IDS, как правило, состоят из следующих компонент:

Способы управления

Стратегия управления описывает, каким образом можно управлять элементами IDS, их входными и выходными данными.

В сети должны поддерживаться следующие связи:

Централизованное управление

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

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

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

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

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

Скорость реакции

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

  1. IDS, реакция которых происходит через определенные интервалы времени (пакетный режим)

    В IDS, реакция которых происходит через определенные интервалы времени, информационный поток от точек мониторинга до инструментов анализа не является непрерывным. В результате информация обрабатывается способом, аналогичным коммуникационным схемам "сохранить и перенаправить". Многие ранние host-based IDS используют данную схему хронометража, так как они зависят от записей аудита в ОС. Основанные на интервале IDS не выполняют никаких действий, являющихся результатом анализа событий.

  2. Real-Time (непрерывные)

    Real-time IDS обрабатывают непрерывный поток информации от источников. Чаще всего это является преобладающей схемой в network-based IDS, которые получают информацию из потока сетевого трафика. Термин "реальное время" используется в том же смысле, что и в системах управления процессом. Это означает, что определение проникновения, выполняемое IDS "реального времени", приводит к результатам достаточно быстро, что позволяет IDS выполнять определенные действия в автоматическом режиме.

Информационные источники

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

Network-Based IDS

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

Network-based IDS часто состоят из множества сенсоров, расположенных в различных точках сети. Эти устройства просматривают сетевой трафик, выполняя локальный анализ данного трафика и создавая отчеты об атаках для центральной управляющей консоли. Многие из этих сенсоров разработаны для выполнения в "невидимом (stealth)" режиме, чтобы сделать более трудным для атакующего обнаружение их присутствия и расположения.

Преимущества network-based IDS:

Недостатки network-based IDS:

Host-Based IDS

Host-based IDS имеют дело с информацией, собранной внутри единственного компьютера. (Заметим, что application-based IDS на самом деле являются подмножеством host-based IDS.) Такое выгодное расположение позволяет host-based IDS анализировать деятельность с большой достоверностью и точностью, определяя только те процессы и пользователей, которые имеют отношение к конкретной атаке в ОС. Более того, в отличии от network-based IDS, host-based IDS могут "видеть" последствия предпринятой атаки, так как они могут иметь непосредственный доступ к системной информации, файлам данных и системным процессам, являющимся целью атаки.

Нost-based IDS обычно используют информационные источники двух типов: результаты аудита ОС и системные логи. Результаты аудита ОС обычно создаются на уровне ядра ОС и, следовательно, являются более детальными и лучше защищенными, чем системные логи. Однако системные логи намного меньше и не столь многочисленны, как результаты аудита, и, следовательно, легче для понимания. Некоторые host-based IDS разработаны для поддержки централизованной инфраструктуры управления и получения отчетов IDS, что может допускать единственную консоль управления для отслеживания многих хостов. Другие создают сообщения в формате, который совместим с системами сетевого управления.

Преимущества host-based IDS:

Недостатки host-based IDS:

Application-Based IDS

Application-Based IDS является специальным подмножеством host-based IDS, которые анализируют события, поступившие в ПО приложения. Наиболее общими источниками информации, используемыми application-based IDS, являются лог-файлы транзакций приложения.

Способность взаимодействовать непосредственно с приложением, с конкретным доменом или использовать знания, специфичные для приложения, позволяет application-based IDS определять подозрительное поведение авторизованных пользователей, которое превышает их права доступа. Такие проблемы могут проявиться только при взаимодействии пользователя с приложением.

Преимущества application-based IDS:

Недостатки application-based IDS:

Анализ, выполняемый IDS

Существует два основных подхода к анализу событий для определения атак: определение злоупотреблений (misuse detection) и определение аномалий (anomaly detection).

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

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

Определение злоупотреблений

Детекторы злоупотреблений анализируют деятельность системы, анализируя событие или множество событий на соответствие заранее определенному образцу, который описывает известную атаку. Соответствие образца известной атаке называется сигнатурой, определение злоупотребления иногда называют "сигнатурным определением". Наиболее общая форма определения злоупотреблений, используемая в коммерческих продуктах, специфицирует каждый образец событий, соответствующий атаке, как отдельную сигнатуру. Тем не менее существует несколько более сложных подходов для выполнения определения злоупотреблений (называемых state-based технологиями анализа), которые могут использовать единственную сигнатуру для определения группы атак.

Преимущества сигнатурного метода:

Недостатки сигнатурного метода:

Определение аномалий

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

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

Только первые две технологии используются в современных коммерческих IDS.

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

Более того, некоторые формы определения аномалий создают выходные данные, которые могут быть далее использованы в качестве источников информации для детекторов злоупотреблений. Например, детектор аномалий, основанный на пороге, может создавать диаграмму, представляющую собой "нормальное" количество файлов, доступных конкретному пользователю; детектор злоупотреблений может использовать данную диаграмму как часть сигнатуры обнаружения, которая говорит: "если количество файлов, доступных данному пользователю, превышает данную "нормальную" диаграмму более чем на 10%, следует инициировать предупреждающий сигнал".

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

Преимущества определения аномалий:

Недостатки определения аномалий:

Возможные ответные действия IDS

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

Активные действия

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

Сбор дополнительной информации

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

Изменение окружения

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

Выполнение действия против атакующего

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

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

Рекомендуется проконсультироваться с законодательством перед тем, как использовать какие-либо опции "ответного удара".

Пассивные действия

Пассивные ответы IDS предоставляют информацию пользователям системы, предполагая, что человек сам выполнит дальнейшие действия на основе данной информации. Многие коммерческие IDS предполагают исключительно пассивные ответы.

Тревоги и оповещения

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

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

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

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

Использование SNMP Traps

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

Возможности отчетов и архивирования

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

Возможность хранения информации о сбоях

При обсуждении возможностей различных IDS важно рассмотреть способы хранения информации о сбоях и отказах. Возможность хранения информации о сбоях обеспечивает дополнительный способ защиты IDS от обхода ее атакующим. Это является обязательным требованием для средств управления, которые можно считать безопасными.

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

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

Дополнительные инструментальные средства

Существует несколько инструментальных средств, которые дополняют IDS и часто помечаются производителями как системы обнаружения проникновения, так как они выполняют аналогичные функции. Обсудим четыре из таких инструментальных средств: системы анализа уязвимостей, контроллеры целостности файлов, Honey Pots и Padded Cells, и опишем, какие они обеспечивают возможности для организации определения проникновения.

Системы анализа и оценки уязвимостей

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

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

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

Разница между системами анализа уязвимостей и системами обнаружения проникновения

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

Процесс анализа уязвимостей

Общий процесс оценки уязвимостей состоит в следующем:

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

Классификация инструментальных средств анализа уязвимостей

Существует два основных способа классификации систем анализа уязвимостей: первый – по расположению, из которого информация об оценке получена, и второй – по информации, которой располагает инструментальное средство анализа уязвимостей. При использовании первой схемы классификации для оценки уязвимостей системы классифицируются либо как network-based, либо как host-based. При использовании второй схемы системы классифицируются как credentialed или non-credentialed. Эти термины указывают, делался ли анализ с креденциалами или без креденциалов (таких, как IDs и пароли или другая идентификационная и аутентификационная информация, с помощью которой предоставляется доступ к внутренним системам). Мы будем использовать первую схему классификации для описания различных подходов к анализу уязвимостей.

Host-Based анализ уязвимостей

Системы host-based анализа уязвимостей определяют уязвимость, анализируя доступный источник системных данных, такой как содержимое файлов, параметры конфигурации и другая информация о статусе. Данная информация обычно доступна с использованием стандартных системных запросов и проверки системных атрибутов. Так как информация получена в предположении, что анализатор уязвимости имеет доступ к хосту, данный тип инструментальных средств анализа также иногда называется credential-based оценка уязвимости. Такая оценка определяется как пассивная.

Наилучшего результата достигают host-based оценки уязвимостей, которые имеют возможность выполнять привилегированные атаки. Это такие атаки, которые могут получить привилегии superuser или root на UNIX-системе или доступ administrator на Windows-системе.

Network-Based анализ уязвимостей

Системы network-based анализа уязвимостей получили распространение в последние несколько лет. Данные системы требуют установления удаленного соединения с целевой системой. Они могут реально проводить атаки на систему, понимать и записывать ответы на эти атаки или прощупывать различные цели для поиска слабых мест, которые следуют из их ответов. Такое проведение атак или прощупывание может происходить независимо от того, есть ли разрешение на доступ к целевой системе; следовательно, это можно считать non-credential анализом. Более того, так как network-based анализ уязвимостей выглядит как реальная атака или сканирование целевой системы, он также иногда обозначается как активный анализ.

Инструментальные средства network-based анализа уязвимостей иногда определяются как инструментальные средства обнаружения проникновения. Хотя, как уже обсуждалось ранее, это корректно в соответствии с некоторыми определениями обнаружения проникновения, все же программный продукт анализа уязвимостей не является законченным решением обнаружения проникновения для большинства окружений.

Существуют два метода, используемые при network-based оценки уязвимостей:

Преимущества и недостатки систем анализа уязвимостей

Преимущества систем анализа уязвимостей:

Недостатки и проблемы систем анализа уязвимостей:

Способы взаимодействия сканера уязвимостей и IDS

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

Проверка целостности файлов

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

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

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

Свободно распространяемый продукт Tripwire (www.tripwiresecurity.com), возможно, является лучшим примером инструментального средства проверки целостности файлов.

Лекция 5. Развертывание IDS

Рассматривается еще одна смежная IDS технология – создание Honey Pot и Padded Cell. Приводятся различные способы развертывания IDS разного типа. Исследуются возможные комбинации использования network-based и host-based IDS. Даются способы обработки выходной информации IDS. Перечисляются типы компьютерных атак, обычно определяемых IDS.

Системы Honey Pot и Padded Cell

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

Honey Pot являются системами-ловушками, которые разработаны для привлечения потенциального атакующего и отвлечения его от уязвимых систем. Honey Pot создаются для того, чтобы:

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

Padded Cell используют другой подход. Вместо того, чтобы пытаться привлечь атакующих заманчивыми данными, Padded Cell функционируют вместе с традиционной IDS. Когда IDS определяет атакующего, она перенаправляет его в специальный Padded Cell хост. После того как атакующие попадают в Padded Cell, они находятся внутри эмулированного окружения, где не могут причинить вред. Как и Honey Pot, данное эмулированное окружение заполняется представляющими интерес данными, разработанными для того, чтобы убедить атакующего, будто атака продолжается по его плану. Как и Honey Pot, Padded Cell являются хорошо оборудованными и имеют уникальные возможности для мониторинга действий атакующего. Разработчики IDS используют системы Padded Cell и Honey Pot, начиная с 1980 года. Важно проконсультироваться с законодательством, прежде чем принять решение об использовании тех или иных систем в конкретном функциональном окружении.

Преимущества систем Honey Pot и Padded Cell:

Недостатки систем Honey Pot и Padded Cell:

Выбор IDS

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

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

Выбор самой подходящей IDS

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

Определение окружения IDS

Во-первых, следует понимать, в каком окружении IDS должна функционировать. Это важно, поскольку если IDS не развернута с учетом информационных источников, которые доступны системе, она может не иметь возможности видеть все, что делается в сети или системе – как атаку, так и нормальную деятельность.

  1. Технические спецификации окружения систем

Во-первых, следует специфицировать технические характеристики окружения систем. Такая спецификация должна включать топологию сети с учетом количества и расположения хостов, ОС на каждом хосте, количества и типов сетевых устройств, таких как роутеры, мосты, коммутаторы, количества и типов граничных маршрутизаторов и dial-up соединений. Должно быть сделано описание всех серверов, включая типы, конфигурации, прикладное ПО и версии, выполняющиеся на каждом из них. Если работает система управления сетью, то нужно описать ее функционирование.

  1. Технические спецификации используемой системы безопасности

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

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

  1. Цели организации

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

  1. Возможность формализации окружения системы и принципы управления, используемые в организации

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

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

Цели и задачи использования IDS

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

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

  1. Защита от внешних угроз

Следует максимально конкретно определить возможные внешние угрозы.

  1. Защита от внутренних угроз

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

  1. Возможность определения необходимости обновления

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

  1. Возможность использования IDS для контроля поведения пользователя

Существуют системы, где может быть создана политика, целью которой является определение поведения пользователей, а не решение проблем информационной безопасности. Такая политика может включать ограничение возможности доступа к определенным web-сайтам, в зависимости от предоставляемого ими содержимого, или ограничение использования e-mail или других систем обмена сообщениями. Некоторые IDS предоставляют подобные возможности.

Существующая политика безопасности

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

  1. Структурированность

Следует определить цели политики безопасности в терминах стандартных целей безопасности (целостность, конфиденциальность и доступность), а также общих целей управления.

  1. Описание функций, выполняемых пользователями системы

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

  1. Реакция на нарушения политики

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

Организационные требования и ограничения

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

  1. Внешние по отношению к IDS требования

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

  1. Требования для публичного доступа к информации в системах

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

  1. Законодательные требования, относящиеся к безопасности и к расследованию инцидентов безопасности

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

Следует специфицировать все функции IDS, относящиеся к сбору и защите логов IDS, которые могут использоваться в качестве судебного доказательства.

  1. Требования внутреннего аудита

Следует рассмотреть, имеются ли какие-либо функции аудита, которые IDS может предоставлять или поддерживать.

  1. Требования аккредитации системы

Следует рассмотреть, какая аккредитация требуется для IDS и других систем.

Ограничения на ресурсы, существующие в организации

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

  1. Бюджет для приобретения и поддержки жизненного цикла аппаратуры, ПО и инфраструктуры IDS

Следует помнить, что приобретение ПО IDS не определяет полную стоимость владения; нужно также приобрести систему, на которой будет выполняться ПО, специализированные вспомогательные устройства для инсталлирования и конфигурирования системы. Также необходимо обеспечить определенные тренинги для персонала.

  1. Специалисты по эксплуатации IDS

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

  1. Полномочия для осуществления изменений на основе результатов, предоставленных IDS

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

Возможности IDS

IDS должна обеспечивать следующие возможности.

  1. Масштабируемость используемого программного продукта для конкретного окружения

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

  1. Протестированность программного продукта

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

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

Учет возможного роста организации

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

  1. Адаптируемость программного продукта к возрастающей квалификации пользователей

Следует проанализировать, может ли интерфейс IDS конфигурироваться для использования настраиваемых по мере необходимости различных shortcut-ключей, возможностей тревоги и т.п. Следует проанализировать также, насколько такие возможности документированы и поддерживаются.

  1. Адаптируемость программного продукта к возрастанию и изменению инфраструктуры организации

Это означает возможность масштабирования IDS при расширении и увеличении разнородности сети. Большинство производителей могут хорошо адаптировать свои продукты к возрастанию сетей. Следует также узнать о поддержке новых стандартов протоколов и типов платформ.

  1. Адаптируемость программного продукта к возрастанию и изменению угроз безопасности

Данный вопрос особенно актуален для текущего состояния угроз в Интернете, когда каждый месяц появляется по 30-40 новых атак.

Предоставляемая поддержка программного продукта

Подобно другим программным продуктам, IDS требуют постоянного сопровождения и поддержки.

  1. Поддержка инсталляции и конфигурирования

Многие производители предоставляют квалифицированную помощь при инсталляции и конфигурировании IDS; другие считают, что это могут делать собственные специалисты потребителя, и обеспечивают только поддержку по телефону или e-mail.

  1. Возможность непрерывной поддержки программного продукта

Существует ли подписка на обновления.

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

Как часто подписчики получают обновления.

При современных угрозах, когда ежемесячно публикуется 30-40 новых атак, это является важным фактором.

Как быстро после обнаружения новой атаки производитель поставит новую сигнатуру.

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

Включает ли подписка на обновление также и обновление ПО.

Большинство IDS являются программными продуктами и, следовательно, могут содержать ошибки и уязвимости. Таким образом, возможность частого обновления ПО также является весьма существенным фактором.

Как быстро выпускаются обновления ПО после того, как о проблеме было сообщено производителю.

Так как ошибки ПО в IDS могут позволить атакующему обойти всю защиту, особенно важно, чтобы проблемы фиксировались надежно и быстро.

Включены ли сервисы технической поддержки и сколько они стоят.

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

Какой способ контакта (e-mail, телефон, on-line chat, web-интерфейс) осуществляется для выполнения технической поддержки.

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

Какие имеются гарантии, связанные с IDS.

Как и в случае других продуктов ПО, IDS должны иметь определенные гарантии, связанные с их функционированием.

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

После того как IDS выбрана, инсталлирована и сконфигурирована, она должна обслуживаться персоналом предприятия. Для того чтобы эти люди могли оптимально использовать IDS, они должны сначала научиться ее использовать. Некоторые производители предоставляют программы обучения как часть пакета услуг.

  1. Дополнительные ресурсы, доступные для обучения

В случае, если производитель IDS не предоставляет обучение как часть пакета IDS, следует выделить определенный бюджет для обучения персонала.

Развертывание IDS

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

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

Стратегия развертывания IDS

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

Для защиты сети предприятия рекомендуется рассмотреть комбинацию network-based IDS и host-based IDS. Далее следует определить стадии развертывания, начиная с network-based IDS, так как они обычно являются более простыми для инсталлирования и сопровождения. После этого следует защитить критичные серверы с помощью host-based IDS. Используя инструментальные средства анализа уязвимостей, следует протестировать IDS и другие механизмы безопасности относительно правильного конфигурирования и функционирования.

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

Развертывание network-based IDS

Единственный вопрос, который следует тщательно продумать при развертывании network-based IDS, — это расположение системных сенсоров. Существует много вариантов расположения network-based IDS, каждый из которых имеет свои преимущества:

Возможные варианты расположения сенсоров network-based IDS


Рис. 5.1.  Возможные варианты расположения сенсоров network-based IDS

  1. Основная подсеть
  2. Подсеть с критичными ресурсами и дополнительными точками доступа
  3. DMZ-сеть
Позади внешнего firewall’а в DMZ-сети (расположение 1)

Преимущества:

Перед внешним firewall’ом (расположение 2)

Преимущества:

На основной магистральной сети (расположение 3)

Преимущества:

В критичных подсетях (расположение 4)

Преимущества:

Развертывание host-based IDS

После того как network-based IDS размещены и функционируют, для увеличения уровня защиты системы дополнительно может быть рассмотрено использование host-based IDS. Однако инсталлирование host-based IDS на каждый хост может потребовать существенных временных затрат. Поэтому рекомендуется, чтобы в первую очередь host-based IDS были инсталлированы на критичных серверах. Это может уменьшить общую стоимость развертывания и позволит основное внимание уделить реагированию на тревоги, касающиеся наиболее важных хостов. После того как host-based IDS начали функционировать в обычном режиме, организации с повышенными требованиями к безопасности могут обсудить возможность инсталлирования host-based IDS на другие хосты. В этом случае следует приобретать host-based системы, которые имеют централизованное управление и функции создания отчетов. Такие возможности могут существенно понизить сложность управления сообщениями о тревогах от большого числа хостов.

Далее следует рассмотреть возможность повышения квалификации администраторов. В большинстве случаев эффективность конкретной host-based IDS зависит от возможности администратора различать ложные и верные тревоги.

Также важно (так как часто администратор не сопровождает постоянно host-based IDS) установить график проверки результатов IDS. Если это не сделано, риск, что противник изменит что-либо в IDS в течение осуществления атаки, возрастает.

Стратегии оповещения о тревогах

Наконец, при развертывании IDS важной проблемой является определение того, какие именно возможности оповещения IDS о тревогах использовать в каждом конкретном случае. Большинство IDS поставляются с уже сконфигурированными возможностями оповещения о тревогах, которые допускают широкий диапазон опций, включая посылку сообщений на e-mail, пейджер, использование протоколов сетевого управления и даже автоматическое блокирование источника атаки.

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

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

Сильные стороны и ограниченность IDS

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

Сильные стороны IDS

IDS хорошо выполняют следующие функции:

Ограничения IDS

IDS имеют много ограничений. Наиболее существенные следующие:

IDS не могут выполнять следующие функции:

Обработка выходной информации IDS

Типичные выходные данные IDS

Почти все IDS имеют в качестве выходной информации строку сообщения о каждой обнаруженной атаке. Эта строка обычно содержит перечисленные ниже поля:

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

Данное описание обычно содержит следующую информацию:

Выполняемые IDS действия при обнаружении атаки

Возможно лучшим результатом, соответствующим успешной трактовке выходной информации IDS, должно быть сообщение, что атака "Be Prepared", т.е. полностью ликвидирована.

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

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

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

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

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

Типы атак

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

Конфиденциальность. Атака осуществляет нарушение конфиденциальности, если она позволяет атакующему получить доступ к данным без авторизации (явно или неявно).

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

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

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

Типы компьютерных атак, обычно определяемые IDS

Три типа компьютерных атак обычно определяются IDS: сканирование системы, denial of service (DoS) и проникновение в систему. Эти атаки могут быть осуществлены локально, с атакованной машины, или удаленно, используя сеть для доступа к цели. Оператор IDS должен понимать различие между этими типами атак, так как каждый тип требует различного множества ответов.

Атаки сканирования

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

Используя ответы, посылаемые целью, атакующий может много узнать о характеристиках и уязвимостях системы. Таким образом, атака сканирования является для атакующего средством идентификации цели. Эти атаки не выполняют проникновение или другую компрометацию систем. Различные названия инструментальных средств, используемых для выполнения таких действий, включают: сетевые mappers, порт mappers, сетевые сканеры, порт сканеры или сканеры уязвимостей. Атаки сканирования могут определять:

Сканеры уязвимостей являются специальным типом сканеров, которые проверяют наличие конкретных уязвимостей на хостах. Таким образом, атакующий может запустить сканер уязвимостей, и он выдаст список хостов (IP-адресов), которые являются уязвимыми для конкретной атаки.

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

Существуют законодательные оправдания для сканирования. Инструменты поиска в web могут сканировать Интернет для поиска новых web-страниц. Каждый может сканировать Интернет для поиска свободных музыкальных репозиториев или публично доступных многопользовательских игр. Главным является то, что, как правило, технология, которая позволяет обнаруживать публично доступные ресурсы, также позволяет анализировать систему для поиска слабых мест в безопасности. Лучшие IDS, которые могут определять сканирование, обычно имеют возможность делать различие между законным и враждебным сканированием. Сканирование подобно большинству общих атак, так как оно является предвестником любой серьезной попытки проникновения. Если сеть подсоединена к Интернету, это почти всегда означает, что она будет просканирована, если не сегодня, то, по крайней мере, в ближайшую неделю.

DoS-атаки

DoS-атаки пытаются замедлить или остановить системы или сервисы в целевой сети. Существует два типа DoS-атак: шквальная эксплуатация и наводнение (flooding). Важно понимать разницу между ними.

DoS-атаки шквальной эксплуатации

Атаки шквальной эксплуатации вызывают "шквал" в ПО целевой системы, чтобы вызвать невозможность обработки или исчерпание системных ресурсов. Например, результатом "ping of death" атаки является невозможность дальнейшей обработки. Данная атака включает отправку очень большого пакета ping некоторым Windows-системам. Целевая система может не обработать такой анормальный пакет, в результате чего произойдет крах системы. Что касается исчерпания ресурсов, то под ресурсами в данном случае понимается время ЦП, память, дисковое пространство, пространство в некотором буфере или пропускная способность сети. Во многих случаях достаточно установить последние версии ПО, чтобы предотвратить данный тип DoS-атаки.

Flooding DoS-атаки

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

Термин "распределенная DoS-атака" (DDoS) означает подмножество DoS-атак. DDoS-атаки являются простыми flooding DoS-атаками, когда атакующий использует несколько компьютеров для запуска атаки. Эти компьютеры обычно управляются компьютером атакующего и, таким образом, действуют как единая огромная атакующая система. Атакующий обычно не может нанести вред большому сайту электронной коммерции с помощью наводнения сетевыми пакетами с единственного хоста. Однако, если он получит управление над 20 000 хостами и взломает их таким образом, чтобы заставить их выполнять атаку под своим управлением, то он может получить достаточно средств для успешной атаки на самые большие системы.

Атаки проникновения

Атаки проникновения включают неавторизованное приобретение и/или изменение системных привилегий, ресурсов или данных. Будем воспринимать эти нарушения целостности и управляемости как противоположность DoS-атакам, которые нарушают доступность ресурсов, и атакам сканирования, которые не делают ничего незаконного. Атака проникновения может получить управление над системой, используя различные изъяны ПО. Наиболее общие изъяны и последствия для безопасности каждого из них перечислены ниже.

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

User to Root. Локальный пользователь на хосте получает полное управление над целевым хостом.

Remote to User. Атакующий по сети получает доступ к пользовательскому аккаунту на целевом хосте.

Remote to Root. Атакующий по сети получает полное управление на сетевом хосте.

Remote Disk Read. Атакующий по сети получает возможность читать файлы данных на целевом хосте без выполнения авторизации.

Remote Disk Write. Атакующий по сети получает возможность записывать в файлы данных на целевом хосте без выполнения авторизации.

Удаленные vs. локальные атаки

DoS-атаки и атаки проникновения имеют два варианта: локальный и удаленный.

Атака авторизованного пользователя

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

Атаки публичного доступа

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

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

Определение расположения атакующего на основе анализа выходной информации IDS

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

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

Если атакующий запустил одностороннюю атаку, подобную многим flooding DoS-атакам, когда ему не нужно видеть никаких ответных пакетов, то он может проставить в своих пакетах случайные IP-адреса. Атакующий действует аналогично тому, что происходит в реальном мире при посылке открытки с фальшивым обратным адресом, заполняя тем самым почтовый ящик, чтобы никто другой не мог отправить почту. В данном случае атакующий не может получать никаких ответов от жертвы.

Однако, если необходимо видеть ответы жертвы, то атакующий не может изменить IP-адрес источника.

В общем случае, атакующие должны использовать корректный IP-адрес, когда они запускают атаки проникновения, но не DoS-атаки.

Однако существует одно исключение, связанное с квалифицированными атакующими. Атакующий может послать пакеты, используя поддельный IP-адрес источника, но установить ловушку для ответа жертвы на поддельный адрес. Это можно сделать без доступа к компьютеру с поддельным адресом. Такая манипуляция с IP-адресацией называется "IP- Spoofing".

Чрезмерная отчетность об атаках

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

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

Соглашения по именованию атак

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

В настоящее время приложены определенные усилия по разработке общей номенклатуры компьютерных уязвимостей и атак. Наиболее популярным из них является Common Vulnerabilities and Exposures List (CVE), который поддерживается MITRE, получающим информацию от различных профессиональных сообществ по безопасности. Многие производители программных и аппаратных продуктов, связанных с безопасностью, делают их CVE-совместимыми. Список CVE может быть найден на сайте http://cve.mitre.org.

Уровни важности атак

Многие IDS связывают с определяемыми атаками уровень важности. Это делается, чтобы помочь оператору правильно определить воздействие атаки и тем самым выполнить соответствующие действия. Однако воздействие и важность атаки являются очень субъективными и не обязательно должны быть одними и теми же во всех случаях, а могут зависеть от топологии сети и окружения в каждом конкретном случае. Например, если атакующий запускает высокоэффективную UNIX-атаку против большой гетерогенной сети, воздействие атаки на сетевой сегмент, который в основном состоит из Windows-систем, может быть низким, тогда как воздействие атаки на всю сеть (и, таким образом, важность атаки) остается высоким. Следовательно, уровни важности, о которых говорится в отчетах IDS, являются полезной информацией для менеджеров безопасности, но должны рассматриваться в контексте конкретного системного окружения, в котором выполняется IDS.

Типы компьютерных уязвимостей

Многие IDS предоставляют описания атак, которые они определяют. Это описание часто включает типы уязвимостей, которые используют атаки. Данная информация является очень полезной после того, как атака произошла, потому что системный администратор может исследовать и скорректировать использованную уязвимость. NIST рекомендует использовать ICAT Metabase проект для исследования и фиксации уязвимостей в сетях организации. ICAT содержит тысячи примеров реальных компьютерных уязвимостей со ссылками на детальное описание. ICAT доступна по адресу http://icat.nist.gov.

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

Ошибка корректности входных данных

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

Переполнение буфера

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

Ошибка граничного условия

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

Ошибка управления доступом

При такой ошибке система является уязвимой, потому что механизм управления доступом не функционирует. Проблема заключается не в конфигурации механизма управления доступом, а в самом механизме.

Исключительное условие при обработке ошибки

При возникновении исключительного условия при обработке ошибки система также иногда может стать уязвимой.

Ошибка окружения

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

Ошибка конфигурирования

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

Race-условие

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

Будущие направления развития IDS

Хотя функция аудита системы, которая являлась первоначальной задачей IDS, стала формальной дисциплиной за последние пятьдесят лет, поле для исследований IDS все еще остается обширным, большинство исследований датировано не позднее 1980-х годов. Более того, широкое коммерческое использование IDS не начиналось до середины 1990-х.

Intrusion Detection и Vulnerability Assessment является быстро развивающейся областью исследований.

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

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

Более того – очень вероятно, что основные возможности IDS скоро станут ключевыми в сетевой инфраструктуре (такой как роутеры, мосты и коммутаторы) и в операционных системах. При этом, скорее всего, разработчики IDS сфокусируют свое внимание на решении проблем, связанных с масштабируемостью и управляемостью IDS.

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

Наконец, механизмы, связанные с управлением рисками в области сетевой безопасности, будут оказывать влияние на требования к IDS.

Лекция 6. Принципы безопасного развертывания сервисов DNS

Рассматриваются основное назначение сервисов DNS и свойства инфраструктуры DNS. Перечисляются компоненты DNS, такие, как зонный файл, name-сервер и resolver’ы. Вводятся различные типы DNS-транзакций: запрос / ответ DNS, зонная пересылка, динамические обновления, DNS NOTIFY. Исследуются возможные угрозы сервисам и компонентам DNS. Обсуждается понятие безопасности для сервисов и компонентов DNS.

Введение

Рассмотрим сервис DNS и принципы его безопасного развертывания, а именно следующее:

  1. Основные функции и свойства протокола DNS и инфраструктуры DNS. Также обсудим, что означает безопасность для сервисов DNS.
  2. Основные компоненты DNS, такие как зонный файл, содержащий DNS-данные, name-серверы и resolver’ы, которые предоставляют DNS-сервисы.
  3. Различные типы DNS-транзакций и типы информации, участвующие в этих транзакциях.
  4. Возможные угрозы различным информационным объектам DNS.
  5. Способы обеспечения безопасности для сервисов DNS.
  6. Обеспечение безопасности для DNS Query/Response транзакций.
  7. Способы минимизации информации, раскрываемой посредством сервисов DNS.
  8. Способы администрирования, обеспечивающие безопасность DNS.

Безопасность DNS

Рассмотрим общие принципы безопасного развертывания сервисов DNS. Начнем с анализа целей безопасности и согласованных подходов к защите всех компонентов DNS.

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

Спецификации механизмов безопасного развертывания сервисов DNS приводятся в следующих документах:

Сервисы DNS

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

С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется IP-адресом, который представляет собой набор из четырех чисел, разделенных точками (например, 123.67.43.245). Для доступа к ресурсам Интернета по доменным именам, понятным пользователям, а не по этим IP-адресам, пользователям нужна система, которая преобразовывает доменные имена в IP-адреса и обратно. Такое преобразование является первоочередной задачей сервисов, называемых Domain Name System (DNS).

Пользователи получают доступ к ресурсам Интернета (например, web-серверу) с помощью соответствующей клиентской программы (например, web-браузера), указывая доменное имя этого ресурса. Для соединения с web-сервером и получения соответствующей web-страницы браузеру необходим IP-адрес этого имени. Браузер вызывает функцию DNS для получения данной информации. Функция отображения доменных имен в IP-адреса, которую предоставляет DNS, называется name resolution (разрешение имен). Протокол, который используется для выполнения функции разрешения имен, называется DNS-протокол.

Функция DNS, описанная выше, включает следующие составные части. Во-первых, необходимо иметь репозиторий для хранения доменных имен и соответствующих им IP-адресов. Так как количество доменных имен весьма велико, то основными требованиями являются масштабируемость и эффективность. Это означает, что данный репозиторий должен быть распределенным. Доменные имена могут также нуждаться в репликации для защиты от разного рода сбоев. Также должно существовать ПО, которое управляет этим репозиторием и предоставляет функцию разрешения имен. Эти две функции (управление репозиторием доменных имен и предоставление сервиса разрешения имен) выполняются компонентой DNS, называемой name-сервер. Существует несколько категорий name-серверов, различаемых по типу обрабатываемых данных и выполняемым функциям. Для доступа к сервисам, предоставляемым name-сервером, от имени пользовательских программ, существует другой компонент DNS, называемый resolver. Существуют две основных категории resolver’ов – рекурсивный name-сервер и stub resolver, различающиеся по своим возможностям. Коммуникационный протокол, различные компоненты DNS, политики, которые определяют конфигурацию этих компонент, процедуры создания, хранения и использования доменных имен составляют инфраструктуру DNS.

Инфраструктура DNS

Инфраструктура DNS состоит из вычислительных и коммуникационных элементов, географически распределенных по всему миру. Для того, чтобы понять инфраструктуру DNS, необходимо, во-первых, проанализировать структуру доменных имен. Пространство доменных имен организовано в виде иерархической структуры. Самым верхним уровнем иерархии является root domain, который представим в виде точки ("."). Следующий уровень называется top-level domain (TLD) (домен верхнего уровня). Существует только один root domain, но много TLDs. Каждый TLD называется дочерним доменом от домена root. В данном контексте root домен является родительским доменом, потому что он на один уровень выше TLD. Каждый TLD, в свою очередь, может иметь много дочерних доменов. Дочерние домены для TLDs называются second-level или enterprise-level доменами (доменами второго уровня).

Символ, обозначающий root-домен, обычно опускается. Например, рассмотрим доменное имя marketing.example.ru. Самая правая часть данного доменного имени ( ".ru" ) является TLD. Следующая часть ( "example" ) есть домен второго или enterprise уровня. Самая левая часть ( "marketing" ) есть домен третьего уровня. Также возможно существование доменов четвертого, пятого и т.д. уровней. Каждая из частей в marketing.example.ru называется доменом, конкатенация всех этих частей от текущего уровня до TLD называется полностью определенным доменным именем (Fully Qualified Domain Name – FQDN). Однако часто FQDN называется просто доменным именем.

Существует только один root домен. Существуют более 250 TLDs, разделенных на следующие категории:

Имеется несколько миллионов доменов второго уровня.

В инфраструктуре DNS насчитывается большое количество name-серверов. Каждый name-сервер содержит информацию о части пространства доменных имен и связан с определенным уровнем. Существует 13 name-серверов, связанных с уровнем root; они называются root servers. Два из этих серверов расположены в частной корпорации VeriSign в США; остальные функционируют в добровольных организациях по всему миру. Организации, в которых функционируют name-серверы, связанные с TLD, называются registries. Обычно ссTLDs поддерживаются специально назначенными регистрационными органами в каждой стране, gTLDs поддерживаются глобальными регистрационными органами. Например, VeriSign в настоящее время управляет name-серверами для .org и .net TLDs, непрофицитная организация, называемая Public Internet Registry (PIR), управляет name-серверами для .org TLD; другая непрофицитная организация, называемая EDUCAUSE, управляет name-серверами для .edu TLD. Однако все эти регистрационные органы могут быть изменены. Name-серверы, связанные с доменами второго уровня и ниже, выполняются либо непосредственно в организациях, которые владеют этими доменами, либо у Интернет Сервис Провайдера (ISP) или провайдеров других сервисов.

Инфраструктура DNS функционирует посредством соглашения среди различных участников, включая организации, в которых функционируют root-серверы, registries, в которых функционируют TLDs, и т.п. Непрофицитная корпорация Internet Corporation for Assigned Names and Numbers (ICANN) действует в качестве технического координатора всех аспектов, касающихся DNS. Например, ICANN формулирует политики для управления root-серверами. ICANN также отвечает за создание новых TLDs.

Пользователь (как индивид, так и корпорация), желающий зарегистрировать доменное имя (которое может быть не выше второго уровня), должен обратиться к своему уполномоченному органу, называемому регистратором (registrar). Регистраторами являются компании, которые уполномочены выделять доменные имена в конкретном TLD конечным пользователям или организациям. Регистраторы существуют во всем мире. Когда регистратор получает запрос на регистрацию, он проверяет в соответствующем реестре, что имя свободно, и регистрирует его в данном реестре.

Владельцы доменных имен второго уровня часто создают дочерние домены, чтобы различные ресурсы, расположенные в их домене, могли быть доступны в Интернете. Например, собственник имени домена example.ru может создать поддомен unit для того, чтобы ресурсы, связанные с подразделением, могли быть доступны в Интернете. Аналогично, поддомены могут создавать свои поддомены (в данном контексте, домены третьего уровня) для доступа к своим ресурсам из Интернета. Очень часто в некоторой организации, которая является собственником домена второго уровня, определено много доменов третьего уровня, но в каждом из них существует всего несколько ресурсов, доступных из Интернета (web-серверов, прикладных серверов и т.п.). Следовательно, неэкономично связывать уникальный name-сервер с каждым из доменов третьего и более низкого уровня. Более того, с точки зрения администрирования, удобнее сгруппировать всю информацию, относящуюся к основному домену организации (например, домену второго уровня) и всем его поддоменам, в единый ресурс и управлять им как одним блоком.

Чтобы облегчить возможность такого группирования, в DNS определено понятие "зоны". Зоной может являться либо весь домен, либо домен с группой поддоменов. Зона является конфигурируемой сущностью внутри name-сервера, которая описывает все ресурсы Интернета, относящиеся к домену и выбранному множеству поддоменов. Таким образом, зоны — это административно созданные блоки пространства имен DNS, а домены — структурно созданные блоки. Как результат, термин зона обычно используется и для ссылки на домен, который управляется как отдельная административная единица (например, зона root, зона .ru). Будем использовать термин зона для ссылки на ресурсные записи, которые содержат информацию о доменных именах для одного или более доменов и управляются как единая административная сущность. Другими словами, зона есть конфигурируемый ресурс внутри развернутого name-сервера.

Имея общее представление об инфраструктуре DNS (name-серверах и resolver’ах), доменных именах, зонах, name-серверах различного уровня (например, root-сервера и TLD-сервера) и resolver’ах, функцию разрешения имени теперь можно определить более детально. Когда пользователь вводит URL ресурса (например, www.example.ru) в web-браузер, программа браузера соединяется с resolver’ом, тип которого называется stub resolver, который, в свою очередь, соединяется с локальным name-сервером (называемым рекурсивным name-сервером или resolving name-сервером). Рекурсивный name-сервер проверяет свой кэш, чтобы узнать, имеется ли там корректная информация (информация определяется как корректная на основе критерия, который будет описан далее) об IP-адресе для этого ресурса. Если такой информации нет, то рекурсивный name-сервер проверяет кэш, чтобы узнать, имеется ли информация, относящаяся к name серверу для зоны example.ru (так как считается, что эта зона содержит ресурс www.example.ru). Если IP-адрес name-сервера есть в кэше, следующий запрос resolver’а будет перенаправлен на данный name-сервер. Если IP-адреса name-сервера для example.ru нет в кэше, то resolver определяет, имеется ли у него информация о name-сервере для зоны, которая расположена на один уровень выше, чем example.ru (т.е. ru ).

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

Соединение с root-сервером возможно благодаря файлу, называемому root.hint, который есть в каждом name-сервере. Файл root.hint содержит IP-адреса нескольких root-серверов. Root-сервер, в свою очередь, содержит информацию о name-серверах в своих дочерних зонах (т.е. TLDs). TLD (например, .ru ) содержит информацию о name-серверах для своих дочерних зон (например, example.ru ). Информация name-сервера о name-серверах в своих дочерних зонах называется информацией делегирования. Информация делегирования является информацией, которая используется для перенаправления запросов разрешения имен для ресурса, расположенного ниже, чем данный, в иерархии доменных имен. Пусть запрос разрешения имени относится к ресурсу в домене третьего уровня (www.example.ru). Root сервер перенаправляет запрос name-серверу более низкого уровня. Ответ рекурсивному name-серверу, который включает посылку информации делегирования, называется referral. В данном случае referral предоставляет IP-адрес name-сервера для TLD-зоны, которая соответствует запросу (т.е. .ru зона, так как запрос выполняется для ресурса в example.ru ). Используя данный referral, рекурсивный name-сервер затем формулирует и посылает запрос к name-серверу зоны .ru. Данный сервер уже предоставит referral на example.ru name-сервер. Если www.example.ru ресурс существует в зоне example.ru, то запрос name-сервера для www.example.ru предоставит IP-адрес для ресурса www.example.ru Диаграмма процесса разрешения имени (без операций поиска в кэше) приведена на рис. 6.1.

Последовательность запросов и ответов при разрешения имен


Рис. 6.1.  Последовательность запросов и ответов при разрешения имен

Name-сервер выполняет следующие функции:

Name-сервер выполняет эти три функции, используя некоторую базу данных, которая называется зонным файлом. Класс информации, называемый информацией делегирования, содержит информацию name-сервера о дочерних зонах в родительской зоне и использует ее при выполнении функции предоставления referral’а. Функция отображения выполняется классом информации в файле зоны, называемом авторитетной информацией, и обеспечивается набором записей, которые перечислены в ресурсах для данной зоны вместе с их доменными именами и соответствующими IP-адресами. Так как ресурсы принадлежат данной зоне, предоставляемая информация считается авторитетной. Таким образом, файл зоны содержит две категории информации: авторитетную информацию (информацию обо всех ресурсах во всех доменах в зоне) и информацию делегирования (информацию о name-серверах в дочерних зонах). Строки в файле зоны, в которых указывается информация делегирования, называются точками делегирования. Уровень файла зоны есть уровень самого верхнего домена, для которого он содержит авторитетную информацию.

Компоненты DNS и понятие безопасности для них

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

Технология сетевого доступа (например, Ethernet-сеть, соединяющая stub resolver и локальный рекурсивный name-сервер) не рассматривается при описании DNS.

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

Основные механизмы безопасности для сервисов DNS

Основные механизмы безопасности для сервисов DNS описаны в документах IETF, специфицирующих DNSSEC и TSIG. Рассмотрим эти спецификации, конфигурационные опции и список необходимых действий для различных компонент DNS и систем, на которых они развернуты.

Данные DNS и ПО DNS

Двумя основными компонентами ПО DNS являются name-сервер и resolver. Основные функции name-сервера состоят в обслуживании базы данных (называемой зонным файлом), содержащей информацию о зоне, и в предоставлении ответов на запросы разрешения имени посредством авторитетных ответов или referral’ов. Основной функцией ПО resolver’а является запрос или серия запросов разрешения имени. Основными данными DNS является зонный файл; другим типом данных DNS является конфигурационный файл. Сначала обсудим структуру зонного файла, а затем функции различных типов name-серверов и resolver’ов. Обсуждение name-серверов и resolver’ов будет вестись в контексте уровня предприятия и может быть неприменимо к аналогичным сущностям уровней root и TLD.

Зонный файл

Зонный файл содержит информацию о различных ресурсах в данной зоне. Информация о каждом ресурсе представлена в записи, называемой Resource Record (RR). Так как зона может содержать несколько доменов и несколько типов ресурсов внутри каждого домена, формат каждой RR содержит поля для указания этой информации. В частности, ресурсная запись состоит из следующих основных полей:

Некоторые наиболее часто используемые типы ресурсов:

В RFC 1035 приведен полный формат допустимых RRType в DNS. Множество ресурсных записей с одним и тем же именем собственника, TTL, классом и RRType называется RRSet. Следовательно, логически зонный файл можно представить состоящим из нескольких RRSets.

Name-серверы

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

Авторитетные name-серверы

Существует два типа авторитетных name-серверов: master (или первичный) name-сервер и slave (или вторичный) name-сервер. Для обеспечения большей надежности от сбоев может существовать несколько slave name-серверов для каждого master-сервера. Master name-сервер содержит зонные файлы, которые создаются и редактируются вручную администратором зоны. Иногда master name-сервер допускает, чтобы зонный файл мог динамически изменяться авторизованными DNS-клиентами. Slave name-сервер также содержит авторитетную информацию для зоны, но его зонный файл является репликацией зонного файла связанного с ним master name-сервера. Репликация осуществляется с помощью транзакции, называемой зонной пересылкой, которая пересылает все ресурсные записи из зонного файла в master name-сервере на slave name-сервер. Так как запрос разрешения имени выполняется для конкретной ресурсной записи, зонная пересылка на самом деле рассматривается как категория запроса разрешения имен с кодом типа AXFR, который означает "все ресурсные записи для зоны, которая запрашивается". Всякий раз, когда содержимое зонного файла изменяется на master name-сервере, slave name-сервер уведомляется об изменении с помощью транзакции, называемой DNS NOTIFY. Когда slave name-сервер получает данное сообщение, он инициализирует запрос зонной пересылки к master name-серверу. Для обозначения данных типов name-серверов могут использоваться также термины первичный и вторичный name-сервера.

Кэширующие name-серверы

Кэширующий name-сервер обычно является локальным name-сервером, выполняющим функции разрешения имен для различных клиентов. Кэширующий name-сервер также является рекурсивным name-сервером. Функция разрешения имен выполняется кэширующим name-сервером в ответ на запросы от stub resolver’а. Процесс поиска, выполняемый при разрешении имен, означает либо поиск в своем собственном кэше, либо последовательность запросов к различным авторитетным серверам.

Конкретный name-сервер может быть сконфигурирован и как авторитетный, и как рекурсивный. При такой конфигурации один и тот же name-сервер предоставляет авторитетную информацию на запросы, относящиеся к своей зоне, и выполняет рекурсивные функции для запросов, относящихся к другим зонам. Для выполнения рекурсивной функции он должен поддерживать рекурсивные запросы. Любой сервер, который поддерживает рекурсивные запросы, является более уязвимым для атак, чем сервер, который такие запросы не поддерживает. Одним из результатов атак может быть компрометация авторитетной информации. Следовательно, с точки зрения безопасности, не считается оптимальной практикой конфигурирование одного и того же name-сервера для выполнения как авторитетных, так и рекурсивных функций.

Resolver’ы

Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.

Транзакции DNS

Существуют следующие типы DNS-транзакций:

Опишем каждый из этих типов.

Запрос / ответ DNS

Это наиболее распространенная транзакция в DNS. Запрос DNS исходит от resolver’а; получателем является авторитетный или кэширующий name-сервер. Наиболее распространенным запросом является поиск ресурсной записи по имени владельца или типу. Ответ может состоять из единственной ресурсной записи, множества ресурсных записей или сообщения о соответствующей ошибке.

Существует два типа запросов: нерекурсивный и рекурсивный. DNS-resolver’ы, которые обычно посылают нерекурсивные запросы, как правило, предоставляют более стабильные ответы, потому что они могут переходить по referral’ам для получения окончательного ответа на запрос. Если они также имеют кэш DNS, они могут обладать достаточно полной информацией о пространстве name-серверов в DNS, полученной из ответов на предыдущие запросы. Это может быть использовано для уменьшения времени ответа на последующие запросы. Рекурсивные запросы обычно посылаются от stub resolver’ов, которые не имеют возможности выполнять сложные операции DNS. Вместо этого они полагаются на вышележащий сервер DNS (обычно name-сервер с кэшем, который посылает нерекурсивные запросы от имени нескольких stub resolver’ов) для выполнения запроса и возврата окончательного ответа.

Запросы DNS посылаются в виде одного UDP-пакета. Ответ обычно также является одним UDP-пакетом, но данные могут быть усечены – в этом случае выполняется повторный запрос с использованием ТСР. UDP используется потому, что он требует меньше вычислительных ресурсов и является более быстрым, чем ТСР, который требует процедуры установления соединения.

Запросы DNS посылаются в открытом виде, но при этом хотелось бы, чтобы полученный ответ являлся корректным и пришел от аутентичного источника. Как результат, для активного атакующего существует возможность перехватить (и изменить) или сфабриковать ответы обратно к клиенту. Далее более детально проанализируем угрозы для транзакций запрос / ответ DNS и предложим соответствующие решения.

Зонная пересылка

Зонная пересылка является способом, которым вторичный (slave) сервер обновляет все содержимое своего зонного файла от первичного (master) сервера. Этот процесс дает возможность вторичному name-серверу поддерживать свой зонный файл в синхронном состоянии с первичным name-сервером. Транзакция зонной пересылки начинается в виде запроса от вторичного name-сервера к первичному name-серверу. Запрос зонной пересылки – в противоположность запросу DNS – запрашивает все ресурсные записи из зоны вместо конкретных ресурсных записей для данного владельца или типа. Этот запрос начинается с вторичного name-сервера либо в ответ на сообщение DNS NOTIFY, либо основываясь на значении элемента данных Refresh в поле RData в Start of Authority (SOA) ресурсной записи.

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

Динамические обновления

Если происходит добавление, удаление или перемещение сетевых ресурсов (например, серверов баз данных, web-серверов, почтовых серверов или name-серверов), соответствующие изменения необходимо делать в зонном файле, содержащим информацию о доменах, в которых размещены эти ресурсы. На ранних стадиях развития DNS администратор зоны делал такие изменения вручную. Когда такие изменения становятся большими и частыми, ручное изменение затрудняется, поэтому было введено понятие динамического обновления. Независимо от объема и частоты обновлений, существуют некоторые приложения, которые требуют немедленных автоматических изменений зонного файла с помощью прикладных программ. Примерами этого являются серверы DHCP.

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

В некоторых случаях DNS-сервер может использоваться в качестве репозитория сертификатов открытого ключа. При этом СА получает открытый ключ от пользователя, подписывает его своим закрытым ключом для создания сертификата и хранит данный сертификат в ресурсной записи с типом CERT (CERT RR) в зонном файле.

В RFC 2136 описан механизм динамического изменения, который затем был реализован в BIND 8-й версии и поддерживается во всех последующих версиях.

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

Набор операций для динамического изменения определен следующим образом:

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

DNS NOTIFY

Всякий раз, когда выполняются изменения в зонном файле первичного (master) DNS-сервера, вторичные (slave) DNS-серверы, которые содержат идентичные данные, должны быть уведомлены об изменениях. Такое уведомление выполняется посредством сообщения DNS NOTIFY, которое указывает, что вторичному DNS-серверу следует начать зонную пересылку. Сообщение DNS NOTIFY является более быстрым и эффективным способом поддержки синхронизации вторичных серверов с первичным сервером, чем альтернативный подход, при котором вторичные серверы запрашивают первичный сервер об изменениях с помощью значения времени в SOA Refresh.

Посылка сообщения DNS NOTIFY, называемая операцией notify, является способом синхронизации по умолчанию в BIND 9.x. Возникает вопрос: как name-сервер узнает, каким серверам сообщение DNS NOTIFY должно быть послано? В BIND 9.x уведомление посылается серверам, которые определены в NS ресурсных записях для зоны. Если существуют дополнительные серверы, которым администратор зоны хочет посылать сообщение DNS NOTIFY (так называемые невидимые slave-серверы), администратор DNS может добавить IP-адреса этих серверов в конфигурационный файл BIND. Администратор может также с помощью конфигурационных опций не разрешать серверу посылать сообщения NOTIFY о некоторых зонах, обслуживаемых данным name-сервером.

После того как вторичный сервер получил сообщение DNS NOTIFY, он посылает запрос зонной пересылки к первичному серверу, независимо от того, как давно в последний раз зонная пересылка осуществлялась. Данная процедура позволяет распространять изменение зоны всем вторичным name-серверам более быстро.

Так как сообщение DNS NOTIFY запускает зонную пересылку, ложные сообщения DNS NOTIFY могут привести к ненужным зонным пересылкам и, следовательно, потенциальным DoS-атакам.

Безопасность окружения DNS

Окружение, в котором выполняются сервисы DNS, состоит из следующих элементов:

Рассмотрим угрозы и возможные подходы к защите для окружения DNS.

Угрозы и обеспечение защиты платформы хоста

Угрозы для платформы, на которой выполняется ПО DNS, не отличаются от угроз, с которыми сталкивается любой хост в Интернете. Рассмотрим с точки зрения сервисов DNS эти общие угрозы и их воздействие на DNS:

Обеспечение защиты и/или уменьшению угроз для платформы хоста DNS состоит в следующем:

Угрозы ПО DNS

Угрозы для самого ПО DNS могут серьезно повлиять на безопасность. Большинство общих проблем, связанных с ПО, следующие:

Наилучшими подходами к обеспечению защиты ПО DNS являются следующие:

Угрозы для данных DNS

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

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

Подходы, обеспечивающие защиту от этих угроз, будут обсуждаться далее.

Лекция 7. Транзакции DNS

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

Угрозы для транзакций DNS

Угрозы транзакциям DNS зависят от типа транзакции. Запросы и ответы разрешения имен ( DNS Query/Response ) между DNS-клиентами (stub resolver или рекурсивным name-серверы) и DNS-серверами (кэширующий и авторитетный name-сервер) могут проходить через любые узлы в Интернете; следовательно, угроз для этих транзакций намного больше, чем для транзакций зонной пересылки, динамического обновления или DNS NOTIFY. Как правило, хосты, участвующие в транзакциях зонной пересылки, динамических обновлениях и DNS NOTIFY, находятся внутри одного административного домена. Единственным исключением являются первичный или вторичный name-серверы организации, которые часто расположены у Интернет-провайдера или в других организациях. При этом обычно предполагается наличие заранее существующего отношения доверия между первичным и вторичным name-серверами. Тем не менее возможны случаи, когда потребуется установить тот или иной способ взаимной аутентификации при зонных пересылках DNS.

Угрозы DNS-запросам и ответам и способы обеспечения защиты

Обычные запросы и ответы сервиса разрешения имен содержат неподписанные и незашифрованные UDP-пакеты. Возможные угрозы транзакциям DNS Query/Response описаны в RFC 3833 и могут быть классифицированы следующим образом:

Поддельный или выдуманный ответ

Поддельный или выдуманный ответ – это ответ, который отличается от того, который посылает законный авторитетный name-сервер. Поддельный ответ может быть получен от:

Поддельный ответ может быть создан в результате:

Последствия для систем, которым требуются сервисы name-сервера, имеющего испорченный кэш или скомпрометированный зонный файл:

Удаление некоторых ресурсных записей

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

Защищенный подход для DNS Query/Response – DNSSEC

Ликвидация угрозы, связанной с DNS Query/Response (т.е. подделанного ответа), состоит в обеспечении целостности данных DNS, возвращаемых в ответе. Следовательно, целью безопасности является проверка целостности каждого полученного ответа. Составной частью проверки целостности является гарантирование того, что данные получены из нужного источника. Установление доверия к источнику называется аутентификацией источника. Итак, целями безопасности для транзакций DNS Query/Response являются аутентификация источника и проверка целостности данных.

Эти сервисы могут быть предоставлены для установления доверия к источнику с помощью проверки подписи данных, посланных источником. Описание использования механизма цифровой подписи в контексте инфраструктуры DNS называется стандартом DNSSEC. Преследуемые цели, дополнительные ресурсные записи и содержание сообщений DNS специфицированы в RFC 4033, 4034 и 4035. В DNSSEC доверие к открытому ключу источника, который используется для проверки подписи, устанавливается не с помощью третьей стороны или цепочки третьих сторон (как в инфраструктуре открытого ключа PKI), а наличием доверенного name-сервера (такого как root name-сервер) и установлением цепочки доверия вниз к текущему источнику ответа с помощью проверок подписи, созданной в родительском домене для открытого ключа потомка. Открытый ключ доверенных name-серверов называется trust anchor.

После аутентификации источника DNSSEC выполняет аутентификацию ответа. Для этого требуется, чтобы ответы состояли не только из запрошенных ресурсных записей, но также и из аутентификатора, связанного с ними. В DNSSEC таким аутентификатором является цифровая подпись для множества ресурсных записей. Эта цифровая подпись хранится в специальном типе ресурсной записи, называемом RRSIG. Клиент DNS, используя доверенный открытый ключ (доверие к которому уже установлено), проверяет цифровую подпись для определения действительности ответа.

Для гарантии того, что ресурсные записи, указанные в запросе, на самом деле отсутствуют в зонном файле и не были удалены при передаче, механизм DNSSEC определяет способ аутентификации несуществующей ресурсной записи. Создается специальная ресурсная запись, называемая NSEC RR, в которой перечислены типы ресурсных записей, связанные с конкретным именем, а также следующее имя в зонном файле. Данная специальная ресурсная запись посылается вместе с подписью для нее к рекурсивному name-серверу. Проверяя данную подпись, поддерживающий DNSSEC рекурсивный name-сервер может определить, какие существуют авторитетные имена в зоне и какие существуют авторитетные типы ресурсных записей для этих имен.

Для защиты от атак некорректного применения правил расширения для wildcard в ресурсных записях механизм DNSSEC предоставляет значения для сравнения действительной ресурсной записи в wildcard с NSEC -ресурсной записью, и тем самым проверяет, что name-сервер корректно применил в созданном ответе правила расширения wildcard.

DNSSEC гарантирует целостность ответов разрешения имен DNS-клиентам, предоставляя клиентам возможность выполнить проверку подписи. Однако во многих случаях эти DNS-клиенты являются stub resolver’ами, в которых не реализован DNSSEC. Если проверка подписи выполняется рекурсивным name-сервером, который предоставляет сервис разрешения имен для своих клиентов, то end-to-end целостность данных ответа может быть гарантирована только защитой коммуникационного канала между рекурсивным name-сервером и stub resolver’ом.

Данные DNS считаются публичными, следовательно, конфиденциальность не является целью безопасности DNSSEC. DNSSEC не разрабатывался непосредственно для защиты от DoS-атак, хотя он делает это косвенно, обеспечивая целостность сообщения и аутентификацию источника.

Угрозы зонной пересылке и способы обеспечения защиты

Зонные пересылки выполняют репликацию зонных файлов на несколько серверов для защиты от сбоев DNS-сервиса. Первая угроза, DoS, является общей для любой сетевой транзакции. Вторая угроза основана на использовании знания, которое получено из информации, указанной в зонных пересылках.

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

Был разработан альтернативный механизм, называемый transaction signature ( TSIG ) , при использовании которого взаимная аутентификация серверов основана на разделяемом секретном ключе. Так как количество серверов, включенных в зонную пересылку, ограничено (обычно это name-серверы в одном и том же административном домене), двухсторонняя модель доверия, основанная на разделяемом секретном ключе, является адекватной для большинства случаев, — исключением могут быть только очень большие организации. TSIG описывает, как разделяемый секретный ключ используется не только для взаимной аутентификации, но и для аутентификации запросов и ответов зонных пересылок. Следовательно, это обеспечивает защиту от подделки сообщений запросов зонной пересылке (угроза Т13). Защита самих данных DNS в сообщении зонной пересылке также может быть обеспечена с помощью проверки подписи для ресурсных записей зоны, созданной name-сервером. Эти подписи, однако, не охватывают всю информацию в зонном файле (например, информацию делегирования). Более того, они позволяют проверить только отдельные множества ресурсных записей, а не все сообщение запроса зонной пересылке.

Угрозы для динамических обновлений и способы обеспечения защиты

Динамические обновления означают, что клиенты могут делать изменения в данных зоны авторитетного name-сервера в реальном режиме времени. Клиентами, которые обычно выполняют динамические обновления, являются СА-серверы, DHCP-серверы или Интернет Multicast Address серверы. Рассмотрим некоторые основные угрозы, основанные на том факте, что динамические обновления означают модификацию данных, передаваемых по сети.

Угрозы Т14 и Т15 могут быть ликвидированы аутентификацией участников и обеспечением способов определения подделанных сообщений. Так как данные цели безопасности в случае зонной пересылки могут быть решены TSIG-механизмом, тот же самый TSIG-механизм используется для защиты динамических обновлений. TSIG также обеспечивает способ защиты от replay-атак (угроза Т16) включением поля с отметкой времени в запрос динамического обновления таким образом, чтобы отметка времени также была аутентифицирована. Данная отметка времени дает возможность серверу определить своевременность запроса динамического обновления, используя ограничения времени, указанные в конфигурации.

Угрозы DNS NOTIFY и способы обеспечения защиты

DNS NOTIFY является сообщением, посылаемым первичным name-сервером вторичному, которое содержит информацию, что зонный файл изменился и что вторичному name-серверу следует выполнить зонные пересылки для поддержания своих зонных файлов в синхронном состоянии. Так как сообщение NOTIFY является сигнальным, то существует минимальный риск безопасности, связанный с данным сообщением. Считается, что основной риск состоит в следующем:

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

Выводы

Просуммируем транзакции DNS и связанные с ними угрозы, цели безопасности и механизмы безопасности, обеспечивающие защиту от этих угроз.

Транзакция DNSУгрозыЦели безопасностиМеханизмы безопасности
DNS Query/Response

(a) Изменение или вставка ложного ответа

(b) Удаление ресурсных записей в ответах

(c) Некорректные правила расширения wildcard

(a) Аутентификация исходных данных

(b) Проверка целостности данных

DNSSEC
Зонная пересылка

(a) DoS-атака

(b) Изменение сообщений

(a) Взаимная аутентификация участников

(b) Проверка целостности данных

TSIG
Динамическое обновление

(a) Неавторизованные модификации

(b) Изменение сообщений

(c) Replay-атака

(a) Взаимная аутентификация участников

(b) Проверка целостности данных

(c) Подписанные отметки времени

TSIG
DNS NOTIFY(a) Ложные уведомления(a) Предотвращение DoS-атак, возникающих из-за возрастания нагрузкиКонфигурационные опции

Создание безопасного окружения для сервисов DNS

Создание безопасной конфигурации для окружения DNS-хостинга должно обеспечивать следующее:

Рассмотрим рекомендации для каждого перечисленного выше пункта.

Безопасность платформы

На платформе, на которой выполняется ПО name-сервера, должна быть установлена ОС, удовлетворяющая требованиям безопасности. Большинство инсталляций DNS осуществляется либо на ОС Unix, либо на ОС Windows. В любом случае необходимо гарантировать следующее:

Безопасность ПО DNS

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

Использование самой последней версии ПО name-сервера

Каждая последующая версия ПО name-сервера, (особенно это касается BIND), обычно лишена уязвимостей, найденных в более ранних версиях. Если установлены старые версии, то эти уязвимости могут использоваться атакующим, чтобы осуществить атаку. Таким образом, хорошей практикой считается выполнение самой последней версии BIND, потому что теоретически она самая безопасная. Но даже если используется ПО самой последней версии, небезопасно выполнять его в режиме "по умолчанию". Администратор должен свободно владеть всеми установками безопасности для этой последней версии.

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

Рекомендации:

  1. При инсталляции версии ПО name-сервера администратор должен сделать необходимые изменения в конфигурационных параметрах, чтобы использовать преимущества новых возможностей, связанных с безопасностью.
  2. Выполнить следующие действия:

Выполнение ПО name-сервера с ограниченными привилегиями

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

Ограничение доступа к другим директориям может быть выполнено с помощью команды chroot в Unix. Такой подход называется выполнением name-сервера в jail (тюрьме). Должна быть выполнена следующая команда:

chroot –u named –g other –t /var/named

где:

-u указывает userID, от имени которого name-сервер будет выполняться после старта. Аккаунт данного пользователя должен быть создан до выполнения команды chroot.

-g указывает groupID, которой userID должен принадлежать. Если –g не указано, name-сервер выполняется от имени основной группы для userID.

-t указывает директорию, к которой name-сервер будет иметь доступ.

Изоляция ПО name-сервера

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

Выделенный экземпляр name-сервера для каждой функции

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

Авторитетный name-сервер только обеспечивает разрешение имен для зон, для которых он имеет авторитетную информацию. Следовательно, политика безопасности не должна допускать рекурсию для данного типа name-сервера. Запрещение рекурсии означает невозможность посылки запросов от имени других name-серверов и создания кэша из полученных ответов. В BIND рекурсия запрещается использованием утверждения options в конфигурационном файле:

options {
  recursion no;
};

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

Удаление ПО name-сервера с не предназначенных для этого хостов

ПО DNS не должно выполняться или присутствовать на хостах, которые не предназначены для функционирования на них name-серверов. Вероятность такого присутствия существует, потому что ПО DNS BIND во многих версиях Unix (включая версии Solaris и Linux) инсталлировано по умолчанию. Следовательно, необходимо проверить наличие инсталляций BIND на рабочих станциях и серверах и удалить его с тех хостов, которые не предназначены для функционирования в качестве name-серверов.

Сетевое и географическое расположение авторитетных name-серверов

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

Рекомендация:

Авторитетные name-серверы предприятия должны быть как географически распределенными, так и распределенными в смысле сетевой топологии. Сетевая распределенность гарантирует, что все серверы не будут расположены за одним и тем же роутером или коммутатором в одной подсети. Географическая распределенность гарантирует, что не все name-серверы будут находиться в одном и том же физическом месте и в любом случае будет доступен по крайней мере один авторитетный name-сервер.

Использование расчлененных зонных файлов

Авторитетные name-серверы организации получают запросы как от внешних, так и от внутренних клиентов. Во многих случаях внешние клиенты должны получать ресурсные записи, которые относятся только к публичным сервисам, таким, как web-сервер, почтовый сервер и т.п. Внутренние клиенты должны получать ресурсные записи, которые относятся как к публичным сервисам, так и к внутренним хостам. Следовательно, зонная информация, которая содержит эти ресурсные записи, может быть разделена на два представления, каждое из которых заключает в себе информацию, предназначенную для определенного типа клиентов: один для внешних клиентов, другой – для внутренних. Такой способ реализации зонного файла называется split DNS.

Рекомендация:

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

Для конфигурирования split DNS в BIND следует использовать специальное утверждение в конфигурационном файле BIND. Например, для конфигурирования авторитетного view в зоне sales.mycom.ru для внутренних хостов следует использовать утверждение

view "insider" {
  match-clients { internal_hosts; };
  recursion yes;
  zone sales.mycom.ru {
    type master;
    file "sales_internal.db";
  };
};

В данном утверждении указывается, что файл sales_internal.db содержит авторитетную информацию для зоны sales.mycom.ru, и вводится ограничение, что данная информация может быть запрошена со списка адресов, перечисленных в internal_hosts. Как задать данный список, будет объяснено ниже. Чтобы сконфигурировать view в некоторой зоне только для обслуживания запросов от внешних хостов, используется следующее утверждение в конфигурационном файле:

view "outsider" {
  match-clients { any };
  match-destination { public_hosts; };
  recursion no;
  zone sales.mycom.ru {
    type master;
    file "sales.external.db";
  };
};

Данное утверждение очень похоже на предыдущее, за исключением того, что файл с view зоны есть sales.external.db и список клиентов указан как any, — это означает, что запросы могут быть как извне, так и изнутри сети. Вместе эти утверждения позволяют внутренним клиентам видеть как внутренние, так и внешние хосты, а внешние хосты, расположенные вне данной сети, могут видеть только информацию DNS, содержащуюся во внешнем view зоны, где адрес получателя соответствует адресам, перечисленным в public_host.

Использования отдельных name-серверов для различных типов клиентов

Вместо того чтобы иметь одно и то же множество авторитетных name-серверов, обслуживающих различные типы клиентов, можно развернуть два различных множества авторитетных name-серверов. Одно множество, называемое external name-серверы, может быть расположено внутри DMZ; это должны быть только те name-серверы, которые доступны внешним клиентам и которые содержат ресурсные записи, относящимся к хостам с публично доступными сервисами (web-серверы, которые обрабатывают внешние web-страницы или предоставляют В2С-сервисы, почтовые серверы и т.п.). Другое множество, называемое internal name-серверы, расположено за firewall’ом и должно быть сконфигурировано таким образом, чтобы эти серверы не были доступны извне и, следовательно, предоставляли сервисы разрешения имен исключительно для внутренних клиентов. Целью обеих архитектур (т.е. создания двух различных множеств name-серверов и split DNS) является предотвращение раскрытия IP-адресов внутренних хостов.

Управление содержимым зонного файла

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

Безопасность транзакций DNS

Ранее были перечислены угрозы, цели безопасности и способы обеспечения защиты для различных транзакций DNS. Сейчас рассмотрим шаги, необходимые для реализации этих способов защиты. Перечислим типы способов обеспечения защиты:

Ограничение участников транзакций на основе IP-адреса

Некоторые реализации name-сервера, такие как BIND 9.x, предоставляют утверждения для управления доступом, с помощью которых можно указать хосты, которые могут участвовать в конкретной DNS-транзакции. Хосты могут быть указаны по их IP-адресам или указанием их IP-подсети (называемой IP-префиксом ) в данных утверждениях.

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

Синтаксис утверждения управления доступомТранзакция DNS
allow-query {address_match_list }DNS Query/Response
allow-recursion {address_match_list }Рекурсивный запрос
allow-transfer {address_match_list }Зонная пересылка
allow-update {address_match_list }Динамическое обновление
allow-update-forwarding {address_match_list }Динамическое обновление
allow-notify (address_match_list }DNS NOTIFY
blackhole {address_match_list }Хосты, попавшие в черный список

Цель каждого из этих утверждений управления доступом состоит в следующем:

Перечисленные утверждения управления доступом являются в действительности подутверждениями, которые могут использоваться в контексте утверждений options и zone в конфигурационном файле named.conf в BIND 9.x. Когда они используются внутри утверждения zone, они определяют ограничения управления доступом для соответствующей транзакции для указанной зоны. Когда они используются как часть утверждения options, они определяют ограничения управления доступом для соответствующей транзакции для всего name-сервера, который может обслуживать несколько зон.

Ограничение участников транзакции DNS Query/Response

Рассмотрим пример использования подутверждения allow-query для указания ограничений для транзакции Query / Response, определяя допустимые IP-адреса / подсети в запросах DNS) как на уровне сервера, так и на уровне зоны (для зоны example.ru ):

options {
  allow-query {254.10.20.10; 239.10.30.0/24; };
};
zone "example.ru." {
  type master;
  file "zonedb.example.ru";
  allow-query {192.249.249.1; 192.249.249.4; };
};

Указывая список IP-адресов или IP-префиксов внутри утверждений options или zone, можно внести путаницу в конфигурационный файл. Более того, список IP-адресов и IP-префиксов может быть одним и тем же для многих утверждений управления доступом внутри name-сервера, и ошибка может возникнуть, если сделано какое-то одно добавление или удаление в данный список. Чтобы избежать таких проблем, в BIND существует способ создания поименованных списков адресов, которые называются access control lists (ACLs). Эти ACLs могут использоваться в тех местах, где допустимо использование списка IP-адресов или IP-префиксов (в качестве аргумента списка соответствующих адресов) в утверждениях управления доступом.

ACLs создаются с использованием утверждения acl в BIND 9.х. Общий синтаксис утверждения acl следующий:

acl acl-list-name {
  address_match_list
};

acl-list-name есть определенная пользователем строка (например, "internal_hosts"). Address_match_list может быть списком IP-адресов, префиксами IP-адресов (обозначающих подсети) или криптографическими ключами. Пример утверждения acl, который использует IP-адрес и подсеть в address_match_list, приведен ниже. В примере 254.10.20.10 обозначает IP-адрес хоста, IP-префикс 239.10.30.0/24 обозначает подсеть класса С.

acl "internal_hosts" {
  254.10.20.10;
  239.10.30.0/24;
};

Можно использовать ACL internal_hosts в тех местах, где используется список IP-адресов или IP-префиксов в утверждениях options и zone следующим образом:

options {
  allow-query { internal_hosts; };
};
zone "example.ru." {
  type master;
  file "zonedb.example.ru";
  allow-query { internal_hosts; };
};

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

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

Рекомендация:

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

Дополнительно к IP-адресам, IP-префиксам или ACL, параметр списка соответствующих адресов в утверждениях управления доступом может принимать следующие специальные значения:

Приведем несколько примеров команд для создания ACLs и использования ACLs в утверждениях options и zone:

acl "local_hosts" {
  254.10.20.10;
  239.10.30.0/24;
};
acl "fake-net" {
  0.0.0.0/8;
  1.0.0.0/8;
};
options {
  allow-query { any; };
  blackhole { fake-net; };
};
zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-query {local_hosts; };
};

Во фрагменте named.conf, приведенном выше, определены два ACLs, local_hosts и fake_net. На уровне сервера разрешены DNS-запросы с любого хоста. Никакие транзакции не разрешены с хостов, включенных в fake-net. Запросы для зоны example.ru могут быть инициированы только хостами, включенными в ACL local_hosts, потому что любое ограничение, указанное в утверждении zone, перекрывает ограничение, указанное в утверждении options.

Ограничение рекурсивных запросов (специальный случай DNS Query/Response)

Авторитетный name-сервер обеспечивает сервис разрешения имен для клиента, исходя из своих собственных данных. Следовательно, конфигурирование авторитетного name-сервера должно быть сделано таким образом, чтобы он мог принимать запросы от любых хостов. Обеспечение безопасности авторитетного name-сервера состоит в выключении возможности рекурсивного запроса, чтобы этот сервер не испортил свой кэш, запрашивая другие (возможно, скомпрометированные) name-серверы. Локальный рекурсивный name-сервер может быть сконфигурирован таким образом, чтобы принимать запросы только от внутренних хостов, что защитит его от DoS-атак, а также от порчи кэша. Однако возможны ситуации, когда экономически нежелательно иметь выделенные серверы для авторитетного сервиса и сервиса разрешения имен, и рекурсивный name-сервер должен выполняться как авторитетный сервер для одной или более зон. В такой ситуации возможны следующие стратегии с использованием BIND 9.х name-сервера:

Ограничение на уровне сервера с перекрытием для авторитетных зон

В этом случае определяется допустимое множество внутренних клиентов, которые могут передавать запросы к name-серверу. Для этого соответствующее acl утверждение таково:

acl "internal_hosts" { 192.158.43.3, 192.158.43.6, 192.158.44.56; };

Опцией на уровне сервера следует указать ограничение, чтобы запросы могли исходить только от данных клиентов:

options {
  allow_query { internal_hosts; };
};

Опция может быть перекрыта указанием зон, для которых данный name-сервер является авторитарным (тем самым разрешая запросы, касающиеся ресурсов в данной зоне от всех клиентов):

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow_query { any; };
};

Ограничение всех рекурсивных запросов конкретным множеством IP-адресов

Ограничение на уровне сервера:

options {
  allow_recursion { internal_hosts; };
};

Ограничение рекурсии с помощью views

Цель создания views состоит в логической комбинации клиентов (на основе IP-адресов) и зон, для которых будут поддерживаться рекурсивные запросы и для которых они не будут поддерживаться. В следующем примере view recursion_view дает возможность определить область IP-адресов и зон, которым разрешено передавать рекурсивные запросы; no_recursion_view означает запрещение рекурсии.

view recursion_view {
  match-clients ( internal_hosts; };
  recursion yes;
};
view no_recursion_view {
  match-client { any; };
  recursion no;
};
Ограничение участников транзакции зонной пересылки

Авторитетные name-серверы (особенно первичные) должны быть сконфигурированы с утверждением управления доступом allow-transfer, содержащим список хостов, с которых запросы зонной пересылки могут приниматься. Это ограничивает DoS-атаки и использование возможных ошибок (exploits), а также неконтролируемое распространение информации о внутренних ресурсах. Единственными name-серверами, которым необходимо периодическое обновление своих зонных файлов, являются вторичные name-серверы. Следовательно, зонная пересылка от первичного name-сервера должна разрешаться только к вторичным name-серверам. Зонная пересылка должна быть полностью запрещена на вторичных name-серверах. Аргумент списка соответствующих адресов в подутверждении allow-transfer должен состоять из IP-адресов вторичных name-серверов, которые указаны в NS множества ресурсных записей, и "невидимых" вторичных name-серверов, которые указаны только в этом подутверждении.

Команда для создания ACL valid_secondary_NS с IP-адресами трех вторичных name-серверов следующая:

acl "valid_secondary_NS" {
  224.10.229.5;
  224.10.235.6;
  224.10.245.25;
};

Подутверждение allow-transfer может быть использовано в утверждении zone и в утверждении options. Если оно используется в утверждении zone, то ограничивает зонную пересылку для данной зоны; если используется в утверждении options, ограничивает зонную пересылку для всех зон в name-сервере.

Подутверждение allow-transfer на уровне сервера является следующим:

options {
  allow-transfer { valid_secondary_NS; };
};

Подутверждение allow-transfer на уровне зоны является следующим:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-transfer { valid_secondary_NS; };
};

Предыдущие утверждения используются на первичных name-серверах. На вторичных и невидимых name-серверах зонная пересылка должна быть запрещена, как показано ниже:

zone "example.ru" {
  type slave;
  masters { 224.239.5.1 };
  file "zonedb_bak.example.ru";
  allow-transfer { none; };
};
Ограничение участников транзакции динамического обновления

Динамические обновления зонного файла могут осуществляться только для зонного файла, находящегося на первичном name-сервере зоны. По умолчанию динамические обновления отключены как в BIND 8, так и в BIND 9. Динамические обновления управляются использованием одного из следующих двух утверждений в BIND:

Эти утверждения могут быть указаны только на уровне зоны, а не на уровне сервера. Следовательно, они являются подутверждениями внутри утверждения zone. Подутверждение allow-update дает возможность указать ограничения динамического обновления на основе IP-адресов и разделяемого секрета (также называемого TSIG key). Сначала обсудим использование allow-update с помощью указания только IP-адресов, а затем — использование утверждения allow-update с TSIG-ключами.

Утверждение update-policy дает возможность указать ограничения динамического обновления только на основе TSIG-ключей, при этом ограничения могут быть указаны более детально. Подутверждение allow-update определяет права доступа, касающиеся модификаций, ко всем записям в зоне. Подутверждение update-policy может быть использовано для ограничения прав доступа по модификации к одному или более типам ресурсных записей (например, A ресурсные записи).

Для использования утверждения allow-update должен быть создан список соответствующих адресов. Команда для создания ACL DU_Allowed_List с одним IP-адресом следующая:

acl "DU_Allowed_List" {
  192.249.12.21;
};

ACL DU_Allowed_List (содержащий IP-адреса хостов, которым разрешено посылать запросы динамического обновления для изменения содержимого зоны example.ru ) используется внутри подутверждения allow-update утверждения zone следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-update { DU_Allowed_List; };
};

Запросы динамического обновления обычно исходят от таких хостов, как DHCP-серверы, которые динамически связывают IP-адреса с хостами. После того, как они назначат IP-адрес новому хосту, им нужно сохранить информацию отображения доменного имени на IP-адрес (созданием A ресурсной записи) и отображения адреса на доменное имя (созданием PTR ресурсной записи) в первичном авторитетном name-сервере для зоны. Создание данной информации происходит посредством динамических обновлений.

Ограничение участников транзакции DNS NOTIFY

После того как зонные пересылки между серверами установлены, хорошо бы гарантировать, что вторичные name-серверы будут информироваться об изменениях в данных зонного файла посредством получения уведомления. По умолчанию сообщение уведомления посылается всякий раз, когда первичный name-сервер определил, что было сделано изменение в зонном файле. Он посылает сообщение DNS NOTIFY каждому name-серверу, перечисленному в NS -множестве ресурсных записей в зоне, потому что эти серверы считаются вторичными name-серверами зоны. Администратор DNS должен оставить выполнение этой транзакции, потому что это позволяет быстро распространять обновления на вторичные name-серверы. Однако, если администратор хочет выключить данную функциональность для конкретной зоны, следует использовать подутверждение notify в утверждении zone для данной зоны:

zone "example.ru" {
  type master;
  notify no;
  file "zonedb.example.ru";
};

Если существуют дополнительные серверы, на которые администратор хочет посылать сообщение DNS NOTIFY (например, "невидимый" вторичный сервер), должно быть добавлено подутверждение also-notify в утверждение zone, и IP-адреса дополнительных серверов должны быть указаны в качестве значений параметров следующим образом:

zone "example.ru" {
  type master;
  also-notify { 192.168.25.2; };
  file "zonedb.example.ru";
};

Получатель сообщения DNS NOTIFY, которым является вторичный name-сервер, по умолчанию разрешает получать сообщения уведомления только от первичного name-сервера. То, что данный name-сервер является вторичным для первичного name-сервера, указывается посредством подутверждения masters в утверждении zone. Если вторичный name-сервер хочет получать сообщения уведомления также и от других серверов, следует добавить подутверждение allow-notify в утверждение zone, и соответствующие IP-адреса этих серверов:

zone "example.ru" {
  type slave;
  allow-notify { 193.168.25.4; };
  file "zonebak.example.ru";
  masters { 192.168.25.1; };
};

Защита транзакции с использованием НМАС (TSIG)

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

Функция НМАС использует два параметра – сообщение и секретный ключ – и создает выход, называемый кодом аутентификации сообщения (МАС) или хэшем. Отправитель сообщения использует функцию НМАС для создания МАС и посылает данный МАС вместе с сообщением получателю. Получатель, который разделяет тот же самый секретный ключ, использует ключ и ту же самую хэш-функцию для вычисления МАС для полученного сообщения. Затем получатель сравнивает вычисленный МАС с полученным МАС; если два значения совпали, существует определенная гарантия, что сообщение передано корректно и что отправитель знает тот же самый секретный ключ. Таким образом, выполняется одновременно аутентификация источника сообщения и проверка целостности.

Хэш-алгоритм создает МАС фиксированной длины из сообщения произвольной длины. Функция НМАС для TSIG, специфицированная в RFC 2845, определяет только один хэш-алгоритм (MD5), идентификатор алгоритма есть HMAC-MD5. Поддержка других алгоритмов (например, SHA-1 и SHA-256) может быть задана в дальнейшем.

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

МАС, создаваемый отправителем DNS-сообщения, помещается в новую ресурсную запись, называемую TSIG записью, которая добавляется к DNS-сообщению. Запись TSIG в дополнение к созданному хэшу содержит следующее:

Поле timestamp указывает время, когда был создан МАС. Цель данного поля состоит в защите от replay-атак. При replay-атаке атакующий может перехватить пакет, содержащий МАС, и послать его позднее. Для гарантирования того, что этого не произойдет, получатель анализирует время создания МАС и текущее время и проверяет, был ли создан МАС в "допустимое время", которое вычисляется с использованием "Fudge-фактора".

Для того чтобы обеспечить безопасность транзакции на основе МАС, отправитель вычисляет хэш от всего DNS-сообщения и секретного ключа и записывает результат в TSIG ресурсную запись в конец сообщения. На стороне получателя запись TSIG извлекается из сообщения и обрабатывается. Процесс, при котором получатель использует запись TSIG для проверки целостности полученного DNS-сообщения, называется верификацией. Процесс верификации использует название хэш-алгоритма для определения хэш-функции и имя ключа для определения ключа, используемого для верификации записи TSIG. Значение Fudge-фактора используется для возможной корректировки времени создания хэша. Тем самым Fudge-фактор определяет допустимый период действительности МАС относительно времени его создания.

Указание имени ключа в записи TSIG дает возможность проверяющей стороне (т.е. получателю) использовать правильный ключ, а также дает возможность проверить, что ключ действительно является одним из ключей, разделяемых отправителем и получателем. Цель поля timestamp в записи TSIG состоит в информировании получателя сообщения о времени создания МАС. Получатель сравнивает данное значение с текущим значением часов на машине получателя для гарантии того, что МАС был создан в допустимый интервал времени. Цель использования timestamp состоит в предотвращении replay-атак. Для корректной проверки времени создания относительно текущего времени особенно важно, чтобы системные часы участников транзакции были синхронизованы. В этих целях может использоваться такой протокол, как Network Time Protocol (NTP).

Процесс верификации состоит в извлечении соответствующего секретного ключа, вычислении хэша от полученного сообщения и секретного ключа, и сравнении вычисленного хэша с полученным хэшем (в TSIG-записи). В процессе верификации name-сервер выполняет следующие проверки:

В BIND версии 8.2 были впервые введены возможности TSIG, но полностью TSIG был реализован только в BIND 9.х. Поддержка в BIND 9.х возможностей TSIG обеспечена и для транзакций зонных пересылок, и для транзакций динамического обновления.

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

Создание ключа

Чтобы обеспечить возможность выполнять аутентификацию зонных пересылок (запросов и ответов), необходимо создать ключи для каждой пары name-серверов. Ключ также может использоваться для обеспечения безопасности других транзакций, таких как динамические обновления, запросы и ответы DNS. Битовая строка ключа, которая создается большинством утилит генерации ключа, используемых с DNSSEC, указывается в виде Base64. Программой, которая создает ключ в BIND 9.х, является dnssec-keygen. Приведем пример вызова этой программы для создания секретного ключа. Следует заметить, что программа может также создавать и другие типы ключей, например, открытый и закрытый ключи:

dnssec-keygen –a HMAC-MD5 –b 128 –n HOST ns1-ns2.example.ru

где параметры команды означают следующее:

-a: название алгоритма хэширования, который будет использоваться (HMAC-MD5).

-b: длина ключа (128 бит).

-n: тип ключа (HOST).

Последний параметр: имя ключа ( ns1-ns2.example.ru ).

Программа dnssec-keygen создает следующие файлы, содержащие строку ключа:

Kns1-ns2.example.ru.+157+34567.key
Kns1-ns2.example.ru.+157.34567.private

Когда программа создает пару ключей (открытый и закрытый), файл с расширением key будет содержать строку открытого ключа, а файл с расширением private будет содержать закрытый ключ. Так как в нашем случае создается только секретный ключ, строки ключа в обоих файлах будут одинаковыми. Строка ключа из любого из этих файлов затем копируется в файл, называемый файлом ключа. Данный файл указывается в утверждении include внутри утверждения key.

Определение ключей для взаимодействующих name-серверов

Ключ, созданный с использованием утилиты dnssec-keygen, должен быть указан внутри конфигурационных файлов named.conf двух взаимодействующих серверов (обычно это один первичный name-сервер и один вторичный name-сервер). Это достигается использованием утверждения key в BIND:

key "ns1-ns2.example.ru." {
  algorithm hmac-md5;
  include "/var/named/keys/secretkey.conf";
};

где файл secretkey.conf содержит слово secret и реальную строку ключа:

secret "Mdkhhladasdka;"

Указание name-серверу использовать ключи во всех транзакциях

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

Команда для указания серверу использовать ключ во всех транзакциях (запрос / ответ DNS, зонная пересылка, динамическое обновление и т.п.) следующая:

server 192.249.249.1 {
  keys { ns1-ns2.example.ru.; };
};

где параметр keys является именем ключа.

Подведем итоги:

  1. TSIG должен создавать МАС длиной минимум 128 бит.
  2. Для каждого типа транзакций (зонная пересылка, динамическое обновление и т.п.) должен быть создан уникальный TSIG-ключ.
  3. После того как строка ключа скопирована в файл ключа на name- сервере, оба файла, созданные программой dnssec-keygen, должны быть сделаны доступными только аккаунту администратора сервера (например, root на Unix), или, еще лучше, удалены. Бумажные копии этих файлов также должны быть уничтожены.
  4. Файл с ключом должен быть безопасно передан name-серверам, которые будут взаимодействовать с name-сервером, где создан ключ.
  5. Утверждение в конфигурационном файле (обычно находящимся в /etc/named.conf для BIND, выполняющихся на Unix), которое описывает TSIG-ключ (имя ключа (ID), алгоритм и строка ключа) не должно непосредственно содержать строку ключа. Когда строка ключа находится в конфигурационном файле, риск компрометации ключа возрастает в тех окружениях, в которых требуется делать конфигурационный файл читаемым кому-либо, кроме администратора зоны. Вместо этого строка ключа должна быть определена в отдельном файле ключа, на который должна быть сделана ссылка с помощью директивы include в утверждении key в конфигурационном файле. Каждый TSIG-ключ должен храниться в отдельном файле ключа.
  6. Собственником файла ключа должен быть аккаунт, от имени которого выполняется ПО name-сервера. Биты разрешения должны быть установлены таким образом, чтобы файл ключа мог читаться и модифицироваться только аккаунтом, от имени которого выполняется ПО name-сервера.
  7. Ключ TSIG, используемый для аутентификации и обеспечения целостности сообщений между парой серверов, должен быть указан в утверждении server у обоих взаимодействующих серверов. Это необходимо, чтобы гарантировать, что и для сообщения запроса, и для сообщения транзакции вычислены МАС и тем самым обеспечена их безопасность.

Безопасность зонных пересылок с использованием TSIG

Для пары серверов, участвующих в транзакциях зонных пересылок, указывается, что они должны использовать ключ, определенный в утверждении key. Такая пара обычно состоит из первичного name-сервера и вторичного name-сервера. Первичный name-сервер конфигурируется таким образом, чтобы принимать запросы зонной пересылки только от вторичных name-серверов, которые посылают МАС с использованием поименованного ключа, передаваемого в сообщении запроса зонной пересылки. Конфигурация создается с использованием подутверждения allow-transfer в утверждении zone. Пример подутверждения allow-transfer, которое указывает, что первичный name-сервер должен разрешать запросы зонной пересылки только для зоны example.ru от name-серверов, использующих ns1-ns2.example.ru ключ, выглядит следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-transfer { key {ns1-ns2.example.ru}; };
};

Вторичному name-серверу указывается использовать ключ ns1-ns2.example.ru в запросе зонной пересылки к первичному name-серверу, задействуя утверждение server.

Безопасность динамических обновлений с использованием TSIG

Ограничения динамических обновлений, основанные на ключах TSIG, могут быть указаны в BIND 8.2 и более поздних версиях использованием подутверждения allow-update утверждения zone. Аргументом данного утверждения является ключевое слово key, за которым следует имя TSIG-ключа.

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  allow-update { key {dhcp-server.example.ru.}; };
};

Заметим, что, хотя строка dhcp-server.example.ru. выглядит как FQDN, на самом деле она обозначает имя TSIG-ключа. В данном примере любой хост, который обладает ключом с именем dhcp-server.example.ru., может посылать запросы динамического обновления (добавления, удаления или модификации ресурсных записей) зонного файла (для зоны example.ru ), который расположен на первичном авторитетном name-сервере.

Конфигурирование ограничений перенаправления динамических обновлений с использованием ключей TSIG

Динамическим обновлениям разрешено копирование зонного файла на первичный авторитетный name-сервер только потому, что он является "writable". При этом автоматически не предполагается, что только первичный авторитетный name-сервер может принимать запросы динамического обновления. В BIND 9.1.0 и более поздних версиях разрешается вторичным name-серверам принимать запросы динамического обновления и перенаправлять их первичному авторитетному name-серверу. В данном сценарии, если не существует ограничений, основанных на идентификации хостов, с которых вторичный name-сервер может перенаправлять такие запросы динамического обновления, это эквивалентно обходу ограничений динамического обновления, указанным в первичном name-сервере, потому что запрос может исходить с любого хоста к вторичному name-серверу и перенаправляться на первичный name-сервер. Для решения данной проблемы было добавлено новое подутверждение allow-update-forwarding в версии BIND, которые имеют возможность перенаправления динамических обновлений. Пример такого allow-update-forwarding утверждения с использованием TSIG-ключей следующий:

zone "example.ru" {
  type slave;
  file "backupdb.example.ru";
  allow-update-forwarding { key {dhcp-server.example.ru.}; };
};

Конфигурирование более точных ограничений динамического обновления с использованием TSIG-ключей

Подутверждение allow-update определяет ограничения динамического обновления, которые основаны на отправителях запросов динамических обновлений (конкретное множество хостов, идентифицируемых по IP-адресу или обладающих TSIG-ключом), но не на содержимом зонных записей. Для указания ограничений доступа ( grant или deny ) к динамическим обновлениям, основанным на комбинации имен домена или поддомена и типов ресурсных записей ( A, MX, NS и т.п.), BIND 9 и более поздние версии предоставляют подутверждение update-policy в утверждении zone. Эти ограничения в подутверждении update-policy основаны на TSIG-ключе. Другими словами, подутверждение update-policy указывает, каким TSIG ключам (держателям ключей) разрешено выполнять динамические обновления для каких доменов или поддоменов и типов ресурсных записей внутри данного домена или поддомена.

Общая форма update-policy утверждения следующая:

update-policy {
  (grant | deny) TSIGkey nametype name [type]
};

где семантика каждого компонента утверждения такова:

Примеры update-policy утверждений и связанная с ними семантика приведены ниже.

Предположим, что существует домен sales.example.ru внутри example.ru и что name-сервер использует TSIG ключ, который имеет то же самое имя, что и имя его домена (т.е. sales.example.ru ). Все динамические обновления от sales.example.ru могут быть ограничены ко всем ресурсным записям данного домена следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  update-policy { grant sales.example.ru. self sales.example.ru.; };
};

Все динамические обновления от sales.example.ru могут быть ограничены только типами ресурсных записей A и MX данного домена следующим образом:

zone "example.ru" {
  type master;
  file "zonedb.example.ru";
  update-policy {
  grant sales.example.ru. self sales.example.ru. A MX; };
};

Лекция 8. Безопасность DNS Query/Response

Рассматривается способ, которым DNSSEC обеспечивает защиту транзакций DNS Query/Response с помощью аутентификации источника, проверки целостности данных и аутентифицированного отказа при отсутствии запрошенных данных. Описываются механизмы, используемые DNSSEC, операции, с помощью которых эти механизмы реализуются, и способы обеспечения безопасности этих операций. Задаются принципы безопасного развертывания DNSSEC.

Рассмотрим способ, которым DNSSEC обеспечивает защиту транзакций DNS Query / Response с помощью аутентификации источника, проверки целостности данных и аутентифицированного отказа при отсутствии запрошенных данных. Опишем механизмы, используемые DNSSEC операции, с помощью которых эти механизмы реализуются, и способы обеспечения безопасности этих операций. Другими словами, опишем принципы безопасного развертывания DNSSEC.

Для гарантирования end-to-end защиты транзакций запросов и ответов DNS необходимы дополнительные меры защиты (отличные от тех, которые определены в спецификации DNSSEC – такие как обеспечение безопасности коммуникационного пути между локальными поддерживающими DNSSEC кэширующим name-сервером и stub resolver’ами. Эти меры также будут обсуждаться далее.

Механизмы и операции DNSSEC

Механизмы DNSSEC определяют две основных операции: подписывание (и связанные с этим действия) и проверка подписи. Рассмотрим эти операции.

Типы записей, используемых DNSSEC

Первой задачей является создание цифровых подписей для ресурсных записей в зонном файле. DNSSEC предполагает создание подписи для всего RRSet (множества ресурсных записей c одним и тем же именем владельца, классом и типом), а не для каждой ресурсной записи. Цифровая подпись и связанная с ней информация (ID использованного ключа, признаки начала и конца подписываемого блока и т.п.) содержатся в специальной ресурсной записи RRSIG. Строка, содержащая открытый ключ, который используется для проверки подписи (в RRSIG ), содержится в ресурсной записи с типом DNSKEY. Другой тип ресурсной записи, NSEC (Next Secure) используется для перечисления типов ресурсных записей (в каноническом порядке), существующих в данном домене. Подписи (т.е. ресурсные записи RRSIG ) для данного типа ресурсных записей создаются, кроме того, для обеспечения аутентифицированного доказательства невозможности создания ответов на запросы для несуществующего типа ресурсных записей. Дополнительно существует необязательный тип ресурсной записи DS (Delegation Signer) для случая, когда зона хочет разрешать выполнить проверку подлинности открытых ключей своих дочерних зон. Детальный синтаксис каждого из этих дополнительных типов ресурсных записей, введенных спецификацией DNSSEC указан в RFC 4034. Самой важной из них является ресурсная запись RRSIG, потому что именно она содержит строку подписи.

Ресурсная запись RRSIG, подобно другим ресурсным записям, содержит поля имени собственника, TTL, класс, RRType и RDATA. Цифровая подпись и вся связанная с ней информация находится в поле RDATA. Расположение поля RDATA в ресурсной записи RRSIG со всеми подполями показано ниже. Также приведено краткое описание каждого подполя.

Содержимое поля RDATA в ресурсной записи RRSIG
RRRtype CoveredAlgorihm CodeLabels
Original TTL
Signature Expiration
Signature Inception
Key TagSigner's NAme
Encoded Signature
Поле RRType Covered имеет тип ресурсной записи, для которого RRSIG содержит подпись.

Поле Algorithm Code есть целое число, равное коду соответствующего криптографического алгоритма, использованного для создания подписи.

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

Значения Signature Expiration и Signature Inception являются абсолютными значениями времени, которые определяют период действительности подписи, – период времени, в течение которого данная RRSIG считается действительной для зоны.

Поля Key Tag и Signer’s Name являются хэшем и доменным именем (FQDN) для ресурсной записи DNSKEY, которая будет использоваться клиентом для проверки действительности подписи.

Наконец, последнее поле содержит саму подпись.

Зона, которая содержит эти дополнительные ресурсные записи наряду с обычными ресурсными записями, называется подписанной зоной. Name-сервер, который создает такие подписанные зоны и включает в свой ответ соответствующие подписи (т.е. соответствующие RRSIG ) вместе в запрошенными ресурсными записями, называется поддерживающим DNSSEC name-сервером.

Список операций DNSSEC

Ответ, пришедший из подписанной зоны, называется подписанным ответом. Resolver, который имеет возможность проверять подписи в подписанном ответе, называется поддерживающий DNSSEC validating resolver. Прежде чем resolver сможет проверить подпись, созданную для множества ресурсных записей и полученную им в ответе, используя открытый ключ зоны, посланный в ответе, он должен установить доверие к этому открытому ключу. В DNSSEC данное требование означает, что resolver должен выполнить так называемое построение доверенной цепочки. Для этого resolver рассматривает список известных доверенных ключей (называемых trust anchors ) и создает цепочку открытых ключей, с помощью которой он устанавливает доверие к открытому ключу зоны, полученному им в ответе. Для построения цепочки используется иерархия пространства имен DNS. В идеале trust anchors в resolver’е содержат открытые ключи root’а (если root-сервер поддерживает DNSSEC или открытые ключи зон, расположенных ниже в иерархии. Список trust anchors в resolver’е не строится с помощью транзакций DNS; для этого используется некоторый внешний механизм.

Процессы DNSSEC описанные выше, включают несколько операций name-сервера и несколько операций resolver’а. Операциями name-сервера являются следующие:

Операциями resolver’а являются:

Операции name-сервера с DNSSEC-ОР1 по DNSSEC-ОР4 и операции resolver’а DNSSEC-ОР7 и DNSSEC-ОР8 выполняются либо перед развертыванием DNSSEC, либо перед операциями обеспечения безопасности запросов и ответов (таких как обработка подписанных ответов и проверка подписей). Рассмотрим эти операции в первую очередь. Оставшиеся операции name-сервера (обновление ключа и переподписывание зоны – DNSSEC-ОР5 и DNSSEC-ОР6 соответственно) выполняются периодически после полного развертывания DNSSEC и будут приведены в конце лекции.

Создание пары открытый / закрытый ключи (DNSSEC-ОР1)

DNSSEC определяет создание и проверку цифровых подписей с использованием асимметричных ключей. Это требует создания пары открытый / закрытый ключи. Для облегчения операций администрирования, которые должны выполняться периодически, таких как обновление ключа и переподписывание зоны, необходимо иметь два различных типа ключей. Один тип ключа называется Key Signing Key ( KSK Ключ данного типа (а именно, закрытый ключ, называемый KSK-private) будет использоваться только для подписывания ключа, содержащегося в зонном файле в ресурсной записи с типом DNSKEY . Другой тип ключа называется Zone Signing Key ( ZSK ) (соответствующий закрытый ключ называется ZSK-private). Этот ключ используется для подписывания всех множеств ресурсных записей в зоне (включая множество ресурсных записей DNSKEY ). Административное разграничение между KSK- и ZSK-ключами осуществляется с помощью флага Secure Entry Point ( SEP ) в ресурсной записи DNSKEY, который присутствует в открытых ключах, называемых KSK-public и ZSK-public, соответственно.

Причина, лежащая в основе создания двух типов пар ключей, состоит в определении отдельного набора функций для каждого типа ключа для того, чтобы уменьшить сложность задач, связанных с обновлением ключей и переподписыванием зоны. KSK (KSK-private) используется для подписывания множества ключей (т.е. множества ресурсных записей DNSKEY ) и является тем ключом, который передается родительской зоне для использования его при аутентифицированном делегировании. Аутентифицированное делегирование выполняется посредством создания ресурсной записи DS, содержащей хэш дочернего KSK-public ключа, и затем создания соответствующей подписи (ресурсной записи RRSIG ), используя свой собственный ZSK-private. Ключ KSK (KSK-public) также может использоваться в качестве доверенного anchor для установления доверенных цепочек при проверке подписей.

Ключ ZSK (ZSK-private) применяется для подписывания зонного файла (всех множеств ресурсных записей). Открытый ключ (ZSK-public) не посылается родителю, он всегда хранится в зоне.

При создании пар ключей KSK и ZSK необходимо выбрать следующие параметры:

Выбор алгоритма цифровой подписи основывается на принятых стандартах. Обычно рассматриваются следующие алгоритмы:

Из этих трех алгоритмов наиболее широко распространены RSA и DSA. С точки зрения производительности RSA и DSA имеют сопоставимую скорость создания подписи, но DSA является более медленным при проверке, а RSA — более быстрым. Единственным обязательным для реализации в DNSSEC алгоритмом является RSA с MD5. Считается, что как минимум name-серверы и клиенты должны иметь возможность использовать RSA. Предполагается, что по крайней мере один ZSK для зоны использует алгоритм RSA.

Выбор длины ключа определяется соотношением между риском компрометации ключа и производительностью. Производительность определяется временем создания подписи и временем проверки подписи. Длина пакета DNS-ответа также должна учитываться, потому что ресурсные записи DNSKEY посылаются в дополнительном разделе DNS-ответа. Так как ключ KSK используется только для подписывания множества ключей (множества ресурсных записей DNSKEY ), в этом случае производительность не является решающим фактором. Однако компрометация ключа KSK может иметь большее негативное воздействие, так как этот ключ является фактически мастер-ключом для зоны. Компрометация ключа KSK в зоне, расположенной высоко в DNS-иерархии, может подвергнуть большую часть DNS-поддерева (следовательно, большое число зон) spoofing атакам. Кроме того, обновление ключа KSK в случае компрометации означает изменение доверенных anchor’ов во многих name-серверах и resolver’ах. Тем самым для KSK рекомендуется большая длина ключа: он имеет небольшое воздействие на производительность, но чувствителен к компрометации.

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

Выбор периода использования (периода обновления) определяется риском раскрытия ключа. В случае KSK объем подписываемой информации не очень большой (потому что ключ KSK подписывает только множество ресурсных записей DNSKEY, и частота изменения данного множества ресурсных записей также маленькая). Минимальная вероятность раскрытия ключа (небольшой объем данных, доступный для угадывания KSK-private) в комбинации с большой длиной ключа приводит к тому, что период использования KSK может быть большим (обычно год или два).

В случае ключа ZSK риск раскрытия больше. Большая, чем для KSK вероятность раскрытия ключа есть результат того, что подписываемый объем данных является достаточно большим (так как ZSK подписывает все ресурсные записи в зоне, и изменения ресурсных записей происходят чаще, чем ресурсных записей DNSKEY, тем самым количество создаваемых подписей больше). Этот фактор в сочетании с относительно небольшой длиной ключа приводит к тому, что период действительности ключей ZSK должен быть меньше, чем период действительности ключей KSK обычно месяц или два).

Рекомедация:

Длина ключа для KSK должна быть достаточно большой, потому что компрометация KSK-ключа сильно влияет на безопасность DNS. Период действительности (период обновления) для ZSK должен быть сравнительно коротким, потому что существует больший риск угадывания ключа в результате большей незащищенности ZSK-ключа.

С точки зрения количества создаваемых ключей каждого типа ( KSK и ZSK ), хорошей практикой считается создание дополнительного ключа ZSK к тому, который используется в текущий момент. Следовательно, администратор зоны должен использовать программу создания ключа для создания одного KSK и двух ZSKs при начальном развертывании DNSSEC. Один ZSK рассматривается как активный ключ, и его закрытая часть (ZSK-private) используется для создания подписей. Другой ZSK (ZSK-public) помещается в множество ресурсных записей DNSKEY, но соответствующая закрытая часть (ZSK-private) не будет использоваться для подписывания множества ресурсных записей. Данный дополнительный ключ ZSK дает возможность немедленно обновить ZSK в случае аварийных ситуаций, таких как компрометация ключа. Этот подход предоставляет способ предварительного уведомления resolver’ов, которые будут проверять подписи зон, что это тот ключ, который станет новым ключом после истечения периода действительности текущего ключа. Указание периода действительности ключа в множестве ресурсных записей DNSKEY дает возможность resolver’ам кэшировать и устанавливать доверие к новому ключу так, что они могут немедленно после обновления использовать новый ключ для проверки подписи.

Пример создания пары ключей

Любое ПО name-сервера поддерживающего DNSSEC должно предоставлять программную утилиту для создания пары асимметричных ключей. Проиллюстрируем использование одной из таких программ, dnssec-keygen (имеющейся в BIND 9.3.x):

dnssec-keygen –a algorithm –b bits –n type [options] name

где algorithm может быть один из следующих:

bits (длина ключа) имеет следующие диапазоны:

type может быть одним из ZONE или HOST. В принципе, могут быть добавлены и любые другие типы ключей.

name есть имя собственника ключа (обычно имя домена).

Данная команда создает два файла: один содержит открытый ключ, а другой файл — соответствующий ему закрытый ключ. Имена этих файлов следующие:

K<domain_name>+algorithm_id+Key_id.key
K<domain_name>+algorithm_id+Key_id.private

domain_name является значением параметра name, указанного в командной строке. Algorithm_id может быть следующим:

3 – DSA

5 – RSAMD5

key_id есть уникальный идентификатор созданного ключа, созданного программой.

Например, для создания ZSK-ключа длиной 1024 бит, который использует набор алгоритмов RSAMD5 для подписывания зоны example.ru, должна быть выполнена следующая команда:

dnssec-keygen –a RSAMD5 –b 1024 –n ZONE example.ru

Будут созданы следующие файлы, содержащие закрытый и открытый ключи:

Kexample.ru.+005+28345.private
Kexample.ru.+005+28345.key

В этих именах файлов 005 определяет algorithm_id и 28345 есть уникальный идентификатор ключа.

В *.key файле информация открытого ключа имеет тот же самый синтаксис, что и ресурсной записи в зонном файле. Содержимое файла Kexample.ru.+005+28345.key следующее:

example.ru IN DNSSEC 256 3 5 BQFG...... (строка ключа в Base64)

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

cat *.key >> /var/named/zonedb.example.ru

После того как ресурсная запись DNSKEY, содержащая открытый ключ, добавлена в зонный файл, Serial Number зоны должен быть увеличен до того, как будет выполнено подписывание зоны.

Безопасное хранение закрытых ключей (DNSSEC-OP2)

Закрытые ключи из KSK и ZSK пар ключей должны быть защищены от неавторизованного доступа. В идеале, закрытые ключи должны храниться off-line на физически безопасной, не доступной из сети машине вместе с мастер-копией зонного файла. Подписи, создаваемые с использованием закрытых ключей, должны пересылаться на первичные авторитетные name-сервера посредством процесса загрузки, используя динамически устанавливаемое сетевое соединение (а не постоянный сетевой канал).

Данная стратегия неосуществима в ситуациях, когда поддерживающий DNSSEC name-сервер должен выполнять динамические обновления. Для поддержки транзакций динамических обновлений name-сервер (который обычно является первичным авторитетным name-сервером) должен иметь как мастер-копию зонного файла, так и соответствующий закрытый ключ для подписывания зоны (ZSK-private) в режиме on-line для немедленного обновления подписей для измененных ресурсных записей. Закрытый ключ из KSK (KSK-private) может, тем не менее, храниться off-line. В этом случае должны быть предприняты следующие меры для защиты ZSK-private:

  1. shell, из которого вызывается утилита создания ключа, должен быть недоступен для всех, за исключением администратора зоны.
  2. Директория, в которой хранятся файлы закрытых ключей (обычно это поддиректория с тем же именем, что и зона, с именами файлов, имеющими структуру имени K<zonename>.AlgorithmID+<keytag>.private в BIND), должна быть недоступна и невидима для всех, за исключением администратора зоны.
  3. Возможность быстрого восстановления должна быть обеспечена тем, что имеется зеркальный диск или выполняется периодический backup на съемный носитель.
  4. Другая стратегия состоит в хранении закрытых ключей в зашифрованной файловой системе.

Рекомендация:

Закрытые ключи, соответствующие как ZSK, так и KSK, не должны храниться в поддерживающем DNSSEC первичном авторитетном name-сервере, если name-сервер не должен выполнять динамических обновлений. Если динамические обновления поддерживаются, то только закрытый ключ, соответствующий ZSK, должен храниться на name-сервере в директории и файле с соответствующем управлением доступа или криптографически защищенным.

Опубликование открытого ключа (DNSSEC-OP3) и конфигурирование доверенных anchor’ов (DNSSEC-OP7)

Проверка данных зоны resolver’ом начинается с того, что resolver знает открытый ключ данной зоны (той, чьи данные он проверяет) или любой из открытых ключей зон, расположенных выше в дереве DNS. Если проверяемая зона (например, example.ru ) поддерживает безопасность (т.е. поддерживает DNSSEC ), а ее родитель ( .ru ) — нет, то точка доверия начинается с самой зоны. Если зона родителя (зона .ru ) поддерживает безопасность, а зона выше по дереву (зона root) — нет, начальной точкой доверия является родитель (т.е. зона .ru ). Если зона root поддерживает безопасность, то она становится исходной точкой доверия.

В любом случае открытый ключ данной начальной точки должен быть известен resolver’ам. Такие открытые ключи, известные resolver’ам, называются доверенными anchor’ами. Поскольку не существует возможности средствами DNS выполнить проверку этих открытых ключей, открытый ключ доверенного anchor’а должен распространяться внешним по отношению к DNS способом. Данное распространение может быть осуществлено с использованием таких каналов, как web-сайты или e-mail.

Список доверенных anchor’ов в поддерживающем DNSSEC resolver’е определяет, какой подписанный ответ от зоны будет рассматриваться как безопасный, а какой — нет. Как уже отмечалось, resolver должен установить доверие к открытому ключу зоны, из которой он получил ответ, перед тем как выполнить проверку подписи. Если такое доверие не может быть установлено с помощью построения доверенной цепочки, используя записи в списке доверенных anchor’ов, ответ должен помечаться как небезопасный. Причина, по которой отсутствует возможность построения доверенной цепочки, может состоять в том, что пространство имен DNS содержит только отдельные участки подписанных зон вместо непрерываемой иерархической последовательности подписанных зон. Предположим, что дерево DNS имеет следующую структуру.

Тогда статус ответа (безопасный или небезопасный) зависит от списка хранящихся в resolver’е доверенных anchor’ов и от того, из какой зоны получен ответ.

"Острова" подписанных зон


Рис. 8.2.  "Острова" подписанных зон

Результат приведен в таблице.

Возможные статусы ответа
Доверенный anchor, инсталированный в поддерживающий DNSSEC resolverСтатус DNSSEC ответа для запрошенных адресов
www.example.ruwww.example.orgwww.example.com
NoneInsecureInsecureInsecure
RootSecureInsecureInsecure
.orgInsecureSecureInsecure
example.comInsecureInsecureSecure

Подписывание зоны (DNSSEC-OP4)

При подписывании зонного файла выполняется следующая последовательность действий:

  1. Зонный файл сортируется в каноническом порядке доменных имен.
  2. Создается ресурсная запись NSEC для каждого имени собственника в зоне.
  3. Используется ключ KSK (KSK-private) для подписывания множества ресурсных записей DNSSEC. Ключ KSK определяется по наличию установленного флага SEP в RDATA в ресурсной записи DNSSEC.
  4. Ключ ZSK (ZSK-private) используется для подписывания всех ресурсных записей в зоне (включая ресурсные записи DNSKEY и NSEC ).

Рекомендации:

  1. Создание подписи с использованием ключа KSK должно выполняться off-line, используя KSK-private, также хранимый off-line; затем ресурсные записи DNSKEY вместе в ресурсной записью RRSIG должны быть размещены в первичном авторитетном name-сервере.
  2. Хранение ключа ZSK-private и создание подписи с использованием этого ключа должно выполняться off-line; ресурсные записи вместе с RRSIG ресурсными записями затем могут быть записаны в первичный авторитетный name-сервер. Исключением является случай, когда name-сервер поддерживает динамические обновления. В этом случае ZSK-private должен располагаться в name-сервере.

Пример подписывания зоны

Приведем пример, иллюстрирующий использование программы подписывания зоны (dnssec-signzone в BIND 9.3.x):

dnssec-signzone –o <name of zone> -k <name of file containing KSK> 
   <location of zone file> <name of file containing ZSK>

Для подписывания данных из зоны example.ru с KSK, расположенным в файле Kexample.ru.+005+76425.key, и ZSK, созданным заранее, следует выполнить следующую команду:

dnssec-signzone –o example.ru -k Kexample.ru.+005+76425.key
   /var/named/zonedb.example.ru Kexample.ru.+005+28345.key

Процесс подписывания зонного файла состоит из следующих шагов:

Ключ KSK подписывает только множество ресурсных записей DNSKEY, а ключ ZSK — все ресурсные записи в зонном файле. Участник, чей закрытый ключ используется для подписывания данных зоны, называется подписывающей стороной (signer или signing authority). В большинстве случаев подписывающая сторона является доменом, связанным с зоной. В ответ на DNS-запрос поддерживающий DNSSEC авторитетный name-сервер выдает соответствующие данные зоны вместе с цифровой подписью этих данных. Получатель проверяет цифровую подпись для полученных данных зоны, используя открытый ключ подписавшего (после установления доверия к открытому ключу).

Создание доверенной цепочки и проверка подписи (DNSSEC-OP8)

До тех пор, пока все зоны не станут подписанными, возможна ситуация, при которой зона является подписанной, но ее родитель не является подписанной зоной. Единственной точкой доверия для поддерживающего DNSSEC resolver’а в этом случае может считаться заранее сконфигурированный открытый ключ подписывающей стороны. При отсутствии другого источника, подтверждающего достоверность открытого ключа подписывающей стороны, требуется, чтобы открытый ключ был получен безопасным способом. В противном случае, если существует домен X, который может подтвердить достоверность открытого ключа домена Y, resolver может установить доверие к подписывающей стороне Y, используя X. Последовательность зон в дереве DNS, с помощью которых resolver устанавливает доверие к открытому ключу подписывающей стороны, называется цепочкой доверия.

Будем считать, что цепочка доверия начинается с домена X и заканчивается доменом Y. Обычно домен X является непосредственным родителем Y и называется родительской зоной. Родительская зона обеспечивает доказательство достоверности открытого ключа дочерней зоны, подписывая ее ключ. Данная подпись хранится в ресурсной записи, называемой Delegation Signer ( DS ). Родительская зона также должна быть подписанной зоной, потому что неподписанная зона не умеет создавать подписи. Таким образом, подписанная зона может быть одного из следующих типов.

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

Для глобально безопасной зоны существуют дополнительные задачи. Чтобы обеспечить возможность создания цепочки доверия, зона должна безопасным образом (внешним по отношению к сервисам DNS) передать родительской зоне свой открытый ключ (KSK-public). Затем родитель создает хэш этого открытого ключа дочерней зоны и хранит его в своей зоне в виде новой ресурсной записи, называемой DS. Он подписывает эту ресурсную запись DS, создавая ресурсную запись RRSIG. Родителю передается ключ KSK, а не ключ ZSK, потому что в противном случае происходило бы следующее. Всякий раз, когда зона изменяет свой ZSK, ее родитель должен был бы быть уведомлен о новом ключе. При этом родителю приходилось бы создавать новую ресурсную запись DS и снова подписывать ее. Для уменьшения подобной административной нагрузки родительской зоне передается ключ KSK. KSK используется для подписывания только ресурсных записей DNSKEY ; все остальные ресурсные записи в зонном файле подписываются ZSK. KSK является тем ключом, который опубликовывается у родителя. Родитель создает ресурсную запись DS, содержащую ключ KSK дочерней зоны, создает подпись для данного KSK и размещает ее в ресурсной записи RRSIG. Ключ KSK создается достаточно большим (например, 2048 бит) по сравнению с ключом ZSK, который может быть, например, длиной 1024 бит и, следовательно, должен изменяться менее часто.

Просуммируем дополнительные задачи, которые имеют место при глобально безопасной зоне.

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

Для понимания обработки аутентифицированной ссылки, которая находится у родителя, необходимо посмотреть, как обрабатывается обычная ссылка DNS. В обычном DNS-запросе зона, которая не имеет авторитетной информации, относящейся к запросу для доменного имени в дочерней зоне, предоставляет ссылку, указывая множество ресурсных записей NS и соответствующие относящиеся к ним ресурсные записи (ресурсные записи, которые содержат IP-адреса серверов, указанных в ресурсных записях NS). При обычной обработке DNS-запроса следование по этим ссылкам будет следующим шагом обработки. Однако данный процесс является недостаточным с точки зрения установления цепочки доверия; информация о множестве ресурсных записей NS и связанных с ними ресурсными записями не может считаться аутентичной, потому что они не подписаны закрытым ключом аутентичного источника. Аутентификацию данной информации о ссылке родитель предоставляет криптографическим способом с помощью ресурсной записи DS.

Рассмотрим пример того, как поддерживающий DNSSEC resolver проверяет правильность DNS-ответа от подписанной зоны example.ru. Resolver, следуя по своей цепочке доверия, начинающейся от доверенного anchor’а, аутентифицирует открытый ключ для зоны .ru и тем самым доверяет ему. Следовательно, он доверяет ресурсным записям NS и DS в зоне .ru. Из ресурсной записи NS и связанных с ней ресурсных записей resolver определяет, что авторитетный name-сервер для example.ru есть ns.example.ru, и он также знает его IP-адрес. Используя данную информацию, он идет на ns.example.ru и получает ключ KSK для example.ru из его множества ресурсных записей DNSKEY. Он вычисляет хэш данного ключа и сравнивает его с хэшем в ресурсной записи DS его родительской зоны .ru. Равенство этих двух хэшей означает, что ссылка из .ru зоны на example.ru зону аутентифицирована; аутентифицирован также и ключ KSK example.ru зоны. Так как ключ ZSK подписан ключом KSK example.ru, resolver может получить ключ ZSK example.ru аутентифицированным способом. Так как ключ ZSK подписывает все ресурсные записи в example.ru, действительность любого подписанного ответа из данной зоны может быть определена с использованием ключа ZSK, который уже аутентифицирован.

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

Безопасность ответов кэширующего name-сервера

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

Когда поддерживающий DNSSEC кэширующий name-сервер получает запрос от не поддерживающего безопасность resolver’а, resolver получает как безопасные, так и небезопасные данные из кэша сервера. Так как данный запрос передан небезопасным способом, ресурсная запись DNSSEC не включается в ответ, тем самым применяется только обычная обработка DNS.

Поддерживающие DNSSEC resolver’ы получают либо безопасные, либо и безопасные, и небезопасные данные от поддерживающего DNSSEC кэширующего сервера с установленным в заголовке ответа битом. Этот Authenticated Data ( AD ) бит в заголовке указывает, что множества ресурсных записей в ответе прошли или не прошли все проверки безопасности, выполненные кэширующим name-сервером. Клиент может решить, полагаться ли ему на данную проверку или выполнить свое собственное множество проверок безопасности.

В некоторых случаях клиент может захотеть получить фальшивые данные от кэширующего name-сервера. В этом случае клиент посылает запрос с установленным Checking Disabled ( CD ) битом в заголовке DNS-сообщения. Это дает поддерживающему DNSSEC кэширующему name-серверу команду отвечать фальшивыми данными из BAD кэша. Клиент должен затем выполнить свою собственную проверку множества ресурсных записей в ответе. В таких типах ответов сервер не устанавливает AD бит, указывая, что ответ не прошел все проверки безопасности, выполняемые сервером.

Дополнительные меры защиты для DNS Query / Response

Спецификации DNSSEC для защиты транзакций DNS Query / Response определяет следующие типы ответов:

Так как большинство запросов первоначально исходят от stub resolver’а (от имени ПО клиента, требующего доступ к ресурсу в Интернете), защита сообщения DNS ответа должна также обеспечиваться для stub resolver’а от рекурсивного name-сервера. Способ обеспечения защиты на этом участке, который часто называется DNS "last hop", определяется природой stub resolver’а и топологией сети.

Stub resolver может:

Большинство stub resolver’ов, существующих сегодня, не поддерживают DNSSEC. Другими словами, они не имеют возможности проверить цифровые подписи, связанные с полученными множествами ресурсных записей, и также не могут отличить аутентифицированный ответ (проверяя его подпись) от неаутентифицированного ответа, передаваемого им их локальными рекурсивными name-серверами. Чтобы создать полную end-to-end защиту для DNS Query / Response, эти типы stub resolver’ов как минимум должны иметь возможность выполнять аутентификацию источника и проверку целостности данных в ответах, пришедших от рекурсивного name-сервера, который предоставляет им сервис разрешения имен. Такая возможность может быть обеспечена использованием подхода НМАС, заданного в TSIG (где описано использование НМАС для защиты транзакций зонных пересылок и динамических обновлений). В качестве альтернативы защиту можно обеспечить с помощью других механизмов сетевой безопасности, таких как IPsec. Независимо от механизма, используемого для обеспечения безопасности канала "last hop" (от рекурсивного name-сервера к stub resolver), данная возможность также должна присутствовать в поддерживающих DNSSEC и не проверяющих правильность ответа stub resolver’ах в дополнение к не поддерживающим DNSSEC stub resolver’ам. Поддерживающий DNSSEC, но не проверяющий правильность ответа stub resolver может увеличить доверие к этому ответу, проверяя значение AD бита в заголовке сообщения в полученном ответе. Данные типы stub resolver’ов могут затем использовать этот бит в качестве признака того, что рекурсивный name-сервер имеет возможность проверять действительность подписей для данных в ответе.

В некоторых ситуациях установление доверенного пути между stub resolver’ами и рекурсивными name-серверами не предоставляется возможным. Примером является ситуация, когда рекурсивный name-сервер не расположен в административном домене предприятия, а выполняется у провайдера. В такой ситуации end-to-end защита может быть обеспечена только при наличии поддерживающего DNSSEC stub resolver’а. Поддерживающий DNSSEC stub resolver может уведомить локальный рекурсивный name-сервер, что он хочет сам выполнить проверку действительности подписи, установив Checking Disabled ( CD ) бит в свои сообщения запроса.

Динамические обновления в поддерживающей DNSSEC-зоне

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

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

Рассмотрим содержимое ресурсных записей NSEC для зоны example.ru. Предположим следующую каноническую упорядоченность доменных имен в зоне:

example.ru
	IN	SOA	 ns.example.ru admin.example.ru (12985 3600 2700 800 3600)
	IN	RRSIG ( SOA )
	IN	NS	 ns.example.ru.
	IN	RRSIG ( NS )
	IN	MX	 mail.example.ru.
	IN	RRSIG ( MX )
marketing.example.ru
	IN	A	192.253.101.9
	IN	RRSIG ( A )
	IN	MX	 mail.example.ru
	IN	RRSIG ( MX )
sales.example.ru
	IN	NS	 ns.example.ru.
	IN	RRSIG ( NS )
www.exapmle.ru
	IN	A	 192.253.101.10
	IN	RRSIG ( A )

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

example.ru	IN	NSEC	marketing.example.ru	(SOA NS MX RRSIG NSEC)
marketing.example.ru	IN	NSEC	sales.example.ru	(A MX RRSIG NSEC)
sales.example.ru	IN	NSEC	www.example.ru	(NS RRSIG NSEC)
www.example.ru	IN	NSEC	example.ru	(A RRSIG NSEC)

Заметим, что существует столько NSEC -ресурсных записей, сколько уникальных доменных имен в зоне. NSEC -ресурсная запись, чье имя есть example.ru, ссылается на следующий домен в каноническом порядке (например, marketing.example.ru ). То же самое выполняется для NS-ресурсных записей, относящихся к доменам marketing.example.ru и sales.example.ru. NSEC -ресурсная запись, относящаяся к последнему доменному имени (т.е, www.example.ru ), ссылается на первое доменное имя в зоне (т.е. example.ru ).

Когда получен запрос для " package.example.ru IN A " (т.е. запрос для зоны, которой не существует), авторитетный сервер отвечает NSEC множеством ресурсных записей, доказывая, что имя не существует в зоне. В данном случае ответ от сервера будет состоять из обычного DNS-ответа, указывающего, что имя не существует, и следующей информации:

Модификации NSEC -ресурсных записей, выполняется при следующих операциях:

Добавление нового типа ресурсной записи в существующий домен

Предположим, что новый почтовый хост добавлен в домен www.example.ru. Такое изменение требует добавления MX-ресурсной записи к данному имени домена. Следовательно, NSEC -ресурсная запись для www.example.ru должна быть модифицирована следующим образом:

www.example.ru	IN	NSEC	example.ru	( A MX RRSIG NSEC )

Удаление некоторого типа ресурсной записи из существующего домена

Предположим, что предприятие example.ru решило, что больше не требуется отдельного почтового сервера для сотрудников отдела маркетинга. Такое изменение требует удаления почтового сервера ( RRType = MX ) из домена marketing.example.ru. Модифицированная NSEC -ресурсная запись теперь выглядит следующим образом:

marketing.example.ru	IN	NSEC	sales.example.ru	(A RRSIG NSEC)

Добавление нового имени домена в зону

Чтобы заказчики могли работать в режиме on-line, предприятие решило добавить отдельный домен websales.example.ru. Также был добавлен отдельный name-сервер и множество новых хостов. Этот новый домен требует следующих изменений в зонном файле:

Удаление домена из зоны

Предположим, предприятие решило, что все продажи теперь будут осуществляться только через Интернет. Так как хосты были созданы для выполнения данной функции в новом домене websales.example.ru, хосты в домене sales.example.ru больше не нужны. Поэтому все ресурсные записи, принадлежащие домену, должны быть удалены из зоны. Данное изменение включает следующие операции:

Краткое резюме

Перечислим основные принципы, которым необходимо следовать при развертывании DNSSEC.

  1. Размер ключа KSK должен быть достаточно большим, потому что это имеет большее влияние на безопасность DNS при компрометации ключа KSK. Период действительности (период обновления) для ключа ZSK должен быть достаточно коротким, потому что существует больший риск для угадывания ключа.
  2. Закрытые ключи, соответствующие и ZSK, и KSK, не должны храниться в поддерживающем DNSSEC первичном авторитетном сервере, если name-сервер не должен выполнять динамических обновлений. Если динамические обновления поддерживаются, закрытый ключ ZSK, должен храниться на name-сервере с соответствующим управлением доступом на уровне файла и директории или в криптографически защищенном виде.
  3. Создание подписи с использованием ключа KSK должно выполняться в режиме off-line с использованием ключа KSK-private, хранящегося off-line; затем множество ресурсных записей DNSKEY вместе с его RRSIG -ресурсной записью должны быть записаны в зонный файл первичного авторитетного name-сервера.
  4. Хранение ключа ZSK-private и создание подписи с использованием данного ключа должно выполняться в режиме off-line; множество ресурсных записей вместе с RRSIG -ресурсными записями может затем быть записано в зонный файл первичного авторитетного name-сервера. Исключением является случай, когда name-сервер поддерживает динамические обновления. При этом ключ ZSK-private должен располагаться на name-сервере.

Минимизация раскрываемой DNS-информации

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

Существует вероятность, что атакующий попытается получить информацию о локальной сети с использованием сервисов DNS и использует данную информацию для выполнения атаки. Некоторые типы информации, например, IP-адреса публичных серверов, предназначены для того, чтобы быть доступными всем. Что касается другой информации, администратору DNS рекомендуется выполнить определенные действия при создании зонного файла, которые бы сводили раскрытие локальной сети к минимуму. Данный процесс должен быть выполнен до подписывания зоны. Информация о сети, которая должна быть абсолютно закрытой, не должна публиковаться в DNS совсем.

Выбор значений параметров в SOA RR

Первое действие, которое должен предпринять администратор DNS, – это гарантировать, что значения данных ресурсной записи SOA являются корректными. Значения в данной ресурсной записи определяют взаимодействие между первичным и вторичными серверами в зоне, а именно, с какой периодичностью вторичные серверы должны выполнять зонные пересылки с первичного сервера. Эти данные также содержат минимальное значение TTL, которое говорит клиентским resolver’ам, как долго находятся данные в кэше. Смысл этих полей следующий:

Рекомендации:

  1. Значение refresh в SOA ресурсной записи зоны должно быть выбрано в зависимости от частоты обновлений. Если зона подписана, значение refresh должно быть меньшим, чем период действительности RRSIG.
  2. Значение retry в SOA ресурсной записи зоны должно равняться 1/10 от значения refresh.
  3. Значение expire в SOA ресурсной записи зоны должно быть от 2 до 4 недель.
  4. Минимальное значение TTL должно быть между 30 секундами и 24 часами, чтобы гарантировать, что устаревшие множества ресурсных записей будут очищены из кэшей клиентов.

Утечка информации и Informational RRTypes

Существует несколько типов ресурсных записей, которые сообщают информацию о сети, хостах или сервисах. К этим ресурсным записям относятся Responsible Person ( RP ) запись, Host Information ( HINFO ) запись, Location ( LOC ) запись и различные Text рекурсивные записи ( TXT ). Хотя данные типы записей предназначены для информирования пользователей, не имеющих плохих намерений, они также позволяют атакующему получить информацию о хостах в локальной сети для того, чтобы попытаться использовать их уязвимости. Например, атакующий может запросить HINFO -записи, просмотреть перечисленные хосты и определить ОС и платформы, которые имеют известные уязвимости. Следовательно, следует быть очень осторожным, включая данные типы записей в зонный файл.

Рекомендации:

  1. Администратор DNS не должен включать в зонный файл или во внешний view зоны (если используется split DNS) HINFO, RP, LOC или другие типы ресурсных записей, которые могут разглашать информацию, полезную атакующему.
  2. Администратор DNS должен просмотреть все данные, которые содержатся в ресурсной записи TXT, для проверки возможной утечки информации, перед тем как добавлять их в зонный файл.

Использование периода действительности RRSIG для минимизации последствий компрометации ключа

Самым лучшим способом минимизировать последствия компрометации ключа является ограничение периода действительности RRSIG как в самой зоне, так и в родительской зоне. Это позволяет ограничить время, в течение которого атакующий может использовать скомпрометированный ключ для подделки ответов. Атакующий, который имеет скомпрометированный ключ ZSK, может использовать данный ключ только в течение интервала действительности подписи, созданной ключом KSK. Атакующий, который скомпрометировал ключ KSK, может использовать его только в интервале, указаном в DS -ресурсной записи, которая является точкой делегирования у родителя. Но если определить данный период действительности коротким, то потребуется частое переподписывание в зонном файле родителя.

Для минимизации влияния скомпрометированного ключа ZSK следует установить период действительности подписи RRSIG, охватывающей DS -ресурсные записи, в диапазоне от нескольких дней до одной недели. Данное переподписывание не требует частого обновления родительского ключа ZSK, а плановое обновление ключа ZSK должно выполняться через фиксированные интервалы.

Рекомендации:

  1. Период действительности для RRSIG, охватывающих множество ресурсных записей DNSKEY зоны, должен быть в диапазоне от двух дней до одной недели. Такое значение помогает уменьшить период существования уязвимости, который может возникнуть в результате компрометации ключа.
  2. Зона, имеющая делегированную дочернюю зону, должна иметь период действительности от нескольких дней до одной недели для RRSIG, охватывающей DS-ресурсную запись для делегированной дочерней зоны. Такое значение помогает снизить период уязвимости в дочерней зоне, возникший в результате компрометации ее ключа KSK.

Администрирование операций для обеспечения безопасности сервисов DNS

Мы рассмотрели операции развертывания и использования возможностей DNSSEC для защиты транзакций запросов и ответов DNS. Рассмотрим операции администрирования, которые должны выполняться периодически, в поддерживающей DNSSEC зоне.

Плановое обновление ключа (время жизни ключа)

Ключи, используемые для подписывания зоны ( ZSK ), и ключи подписывания ключа ( KSK ) должны периодически меняться, потому что они становятся уязвимыми после определенного периода использования. Компрометация закрытого ключа означает, что любой хост может подделать данные зоны, подписывая ложное множество ресурсных записей закрытым ключом, тем самым полностью аннулируя цели, которые преследовались при подписывании зонного файла. Обновление ключа может быть плановым (плановое обновление) или может иметь место в результате каких-либо чрезвычайных обстоятельств (чрезвычайное обновление). Чрезвычайное обновление происходит по одной из следующих причин:

При плановом обновлении ключа период времени, после которого ключи должны быть изменены, определяется несколькими факторами:

Основываясь на этих факторах, в каждой зоне определяется частота обновления ключей для ZSK и KSK. Напомним, что ключ KSK (KSK-private) используется для подписывания только множества ресурсных записей DNSKEY, в то время как ключ ZSK (ZSK-private) используется для подписывания всего зонного файла. Независимо от объема данных, ключ ZSK используется намного чаще, а именно, в следующих случаях:

Рекомендация:

Ключ KSK должен обновляться менее часто, чем ключ ZSK. Рекомендуемая частота обновления для ключа KSK равна одному году (при использовании RSA/MD5 с длиной ключа 2048 бит), а ключ ZSK должен обновляться каждый месяц (при использовании RSA/MD5 с длиной ключа 1024 бит).

Воздействие обновления ключа на оставшуюся часть DNS зависит от того, является ли безопасная зона локально безопасной или глобально безопасной (как часть цепочки доверия).

Обновление ключа в локально безопасной зоне

Зона, которая является локально безопасной имеет ключ ZSK и, возможно, ключ KSK, который сконфигурирован в resolver’ах клиента как доверенный ключ. Определенные сложности возникают, когда любой из ключей обновляется, хотя наличие ключа KSK для локально подписанной зоны делает обновление ключа ZSK более легким. Когда зона изменяет свой ключ ZSK и имеется ключ KSK, который не изменяется, проблема состоит в том, что следует ввести новый ключ, в то время как старый ключ может находиться в некоторых удаленных resolver’ах или кэшах name-серверов.

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

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

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

При обновлении KSK безопасная зона может не знать, какие resolver’ы хранят открытый ключ в качестве доверенного anchor’а. Если сетевой администратор имеет внешний способ (хотя бы по e-mail) контактирования с администраторами resolver’ов, которые хранят открытые ключи в качестве доверенных anchor’ов, сетевой администратор должен послать соответствующее уведомление и установить безопасные способы распространения нового доверенного anchor’а. Если такого внешнего способа не существует, администратор ничего не сможет сделать, за исключением предварительного опубликования нового ключа KSK, давая администраторам resolver’ов достаточно времени для получения нового ключа KSK.

Обновление ключа в глобально безопасной зоне

Глобально безопасная зона использует два множества ключей: ZSK и KSK.

Обновление ключа ZSK в глобально безопасной зоне

Операции, выполняемые при обновлении ключа ZSK в глобально безопасной зоне не отличаются от тех, которые выполняются при обновлении ключа ZSK в локально безопасной зоне.

Обновление ключа KSK в глобально безопасной зоне

Ключ KSK (KSK-public) является ключом, для которого родитель данной безопасной зоны обеспечивает доверие. Для этого он использует ресурсную запись DS, которая содержит хэш дочернего ключа KSK. Делегирующий родитель подписывает данную ресурсную запись DS своим собственным ключом ZSK для того, чтобы отношения доверия осталось в силе. Для обновления ключа KSK дочерней зоны следует выполнить следующее:

Для того чтобы родитель мог аутентифицировать новый ключ KSK (будем называть его KSK2), основываясь на существующей цепочке доверия, дочерняя зона при выполнении обновления ключа создает DNSKEY -множество ресурсных записей, используя DNSKEY -ресурсные записи существующего ключа вместе с новой DNSKEY -ресурсной записью для KSK2. Затем создаются две подписи (две RRSIG -ресурсные записи) – одна с использованием существующего ключа KSK, другая с использованием нового ключа KSK2. Затем родителю посылается заново созданное DNSKEY множество ресурсных записей вместе с RRSIG -ресурсными записями (во множественном числе, потому что существуют две подписи, соответствующие ключам KSK и KSK2). Множество ресурсных записей, посылаемое родителю, приведено ниже в некотором псевдоформате:

example.ru	DNSKEY	<key-id: 43543>	/* новый KSK*/
example.ru	DNSKEY	<key-id: 78546>	/* существующий KSK*/
example.ru	DNSKEY	<key-id: 98342>	/* ZSK*/
example.ru	RRSIG (DNSKEY)	<signer:example.ru signing-key:78546> 
                                    /* весь DNSKEY RRset подписан существующим KSK */
example.ru	RRSIG (DNSKEY)	<signer:example.ru signing-key:43543> 
                                   /* весь DNSKEY RRset подписан новым KSK */

При получении данной информации родитель выполняет следующие действия:

Когда данные задачи выполнены родителем, процесс обновления ключа KSK с точки зрения дочерней зоны полностью выполнен. Родительская зона должна затем обновить свой зонный файл с новой DS -ресурсной записью. Это аналогично обновлению любого другого множества ресурсных записей, которое включает создание, если требуется, любых новых RRSIG. Данное обновление может выполняться автоматически. Это означает, что старая DS -ресурсная запись может быть сброшена и одновременно новая DS -ресурсная запись добавлена. При этом будет выполнено только одно переподписывание в зоне.

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

Аварийное обновление ключа

Аварийное обновление ключа происходит тогда, когда один или более ключей в зоне ( ZSK или KSK компрометируются или закрытая компонента потеряна и необходимо выполнить переподписывание. Данный тип обновления не является плановым, поэтому велика вероятность разорвать цепочку аутентификации, если администратору зоны необходимо выполнить процесс обновления.

Аварийное обновление ZSK

Администратор DNS может обновить компрометированный ключ ZSK более быстро, чем компрометированный ключ KSK, потому что компрометация влияет только на зону. Возможность более быстрого обновления является другой причиной, по которой администратор зоны выполняет обновление ключа ZSK более часто. Если администратор зоны имеет новую DNSKEY -ресурсную запись, уже опубликованную в зоне в качестве части набора ключей зоны (первые три шага в процессе, который рассматривался ранее), следующий шаг зависит от того, является ли ключ компрометированным.

Если используемый в текущий момент ключ ZSK компрометирован, администратор зоны может немедленно заменить его на новый ключ. Нет необходимости ждать, чтобы истек период TTL, потому что новый ключ уже опубликован к данному моменту. Администратор может просто удалить старые RRSIG из зоны и переподписать новым ключом ZSK раньше, чем предполагалось сделать плановое обновление. Функционирование DNS должно продолжиться нормально после такого переподписывания, без разрыва цепочки аутентификации.

Если новый ключ ZSK (следующий ключ ZSK, который будет использоваться) компрометирован, его следует заменить немедленно в множестве ключей зоны. Такая замена также может выполниться автоматически, потому что новый ключ не использовался для создания каких-либо RRSIG ; должно быть переподписано только множество ключей зоны. Также возможно просто удалить компрометированный ключ и заменить его новым ключом ZSK за одно обновление.

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

Аварийное обновление KSK

Когда компрометирован ключ KSK зоны, единственным действием должно быть инициирование его обновления. Данное обновление, однако, не аналогично процессу планового обновления ключа KSK. Должен существовать способ оповестить администратора родительской зоны, что старый ключ KSK компрометирован и не следует принимать никаких сообщений об обновлении ключа KSK с использованием данного ключа. Замененный ключ должен быть передан и верифицирован с использованием некоторого безопасного канала, чтобы гарантировать идентификацию дочерней зоны, что может включать один или более неDNSSEC методов аутентификации. Данный процесс может быть аналогичен тому, который используется при установлении начального ключа KSK дочерней зоны.

Рекомендация:

Администратор DNS должен иметь способ аварийного контактирования с администратором родительской зоны, чтобы иметь возможность выполнять аварийное обновление ключа KSK.

Переподписывание зоны

Зонный файл переподписывается (т.е. заново создаются RRSIG -ресурсные записи), в следующих ситуациях:

Существуют две стратегии для переподписывания данных зоны.

Рекомендации:

  1. Периодическое переподписывание должно быть запланировано до истечения действительности RRSIG -ресурсных записей, существующих в зоне. Это уменьшит риск того, что подписанная зона будет фиктивной в результате истекших подписей.
  2. Серийный номер в SOA ресурсной записи должен быть увеличен перед переподписыванием зонного файла. Если данная операция не сделана, вторичные name-серверы могут не получить новые подписи, потому что они выполняют обновление исключительно на основе соответствия серийного номера SOA. В результате этого некоторые поддерживающие безопасность resolver’ы не будут иметь возможность проверять подписи (и таким образом иметь безопасный ответ), а другие — будут.

Лекция 9. Обеспечение безопасности web-серверов

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

Введение

В самом общем виде web можно разделить на два основных компонента: web-серверы — они являются приложениями, которые формируют информацию, доступную по протоколу НТТР, и web-браузеры (клиенты) — они используются для доступа и показа информации, хранящейся на web-серверах. В основном будем рассматривать проблемы безопасности, касающиеся web-серверов.

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

Рассмотрим проблемы, связанные с безопасностью при инсталлировании, конфигурировании и сопровождении web-серверов. Перечислим кратко основные вопросы:

Здесь нужно придерживаться следующих принципов.

Следует реализовать соответствующую практику управления безопасностью и контроль за функционированием системы.

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

Для гарантирования безопасности web-сервера и поддержки сетевой инфраструктуры должны быть рассмотрены и реализованы следующие основные моменты:

Следует гарантировать, что ОС, на которой выполняется web-сервер, развернута, сконфигурирована и управляется в соответствии с требованиями безопасности.

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

Следует гарантировать, что ПО web-сервера развернуто, сконфигурировано и управляется в соответствии с требованиями безопасности, определенными в организации.

Во многих аспектах инсталляция и конфигурирование безопасности ПО web-сервера аналогично процессу инсталляции и конфигурирования ОС. Главным принципом, как и раньше, является инсталляция минимального числа требуемых сервисов web-сервера и удаление всех известных уязвимостей с помощью patche’ей и upgrade’ов. Если инсталляционная программа устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть удалены немедленно после завершения процесса установки. Обеспечение безопасности web-сервера как минимум должно включать следующие шаги:

Следует предпринять шаги для гарантирования того, что на web-сайте публикуется только корректное содержимое.

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

Следует гарантировать защиту web-содержимого от неавторизованного доступа или модификации.

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

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

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

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

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

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

Следует обеспечивать безопасность сетевой инфраструктуры для защиты web-серверов.

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

Следует гарантировать постоянное функционирование системы обеспечения безопасности.

Поддержание безопасного функционирования web-сервера требует постоянных усилий и наличия достаточного количества ресурсов. Поддержание безопасности web-сервера обычно включает следующие шаги:

Рассмотрим общие принципы, которые применимы ко всем системам.

Причины уязвимости web-сервера

Основные проблемы, связанные с безопасностью функционирования публично доступного web-сайта, возникают по следующим причинам:

Планирование развертывания web-сервера

При планировании развертывания web-сервера следует рассмотреть следующие пункты:

Безопасность лежащей в основе ОС

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

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

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

Безопасное инсталлирование и конфигурирование ОС

Применение Patch и Upgrade ОС

После того как ОС инсталлирована, следует применить все patches и upgrades для удаления известных уязвимостей. Все ОС, реализованные сегодня, имеют известные уязвимости, которые должны быть удалены перед использованием ОС в качестве хоста web-сервера. Для адекватного определения и корректирования этих уязвимостей web-администратор должен:

Удаление или запрещение ненужных сервисов и приложений

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

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

Удаление или запрещение ненужных сервисов усиливает безопасность web-сервера по следующим причинам:

При конфигурировании ОС следует применять принцип "запретить все, за исключением того, что явно разрешено" — это означает запретить и по возможности удалить все сервисы и приложения и затем выборочно разрешить те, которые требуются web-серверу. Также нужно по возможности установить минимальную конфигурацию ОС, которая требуется для приложения web-сервера. Если система инсталляции ОС предоставляет опцию "минимальная инсталляция", то нужно выбрать ее, потому что это минимизирует усилия, требуемые для удаления ненужных сервисов. Многие скрипты или программы типа uninstall не выполняют полного удаления всех компонент сервиса; следовательно, всегда лучше по возможности избегать инсталлирования ненужных сервисов.

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

Конфигурирование аутентификации пользователя в ОС

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

Конфигурирование компьютера для аутентификации обычно включает конфигурирование ОС, firmware и приложений на сервере, таких как ПО, которое реализует сетевой сервис. В специальных случаях для сайтов с высоким риском или хранящих важные данные можно также применять аппаратуру для аутентификации, например, токены или устройства с одноразовыми паролями. Использование аутентификационных механизмов, в которых аутентификационная информация является переиспользуемой (например, пароли) и передается в явном виде по сети, не рекомендуется, потому что информация может быть перехвачена и задействована атакующим для подделки под аутентифицированного пользователя.

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

Как отмечалось ранее, нарушитель, используя сетевые сниферы, может легко перехватить переиспользуемые пароли, передаваемые по сети в явном виде. Вместо этого следует использовать менее уязвимые технологии аутентификации и шифрования, такие как SSH и SSL/TLS.

Управление ресурсами на уровне ОС

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

Альтернативные платформы для web-сервера

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

Trusted ОС

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

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

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

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

Использование Appliances для web-сервера

Относительно недавние разработки в области web-серверов привели к появлению так называемых web Appliances. Web Appliances является комбинацией ПО и аппаратуры, которая разработана, чтобы быть "plug-and-play" web-сервером. Эти Appliances используют упрощенную ОС, которая оптимизирована для поддержки web-сервера. Упрощенная ОС обеспечивает безопасность, минимизируя возможности, сервисы и опции, которые не являются необходимыми для web-приложений. ПО web-сервера в таких системах часто заранее инсталлировано и заранее сконфигурировано с точки зрения безопасности.

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

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

Некоторые вопросы, которые следует рассматривать при принятии решения о покупки web Appliances:

Специально усиленные (pre-hardened) ОС и web-серверы

Сегодня распространяется всё возрастающее число специально усиленных ОС и пакетов web-сервера. Эти пакеты включают ОС и ПО web-сервера, которые модифицированы и заранее сконфигурированы для обеспечения большой безопасности. Некоторые из этих пакетов содержат и аппаратную платформу, другие являются ПО, которое состоит только из ОС и ПО web-сервера. Эти дистрибутивы обычно основаны на специально усиленной и/или модифицированной ОС общего назначения (например, Linux, Unix и, реже, Windows), которая специально разработана для поддержки безопасного web-сервера. Приложение web-сервера также часто основано на усиленном и/или модифицированном обычном ПО web-сервера например, Apache или IIS). Эти пакеты зачастую включают большее число опций безопасности и разработаны для более легкого конфигурирования с помощью заранее cкомпилированных скриптов и GUIs. Хотя все пакеты различны, они обычно обеспечивают какие-либо из следующих возможностей:

Эти типы систем должны быть рассмотрены организацией, которая понимает важность угроз и/или имеет важные данные на web-сайтах (например, правительственные организации, банки и т.п.). Такие пакеты доступны от некоторых основных производителей аппаратуры и ПО, а также от некоторых специализированных производителей.

Некоторые вопросы, которые следует рассмотреть при приобретении усиленного web Appliance.

Тестирование безопасности операционной системы

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

Список действий для обеспечения безопасности ОС, на которой выполняется web-сервер

Составление плана конфигурации и развертывания web-сервера.

Выбор подходящей ОС для web-сервера.

Применение patch’ей и upgrade’ов ОС.

Удаление или запрещение ненужных сервисов и приложений.

Конфигурирование аутентификации пользователей в ОС.

Тестирование безопасности ОС.

Безопасное инсталлирование и конфигурирование web-сервера

После того как ОС инсталлирована и сделана безопасной, следует инсталлировать выбранное ПО web-сервера. Перед началом данного процесса следует прочитать документацию производителя и понять, какие опции доступны при инсталляции. Также следует посетить web-сайт производителя или web-сайт базы данных уязвимостей, такой как ICAT метабаза (http://icat.nist.gov), для определения всех известных уязвимостей и соответствующих patches, которые должны быть инсталлированы или сконфигурированы как часть процесса установки. Только после завершения этих предварительных шагов следует начать инсталляцию. Будем обсуждать только общие процедуры инсталляции и конфигурирования.

Безопасное инсталлирование web-сервера

Во многих аспектах безопасное инсталлирование и конфигурирование приложения web-сервера аналогично инсталляции и конфигурированию ОС. Основной принцип состоит в том, чтобы инсталлировать минимальное количество требуемых сервисов web-сервера и исключить все известные уязвимости с помощью patches или upgrades. Если программа инсталляции устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть немедленно удалены после завершения процесса. При инсталляции web-сервера должны быть выполнены следующие шаги:

  1. Инсталлировать ПО сервера на выделенный хост.
  2. Инсталлировать минимально требуемые сервисы Интернета.
  3. Применить все patches или upgrades для корректировки известных уязвимостей.
  4. Создать выделенный физический диск или логический раздел (отдельный от ОС и приложения сервера) для содержимого web.
  5. Удалить или запретить все web-сервисы, инсталлированные приложением web-сервера, но не требуемые (например, gopher, FTP и удаленное администрирование).
  6. Из корневой директории приложения web-сервера удалить все файлы, которые не являются частью web-сайта.
  7. Удалить всю документацию, а также примеры скриптов и выполняемого кода.
  8. Выполнить разного рода образцы безопасности или "hardening" скрипты, усиливающие безопасность web-сервера.
  9. Переконфигурировать баннер НТТР-сервиса (и других сервисов, если они используются), чтобы он не сообщал о типе и версии web-сервера и ОС. Это может быть выполнено в IIS использованием свободного Microsoft IIS Lockdown Tool и в Apache посредством "ServerTokens" директивы.

Конфигурирование управления доступом

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

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

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

Разграничение доступа для ПО web-сервера

Первый шаг в конфигурировании управления доступа состоит в гарантировании того, что web-сервер выполняется только от имени пользователя и группы, которые специально созданы для этого и имеют очень ограниченные права доступа. Таким образом, должны быть введены специальные идентификаторы пользователя и группы, используемые исключительно ПО web-сервера. Новый пользователь и новая группа должны быть уникальными и независимыми от всех остальных пользователей и групп. Это необходимо для реализации управления доступом, описанного далее. Хотя сервер может начинать выполняться как root (Unix) или system/administrator (Windows NT/2000/XP) для привязки к ТСР-порту 80 и/или 443 (используемому для предоставления НТТР и НТТРS-сервисов соответственно), не следует допускать, чтобы сервер продолжал выполняться на данном уровне доступа.

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

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

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

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

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

Если максимальное число открытых соединений (или соединений, которые являются полуоткрытыми, – это означает, что первая часть ТСР-рукопожатия завершилась успешно) установить в наименьшее число, атакующий может легко израсходовать доступные соединения ложными запросами (часто называемыми SYN flood). Установка в максимум данного числа может смягчить эффект такой атаки, но ценой расходования дополнительных ресурсов. Заметим, что это является проблемой только тех web-серверов, которые не защищены firewall’ом, останавливающим SYN flood атаки. Большинство современных firewall’ов защищают web-сервер от SYN flood атаки, прерывая ее прежде, чем она достигнет web-сервера.

Управление доступом к директории содержимого web-сервера

Не следует использовать ссылки, aliases или shortcuts из дерева директории содержимого web на директории или файлы, расположенные где-то еще на хосте или сетевой файловой системе. Лучше всего запретить возможность ПО web-сервера следовать по ссылкам и aliases. Как указывалось раньше, лог-файлы и конфигурационные файлы web-сервера должны размещаться вне дерева директории, которое определено для публичного содержимого web.

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

Большинство производителей ПО web-сервера предоставляют директивы или команды, которые позволяют web-администратору ограничить доступ пользователя к файлам содержимого web-сервера. Например, ПО web-сервера Apache предоставляет директиву Limit, которая позволяет web-администратору указать, какие возможности доступа (такие как New, Delete, Connect, Head и Get ) связаны с каждым файлом web-содержимого. Директива Require в Apache позволяет web-администратору ограничивать доступ к содержимому аутентифицированными пользователями или группами.

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

В большинстве случаев подобные директивы web-сервера должны быть запрещены. НТТР определяет, что URL, заканчивающийся символом слеша, должен трактоваться как запрос на перечисление файлов в указанной директории. Web-сервер должен запрещать отвечать на такие запросы, даже если возможно публичное чтение всех файлов директории. Такие запросы часто указывают на попытку разместить информацию способами, отличными от тех, которые допускает web-администратор. Пользователи могут пытаться это делать, если у них возникают трудности в навигации по сайту или если ссылки в web-страницах обрываются. Нарушитель может пытаться это сделать, чтобы разместить информацию, скрытую интерфейсом сайта. Web-администраторы должны исследовать запросы данного типа, найденные в лог-файлах web-сервера.

Управление влиянием web Bots

Web bots (что тоже самое, что и агенты или spiders) есть прикладное ПО, используемое для сбора, анализа и индексирования web-содержимого. Web bots используются многими организациями в разных целях. Некоторые примеры:

Bots имеют негативные последствия, потому что:

В принципе, существует способ для web-администратора повлиять на поведение большинства bots на своем web-сайте. Была создана серия соглашений, называемая Robots Exclusion Standard (REP). Хотя REP не является официальным стандартом Интернета, он поддерживается большинством хорошо написанных и имеющих благие цели bots, включая те, которые используются в большинстве поисковых систем.

Web-администраторы, которые хотят ограничить деятельность bots на своих web-серверах, должны создать тестовый файл, называемый robots.txt. Файл должен всегда иметь данное имя и располагаться в корневой директории web-сервера. Кроме того, допускается только один такой файл на весь web-сайт. Заметим, что файл robots.txt является стандартом, который на добровольной основе должен поддерживаться программистами bots. Не существует обязательного требования использовать его. Таким образом, вредоносные bots, такие как EmailSiphon и Cherry Picker, игнорируют данный файл.

Robots.txt является простым тестовым файлом, который содержит определенные ключевые слова и спецификации файла. Каждая строка файла либо является пустой, либо состоит из единственного ключевого слова и относящейся к нему информации. Ключевые слова используются для того, чтобы сказать роботам, какую часть web-сайта следует исключить из их анализа.

Допустимы следующие ключевые слова:

Заметим, что /do будет соответствовать любой директории, начинающейся с "/do" (например, /do, /document, /docs и т.п.), в то время как /do/ соответствует только директории, называемой "/do/".

Web-администратор может также указать конкретные файлы. Например, он может указать /mydata/help.html для предотвращения доступа только к одному файлу.

Значение "/" указывает, что ничего на web-сайте не разрешено для доступа указанных в user-agent bots.

Должна существовать по крайней мере одна запись на каждый user-agent.

Существует много способов использовать файл robots.txt. Несколько простых примеров:

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

Использование программ проверки целостности файлов

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

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

  1. При создании первого варианта базы данных файлом проверки целостности требуется гарантия, что система находится в безопасном состоянии. В противном случае могут быть созданы криптографические хэши скомпрометированной системы, и тем самым создастся ложное чувство безопасности у тестирующего.
  2. База данных контрольных сумм должна храниться off-line, чтобы атакующий не мог скомпрометировать систему и модифицировать базу данных с целью спрятать следы атаки.
  3. Программа проверки целостности файлов может также создавать ложные позитивные предупреждения. Каждое изменение файла и каждый системный patch изменяет файл и, следовательно, требуется изменить базу данных контрольных сумм. Таким образом, держать базу данных актуальной может быть непросто.

Однако, даже если программа проверки целостности выполняется только один раз (при первой инсталляции системы), она может быть полезна для определения того, какие файлы были модифицированы в случае предполагаемой компрометации. Наконец, атакующий может так модифицировать файл, что использование 32-битной циклической контрольной суммы (Cyclic Redundancy Check – CRC) не определит модификацию. Следовательно, рекомендуются более сильные алгоритмы подсчета контрольных сумм для гарантирования целостности данных.

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

Список действий для безопасного инсталлирования и конфигурирования web-сервера

Безопасное инсталлирование web-сервера.

Конфигурирование управления доступом web-сервера со стороны ОС.

Конфигурирование безопасной директории web-содержимого.

Использование программ проверки целостности.

Лекция 10. Безопасность web-содержимого

Рассматриваются принципы обеспечения безопасности содержимого web-сервера. Перечислены различные технологии создания активного содержимого на стороне клиента и сравнивается создаваемая ими степень риска. Изучаются различные технологии создания динамических страниц на стороне сервера и связанные с ними уязвимости.

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

Опубликование информации на web-сайтах

Политика опубликования в web должна содержать следующие элементы:

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

Публичный web-сайт обычно не содержит следующую информацию:

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

Для гарантирования согласованного подхода организация должна создать формальную политику и описать процесс определения того, какая информация публикуется на web-сервере. Во многих организациях за это отвечает офицер информационной службы (Chief Information Officer — CIO). Такой процесс должен включать следующие шаги.

  1. Определить информацию, которая должна публиковаться в web.
  2. Определить целевую аудиторию.
  3. Определить возможные негативные последствия опубликования информации.
  4. Определить, кто отвечает за создание, опубликование и сопровождение конкретной информации.
  5. Создать или отформатировать информацию для опубликования в web.
  6. Просмотреть информацию на предмет наличия чувствительных данных.
  7. Определить соответствующий доступ и управление безопасностью.
  8. Опубликовать информацию.
  9. Проверить опубликованную информацию.
  10. Периодически просматривать опубликованную информацию на соответствие текущим требованиям политики безопасности.

Областью web-содержимого, про которую часто забывают, является информация, находящаяся в исходном коде HTML-страницы. Она может быть просмотрена из web-браузера использованием опции меню view source code. Разработчики часто не придают значения содержимому исходного кода их HTML страниц, даже если этот код содержит чувствительную информацию. Он может, например, содержать указатели на контактную информацию и показывать части структуры директории web-сервера. Атакующие могут проанализировать не только очевидное содержимое web-сайта, но также и исходный код; следовательно, web-администраторы должны проверять создаваемые HTML страницы своего web-сервера.

Обеспечение безопасности технологий создания активного содержимого

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

Активное содержание на стороне клиента относится к интерактивным элементам, обрабатываемым web-браузером. Активное содержание может представлять серьезную угрозу для конечного пользователя. Например, оно может выполняться на машине клиента без явного разрешения пользователя. Существуют различные технологии создания активного содержимого. Некоторые наиболее популярные примеры включают ActiveX, Java, VBScript и JavaScript. Организации, рассматривающие разработку активного содержимого на стороне клиента, должны тщательно изучить риски для своих пользователей, так как использование активного содержания часто требует от пользователя понижения установок безопасности в своем web-браузере.

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

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

Специальная осторожность также требуется при загрузке заранее созданных скриптов или выполняемых файлов из Интернета. Многие web-администраторы хотят сэкономить время, загружая свободно доступный код из Интернета. Хотя удобства очевидны, риск тоже велик. Существует много примеров вредоносного кода, распространяемого данным способом. В общем случае, никакие скрипты третьих фирм не должны быть установлены на web-сервер до тех пор, пока код не просмотрит доверенный эксперт.

URLs и cookies

URLs являются технологией адресации в Интернете. Существует несколько проблем безопасности, связанных с URLs. Так как URLs посылаются в открытом виде, любые данные, которые хранятся внутри них, могут быть легко скомпрометированы. Например, URLs записываются во многие места, включая логи web-браузера (например, история браузера), логи прокси-сервера и логи НТТР referrer. Тем самым хранить чувствительные данные, такие, как имена пользователей и пароли или указатели на ресурсы сервера, в URL не следует. Безопасность через неясность не является хорошей практикой.

URLs часто содержатся в содержимом web. Хотя эти URLs могут не показываться в браузере пользователя, они могут быть легко раскрыты просмотром исходного кода. Следовательно, никакое содержимое web-страниц не должно включать чувствительных URLs, спрятанных в исходном коде. Многие атакующие осуществляют поиск чувствительных URLs в исходном коде, которыми могут быть:

Cookie – есть небольшой блок информации, которая может быть записана на жесткий диск пользователя, когда он посещает web-сайт. Цель cookies состоит в том, чтобы позволить серверу распознать конкретный браузер и, в конечном счете, пользователя при повторном посещении данного сервера. В сущности, они добавляют состояние в НТТР-протоколе, в котором состояние отсутствует. К сожалению, cookies обычно посылаются в явном виде и хранятся в явном виде на хосте пользователя, тем самым, они уязвимы для компрометации. Существуют уязвимости, например, в некоторых версиях IE, которые позволяют нарушителю удаленно собрать все cookies без оповещения об этом самого пользователя. Следовательно, cookies никогда не должны содержать данные, которые могут быть использованы непосредственно атакующим (например, аутентификационная информация, такая, как имя пользователя, пароль).

Существует два типа cookies.

Cookies, которые являются причиной большинства проблем, называются постоянные (persistent) cookies. Эти cookies могут использоваться для отслеживания деятельности пользователя в течение всего времени и на различных web-сайтах. Наиболее общее использование постоянных cookies состоит в сохранении соответствия информации о пользователях между сессиями. Часто запрещается использование постоянных cookies на публично доступных web-сайтах.

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

Уязвимости технологий активного содержимого на стороне клиента

Доступны различные варианты технологий активного содержимого на стороне клиента (web-браузера). Каждая технология имеет свои сильные и слабые места, но ни одна не является полностью безопасной. Обсудим некоторые наиболее популярные технологии активного содержимого и связанные с ними риски. (Однако следует помнить, что в каждый момент времени могут появиться новые технологии.) Web-администратор, который рассматривает развертывание web-сайта с возможностями, требующими технологии активного содержимого на стороне клиента, должен тщательно взвесить риски и преимущества данной технологии перед ее внедрением. В частности, web-администраторы должны помнить, что даже если содержимое сайта не представляет угрозы для пользователя, активное содержимое других сайтов может представлять угрозу и пользователь может забыть изменить установки безопасности в браузере на более безопасные.

Java – полнофункциональный, объектно-ориентированный язык программирования, который компилируется в платформонезависимый байт-код, выполняемый интерпретатором, называемым Java Virtual Machine (JVM). Результирующий байт-код может быть выполнен в том месте, где он был скомпилирован, или передан на другую поддерживающую Java платформу (например, передан с помощью HTML-страницы как апплет). Java используется для добавления функциональности в web-сайтах. Многие сервисы, предлагаемые популярными web-сайтами, требуют от пользователя иметь поддерживающий Java браузер. Когда web-браузер видит ссылки на Java-код, он загружает код и затем выполняет его, используя встроенную JVM.

Разработчики Java в большинстве случаев успешно решают проблемы безопасности. Язык программирования Java и окружение времени выполнения обеспечивают безопасность первоначально с помощью строгой типизации, при которой программа может выполнять определенные операции только для определенных типов объектов. Java придерживается так называемой модели безопасности sandbox, использующей изолирование памяти и методов доступа, а также поддержку нескольких независимых доменов выполнений. Код Java, такой, как web-апплет, заключается в sandbox, который разработан для предотвращения выполнения неавторизованных операций, например, просмотр или изменение файлов в файловой системе клиента и использование сетевых соединений в обход защиты файлов.

Тем не менее, апплеты хоста представляют угрозы для безопасности, даже если выполняются внутри sandbox. Апплеты хоста могут использовать различными способами не предназначенные для этого системные ресурсы или могут заставить пользователя выполнить различные нежелательные действия. Примеры нежелательных действий апплетов на хосте включают DoS-атаки, подделку e-mail адресов, вторжение в частную жизнь (например, экспорт идентификации e-mail адреса и информации о платформе) и инсталлирование люков (backdoors) в систему. Так как модель безопасности Java является более сложной, пользователю может быть трудно понять ее и управлять ею. Такая ситуация может увеличить риск.

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

Теоретически ограничение языка скрипта границами web-браузера должно обеспечивать относительно безопасное окружение. На практике это выполняется не во всех случаях. Многие основанные на браузерах атаки используют скриптовый язык в сочетании с конкретной уязвимостью безопасности. Основной источник проблем двойной: существование изъянов в реализации в выполняемом окружении и скрытое связывание браузера с соответствующей функциональностью, такой, как клиент e-mail. Подобные внедрения включают посылку списка истории URL на удаленный сайт и использование e-mail адреса пользователя для подделки почты. Возрастающее использование HTML и других языков разметки в качестве содержимого электронной почты и в сервисах push-технологий может открыть новые бреши для внедрения ошибок с использованием встроенных скриптов.

Visual Basic Script (VBScript) – язык программирования, разработанный Microsoft для создания скриптов, которые могут быть встроены в web-страницы, просматриваемые с помощью браузера IE. Netscape Navigator, однако, не поддерживает VBScript. Подобно JavaScript, VBScript является интерпретируемым языком, который дает возможность обрабатывать скрипты на стороне клиента. VBScript, который является подмножеством широко используемого Microsoft языка программирования Visual Basic, работает под управлением Microsoft ActiveX. Язык подобен JavaScript и имеет аналогичные риски.

ActiveX – это множество технологий от Microsoft, которые предоставляют инструментальные средства для связывания desktop-приложений с web. Управления ActiveX являются переиспользуемыми программными компонентными объектами, которые могут быть присоединены к e-mail или быть загруженными с web-сайта. Управления ActiveX также могут быть заранее инсталлированы на Windows-платформе. Web-страницы включают управления ActiveX, используя скриптовый язык или с помощью HTML-тега OBJECT.

Модель безопасности ActiveX значительно отличается от модели sandbox Java. Модель Java ограничивает апплет множеством безопасных действий. В противоположность этому, ActiveX не имеет ограничений на то, что он может делать. Вместо этого управляющие элементы ActiveX имеют цифровую подпись своего автора в соответствии с технологией, называемой Authenticcode. Цифровые подписи проверяются, используя сертификаты, выпущенные доверенными сертификационными центрами. Сертификационный центр должен гарантировать, что никакого опасного кода не будет сознательно распространено. Технология Authenticcode гарантирует, что управления ActiveX не могут быть распространены анонимно и что модификация управления может быть определена. Такой процесс сертификации, однако, не гарантирует, что поведение управления будет корректным.

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

Рассмотрим риск ActiveX в сравнении с другими популярными технологиями активного содержимого на стороне клиента.

Сравнение риска различных технологий на стороне клиента
Технология на стороне клиентаСтепень риска
JavaScript и VBScriptНизкая
Java-апплетыСредняя
Управление ActiveXВысокая
Уязвимости технологий создания содержимого на стороне сервера

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

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

Генераторы содержимого на стороне сервера могут создать уязвимости на сервере следующим образом:

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

Уязвимость может потенциально воздействовать на весь web-сервер. Хотя чаще всего подобное происходит в CGI-приложениях, другие интерфейсы и технологии разработки серверных приложений также имеют изъяны. CGI, как наиболее ранний и часто используемый стандарт, приобрел большее значение за последние годы, но то же множество уязвимостей существует при использовании аналогичных технологий web-разработки на стороне сервера.

Common Gateway Interface ( CGI ) – CGI-скрипты определяют механизм, используемый для взаимодействия web-сайтов с базами данных и другими приложениями на стороне сервера. Существуют различные методы обработки информации на стороне сервера, такие, как Microsoft ASP для IIS-сервера, Java-сервлеты и РНР, поддерживаемые большинством web-платформ, включая Apache и IIS. Перечислим основные требования, которым должна удовлетворять лежащая в основе ОС:

Server Side Includes ( SSI ) – ограниченный скриптовый язык на стороне сервера, поддерживаемый большинством web-серверов. SSI предоставляет множество динамических возможностей, например, включение текущего момента времени или даты последней модификации HTML файла, и является альтернативой использованию CGI-программ для выполнения определенных функций. Когда браузер запрашивает документ со специальным типом файла, таким, как .shtml, это говорит о том, что сервер должен обработать его перед тем, как послать клиенту (web-браузеру). Команды SSI встроены в HTML комментарии (к примеру, <!--#include file="standard.html"--> ). Сервер читает файл и ищет HTML комментарии, содержащие встроенные команды SSI. Когда он находит их, он заменяет часть исходного HTML-текста выходом найденной команды. Например, команда SSI, приведенная выше ( #include file ), заменяет весь SSI-комментарий содержимым другого HTML файла. Это позволяет показать соответствующий логотип или другую статическую информацию, подготовленную в другом файле, для реализации унифицированного способа изображения во всех web-страницах. Некоторые доступные директивы дают возможность серверу выполнить произвольные системные команды и CGI-скрипты, которые могут создать нежелательные эффекты на стороне сервера. Вот некоторые проблемы, которые возникают при использовании SSI:

Microsoft Active Server Pages (ASP) – скриптовая технология на стороне сервера от Microsoft, аналогичная SSI, может быть использована для создания динамических и интерактивных web-приложений. ASP-страница представляет собой образец HTML, который содержит скрипты на стороне сервера, выполняющиеся, когда браузер запрашивает ресурс *.asp от web-сервера. Web-сервер обрабатывает запрошенную станицу и выполняет любые команды скрипта перед посылкой полученного результата браузеру пользователя. Поддерживаются скриптовые языки Jscript и VBScript, но могут быть включены и другие скриптовые языки, которые поддерживаются ASP-совместимым интерпретатором. Например, доступны скриптовые средства для языков PERL, REXX и Python. Скриптовые возможности могут быть расширены использованием объектов ActiveX, которые могут быть разработаны в различных языках, скажем, Visual Basic, C++, COBOL и Java. Скрипт, который включает объект ActiveX, может создать объект и передать ему необходимые входные параметры. Заметим, что ActiveX является необязательной технологией и не требуется для ASP.

Некоторые проблемы, которые следует рассмотреть при использовании ASP:

Тем не менее, существуют определенные гарантии от переполнения буфера.

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

Основные особенности, которые следует учитывать при использовании Java сервлетов:

PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера. РНР обычно используется для извлечения данных из базы данных и представления их на web-странице. Большинство web-серверов на Windows и Unix поддерживают данный язык, и он широко применяется вместе с базой данных MySQL. Некоторые проблемы, которые следует учитывать при разработке на РНР:

При анализе или написании выполняемого активного содержимого или скрипта следует рассмотреть следующие вопросы:

При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий. Хотя история в полной мере и не отражает будущего возможного риска, на ее основе можно сделать вывод о том, какие технологии считаются более уязвимыми.

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

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

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

Список действий для обеспечения безопасности web-содержимого

Гарантировать, что никакая из следующих типов информации не доступна через публичный web-сервер.

Установить документированную формальную политику и процесс принятия решения об опубликовании web-содержимого.

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

Обсуждение безопасности активного содержимого на стороне клиента.

Обсуждение безопасности активного содержимого на стороне сервера.

Лекция 11. Технологии аутентификации и шифрования

Рассматриваются существующие технологии аутентификации и шифрования в web: BASIC-аутентификация, DIGEST-аутентификация, TLS/SSL-аутентификация. Изучается firewall прикладного уровня для web – ModSecurity: понятие регулярных выражений, основные возможности конфигурирования, способы задания правил (rules), действий (actions). Приводится примерная минимальная конфигурация.

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

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

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

Требования к аутентификации и шифрованию

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

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

Аутентификация, основанная на IP-адресе

Простейшим механизмом аутентификации, который поддерживается большинством web-серверов, является аутентификация по IP-адресу. Управление доступом основано на IP-адресе и/или имени хоста. Хотя это легко реализовать для небольших групп пользователей, аутентификация на основе адреса может быть громоздкой для web-сайтов, которые имеют большое число потенциальных пользователей (т.е. большинство публичных web-серверов). Такая аутентификация чувствительна к некоторым типам атак, включая подделку IP-адреса (IP-spoofing) и атаки на DNS. Данный тип аутентификации должен применяться только тогда, когда требуется минимальная безопасность, в противном случае она должна использоваться совместно с более сильными методами аутентификации.

Basic-аутентификация

Технология Basic -аутентификации использует определенную структуру директорий содержимого web-сервера. Все файлы в некоторой директории должны иметь одни и те же привилегии доступа. Пользователь, выполняющий запрос, предоставляет свою идентификацию и пароль для доступа к файлам в данной директории. Каждый производитель ПО web-сервера определяет свой собственный синтаксис для использования механизма Basic -аутентификации.

С точки зрения безопасности, основной недостаток данной технологии состоит в том, что пароль передается в явном виде без шифрования. Любой, кто имеет доступ к сетевому трафику, может извлечь пароль при сетевом просматривании. Более того, все web-содержимое передается в незашифрованном виде и, тем самым, также может быть перехвачено, что нарушает конфиденциальность. Этот недостаток может быть ликвидирован с использованием Basic -аутентификации совместно с SSL/TLS. Basic -аутентификация поддерживается стандартными web-браузерами. Она используется также для защиты информации от вредоносных bots.

Digest-аутентификация

Так как в Basic -аутентификации существуют определенные недостатки, в версии 1.1 протокола НТТР была введена Digest -аутентификация. Она использует для "опознания" пользователя механизм запроса / ответа (challenge / response), когда пользователю посылается nonce (случайное значение), который предназначен для использования вместе с ID и паролем. В данном случае информация, вводимая пользователем, соединяется вместе с переданным nonce и запрошенным URL, и вычисляется криптографический хэш, который затем посылается в качестве ответа.

Так как пароль пользователя не посылается в явном виде, он не может быть подсмотрен в сети. Nonce может быть сконструирован из информации о текущей дате и времени, поэтому replay-атаки также невозможны. Следовательно, Digest -аутентификация является более безопасной, чем Basic -аутентификация. К сожалению, все данные посылаются в явном виде (не шифруются), что является уязвимым для перехвата и изменения. Это ограничение можно обойти, используя Digest -аутентификацию вместе с SSL/TLS. Подобно Basic -аутентификации, Digest -аутентификация используется для защиты информации от вредоносных bots.

SSL/TLS

Протоколы SSL и TLS обеспечивают аутентификацию сервера и клиента и шифрование соединений. SSL был впервые введен компанией Netscape Communication в 1994 году и дважды пересматривался (последней версией SSL является версия 3). В 1996 году IETF основало рабочую группу TLS, чтобы определить протокол SSL в качестве стандарта Интернета. Протокол TLS версии 1.0 специфицирован в RFC 2246 в 1999 году и основывается на SSL версии 3. Можно считать, что SSL версии 3 и TLS версии 1 идентичны, поэтому они будут обсуждаться вместе. Протоколы TCP/IP управляют транспортом и роутингом данных в Интернете. Протоколы прикладного уровня, такие как НТТР, LDAP, IMAP, выполняются поверх TCP. SSL/TLS расположен между протоколом ТСР и протоколами прикладного уровня.

Возможности SSL/TLS

SSL/TLS обеспечивает следующие возможности.

Слабые места SSL/TLS

SSL/TLS присущи некоторые ограничения. Пакеты шифруются выше уровня ТСР, таким образом, информация на уровне IP не зашифрована. Хотя это и защищает передаваемые web-данные, при просмотре соединений SSL/TLS сессии можно определить как отправителя, так и получателя с помощью незашифрованной информации IP-адреса. Кроме того, SSL/TLS защищает только передаваемые данные. Он не шифрует данные, хранимые на конечных точках. Таким образом, при хранении данные становятся уязвимыми (например, база данных кредитных карт), если не предприняты дополнительные гарантии на конечных точках.

SSL/TLS также уязвим для атаки "man-in-the-middle" при отсутствии аутентификации сервера или использовании им самоподписанного сертификата. В случае анонимного сервера общий секрет вырабатывается по алгоритму Диффи-Хеллмана, который уязвим для атак "man-in-the-middle". Аналогичная ситуация возникает, когда пользователь принимает сертификат сервера без проверки его действительности вручную или при отсутствии в браузере открытого ключа выпустившего сертификат СА.

При этом атакующий устанавливает одно множество ключей сессии для использования с настоящим сервером, и другое множество ключей – для использования с клиентом. Это позволяет атакующему не только читать все данные, которые передаются между клиентом и сервером, но и изменять данные без обнаружения этого. Следовательно, очень важно для пользователей понимать опасность данного типа атаки и проверять действительность сертификата, прежде, чем полагаться на безопасность SSL/TLS сессии. Данная угроза может быть понижена, если клиент доверяет сертификатам, выпущенным доверенными CAs, или самоподписанные сертификаты получены с использованием некоторых внешних механизмов. Предоставление самоподписанного сертификата может означать, что происходит атака "man-in-the-middle". Последние версии браузеров выполняют некоторые проверки автоматически, но на это нельзя полагаться во всех случаях.

Пример SSL/TLS-сессии

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

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

  1. Клиент посылает номер версии, наборы криптографических алгоритмов, случайное число и другую информацию, необходимую серверу для взаимодействия с клиентом, используя SSL/TLS.
  2. Сервер посылает клиенту номер версии, выбранные криптографические алгоритмы, случайное число и другую информацию, необходимую клиенту для взаимодействия с сервером, используя SSL/TLS. Сервер также посылает свой собственный сертификат и, если клиент запрашивает ресурсы сервера, которые требуют аутентификации клиента, может запросить сертификат клиента.
  3. Клиент использует информацию, полученную от сервера, для аутентификации сервера. Если сервер не может быть аутентифицирован, то пользователю сообщают о проблемах и информируют, что аутентифицированное и зашифрованное соединение не может быть установлено. Если сервер успешно прошел аутентификацию, то клиент переходит к шагу 4.
  4. Используя данные, созданные на предыдущих шагах, клиент (вместе с сервером, в зависимости от используемого асимметричного алгоритма) создает мастер-секрет, из которого вычисляются ключи сессии, необходимые для обеспечения целостности и конфиденциальности соединения.
  5. Если сервер запросил аутентификацию клиента, клиент подписывает определенные данные, которые уникальны для данного Рукопожатия и известны как клиенту, так и серверу. В этом случае клиент посылает подписанные данные и свой сертификат серверу.
  6. После этого сервер пытается аутентифицировать клиента. Если клиент не может быть аутентифицирован, то сессия прерывается.
  7. Как клиент, так и сервер используют мастер-секрет для создания ключей сессии.
  8. Клиент посылает сообщение серверу, информируя его, что дальнейшие сообщения от клиента серверу будут зашифрованы ключом сессии. Затем он посылает зашифрованное сообщение, указывающее, что клиентская часть данных Рукопожатия завершена.
  9. Сервер посылает сообщение клиенту, информирующее его, что дальнейшие сообщения от сервера будут зашифрованы ключом сессии. Затем он посылает отдельное зашифрованное сообщение, указывающее, что серверная часть данных Рукопожатия завершена.
  10. Теперь Рукопожатие SSL/TLS завершено и начинается SSL/TLS -сессия. Клиент и сервер используют ключи сессии для шифрования и дешифрования, а также для проверки целостности посылаемых друг другу данных.
Схемы шифрования SSL/TLS

Протокол SSL/TLS поддерживает использование различных криптографических алгоритмов для таких операций, как аутентификация сервера и клиента и установление ключей сессии.

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

Требования к реализации SSL/TLS

Цифровые подписи необходимы для выполнения протокола SSL/TLS. Сертификаты могут быть выпущены третьей доверенной стороной (СА) или быть самоподписанными. Организационные требования определяют используемый подход.

Должны быть рассмотрены три ограничения на самоподписанные сертификаты.

После того как сертификат получен от СА или самовыпущен, необходимо сконфигурировать SSL/TLS. Некоторые шаги, которые являются общими для всех web-серверов:

Список действий для технологий аутентификации и шифрования

Технологии web-аутентификации и шифрования.

Конфигурирование SSL/TLS.

Firewall прикладного уровня для web — ModSecurity

Введение

ModSecurity является инструментом определения и предотвращения проникновений для web-приложений. Он также может называться прикладным web firewall’ом. Данный модуль встроен в web-сервер Apache.

Основные возможности модуля:

ModSecurity может использоваться не только для обнаружения, но и для предотвращения атак.

Понятие регулярных выражений

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

Замечание. В Apache 1.x и Apache 2.x используются различные инструментальные средства для регулярных выражений. В Apache 2.x обработка регулярных выражений совместима с Perl. В Apache 1.x обработка регулярных выражений совместима с POSIX.

В регулярных выражениях используются специальные символы. Приведем краткую семантику некоторых из них:

СимволОписание
.Соответствует любому символу
( )Группирует последовательность элементов
+Соответствует образцу один или более раз
*Соответствует образцу нуль или более раз
?Соответствует образцу нуль или один раз
^Соответствует началу строки
$Соответствует образцу в конце строки
! (перед первым символом)Инвертирует выражение

Конфигурирование

Директивы конфигурирования ModSecurity непосредственно добавляются в конфигурационный файл (обычно httpd.conf ). Если заранее не известно, включен ли данный модуль, директивы следует заключить в тег <IfModule>. Это позволит Apache игнорировать конфигурационные директивы, когда модуль не активен.

<IfModule mod_security.c>
# mod_security configuration directives
# ѕ
</IfModule>

Так как Apache допускает, чтобы конфигурационные данные были расположены более чем в одном файле, существует возможность сгруппировать конфигурационные директивы в один файл (например, modsecurity.conf ) и включить его в httpd.conf с помощью директивы Include.

Include conf/modsecurity.conf
Включение фильтрации

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

SecFilterEngine On

Возможные значения параметров:

Сканирование POST-запросов

Сканирование содержимого тела запроса (т.е. содержимое POST -запросов) по умолчанию выключено. Для выполнения сканирования содержимого POST -запросов необходимо указать:

SecFilterScanPOST		On

ModSecurity поддерживает два типа кодирования тела запроса:

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

SecFilterSelective HTTP_Content-Type \
"! (^$ | ^application/x-www-form-urlencoded$ | ^multipart/form-data;)"
Настройка отключения динамической буферизации

Существует возможность настройки отключения сканирования содержимого POST -запросов для отдельного запроса. Если определена переменная окружения MODSEC_NOPOSTBUFFERING для ModSecurity, то буферизация содержимого POST не выполняется. Например, для выключения буферизации загрузок (upload) файлов следует использовать следующее:

SetEnvIfNoCase Content-Type \
"^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"

Значение, связанное с переменной MODSEC_NOPOSTBUFFERING, будет записано в логи отладки.

Динамическое управление ModSecurity

Возможно разрешать или запрещать функционирование ModSecurity для конкретного запроса. Это выполняется с помощью переменной окружения MODSEC_ENABLE совместно с директивами SetEnvIf и SetEnvIfNoCase. Если MODSEC_ENABLE не установлена, то считается, что будет использоваться SecFilterEngine. Если MODSEC_ENABLE установлена, то значение SecFilterEngine игнорируется. Значения MODSEC_ENABLE являются теми же самыми, что и для директивы SecFilterEngine: On, Off или DynamicOnly.

Кодирование запросов и ответов, использующих chunk

Протокол НТТР поддерживает метод передачи запроса, при котором размер содержимого заранее не известен. В этом случае тело запроса доставляется с использованием chunk’ов. Следовательно, должно существовать кодирование именованных chunk’ов. ModSecurity в настоящее время не поддерживает анализ запросов, состоящих из chunk’ов; когда запрос разбивается на chunk’и, тело запроса игнорируется. Насколько известно, браузеры не посылают разбитых на chunk’и запросов. Хотя Apache поддерживает данное представление для некоторых операций, большинство модулей (например, модуль РНР с Apache 1.3.x) его не поддерживает.

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

SecFilterSelective HTTP_Transfer-Encoding "!^$"

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

Список действий по умолчанию

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

SecFilterDefaultAction "deny, log, status:404"

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

Замечание. Если указан нефатальный список действий по умолчанию (список, который не вызовет ситуацию, при которой запрос может быть отвергнут, например, log, pass ), то такой список действий будет игнорироваться на фазе инициализации. Фаза инициализации предназначена для того, чтобы получить информацию о запросе. Разрешение нефатальных действий будет приводить к тому, что некоторые части запроса могут быть пропущены. Поскольку данная информация требуется для внутренней обработки, такие действия не могут быть разрешены. Если ModSecurity должен выполняться в "detect-only" режиме, необходимо запретить все неявные проверки корректности (проверку корректности представления URL, проверку корректности представления Unicode, проверку корректности формата cookie и ограничение диапазона байтов).

Замечание. Некоторые действия не могут появиться в списке по умолчанию такие как: id, rev, skipnext, chain.

Неявная проверка корректности

Неявная проверка корректности запроса (если она сконфигурирована), выполняется только в начале обработки запроса. Эта проверка состоит из проверок строки запроса и заголовков.

Замечание. Проверка корректности Unicode не применяется к содержимому заголовка Referer как часть начальной неявной проверки корректности запроса. Это делается потому, что данный заголовок часто содержит информацию о других web-сайтах, и их кодирование обычно отличается от кодирования, используемого на защищаемом web-сайте.

Наследование фильтра

Фильтры, определенные в родительских каталогах, обычно наследуются во вложенных контекстах Apache. Такое поведение приемлемо (и требуется) в большинстве случаев, но не всегда. Иногда необходимо ослабить проверки для некоторой части сайта. Используя SecFilterInheritance директиву

SecFilterInheritance Off

можно указать ModSecurity не учитывать родительские фильтры, тем самым начать задавать правила заново. Данная директива влияет только на правила. Конфигурация всегда наследуется от родительского контекста, но ее можно перекрыть, используя соответствующие конфигурационные директивы.

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

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

В обеих директивах ( SecFilterImport и SecFilterRemove ) указываются в качестве параметра IDs списка правил. Требуемые правила должны иметь соответствующие IDs (это выполняется использованием действия id ). Директивы будут выполняться в том порядке, в котором появляются в конфигурационном файле. Следовательно, возможно удаление правила с помощью SecFilterRemove и затем добавление его снова с помощью SecFilterImport. Далее будут приведены два примера, в которых создается одна и та же конфигурация правил, но разными способами.

Замечание. Если ID требуемого правила ссылается на правило, которое является частью цепочки, директивы импорта и удаления воздействуют на всю цепочку, а не только на правило, на которое указывает ID.

Пример 1. Правила из родительского контекста не наследуются, но одно правило импортируется.

SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
<Location /subcontext/>
SecFilterInheritance Off
SecFilterImport 1003
</Location>

Пример 2. Правила из родительского контекста наследуются, при этом два правила удаляются.

SecFilter XXX id:1001
SecFilter YYY id:1002
SecFilter ZZZ id:1003
<Location /subcontext/>
SecFilterRemove 1001 1002
</Location>

Замечание. Web-сервер Apache поддерживает много различных типов контекстов (например, <Directory>, <Location>, <Files> ). Последовательность, в которой контексты соединяются, важна. Не следует смешивать наследование и контексты разного типа. В любом случае следует тщательно протестировать конфигурацию, чтобы быть уверенным, что все работает так, как ожидается.

Наследование фильтра в многопользовательских окружениях

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

Замечание. Если нет полного доверия пользователям (например, в случае web-хостинга), то никогда не следует разрешать им доступ к ModSecurity. Возможность .htaccess используется для децентрализованного администрирования. Но это не означает, что ее следует использовать в ситуациях, в которых пользователи могут захотеть разрушить конфигурацию. В этом случае надо полностью выключить возможность .htaccess, скомпилировав ModSecurity с опцией –DDISABLE_HTACCESS_CONFIG.

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

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

SecFilterInheritanceMandatory On
Рассмотрим, что произойдет в следующей ситуации:
SecFilter XXX id:1001
SecFilterInheritabceMandatory On
<Location /subcontext/>
SecFilterInheritance Off
SecFilter YYY id:1002
SecFilter ZZZ id:1003, mandatory
</Location>

<Location /subcontext/another/>
SecFilterRemove 1001 1002 1003
SecFilter QQQ id:1004
</Location>

Так как наследование правил является обязательным в основном контексте, /subcontext/ контекст будет наследовать правило 1001, несмотря на попытку его отключить (используя SecFilterInheritance Off ). В данном подконтексте первым будет выполняться правило 1001, далее правила 1002 и 1003.

Обязательное правило 1001 из основного контекста будет также распространяться на контекст /subcontext/another/, несмотря на попытку удалить его. Это также выполняется для правила 1003, которое было сделано обязательным для наследования, используя действие mandatory. Директива SecFilterRemove 1001 1002 1003 будет, однако, успешно удалять правило 1002, потому что наследование не является обязательным в /subcontext/. Следовательно, в данном контексте первыми будут выполняться правила 1001 и 1003, следующим будет правило 1004.

Замечание. Следует избегать импортирования и удаления правил с использованием действия skip. Если такие действия тщательно не проверить, то можно перейти в ту часть конфигурации, которая выполняет что-либо другое.

Проверка корректности представления URL

Специальные символы могут быть закодированы злоумышленником перед тем, как они будут вставлены в URL. Любой символ может быть заменен с использованием комбинации из трех символов: %XY, где XY представляют собой шестнадцатеричный код символа. В шестнадцатеричных числах разрешены только буквы от А до F, но атакующие иногда используют другие буквы, чтобы запутать алгоритм декодирования. ModSecurity выполняет декодирование с помощью следующего правила:

SecFilterCheckURLEncoding On

Замечание. Данная директива не проверяет содержимого POST -запросов при использовании представления multipart/form-data. Это не является обязательным, потому что в этом случае не используется URL.

Проверка корректности представления Unicode

Аналогично многим другим возможностям, проверка корректности представления Unicode по умолчанию выключена. Ее следует включить, если приложение или лежащая в основе ОС принимают и понимают Unicode.

SecFilterCheckUnicodeEncoding On

Это предполагает представление в UTF-8 и проверяет следующие три типа ошибок.

Проверка диапазона байтов

Часто следует проверять, что запрос состоит из количества байтов, принадлежащих определенному диапазону. Это может быть полезно для того, чтобы избежать атак переполнения стека (так как они обычно содержат "случайные" биты). Например, для того, чтобы разрешить запрос, состоящий из значений байтов от 32 до 126 (включительно), следует использовать директиву:

SecFilterForceByteRange 32 126

Значениями диапазона по умолчанию являются 0 и 255, т.е. все значения байтов разрешены.

Замечание. Данная директива не проверяет содержимое POST -запросов при использовании представления multipart/form-data. Если это делать, то невозможно будет загружать бинарные файлы. Однако, после того, как параметры извлечены из такого запроса, оставшаяся часть проверяется на корректность диапазона.

Правила (Rules)

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

Простая фильтрация

Самая простейшая форма фильтрации выглядит следующим образом:

SecFilter KEYWORD [ACTION]

Для каждого простого фильтра ModSecurity ищет KEYWORD в запросе. Поиск ведется очень широко; он применяется к строке запроса, которая выглядит некоторым аналогичным образом: GET /index.php?parameter= value HTTP/1.0. В случае POST -запросов тело запроса также будет просматриваться.

Первое, что следует отметить: KEYWORD – это не простой текст. Это регулярное выражение.

Нормализация пути

Фильтры не применяются к исходным данным запроса – первым делом выполняется их нормализация. Это делается потому, что атакующий может применить различные технологии скрытия определенной последовательности символов, чтобы избежать обнаружения атаки. Например, можно установить фильтр, который определяет выполнение команд shell:

SecFilter /bin/sh

Но атакующий может использовать строку /bin/./sh (которая приведет к тем же самым действиям), чтобы обойти фильтр. ModSecurity автоматически применяет следующие преобразования:

Можно также установить или запретить проверку представления URL, а также разрешать использовать только байты из некоторого диапазона

Предотвращать null byte атаки

Атаки null byte пытаются обмануть ПО, написанное на C/C++, заставляя его считать, что строка заканчивается раньше, чем это есть на самом деле. Данный тип атак обычно предотвращается с помощью фильтра SecFilterByteRange. Если не отфильтровать null byte, то это может повлиять на последующую фильтрацию. Например:

SecFilter hidden

Но при этом слово hidden не будет определено в случае такого запроса:

GET /one/two/three?p=visible%00hidden HTTP/1.0
Выборочное фильтрование
SecFilterSelective LOCATION KEYWORD [ACTION]

Позволяет точнее указать условия поиска. KEYWORD и ACTION аналогичны SecFilter. Параметр LOCATION состоит из набора идентификаторов, разделенных вертикальной чертой.

SecFilterSelective "REMOTE_ADDR | REMOTE_HOST" KEYWORD

Модуль применяет регулярное выражение только к IP-адресу клиента или имени хоста. Список возможных идентификаторов включает все CGI-переменные и некоторые другие.

Существует несколько специальных идентификаторов:

Существуют и более специальные идентификаторы:

В Apache 2 существует ограниченное число переменных, специфичных для вывода (только когда доступна буферизация вывода).

Исключение фильтрования аргументов

Для фильтрования можно указать инверсию некоторой переменной. Например:

SecFilterSelective "ARGS | !ARG_param" KEYWORD

Будет осуществляться поиск всех аргументов, за исключением названного параметра.

Cookies

ModSecurity обеспечивает полную поддержку cookies. По умолчанию cookies обрабатываются как формат версии 0. Однако версия 1 cookies (как определено в RFC 2965) также поддерживается. Для того чтобы включить поддержку cookie версии 1, надо использовать следующую директиву:

SecFilterCookieFormat 1

По умолчанию ModSecurity не пытается нормализовать имена и значения cookies. Однако, так как некоторые приложения и платформы (например, РНР) выполняют декодирование содержимого cookie, можно выбрать применение нормализации к cookies. Это делается следующим образом:

SecFilterNormalizeCookies On
Исходящая фильтрация

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

SecFilterScanOutput On

После этого следует просто добавлять фильтры, используя специальную переменную OUTPUT:

SecFilterSelective OUTPUT "credit card numbers"

В следующем примере перехватывается исходящее сообщение об ошибке РНР в теле ответа и заменяется ответ с ошибкой.

SecFilterSelective OUTPUT "Fatal error:" deny,status:500
ErrorDocument 500 /php-fatal-error.html

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

Действия skipnext и chain не работают с выходными фильтрами.

Выходная фильтрация используется только для выхода в виде plain-текста и HTML. Применение регулярных выражений к бинарным данным (например, к изображениям) сильно загрузит сервер. По умолчанию ModSecurity сканирует выходные данные в ответах, в которых не указан Content Type или Content Type есть text/plan или text/html. Это можно изменить, используя директиву SecFilterOutputMimeTypes:

SecFilterOutputMimeTypes "(null) text/html text/plain"

В данной конфигурации ModSecurity будет применять выходные фильтры к файлам в виде plain-текста, HTML-файлам и файлам, чей MIME-тип не указан.

При использовании буферизации ModSecurity держит всю страницу в памяти, независимо от размера страницы.

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

  1. Использовать Content-Type, который не просматривается. По причинам, связанным с производительностью, невозможно просматривать все типы содержимого;
  2. Некоторым способом перекодировать выходные данные. Даже простейшее перекодирование может обмануть мониторинг.

Поддерживается выходная переменная – OUTPUT_STATUS. Данная переменная определяет код статуса в ответе.

Действия (Actions)

Существует несколько типов действий.

Способы задания действий

Существует несколько мест, в которых могут быть указаны действия. Одним из таких мест является директива SecFilterDefaultAction, в которой указываются действия, которые следует выполнять для правил, следующих за директивой:

SecFilterDefaultAction "deny, log, status:500"

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

SecFilterDefaultAction "deny, log, status:’Hello, World!’"

Замечание. Если указано по умолчанию нефатальное действие (такое как log, pass ), то оно будет игнорироваться при инициализации. Фаза инициализации разработана для получения информации о запросе, не допуская, чтобы не фатальные действия приводили к тому, чтобы некоторая часть запроса пропускалась при обработке в ModSecurity. Следовательно, если ModSecurity должен функционировать в режиме "detect-only", следует запретить все неявные проверки корректности (проверка представления URL, Unicode, формат cookie, диапазон байтов).

Замечание. Действия над метаданными ( id, rev, msg, severity ) и действия, которые управляют последовательностью правил ( skip/skipnext, chain ), не могут появиться в директиве SecFilterDefaultAction.

Действия для правила

Можно также указать действия для каждого фильтра. В обеих директивах фильтрования ( SecFilter и SecFilterSelective ) может быть указано множество действий в качестве дополнительного параметра. Действия, указанные для правила, объединяются с действиями, указанными в директиве SecFilterSignatureAction (значением по умолчанию является log, deny, status:403 ). Объединение происходит по следующим правилам:

  1. Разрешается только одно первичное действие для каждого списка правил. Первичное действие для правила перекрывает первичное действие в списке по умолчанию;
  2. Действия, указанные в конфигурации для правила, перекрывают эквивалентные действия в списке действий по умолчанию;
  3. Когда задан ограниченный режим (см SecFilterActionsRestricted ), только действия над метаданными могут появиться в списке действий для каждого правила;
  4. Правила могут объединяться во время конфигурирования (предпочтительней и понятней) или во время выполнения.

Директива SecFilterSignatureAction упрощает поддержку множества правил. В более ранних версиях, если требовалось использовать список действий для правила, каждый список действий должен был быть полным, т.е. следовало указывать первичное действие, коды статуса и т.п. Это делало очень трудным отделение правил (логику определения атак) от политики конфигурирования. Директива SecFilterSignatureAction может появляться много раз внутри одного конфигурационного контекста, и она применяется к правилам, которые непосредственно следуют за ней. Также нужно заметить, что правила, которые не содержат настраиваемых действий, будут наследовать список действий данной директивы. Правило, указанное ниже, будет распространяться на действия, указанные в контексте, в котором оно выполняется. Следует подчеркнуть, что контекст правила, в котором оно выполняется, не обязательно является тем же контекстом, в котором правило было создано. С помощью наследования одно правило может выполняться во многих различных контекстах. Например:

SecFilterDefaultAction log, deny, status:500
SecFilter 000

# Warning rules
SecFilterSignatureAction log, pass
SecFilter 111 id:1
SecFilter 222 id:2

# Error rules
SecFilterSignatureAction log, pass, status:403
SecFilter 333 id:3
SecFilter 444 id:4

При использовании совместно с директивой SecFilterActionsRestricted данная директива позволяет с легкостью включать в конфигурацию набор правил стороннего разработчика.

Замечание. Значение директивы SecFilterSignatureAction не наследуется в дочерних контекстах.

Ограничения в списке действий для каждого правила

Иногда при включении правил стороннего разработчика может потребоваться, чтобы действия также появлялись и в них. Это делается с помощью директивы SecFilterActionsRestricted:

SecFilterSignatureAction log, deny, status:403
SecFilterActionsRestricted On
Include conf/third-party-rules.conf

Единственными действиями, которые разрешены в конфигурации для каждого правила при включении ограниченного режима, являются правила метаданных id, msg, rev и severity. Другие правила игнорируются.

Встроенные действия

pass

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

SecFilter KEYWORD "log, pass"

allow

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

SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow

deny

Прерывает обработку запроса, который соответствует фильтру. Если не используется действие status, ModSecurity возвращает код ошибки HTTP 500. Если запрос запрещен, заголовок mod_security_action будет добавлен в список заголовков запроса. Данный заголовок будет содержать используемый код статуса.

status

Использует указанный код статуса НТТР при прерывании запроса. Пример:

SecFilter KEYWORD "deny, status:404"

Будет возвращать ответ "Page not found" при соответствии фильтру. Директива Apache ErrorDocument будет использована, если она присутствует в конфигурации. Следовательно, если имеется заранее определенная страница для сообщения об ошибке для данного статуса, она будет выполняться, и ее выходные значения будут показаны пользователю.

redirect

При соответствии фильтру происходит перенаправление запроса пользователя на данный URL. Например:

SecFilter KEYWORD "redirect:http://www.modseciruty.org"

Данная конфигурационная директива всегда перекрывает код статуса НТТР или ключевое слово deny.

proxy

При соответствии фильтру запрос попускается через внутренний реверсный прокси.

SecFilter KEYWORD "proxy:http://www.example.ru"

Для выполнения данного действия должен быть инсталлирован mod_proxy.

exec

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

SecFilter KEYWORD "exec:/home/my/report-attack.pl"

Данная директива не влияет на первичное действие, если оно существует. Данное действие всегда вызывает скрипт без параметров, но предоставляя всю информацию через окружение. Можно использовать все обычные CGI-переменные окружения.

На каждый фильтр можно иметь только один выполняемый бинарный файл. Выполнение будет добавлять заголовок mod_security-executed в список заголовков запроса.

Замечание. Выполняемый скрипт должен что-либо записать в stdout. Если он этого не делает, то ModSeciruty предполагает, что скрипт не работает.

log

При соответствии фильтру информация заносится в error log Apache.

nolog

Не заносится ничего в лог при соответствии фильтру.

skipnext

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

SecFilterSelective ARG_p value1 skipnext:2
SecFilterSelective ARG_p value2
SecFilterSelective ARG_p value3

chain

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

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

SecFilterSelective ARG_username admin chain
SecFilterSelective REMOTE_ADDR "!^YOUR_IP_ADDRESS_HERE$"

Для первого правила выполняется соответствие только тогда, когда существует параметр username, и его значение есть admin. Только при этом будет выполняться второе правило, которое проверяет соответствие удаленного адреса в запросе с указанным IP-адресом. Если соответствие не выполняется (так как указан восклицательный знак перед адресом), запрос отвергается.

pause

Указывается количество миллисекунд перед тем, как будет выдан ответ на запрос. Используется для того, чтобы замедлить или полностью остановить некоторые web-сканеры.

auditlog

Занесение информации о транзакции в лог аудита.

noauditlog

Информация о транзакции не заносится в лог аудита.

id, rev, msg, severity

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

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

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

mandatory

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

Замечание. Действие может применяться только для отдельного правила или в начале цепочке.

SecFilter 111 mandatory

Или

SecFilter 111 mandatory, chain
SecFilter 222

setenv, setnote

Данные два действия устанавливают и удаляют поименованную переменную окружения или Apache. Существует три формата, которые могут использоваться.

Указание имени и значения:

SecFilter KEYWORD setenv:name=value

Указание только имени, значение предполагается равным "1":

SecFilter KEYWORD setenv:name

Удаление существующей переменной указывается с помощью восклицательного знака перед именем переменной:

SecFilter KEYWORD setenv:!name
Заголовки запроса, добавляемые mod_security

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

Список добавляемых заголовков следующий:

Занесение в лог тела запроса

ModSecurity экспортирует тело запроса с помощью mod_security-body. Это можно использовать для создания логов.

LogFormat "%h %l %u %t \" %r \" %>s %{mod_security-body}n

Замечание. Если запрос является multipart/request-data типом (например, загрузка файла), реальное тело запроса будет заменено эмулированным содержимым application/x-www-form-urlencoded.

Взаимодействие ModSecurity c пакетным фильтром

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

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

Так как большинство прокси посылает информацию, описывающую исходного клиента, можно попытаться определить реальный IP-адрес. Рассмотрим следующий сценарий.

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

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

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

Специальные возможности

Поддержка загрузки (upload) файла

ModSecurity имеет возможность перехватывать файлы, загружаемые с помощью POST -запросов и multipart/form-data кодирования или с помощью PUT-запросов.

Выбор местоположения для загружаемых файлов

ModSecurity всегда загружает файлы во временный каталог. Это можно изменить, используя директиву SecUploadDir:

SecUploadDir /tmp

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

Проверка файлов

Можно выполнять внешний скрипт для проверки файла перед тем, как разрешить ему проходить через web-сервер к приложению. Директива SecUploadApproveScript делает доступной данную функцию:

SecUploadApproveScript /full/path/to/the/script.sh

Скрипт получает один параметр из командной строки – полный путь к файлу, который должен быть загружен. После того как скрипт выполнит его обработку, он должен записать ответ в стандартный вывод. Если первый символ ответа есть "1", то файл принимается. В противном случае ответ отвергается. Скрипт может использовать остаток строки для записи более информативного сообщения об ошибке. Данное сообщение будет храниться в логах отладки.

Хранение загруженных файлов

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

SecUploadKeepFiles On

Каталог, в котором хранятся файлы, определяется с помощью директивы SecUploadDir.

Взаимодействие с другими демонами

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

Ограничение памяти, используемой для загрузки

В Apache 2.х можно определить количество памяти, которое может быть использовано для обработки multipart/form-data запросов. Если запрос больше, чем доступная память, то может использоваться временный файл. Значением по умолчанию является 60 Kб но данный лимит может быть изменен с помощью директивы SecUploadInMemoryLimit:

SecUploadInMemoryLimit 125000
Скрытие идентификации сервера

Одной из технологий, которая позволяет запутать атакующих, является изменение идентификации web-сервера. Web-серверы обычно посылают свою идентификацию в каждом НТТР-ответе в заголовке Server.

Для изменения идентификации web-сервера можно найти его имя (например, "Apache") в исходном коде, заменить его и перекомпилировать сервер. Тот же самый результат можно получить, используя директиву SecServerSignature:

SecServerSignature "Microsoft-IIS/5.0"

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

Поддержка chroot
Стандартный подход

ModSecurity включает поддержку изоляции файловой системы Apache или выполнение chroot. После того как операция chroot выполнена, приложение не может иметь доступа вне указанной директории.

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

Подход mod_security

В ModSecurity добавлена специальная директива, которая позволяет успешно выполнить chroot.

SecChrootDir /chroot/apache

Кроме простоты, такой подход имеет и другие преимущества. В отличие от выполнения внешнего chroot, при выполнении chroot ModSecurity не требуется, чтобы существовали дополнительные файлы в указанной директории. Вызов chroot делается после того, как web-сервер инициализирован, но перед выполнением fork. В результате этого все разделяемые библиотеки уже загружены, все модули web-сервера инициализированы и лог-файлы отрыты. В указанной директории должны быть только данные.

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

Решение общих проблем безопасности

Возможности ModSecurity могут использоваться для определения и предотвращения наиболее общих проблем, связанных с безопасностью.

Перемещение по директории

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

SecFilter "\.\./"
Атаки Cross Site Scripting

Атаки Cross Site Scripting (XSS) возникают тогда, когда атакующий вставляет HTML и/или JavaScript код в web-страницы и затем данный код выполняется на компьютерах других пользователей. Обычно это достигается добавлением HTML в те места, где он не должен быть. Результатом успешной XSS-атаки может стать получение атакующим cookie сессии и затем получение полного доступа к приложению от имени другого пользователя.

Должная защита от данной атаки состоит в фильтровании параметра (тем самым, в удалении ненужного HTML/JavaScript), и при этом часто требуется защитить существующие приложения без изменения их. Это может быть сделано с помощью одного из следующих фильтров:

SecFilter "<script"
SecFilter "<.+>"

Первый фильтр защищает только от вставления JavaScript c тегом <script>. Второй фильтр – более общий и запрещает любой HTML-код в параметрах.

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

<Location /xxx.php>
SecFilterInheritance Off
SecFilterSelective :ARGS | !ARG_body" "<.+>"
</Location>

Данный фрагмент кода будет разрешать HTML только в теле указанного параметра.

Атаки SQL / база данных

Большинство web-приложений обращаются к базам данных. Независимо от того, насколько безопасно выполняется доступ к базе данных, атакующий может вставить произвольные команды SQL для непосредственного обращения к базе данных. В результате атакующий может прочитать чувствительные данные, изменить их или даже удалить из базы данных.

Фильтры должны быть примерно следующими:

SecFilter "delete[[:space:]]+from"
SecFilter "insert [[:space:]]+into"
SecFilter "select.+from"

Эти фильтры могут защитить от большинства атак, относящихся к SQL.

Выполнение команд ОС

Web-приложениям иногда требуется выполнять команды ОС. Это может позволить атакующему выполнить произвольные команды. Фильтр должен быть подобен следующему:

SecFilterSelective ARGS "bin/"

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

Атаки переполнения буфера

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

SecFilterByteRange 32 126

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

Проверка параметров

Проверка того, что параметр является целым в диапазоне от 0 до 99999, выполняется с помощью следующего фильтра:

SecFilterSelective ARG_parameter "!^[0-9]{1,5}$"
Загрузка файлов

Запрещение загрузки файлов в произвольное место файлового пространства, но разрешение загрузки в конкретный подкаталог выполняется с помощью следующего фильтра:

SecFilterSelective HTTP_CONTENT_TYPE multipart/form-data
<Location /upload.php>
SecFilterInheritance Off
</Location>

Рекомендуемая конфигурация

Ниже приведена рекомендуемая минимальная конфигурация.

SecFilterEngine On

# Reject requests with status 403
SecFilterDefaultAction "deny, log, status:403"

# Some defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off

# Accept almost all byte values
SecFilterForceByteRange 1 255
SecUploadDir /tmp
SecUploadKeepFiles Off

# Only accept request encoding we know how to handle
# we exclude GET requests from this because some (automated)
# client supply
# "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET | HEAD) $" chain
SecFilterSelective HTTP_Content-Type \
"!(^applicatin/x-www-form-urlencoded$ | ^multipart/form-data;)"

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD "^(GET | HEAD)$" chain
SecFilterSelective HTTP_Content-Length "!^$"

# Require Content-Length to be provided with every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding "!^$"
Пример 11.1. (html, txt)

Лекция 12. Реализация безопасной сетевой инфраструктуры для web-сервера

Рассматривается реализация безопасной сетевой инфраструктуры для web-сервера: топология сети, использование firewall’ов, сетевых коммутаторов и концентраторов, IDS. Формулируются принципы администрирования web-сервера: создание логов, процедуры создания backup web-сервера, восстановление при компрометации безопасности, тестирование безопасности и удаленное администрирование web-сервера.

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

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

Топология сети

Существует много вариантов создания топологии сети, и безопасность может быть не главным фактором при принятии решений. Топология сети является первым и во многих аспектах наиболее критичным сетевым решением, которое воздействует на безопасность web-сервера. Она важна по нескольким причинам. Топология сети определяет, какая сетевая инфраструктура может быть использована для защиты web-сервера. Например, если web-сервер расположен позади firewall’а организации, то firewall может использоваться для контроля входящего и исходящего трафика во внутреннюю сеть и web-сервер. Топология сети также определяет, какие участки сети окажутся уязвимыми, если web-сервер будет скомпрометирован. Например, если web-сервер размещен во внутренней производственной сети, то внутренняя сеть может быть подвергнута атаке со стороны скомпрометированного web-сервера. Организация может принять решение не размещать web-сервер в своей сети, а разместить его в сторонней организации.

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

Также не рекомендуется располагать web-сервер перед firewall’ом организации или роутером, который осуществляет IP-фильтрацию. При таком типе конфигурации сеть может обеспечивать меньшую, чем необходимо, защиту web-сервера. Вся безопасность зависит только от самого web-сервера, который представляет собой единственную точку падения. Даже если при такой топологии и задействовать существенные меры обеспечения безопасности, все равно ОС, на которой выполняется web-сервер, должна быть достаточно укрепленной (все ненужные и небезопасные сервисы запрещены) и полностью применены необходимые patches безопасности, а web-администратор должен выполнять своевременное устранение всех уязвимостей. Другой недостаток подобной топологии состоит в том, что в данном случае трудно реализовать какой-либо тип безопасного удаленного администрирования или модификации содержимого.

Демилитаризованная зона

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

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

Базовая DMZ


Рис. 12.1.  Базовая DMZ

Данный тип DMZ имеет минимальную стоимость. Это подходит для небольших организаций при наличии минимальной угрозы. Основное слабое место такого подхода состоит в том, что, хотя роутер и имеет возможность защитить от большинства сетевых атак, он не "понимает" протокол НТТР и, следовательно, не может защитить от атак прикладного уровня, нацеленных на web-сервер. Лучший подход состоит в добавлении второго firewall’а между Интернетом и DMZ. Так будет создана лучшая защита DMZ. Пример данного типа реализации показан на рис. 12.2.

DMZ с двумя firewall’ами


Рис. 12.2.  DMZ с двумя firewall’ами

Эта DMZ с двумя firewall’ами обеспечивает лучшую защиту по сравнению с базовой DMZ, так как выделенные firewall’ы могут иметь более сложные и сильные наборы правил безопасности. Кроме того, выделенный firewall часто имеет возможность анализировать входящий и исходящий НТТР-трафик, он может определить атаки прикладного уровня, направленные на web-сервер, и защитить от них. Однако, данный тип DMZ может иметь некоторые проблемы с эффективностью выполнения.

Для организаций, которым требуется безопасность уровня DMZ с двумя firewall’ами, но которые не имеют финансовых возможностей для покупки двух firewall’ов, существует возможность, называемая service leg DMZ. В такой конфигурации firewall создается с тремя (или более) сетевыми интерфейсами. Один сетевой интерфейс соединяется с пограничным роутером, другой — с внутренней сетью и третий — с DMZ.

DMZ с firewall’ом с тремя интерфейсами


Рис. 12.3.  DMZ с firewall’ом с тремя интерфейсами

Данная конфигурация имеет определенные недостатки. В конфигурации DMZ, которая обсуждалась выше, DoS-атака, направленная на web-сервер, обычно задевает только сам web-сервер. В service leg конфигурации firewall принимает удар любой DoS-атаки, потому что он должен проверить весь сетевой трафик до того, как трафик достигнет web-сервера (либо любого другого ресурса в DMZ или во внутренней сети). Необходимость такой обработки может сильно загрузить firewall и замедлить весь трафик, включая тот, что предназначен для внутренней сети.

Преимущества создания DMZ с точки зрения безопасности:

Недостатки DMZ с точки зрения безопасности.

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

Хостинг во внешней организации

Многие организации предпочитают хостинг своего web-сервера в третьей организации (например, в Internet Service Provider – ISP). В этом случае web-сервер не размещается в сети организации. ISP имеет выделенную сеть, обслуживающую много web-серверов (для многих организаций), которые выполняются в одной сети.

Преимущества хостинга во внешней организации с точки зрения безопасности:

Недостатки хостинга во внешней организации с точки зрения безопасности:

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

Сетевые элементы

После того как web-сервер размещен в сети, следует сконфигурировать элементы сетевой инфраструктуры для поддержки и защиты web-сервера. Элементами сетевой инфраструктуры, которые влияют на безопасность web-сервера, являются firewall’ы, роутеры, системы обнаружения проникновения и сетевые коммутаторы (switch). Каждый из них играет важную роль для защиты web-сервера при обеспечении многоуровневой обороны. К сожалению, при обеспечении безопасности web-сервера не существует универсального решения. Единичный firewall или IDS не может обеспечить адекватную защиту публичного web-сервера от всех угроз и атак.

Роутер и firewall

Firewall’ы (или роутеры, функционирующие как firewall’ы) являются устройствами или системами, которые контролируют поток сетевого трафика между сетями. Они защищают web-серверы от уязвимостей, существующих в семействе протоколов TCP/IP. Они также помогают уменьшить проблемы безопасности, связанные с небезопасными приложениями и ОС. Существует несколько типов firewall’ов: роутеры, которые могут обеспечивать управление доступом на уровне IP-пакетов; statefull firewalls’ы которые могут также контролировать доступ, основываясь не только на содержимом IP, но также и на содержимом заголовков протоколов ТСР и UDP; и наиболее мощные firewall’ы, которые могут распознавать и фильтровать web-содержимое.

Существует ошибочное мнение, что firewall’ы (или роутеры, функционирующие как firewall’ы) могут избавить от всех рисков и защитить от неправильной конфигурации web-сервера или плохо разработанной топологии сети. К сожалению, этого не происходит. Firewall’ы сами являются уязвимыми с точки зрения неправильной конфигурации, иногда уязвимы с точки зрения ПО. Кроме того, web-серверы уязвимы для многих атак, даже когда они расположены позади безопасного правильно сконфигурированного firewall’а. Например, firewall, который защищает web-сервер, должен блокировать любой доступ к web-серверу из Интернета, за исключением НТТР (обычно ТСР порт 80) и/или HTTPS (обычно ТСР порт 443). Тем не менее при такой конфигурации многие приложения web-сервера уязвимы для атак через 80 порт. Тем самым, firewall можно считать первой линией обороны web-сервера. Однако, чтобы быть действительно в безопасности, организация должна применять "оборону вглубь". Более важно, чтобы организация старалась поддерживать все системы безопасным образом и не зависела исключительно от firewall’ов (или любого другого единственного компонента), которые должны остановить атаку.

Для того чтобы более успешно защищать web-сервер с использованием firewall’а, следует гарантировать, что существует возможность сконфигурировать следующее:

Системы обнаружения проникновения (IDS)

IDS является приложением, которое просматривает системные и сетевые ресурсы и анализирует различные виды деятельности, а также, используя информацию, полученную из этих источников, уведомляет сетевого администратора и/или соответствующий персонал, отвечающий за безопасность, о возможном проникновении или попытки взлома. Два основных типами IDS: host-based и network-based.

Сетевые коммутаторы и концентраторы

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

При использовании коммутаторов труднее просматривать взаимодействия между различными хостами в данном сегменте сети. Это преимущество особенно важно, когда web-сервер расположен в сегменте сети, в котором также расположены и другие хосты. Например, если используется концентратор и web-сервер скомпрометирован, атакующий может иметь возможность подсмотреть взаимодействие других хостов, что может привести к компрометации этих хостов или информации, которую они посылают по сети. E-mail серверы часто расположены вместе с web-серверами и в конфигурации по умолчанию принимают незашифрованные пароли. В таком случае компрометация web-сервера приводит к компрометации почтового сервера, независимо от того, используется коммутатор или нет. Коммутатор предотвращает или, по крайней мере, затрудняет для атакующего перехват паролей почтового сервера с использованием скомпрометированного web-сервера, если эти серверы расположены на разных хостах.

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

Список действий для обеспечения безопасности сетевой инфраструктуры

Расположение сети.

Конфигурация firewall’а.

Использование IDS.

Использование сетевых коммутаторов и концентраторов.

Администрирование web-сервера

Создание логов

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

Логи web-сервера обеспечивают следующее:

Выбор конкретного ПО web-сервера определяет множество более детальных инструкций, которым должен следовать web-администратор для конфигурирования логов.

Основные возможности создания логов

Каждое приложение web-сервера поддерживает различные возможности ведения логов. В зависимости от приложения web-сервера могут быть доступны одна или более следующих возможностей логов.

Большинство web-серверов поддерживают Transfer Log, и это обычно считается наиболее важным. Для записей Transfer Log доступно несколько форматов логов. Обычно информация представлена в виде плоского ASCII-текста без специальных разграничений различных полей.

Дополнительные требования для создания логов

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

Возможные параметры логов

Логи, созданные со следующими параметрами, можно считать оптимальными для первоначального использования:

Просмотр и хранение лог-файлов

Просмотр лог-файлов может быть трудоемким и занимать много времени. Лог-файлы являются реагирующей мерой безопасности; они информируют о событиях, которые уже произошли. Соответственно, они часто бывают полезны для поддержки других доказательств, таких как аномальный сетевой трафик, обнаруженный IDS. Логи web-сервера должны также просматриваться для обнаружения атак. Частота просмотра зависит от следующих факторов:

Для облегчения анализа логов разработаны специальные автоматизированные средства.

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

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

Необходимо регулярно создавать back up и архивы лог-файлов. Периодическое архивирование лог-файлов существенно по нескольким причинам. Оно может быть важно с точки зрения законодательных действий или использоваться при возникновении различных проблем, связанных с web-сервером. Периодичность архивации лог-файлов зависит от нескольких факторов, включающих следующие:

Автоматизированные инструментальные средства анализа лог-файлов

Большинство web-серверов имеют большой трафик, и лог-файлы быстро становятся огромными. Для облегчения работы web-администратора необходимо использовать одно или более автоматизированное средство анализа лог-файлов. Эти средства анализируют записи в лог-файле и идентифицируют подозрительную или необычную деятельность.

Доступно большое количество коммерческих и свободно распространяемых средств, обеспечивающих регулярный анализ Transfer Log. Большинство выполняется для Common или Combined Log Format.

Такие средства могут идентифицировать IP-адреса, которые являются источником большого числа соединений или большого объема трафика.

Средства Error Log определяют не только ошибки, которые могут существовать в конкретном web-содержимом (такие как отсутствующие файлы), но также попытки доступа к несуществующим URL. Эти попытки могут указывать на следующее:

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

Процедуры создания backup web-сервера

Одна из наиболее важных функций администратора web-сервера — поддержка целостности данных на web-сервере. Это жизненно важно, потому что web-сервер часто является наиболее незащищенным сервером в сети организации и, таким образом, часто наиболее чувствительным к враждебным действиям и возможным падениям ПО и аппаратуры. Существуют два принципиальных компонента для выполнения backup’а данных для web-сервера: регулярный backup данных и всей системы и поддержка защищенной, аутентичной, отдельно хранящейся копии содержимого web-сервера.

Политики и стратегии выполнения backup’а web-сервера

Web-администратор должен регулярно выполнять backup web-сервера. Это существенно по нескольким причинам. Если web-сервер падает в результате совершения предумышленного или непреднамеренного действия, он должен быть восстановлен и содержать актуальную информацию.

Все организации должны иметь политику выполнения backup’а данных web-сервера. На содержание этой политики могут повлиять следующие факторы:

Хотя политика выполнения backup’а в каждой организации может отличаться в соответствии с конкретным окружением, она должна рассматривать следующие проблемы:

Существует два основных типа backup’а. Полный backup включает ОС, приложения и данные, хранимые на web-сервере (например, образ каждого участка данных, хранимых на жестких дисках web-сервера). Преимущество полного backup’а состоит в том, что легко вернуть весь web-сервер в состояние (конфигурация, уровень patch, данные и т.п.), которое существовало, когда был выполнен backup. Недостаток полного backup, а в том, что для его выполнения требуется много времени и ресурсов. Инкрементальный backup выполняется только для данных, которые изменены после предыдущего backup’а (либо полного, либо инкрементального). Обычно полный backup выполняется менее часто (еженедельно или ежемесячно или когда сделаны важные изменения), чем инкрементальный backup (ежедневно или еженедельно). Частота выполнения backup’а определяется несколькими факторами:

Поддержка тестового web-сервера

Большинство организаций поддерживают тестовый или развиваемый web-сервер. Идеально, чтобы данный сервер имел аппаратуру и ПО, идентичную основному web-серверу, и был размещен во внутреннем сегменте сети (Интранет), где он может быть полностью защищен обороной периметра. Хотя цена поддержки дополнительного web-сервера может быть значительной, наличие тестового сервера часто обеспечивает значительные преимущества.

Замечание: тестовый web-сервер должен быть отделен от сервера, который содержит аутентичную копию содержимого производственного web-сервера.

Поддержка аутентичной копии web-содержимого

Следует поддерживать аутентичную (проверенную, доверяемую) копию web-содержимого на хосте, который не доступен из Интернета. Это дополняет, но не заменяет соответствующую политику backup’а. Например, в отношении статических web-сайтов это должна быть простая копия web-сайта на устройстве только для чтения (CD-R). Аутентичная копия web-сайта должна поддерживаться на безопасном хосте. Такой хост обычно расположен позади firewall’а во внутренней сети, а не в DMZ. Цель создания аутентичной копии состоит в том, чтобы предоставить способы восстановления информации на web-сайте, если он был скомпрометирован в результате случайных или преднамеренных действий. Аутентичная копия web-сайта позволяет быстро восстановить изуродованный web-сайт.

Для успешного выполнения данной цели должны быть выполнены следующие требования:

Восстановление при компрометации безопасности

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

Web-администраторы должны выполнить следующие шаги при определении успешной компрометации:

Системные администраторы должны рассмотреть следующие параметры при принятии решения о том, следует ли переинсталлировать ОС на скомпрометированной системе или же достаточно восстановить все из backup’а:

Более низкий уровень доступа, полученный нарушителем, и большие знания web-администратора о действиях нарушителя уменьшают риск, существующий при восстановлении из backup’а и выполнении patch для устранения уязвимостей. Если о действиях нарушителя известно мало, то нужно переустановить все ПО на хосте.

Тестирование безопасности web-серверов

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

Сканирование уязвимостей

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

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

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

Для сканеров уязвимостей периодически должно выполняться обновление базы данных, чтобы они могли распознавать самые последние уязвимости. Перед запуском любого сканера web-администраторы должны инсталлировать самые последние обновления базы данных уязвимостей. Некоторые базы данных изменяются более регулярно, чем другие (выпуск обновлений часто должен быть важным фактором при выборе сканера уязвимостей).

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

Сканеры уязвимостей предоставляют следующие возможности:

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

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

Тестирование проникновения

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

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

Тестирование проникновения имеет следующие преимущества:

Удаленное администрирование web-сервера

Администраторы web-сервера должны тщательно рассмотреть, существует ли необходимость удаленного администрирования и/или модификации содержимого web-сервера. Большинство безопасных конфигураций запрещает любое удаленное администрирование или модификации содержимого, хотя это может и не являться необходимым абсолютно для всех организаций. Риск от необходимости удаленного администрирования или модификации содержимого зависит от размещения web-сервера в сети. Например, если web-сервер расположен внешне относительно firewall’а или фильтрующего роутера, то никакого удаленного администрирования или модификации содержимого не должно выполняться. Удаленное администрирование или модификация содержимого могут выполняться относительно безопасно из внутренней сети, когда web-сервер расположен позади firewall’а. Удаленное администрирование или модификация содержимого не должны допускаться с хоста, расположенного вне сети организации.

Если необходимо удаленное администрирование или модификация содержимого на web-сервере, то для обеспечения безопасности должно быть гарантировано следующее:

Список действий для безопасного администрирования web-сервера

Создание логов.

Выполнение backup’ов web-сервера.

Восстановление после компрометации.

Тестирование безопасности.

Удаленное администрирование и модификация содержимого.

Дополнения


Литература

  1. Галатенко В.А, Основы информационной безопасности, изд. Интуит, 2005г
  2. Галатенко В.А, Стандарты информационной безопасности, изд, изд. Интуит, 2005г
  3. Лапонина О.Р, Основы сетевой безопасности: криптографические алгоритмы и протоколы взаимодействия, изд. Интуит, 2005г
  4. , National Institute of Standards and Technology U.S. Department of Commerce "Secure Domain Name System (DNS) Deployment Guide", Special Publication 800-81 (Draft), 2005г, 91с
  5. , National Institute of Standards and Technology U.S. Department of Commerce "Intrusion Detection Systems", Special Publication 800-31, 2004г, 51с
  6. , National Institute of Standards and Technology U.S. Department of Commerce "Guidelines on Firewalls and Firewall Policy", Special Publication 800-41, 2002г, 74с
  7. , National Institute of Standards and Technology U.S. Department of Commerce "Guidelines on Securing Public Web Servers", Special Publication 800-44, 2002г, 187с
  8. , Mod_Security Reference Manual v1.7.4, 2003г., 27с
  9. , FreeBSD Handbook, 2006г
  10. , RFC 793 "Transmission Control Protocol", 1981г, 85с
  11. , RFC 1035 "DOMAIN NAMES – implementation and specification", 1987г., 55с
  12. , RFC 2069 "An Extension to HTTP : Digest Access Authentication", 1997г., 18с
  13. , RFC 2616 "Hypertext Transfer Protocol - HTTP/1.1", 1999г., 176с
  14. , RFC 2617 "HTTP Authentication: Basic and Digest Access Authentication", 1999г., 34с
  15. , RFC 2845 "Secret Key Transaction Authentication for DNS (TSIG)", 2000г., 15с
  16. , RFC 2930 "Secret Key Establishment for DNS (TKEY RR)", 2000г., 16с
  17. , RFC 2931 "DNS Request and Transaction Signatures ( SIG(0)s )", 2000г., 10с
  18. , RFC 2964 "Use of HTTP State Management", 2000г., 8с
  19. , RFC 2965 "HTTP State Management Mechanism", 2000г., 26с
  20. , RFC 3007 "Secure Domain Name System (DNS) Dynamic Update", 2000г., 9с
  21. , RFC 3833 "Threat Analysis of the Domain Name System (DNS)", 2004г., 16с
  22. , RFC 4033 "DNS Security Introduction and Requirements", 2005г., 21с
  23. , RFC 4034 "Resource Records for the DNS Security Extensions", 2005г., 29с
  24. , RFC 4035 "Protocol Modifications for the DNS Security Extensions", 2005г., 53с