ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Olli Artemjev                        2:5020/1354    28 Aug 2001  23:56:32
 To : Andrey Sokolov
 Subject : -1-
 -------------------------------------------------------------------------------- 
 

   Hi, Andrey !
 
 On 16 Aug 2001 at 16:19, "AS", Andrey Sokolov wrote:
 
  AS> ЦДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД
 
 как меня тошнит от псевдографики.. кто бы знал. =)
 
 AS> ближайший ко взломщикy маpшpyтизатоp |  .  \|/ ЪДДДДДї ЪДДДДї .ЙННННН»
  AS> ЪДДДДДї   і  і   --- і   і  ---.є  ЗДДДґ  і<-взломщик  АДДДДДЩ  АДДДДЩ
  AS> .ИНННННј/|\АДДДДДЩ |   .  | |  пpомежyточные .   канал связи взломщика
  AS> ЪДДДДДї  хосты .  .  і і  .  .  АДДДДДЩ .   .......|....  pоyтинг .  |
  AS> ...............  ЙННННН» є є<-ближайший к жеpтве маpшpyтизатоp ИННСННј
  AS> і<-канал связи жеpтвы ЪДДБДДї і і<-жеpтва АДДДДДЩ
 
 вот эта порнография у меня выглядит на linux терминале как порнография, а
 не как линии, на что ты вероятно рассчитывал. ASCII рулят. =)
 
  AS> Установив максимальное значение поля  TTL в заголовке IP  отпpавляемых
  AS> жеpтве сообщений (т.е. yстановив максимально высокое вpемя жизни своих
  AS> пакетов  данных),  взломщик добьётся  полного блокиpования  соединения
  AS> жеpтвы: хост жеpтвы    не   сможет полyчить ни   одного    легитимного
  AS> сообщения.
 
 Это конечно мелочь, но.. не знал бы - мог бы подумать, что время
 максимальное время жизни дает что нить еще, помимо просто большей
 вероятности что пакет не умрет по дороге. :)
 
  AS> взломщика, необходимо иметь достyп ко всем маpшpyтизатоpам, пpичастным
  AS> к  атаке,  а   это  весьма затpyднительно.   Таков  самый  общий смысл
  AS> классического флyда.
 
  Hа самом деле надо всего-навсего чтобы атака продолжалась достаточно
 длительное время, чтобы за него успеть позвонить upstream провайдеру и
 запрячь его на определение проблем. =)
 
  AS> очевидной защиты от классического флyда.
 
 только и всего-то надо - выбрать провайдера который a) реагирует на твои
 жалобы b) имеет multihomed подключение к остальной сети c) филтрует spoofed
 adresses как внутри своей сети (таких атак по моему должно быть
 большинство), так и на границах своей автономной системы. Хотя это конечно
 частный случай, но.. каждая контора сама выбирает себе тип подключения. =)
 Еще в качестве методов защиты крупных web-хостов можно рассмотреть настройку
 завязки (динамической dns)<-->(пропускная способность того или иного канала),
 например хост A имеет n сетевых iface'ов, каждый смотрящий на провайдера,
 соответствующего вышеуказанному описанию, на каждом отдельный IP (разумеется),
 по очереди выдаются клиентам через dns как safebox.somedomain k из n. В
 случае ухудшения пропускной способности одного из каналов (простой скрипт
 можно написать) поднимается +1 запасной, и так до максимума. В случае
 подъема l из n интерфейсов ситуацию можно считать началом флуда и бить
 тревогу (через отдельный канал, например мобилку повешенную на порт
 port). Кстати это схема имеет хитрый финт ушами - поскольку все провайдеры
 на каждом интерфейсе филтруют spoffed-traffic часть атакующих будет
 постоянно отфильтровываться. Такое решение конечно будет стоить бешеных
 денег (отдельные деньги каждому провайдеру за поддержку дополнительной
 фильтрации, поскольку едва ли все захотят ставить фильтры на все, но
 персональное правило легко выбивается за отдельные деньги) плюс умножение
 стоимости подключения в n раз (по числу подключений) )и накладывает
 ограничение на физическое положение сервера (желательно ему находится в
 точке обмена трафиком, например на М9), но IMO будет довольно эффективным,
 особенно с учетом, что по этой схеме можно поставить несколько машин, всилу
 того что вероятно, что скорее закончится производительность софта сервера
 по отдаче контента, чем пропускная способность канала, то есть на
 каждое из n используемых подключений можно повесить по k машин по той же
 схеме и все их завязать в dns, плюс ускорить настройки на эти машинах,
 например повесив по отдельному демону на каждый интерфейс (можно даже по
 отдельному серверу, но это не слишком эффективно)
 
 В принципе, можно посчитать математическую зависимость и выяснить коэффициент
 умножения количества атакующих, которые будут нужны для того, чтобы
 положить такую схему. :) Hо влом. :)
 
 < скип, на сегодня коментариев хватит =) >
 
 -- 
 Bye.Olli.     mailto(remove "NOSPAM"): olli@digger.NOSPAMorg.ru
 *: .. Грядущее пепел, прошлое мрак.. /Крем.
 
 --- Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon)
  * Origin: Sunrise. (2:5020/1354.0)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    -1-   Andrey Sokolov   16 Aug 2001 16:19:51   Re: -1-   Vlad   20 Aug 2001 07:14:01   -1-   Andrey Sokolov   20 Aug 2001 17:47:44   -1-   Olli Artemjev   28 Aug 2001 23:56:32   -1-   Olli Artemjev   29 Aug 2001 00:01:15   -1-   Andrey Sokolov   30 Aug 2001 07:05:31