Защита информации с помощью Kerio Control/WinRoute Firewall

Почтовая бомбардировка

Бомбардировка электронной почтой (т.н. mailbombing) - один из самых старых и примитивных видов интернет-атак. Суть мэйлбомбинга - в засорении почтового ящика "мусорной" корреспонденцией или даже выведении из строя почтового сервера интернет-провайдера. Для этого применяются специальные программы - мэйлбомберы. Они попросту засыпают указанный в качестве мишени почтовый ящик огромным количеством писем, указывая при этом фальшивые данные отправителя - вплоть до IP-адреса. Все, что нужно агрессору, использующему такую программу, - указать e-mail объекта атаки, число сообщений, написать текст письма (обычно пишется что-нибудь оскорбительное), указать фальшивые данные отправителя, если программа этого не делает сама и нажать кнопку "пуск". Впрочем, большинство интернет-провайдеров имеют собственные системы защиты клиентов от мэйлбомбинга. Когда число одинаковых писем из одного и того же источника начинает превышать некие разумные пределы, вся поступающая корреспонденция такого рода просто уничтожается. Так что сегодня почтовых бомбардировок можно всерьез уже не опасаться.

Атаки с подбором пароля

Атакующий систему хакер часто начинает свои действия с попыток раздобыть пароль администратора или одного из пользователей. Для того чтобы узнать пароль, существует великое множество различных методов. Вот основные из них: IP-спуфинг и сниффинг пакетов – они рассмотрены ниже. Внедрение в систему "троянского коня" - один из наиболее распространенных в хакерской практике приемов, про него также рассказано подробнее в дальнейшем. Перебор "в лоб" (brute force attack - "атака грубой силой"). Существует множество программ, которые осуществляют простой перебор вариантов паролей через Интернет или напрямую на атакуемом компьютере. Одни программы перебирают пароли по определенному словарю, другие просто генерируют случайным образом различные последовательности символов. Использующий логический перебор вариантов пароля злоумышленник просто перебирает вероятные комбинации символов, которые могут быть использованы пользователем в качестве пароля. Такой подход обычно оказывается на удивление эффективным. Специалисты по компьютерной безопасности не перестают удивляться, до чего часто пользователи используют в качестве пароля такие "загадочные" комбинации как, 1234, qwerty или собственное имя, написанное задом наперед. Серьезные хакеры, подбирая заветный пароль, могут досконально изучить человека, этот пароль использующего. Имена членов семьи и прочих родственников, любимой собаки/кошки; за какие команды и в каких видах спорта "объект" болеет; какие книги и кинофильмы любит; какую газету читает по утрам - все эти данные и их комбинации идут в дело. Спастись от подобных атак можно, только используя в качестве пароля случайную комбинацию букв и цифр, желательно сгенерированную специальной программой. И, разумеется, необходимо регулярно менять пароль - следить за этим обязан системный администратор.

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

3.2.3 Вирусы, почтовые черви и "троянские кони"

Эти напасти поражают, в основном, не провайдеров или корпоративные коммуникации, а компьютеры конечных пользователей. Масштабы поражения при этом просто впечатляют - вспыхивающие все чаще глобальные компьютерные эпидемии приносят многомиллиардные убытки. Авторы же "зловредных" программ становятся все изощреннее, воплощая в современных вирусах самые передовые программные и психологические технологии. Вирусы, «черви» и «троянские кони» - это разные классы "враждебного" программного кода. Вирусы внедряются в другие программы с целью выполнения заложенной в них вредоносной функции на рабочей станции конечного пользователя. Это может быть, например, уничтожение всех или только определенных файлов на винчестере (чаще всего), порча оборудования (пока экзотика) или другие операции. Часто вирусы запрограммированы на срабатывание в определенную дату (типичный пример - знаменитый WinChih, он же "Чернобыль" – вирус, полностью стирающий БИОС, срабатывал в дату Чернобыльской аварии), а также на рассылку своих копий посредством электронной почты по всем адресам, найденным в адресной книге пользователя.

