Я никогда не встречался с реальными случаями сканирования с помощью FIN-пакетов и не хочу ничего моделировать. При этом сканировании отправляется большое количество FIN-пакетов, хотя никакого TCP-соединения не было установлено. Мы уже обсуждали использование баз данных при изучении атак по FTP. Хорошая система обнаружения вторжений должна выявлять подобный трафик, состоящий из FIN-пакетов, для несуществующих соединений. Лично я видел только, как для сканирования использовались SYN-пакеты, и как они проникли сквозь брандмауэр Check Point.

Метод “от обратного”

Составление схем сетей по методу “от обратного” позволяет получить списки недостижимых сетей или хостов, а затем использовать эту информацию для предположительного представления о реально работающих компьютерах. Рассмотрим пример использования запросов службы DNS для этой цели. Если в локальной сети невозможно применить службу NAT и должны использоваться общедоступные IP-адреса, то необходимо гарантировать, что будут блокироваться все исходящие ICMP-сообщения о недостижимости. Это не остановит все попытки сканирования “от обратного”, но сделает бесполезными большинство из них. При изучении следующей трассировки помните о том, что основную опасность несут ответы от хоста router . mynet .net.

02:58:05.490 stealth.mappem.com.25984 > 172.30.69.23.2271:

'Ь R 0:0(0) ack 674719802 win 0

02:59:11.208 stealth.mappem.com.50620 > 172.16.7.158.1050:

R 0:0(0) ack 674719802 win 0 02:59:20.670 stealth.mappem.com.19801 > 192.168.184.174.1478:

R 0:0(0) ack 674719802 win 0 02:59:31.056 stealth.mappem.com.7960 > 192.168.242.139.1728:

Ъ R 0:0(0) ack 674719802 win 0

02:59:42.792 stealth.mappem.com.16106 > 172.16.102.105.1008:

R 0:0(0) ack 674719802 win 0 03:00:50.308 stealth.mappem.com.8986 > 172.16.98.61.1456:

^ R 0:0(0) ack 674719802 win 0

03:00:58.939 stealth.mappem.com.35124 > 192.168.182.171.1626:

R 0:0(0) ack 674719802 win 0 03:00:58.940 router.mynet.net > stealth.mappem.com:

'Ь icmp: host 192.168.182.171 unreachable

Ответы на DNS-запросы

Ниже представлен еще один вариант составления схемы сети “от обратного”. Сканирующий компьютер отправляет ответы на DNS-запросы, которые к нему никогда не поступали. Цель заключается в получении ответных ICMP-сообщений о недостижимости. Как указывалось ранее, такой метод позволяет избежать обнаружения сканирования. Программы выявления сканирования обнаружат подобную попытку, если злоумышленник будет слишком “энергичен” и захочет быстро прозондировать большое количество хостов. Также эти попытки выявляются при ретроспективном анализе или с помощью поиска в базах данных нарушений в работе приложений.

05:55:36.515566 stealth.com.domain > 172.29.63.63.20479: udp 06:46:18.542999 stealth .'сот.domain > 192.168.160.240.12793: udp 07:36:32.713298 stealth.com.domain > 172.29.185.48.54358: udp 07:57:01.634613 stealth.com.domain > 254.242.221.165.13043: udp 09:55:28.728984 stealth.com.domain > 192.168.203.163.15253: udp 10:38:53.862779 stealth.com.domain > 192.168.126.131.39915: udp 10:40:37.513176 stealth.com.domain > 192.168.151.126.19038: udp 10:44:28.462431 stealth.com.domain > 172.29.96.220.8479: udp 11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp

11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp 11:35:40.489523 router.mynet.net > stealth.com: icmp: host 192.168.7.246 unreachable

Поскольку подмена IP-адресов является, по существу, неотъемлемой частью атак отказа в обслуживании, то может возникнуть вопрос: “А не являются ли данные пакеты результатом подмены IP-адресов сетей 172.29, 192.168 и т.д. и ответа stealth.com на полученные запросы?”. Дело в том, что это не похоже на стандартные DNS-ответы, и нет никаких признаков того, что были отправлены какие-либо DNS-запросы.

