Илья Медведовский - Атака на 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 с именами?).