=?iso-8859-1?q?=5BComm=5D_=E2=CF=D2=D8=C2=C1_=D3_=C8=C1=CB=C5=D2=C1=CD=C9?= =?iso-8859-1?q?_=CE=C1_=D5=D2=CF=D7=CE=C5_=D4=C5=C8=CE=CF=CC=CF=C7=C9=CA?=

[satana]

ПРОБЛЕМА 1:
цитата: Корпорация UltraDNS подверглась массированной DoS-атаке.
[skip] что на атакуемые серверы ежесекундно приходило более двух
миллионов пакетов данных, при этом IP-адреса злоумышленников
засечь не удалось, так как они "динамически менялись".
(( http://www.compulenta.ru/2002/11/28/35846/ ))

РЕШЕНИЕ 1:
Все провайдеры у себя настраивают ипчаинсы/иптаблесы таким
образом, чтобы у IP-пакетов проверялся соурсе IP-адрес. Если он
не соответствует внутренним адресам провайдера -- дропить этот
пакет нафиг.

ПРОБЛЕМА 2:
нереально заставить всех провайдеров настроить у себя правильно
ипчаинсы/иптаблесы и всегда поддерживать эти настройки в
соответствии с текущей реальностью.

РЕШЕНИЕ 2 (предлагаемое мной и выносящееся на всеобщее
обсуждение):
встроить в исходное ядро (в то, которое выходит от Линуса)
_ПО_ДЕФОЛТУ_ВКЛЮЧЕННУЮ_ (то есть, если при компиляци нарочно не
выключить, то она будет работать) такую проверку соурсе IP - оно
(IP) должно соответствовать текущим записям в роутинге машины.
Например имеем:

Destination    Gateway   Genmask           Iface
192.168.0.0   *               255.255.255.0   eth1
default           1.1.1.1      0.0.0.0               eth0

и получаем пакет от интерфейса eth0 с соурсе IP= 192.168.0.1
Этот пакет явно фальшивый (сеть 192.168.0.х находится на другом
интерфейсе - eth1) -- удаляем этот пакет и никуда не пускаем.
Или, допустим, получаем пакет с интерфейса eth1 и с соурсе IP=
5.5.5.5
Совершенно очевидно, что этот пакет тоже фальшивый, т.к. на этом
интерфейсе (согласно роутингу) расположена только сеть
192.168.0.х

Напомню, что этот фильтр встроен в ядро _по_умолчанию_ вместе с
ruote. Дальше, по моей задумке, события развиваются следующим
образом: через пол-года после выхода нового ядра его так или
иначе поставят себе большинство провайдеров (крупных и мелких).
После это хакеры снова осуществляют атаку (на ДНС или что еще -
неважно), и в запросах посылают ложные соурсе ИП. Результат - эти
пакеты не уходят дальше ближайшего провайдера. Возможными
остаются только адреса сети данного провайдера (или вообще -
толька адреса взломанной компании).
Таким образом поиск злоумышленников гораздо облегчается. И, как
минимум, находятся взломанные сервера и чинятся от дыр и троянов.
______________
на этом изложение идеи заканчивается и начинается ее обсуждение.
Были выдвинуты такие аргументы против:
1) при такой дополнительной проверке - компьютеры не справятся с
потоком пакетов. (ИМХО - это совсем почти не добавит нагрузки)
2) у большинства провайдеров роутерами работают не писишки, а
кошки. (тогда в кошек надо тоже такую фичу встроить _по_дефолту_,
а лучше - вообще неотключаемую)
3) если стоят несколько роутеров, соединенных между собой,
использующие какой-нить bgp*, то невозможно сказать, где именно
находится конкретная сетка. то есть пакет от 1.2.3.4 может прийти
как с одного интерфейса, так и с другого.
*[border gateway protocol, пртокол маршрутизации, когда маршруты
могут меняться динамически из-за разных условий]
(не знаю, как работает эта штука, но если она просто в реальном
времени изменяет записи в route ядра, то никакой проблемы тут
нет - ядро будет постоянно сверяться с текущими правилами
роутинга так же, как оно смотрит на них чтобы решить куда
отправить данный пакет. А если это работает как-то иначе и
срастить ее с этим фильтром невозможно, то в таких специфических
случаях этот фильтр можно отключить)
------------------------------
Какие еще есть "за" и "против" у сообщества?


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ даннное письмо я постил в
форуме lrn.ru  Ответы на него можно посмотреть по ссылке
http://lrn.ru/index.php?module=forums&faction=show&message=53702

В частности, там прозвучала мысль, что в IPv6 это (возможно) уже
реализовано или станет ненужным т.к. то же самое будет достигнуто
другим способом.
^^ может эту мысль тут кто-нибудь подтвердить или опровергнуть?

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