IP-адреса «тривиально подделать»?

Я читал некоторые заметки о новом общедоступном DNS-сервисе Google :

• Преимущества производительности
• Преимущества безопасности

Я заметил в разделе безопасности этот пункт:

До тех пор, пока стандартное общесистемное решение для уязвимостей DNS не будет внедрено повсеместно, такое как протокол DNSSEC2, открытые средства распознавания DNS должны независимо принимать некоторые меры для предотвращения известных угроз. Многие методы были предложены; см. IETF RFC 4542: Меры по повышению устойчивости DNS к поддельным ответам для ознакомления с большинством из них. В Google Public DNS мы реализовали и рекомендуем следующие подходы:

• Чрезмерное выделение ресурсов машины для защиты от прямых DoS-атак на самих распознавателей. Поскольку злоумышленники могут легко подделать IP-адреса, невозможно блокировать запросы на основе IP-адреса или подсети; Единственный эффективный способ справиться с такими атаками - просто поглотить нагрузку.

Это удручающее осознание; даже в случае переполнения стека / сбоя сервера / суперпользователя мы часто используем IP-адреса в качестве основы для запретов и блоков всех видов.

Думать, что «талантливый» злоумышленник может тривиально использовать любой IP-адрес, который он хочет, и синтезировать столько уникальных поддельных IP-адресов, сколько он хочет, действительно страшно!

Итак, мой вопрос (ы):

• Действительно ли это , что легко злоумышленнику подделать IP - адрес в дикой природе?
• Если да, то какие смягчения возможны?

Как заявляют многие другие, подделывать заголовки IP-адресов достаточно просто, если не нужно получать ответ. Вот почему это чаще всего наблюдается с UDP, так как TCP требует трехстороннего рукопожатия. Одним заметным исключением является поток SYN , который использует TCP и пытается связать ресурсы на принимающем хосте; опять же, поскольку ответы отбрасываются, адрес источника не имеет значения.

Особенно неприятным побочным эффектом способности злоумышленников подделывать адреса источника является атака обратного рассеяния . Существует отличное описание здесь , но кратко, это обратное традиционной DDoS атаки:

1. Получите контроль над ботнетом.
2. Настройте все узлы на использование одного и того же исходного IP-адреса для вредоносных пакетов. Этот IP-адрес будет вашей возможной жертвой.
3. Отправляйте пакеты со всех ваших контролируемых узлов на различные адреса в Интернете, ориентируясь на порты, которые обычно не открыты, или подключаясь к действительным портам (TCP / 80), претендующим на участие в уже существующей транзакции.

В любом из случаев, упомянутых в (3), многие хосты ответят недоступным ICMP или сбросом TCP, нацеленным на адрес источника вредоносного пакета . Теперь у злоумышленника в сети потенциально находятся тысячи бескомпромиссных машин, выполняющих DDoS-атаку на выбранную им жертву, используя поддельный IP-адрес источника.

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

1. Входящая фильтрация - обеспечение поступления пакетов в вашу сеть из диапазонов адресов, которые находятся на дальнем конце входящего интерфейса. Многие поставщики маршрутизаторов реализуют такие функции, как одноадресная переадресация по обратному пути , которая использует таблицы маршрутизации и пересылки маршрутизатора для проверки того, что следующим шагом адреса источника входящего пакета является входящий интерфейс. Это лучше всего выполнить на первом уровне 3 перехода в сети (т. Е. Ваш шлюз по умолчанию.)

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

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

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

Неужели злоумышленнику так просто подделать IP-адрес в дикой природе?

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

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

Запрет людей по IP-адресу является умеренно эффективным в SF / SO / SU, поскольку сайт использует http / https, что требует двусторонней связи.

