İstanbul'da iş ilanları

Category: traffic engineering

Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

Уже не раз рассказывал о протоколе ТСР, так что повторятся особо не буду, напомню лишь основные положения: Transmission Control Protocol описывается в RFC 793 и преимуществом его является надежность передачи данных от одной машины к другому устройству по сети интернет. Это означает, что ТСР гарантирует надежность передачи данных и автоматически определит пропущенные или поврежденные пакеты. Что для нас важно из его конструкции?

В общем виде заголовок ТСР пакета выглядит так:

Программа передает по сети некий буфер данных, ТСР разбивает данные на сегменты и дальше упаковывает сегменты в наборы данных. Из наборов данных формируются пакеты и уже они передаются по сети. У получателя происходит обратный процесс: из пакетов извлекаются набор данных, его сегменты, затем сегменты передаются в ТСР стек и там проверяются, потом собираются и передаются программе.

Sequence numbers

Данные разбиваются на сегменты, которые отдельными пакетами направляются по сети получателю. Возможна ситуация, когда пакеты прибудут в точку назначения не по порядку. Это поле – 32-битный номер, определяющий номер сегмента в последовательности, он с каждым пакетом увеличивается и позволяет собрать данные в правильном порядке. В общем смысле значение определяет принадлежит ли пакет активной сессии или нет.

Window

TCP так же предоставляет хостам механизм сказать друг другу сколько данных они хотят получить. Это и есть поле Window – 16 битное число в ТСР заголовке. Будучи однажды заданным, оно говорит хосту, что приниматься будет строго ограниченный объем данных, а остальные пакеты будут отброшены. Если очередь приема будет переполнена, то хост может выставить значение окна приема в 0 и таким образом сказать партнеру по обмену трафиком, что типа мол хорош.

Контрольные биты – SYN, ACK, PSH, URG, RST и FIN, про них уже не раз говорили, так что повторяться не буду.

Атака TCP RESET

Главная идея – сфальсифицировать пакет и прекратить или скомпрометировать установленное ТСР соединение. Давай представим, что существует соединение от хоста А к хосту В. Третий хост С подделывает пакет в котором указывает исходный порт и IP адрес хоста А, порт назначения и адрес хоста В, и текущий sequence number активного ТСР соединения между А и В. Хост С устанавливает RTS бит на пакете, так что когда В получит пакет, он немедленно прекратит соединение. Это приведет к отказу от обслуживания до тех пор, пока соединение не будет восстановлено. На уровне приложения конечно трудно сказать что будет, это скорее зависит от самой программы.

В такой ситуации конечно наиболее уязвимы приложения и протоколы поддерживающие продолжительные соединения. Например BGP (Border Gateway Protocol) от Cisco (см. RFC 1771), так как он основывается на постоянной ТСР сессии между компьютерами. Сбой в работе протокола может привести к “колебанию маршрута” (route flapping), довольно неприятному событию для маршрутизатора.

Уязвимость

Paul Watson, обнаруживший уязвимость, объясняет, что на самом деле такую атаку не так трудно организовать как казалось ранее. По предыдущим подсчетам выяснили, что брутфорс атака на sequence number потребует перебора всех чисел от 1 до 4.294.967.295. Однако это вовсе не так. Например, если ТСР стек на хосте А ограничен window в 16К, стек должен получать все пакеты в пределах этого “окна” и атакующему не обязательно посылать пакеты с установленным RTS во всей последовательности SN, а ограничится только каждым возможным окном, так как ТСР примет любой Sequence number в пределах некоторого диапазона, заданного величиной окна. Таким образом нападающему надо перебрать 4.294.967.295 / 16.384 = 262.143 что бы попасть во все доступные окна.

Вероятно и 262 тысячи может показаться большим числом, однако это не так. Во-первых, при хорошем коннекте атакующий способен генерить десятки тысяч пакетов в секунду. Во-вторых, атаку можно распределить по нескольким хостам. Например на стандартной DSL линии можно производить 250 пакетов в секунду, что исчерпает все варианты за 17 минут, при подключении на скорости 2 МБит/С это уже 4.730 пакетов и всего лишь 60 секунд.