При более углубленном анализе можно проверить, действительно ли хост stealth.com является DNS-сервером. Для этого воспользуйтесь командой nslookup, измените имя используемого DNS-сервера на stealth.com и попытайтесь определить имя хоста по какому-либо адресу. Если это удастся, значит, stealth. com действительно DNS-сервер и нет никаких загадок (к сожалению, по крайней мере на UNIX-хостах утилиту nslookup все чаще заменяет менее точная утилита dig). Если ответа не будет, значит, есть шанс, что это никакой не DNS-сервер, а хост злоумышленника (также возможно, что у вас просто нет доступа к этому DNS-серверу).

Следующая трассировка во многом напоминает предыдущую, так как в обоих случаях портом отправителя является ТСР-порт 53 (domain). Однако в данном случае пакеты поступают от различных отправителей. Есть предположения о том, что происходит?

11:19:30.885069 hostl.corecomm.net.53 > myhost1.com.21: S 7936:7936(0) win 1024

11:17:29.375069 host1.corecomm.net.53 > myhcst1.com.139: S 7936:7936(0) win 1024

11:15:32.115069 hostl.corecomm.net.53 > myhostl.com.23: S 7936:7936(0) win 1024

11:11:17.485069 host 1.corecomm.net.53 > myhostl.com.43981: S 7936:7936(0) win 1024

11:09:12.945069 host 1.corecomm.net.53 > myhostl.com.880: S 7936:7936(0)

^ win 1024

12:01:05.060000 host70.corecomm.net.53 > pci12.com.880: S 1738:1738(0) win 1024

12:03:24.820000 host70.corecomm.net.53 > pcll2.com.139: S 1738:1738(0) win 1024

12:06:12.620000 host70.corecomm.net.53 > pci12.com.21 : S 1738:1738(0)

Ь Win 1024

12:09:09.940000 host70.corecomm.net.53 > pcll2.com.43981 : S 1738:1738(0)

win 1024

12:09:57.960000 host70.corecomm.net.53 > pcll2.com.23 : S 1738:1738(0)

Win 1024

Это похоже на сканирование, например, хостов myhostl .com, рс112 .com и многих других хостов, которые не были показаны в этом фрагменте трассировки. Сканируются порты стандартных служб, а именно 21 (FTP), 23 (telnet) и 139 (NetBIOS Session Manager). Кроме того, проверяется несколько необычных номеров портов, например 43981 и 88 0. Можно высказывать любые предположения относительно попыток доступа к этим портам, но в данном случае основное внимание следует обратить на порт отправителя.

Трафик, поступающий с ТСР-порта 53, не блокируется для многих сетей, так как этот порт используется для “больших” DNS-ответов. В главе 6, “DNS”, указывалось, что для отправки DNS-ответов размером более 512 байт (вместо UDP протокола) DNS-сервер использует ТСР-порт 53. Предусмотрительные системные администраторы позволяют проходить таким пакетам только тогда, когда они поступают от хоста исходной сети и только, если номер порта получателя превышает 1023 (временный порт), что обязательно для “объемных” DNS-ответов.

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

Интересно отметить, что в приведенном выше отчете о сканировании порядковые номера TCP-сегментов повторяются при проверке портов каждого нового хоста. Обычно они должны изменяться для каждого создаваемого ТСР-сегмента. Еще один интересный момент, для обнаружения которого нужно проанализировать больше пакетов, чем приведено в этом фрагменте сканирования, в методе назначения порядковых номеров. В нашем фрагменте использованы только два порядковых номера: 7936 и 1738. Учитывая, что для хранения значений порядкового номера ТСР-сегмента предназначено 32-битовое поле, эти значения довольно малы, что необычно. Мы выбрали все порядковые номера, использованные в данном сканировании, перевели их в шестнадцатеричный формат и обнаружили отгадку. Старшие 16 бит порядкового номера ТСР-сегмента всегда были нулями. Это подтверждает факт манипуляции значениями порядковых номеров и становится сигнатурой для обнаружения данного сканирования.

