Защита фирм от хакерских атак

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

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

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

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

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

Если отвечать на этот вопрос коротко, то, опять же, никак. Единственным способом затруднить осуществление  данной удаленной атаки, это использовать для общения с хостами и  с другими DNS-серверами только протокол TCP, а не UDP. Тем не менее, это только затруднит выполнение атаки - не забывайте  как про возможный перехват DNS-запроса, так и про возможность математического  предсказания начального значения TCP-идентификатора ISN.

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

Как защититься от навязывания ложного маршрута при  использовании протокола ICMP?

Атака, которая заключалась  в передаче на хост ложного ICMP Redirect сообщения о смене исходного  маршрута приводила как к перехвату  атакующим информации, так и к  нарушению работоспособности атакуемого хоста. Для того, чтобы защититься от данной удаленной атаки, необходимо либо фильтровать данное сообщение (используя Firewall или фильтрующий  маршрутизатор), не допуская его попадания  на конечную систему, либо соответствующим  образом выбирать сетевую ОС, которая  будет игнорировать это сообщение. Однако обычно не существует административных способов повлиять на сетевую ОС так, чтобы запретить ей изменять маршрут и реагировать на данное сообщение. Единственный способ, например, в случае ОС Linux или FreeBSD заключается в том, чтобы изменить исходные тексты и перекомпилировать ядро ОС. Очевидно, что такой экзотический для многих способ возможен только для свободно распространяемых вместе с исходными текстами операционных систем. Обычно на практике не существует иного способа узнать реакцию используемой у вас ОС на ICMP Redirect сообщение, как послать данное сообщение и посмотреть, каков будет результат. Эксперименты показали, что данное сообщение позволяет изменить маршрутизацию на ОС Linux 1.2.8, Windows '95 и Windows NT 4.0. Следует отметить, что продукты компании Microsoft не отличаются особой защищенностью от возможных удаленных атак, присущих IP-сетям. Следовательно, использовать данные ОС в защищенном сегменте IP-сети представляется нежелательным. Это и будет тем самым административным решением по защите сегмента сети от данной удаленной атаки.

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

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

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

Как защититься от подмены одной из сторон при взаимодействии с использованием базовых протоколов семейства 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).

3.2. Программно-аппаратные  методы защиты от удаленных  атак в сети Internet

К программно-аппаратным средствам  обеспечения информационной безопасности средств связи в вычислительных сетях относятся:

• аппаратные шифраторы сетевого трафика;
• методика Firewall, реализуемая на базе программно-аппаратных средств;
• защищенные сетевые криптопротоколы;
• программно-аппаратные анализаторы сетевого трафика;
• защищенные сетевые ОС.

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

Далее мы, по возможности  кратко, чтобы не повторять всем хорошо известную информацию, опишем данные средства защиты, применяемые  в Internet. При этом мы преследуем следующие  цели: во-первых, еще раз вернемся к мифу об "абсолютной защите" , которую якобы обеспечивают системы Firewall, очевидно, благодаря стараниям  их продавцов; во-вторых, сравним существующие версии криптопротоколов, применяемых  в Internet, и дадим оценку, по сути, критическому положению в этой области; и, в-третьих, ознакомим читателей с возможностью защиты с помощью сетевого монитора безопасности, предназначенного для осуществления динамического контроля за возникающими в защищаемом сегменте IP-сети ситуациями, свидетельствующими об осуществлении на данный сегмент одной из описанных в 4 главе удаленных атак.

. Методика Firewall как  основное программно-аппаратное  средство осуществления сетевой  политики безопасности в выделенном  сегменте IP-сети

В общем случае методика Firewall реализует следующие основные три функции:

1. Многоуровневая  фильтрация сетевого трафика.

Фильтрация обычно осуществляется на трех уровнях OSI:

сетевом (IP);

транспортном (TCP, UDP);

прикладном (FTP, TELNET, HTTP, SMTP и  т. д.).

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