К «сетевым червям» относятся программы, распространяющие свои копии по локальным и/или глобальным сетям с целью:

1. проникновения на удаленные компьютеры;

2. запуска своей копии на удаленном компьютере;

3. дальнейшего распространения на другие компьютеры в сети.

Для своего распространения сетевые черви используют разнообразные компьютерные и мобильные сети: электронную почту, системы обмена мгновенными сообщениями, файлообменные (P2P) и IRC-сети, LAN, сети обмена данными между мобильными устройствами (телефонами, карманными компьютерами) и т. д. Большинство известных червей распространяется в виде файлов: вложение в электронное письмо, ссылка на зараженный файл на каком-либо веб- или FTP-ресурсе в ICQ- и IRC-сообщениях, файл в каталоге обмена P2P и т. д. Некоторые черви (так называемые «безфайловые» или «пакетные» черви) распространяются в виде сетевых пакетов, проникают непосредственно в память компьютера и активизируют свой код. Для проникновения на удаленные компьютеры и запуска своей копии черви используют различные методы: социальный инжиниринг (например, текст электронного письма, призывающий открыть вложенный файл), недочеты в конфигурации сети (например, копирование на диск, открытый на полный доступ), ошибки в службах безопасности операционных систем и приложений. Некоторые черви обладают также свойствами других разновидностей вредоносного программного обеспечения. Например, некоторые черви содержат троянские функции или способны заражать выполняемые файлы.

«Троянский конь» - самостоятельная программа, чаще всего не ориентированная на грубое разрушение информации, свойственное вирусам. Обычно цель внедрения "троянского коня" - получение скрытого удаленного контроля над компьютером для того, чтобы манипулировать содержащейся на нем информацией. "Троянские кони" успешно маскируются под различные игры или полезные программы, великое множество которых бесплатно распространяется в Интернете. Более того, хакеры иногда встраивают "троянских коней" в совершенно "невинные" и пользующиеся хорошей репутацией программы. Попав на компьютер, "троянский конь" обычно не афиширует свое присутствие, выполняя свои функции максимально скрытно. Такая программа может, к примеру, тишком отсылать своему хозяину-хакеру пароль и логин для доступа в Интернет с данного конкретного компьютера; делать и отправлять по заложенному в нее адресу определенные файлы; отслеживать все, что вводится с клавиатуры, и т.д. Более изощренные версии "троянских коней", адаптированные для атаки на конкретные компьютеры конкретных пользователей, могут по указанию хозяина заменять те или иные данные на другие, заранее заготовленные, или видоизменять хранящиеся в файлах данные, вводя тем самым в заблуждение владельца компьютера. К слову, довольно распространенный прием из арсенала промышленного шпионажа и провокаций.

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

Сетевая разведка

Собственно говоря, сетевую разведку нельзя назвать атакой на компьютерную систему - ведь никаких "зловредных" действий хакер при этом не производит. Однако сетевая разведка всегда предшествует собственно нападению, так как при его подготовке злоумышленникам необходимо собрать всю доступную информацию о системе. При этом информация собирается с использованием большого набора общедоступных данных и приложений - ведь хакер старается получить как можно больше полезной информации. При этом производится сканирование портов, запросы DNS, эхо-тестирование раскрытых с помощью DNS адресов и т.д. Так удается, в частности, выяснить, кому принадлежит тот или иной домен и какие адреса этому домену присвоены. Эхо-тестирование (ping sweep) адресов, раскрытых с помощью DNS, позволяет увидеть, какие хосты реально работают в данной сети, а средства сканирования портов позволяют составить полный список услуг, поддерживаемых этими хостами. Анализируются при проведении сетевой разведки и характеристики приложений, работающих на хостах, - словом, добывается информация, которую впоследствии можно использовать при взломе или проведении DoS-атаки. Полностью избавиться от сетевой разведки невозможно, в первую очередь потому, что формально враждебных действий не производится. Если, например, отключить эхо ICMP и эхо-ответ на периферийных маршрутизаторах, можно избавиться от эхо-тестирования, однако при этом окажутся потеряны данные, которые необходимы для диагностики сбоев в Сети. К тому же, просканировать порты злоумышленники могут и без предварительного эхо-тестирования. Защитные и контролирующие системы на уровне сети и хостов обычно вполне справляются с задачей уведомления системного администратора о ведущейся сетевой разведке. При добросовестном отношении администратора к своим обязанностям это позволяет лучше подготовиться к предстоящей атаке и даже принять упреждающие меры, например, оповестив провайдера, из сети которого кто-то проявляет чрезмерное любопытство.

