Pull to refresh

Comments 50

Т.е. проблема была не в атаке, а в том, что роутеры упали из-за наличия такого правила? Чисто аппаратная проблема?
Скорее все-таки программная, с кодом на маршрутизаторах. Бывает.
Он позволяет вам эффективно распространять правила маршрутизации на большое количество роутеров.

Вот потому я традиционно побаиваюсь решений, позволяющих одной кнопкой внести изменение разом на множество железок… Хотя при определенных масштабах может оказаться, что руками работать неэффективно. Но в этом случае все равно надо применять изменение на небольшие группы железок за раз, выбирая их так, чтобы в случае проблем эти железки можно было изолировать, не нанеся вред сервису. Возможно, CloudFlare изначально так и делали, но потом разленились.
Особено если вся сеть — single vendor, а значит и баги одни и те же.
Добавить — «с одинаковым софтом». У Жунипера вроде софт один и тот же на всех. У циски с этой точки зрения лучше — сам черт ногу сломит в линейках их софта, и даже сравнивать к примеру 7200 и 3845 с одинаковыми по названию иосами — они могут иметь разные баги :)
С другой стороны, если весь софт разный — выше шанс словить проблемы хоть где-то.
Если у тебя 23 дата-центра по всему миру на разном софте, то положить часть из них далеко не так катастрофично, как то, что описано в топике.
Но по совести, да, уж если не хочешь думать головой, то будь добр — проверь конфиг на одной железке, и только потом кидай на все остальные.
Причем проверять надо на боевой железке. В лабе проблема запросто может не воспроизвестись.

Ну и «подумай 10 раз перед тем, как вносить изменение, которое в лучшем случае никак не поможет». 100кб пакеты, ага…
Имхо данные решения подходят только для стеков.
Какие решения? Причем тут стеки? У них и так «один мозг на всех».
По задумке оно должно было дропать те огромные пакеты.
И как же они они попадали в сеть если у вас mtu 4470?
Никак. Но профилировщик был уверен, что они попадают.
Commit confirmed в вашей среде не возможен?
Алекс ВВВ хотел вежливо попросить перевести вопрос Матвею Принцу
Дело даже не в MTU, а в том, что длина IP-пакета ограничена двумя октетами, т. е. 65535.
UFO just landed and posted this here
После просмотра видео вспомнилось: «Первый залетевший дятел разрушил цивилизацию»
Я надеюсь инженеров этих выпиздрили улицы подметать после этого?
Ну вообще говоря да, после «зафильтровал 100к пакеты при MTU со всех сторон не более 4к» имеет смысл отправить человека подметать улицы.
«как дети, верят в глюки свято, говорят так должно быть» © Хроники лаборатории.
Кто влепил минус???
Это ведь и есть одна из фундаментальных проблем SDN: единый мозг на всю инфраструктуру, и глюк этого мозга может положить не часть сети, а вообще всё. В данном случае — по частностям ситуация немного другая (глюк не контроллера, а каждого из передающих пакеты устройств, хотя — есть ли разница с точки зрения конечного результата?), но суть проблемы проиллюстрирована довольно наглядно.
Ну влепили и влепили. Не надо злиться :)
У SDN есть и кроме этой проблем достаточно. Я недавно смотрел вебинар на ipspace.net по теме. В нем учавствовал главный архитектор NEC, который якобы должен был представить первый готовый работающий продукт на SDN. В конце концов показали только ппт-шку с диаграммами, и рассказали устно про свою имплементацию. В какой-то момент я просто устал считать причины, по которым лично я ни в коем случае даже не думал бы поставить это решение в production.
Я не злюсь, я недоумеваю :)

