Почему лежал CloudFlare

[UncleAndy]

Т.е. проблема была не в атаке, а в том, что роутеры упали из-за наличия такого правила? Чисто аппаратная проблема?

[thevar1able]

Именно так.

[JDima]

Скорее все-таки программная, с кодом на маршрутизаторах. Бывает.

Он позволяет вам эффективно распространять правила маршрутизации на большое количество роутеров.

Вот потому я традиционно побаиваюсь решений, позволяющих одной кнопкой внести изменение разом на множество железок… Хотя при определенных масштабах может оказаться, что руками работать неэффективно. Но в этом случае все равно надо применять изменение на небольшие группы железок за раз, выбирая их так, чтобы в случае проблем эти железки можно было изолировать, не нанеся вред сервису. Возможно, CloudFlare изначально так и делали, но потом разленились.

[MetallicAt]

Особено если вся сеть — single vendor, а значит и баги одни и те же.

[JDima]

Добавить — «с одинаковым софтом». У Жунипера вроде софт один и тот же на всех. У циски с этой точки зрения лучше — сам черт ногу сломит в линейках их софта, и даже сравнивать к примеру 7200 и 3845 с одинаковыми по названию иосами — они могут иметь разные баги :)
С другой стороны, если весь софт разный — выше шанс словить проблемы хоть где-то.

[MetallicAt]

Если у тебя 23 дата-центра по всему миру на разном софте, то положить часть из них далеко не так катастрофично, как то, что описано в топике.
Но по совести, да, уж если не хочешь думать головой, то будь добр — проверь конфиг на одной железке, и только потом кидай на все остальные.

[JDima]

Причем проверять надо на боевой железке. В лабе проблема запросто может не воспроизвестись.

Ну и «подумай 10 раз перед тем, как вносить изменение, которое в лучшем случае никак не поможет». 100кб пакеты, ага…

[SKYnv]

Имхо данные решения подходят только для стеков.

[JDima]

Какие решения? Причем тут стеки? У них и так «один мозг на всех».

[essential55]

Зачем такое правило?

[thevar1able]

По задумке оно должно было дропать те огромные пакеты.

[alex_www]

И как же они они попадали в сеть если у вас mtu 4470?

[thevar1able]

Никак. Но профилировщик был уверен, что они попадают.

[alex_www]

Commit confirmed в вашей среде не возможен?

[thevar1able]

Моей? Я только переводчик.

[NecroHill]

Алекс ВВВ хотел вежливо попросить перевести вопрос Матвею Принцу

[ximaera]

Дело даже не в MTU, а в том, что длина IP-пакета ограничена двумя октетами, т. е. 65535.

[rozboris]

После просмотра видео вспомнилось: «Первый залетевший дятел разрушил цивилизацию»

[tgz]

Я надеюсь инженеров этих выпиздрили улицы подметать после этого?

[JDima]

Ну вообще говоря да, после «зафильтровал 100к пакеты при MTU со всех сторон не более 4к» имеет смысл отправить человека подметать улицы.
«как дети, верят в глюки свято, говорят так должно быть» © Хроники лаборатории.

[MetallicAt]

SDN вдруг выглядит не так привлекательно…

[JDima]

Кто влепил минус???
Это ведь и есть одна из фундаментальных проблем SDN: единый мозг на всю инфраструктуру, и глюк этого мозга может положить не часть сети, а вообще всё. В данном случае — по частностям ситуация немного другая (глюк не контроллера, а каждого из передающих пакеты устройств, хотя — есть ли разница с точки зрения конечного результата?), но суть проблемы проиллюстрирована довольно наглядно.

[MetallicAt]

Ну влепили и влепили. Не надо злиться :)
У SDN есть и кроме этой проблем достаточно. Я недавно смотрел вебинар на ipspace.net по теме. В нем учавствовал главный архитектор NEC, который якобы должен был представить первый готовый работающий продукт на SDN. В конце концов показали только ппт-шку с диаграммами, и рассказали устно про свою имплементацию. В какой-то момент я просто устал считать причины, по которым лично я ни в коем случае даже не думал бы поставить это решение в production.

[JDima]

Я не злюсь, я недоумеваю :)

Да, сейчас SDN лучше всего работает в powerpoint… Хотя где-то уже даже немного начинают внедрять…

[MetallicAt]

Кроме гугла не знаю ни одного примера…
Меня моё начальство попросило изучить тему вплоть до построения работающего живого прототипа. Потому и интересуюсь.

[JDima]

Ага, я тоже кроме гугла никого не знаю с такими интересами. Да и у них никто не отказывается от «классических» протоколов даже внутри области SDN — для фейловера, если что-то пойдет не так.

[equand]

Удивляет, что не был настроен out-of-band для работы с рутерами…

[MetallicAt]

Я практически уверен, что был, иначе это уже какой-то совсем эпик фейл.
Просто, когда у тебя виснет сама железяка, никакой out-of-band или консоль тебя уже не спасёт.

[Bezruk]

А меня нет :) Большая часть компаний так работает. Так что «авось» это не русское изобретение :)

