Comments 14
Интернет-провайдеры никогда не должны разрешать IP-спуфинг в своей сети. Подделка IP-адресов — вот истинная корневая причина проблемы.У спуфинга есть и законные применения, не нужно быть таким категоричным.
Например, есть программа для обхода интернет-цензуры ReQrypt, которая работает как эффективный прокси-сервер: исходящие от клиента пакеты отправляются на сервер ReQrypt в зашифрованном виде, сервер ReQrypt пересылает их серверу назначения с подменой исходящего IP-адреса на клиентский, сервер назначения отвечает клиенту напрямую, минуя ReQrypt.
Долгое время разработка была заморожена из-за того, что автор не мог найти сервер с возможностью спуфинга. Теперь он найден, разработка продолжается.
Второй случай, когда полезна подмена исходящего IP-адреса — обход NAT. На компьютере за NAT можно постоянно посылать ICMP-запросы к какому-нибудь неиспользуемому IP-адресу, например 3.3.3.3, каждые 30 секунд. Если отправить этому компьютеру ICMP TTL Exceeded, то этот пакет дойдет до компьютера за NAT, и из него он сможет получить IP-адрес отправителя (в ICMP-пакете мы можем указать любой адрес без спуфинга).
Однако, TTL Exceeded не получится отправить с компьютера за NAT, и здесь нам будет полезен промежуточный сервер со спуфингом.
А в чём именно ценность этих применений?
ReQrypt просто экономит немного скорости для пользователя и много трафика для своего сервера — это прикольно, но не настолько принципиально по сравнению с обычным прокси/VPN чтобы ради этого разрешать IP-спуфинг.
В чём ценность такого способа обхода NAT я, возможно, просто не понял — есть ведь немало других способов, чем конкретно этот лучше?
В чём ценность такого способа обхода NAT я, возможно, просто не понял — есть ведь немало других способов, чем конкретно этот лучше?Тем, что он автономный. Этому подходу не требуется какой-либо промежуточный сервер (если подключающийся клиент не за NAT), и серверу за NAT не нужно знать IP-адрес подключающегося клиента наперед.
Т.е. кейс тут один: сервис за NAT, к которому по своей инициативе подключается клиент не за NAT? Причём для подключения клиенту нужно заранее знать, на какой неиспользуемый IP отправляет пакеты конкретно этот сервис (их ведь за NAT может быть несколько, так что нужно дополнительно обеспечить уникальность этих неиспользуемых IP для всех сервисов за этим NAT), плюс клиент должен знать адрес самого NAT. И всю эту информацию клиент должен получить без использования промежуточного сервера.
Как по мне — всё это звучит крайне сомнительно. Для статических, штатных сервисов проще настроить форвардинг портов на NAT. Для динамических будет сложновато обеспечить распределение между ними на какие неиспользуемые IP они будут слать ICMP, плюс потребуется как-то доносить выбранный конкретным сервисом IP до клиентов, что ещё сложнее.
Либо я по-прежнему что-то упускаю, либо это странный и малополезный в реальных задачах хак, которым крайне сложно оправдывать поддержку спуфинга IP.
В сетевых технологиях разбираюсь поверхностно, поэтому заранее прошу прощения, если вопрос глупый.
Почему для атаки нужен протокол UPnP? Почему, например, не HTTP, где коэффициент умножения трафика намного выше?
syn и ack — имеют свои порядковые номера, но начинаются не с единицы (или нуля), а генерируются рандомно.
Атакующие подделывают ip-адрес отправителя(вместо своего реального IP-адреса они в качестве «адреса отправителя» указывают адрес сервера, который ддосят в данный момент), поэтому если атакующий будет использовать tcp, то первый ответ от сервера, который syn+ack уйдет сразу «жертве ддоса», жертва ответит на него rst (reset, сброс соединения), сервер увидев вместо ack-пакета rst пакет пойдем что «что-то пошло не так» и не будет пытаться что-то отправлять в сторону «жертвы».
То есть вроде как произойдет примерно тоже самое, но не получиться такого сильного «усиления атаки», на один пакет злоумышленника «syn» промежуточный сервер сформирует один пакет «syn+ack» примерно равный по размеру изначальному syn-пакету.
В UDP же нет понятия «установки соединения», и поэтому одним маленьким пакетом (без установки соединения syn — sync+ack — ack, просто первым пакетом сразу отправляется запрос какой-то информации) можно получить относительно большой ответ. И за счет этого получается «усиление», когда злоумышленник тратит 5Гб\с на запросы (так же указывая в качестве адреса отправителя не свой реальный IP, а IP жертвы), а промежуточные сервера (сторонних людей, которые подвержены этой атаке) формируют ответов на 100Гб\с, и все ответы уходят жертве.
Вообще стоит разобраться (хотя бы в общих чертах) в механизмах работы tcp и udp и все сразу станет очевидно. Проблема не только в UPnP, раньше для того же самого широко использовались DNS и NTP протоколы, (которые тоже работают через UDP), но это стало неэффективным потому что большинство администраторов столкнулись с тем что «DNS сервер внезапно стал генерировать большой трафик в интернет», разобрались с тем, что происходит и закрыли DNS и NTP сервера фаерволами. Те, кто разумнее — заодно прикрыли и остальные сервисы работающие по UDP, поэтому видим что злоумышленники переключились на «домашних пользователей» в качестве «промежуточных серверов усиления». Со временем UPnP тоже позакрывают(зами пользователи или администраторы провайдеров) и атакующие будут искать другие способы усиление трафика (другие протоколы, или вернуться к комбинации DNS+NTP+UPnP+что-там еще есть, рассчитывая на то, что появились новые сервера с этими сервисами, которые забыли закрыть фаерволом или обновить).
Если не ошибаюсь, когда-то amarao описывал в комментах почему провайдерам сложно реализовать защиту от IP-спуфинга. Если кто-нибудь найдёт этот коммент — добавьте ссылку сюда, плз.
Если кратко — то при наличии у клиента дублирующего канала от другого провайдера пакеты с "чужим" IP являются "легальными", поскольку в теории никто не запрещает клиенту отправлять пакет через одного провайдера, рассчитывая получить ответ через другого.
Если же клиент использует PA адреса одного провайдера, но трафик пускает через другого провайдера, то второй провайдер может спокойно блокировать этот трафик и на любой вопрос в саппорт ответит «это не ваши адреса, мы выделили вам другие, используйте их» и будет на 100% прав.
Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит/с