1. Abstract В статье рассматривается безопасность семейства IP-протоколов. Описываютсявозможные типа атак, представлено несколько вариантов решения проблем.
2. Вступление Протоколы семейства IP являются основой построения сетей intranet иглобальной сети Internet. Несмотря на то, что разработка TCP/IP финансироваласьМинистерством обороны США, TCP/IP не обладает абсолютной защищенностьюи допускает различные типы атак, рассмотренные в данной статье.
Для того, чтобы предпринять подобные атаки, крэкер должен обладать контролемнад одной из систем, подключенной к Internet. Это возможно, например, вслучае, когда крэкер взломал какую-то систему или использует собственныйкомпьютер, имеющий соединение с Internet (для многих атак достаточно иметьPPP-доступ)
В данной статье не рассматриваются возможные физические атаки (например,непосредственный съем информации через ethernet или перехват трафика междурадио-мостами). Все внимание обращено на программную реализацию.
Статья подразумевает знакомство читателя с TCP/IP и ориентирована наадминистраторов в области безопасности. Официальное описание семействаIP-протоколов можно найти в RFC, при первомзнакомстве с TCP/IP может оказать неоценимую помощь великолепная книга"TCP/IP Illustrated"by R.Stevens
Автор оставляет в стороне моральные вопросы, т.к. считает, что толькополная информация может помочь подготовиться к возможным атакам и защититьсяот них. Принцип "Безопасность через незнание"(Security through Obscurity) редко оправдывает себя.
Атаки на TCP/IP можно разделить на два вида: пассивные и активные.
3. Пассивные атаки на уровне TCP При данные типе атак крэкеры никаким образом не обнаруживают себя ине вступают напрямую во взаимодействие с другими системами. Фактическивсе сводиться к наблюдению за доступными данными или сессиями связи.
3.1. Подслушивание Атака заключаются в перехвате сетевого потока и его анализе. Англоязычныетермин -- "sniffing"
Для осуществления подслушивания крэкеру необходимо иметь доступ к машине,расположенной на пути сетевого потока, который необходимо анализировать;например, к маршрутизатору или PPP-серверу на базе UNIX. Если крэкеру удастсяполучить достаточные права на этой машине, то с помощью специального программногообеспечения сможет просматривать весь трафик, проходящий через заданныеинтерфейс.
Второй вариант -- крэкер получает доступ к машине, которая расположенав одном сегменте сети с системой, которой имеет доступ к сетевому потоку.Например, в сети "тонкий ethernet" сетевая карта может быть переведенав режим, в котором она будет получать все пакеты, циркулирующие по сети,а не только адресованной ей конкретно. В данном случае крэкеру не требуетсядоступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуацияв университетских сетях)
Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключенияниже), крэкер, используя соответствующий инструментарий, может перехватыватьTCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователейи их пароли.
Следует заметить, что данный тип атаки невозможно отследить, не обладаядоступом к системе крэкера, поскольку сетевой поток не изменяется. Единственнаянадежная защита от подслушивания -- шифрование TCP/IP-потока (например,secure shell) или использованиеодноразовых паролей (например, S/KEY)
Другое вариант решения - использование интеллектуальных свитчей и UTP,в результате чего каждая машина получает только тот трафик, что адресованей.
У каждой палки два конца. Естественно, подслушивание может быть и полезно.Так, данный метод используется большим количеством программ, помогающихадминистраторам в анализе работы сети (ее загруженности, работоспособностии т.д.). Один из ярких примеров -- общеизвестный tcpdump
4. Активные атаки на уровне TCP При данном типе атак крэкер взаимодействует с получателем информации,отправителем и/или промежуточными системами, возможно, модифицируя и/илифильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся техническисложными в реализации, однако для хорошего программиста не составляет трудареализовать соотвествующий инструментарий. К сожалению, сейчас такие программыстали доступны широким массам пользователей (например, см. раздел про SYN-затопление).
Активные атаки можно разделить на две части. В первом случае крэкерпредпринимает определенные шаги для перехвата и модификации сетевого потокаили попыток "притвориться" другой системой. Во втором случае протокол TCP/IPиспользуется для того, чтобы привести систему-жертву в нерабочее состоянии.
Обладая достаточными привилегиями в Unix (или попросту используя DOSили Windows, не имеющие системы ограничений пользователей), крэкер можетвручную формировать IP-пакеты и передавать их по сети. Естественно, полязаголовка пакета могут быть сформированы произвольным образом. Получивтакой пакет, невозможно выяснить откуда реально он был получен, посколькупакеты не содержат пути их прохождения. Конечно, при установке обратногоадреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответна отосланный пакет. Однако, как мы увидим, часто это и не требуется.
Возможность формирования произвольных IP-пакетов является ключевым пунктомдля осуществления активных атак.
4.1. Предсказание TCP sequence number Данная атака была описана еще Робертом Моррисом (Robert T. Morris)в AWeakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера- притвориться другой системой, которой, например, "доверяет" система-жертва(в случае использования протокола rlogin/rshдля беспарольного входа). Метод также используется для других целей --например, для использовании SMTP жертвы для посылки поддельных писем.
4.1.1. Описание Вспомним, что установка TCP-соединения происходит в три стадии ( 3-wayhandshake): клиент выбирает и передает серверу sequencenumber (назовем его C-SYN), в ответ на это сервер высылаетклиенту пакет данных, содержащий подтверждение ( C-ACK) и собственныйsequence number сервера ( S-SYN). Теперь уже клиент должен выслатьподтверждение ( S-ACK). Схематично это можно представить так:
После этого соединение считается установленным и начинается обмен данными.При этом каждый пакет имеет в заголовке поле для sequencenumber и acknowledge number. Данныечисла увеличиваются при обмене данными и позволяют контролировать корректностьпередачи.
Предположим, что крэкер может предсказать, какой sequence number ( S-SYNпо схеме) будет выслан сервером. Это возможно сделать на основе знанийо конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number,которое будет использовано при установке следующего значения, каждую секундуувеличивается на 125000. Таким образом, послав один пакет серверу, крэкерполучит ответ и сможет (возможно, с нескольких попыткок и с поправкой наскорость соединения) предсказать sequence number для следующего соединения.
Если реализация TCP/IP использует специальный алгоритм для определенияsequence number, то он может быть выяснен с помощью посылки несколькихдесятков пакетов серверу и анализа его ответов.
Итак, предположим, что система A доверяет системе B, так,что пользователь системы B может сделать "rloginA"_ и оказаться на A, не вводя пароля. Предположим, что крэкеррасположен на системе C. Система A выступает в роли сервера,системы B и C - в роли клиентов.
Первая задача крэкера - ввести систему B в состояние, когда онане сможет отвечать на сетевые запросы. Это может быть сделано несколькимиспособами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна,должно хватить. Другой вариант -- использование описанными в следующихразделах методов.
После этого крэкер может попробовать притвориться системой B,для того, что бы получить доступ к системе A (хотя бы кратковременный).
Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.
Крэкер высылает IP-пакет, в котором в качестве обратного адреса указануже адрес системы B.
Система A отвечает пакетом с sequence number, который направляетсясистеме B. Однако система B никогда не получит его (она выведенаиз строя), как, впрочем, и крэкер. Но он на основе предыдущего анализадогадывается, какой sequence number был выслан системе B
Крэкер подтверждает "получение" пакета от A, выслав от имени Bпакет с предполагаемым S-ACK (заметим, что если системы располагаютсяв одном сегменте, крэкеру для выяснения sequence number достаточно перехватитьпакет, посланный системой A). После этого, если крэкеру повезлои sequence number сервера был угадан верно, соединение считается установленным.
Теперь крэкер может выслать очередной фальшивый IP-пакет, который будетуже содержать данные. Например, если атака была направлена на rsh, он можетсодержать команды создания файла .rhosts илиотправки /etc/passwd крэкеру по электроннойпочте.
Представим это в виде схемы:
4.1.2. Детектирование и защита Простейшим сигналом IP-spoofing будутслужить пакеты с внутренними адресами, пришедшие из внешнего мира. Программноеобеспечение маршрутизатора может предупредить об этом администратора. Однаконе стоит обольщаться - атака может быть и изнутри Вашей сети.
В случае использования более интеллектуальных средств контроля за сетьюадминистратор может отслеживать (в автоматическом режиме) пакеты от систем,которые в находятся в недоступном состоянии. Впрочем, что мешает крэкеруимитировать работу системы B ответом на ICMP-пакеты?
Какие способы существуют для защиты от IP-spoofing? Во-первых, можноусложнить или сделать невозможным угадывание sequence number (ключевойэлемент атаки). Например, можно увеличить скорость изменения sequence numberна сервере или выбирать коэффициент увеличения sequence number случайно(желательно, используя для генерации случайных чисел криптографически стойкийалгоритм).
Если сеть использует firewall (или другойфильтр IP-пакетов), следует добавить ему правила, по которым все пакеты,пришедшие извне и имеющие обратными адресами из нашего адресного пространства,не должны пропускаться внутрь сети. Кроме того, следует минимизироватьдоверие машин друг другу. В идеале не должны существовать способа, напрямуюпопасть на соседнюю машину сети, получив права суперпользователя на однойиз них. Конечно, это не спасет от использования сервисов, не требующихавторизации, например, IRC (крэкер может притвориться произвольной машинойInternet и передать набор команд для входа на канал IRC, выдачи произвольныхсообщений и т.д.).
Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а(при условии, что используются криптографически стойкие алгоритмы).
Для того, чтобы уменьший число таких атак, рекомендуется также настроитьfirewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющихадреса, не принадлежащие нашему адресному пространству. Это защитит мирот атак из внутренней сети, кроме того, детектирование подобных пакетовбудет означать нарушение внутренней безопасности и может помочь администраторув работе.
4.2. IP Hijacking Если в предыдущем случае крэкер инициировал новое соединение, то вданном случае он перехватывает весь сетевой поток, модифицируя его и фильтруяпроизвольным образом. Метод является комбинацией 'подслушивания' и IP spoofing'а.
4.2.1. Описание Необходимые условия -- крэкер должен иметь доступ к машине, находящейсяна пути сетевого потока и обладать достаточными правами на ней для генерациии перехвата IP-пакетов.
Напомним, что при передаче данных постоянно используются sequence numberи acknowledge number (оба поля находятся в IP-заголовке). Исходя из ихзначения, сервер и клиент проверяют корректность передачи пакетов.
Существует возможность ввести соединение в "десинхронизированное состояние",когда присылаемые сервером sequence number и acknowledge number не будутсовпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер,"прослушивая" линию, может взять на себя функции посредника, генерируякорректные пакеты для клиента и сервера и перехватывая их ответы.
Метод позволяет полностью обойти такие системы защиты, как, например,одноразовые пароли, поскольку крэкер начинает работу уже после того, какпроизойдет авторизация пользователя.
Есть два способа рассинхронизировать соединение
4.2.1.1. Ранняя десинхронизация Соединение десинхронизируется на стадии его установки.
Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующейего сессии
Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакеттипа RST (сброс), конечно, с корректным sequence number, и, немедленно,вслед за ним фальшивый C-SYN-пакет от имени клиента
Сервер сбрасывает первую сессию и открывает новую, на том же порту, ноуже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет.
Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию,высылает серверу S-ACK-пакет от имени клиента.
Итак, клиент и сервер находятся в состоянии ESTABLISHED,однако сессия десинхронизирована.
Представим это в виде схемы:
Естественно, 100% срабатывания у этой схемы нет, например, она не застрахованаот того, что по дороге не потеряются какие-то пакеты, посланные крэкером.Для корректной обработки этих ситуаций программа должна быть усложнена.
4.2.1.2. Десинхронизация нулевыми данными В данном случае крэкер прослушивает сессию и в какой-то момент посылаетсерверу пакет с "нулевыми" данными, т.е. такими, которые фактически будутпроигнорированы на уровне прикладной программы и не видны клиенту (например,для telnet это может быть данные типа IAC NOP IACNOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно,что после этого сессия переходит в десинхронизированное состояние.
4.2.2. ACK-буря Одна из проблем IP Hijacking заключается в том, что любой пакет, высланныйв момент, когда сессия находится в десинхронизированном состоянии вызываеттак называемый ACK-бурю. Например, пакет выслан сервером, и дляклиента он является неприемлимым, поэтому тот отвечает ACK-пакетом.В ответ на этот неприемлимый уже для сервера пакет клиент вновь получаетответ... И так до бесконечности.
К счастью (или к сожалению?) современные сети строятся по технологиям,когда допускается потеря отдельных пакетов. Поскольку ACK-пакетыне несут данных, повторных передачи не происходит и "буря стихает".
Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает"себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединенияхтипа SLIP - ненамного больше.
4.2.3. Детектирование и защита> Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которыебудут контролировать переход в десинхронизированное состояние, обмениваясьинформацией о sequence number/acknowledge number. Однако в данному случаемы не застрахованы от крэкера, меняющего и эти значения.
Поэтому более надежным способом является анализ загруженности сети,отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретныхсредств контроля за сетью.
Если крэкер не потрудиться поддерживать десинхронизированное соединениедо его закрытия или не станет фильтровать вывод своих команд, это такжебудет сразу замечено пользователем. К сожалению, подавляющее большинствопросто откруют новую сессию, не обращаясь к администратору.
Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрованиеTCP/IP-трафика (на уровне приложений - secure shell)или на уровн протокола - IPsec). Это исключаетвозможность модификации сетевого потока. Для защиты почтовых сообщенийможет применяться PGP.
Следует заметить, что метод также не срабатывает на некоторых конкретныхреализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливогозакрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречныйRST-пакет. Это делает невозможным раннюю десинхронизацию.
Для более глубокого ознакомления с этой атакой рекомендуется обратитьсяк IP Hijacking(CERT).
4.3. Пассивное сканирование Сканирование часто применяется крэкерами для того, чтобы выяснить,на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычнаяпрограмма-сканер последовательно открывает соединения с различными портами.В случае, когда соединение устанавливается, программа сбрасывает его, сообщаяномер порта крэкеру.
Данный способ легко детектируются по сообщениям демонов, удивленныхмгновенно прерваным после установки соединением, или с помощью использованияспециальных программ. Лучшие из таких программ обладают некоторыми попыткамивнести элементы искуственного элемента в отслеживание попыток соединенияс различными портами.
Однако крэкер может воспользоваться другим методом -- пассивным сканированием(английский термин "passive scan"). При егоиспользовании крэкер посылает TCP/IP SYN-пакет на все порты подряд(или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединенияизвне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты.Проанализировав данные ответ, крэкер может быстро понять, на каких портахработают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолженне будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализациякрэкера, если он не предпримет специальных мер).
Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединениене устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать
резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED.(при условии, что крэкер не посылает в ответ RST)
прием от клиента RST-пакета в ответ на SYN/ACK.
К сожалению, при достаточно умном поведении крэкера (например, сканированиес низкой скоростью или проверка лишь конкретных портов) детектировать пассивноесканирование невозможно, поскольку оно ничем не отличается от обычных попытокустановить соединение.
В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы,доступ к которым не требуется извне.
4.4. Затопление ICMP-пакетами Традиционный англоязычный термин -- "ping flood".Появился он потому, что программа "ping", предназначенная для оценки качествалинии, имеет ключ для "агрессивного" тестирования. В этом режиме запросыпосылаются с максимально возможной скоростью и программа позволяет оценить,как работает сеть при максимальной нагрузке.
Данная атака требует от крэкера доступа к быстрым каналам в Интернет.
Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHOREQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателяотвечает на подобный запрос пакетом ICMP ECHO REPLY.Получив его ping выдает скорость прохождения пакета.
При стандартном режиме работы пакеты выслаются через некоторые промежуткивремени, практически не нагружая сеть. Но в "агрессивном" режиме потокICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии,лишив ее способности передавать полезную информацию.
Естественно, случай с ping является частным случаем более общей ситуации,связанный с перегрузкой каналов. Например, крэкер может посылать множествоUDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятымправилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакетыстрочками по 80 байт.
Заметим, что крэкер может также подделывать обратный адрес подобныхпакетов, затрудняя его обнаружение. Отследить его поможет разве что скоординированнаяработа специалистов на промежуточных маршрутизаторах, что практически нереально.
Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходнымадресом, указывающем на жертву, на broadcast-адресакрупных сетей. В результате каждая из машин ответит на этот фальшивый запрос,и машина-отправитель получит больше количество ответов. Посылка множествоbroadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей,можно вызвать резкой заполненение канала "жертвы".
Приметы затопления - резко возросшая нагрузка на сеть (или канал) иповышение количество специфических пакетов (таких, как ICMP).
В качестве защиты можно порекомендовать настройку маршрутизаторов, прикоторых они будут фильтровать тот же ICMP трафик, превышающие некоторуюзаданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться,что Ваши машины не могут служить источником ping flood'а, ограничьте доступк ping (например, многие реализации
4.5. Локальная буря Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим"локальные бури" на пример UDP-бури. Как правило, по умолчанию системыподдерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылаетсяназад), 19 ("знакогенератор", в ответ на полученный пакет отправителю выслаетсястрока знакогенератора) и других (date etc).
В данном случае крэкер может послать единственный UDP-пакет, где в качествеисходного порта будет указан 7, в качестве получателя - 19-й, а в качествеадреса получателя и отправителя будут указаны, к примеру, две машины вашейсети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, котораяпопадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19..и так до бесконечности.
Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленнуюнагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться.Как недавно стало известно, данная атака временно выводит из строя (доперезагрузки) некоторые старые модели маршрутизаторов.
Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны(в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMPдостаточно пары фальшивых пакетов)
В качестве защиты стоит еще раз порекомендовать не пропускать в сетипакеты с внутренними адресам, но пришедшие извне. Также рекомендуется закрытьна firewall использование большинства сервисов.
4.6. Затопление SYN-пакетами Пожалуй, затопление SYN-пакетами ("SYN flooding") - самый известныйспособ напакостить ближнему, с того времени, как хакерский электронныйжурнал "2600" опубликовал исходные текстыпрограммы, позволяющие занятьсе этим даже неквалифицированным пользователям.Следует заметить, что впервые эта атака была упомянута еще в 1986 годувсе тем же Робертом Т. Моррисом.
Вспомним, как работает TCP/IP в случае входящих соединений. Системаотвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводитсессию в состояние SYN_RECEIVED и заноситее в очередь. Если в течении заданного времени от клиента не придет S-ACK,соединение удаляется из очереди, в противном случае соединение переводитсяв состояние ESTABLISHED.
Рассмотрим случай, когда очередь входных соединений уже заполнена, асистема получает SYN-пакет, приглашающий к установке соединения.По RFC он будет молча проигнорирован.
Затопление SYN-пакетами основано на переполнении очереди сервера,после чего сервер перестает отвечать на запросы пользователей. Самая известнаяатака такого рода - атака на Panix, нью-йоркского провайдера. Panix неработал в течении 2-х недель.
В различных системах работа с очередью реализована по разному. Так,в BSD-системах, каждый порт имеет свою собственную очередь размером в 16элементов. В системах SunOS, напротив, такогоразделения и нет и система просто располагает большой общей очередью. Соответственно,для того, что бы заблокировать, к примеру, WWW-порт на BSDдостаточно 16 SYN-пакетов, а для Solaris 2.5их количество будет гораздо больше.
После истечение некоторого времени (зависит от реализации) система удаляетзапросы из очереди. Однако ничего не мешает крэкеру послать новую порциюзапросов. Таким образом, даже находясь на соединение 2400 bps, крэкер можетпосылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер,поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректированав последних версиях FreeBSD)
Как обычно, крэкер может воспользоваться случайными обратными IP-адресамипри формировании пакетов, что затрудняет его обнаружение и фильтрацию еготрафика.
Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединитсяс данным портом. В качестве защиты можно порекомендовать патчи, которыереализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать,если к Вашей системе защита от SYN-затопления, обратитесь к поставщикусистемы.
Другой вариант защиты - настроить firewall так, что бы все входящиеTCP/IP-соединения устанавливал он сам, и только после этого перебрасывалих внутрь сети на заданную машину. Это позволит Вам ограничить syn-затоплениеи не пропустить его внутрь сети.