2. Proxy-схема с  дополнительной идентификацией  и аутентификацией пользователей  на Firewall-хосте.

Proxy-схема позволяет, во-первых, при доступе к защищенному  Firewall сегменту сети осуществить  на нем дополнительную идентификацию  и аутентификацию удаленного  пользователя и, во-вторых, является  основой для создания приватных  сетей с виртуальными IP-адресами. Смысл proxy-схемы состоит в создании  соединения с конечным адресатом  через промежуточный proxy-сервер (proxy от англ. полномочный) на хосте  Firewall. На этом proxy-сервере и может  осуществляться дополнительная  идентификация абонента.

3. Создание приватных  сетей (Private Virtual Network - PVN) с "виртуальными" IP-адресами (NAT - Network Address Translation).

В том случае, если администратор  безопасности сети считает целесообразным скрыть истинную топологию своей  внутренней IP-сети, то ему можно порекомендовать  использовать системы Firewall для создания приватной сети (PVN-сеть). Хостам в PVN-сети назначаются любые "виртуальные" IP-адреса. Для адресации во внешнюю  сеть (через Firewall) необходимо либо использование  на хосте Firewall описанных выше proxy-серверов, либо применение специальных систем роутинга (маршрутизации), только через  которые и возможна внешняя адресация. Это происходит из-за того, что используемый во внутренней PVN-сети виртуальный IP-адрес, очевидно, не пригоден для внешней  адресации (внешняя адресация - это  адресация к абонентам, находящимся  за пределами PVN-сети). Поэтому proxy-сервер или средство роутинга должно осуществлять связь с абонентами из внешней  сети со своего настоящего IP-адреса. Кстати, эта схема удобна в том случае, если вам для создания IP-сети выделили недостаточное количество IP-адресов (в стандарте IPv4 это случается  сплошь и рядом, поэтому для создания полноценной IP-сети с использованием proxy-схемы достаточно только одного выделенного IP-адреса для proxy-сервера).

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

 
Рис. 2. Обобщенная схема полнофункционального хоста Firewall.

Однако администраторам IP-сетей, поддавшись на рекламу систем Firewall, не стоит заблуждаться на тот  счет, что Firewall это гарантия абсолютной защиты от удаленных атак в сети Internet. Firewall - не столько средство обеспечения  безопасности, сколько возможность  централизованно осуществлять сетевую  политику разграничения удаленного доступа к доступным ресурсам вашей сети. Да, в том случае, если, например, к данному хосту запрещен удаленный TELNET-доступ, то Firewall однозначно предотвратит возможность данного  доступа. Но дело в том, что большинство  удаленных атак имеют совершенно другие цели (бессмысленно пытаться получить определенный вид доступа, если он запрещен системой Firewall). Какие из рассмотренных  удаленных атак может предотвратить Firewall? Анализ сетевого трафика? Очевидно, нет! Ложный ARP-сервер? И да, и нет (для защиты вовсе не обязательно  использовать Firewall). Ложный DNS-сервер? Нет, к сожалению, Firewall вам тут не помощник. Навязывание ложного маршрута при  помощи протокола ICMP? Да, эту атаку  путем фильтрации ICMP-сообщений Firewall легко отразит (хотя достаточно будет  фильтрующего маршрутизатора, например Cisco). Подмена одного из субъектов TCP-соединения? Ответ отрицательный; Firewall тут абсолютно  не при чем. Нарушение работоспособности  хоста путем создания направленного  шторма ложных запросов или переполнения очереди запросов? В этом случае применение Firewall только ухудшит все  дело. Атакующему для того, чтобы  вывести из строя (отрезать от внешнего мира) все хосты внутри защищенного Firewall-системой сегмента, достаточно атаковать  только один Firewall, а не несколько  хостов (это легко объясняется  тем, что связь внутренних хостов с внешним миром возможна только через Firewall).