Илья Медведовский - Атака на Internet
В заключение заметим, что пользователь, который предпочел клиентскую операционную систему, решил осуществлять только неавторизованный доступ и смирился с удаленной атакой «отказ в обслуживании», может не читать следующие разделы главы.
Административные методы защиты от удаленных атак в сети Internet
Итак, уважаемый пользователь или не менее уважаемый сетевой администратор, вы все-таки решили попытаться защитить свою систему от разного рода удаленных воздействий. Конечно, самым правильным шагом в этом направлении будет приглашение специалиста по информационной безопасности, который вместе с вами постарается решить весь комплекс задач по обеспечению необходимого уровня безопасности для вашей распределенной ВС. Сначала необходимо определить, что (список контролируемых объектов и ресурсов РВС), от чего (анализ возможных угроз данной РВС) и как (разработка требований, определение политики безопасности и выработка административных и программно-аппаратных мер по обеспечению на практике разработанной политики безопасности) защищать.
Пожалуй, наиболее простыми и дешевыми являются именно административные методы защиты от информационных разрушающих воздействий, о чем и рассказывается далее.
Защита от анализа сетевого трафика
В начале четвертой главы рассматривалась атака, позволяющая кракеру с помощью программного прослушивания канала передачи сообщений в сети перехватывать любую информацию, которой обмениваются удаленные пользователи, если по каналу передаются только нешифрованные сообщения. Также было показано, что базовые прикладные протоколы удаленного доступа TELNET и FTP не предусматривают элементарную криптозащиту передаваемых по сети идентификаторов (имен) и аутентификаторов (паролей). Поэтому администраторам сетей мы порекомендуем не использовать эти базовые протоколы для предоставления удаленного авторизованного доступа к ресурсам своих систем и считать анализ сетевого трафика той постоянно присутствующей угрозой, которую невозможно устранить, но можно сделать бессмысленной, применяя стойкие криптоалгоритмы защиты IP-потока.
Защита от ложного ARP-сервера
Коротко напомним, что в главе 4 рассматривалась удаленная атака, использующая недостатки в механизме удаленного поиска на базе протокола ARP. В том случае, если у сетевой ОС отсутствует информация о соответствии IP-и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может прислать ложный ответ, и в дальнейшем весь трафик на канальном уровне окажется перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что для ликвидации данной атаки необходимо устранить причину ее возможного осуществления, которая заключается в отсутствии у ОС каждого хоста необходимой информации о соответствующих IP-и Ethernet-адресах всех остальных хостов внутри данного сегмента сети. Таким образом, самое простое решение – создать сетевым администратором статическую ARP-таблицу в виде файла (в ОС UNIX обычно /etc/ ethers), куда внести необходимую информацию об адресах. Данный файл устанавливается на каждый хост внутри сегмента, и, следовательно, у сетевой ОС отпадает необходимость в использовании удаленного ARP-поиска. Правда, отметим, что ОС Windows 95 это не помогает.
Защита от ложного 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-сети. Это и будет тем самым административным решением по защите от подобной удаленной атаки.
Защита от отказа в обслуживании
Как уже отмечалось, приемлемых способов защиты от отказа в обслуживании для стандарта IPv4 сети Internet нет и не может быть. Это связано с тем, что в IPv4 невозможен контроль за маршрутом сообщений. Поэтому нельзя обеспечить надежный контроль за сетевыми соединениями, так как у одного субъекта сетевого взаимодействия есть возможность занять неограниченное число каналов связи с удаленным объектом и при этом остаться анонимным. Из-за этого любой сервер в Internet может быть полностью парализован при помощи соответствующей удаленной атаки, рассмотренной в главе 4.
Единственное, что можно предложить для повышения надежности работы системы, подвергаемой данной атаке, – использовать как можно более мощные компьютеры. Чем больше число и частота работы процессоров, чем больше объем оперативной памяти, тем более надежной будет работа сетевой ОС, когда на нее обрушится направленный шторм ложных запросов на создание соединения. Кроме того, необходимо использование соответствующих вашим вычислительным мощностям операционных систем с внутренней очередью, способной вместить большое число запросов на подключение. Ведь если вы, например, установите на суперкомпьютер операционную систему Windows NT, у которой средняя длина очереди для одновременно обрабатываемых запросов около 50, а тайм-аут очистки очереди равен 9 секундам, то, несмотря на все вычислительные мощности компьютера, ОС будет полностью парализована атакующим (см. главу 4).