В примере рассмотрен пример окна в 16К, однако по RFC это поле 16 битное, что дает до 64К. Еесли используется полный его размер, то атакующему достается всего 65.537 пакетов, 4 и 15 секунд соответственно. Причем имейте ввиду, что это максимальное время, в среднем оно будет наполовину меньшим (на практике это 3 минуты и 8 секунд). Что касается описанных в уязвимости 4 пакетов, то она возникает только при использовании window scaling, ТСР расширении (см. RFC 1323) где размер “окна” увеличен с 16 до 30 бит (реализовано, например, и в описанном выше BGP). В случае максимального размера атакующему действительно придется послать только 4 пакета что бы реализовать TCP Reset.

Source Port

Все приведенные выше примеры опираются на то, что атакующий знает порт назначения и IP адрес, порт исходный и исходный адрес. Первые два параметра доступны и известны, IP адрес получателя так же не составляет труда узнать – это адрес клиента которого спуфим. Единственный вопрос – исходный порт. Например если ОС случайным образом выдает порт из пула от 1025 до 49.152 (так как например делает OpenBSD), это увеличит количество попыток ровно в 48.127 раз, так как надо будет попробовать подловить номер SN с каждым номером порта. Хорошая новость в том, что большинство ОС, включая Linux и Windows, не используют такой механизм, что сводит на нет вероятность такой защиты.

reset-tcp.c exploit или сплохи средь бела дня

Paul Watson оказался на редкость щедрым и выложил в сеть написаный им reset-tcp.c эксплоит, который собирается достаточно просто даже на простеньком Debian Linux.

Перед сборкой советую проверить наличие в системе необходимой библиотеки libnet-1.1.1 и доставить её в случае отсутствия:

apt-get install libnet1-dev

после успешной установки библиотеки в систему переходим к сборке бинарника сплоита:

gcc reset-tcp.c -o reset-tcp /usr/lib/libnet.a
или
gcc -o reset-tcp reset-tcp.c -lnet

** можно также поменять предварительно MAC адрес (enet_src/enet_dst) в коде, во избежание лишних проблем со своим интернет-провайдером, которые могут возникнуть в процессе эксплуатации сплоита

пример запуска:
reset-tcp [interface] [src ip] [src port] [dst ip] [dst port] [window size]

[root@orc EuroTransTelecom]# ./reset-tcp eth1 172.16.0.1 1 172.16.0.2 2 65536

Packets sent: 8192 Sequence guess: 536805376
Packets sent: 16384 Sequence guess: 1073676288
Packets sent: 24576 Sequence guess: 1610547200
Packets sent: 32768 Sequence guess: 2147418112
Packets sent: 40960 Sequence guess: 2684289024
Packets sent: 49152 Sequence guess: 3221159936
Packets sent: 57344 Sequence guess: 3758030848
packets sent: 65535

SYN атака

Reset атака может быть выполнена и без RST бита. Вместо него можно установить SYN бит выполнив точно такую же атаку, что была описана выше. На большинстве реализаций TCP стека в случае получения повторного SYN будет выслан RST с sequence number. Если SYN входит в “окно” текущей сессии, то вместо с RST ответом сессия будет прекращена, а система вероятно даже перезагружена.

Blind data injection

Наконец и третий, но далеко не последний вариант развития событий. Делается все так же как и в предыдущих случаях – брутфорсом подбирается sequence number, только вместо посылки пустых SYN или RST пакетов лепим нормальный пакет с данными. Соединение в таком случае не прервется, а вот что у пользователя соберется на компьютере – совершенно непонятный вопрос. Передаваемые данные будут катастрофически повреждены.

Более подробно обсудить вопросы практического применения описанного в материале со мной можно в личных сообщениях. Контактные данные указаны в соответствующем разделе на сайте.

10.02.2026
Коннектим полезную нагрузку Metasploit Framework через NAT

Когда я провожу тестирование на проникновение и работаю в сети, где интернет раздается NAT, например из дома через маршрутизатор беспроводной сети, то мне необходимо настроить проброс портов на своем маршрутизаторе, чтобы полезная нагрузка, например Meterpreter смогла подключаться к машине с Metasploit Framework.

Лучшим вариантом было бы подключиться к Интернету напрямую с белым IP адресом, но это слишком затратно или невозможно, например из интернте-кафе. Настройка проброса портов не так уж и сложна, но проверить её работоспособность может не каждый. Жаль, что данный подход нельзя использовать при подключении через 3G модем или публичный Wi-Fi, потому как мне в этом случае изначально выдаётся серый IP адрес, и конечно же доступ к маршрутизатору провайдера для настройки проброса портов мне никто не предоставит.

