Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Т.е. проблема была не в атаке, а в том, что роутеры упали из-за наличия такого правила? Чисто аппаратная проблема?
Именно так.
Скорее все-таки программная, с кодом на маршрутизаторах. Бывает.
Вот потому я традиционно побаиваюсь решений, позволяющих одной кнопкой внести изменение разом на множество железок… Хотя при определенных масштабах может оказаться, что руками работать неэффективно. Но в этом случае все равно надо применять изменение на небольшие группы железок за раз, выбирая их так, чтобы в случае проблем эти железки можно было изолировать, не нанеся вред сервису. Возможно, CloudFlare изначально так и делали, но потом разленились.
Он позволяет вам эффективно распространять правила маршрутизации на большое количество роутеров.
Вот потому я традиционно побаиваюсь решений, позволяющих одной кнопкой внести изменение разом на множество железок… Хотя при определенных масштабах может оказаться, что руками работать неэффективно. Но в этом случае все равно надо применять изменение на небольшие группы железок за раз, выбирая их так, чтобы в случае проблем эти железки можно было изолировать, не нанеся вред сервису. Возможно, CloudFlare изначально так и делали, но потом разленились.
Особено если вся сеть — single vendor, а значит и баги одни и те же.
Добавить — «с одинаковым софтом». У Жунипера вроде софт один и тот же на всех. У циски с этой точки зрения лучше — сам черт ногу сломит в линейках их софта, и даже сравнивать к примеру 7200 и 3845 с одинаковыми по названию иосами — они могут иметь разные баги :)
С другой стороны, если весь софт разный — выше шанс словить проблемы хоть где-то.
С другой стороны, если весь софт разный — выше шанс словить проблемы хоть где-то.
Имхо данные решения подходят только для стеков.
Зачем такое правило?
Я надеюсь инженеров этих выпиздрили улицы подметать после этого?
SDN вдруг выглядит не так привлекательно…
Кто влепил минус???
Это ведь и есть одна из фундаментальных проблем SDN: единый мозг на всю инфраструктуру, и глюк этого мозга может положить не часть сети, а вообще всё. В данном случае — по частностям ситуация немного другая (глюк не контроллера, а каждого из передающих пакеты устройств, хотя — есть ли разница с точки зрения конечного результата?), но суть проблемы проиллюстрирована довольно наглядно.
Это ведь и есть одна из фундаментальных проблем SDN: единый мозг на всю инфраструктуру, и глюк этого мозга может положить не часть сети, а вообще всё. В данном случае — по частностям ситуация немного другая (глюк не контроллера, а каждого из передающих пакеты устройств, хотя — есть ли разница с точки зрения конечного результата?), но суть проблемы проиллюстрирована довольно наглядно.
Ну влепили и влепили. Не надо злиться :)
У SDN есть и кроме этой проблем достаточно. Я недавно смотрел вебинар на ipspace.net по теме. В нем учавствовал главный архитектор NEC, который якобы должен был представить первый готовый работающий продукт на SDN. В конце концов показали только ппт-шку с диаграммами, и рассказали устно про свою имплементацию. В какой-то момент я просто устал считать причины, по которым лично я ни в коем случае даже не думал бы поставить это решение в production.
У SDN есть и кроме этой проблем достаточно. Я недавно смотрел вебинар на ipspace.net по теме. В нем учавствовал главный архитектор NEC, который якобы должен был представить первый готовый работающий продукт на SDN. В конце концов показали только ппт-шку с диаграммами, и рассказали устно про свою имплементацию. В какой-то момент я просто устал считать причины, по которым лично я ни в коем случае даже не думал бы поставить это решение в production.
Удивляет, что не был настроен out-of-band для работы с рутерами…
Я практически уверен, что был, иначе это уже какой-то совсем эпик фейл.
Просто, когда у тебя виснет сама железяка, никакой out-of-band или консоль тебя уже не спасёт.
Просто, когда у тебя виснет сама железяка, никакой out-of-band или консоль тебя уже не спасёт.
А меня нет :) Большая часть компаний так работает. Так что «авось» это не русское изобретение :)
Хотя нет не удивляет. Чуваки-то не знают, что пакет больше MTU будет фрагментироваться до MTU — хедеры…
Поясните пожалуйста, длина пакета IP указывается в двух октетах заголовка и, следовательно, ограничена значением 65536. Откуда могли взяться значения от 99,971 до 99,985 байтов?
Из бага профайлера. Которому инженегр поверил, не потрудившись задействовать межушный ганглий.
Есть подозрение, что профайлера работает в автоматическом режиме и формирует правила самостоятельно. Мне тяжело представить, чтобы каждый commit с него просматривается вручную. А вот почему сделать rollback после этого заняло столько времени, вопрос.
«один из операторов взял вывод профилировщика и добавил правило»
Знаете, разрешить профайлеру самостоятельно принимать решения было бы полным безумием. «Большинство нехороших пакетов адресованы на порт 80 и имеют длину в 250 байт». Удачи в траблшутинге следующей за этим плавающей проблемы у части клиентов…
Что до роллбэка… По опыту решения похожих инцидентов, очень много времени уходит на выяснение причины. Вот весь периметр резко встал раком, мониторинг покраснел. Из-за чего? Несколько минут на попытки достучаться до консоли и ребуты при обнаружении доступности всех хопов кроме последнего. Потом судорожное копание в сислогах. Дальше кто-то хлопнет себя по лбу и откроет логи аудита в поисках последнего изменения — и наверняка пропустит вроде бы невинное и давно обкатанное правило «дропать пакеты такого-то размера», лишь отметив, что последнее из них какое-то странное, но вряд ли опасное.
Но час на восстановление — многовато, конечно, для такого факапа, тут не поспоришь. Видимо, тут еще играли роль трудности в организации телефонной коммуникации между 23-мя площадками. Если я правильно понял, финальным аккордом требовалось ребутнуть все роутеры — уже после отката изменения. Хрен его знает, сколько времени жуниперы ребутятся.
Знаете, разрешить профайлеру самостоятельно принимать решения было бы полным безумием. «Большинство нехороших пакетов адресованы на порт 80 и имеют длину в 250 байт». Удачи в траблшутинге следующей за этим плавающей проблемы у части клиентов…
Что до роллбэка… По опыту решения похожих инцидентов, очень много времени уходит на выяснение причины. Вот весь периметр резко встал раком, мониторинг покраснел. Из-за чего? Несколько минут на попытки достучаться до консоли и ребуты при обнаружении доступности всех хопов кроме последнего. Потом судорожное копание в сислогах. Дальше кто-то хлопнет себя по лбу и откроет логи аудита в поисках последнего изменения — и наверняка пропустит вроде бы невинное и давно обкатанное правило «дропать пакеты такого-то размера», лишь отметив, что последнее из них какое-то странное, но вряд ли опасное.
Но час на восстановление — многовато, конечно, для такого факапа, тут не поспоришь. Видимо, тут еще играли роль трудности в организации телефонной коммуникации между 23-мя площадками. Если я правильно понял, финальным аккордом требовалось ребутнуть все роутеры — уже после отката изменения. Хрен его знает, сколько времени жуниперы ребутятся.
Да нет тут особого безумия, правила BGP filtering policy у большинства операторов тоже, например, скриптами делаются.
Они совершенно шаблонные и строго алгоритмизированные.
А вот правила фильтрации трафика — дело другое. Тут уже не получится доверить машине решение «дропать такие пакеты» — запросто окажется, что чего-то заранее не предусмотрели, и под политику попадет легитимный трафик.
Потому IPSы, а также сервисы защиты от DDOS напрочь лишены фантазии и работают по заранее заданным правилам. Если сенсор видит аномалию, и ему заранее не приказали в случае именно этой аномалии предпринять такие-то шаги, то он не станет ничего делать кроме информирования живого человека.
А вот правила фильтрации трафика — дело другое. Тут уже не получится доверить машине решение «дропать такие пакеты» — запросто окажется, что чего-то заранее не предусмотрели, и под политику попадет легитимный трафик.
Потому IPSы, а также сервисы защиты от DDOS напрочь лишены фантазии и работают по заранее заданным правилам. Если сенсор видит аномалию, и ему заранее не приказали в случае именно этой аномалии предпринять такие-то шаги, то он не станет ничего делать кроме информирования живого человека.
Вопрос не в автоматизации как таковой в инструментальном смысле, а в доверии источнику данных и его интеллектуальности. Вы видели, сколько генерит алармов настроенная по дефолту IDS? Настроенная — меньше, но все равно ложняка может быть прилично. Если не было предварительного обучения на валидном трафике — превращать эти алармы автоматически в фильтры — 100% и мгновенный косяк, если есть более-менее адекватный профиль — еще куда ни шло, но все равно опасно. Опять же клиенты разные, услуги разные, единый профиль для всех как бы наверное составляет проблему.
Это наверное десятичные дроби :)
> Sam Bowne, профессор City College Сан-Франциско, используя BGPlay
Чтобы такую картину получить, не обязательно быть профессором колледжа :)
Чтобы такую картину получить, не обязательно быть профессором колледжа :)
Самое смешное, что оригинал статьи таки недоступен.
Именно из-за таких ситуаций я против автоматизации критически-важных задач. Человек привыкает что за него кто-то думает и просто теряет все навыки, бездумно доверяя компьютеру.
А вообще, вот картинка, характеризующая реакцию разных клиентов на падение сервиса. Один из клиентов — тот, с крохотной атаки на DNS которого всё и началось.
Два мегабайта
Я все еще под впечатлением от соседнего поста :)
Я все еще под впечатлением от соседнего поста :)
Думаю тот, с которого все началось мог и не заметить даже ничего.
Скорей уж виновник вот этого hackersoft.ru/talk/919/
Скорей уж виновник вот этого hackersoft.ru/talk/919/
Фактически, ребята из CloudFlare расписались в полной некомпетентности network департамента — такая конфигурация абсолютно недопустима, и «баги джунипера тут ни при чем».
Не говоря о том, что тупой commit confirm xx совершенно нормально их спас-бы.
В очередной раз убеждаюсь, что от дураков и неучей нет защиты (и железо тут ни причём).
Не говоря о том, что тупой commit confirm xx совершенно нормально их спас-бы.
В очередной раз убеждаюсь, что от дураков и неучей нет защиты (и железо тут ни причём).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему лежал CloudFlare