Описание

Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number[3] (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так:

После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.

Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения.

Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.

Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.

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

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

· Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.

· Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.

· Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B

· Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK (заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным.

Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла.rhosts или отправки /etc/passwd крэкеру по электронной почте.

Представим это в виде схемы:

Детектирование и защита

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

В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты?

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

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

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

Неплохо также на всякий случай заблаговременно пресечь попытки спуфинга чужих сетей пользователями вашей сети - эта мера может позволить избежать целого ряда неприятностей, если внутри организации объявится злоумышленник или просто компьютерный хулиган. Для этого нужно использовать любой исходящий трафик, если его исходный адрес не относится ко внутреннему диапазону IP-адресов организации. При необходимости данную процедуру может выполнять и провайдер услуг Интернет. Этот тип фильтрации известен под названием "RFC 2827". Опять-таки, как и в случае со сниффингом пакетов, самой лучшей защитой будет сделать атаку абсолютно неэффективной. IP-спуфинг может быть реализован только при условии, что аутентификация пользователей происходит на базе IP-адресов. Поэтому криптошифрование аутентификации делает этот вид атак бесполезными. Впрочем, вместо криптошифрования с тем же успехом можно использовать случайным образом генерируемые одноразовые пароли.

Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы).

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

IP Hijacking

Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing'а.

Описание

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

Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в ТСP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.

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

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

Есть два способа рассинхронизировать соединение:

Ранняя десинхронизация

Соединение десинхронизируется на стадии его установки.

· Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии

· Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента.

· Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN -пакет.

· Клиент игнорирует S-SYN -пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK -пакет от имени клиента.

· Итак, клиент и сервер находятся в состоянии ESTABLISHED (установленный), однако сессия десинхронизирована.

Представим это в виде схемы:

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

ACK-буря

Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK -бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK -пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.

К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK -пакеты не несут данных, повторных передачи не происходит и "буря стихает".

Как показали опыты, чем сильнее ACK -буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды.

Детектирование и защита

Есть несколько путей. Например, можно реализовать TCP/IP-стэк, который будет контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения.

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

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

Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell, SSH) или на уровне протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться криптографическая программа PGP (Pretty Good Privacy).

Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.

Пассивное сканирование

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

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

Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN -пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK -пакет, как приглашение продолжить 3-way handshake[4]. Остальные вернут RST -пакеты (сброс). Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK -пакеты он может также ответить RST -пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST -пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер).

Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать

· резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED (принятый), при условии, что крэкер не посылает в ответ RST;

· прием от клиента RST -пакета в ответ на SYN/ACK.

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

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

 

Затопление ICMP-пакетами

Традиционный англоязычный термин - "ping flood". Появился он потому, что программа "ping", предназначенная для оценки качества линии, имеет ключ для "агрессивного" тестирования. В этом режиме запросы посылаются с максимально возможной скоростью и программа позволяет оценить, как работает сеть при максимальной нагрузке.

Данная атака требует от крэкера доступа к быстрым каналам в Интернет.

Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его ping выдает скорость прохождения пакета.

При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию.

Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт.

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

Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на broadcast-адреса (широковещательные) крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество broadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей, можно вызвать резкой заполненение канала "жертвы".

Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP).

В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood'а, ограничьте доступ к ping.

Затопление SYN-пакетами

Пожалуй, затопление SYN -пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие заняться этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом.

Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN -пакет S-SYN/C-ACK -пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течении заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED.

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

