Защита от хакеров корпоративных сетей
Шрифт:
Синхронизация TCP
Известен ряд атак на чисто IP-соединения. Когда начинают анализировать уровни, расположенные над IP-протоколом, то присущая им дополнительная сложность и предъявляемые к ним требования способствуют возникновению новых проблем синхронизации. В настоящее время в большинстве систем обнаружения вторжения реализовано исследование «всех состояний» TCP.
Для исследования «всех состояний» необходим ряд конструкторских решений идентификации потока соединений во время исследования передаваемых по протоколу TCP данных. Система обнаружения вторжения должна обладать всеми возможностями для реконструирования потока данных точно таким же способом, как и хост-адресат. Если системе обнаружения вторжения не предоставить подобной возможности, то злоумышленник сможет избежать обнаружения. Информация
• создание блока TCB;
• повторная сборка потока;
• искажение блока TCB.
Для идентификации новых сессий, контроля открытых соединений и определения соответствующих моментов прекращения контроля системе обнаружения вторжения следовало бы принять участие в каждом из этих трех процессов.
Создание блока TCB
Осознание того, каким образом можно начать контролировать соединение, приводит к пониманию некоторых интересных проблем. Следует ли сетевой системе обнаружения вторжения в момент построения блока TCB контролировать установку соединения по протоколу TCP? Может ли сетевая система обнаружения вторжения эффективно создать блок TCB для соединения, на которое она не получила пакет с флажком SYN (это касается соединений, которые были активны еще до начала контроля)?
Любому способу создания блока TCB сопутствуют свои уникальные проблемы. Желательно, чтобы у системы обнаружения вторжения была возможность контролировать соединения, для которых трехэтапное установление связи (3WH – Three-Way Handshake) было выполнено еще до начала контроля. Если не предоставить такой возможности системе обнаружения вторжения, то злоумышленник сможет установить соединение и сколь угодно долго выжидать благоприятного для него момента, например когда система обнаружения вторжения будет перезагружена и не сможет проследить за уже установленным соединением.
Для создания блока TCB можно использовать только пакеты с установленным флажком ACK. Этот способ известен как синхронизация на данных (synching on data). Он характеризуется дополнительными преимуществами идентификации сессий, для которых не был проанализирован трехэтапный процесс установления связи. Реализация рассматриваемого случая неминуемо столкнется с рядом препятствий. Одно из них состоит в том, что система обнаружения вторжения, даже проанализировав большой объем данных, не сможет различить пакеты, которые передаются вне рамок установленных соединений. Другой проблемой является то, что синхронизация на данных диктует необходимость проверки порядковых номеров. У злоумышленника может появиться возможность десинхронизации системы обнаружения вторжения путем фальсификации ошибочных данных перед попыткой атаки.
Альтернативный способ создания блока TCB основан на необходимости нахождения в потоке данных пакетов c комбинацией флажков SYN + ACK. Из-за того что у злоумышленника практически нет возможности заставить адресуемую сеть выслать ему пакет с установленным флажком ACK, система обнаружения вторжения может определить, какой хост является клиентом, а какой – сервером. Но система обнаружения вторжения может быть обманута при отслеживании многих соединений несуществующих хостов (атаки типа отказа в обслуживании DoS). Кроме того, пакеты с установленными флажками SYN + ACK могут быть легко фальсифицированы. Для этого совсем не обязательно наличие заключительного пакета с установленным флажком ACK от хоста-отправителя. Перед тем как положиться на этот способ создания блока TCB, следует предпринять дополнительные меры предосторожности.
Обычно лучшей линией поведения является комбинация названных способов. При этом должны быть учтены сильные стороны каждого из описанных способов и одновременно предпринята попытка устранить их слабые места.
Повторная сборка потока
Ряд проблем
Если не знать особенностей реализации стека протоколов TCP/IP в операционной системе хоста-адресата, то серьезную сложность представляет интерпретация его возможного поведения. В случае поступления избыточных TCP-сегментов некоторые хосты могут сохранять первый поступивший сегмент, в то время как другие могут отказаться от него, предпочитая иметь дело с сегментом, поступившим последним.
Если система обнаружения вторжения надеется поддерживать последовательное представление оцениваемого трафика, то она должна постоянно отслеживать для каждого соединения сообщаемые размеры окон. Для обеспечения максимальной производительности часто это значение подстраивается во время сессии. Если система обнаружения вторжения не сможет отслеживать размер TCP-окна, то это может привести к возникновению уязвимости и легко реализуемой злоумышленником атаки вставки. Злоумышленник просто посылает адресату данные с избыточным размером окна, а хост-получатель игнорирует получаемые пакеты, если размер окна не соответствует его ожиданиям.
Искажение блока TCB
Для исключения успешной атаки типа отказа в обслуживании (атаки типа DoS) в системе обнаружения вторжения должна быть реализована правильная «сборка мусора». При этом возможны некоторые проблемы. Соединение может быть завершено в любое время, как с уведомлением, так и без него. Некоторые системы могут не требовать присылки им сегментов RST в правильной последовательности. Протокол управляющих сообщений в сети Интернет (ICMP) может даже завершить соединение. Большинство хостов может считать сообщение протокола ICMP о недостижимости адресата сигналом для завершения сессии. Если система обнаружения вторжения не знает эту особенность, то она может десинхронизироваться и не сможет отслеживать новое соединение с подобными параметрами.
Почти не подвергается сомнению необходимость некоторого тайм-аута для любого установленного соединения. Он позволяет предотвратить некоторые логические ошибки, в конечном счете вызванные расходом памяти. Кроме того, отсутствие тайм-аута может привести к успешной реализации уже рассмотренных атак. Большинство хостов не используют для всех соединений сообщений, подтверждающих их активность. Это ставит систему обнаружения вторжения в невыгодное положение, когда злоумышленник может позволить себе выжидать столько, сколько ему потребуется, возможно, провоцируя при этом систему обнаружения вторжения на более активную «сборку мусора» (путем установления большого числа новых соединений). В случае успеха у злоумышленника появится возможность скрытно осуществить любую атаку, никак себя не обнаруживая.
Использование программ fragrouter и congestant
Теоретических знаний недостаточно для оценки производительности средств обеспечения безопасности. Снова и снова видно, как многие производители не учитывают предупреждение исследовательского сообщества. В сентябре 1999 года фирма Dug Song выпустила программу fragrouter, для того чтобы проиллюстрировать присущие сетевым системам обнаружения вторжения уязвимости (www.monkey.org/~dugsong/fragrouter-1.6.tar.gz). Преимущество программы fragrouter заключается в том, что она позволяет без всяких изменений использовать те же самые инструментальные средства и программы использования уязвимостей, что и злоумышленники. Оправдывая свое название, программа fragrouter реализует функции одной из разновидности фрагментированного маршрутизатора. Программа реализует большинство атак, описанных в статье Птасека (Ptacek) и Невшама (Newsham).