Фрагменты, только фрагменты

Рассмотрим последний пример составления схемы сети по принципу “от обратного”. Как известно, только в первом фрагменте содержится информация о протоколе. Это используют злоумышленники для проникновения в сети, защищаемые устаревшими брандмауэрами и фильтрующими маршрутизаторами. Некоторые брандмауэры ошибочно принимают фрагменты за часть трафика, который уже успешно прошел проверку. Нет необходимости говорить о том, что большинство поставщиков уже устранили подобный недостаток.

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

18:32:21.050033 PROBER > 192.168.5.71: (frag 9019:480@552)

18:32:21.109287 PROBER > 192.168.5.72: (frag 9275:480@552)

18:32:21.178342 PROBER > 192.168.5.73: (frag 9531:4800552)

18:32:21.295332 PROBER > 192.168.5.74: (frag 9787:480@552)

18:32:21.344322 PROBER > 192.168.5.75: @(frag 10299:480@552) 18:32:21.384284 PROBER > 192.168.5.76: (frag 10555:480@552)

18:32:21.431136 PROBER > 192.168.5.77: (frag 11067:480@552)

18:32:21.478246 PROBER > 192.168.5.78: (frag 11579:4800552)

18:32:21.522631 PROBER > 192.168.5.79: (frag 11835:480@552)

Оценка времени ответа

Не так давно мы получили большой объем трафика, поступающего из самых разных мест и предназначенного Б^-серверам, но это не были 1)\78-запросы, и не было очевидным какое-либо вредоносное содержимое пакетов. На самом деле какие-то компании создали программы, которые пытались оценить наилучшее время ответа на \¥еЬ-запросы. Исследование показало, что большинство пользователей терпимо относятся ко времени задержки ответа продолжительностью до восьми секунд. Если это время будет большим, они обратятся к сайту конкурентов. Значит, от времени ответа зависит прибыльность и успех электронной коммерции, а так как необходимость - хороший стимул для изобретений, то для решения этой задачи были созданы специальные программы. В этом разделе мы обсудим шаблоны действий программы ЗБЫЭ.

Один из методов работы этой программы заключается в сопоставлении хоста пользователя с уполномоченным DNS-cepвepoм для хоста этого пользователя. Предпринимается попытка определить время ответа БКЗ-сервера на запрос. При этом предполагается, что уполномоченный В\т8-сервер и хост пользователя географически близки, что не всегда соответствует действительности. Почему просто не узнать расстояние до компьютера пользователя? Действительно это кажется более логичным, но многие сети хорошо защищены и доступ к хостам пользователей часто невозможен. Было решено, что вероятность доступа к ВЖ-серверу выше, что иногда правда, иногда - нет.

Трафик, генерируемый программой ЗБЫБ, вызывает многочисленные жалобы аналитиков, являясь причиной тревог со стороны систем обнаружения вторжений. Громкое недовольство легко пояснить тем, что трафик предназначен “неприкасаемым” ОКБ-серверам, обслуживающим все хосты организации. Многие не поняли причин происходящего и решили, что задействована какая-то новая атака. В конце концов, это несанкционированный сбор информации, независимо от того, используется ли она на благо конечных пользователей.

Давайте рассмотрим несколько сигнатур,, связанных с трафиком этого типа. Помните о том, что очень многие сайты используют это программное обеспечение, поэтому нет ничего удивительного в различии 1Р-адресов отправителя. Так как в уникальных сигнатурах обнаружения этого трафика были учтены различные 1Р-адреса отправителей, по ошибке его принимали за какой-то вид скоординированной атаки. Как вы убедитесь, это не так.

Эхо-запросы

Приведенный ниже отчет TCPdump демонстрирует действия, выполняемые для оценки времени ответа чужого DNS-сервера. Отправляется эхо-запрос, а время ответа оценивается по факту возвращения эхо-ответа.

10:25:44.070000 216.32.68.13 > mydns.com: icmp: echo request

