Режется SOCK_RAW (сырые сокеты, спуфинг)

Discussion in 'С/С++, C#, Rust, Swift, Go, Java, Perl, Ruby' started by vvs777, 15 Dec 2015.

  1. vvs777

    vvs777 Elder - Старейшина

    Joined:
    16 Nov 2004
    Messages:
    394
    Likes Received:
    213
    Reputations:
    4
    Доброго времени суток!
    Когда-то экспериментировал с сабжем на винде, работало в локальной сети, но не выпускалось провайдером наружу. Проверял несколько домашних провайдеров и сеть университета, насколько я помню. Было это в далеком 2006 году (судя по дате компиляции). Вообщем, даже думал что тема мертвая :)

    На днях мой сервер пошатали - UDP флуд сколько-то гбит, спуфинг, исходящий порт 53. Понятно что ответы множества DNS серверов на запросы, якобы отправленные с моего сервера. Решил вспомнить старое и проверить работоспособность.

    Значит, в наличии: Delphi, незначительно но многократно модифицированный Raw Packet Sender Copyright (c) 2000 by E.J.Molendijk (скачать).

    Известно, что RAW IP пакеты можно отправить только имея права администратора (все Linux и Windows > 2000). Из под юзера не пробовал, права админа имеются.

    Далее. Начиная с Windows XP SP2 (?) винда (tcpip.sys) не дает отправить пакет если в нем левый адрес отправителя (WSA ошибка 10004, если не ошибаюсь). Есть такое, потому пакеты отправляются с Windows Server 2003 SP2 с отключенным брандмауером (проверено, работает).

    Пара ссылок по теме на Античате, перечитал.
    Реализация DoS атак на Delphi.
    Материал к статье DoS на Delphi.
    Программирование Raw сокетов на языке Си.
    RAW Socket[UDP] & Python.


    А дальше мистика. Формирую IP Header, UDP Header, добавляю контент, считаю checksum - с Windows 2003 пакет успешно улетает и прилетает на любую машину локальной сети, независимо от того, какой в нем адрес отправителя: пробовал и локальные адреса, и даже гугловский 8.8.8.8 - Microsoft Network Monitor регистрирует приход этих пакетов с тех адресов, которые я хочу.

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

    При отправке с подменным адресом пакет регистрируется Microsoft Network Monitor при отправке, но не доходит до удаленного сервера. Причем проверил не только с рабочего ПК, но и с нескольких VPS в облаках (Debian, root).

    Если у меня в локальной сети адрес 192.168.0.200, а я отправляю пакет якобы от узла 192.168.0.201 (не существующий), пакет уходит, НО каким боком мой интернет провайдер может знать, что в моей локальной сети нет компьютера с таким адресом?

    Кто занимался подобными вещами (цели не интересуют) - удалось ли кому отправить пакет с помощью winsock2 или все реализации на WinPcap? Почему-то мне кажется что вирусня, используемая в ddos ботнетах не должна тащить за собой кучу зависимостей типа pcap. С чего отправляются как правило пакеты и измененным адресом для ддос атак - с зараженных ПК пользователей или серверов?
     
    #1 vvs777, 15 Dec 2015
    Last edited: 15 Dec 2015
  2. Kaimi

    Kaimi Well-Known Member

    Joined:
    23 Aug 2007
    Messages:
    1,732
    Likes Received:
    811
    Reputations:
    231
    https://en.wikipedia.org/wiki/Ingress_filtering

     
    _________________________
    vvs777 likes this.
  3. vvs777

    vvs777 Elder - Старейшина

    Joined:
    16 Nov 2004
    Messages:
    394
    Likes Received:
    213
    Reputations:
    4
    Спасибо. Я предполагал такое, только у меня не сходилось - интернет-провайдер (частный случай) не может знать все внутренние адреса своих абонентов, это нужно при каждом пакете проверять есть ли такой IP реально во внутренней сети, хотя бы по тому же DHCP или ARP, а это дикая нагрузка.

    Немного начинает складываться. Вроде как вносит свой вклад алгоритм проброса UDP пакетов через NAT.
    Попробовал отправить с Windows 2003, подключенного непосредственно к провайдеру и имеющего адрес (1) пакет на другую машину, подключенную к тому же провайдеру непосредственно и имеющую адрес (2) UDP пакет - он ушел и дошел нормально.

    Повторяю то же самое с (1) на (2) но исходящий адрес указываю (3) - на машине 1 Ms NetMon регистрирует пакет с исходящим адресом (1) вместо указанного (3). Т.е. адрес заменяется ОС Windows 2003. Этот пакет доходит до машины (2) где регистрируется программой как пакет от машины (1), но другим исходящим портом. Та машина 2 на него отвечает двумя пакетами, этот ответ приходит на 1 как пакеты от 2 к 1 после чего идет попытка отправить первый из них с адреса (1) на адрес (3) - не существующий, все через тот же провайдерский шнур (т.к. 1,2 и 3 в одной подсети). Я смотрю только UDP, так что только предполагаю что в ответ пришел ICMP "узел недоступен", потому второй отправить никто не пытался. Смена исходящего порта намекает именно на проброс UDP через NAT, Windows 2003 посчитал что это пакет из локальной сети, который надо отправить на 2, а ответ от 2 вернуть на 3.

    Делаю аналогичную отправку с машины (4), подключенной к тому же провайдеру через машину (1). Исходящий адрес указываю от лампы 8.7.6.5. На (1) Ms NetMon регистрирует запрос от 8.7.6.5 к (2), отправляет его от (1) к (2), (2) получает пакет как бы от (1), отвечает на него двумя, оба приходят на (1), но уже никуда не уходят.

    Складывается впечатление, что для того чтобы создать лавину, нужно обязательно иметь подключение к глобальной сети без ingress filtering и без NAT. Такую сеть представить не могу, разве что преднамеренное прямое подключение к точке обмена траффиком машины с Windows 2000, в которой возможны такие фокусы.

    Получается, 100% атак подобного рода проходят через оставшиеся 20% незащищенных узлов и достаточно найти один такой с хорошей пропускной способностью? Кажется, что это сложная задача, но почему тогда udp флудом занимается даже школота?

    P.S. с ICMP картина та же - NAT на выходе меняет адрес на свой...
     
    #3 vvs777, 15 Dec 2015
    Last edited: 15 Dec 2015