Затопление SYN -пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель.

В различных системах работа с очередью реализована по разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения нет и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше.

После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD).

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

Детектирование несложно - большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы.

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

Локальная буря

Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю выслается строка знакогенератора) и других (date etc).

В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19 и так до бесконечности.

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

Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов).

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

 

Инструкция по установке

WinRoute необходимо установить на компьютер, который используется как шлюз, связанный с локальной сетью и Интернетом. Этот компьютер должен иметь по меньшей мере один интерфейс для связи с локальной сетью ((Ethernet, TokenRing), и по меньшей мере один интерфейс для связи с Интернетом. В качестве интерфейса для связи с Интернетом, можно использовать сетевой адаптер (Ethernet, WaveLAN) или модем (аналоговый, ISDN). Также рекомендуется проверить следующие пункты прежде, чем начать установку WinRoute:

должно быть верно установлено время в операционной системе (для своевременного выполнения функций, обновлений антивирусных программ);

последние пакеты обновления и любые, рекомендуемые Microsoft, обновления безопасности были применены;

параметры TCP/IP должны быть установлены для всех доступных адаптеров сети;

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

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

Как только программа инсталяции запущена (то есть через kerio-kwf-mcafee-6.0.1-win.exe), гид проведет через установку основных параметров брандмауэра. Будет предложено сделать выбор между двумя типами установки - полной или выборочной. Выборочная установка позволит устанавливать индивидуальные компоненты WinRoute:

брандмауэр WinRoute — ядро программы;

монитор WinRoute — утилита Брандмауэр WinRoute управляющий и контролирующий его статус (иконка в системном трее);

VPN Support — частное VPN решение разработанное Kerio Technologies;

администраторский терминал Kerio — универсальная консоль для всех серверных приложений Kerio Technologies.

 

Рисунок 3.1 – Интерфейс выбора между двумя типами установки

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

все выбранные компоненты будут установлены или обновлены;

все выбранные компоненты не будут установлены или будут удалены.

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

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

Инструкция по настройке

Для того чтобы запустить программу Kerio Control/WinRoute Firewall необходимо произвести минимум настроек:

В первую очередь необходимо настроить меню Interfaces и меню Routing Table.

Рисунок 3.2 – Меню настроек Interfaces

Interfaces - используется для идентификации интерфейсов в WinRoute. Для легкого доступа, желательно, чтобы оно было однозначным, например Интернет для интерфеса соединения с Интернет. Иконка, расположенная слева от имени, представляет тип интерфейса (сетевой адаптер, dial-up соединение, спутниковое соединение, VPN-сервер, VPN-туннель).

IP Adress and Mask - IP адрес и маска подсети этого интерфейса.

Adapter Name - название связи (например “связь по ЛВС 2”).

Adapter Info - идентификационная строка адаптера, возвращенная драйвером устройства.

Add - добавляет новый dial-up интерфейс или VPN канал (см. ниже).

Edit - отображает подробную информацию и позволяет редактировать параметры интерфейса.

Remove - удаляет выбранный интерфейс из WinRoute.

Refresh - используйте эту кнопку, чтобы обновить список интерфейсов.

Dial-In - этот интерфейс представляет сервер удаленного доступа RAS (dial-up содединение сети) на хосте WinRoute. Этот интерфейс может использоваться для определения правил трафика для клиентов RAS которые присоединяются к серверу. Dial-In не может быть сконфигурирован или удален.

VPN сервер - этот интерфейс представляет сервер, который обеспечивает связь для частного VPN клиента Kerio Technologies. Кликните два раза на этом интерфейсе, или кликните Edit, чтобы редактировать назначения и параметры VPN сервера. VPN интерфейс сервера не может быть удален.

Кликните на кнопке Add, чтобы добавить новый интерфейс, dial-up или VPN туннель (то есть сервер-сервер VPN соединение).

Рисунок 3.3 – Меню настройки Routing Table

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

настройки подключения к Интернету (IP, маску сети);

прописать настройки локальной сет