Маленькое доказательство концепции ответа Зордече (с Ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Тогда в другой консоли:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Так что да, тривиально, но тогда вы не получите ответы, как упомянуто ранее, если у вас нет доступа к 11.10.10.20 или нет анализатора где-то между www.google.com и 11.10.10.20 (и он должен быть прямо перед любого конца, так как вы не можете предсказать маршрут пакетов). Кроме того, шлюз спуфера (ISP) может не пропустить этот пакет за дверь, если они проводят какую-то проверку ip и видят, что источник плохо пахнет.

IP-адреса легко подделать для однонаправленного трафика UDP . Для пакетов TCP вы можете только подделать, чтобы получить полуоткрытые соединения TCP с пакетами SYN. Это также основа для некоторой атаки DOS. Но вы не можете подделать HTTP-соединение с поддельным адресом (например, если вы фильтруете сеансы по тому же IP-адресу). Хотя да, вы можете подделать IP-адрес в пакетах, это полезно только для определенных видов атак типа «отказ в обслуживании».

В статье GOOG явно обсуждается DNS. DNS использует как UDP, так и TCP пакеты. UDP могут быть подделаны, но не TCP. TCP требует трехстороннего рукопожатия . Если IP-адрес для TCP-пакета подделан, то подделывающий компьютер не получит ответ, и соединение не будет установлено. UDP, как упомянуто в других ответах, является «запустить и забыть» и не требует ответной связи. По этой причине DoS-атаки происходят почти исключительно в виде пакетов UDP.

В контексте Stack Overflow и семейных сайтов проблема, поднятая Takaun Daikon, очень актуальна. Есть много способов получить новый IP-адрес от своего провайдера. Изменение MAC-адреса, очевидно, является самым простым и работает для многих интернет-провайдеров. Кроме того, многие люди, которые до глупости могут использовать публичный прокси или TOR. Явная блокировка исходного IP-адреса для этих пакетов приведет к блокировке прокси-узла или конечного узла TOR.

Так действует ли блокировка IP-адресов? Да, черт возьми, это так. Но вы в конечном итоге с ошибками. Вы заблокируете некоторые IP-адреса, которые на самом деле не являются источником проблемы (например, прокси), и у вас также будут люди, избегающие ваших блоков путем изменения IP-адресов. Человек, которому не повезло получить забаненный IP позже, не сможет получить доступ к семейству сайтов SO. Но частота ошибок должна быть небольшой. Если вы не блокируете огромные наборы IP-адресов. Но если вы блокируете один или два в день, у вас все будет хорошо.

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

IP-спуфинг будет продолжаться, потому что интернет-провайдеры ленивы.

Мой провайдер чертовски хорошо знает, что я нахожусь по определенному адресу или, по крайней мере, в той подсети, в которой я нахожусь. Тем не менее я могу использовать любой адрес источника. Почему это? Просто стоимость.

Если я подделываю несколько адресов тут и там, мой провайдер ничего не стоит. Если бы каждый пользователь моего интернет-провайдера подделал один пакет в промежутке от 1:00 до 2:00, это вряд ли было бы замечанием на радаре. Однако, когда ботнет отправляет много поддельных пакетов от многих хостов на многих интернет-провайдеров, целевой компьютер или сеть падает.

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

UDP и ICMP проще всего подделать, но возможен и TCP. Это требует небезопасной удаленной ОС, которая использует предсказуемые порядковые номера для использования. Иногда машины балансировки нагрузки изменяют порядковые номера и делают их предсказуемыми. Итак, TCP возможен - но сложнее.

DNS-спуфинг в основном сфокусирован на безопасности, так как кто-то не может дать ложный ответ рекурсивному распознавателю. Аспекты затопления UDP не являются специфичными для DNS, кроме одного маленького запроса (скажем, для «.»), Который вызовет довольно большой ответ. Таким образом, это делает хороший вектор усиления. Существует множество других UDP-протоколов, которые работают, но DNS используется повсеместно, и легко найти машины, которые можно использовать для усиления атак.

DNSSEC делает это еще хуже, с пакетами UDP, которые могут достигать размера 4 КБ.

IP-адреса тривиально подделать, если речь идет о DOS-атаках на основе DNS (D), поскольку они, как правило, представляют собой случайные UDP-пакеты. Для HTTP-трафика это не так, поэтому вам нужно либо находиться в той же локальной сети, что и веб-сервер (конечно, это вполне возможно, в зависимости от того, где размещен ваш сайт), либо управлять промежуточными маршрутизаторами.

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

Однако, если отправитель хочет получить ответ, адрес возврата должен быть правильным, иначе для получения правильного адреса должен быть механизм прикладного уровня. Так что я могу заставить вас думать, что вы открываете письмо от Наны, но даже если я одурачу вас содержанием письма, вы не собираетесь отправлять Нане чек, выписанный в CASH, на какой-либо адрес в Нигерии (если Нана не является нигерийцем). ). Таким образом, вызов / ответ - эффективная защита, если вы не являетесь Человеком в середине.

Я могу установить любой IP-адрес источника, который я хочу в датаграмме.
Будет ли мой провайдер выпустить такой пакет в дикую природу - это другой вопрос.

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

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

Эти методы не только помогают улучшить общее качество сайта, но и стимулируют пользователей к более активному участию и дают более достоверные / надежные ответы.

С технической точки зрения лучше всего поступить так, как предлагает Google: просто эффективно справляться с дополнительной нагрузкой.

Отличная работа и продолжай совершенствоваться!

UDP - основная часть того, почему это легко - на самом деле Skype и Slingbox используют возможность легко подделывать IP-адреса в UDP для « пробивки » через NAT и обеспечения простого однорангового соединения.

TCP сложнее, так как он требует полного цикла SYN / ACK, но вы все равно можете затопить сервер зависшими пакетами SYN, которые отправляются на IP-адреса за много прыжков и, по сути, связывают огромное количество маршрутизаторов в процессе.

Как упомянуто выше, использование прокси тривиально, и существует очень большое количество открытых анонимных прокси.

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

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

Если да, то какие смягчения возможны?

Не много вы можете сделать на принимающей стороне.

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

Это всего лишь несколько строк в конфигурации маршрутизатора, поэтому нет оправдания тому, чтобы этого не делать.

Существует способ отследить злоумышленника, но он требует сотрудничества с вышестоящими провайдерами: http://www.cymru.com/Documents/dos-and-vip.html.

Как отмечали другие, подделать UDP довольно тривиально, а TCP - не так уж и много.

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

Для интернет-провайдеров, на которых работают службы DSL и т. Д., Каждая виртуальная линия должна быть настроена ip verify unicast reverse-path(или независимо от эквивалента, отличного от Cisco), который блокирует любой пакет, исходный IP-адрес которого не находится в диапазонах, о которых известно, что он маршрутизируется по этой линии.

Я помню, как занимался программированием сокетов в конце 90-х, используя, вероятно, Visual Basic, и мы могли установить исходный IP-адрес для нашего соединения. Я смутно помню, что когда мы пробовали это, netstat -an показывал фактический IP-адрес источника, но журналы Apache показывали поддельный IP; и я думаю, что Apache передавал поддельные IP-адреса модулям Perl и так далее.