В моём случае виртуальная машина с установленным Metasploit Pro имеет IP-адрес 192.168.1.169 в локальной сети. Обычно я выбираю порт 4444 в качестве рабочего порта для бэкконнекта полезной нагрузки, чтобы избежать путаницы. Сейчас я покажу пример на маршрутизаторе Asus, другой маршрутизатор конечно же может иметь совершенно иной Web-интерфейс.

Мой маршрутизатор не поддерживает диапазон для проброса трафика на локальный порт, в противном случае я мог бы указать диапазон 1024-65535 и для внешнего диапазона портов и для внутренних локальных портов. Это дало бы полезной нагрузке большее количество портов для возможности обратного подключения, что увеличило бы возможное количество сплоитов, которые одновременно можно было бы запустить на целевом исследуемом хосте. Не стесняясь экспериментировать с этим, если маршрутизатор поддерживает это – можно сделает любое тестирование на проникновение быстрее и получить больше шансов на успех, но я покажу как работать через один единственный порт, который был уже назначен.

Теперь давай проверим, как работает проброс порта на маршрутизаторе, который я только настроил. Для этого во вкладке Модули нахожу модуль “Generic Payload Handler“:

И запускаю этот модуль. Теперь мне нужно узнать мой публичный IP адрес. Это можно посмотреть в настройках маршрутизатора, или просто перейдя на сайт bgp.tools при условии конечно же, что провайдер для моего договора его предварительно мне выдал, а не назначил мне серый адрес и я оказался за двойным NAT как сейчас обычно это случается.

Далее ввожу этот публичный IP адрес в поле Listener Host, оставляю список портов слушателя по умолчанию 4444-4444. Здесь мне нужно использовать именно диапазон, а не значение, в противном случае модуль не сработает. Запускаю модуль. Теперь у меня есть активный слушатель, работающий на моей Metasploit Framework машине, и порт 4444, который проброшен через мой домашний роутер на эту же машину.

Теперь проверю, работает проброс портов или нет. На сайте www.canyouseeme.org ввожу порт 4444 в поле и нажимаю кнопку Can You See Me. Если я всё сделал правильно, то увижу сообщение что-то вроде этого:

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

Перед тем, как начать новое тестирование на проникновение, после проверки бэкконнекта мне нужно остановить запущенную Generic Payload Handler задачу. Теперь при выборе сплоита я буду указывать Listener Port 4444. Проще говоря, настроить бэкконнект легко, но всё упирается в белый IP-адрес, который можно получить у провайдера за небольшую дополнительную плату по договору оказания предоставления услуг доступа в сеть интернет.

Более подробно обсудить со мной вопрос практического применения этого материала можно в личных сообщениях. Контактные данные указаны в соответствующем разделе этого сайта.

04.02.2026
В чём разница между утечками маршрутов BGP leaking и перехватом BGP hijack?
Одной из основных функций служб мониторинга и аналитики глобальной маршрутизации BGP является отслеживание специфических аномалий, которые могут привести к сетевому инциденту, который мы бы далее будем называть утечкой маршрута BGP route leaking или захватом BGP route hijack.

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

Мы начали собирать данные о модели сетевых взаимосвязей BGP за пару лет до появления RFC 7908, пытаясь определить, что является утечкой маршрутов, а что преднамеренным захватом адресного пространства с использованием BGP. Два основных различия между этими событиями были описаны следующим образом:
- Маршруты, перенаправленные через неправильные ASN/каналы (утечки маршрутов), описанные как типы 1-4 RFC 7908.
- Маршруты, перенаправленные на неправильные ASN (перехват трафика), описанные как типы 5 и 6 RFC 7908.
Трафик при утечке маршрута BGP, предназначенный для вашей сети, скорее всего, будет передаваться неэффективно, что может привести к увеличению задержки прохождения пакетов к вашей сети или их полной потере. Тем не менее, в этом случае трафик почти наверняка всегда достигнет вашей сети, если нет критической перегрузки сети по какой-либо причине (например, из-за злонамеренных действий нарушителя правил маршрутизации). При перехвате маршрута BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и приземляется где-то там. Кроме того, механизмы создания таких аномалий также различаются. Для создания утечки маршрута необходимо передать корректный маршрут неподходящему соседнему интернет-провайдеру. Для создания перехвата маршрута необходимо либо объявить маршрут с более коротким или как его ещё называют специфичным для допустимого префикса, чтобы привлечь весь трафик от интернет-провайдеров, получивших такое объявление, с любым желаемым AS_PATH, либо начать анонсировать маршрут с префиксом третьей стороны из вашей сети. Поскольку механизмы создания маршрутных аномалий различаются, механизмы обнаружения инцидентов и предотвращения или смягчения последствий тоже будут различаться.

