Comments 50
Т.е. проблема была не в атаке, а в том, что роутеры упали из-за наличия такого правила? Чисто аппаратная проблема?
+5
Именно так.
0
Скорее все-таки программная, с кодом на маршрутизаторах. Бывает.
Вот потому я традиционно побаиваюсь решений, позволяющих одной кнопкой внести изменение разом на множество железок… Хотя при определенных масштабах может оказаться, что руками работать неэффективно. Но в этом случае все равно надо применять изменение на небольшие группы железок за раз, выбирая их так, чтобы в случае проблем эти железки можно было изолировать, не нанеся вред сервису. Возможно, CloudFlare изначально так и делали, но потом разленились.
Он позволяет вам эффективно распространять правила маршрутизации на большое количество роутеров.
Вот потому я традиционно побаиваюсь решений, позволяющих одной кнопкой внести изменение разом на множество железок… Хотя при определенных масштабах может оказаться, что руками работать неэффективно. Но в этом случае все равно надо применять изменение на небольшие группы железок за раз, выбирая их так, чтобы в случае проблем эти железки можно было изолировать, не нанеся вред сервису. Возможно, CloudFlare изначально так и делали, но потом разленились.
+3
Особено если вся сеть — single vendor, а значит и баги одни и те же.
0
Добавить — «с одинаковым софтом». У Жунипера вроде софт один и тот же на всех. У циски с этой точки зрения лучше — сам черт ногу сломит в линейках их софта, и даже сравнивать к примеру 7200 и 3845 с одинаковыми по названию иосами — они могут иметь разные баги :)
С другой стороны, если весь софт разный — выше шанс словить проблемы хоть где-то.
С другой стороны, если весь софт разный — выше шанс словить проблемы хоть где-то.
0
Если у тебя 23 дата-центра по всему миру на разном софте, то положить часть из них далеко не так катастрофично, как то, что описано в топике.
Но по совести, да, уж если не хочешь думать головой, то будь добр — проверь конфиг на одной железке, и только потом кидай на все остальные.
Но по совести, да, уж если не хочешь думать головой, то будь добр — проверь конфиг на одной железке, и только потом кидай на все остальные.
0
Имхо данные решения подходят только для стеков.
0
Зачем такое правило?
-1
По задумке оно должно было дропать те огромные пакеты.
-2
И как же они они попадали в сеть если у вас mtu 4470?
+1
UFO just landed and posted this here
Я надеюсь инженеров этих выпиздрили улицы подметать после этого?
-6
SDN вдруг выглядит не так привлекательно…
+3
Кто влепил минус???
Это ведь и есть одна из фундаментальных проблем SDN: единый мозг на всю инфраструктуру, и глюк этого мозга может положить не часть сети, а вообще всё. В данном случае — по частностям ситуация немного другая (глюк не контроллера, а каждого из передающих пакеты устройств, хотя — есть ли разница с точки зрения конечного результата?), но суть проблемы проиллюстрирована довольно наглядно.
Это ведь и есть одна из фундаментальных проблем SDN: единый мозг на всю инфраструктуру, и глюк этого мозга может положить не часть сети, а вообще всё. В данном случае — по частностям ситуация немного другая (глюк не контроллера, а каждого из передающих пакеты устройств, хотя — есть ли разница с точки зрения конечного результата?), но суть проблемы проиллюстрирована довольно наглядно.
+1
Ну влепили и влепили. Не надо злиться :)
У SDN есть и кроме этой проблем достаточно. Я недавно смотрел вебинар на ipspace.net по теме. В нем учавствовал главный архитектор NEC, который якобы должен был представить первый готовый работающий продукт на SDN. В конце концов показали только ппт-шку с диаграммами, и рассказали устно про свою имплементацию. В какой-то момент я просто устал считать причины, по которым лично я ни в коем случае даже не думал бы поставить это решение в production.
У SDN есть и кроме этой проблем достаточно. Я недавно смотрел вебинар на ipspace.net по теме. В нем учавствовал главный архитектор NEC, который якобы должен был представить первый готовый работающий продукт на SDN. В конце концов показали только ппт-шку с диаграммами, и рассказали устно про свою имплементацию. В какой-то момент я просто устал считать причины, по которым лично я ни в коем случае даже не думал бы поставить это решение в production.
0
Я не злюсь, я недоумеваю :)
Да, сейчас SDN лучше всего работает в powerpoint… Хотя где-то уже даже немного начинают внедрять…
Да, сейчас SDN лучше всего работает в powerpoint… Хотя где-то уже даже немного начинают внедрять…
+1
Кроме гугла не знаю ни одного примера…
Меня моё начальство попросило изучить тему вплоть до построения работающего живого прототипа. Потому и интересуюсь.
Меня моё начальство попросило изучить тему вплоть до построения работающего живого прототипа. Потому и интересуюсь.
0
Удивляет, что не был настроен out-of-band для работы с рутерами…
0
Я практически уверен, что был, иначе это уже какой-то совсем эпик фейл.
Просто, когда у тебя виснет сама железяка, никакой out-of-band или консоль тебя уже не спасёт.
Просто, когда у тебя виснет сама железяка, никакой out-of-band или консоль тебя уже не спасёт.
0
А меня нет :) Большая часть компаний так работает. Так что «авось» это не русское изобретение :)
0
Хотя нет не удивляет. Чуваки-то не знают, что пакет больше MTU будет фрагментироваться до MTU — хедеры…
0
Поясните пожалуйста, длина пакета IP указывается в двух октетах заголовка и, следовательно, ограничена значением 65536. Откуда могли взяться значения от 99,971 до 99,985 байтов?
0
Из бага профайлера. Которому инженегр поверил, не потрудившись задействовать межушный ганглий.
+8
Есть подозрение, что профайлера работает в автоматическом режиме и формирует правила самостоятельно. Мне тяжело представить, чтобы каждый commit с него просматривается вручную. А вот почему сделать rollback после этого заняло столько времени, вопрос.
0
«один из операторов взял вывод профилировщика и добавил правило»
Знаете, разрешить профайлеру самостоятельно принимать решения было бы полным безумием. «Большинство нехороших пакетов адресованы на порт 80 и имеют длину в 250 байт». Удачи в траблшутинге следующей за этим плавающей проблемы у части клиентов…
Что до роллбэка… По опыту решения похожих инцидентов, очень много времени уходит на выяснение причины. Вот весь периметр резко встал раком, мониторинг покраснел. Из-за чего? Несколько минут на попытки достучаться до консоли и ребуты при обнаружении доступности всех хопов кроме последнего. Потом судорожное копание в сислогах. Дальше кто-то хлопнет себя по лбу и откроет логи аудита в поисках последнего изменения — и наверняка пропустит вроде бы невинное и давно обкатанное правило «дропать пакеты такого-то размера», лишь отметив, что последнее из них какое-то странное, но вряд ли опасное.
Но час на восстановление — многовато, конечно, для такого факапа, тут не поспоришь. Видимо, тут еще играли роль трудности в организации телефонной коммуникации между 23-мя площадками. Если я правильно понял, финальным аккордом требовалось ребутнуть все роутеры — уже после отката изменения. Хрен его знает, сколько времени жуниперы ребутятся.
Знаете, разрешить профайлеру самостоятельно принимать решения было бы полным безумием. «Большинство нехороших пакетов адресованы на порт 80 и имеют длину в 250 байт». Удачи в траблшутинге следующей за этим плавающей проблемы у части клиентов…
Что до роллбэка… По опыту решения похожих инцидентов, очень много времени уходит на выяснение причины. Вот весь периметр резко встал раком, мониторинг покраснел. Из-за чего? Несколько минут на попытки достучаться до консоли и ребуты при обнаружении доступности всех хопов кроме последнего. Потом судорожное копание в сислогах. Дальше кто-то хлопнет себя по лбу и откроет логи аудита в поисках последнего изменения — и наверняка пропустит вроде бы невинное и давно обкатанное правило «дропать пакеты такого-то размера», лишь отметив, что последнее из них какое-то странное, но вряд ли опасное.
Но час на восстановление — многовато, конечно, для такого факапа, тут не поспоришь. Видимо, тут еще играли роль трудности в организации телефонной коммуникации между 23-мя площадками. Если я правильно понял, финальным аккордом требовалось ребутнуть все роутеры — уже после отката изменения. Хрен его знает, сколько времени жуниперы ребутятся.
0
Да нет тут особого безумия, правила BGP filtering policy у большинства операторов тоже, например, скриптами делаются.
0
Они совершенно шаблонные и строго алгоритмизированные.
А вот правила фильтрации трафика — дело другое. Тут уже не получится доверить машине решение «дропать такие пакеты» — запросто окажется, что чего-то заранее не предусмотрели, и под политику попадет легитимный трафик.
Потому IPSы, а также сервисы защиты от DDOS напрочь лишены фантазии и работают по заранее заданным правилам. Если сенсор видит аномалию, и ему заранее не приказали в случае именно этой аномалии предпринять такие-то шаги, то он не станет ничего делать кроме информирования живого человека.
А вот правила фильтрации трафика — дело другое. Тут уже не получится доверить машине решение «дропать такие пакеты» — запросто окажется, что чего-то заранее не предусмотрели, и под политику попадет легитимный трафик.
Потому IPSы, а также сервисы защиты от DDOS напрочь лишены фантазии и работают по заранее заданным правилам. Если сенсор видит аномалию, и ему заранее не приказали в случае именно этой аномалии предпринять такие-то шаги, то он не станет ничего делать кроме информирования живого человека.
0
Вопрос не в автоматизации как таковой в инструментальном смысле, а в доверии источнику данных и его интеллектуальности. Вы видели, сколько генерит алармов настроенная по дефолту IDS? Настроенная — меньше, но все равно ложняка может быть прилично. Если не было предварительного обучения на валидном трафике — превращать эти алармы автоматически в фильтры — 100% и мгновенный косяк, если есть более-менее адекватный профиль — еще куда ни шло, но все равно опасно. Опять же клиенты разные, услуги разные, единый профиль для всех как бы наверное составляет проблему.
0
Это наверное десятичные дроби :)
+2
> Sam Bowne, профессор City College Сан-Франциско, используя BGPlay
Чтобы такую картину получить, не обязательно быть профессором колледжа :)
Чтобы такую картину получить, не обязательно быть профессором колледжа :)
+2
+2
Именно из-за таких ситуаций я против автоматизации критически-важных задач. Человек привыкает что за него кто-то думает и просто теряет все навыки, бездумно доверяя компьютеру.
+2
UFO just landed and posted this here
А вообще, вот картинка, характеризующая реакцию разных клиентов на падение сервиса. Один из клиентов — тот, с крохотной атаки на DNS которого всё и началось.
Два мегабайта![](https://habrastorage.org/storage2/9aa/4ee/070/9aa4ee0709f49da2fcc703383dd6bac0.gif)
Я все еще под впечатлением от соседнего поста :)
![](https://habrastorage.org/storage2/9aa/4ee/070/9aa4ee0709f49da2fcc703383dd6bac0.gif)
Я все еще под впечатлением от соседнего поста :)
0
Думаю тот, с которого все началось мог и не заметить даже ничего.
Скорей уж виновник вот этого hackersoft.ru/talk/919/
Скорей уж виновник вот этого hackersoft.ru/talk/919/
0
Фактически, ребята из CloudFlare расписались в полной некомпетентности network департамента — такая конфигурация абсолютно недопустима, и «баги джунипера тут ни при чем».
Не говоря о том, что тупой commit confirm xx совершенно нормально их спас-бы.
В очередной раз убеждаюсь, что от дураков и неучей нет защиты (и железо тут ни причём).
Не говоря о том, что тупой commit confirm xx совершенно нормально их спас-бы.
В очередной раз убеждаюсь, что от дураков и неучей нет защиты (и железо тут ни причём).
0
Sign up to leave a comment.
Почему лежал CloudFlare