Приносим извинения за неточность формулировки.
Используется та же сетевая инфраструктура (что обеспечивает крайне высокую связанность для клиентов), но клиентский трафик Луны чаще всего выводится на точки обмена трафиком М9 и М10 напрямую, минуя Меркурий. Если же клиент размещает на Луне свою резервную инфраструктуру (а именно для этого и был запущен дата-центр) – тогда трафик проходит через Меркурий.
Для создания связки VSS необходимо железо, которое на момент создания ДЦ еще не продавалось.
Но решение действительно интересное и возможно в дальнейшем оно будет реализовано.
Описанная первым пунктом атака выполняется любыми фреймами, и ARP тут совсем не обязателен.
Вторая описанная атака тоже не требует использования ARP.
Насчет ARP-poisoning согласен… так чаще всего и называют… Просто poisoning — следствие spoofing-а.
Яд слизнул :)
Про МАС. ARP — спуфинг отравляет кэш соседей по VLAN-у, за счет ответов своим МАС-ом на запросы вышеуказанных соседей. В результате все в сегменте начинают общаться через хакнутый сервер и возникает обычный man-in-the-middle, не говоря уже про проседание производительности в сегменте. Защититься от этого можно обычными статик-ARP-ами или ARP-ACL и атака не пройдет. Спуфинг по МАС-ам нацелен на отравление САМ-таблицы коммутатора ( иногда с переполнением). Это делается при помощи:
1. Создания тысяч фреймов с разными (например рандомными) МАС-адресами, которые исчерпывают емкость САМ — таблицы коммутатора и тот начинает рассылать Unicast — фреймы на все порты (и атакующий слышит весь сегмент)
2. Постоянная отправка фреймов с МАС-адресом жертвы с целью создать привязку в данного МАС (в САМ коммутатора) со своим портом. Результат — все фреймы жертвы поступают на хакнутый сервер.
По stp. Даже если клиент такой один, то пробрасывать VLAN между стойками все равно придется, а поскольку требуется отказоустойчивость, то тянем бэкап-каналы, получаем петли и разрываем при помощи stp.
Ну если вы раньше никогда не слышали выражение L2-сегмент, то извините, что я так выразился… видимо это совершенно непонятная фраза для настоящих ITшников и обещаю, что впредь буду выражаться предельно ясно…
Про МАС-спуфинг надо было читать в предыдущем посте… или снова непонятно?
А про ущербность STP: Я прошу у вас совета как при помощи L3 топологии мне соединить единым бродкастовым (если непонятно — «широковещательным») доменом две стойки в разных рядах ДЦ, если требование клиента, занимающего эти две стойки звучит как «сервера должны быть в одной подсети»?
Буду очень признателен, если расскажете как это сделать максимально просто и надежно.
Ага… на L2 не бывает IP… Но я вам не OSI модель рассказываю, а про L2 сегмент, где спуфить можно и по IP и по ARP и по МАС… А вот путать ARP и МАС лучше не нужно… Это и слова разные и спуфинги… Если вам на access — коммутаторе забьют САМ таблицу нелегитимными МАС — адресами с хакнутого сервера, то весь остальной трафик сегмента будет доступен атакующему…
А насчет бесстрашности, то при правильном использовании STP совсем не страшен :) Как альтернативу сквозному VLAN (который обуславливает использование STP) можно использовать L2VPN или VPLS, но нам это бенефитов на данный момент не дает.
Если ботнет будет в 20000 зомбей, которые будут «пульсировать», то облегчит участь сервера rate-limeter, однако почти за год испытаний системы такие пульсации не проходили через AGM (про технологии различия легитимного и нелегитимного трафика официальный ответ от Cisco TAC был такой, что данная информация из разряда «Confidential»).
Да и это же не секрет, что сервер и сам должен быть готов справляться с повышенными нагрузками? Если у вас проект работает как Интернет-магазин подарков, а сервер расчитан на среднюю нагрузку в 500 пользователей, то 7 марта сервер ляжет безо всякого DDoS-а :)
Для таких случаев предусмотрены всякие виртуализации серверов с Auto-Scaling-ом, которые тоже помогают бороться с повышенными нагрузками в real-time.
да… не замечательно, но распознает… но зачем тянуть проспуфленный пакет до гарда, если я могу его отбросить на бордере?
Это не маркетинговые слова… Здесь и списки доступа, и проверка на правильность маршрутизации (ip verify) и виртуальные маршрутизаторы…
Что касается L2 и защиты в сегменте, то спуфинг бывает не только по IP, но и по MAC и по ARP…
По VLAN мы обязательно разделяем клиентов, но иногда этого не достаточно… применяются Port-Security, MAC — фильтры, ARP-фильтры, приватные VLAN и многое другое… В сегменте достаточно начать дергать STP и сегмент ляжет — от этого тоже надо защищаться… Средств много и всего не расскажешь :)
Passive Defense это всевозможные превентивные меры по отбрасыванию заведомо-ложных пакетов (Anti-Spoofing и т.п.)
L2 Security позволяет локализовать успешную атаку и не дать ей распространиться(как минимум затруднить распространение) по всем серверам сегмента, если клиент размещает в ДЦ целую подсеть с серверами. Это технологии защиты от всевозможных подмен (spoofing), переполнений (overflow) и разграничение доступа (access control) внутри сегмента клиента.
Если атака идет по приложению, то можно сниффером попытаться выявить нелегитимные обращения и либо создать Flexible-Filter либо направить трафик на IPS (смотря что будет эффективнее)…
Если же Zombie перезапрашивает разные страницы с веб-сайта (Victim) полностью легитимными запросами (по ХХХ запросов в секунду), то таких Zombie система AGM и сама выявит.
Надеюсь Вы понимаете (да вы и сами написали), что для борьбы с «хитрыми ботами» нужно задействовать не только типовые системы защиты от DDoS, но и другие системы, в том числе и самописанные и разной направленности. Как говорится, наличие IPS в сетке, не отменяет необходимости пользоваться антивирусом и устанавливать заплатки. Если вы пользуетесь защитой от DDoS, но у вас на сервере нет соответствующих патчей, то сервер может упасть исключительно из-за уязвимости в системе, на использование которой Anti-DDoS не среагирует.
В Оверсан-Меркурий применяются типовые решения от Cisco, которые поддерживают «допиливание» защиты под конкретную атаку (если система способна бороться с подобной атакой), а при необходимости можем предоставить и многоступенчатую защиту «Passive Defense---Anti-DDoS---Firewall--IPS».
Иногда GRE съедает гораздо больше ресурсов, чем IPSec. Вы не пробовали гонять 10 гигабит по 10 GRE — туннелям между 65хх? Железо проседает очень неплохо, несмотря на наличие DFC и MPLS…
Используется та же сетевая инфраструктура (что обеспечивает крайне высокую связанность для клиентов), но клиентский трафик Луны чаще всего выводится на точки обмена трафиком М9 и М10 напрямую, минуя Меркурий. Если же клиент размещает на Луне свою резервную инфраструктуру (а именно для этого и был запущен дата-центр) – тогда трафик проходит через Меркурий.
Но решение действительно интересное и возможно в дальнейшем оно будет реализовано.
Вторая описанная атака тоже не требует использования ARP.
Насчет ARP-poisoning согласен… так чаще всего и называют… Просто poisoning — следствие spoofing-а.
Про МАС. ARP — спуфинг отравляет кэш соседей по VLAN-у, за счет ответов своим МАС-ом на запросы вышеуказанных соседей. В результате все в сегменте начинают общаться через хакнутый сервер и возникает обычный man-in-the-middle, не говоря уже про проседание производительности в сегменте. Защититься от этого можно обычными статик-ARP-ами или ARP-ACL и атака не пройдет. Спуфинг по МАС-ам нацелен на отравление САМ-таблицы коммутатора ( иногда с переполнением). Это делается при помощи:
1. Создания тысяч фреймов с разными (например рандомными) МАС-адресами, которые исчерпывают емкость САМ — таблицы коммутатора и тот начинает рассылать Unicast — фреймы на все порты (и атакующий слышит весь сегмент)
2. Постоянная отправка фреймов с МАС-адресом жертвы с целью создать привязку в данного МАС (в САМ коммутатора) со своим портом. Результат — все фреймы жертвы поступают на хакнутый сервер.
По stp. Даже если клиент такой один, то пробрасывать VLAN между стойками все равно придется, а поскольку требуется отказоустойчивость, то тянем бэкап-каналы, получаем петли и разрываем при помощи stp.
Про МАС-спуфинг надо было читать в предыдущем посте… или снова непонятно?
А про ущербность STP: Я прошу у вас совета как при помощи L3 топологии мне соединить единым бродкастовым (если непонятно — «широковещательным») доменом две стойки в разных рядах ДЦ, если требование клиента, занимающего эти две стойки звучит как «сервера должны быть в одной подсети»?
Буду очень признателен, если расскажете как это сделать максимально просто и надежно.
А насчет бесстрашности, то при правильном использовании STP совсем не страшен :) Как альтернативу сквозному VLAN (который обуславливает использование STP) можно использовать L2VPN или VPLS, но нам это бенефитов на данный момент не дает.
Да и это же не секрет, что сервер и сам должен быть готов справляться с повышенными нагрузками? Если у вас проект работает как Интернет-магазин подарков, а сервер расчитан на среднюю нагрузку в 500 пользователей, то 7 марта сервер ляжет безо всякого DDoS-а :)
Для таких случаев предусмотрены всякие виртуализации серверов с Auto-Scaling-ом, которые тоже помогают бороться с повышенными нагрузками в real-time.
Это не маркетинговые слова… Здесь и списки доступа, и проверка на правильность маршрутизации (ip verify) и виртуальные маршрутизаторы…
Что касается L2 и защиты в сегменте, то спуфинг бывает не только по IP, но и по MAC и по ARP…
По VLAN мы обязательно разделяем клиентов, но иногда этого не достаточно… применяются Port-Security, MAC — фильтры, ARP-фильтры, приватные VLAN и многое другое… В сегменте достаточно начать дергать STP и сегмент ляжет — от этого тоже надо защищаться… Средств много и всего не расскажешь :)
L2 Security позволяет локализовать успешную атаку и не дать ей распространиться(как минимум затруднить распространение) по всем серверам сегмента, если клиент размещает в ДЦ целую подсеть с серверами. Это технологии защиты от всевозможных подмен (spoofing), переполнений (overflow) и разграничение доступа (access control) внутри сегмента клиента.
Если же Zombie перезапрашивает разные страницы с веб-сайта (Victim) полностью легитимными запросами (по ХХХ запросов в секунду), то таких Zombie система AGM и сама выявит.
В Оверсан-Меркурий применяются типовые решения от Cisco, которые поддерживают «допиливание» защиты под конкретную атаку (если система способна бороться с подобной атакой), а при необходимости можем предоставить и многоступенчатую защиту «Passive Defense---Anti-DDoS---Firewall--IPS».