[equand]

Хотя нет не удивляет. Чуваки-то не знают, что пакет больше MTU будет фрагментироваться до MTU — хедеры…

[JDima]

А еще роутеру обычно плевать на размер собранного транзитного пакета, если все его фреймы умещаются в MTU… Собственно, только конечные получатели осуществляют сборку пакета.

[flx]

А большинство tcp в сети ходит с флагом DF ;)

[pazhitnov]

Поясните пожалуйста, длина пакета IP указывается в двух октетах заголовка и, следовательно, ограничена значением 65536. Откуда могли взяться значения от 99,971 до 99,985 байтов?

[JDima]

Из бага профайлера. Которому инженегр поверил, не потрудившись задействовать межушный ганглий.

[Dyr]

Есть подозрение, что профайлера работает в автоматическом режиме и формирует правила самостоятельно. Мне тяжело представить, чтобы каждый commit с него просматривается вручную. А вот почему сделать rollback после этого заняло столько времени, вопрос.

[JDima]

«один из операторов взял вывод профилировщика и добавил правило»
Знаете, разрешить профайлеру самостоятельно принимать решения было бы полным безумием. «Большинство нехороших пакетов адресованы на порт 80 и имеют длину в 250 байт». Удачи в траблшутинге следующей за этим плавающей проблемы у части клиентов…

Что до роллбэка… По опыту решения похожих инцидентов, очень много времени уходит на выяснение причины. Вот весь периметр резко встал раком, мониторинг покраснел. Из-за чего? Несколько минут на попытки достучаться до консоли и ребуты при обнаружении доступности всех хопов кроме последнего. Потом судорожное копание в сислогах. Дальше кто-то хлопнет себя по лбу и откроет логи аудита в поисках последнего изменения — и наверняка пропустит вроде бы невинное и давно обкатанное правило «дропать пакеты такого-то размера», лишь отметив, что последнее из них какое-то странное, но вряд ли опасное.
Но час на восстановление — многовато, конечно, для такого факапа, тут не поспоришь. Видимо, тут еще играли роль трудности в организации телефонной коммуникации между 23-мя площадками. Если я правильно понял, финальным аккордом требовалось ребутнуть все роутеры — уже после отката изменения. Хрен его знает, сколько времени жуниперы ребутятся.

[Dyr]

Да нет тут особого безумия, правила BGP filtering policy у большинства операторов тоже, например, скриптами делаются.

[JDima]

Они совершенно шаблонные и строго алгоритмизированные.
А вот правила фильтрации трафика — дело другое. Тут уже не получится доверить машине решение «дропать такие пакеты» — запросто окажется, что чего-то заранее не предусмотрели, и под политику попадет легитимный трафик.
Потому IPSы, а также сервисы защиты от DDOS напрочь лишены фантазии и работают по заранее заданным правилам. Если сенсор видит аномалию, и ему заранее не приказали в случае именно этой аномалии предпринять такие-то шаги, то он не станет ничего делать кроме информирования живого человека.

[casperrr]

Вопрос не в автоматизации как таковой в инструментальном смысле, а в доверии источнику данных и его интеллектуальности. Вы видели, сколько генерит алармов настроенная по дефолту IDS? Настроенная — меньше, но все равно ложняка может быть прилично. Если не было предварительного обучения на валидном трафике — превращать эти алармы автоматически в фильтры — 100% и мгновенный косяк, если есть более-менее адекватный профиль — еще куда ни шло, но все равно опасно. Опять же клиенты разные, услуги разные, единый профиль для всех как бы наверное составляет проблему.

[Dyr]

Не видел. Поэтому уговорили. :)

[casperrr]

Это наверное десятичные дроби :)

[achekalin]

> Sam Bowne, профессор City College Сан-Франциско, используя BGPlay

Чтобы такую картину получить, не обязательно быть профессором колледжа :)

[bondbig]

Самое смешное, что оригинал статьи таки недоступен.

[Bezruk]

Именно из-за таких ситуаций я против автоматизации критически-важных задач. Человек привыкает что за него кто-то думает и просто теряет все навыки, бездумно доверяя компьютеру.

[JDima]

А вообще, вот картинка, характеризующая реакцию разных клиентов на падение сервиса. Один из клиентов — тот, с крохотной атаки на DNS которого всё и началось.

Два мегабайта

Я все еще под впечатлением от соседнего поста :)

[casperrr]

Думаю тот, с которого все началось мог и не заметить даже ничего.
Скорей уж виновник вот этого hackersoft.ru/talk/919/

[JDima]

Ну рано или поздно он наверняка узнал. Я бы на его месте точно так же ухмыльнулся. Особенно если impact был бы небольшим.

[shapa]

Фактически, ребята из CloudFlare расписались в полной некомпетентности network департамента — такая конфигурация абсолютно недопустима, и «баги джунипера тут ни при чем».

Не говоря о том, что тупой commit confirm xx совершенно нормально их спас-бы.

В очередной раз убеждаюсь, что от дураков и неучей нет защиты (и железо тут ни причём).