Главная    Почта    Новости    Каталог    Одноклассники    Погода    Работа    Игры     Рефераты     Карты
  
по Казнету new!
по каталогу
в рефератах

Защита компьютера от атак через интернет

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

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

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

       а)  Как администратору сети защититься от ложного 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 может  быть
просто поставлена  на  колени  перед  всевозрастающими  успешными  попытками
нарушения ее безопасности при помощи данной службы!

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

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

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

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

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

Защита компьютера от атак через интернет

 

Отправка СМС бесплатно

На правах рекламы


ZERO.kz
 
Модератор сайта RESURS.KZ