Для обнаружения причины утечки маршрута необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и найти такие маршруты BGP (из коллектора BGP), которые нарушают формальную модель Gao-Rexford, для получения дополнительной информации смотрите раздел «Взаимосвязи AS» в документации CAIDA. Для обнаружения перехватов трафика необходимы достоверные данные о том, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префикс/ISP, — необходимо создать оповещение или принять меры.

Для предотвращения или смягчения последствий перехвата трафика в рамках единой системы проверки происхождения префиксов используются два стандартных подхода. Можно зарегистрировать объект Route в вашем IRR или создать объект ROA. Наша команда описала различия между этими подходами на конференции RIPE79. Однако общим является то, что оба подхода определяют, какие префиксы принадлежат каким операторам, и пытаются блокировать маршруты от интернет-провайдера в случае анонсирования им незарегистрированных за ним префиксов (внезапно ставшим транзитным интернет-провайдером). Для предотвращения или смягчения последствий чистых утечек маршрута мы участвуем в создании открытой политики BGP. Другой подход — блокировка маршрутов с неожиданными соседями или провайдерами интернет-услуг в AS_PATH. Проект ASPA IETF несколько отличается от чистого предотвращения перехвата трафика или утечек маршрутов, поскольку он больше направлен на блокировку некорректных AS_PATH в случае утечки маршрутов и перехвата без или с некорректной обработкой AS_PATH.

ROA против утечек маршрутов

Итак, безопасна ли ваша сеть, если вы используете подписи и фильтрацию ROA? Нет, потому что без ASPA или любого аналогичного протокола сам по себе ROA не предотвратит утечки маршрутов другими пользователями. Мы надеемся, что теперь вы понимаете, насколько сложна эта проблема, где для обеспечения безопасности основ современной междоменной маршрутизации — протокола Border Gateway Protocol — необходим отдельный подход.

Подписи ROA против фильтрации ROA

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

Как оператор-заглушка (то есть автономная система с одним вышестоящим провайдером), вы ограничены в количестве способов влияния на число фильтрующих сторон. Чем больше их, тем безопаснее будут ваши префиксы (тем меньше регионов пострадает, если нарушитель маршрутизации решит захватить ваши префиксы). Если вы решите подписать свои префиксы, вы можете использовать существующую инфраструктуру фильтрации, которая будет только расти в ближайшем будущем. Более того, мы рекомендуем вам сделать именно это в любом случае, независимо от размера сети вашей автономной системы.

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

Более подробно обсудить со мной вопрос практического применения этого материала можно в личных сообщениях. Контактные данные указаны в соответствующем разделе этого сайта.
01.02.2026
BGP route injection со шкафчика провайдера

Обычно провайдеры раскидывают своё оборудование на чердаках домов или в подвалах, а иногда телекоммуникационный шкаф висит на первом или на последнем этаже прямо в подъезде многоквартирного дома.

Особенно радует то, что для подключения в этом случае светить свои паспортные данный или адрес перед провайдером не требуется, потому как договор на такое подключение оформлять вовсе и не нужно. Раньше в таких местах при помощи Ettercap NG или Wireshark обычно можно было послушать много разных и интересных вещей, например таких как CDP, VTP, DTP, STP, PVST, OSPF, HRSP, IS-IS или RIP.

Подключиться к такой железке, как показано на видео достаточно просто, для этого понадобится простенький ноутбук и провод с обжатыми концами RJ45. Также не забудь захватить ещё и консольный кабель – он тебе тоже может пригодиться.

И что такого интересно можно найти сейчас там или для чего всё это нужно?

На коммутаторе уровня доступа большинство портов настроены под абонентов и ничего особенного ты там не увидишь, вернее сказать не увидишь там абсолютно ничего. В этом случае наибольший интерес представляют транковые порты, они как правило самые последние на коммутаторе доступа. На некоторых моделях порты представлены в комбо варианте в виде обычного порта Gigabit Ethernet и розетки под оптический модуль SFP. На новых моделях Eltex последние четыре порта настраиваются под trunk и используются модули SFP+ уже на 10 Gigabit.

Более подробно обсудить со мной вопрос практического применения этого материала можно в личных сообщениях. Контактные данные указаны в соответствующем разделе этого сайта.

01.02.2026