10:25:44.070000 216.32.68.13 > mydns.com: icmp: echo request

10:25:44.070000 216.32.68.13 > mydns.com: icmp: echo request

10:30:01.530000 216.32.68.13 > mydns.com: icmp: echo request

10:30:01.530000 216.32.68.13 > mydns.com: icmp: echo request

10:30:01.550000 216.32.68.13 > mydns.com: icmp: echo request

10:30:25.660000 209.67.29.8 > mydns.com: icmp: echo request

10:30:25.660000 209.67.29.8 > mydns.com: icmp: echo request

10:30:25.670000 209.67.29.8 > mydns.com: icmp: echo request

10:32:12.520000 209.67.78.200 > mydns.com: icmp: -echo request

Но, как известно, эхо-запросы ICMP часто блокируются, ведь с их помощью можно составлять схемы сетей. Тогда злоумышленник или даже провайдер с помощью средства типа 3DNS может сконцентрировать все внимание на DNS-сервере.

Действительные DNS-запросы

Если DNS-сервер не ответил на эхо-запрос ICMP, а сервер, использующий 3DNS, настроен на дальнейшие попытки установления связи с чужим DNS-сервером, то отправляется трафик другого типа, как показано ниже.

216.32.68.11.3200 > mydns.com.53: 0 [0q] ТуреО (Class 0)? . (36)

mydns.com.53 > 216.32.68.11.3200: 0 FormErr [0q] 0/0/0 (12) DF

216.32.68.11.3201 > mydns.com.53: 256 [Oq] TypeO (Class 0)? . (36)

mydns.com.53 > 216.32.68.11.3201: 0 FormErr [Oq] 0/0/0 (12) OF

216.32.68.11.3202 > mydns.com.53: 512 [Oq] TypeO (Class 0)? . (36)

mydns.com.53 > 216.32.68.11.3202: 0 FormErr [Oq] 0/0/0 (12) DF

На самом деле DNS-запрос не посылается, просто на UDP-порт 53 отправляется “пустое” DNS-сообщение, содержащее одни нули. Программа TCPdump позволяет провести небольшое исследование DNS-сообщений и при выявлении пустых полей сообщает об этом. Например, строка 0q означает, что в DNS-сообщении нет полезных запросов. Анализатор пакетов TCPdump уведомляет об этом поле и обо всех других полях, заполненных нулями. Получение этого DNS-сообщения вызывает ответное сообщение об ошибке от mydns . com, которое и будет использовано для определения времени ответа.

Запрос на иОР-порт 33434

Если предыдущие методы опроса DNS-cepвepa не дали результата, используется следующий.

209.67.78.203.3310 > туапэ.сот.33434: udp 36 [^1 1]

209.67.78.203.3311 > туЗпэ. сот. 33434: udp 36 (^1 2)

216.32.68.10.3307 > mydns.com.33434: udp 36 [^1 1]

216.32.68.10.3308 > mydns.com.33434: udp 36 (^1 2)

216.32.68.10.3307 > mydns.com.33434: udp 36 [^1 1]

216.32.68.10.3308 > mydns.com.33434: udp 36 (^1 2)

209.67.78.200.3411 > туапв. сот. 33434 : udp 36 [«1 1]

209.67.78.2 00.3412 > mydns.сот.33434: udp 36 (^1 2)

Этот результат во многом напоминает отчет о действиях UNIX-утилиты traceroute. Она также использует UDP-соединения с портами с номером 33000 и выше, как и в данном случае. Но есть и небольшое отличие, так как в стандартной реализации traceroute номера портов постоянно увеличиваются для каждого нового пакета. Здесь используется постоянный номер UDP-порта получателя 33434. Целью является получить ІСМР-сообщение о недостижимости порта, после чего программа 3DNS проводит оценку времени ответа DNS-сервера. Еще одной сигнатурой применения утилиты traceroute могут служить увеличивающиеся значения поля TTL.

Атака на порты с помощью syn/fin-пакетов | Обнаружение нарушений безопасности в сетях | Отправка tcp-сегмента на порт 53


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Сентябрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс