Введение в сетевую безопасность

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

Атаки сканирования (по IP или номеру порта) растянуты во времени, их можно сделать трудно идентифицируемыми, замедлив темп сканирования и введя рандомизацию перебора, но они не представляют серьезной угрозы, так как всегда есть задержка между сканированием и собственно атакой (есть время подготовиться и отреагировать, например, введя IP-атакера в ACL – Access Control List).

Наиболее часто по данным CERT сканируются следующие порты (http://www.cert.org/current/scanning.html):

• 21/tcp ftp
• 22/tcp ssh
• 53/tcp dns
• 80/tcp http
• 111/tcp sunrpc
• 137,138,139/udp NetBIOS
• 443/tcp https
• 1433/tcp MS SQL Server

Разновидностью сканирования может являться последовательная посылка разных параметров запросов (варьироваться может как значение параметра, так и его длина). Этот вид атак часто непредсказуем, так как не известно, существует ли значение параметра, представляющее угрозу. Но ясно, что это атака, и адрес отправителя следует заносить в DB-атакеров и в ACL.

Единого определения сетевой атаки не существует, и это не удивительно. Есть сигнатуры, назначение которых не вызывает сомнения (сканирование портов "троянских коней", ping of death, tear drop и т.д.). Примерно треть разновидностей атак имеют целью выявление типа ОС, конфигурации и версий установленных приложений. Хотя непосредственно такие попытки угрозы не представляют, но это может быть разведкой перед реальной атакой. И все же более половины сигнатур атак столь однозначно оценить нельзя.

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

Если же это рабочая станция, не допускающая удаленного подключения, то это, скорее всего, атака, особенно если такая попытка повторяется. Таким образом, одна и та же сигнатура в одних случаях может рассматриваться как атака, а в другом – как нормальное событие. Многое зависит от рабочей ОС, ее версии, набора установленных приложений (Apache, DBI/DBD, BIND, SendMail и пр.).

Именно это обстоятельство делает необходимым введения языков описания правил отбора и сортировки событий. С помощью этих правил администратор, знающий реальную конфигурацию системы, может сформулировать принципы выделения событий, сопряженных с сетевыми атаками. Это означает, что не существует и не может существовать универсальных определений и описаний сигнатур атак. Если на ЭВМ установлен почтовый сервер, то попытка установить с ним соединение через порт 25 является нормальной ситуацией, но если там такого сервера нет – это атака (или ошибка, если попытка не повторяется многократно). Точно так же получение SQL-запроса SELECT для ЭВМ-сервера DB является нормальным, а для рабочей станции – атакой. Это же можно отнести к прокси-серверам и т.д. и т.д.

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

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

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

Особый класс сигнатур представляют DoS-атаки. Их многообразие растет. Следует иметь в виду, что такие атаки могут быть частью процедуры вторжения. Но их роднит друг с другом только поглощение ресурсов атакуемого объекта, механизмы же реализации различны. Такими ресурсами могут быть: полоса внешнего канала, объем памяти ЭВМ или буферов, объемы виртуальной памяти и т.д. К этой разновидности относятся SYN-и ACK-штормы, различные широковещательные запросы, ICMP-запросы по широковещательным адресам. Обычно атакер старается скрыть свой IP-адрес путем его подмены (часто это является частью схемы атаки). Атакер стремится получить усиление трафика на стороне атакуемого (конечное значение трафика больше потока, посылаемого атакером). Примером такого усиления могут служить запросы ресурсов DNS, когда пакет запроса имеет объем во много раз меньше, чем объем отклика (IP-адрес отправителя равен адресу атакуемого). Такая схема атаки эффективна, если сочетается с фальсификацией адреса отправителя (объектами атаки в этом случае становятся как DNS-сервер, так и ЭВМ, адрес которой атакер проставил в поле адрес отправителя ).

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

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

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

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

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