From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <011301c2addc$d92fe400$0200a8c0@intra.zone> From: "satana" To: Date: Sat, 28 Dec 2002 05:19:16 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Comm] Борьба с хакерами на уровне технологий Sender: community-admin@altlinux.ru Errors-To: community-admin@altlinux.ru X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: community@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: ПРОБЛЕМА 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 это (возможно) уже реализовано или станет ненужным т.к. то же самое будет достигнуто другим способом. ^^ может эту мысль тут кто-нибудь подтвердить или опровергнуть? В данной переписке хочется услышать мнение людей, имеющих непосредственное отношение к разработке линукса.