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

  Это довольно сложная комплексная задача, для решения которой необходимо определить, что (список контролируемых объектов и ресурсов РВС), от чего (анализ возможных угроз данной РВС) и как (выработка требований, определение политики безопасности и выработка административных и программно-аппаратных мер по обеспечению на практике разработанной политики безопасности) защищать.

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

   Как защититься от анализа сетевого трафика?

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

   Как защититься от ложного ARP-сервера?

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

  Основная причина успеха данной удаленной атаки - отсутствие необходимой нформации у ОС каждого хоста о соответствующих IP- и Ethernet-адресах всех остальных хостов внутри данного сегмента сети.

  Таким образом, самым простым решением будет создание сетевымадминистратором статической ARP-таблицы в виде файла (в ОС UNIX обычно  /etc/ethers), куда необходимо внести соответствую-щую информацию об адресах. Данный файл устанавливается на каждый хост внутри сегмента, и, следовательно, у сетевой ОС отпадает необходимость в использовании удаленного ARP-поиска. Правда, отметим, что ОС Windows '95 это не помогает.

   Как администратору сети защититься от ложного DNS-сервера?

  Если отвечать на этот вопрос коротко, то никак.

  Ни административно, ни программно нельзя защититься от атаки на существующую версию службы DNS. Оптимальным с точки зрения безопасности решением будет вообще отказаться от использования службы DNS в вашем защищенном сегменте! Конечно, совсем отказаться от использования имен при обращении к хостам для пользователей будет очень не удобно. Поэтому можно предложить следующее компромиссное решение: использовать имена, но отказаться от механизма удаленного DNS-поиска. Вы правильно догадались, что это возвращение к схеме, использовавшейся до появления службы DNS с выделенными DNS-серверами.

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

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

  Для затруднения осуществления данной удаленной атаки можно предложить администраторам воспользоваться для службы DNS вместо протокола UDP, который устанавливается по умолчанию, протокол TCP (хотя из документации далеко не очевидно, как его сменить). Это существенно затруднит для атакующего передачу на хост ложного DNS-ответа без приема DNS-запроса.

  Общий неутешительный вывод таков: в сети Internet при использовании существующей версии службы DNS не существует приемлемого решения для защиты от ложного DNS-сервера (и не откажешься, как в случае с ARP, и использовать опасно)!

   В заключение можно порекомендовать для всей сети Internet поскорее перейти либо к новой более защищенной версии службы DNS, либо принять единый стандарт на защищенный протокол. Сделать этот переход, несмотря на все колоссальные расходы, просто необходимо, иначе сеть Internet может быть просто поставлена на колени перед всевозрастающими успешными попытками нарушения ее безопасности при помощи данной службы!

      Как защититься от отказа в обслуживании?

  Как не раз уже отмечалось, нет и не может быть приемлемых способов защиты от отказа в обслуживании в существующем стандарте IPv4 сети Internet!
Это связано с тем, что в данном стандарте невозможен контроль за маршрутом сообщений. Поэтому невозможно обеспечить надежный контроль за сетевыми соединениями, так как у одного субъекта сетевого взаимодействия существует возможность занять неограниченное число каналов связи с удаленным объектом и при этом остаться анонимным. Из-за этого любой сервер в сети Internet может быть полностью парализован при помощи удаленной атаки.

  Единственное, что можно предложить для повышения надежности работы системы, подвергаемой данной атаке, - это использовать как можно более мощные компьютеры. Чем больше число и частота работы процессоров, чем больше объем оперативной памяти, тем более надежной будет работа сетевой ОС, когда на нее обрушится направленный шторм ложных запросов на создание соединения. Кроме того, необходимо использование соответствующих вашим вычислительный мощностям операционных систем с внутренней очередью, способной вместить большое число запросов на подключение. Ведь от того, что вы, например, поставите на супер ЭВМ операционную систему Linux или Windows NT, у которых длина очереди для одновременно обрабатываемых запросов около 10, а тайм-аут очистки очереди несколько минут, то, несмотря на все вычислительные мощности компьютера, ОС будет полностью парализована атакующим.

  Общий вывод по противодействию данной атаки в существующем стандарте IPv4 следующий: просто расслабьтесь и надейтесь на то, что вы ни для кого не представляете интереса, или покупайте супер ЭВМ с соответствующей ей сетевой ОС.

  Как защититься от подмены одной из сторон при взаимодействии с использованием базовых протоколов семейства TCP/IP Как отмечалось ранее, единственным базовым протоколом семейства TCP/IP, в котором изначально предусмотрена функция обеспечения безопасности соединения и его абонентов, является протокол транспортного уровня - протокол TCP. Что касается базовых протоколов прикладного уровня: FTP, TELNET, r-служба, NFS, HTTP, DNS, SMTP, то ни один из них не предусматривает дополнительную защиту соединения на своем уровне и оставляет решение всех проблем по обеспечению безопасности соединения протоколу более низкого транспортного уровня - TCP.

  Однако, вспомнив о возможных атаках на TCP-соединение, рассмотренных в п. 4.5, где было отмечен, что при нахождении атакующего в одном сегменте с целью атаки защититься от подмены одного из абонентов TCP-соединения в принципе невозможно, а в случае нахождения в разных сегментах из-за возможности математического предсказания идентификатора TCP-соединения ISN также реальна подмена одного из абонентов, несложно сделать вывод, что при использовании базовых протоколов семейства TCP/IP обеспечить безопасность соединения практически невозможно! Это происходит из-за того, что, к сожалению, все базовые протоколы сети Internet с точки зрения обеспечения информационной безопасности невероятно устарели.

  Единственно, что можно порекомендовать сетевым администраторам для защиты только от межсегментных атак на соединения - в качестве базового защищенного протокола использовать протокол TCP и сетевые ОС, в которых начальное значение идентификатора TCP-соединения действительно генерируется случайным образом (неплохой псевдослучайный алгоритм генерации используется в последних версиях ОС FreeBSD).