Да, сейчас SDN лучше всего работает в powerpoint… Хотя где-то уже даже немного начинают внедрять…
Кроме гугла не знаю ни одного примера…
Меня моё начальство попросило изучить тему вплоть до построения работающего живого прототипа. Потому и интересуюсь.
Ага, я тоже кроме гугла никого не знаю с такими интересами. Да и у них никто не отказывается от «классических» протоколов даже внутри области SDN — для фейловера, если что-то пойдет не так.
Удивляет, что не был настроен out-of-band для работы с рутерами…
Я практически уверен, что был, иначе это уже какой-то совсем эпик фейл.
Просто, когда у тебя виснет сама железяка, никакой out-of-band или консоль тебя уже не спасёт.
А меня нет :) Большая часть компаний так работает. Так что «авось» это не русское изобретение :)
Хотя нет не удивляет. Чуваки-то не знают, что пакет больше MTU будет фрагментироваться до MTU — хедеры…
А еще роутеру обычно плевать на размер собранного транзитного пакета, если все его фреймы умещаются в MTU… Собственно, только конечные получатели осуществляют сборку пакета.
А большинство tcp в сети ходит с флагом DF ;)
Поясните пожалуйста, длина пакета IP указывается в двух октетах заголовка и, следовательно, ограничена значением 65536. Откуда могли взяться значения от 99,971 до 99,985 байтов?
Из бага профайлера. Которому инженегр поверил, не потрудившись задействовать межушный ганглий.
Есть подозрение, что профайлера работает в автоматическом режиме и формирует правила самостоятельно. Мне тяжело представить, чтобы каждый commit с него просматривается вручную. А вот почему сделать rollback после этого заняло столько времени, вопрос.
«один из операторов взял вывод профилировщика и добавил правило»
Знаете, разрешить профайлеру самостоятельно принимать решения было бы полным безумием. «Большинство нехороших пакетов адресованы на порт 80 и имеют длину в 250 байт». Удачи в траблшутинге следующей за этим плавающей проблемы у части клиентов…

Что до роллбэка… По опыту решения похожих инцидентов, очень много времени уходит на выяснение причины. Вот весь периметр резко встал раком, мониторинг покраснел. Из-за чего? Несколько минут на попытки достучаться до консоли и ребуты при обнаружении доступности всех хопов кроме последнего. Потом судорожное копание в сислогах. Дальше кто-то хлопнет себя по лбу и откроет логи аудита в поисках последнего изменения — и наверняка пропустит вроде бы невинное и давно обкатанное правило «дропать пакеты такого-то размера», лишь отметив, что последнее из них какое-то странное, но вряд ли опасное.
Но час на восстановление — многовато, конечно, для такого факапа, тут не поспоришь. Видимо, тут еще играли роль трудности в организации телефонной коммуникации между 23-мя площадками. Если я правильно понял, финальным аккордом требовалось ребутнуть все роутеры — уже после отката изменения. Хрен его знает, сколько времени жуниперы ребутятся.
Да нет тут особого безумия, правила BGP filtering policy у большинства операторов тоже, например, скриптами делаются.
Они совершенно шаблонные и строго алгоритмизированные.
А вот правила фильтрации трафика — дело другое. Тут уже не получится доверить машине решение «дропать такие пакеты» — запросто окажется, что чего-то заранее не предусмотрели, и под политику попадет легитимный трафик.
Потому IPSы, а также сервисы защиты от DDOS напрочь лишены фантазии и работают по заранее заданным правилам. Если сенсор видит аномалию, и ему заранее не приказали в случае именно этой аномалии предпринять такие-то шаги, то он не станет ничего делать кроме информирования живого человека.
Вопрос не в автоматизации как таковой в инструментальном смысле, а в доверии источнику данных и его интеллектуальности. Вы видели, сколько генерит алармов настроенная по дефолту IDS? Настроенная — меньше, но все равно ложняка может быть прилично. Если не было предварительного обучения на валидном трафике — превращать эти алармы автоматически в фильтры — 100% и мгновенный косяк, если есть более-менее адекватный профиль — еще куда ни шло, но все равно опасно. Опять же клиенты разные, услуги разные, единый профиль для всех как бы наверное составляет проблему.
Не видел. Поэтому уговорили. :)
Это наверное десятичные дроби :)
> Sam Bowne, профессор City College Сан-Франциско, используя BGPlay

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

image
Именно из-за таких ситуаций я против автоматизации критически-важных задач. Человек привыкает что за него кто-то думает и просто теряет все навыки, бездумно доверяя компьютеру.
UFO just landed and posted this here
А вообще, вот картинка, характеризующая реакцию разных клиентов на падение сервиса. Один из клиентов — тот, с крохотной атаки на DNS которого всё и началось.
Два мегабайта

Я все еще под впечатлением от соседнего поста :)
Думаю тот, с которого все началось мог и не заметить даже ничего.
Скорей уж виновник вот этого hackersoft.ru/talk/919/
Ну рано или поздно он наверняка узнал. Я бы на его месте точно так же ухмыльнулся. Особенно если impact был бы небольшим.
Фактически, ребята из CloudFlare расписались в полной некомпетентности network департамента — такая конфигурация абсолютно недопустима, и «баги джунипера тут ни при чем».

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

В очередной раз убеждаюсь, что от дураков и неучей нет защиты (и железо тут ни причём).
Only those users with full accounts are able to leave comments. Log in, please.