RE: Re: RE: Re: RE: Re: RE: Re: DNS DDOS
Это не всегда просто реализуемо, Cisco Guard (в девичестве Riverhead Guard) как раз для того и позиционируется, чтоб менять IP у атакуемого ресурса.
Не, дядя Вова, не так. Он заворачивает на себя трафик, направленный в сторону атакуемого ресурса, отфильтровывает трафик атаки и выпускает в сторону ресурса нормальный трафик. Как именно он это делает - не спрашивай :) мои попытки выяснить у development team свелись к тому, что я получил совершенно неконкретные ответы и расслабился на эту тему :) To Oleg Nauman: уже ведь не вызывает вопросов, как Thunderbird отлавливает спам? Сначала - обучение и затем уже он автоматически это делает. У меня, когда я им пользовался, процент ложных срабатываний был мизерным - 1 нормальное письмо на несколько тысяч спамовых. Так же и Cisco Guard - сначала он работает в нормальном environment, "обучаясь" профилю нормального трафика. Потом запускается в production и в случае появления аномалий полагает, что это атака. Наверняка алгоритм достаточно сложный, основанный на многих критериях, чтобы снизить процент ложных срабатываний, т.е. все не так просто, как я описал. Ну и штатные проверки, где это возможно - на том же TCP three-way handshaking, какие-то protocol specific проверки (например, переключение DNS из UDP на TCP с дальнейшей проверкой), etc. /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Не выдержал я, переформатировал :) On Wed, May 18, 2005 at 01:52:21PM +0200, Vladimir Litovka (vlitovka) wrote:
Это не всегда просто реализуемо, Cisco Guard (в девичестве Riverhead Guard) как раз для того и позиционируется, чтоб менять IP у атакуемого ресурса.
Не, дядя Вова, не так. Он заворачивает на себя трафик, направленный в сторону атакуемого ресурса, отфильтровывает трафик атаки и выпускает в сторону ресурса нормальный трафик. Как именно он это делает - не спрашивай :) мои попытки выяснить у development team свелись к тому, что я получил совершенно неконкретные ответы и расслабился на эту тему :)
To Oleg Nauman: уже ведь не вызывает вопросов, как Thunderbird отлавливает спам? Сначала - обучение и затем уже он автоматически это делает. У меня, когда я им пользовался, процент ложных срабатываний был мизерным - 1 нормальное письмо на несколько тысяч спамовых. Так же и Cisco Guard - сначала он работает в нормальном environment, "обучаясь" профилю нормального трафика. Потом запускается в production и в случае появления аномалий полагает, что это атака. Наверняка алгоритм достаточно сложный, основанный на многих критериях, чтобы снизить процент ложных срабатываний, т.е. все не так просто, как я описал.
Везет :) Вот я буквально вчера по башке от менеджера получил за свою спамоловку, которая норовила нужные письма в INBOX.spam засунуть :) А учить как делать whitelist - ну наверное в следующей жизни найду время и на это... Точно так и здесь - используемые средства норовят подвести в самый нужный момент, споткнувшись о новый порог реальности - увидав и не поверив в то, что это возможно. Что-то меня не в ту сторону опять завело :) В-общем, ко всем этим магическим штукам все равно нужен некий interface, который зовется человеком, и который обязан принять решение (чаще всего вопреки ;) )
Ну и штатные проверки, где это возможно - на том же TCP three-way
Оно не всегда three-way, ну да ладно, мы ж не об этом :)
handshaking, какие-то protocol specific проверки (например, переключение DNS из UDP на TCP с дальнейшей проверкой), etc.
Это переключение требует достаточно невменяемой логики со стороны железки, и вообще говоря однозначного взаимопонимания железки с самим DNS сервером.
/doka
-- NO37-RIPE
participants (2)
-
Oleg V. Nauman
-
Vladimir Litovka (vlitovka)