Атака на Internet
Шрифт:
Принципы доступности, удобства, быстродействия и функциональности вычислительной системы антагонистичны принципам ее безопасности.
Данная аксиома очевидна: чем более доступна, удобна, быстра и многофункциональна ВС, тем она менее безопасна. Например, служба DNS: удобно, но опасно.
Вернемся к выбору пользователем клиентской сетевой ОС. Это, кстати, один из весьма здравых шагов, ведущих к сетевой политике изоляционизма. Данная сетевая политика безопасности заключается в осуществлении как можно более полной изоляции своей вычислительной системы от внешнего мира. Также одним из шагов к обеспечению политики является, к примеру, использование систем Firewall, позволяющих создать выделенный защищенный сегмент (например, приватную сеть), отделенный от глобальной сети. Конечно, ничто не мешает довести политику сетевого
Итак, пусть пользователь Internet решил для доступа в сеть применить только клиентскую сетевую ОС и осуществлять с ее помощью неавторизованный доступ. Проблемы с безопасностью решены? Нет! Мы чуть не забыли про типовую удаленную атаку «отказ в обслуживании»! Для этой атаки абсолютно не имеет значения ни вид доступа, ни тип сетевой ОС (хотя клиентская ОС с точки зрения защиты от атаки несколько предпочтительнее). Эта атака, используя фундаментальные пробелы в безопасности протоколов и инфраструктуры сети Internet, поражает сетевую ОС на хосте пользователя с одной единственной целью – нарушить его работоспособность (см. главу 4). Напомним, что для атаки с навязыванием ложного маршрута при помощи протокола ICMP, целью которой является отказ в обслуживании, ОС Windows 95 или Windows NT – наиболее лакомая цель (можно поразить любой хост в сети Internet, на котором установлена данная ОС, – см. раздел «Навязывание хосту ложного маршрута с использованием протокола ICMP»). Бедному пользователю в таком случае остается надеяться на то, что его скромный хост не представляет никакого интереса для атакующего, который может нарушить работоспособность хоста разве что из желания просто напакостить.
В заключение заметим, что пользователь, который предпочел клиентскую операционную систему, решил осуществлять только неавторизованный доступ и смирился с удаленной атакой «отказ в обслуживании», может не читать следующие разделы главы.
Административные методы защиты от удаленных атак в сети Internet
Итак, уважаемый пользователь или не менее уважаемый сетевой администратор, вы все-таки решили попытаться защитить свою систему от разного рода удаленных воздействий. Конечно, самым правильным шагом в этом направлении будет приглашение специалиста по информационной безопасности, который вместе с вами постарается решить весь комплекс задач по обеспечению необходимого уровня безопасности для вашей распределенной ВС. Сначала необходимо определить, что (список контролируемых объектов и ресурсов РВС), от чего (анализ возможных угроз данной РВС) и как (разработка требований, определение политики безопасности и выработка административных и программно-аппаратных мер по обеспечению на практике разработанной политики безопасности) защищать.
Пожалуй, наиболее простыми и дешевыми являются именно административные методы защиты от информационных разрушающих воздействий, о чем и рассказывается далее.
Защита от анализа сетевого трафика
В начале четвертой главы рассматривалась атака, позволяющая кракеру с помощью программного прослушивания канала передачи сообщений в сети перехватывать любую информацию, которой обмениваются удаленные пользователи, если по каналу передаются только нешифрованные сообщения. Также было показано, что базовые прикладные протоколы удаленного доступа TELNET и FTP не предусматривают элементарную криптозащиту передаваемых по сети идентификаторов (имен) и аутентификаторов (паролей). Поэтому администраторам сетей мы порекомендуем не использовать эти базовые протоколы для предоставления удаленного авторизованного доступа к ресурсам своих систем и считать анализ сетевого трафика той постоянно присутствующей угрозой, которую невозможно устранить, но можно сделать бессмысленной, применяя стойкие криптоалгоритмы защиты IP-потока.
Защита от ложного ARP-сервера
Коротко напомним, что в главе 4 рассматривалась удаленная атака, использующая недостатки в механизме удаленного поиска на базе протокола ARP. В том случае, если у сетевой ОС отсутствует информация о соответствии IP-и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может прислать ложный ответ, и в дальнейшем весь трафик на канальном уровне окажется перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что для ликвидации данной атаки необходимо устранить причину ее возможного осуществления, которая заключается в отсутствии у ОС каждого хоста необходимой информации о соответствующих IP-и Ethernet-адресах всех остальных хостов внутри данного сегмента сети. Таким образом, самое простое решение – создать сетевым администратором статическую ARP-таблицу в виде файла (в ОС UNIX обычно /etc/ ethers), куда внести необходимую информацию об адресах. Данный файл устанавливается на каждый
Защита от ложного DNS-сервера
Из главы 4 следует, что использование службы DNS в ее нынешнем виде может позволить кракеру получить глобальный контроль над соединениями путем навязывания ложного маршрута через хост кракера – ложный DNS-сервер. Осуществление такой удаленной атаки, основанной на потенциальных уязвимостях службы DNS, приведет к катастрофическим последствиям для огромного числа пользователей Internet и станет причиной массового нарушения информационной безопасности глобальной сети. Далее для администраторов и пользователей Сети и для администраторов DNS-серверов предлагаются возможные административные методы предотвращения или затруднения данной удаленной атаки.
Как администратору сети защититься от ложного DNS-сервера
Если отвечать на вопрос защиты от ложного DNS-сервера коротко, то никак. Ни административно, ни программно нельзя защититься от атаки на существующую версию службы DNS. Оптимальное решение с точки зрения безопасности – вообще отказаться от применения службы DNS в вашем защищенном сегменте.
Конечно, совсем отказаться от использования имен при обращении к хостам будет очень неудобно, поэтому предложим следующее компромиссное решение: использовать имена, но отказаться от механизма удаленного DNS-поиска. Вы правильно догадались, что это возвращение к схеме, применявшейся до появления службы DNS с выделенными DNS-серверами. Тогда на каждой машине существовал файл hosts, в котором находилась информация об именах и соответствующих IP-адресах всех хостов в сети. Очевидно, что на сегодняшний день администратору в подобный файл можно внести информацию лишь о наиболее часто посещаемых пользователями данного сегмента серверах сети. Поэтому на практике выполнить данное решение чрезвычайно затруднительно и, видимо, нереально (что, например, делать с браузерами, которые используют URL с именами?).
Чтобы усложнить осуществление данной удаленной атаки (передача на хост ложного DNS-ответа без приема DNS-запроса), можно предложить администраторам использовать протокол TCP вместо протокола UDP, который устанавливается по умолчанию (хотя из документации далеко не очевидно, как его заменить).
Общий неутешительный вывод таков: в сети Internet при использовании существующей версии службы DNS нет приемлемого решения для защиты от ложного DNS-сервера (и не откажешься, как в случае с ARP, и использовать опасно).
Как администратору DNS-сервера защититься от ложного DNS-сервера
Единственный способ затруднить осуществление данной удаленной атаки – использовать для общения с хостами и с другими DNS-серверами только протокол TCP, но не UDP. Но не забывайте как про возможный перехват DNS-запроса, так и про математическое предсказание начального значения TCP-идентификатора ISN (см. раздел «Подмена одного из субъектов TCP-соединения в сети Internet»).
В заключение можно порекомендовать для всей сети Internet поскорее перейти либо к более защищенной версии службы DNS, либо принять единый стандарт на защищенный протокол. Осуществить этот переход, несмотря на все колоссальные расходы, просто необходимо, иначе Internet окажется на коленях перед возрастающими успешными попытками нарушения безопасности.
Защита от навязывания ложного маршрута
Напомним, что в главе 4 рассматривалась удаленная атака передачи на хост ложного сообщения ICMP Redirect о смене исходного маршрута. Эта атака приводила как к перехвату атакующим информации, так и к нарушению работоспособности атакуемого хоста. Для того чтобы защититься от такой атаки, необходимо либо фильтровать данное сообщение (используя Firewall или фильтрующий маршрутизатор), не допуская его попадания на конечную систему, либо соответствующим образом выбирать сетевую ОС, которая проигнорирует это сообщение. Однако обычно не существует административных способов повлиять на сетевую ОС так, чтобы запретить ей изменять маршрут и реагировать на данное сообщение. Единственный способ (например, в случае ОС Linux или FreeBSD) заключается в том, чтобы изменить исходные тексты и перекомпилировать ядро ОС. Очевидно, что такой экзотический подход возможен только для операционных систем, свободно распространяемых вместе с исходными текстами. Другого способа узнать реакцию используемой у вас ОС на сообщение ICMP Redirect, как послать сообщение и посмотреть, каков будет результат, на практике не существует. Эксперименты показали, что данное сообщение позволяет изменить маршрутизацию на ОС Windows 95 и Windows NT 4.0. Отметим, что продукты компании Microsoft не отличаются особой защищенностью от возможных удаленных атак, присущих IP-сетям (как видно из главы 4). Следовательно, нежелательно использовать данные ОС в защищенном сегменте IP-сети. Это и будет тем самым административным решением по защите от подобной удаленной атаки.