gul

DoS & DDoS

Все привыкли к тому, что время от времени случаются DoS и DDoS-атаки. Что с ними делать?
Владельцы ресурсов и админы корпоративных сетей пытаются защитить себя сами. Всякие IDS, IPS, PIX, ASA, Netscreen и много других умных слов. Этот подход логичен, но имеет очевидный недостаток: если атака уложила border router или забила канал к провайдеру, находящиеся внутри средства обнаружения и предотвращения атак бесполезны, нужно содействие ISP.
Что же делать ISP, как защитить клиентов? Ведь его задача - передавать IP-трафик максимально качественно (надёжно, быстро и без потерь), фильтрация в его функции не входит. На объёмах трафика ISP фильтрация (IPS) будет стоить неразумно, клиентам попросту не нужен такой сервис за такие деньги. Да и настройка фильтров - процесс трудоёмкий и индивидуальный, у каждого клиента свои потребности и особенности.
Реакция ISP нужна только тогда, когда атака уложила либо канал, либо border router клиента. Иначе клиент имеет возможность отфильтровать самостоятельно, и перекладывать эту функцию на ISP смысла нет. Автоматическая фильтрация на стороне ISP может быть и вредна. Например, трафик вполне легитимной видеоконференции может быть ошибочно расценен как DoS (большой поток UDP) и отфильтрован, что, очевидно, не вызовет благодарности клиента.
Collapse )
gul

Рейтинг провайдеров

Давно не писал про рейтинг.
Поступил с ним по-сисадмински: дал инструменты для самостоятельного его просмотра, включая графики, и на постинги забил. А на самом-то деле, читать обзоры многим интересно, а куда-то идти и запрашивать рейтинг - нет. :)
Регулярно постить не буду, но кое-что, всё-таки, опубликую.
Collapse )
gul

Нипанимаю

Когда на винде или на маке падает какое-то приложение, выскакивает окошко с предложением отправить об этом информацию в Майкрософт или, соответственно, в Apple для изучения. Под FreeBSD, если пользователь сталкивается с ошибкой, он может сказать "send-pr" и отправить problem report.

Однако, если я сталкиваюсь с явной проблемой в Cisco/Juniper/Extreme, я должен заплатить за то, чтобы сообщить производителю о проблеме. Даже если у меня на руках отброшенная иосом кора, трапнувшийся джуносовый демон или воспроизводимая бага экстрима. Мне это совершенно непонятно. Ведь это не мне нужно - если у меня что-то не работает, я не буду ждать, пока вендор исправит ошибку и выпустит обновление, это для меня неприемлемо, я найду другой способ решения поставленной задачи, чтобы больше с этой ошибкой не сталкиваться. А после этого могу сообщить вендору об ошибке (чтобы другие пользователи не наступали на те же грабли), а могу не сообщать. Почему вендоры препятствуют тому, чтобы я им сообщал об ошибке? Ведь для этого не обязательно брать на себя гарантии исправления, не обязательно делать багрепорты общедоступными - почему бы просто не дать возможность отправить багрепорт?

Если бы так поступал один вендор, я бы решил, что у него какой-то выверт в мозгах. Но так поступают практически все, а это значит, что чего-то не понимаю я.

Объясните.
gul

Cisco: ограничение скорости транзитного вилана

Часто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают ingress policing на физическом интерфейсе, но если нужно ограничить не весь трафик из интерфейса, а отдельные виланы из транкового порта, всё становится сложнее. Особенно, если скорость должна быть ограничена не по сумме всех направлений вилана, а в каждую сторону независимо (а обычно оно именно так). Тем не менее, задача решается как на 3560 (3550, 3750, 3560-E и т.п.), так и на 6500.
Collapse )
gul

junos dynamic-db

В JunOs не так давно (9.4 или 9.5 - лень смотреть) появилась dynamic-db.
Фича интересная и полезная - в первую очередь для prefix-lists. Смысл в том, что некоторые части конфигурации, относящиеся только к bgp (prefix-lists и policy-statements) можно выносить в отдельный конфиг, а из основного туда делать ссылки. Это сильно уменьшает размер основного конфига, ускоряет коммит, не засоряет rollback history автообновлениями фильтров. У нас prefix-lists - это около 90% объёма конфига, коммит вместо пары минут стал проходить за ~20 секунд.
Однако, как оказалось, пока там не всё гладко. :-(
Первое, с чем столкнулся - нет возможности посмотреть этот самый dynamic config, кроме как войти туда и сказать show, что очень неудобно для скриптов, и требует привилегий изменения конфигурации, когда нужен только просмотр. Пришлось сделать op script show-dyn-conf.slax, показывающий dynamic config (правда, проблему с привилегиями это не решает).
А примерно через месяц использования dynamic-db у него без каких-либо видимых причин сорвало крышу (MX480, 9.5R2.7). :-(
Collapse )

UPD: По просьбам коллег выкладываю скрипт, который апдейтит префикс-листы на cisco и juniper. Вот. Он писан для себя, а не как продукт, пригодный для использования другими, поэтому с диагностикой не всё хорошо, с документацией ещё хуже, но можно попытаться запустить (предварительно заглянув внутрь - как минимум, там всякие умолчания прописаны в начале).
gul

Problems with ASN32

После апдейта IOS у клиента отвалилась BGP. Как оказалось, у EdgeCore, DLink и всяких noname-китайцев BGP падает, если им предложить поддержку ASN32. Падает с ошибкой "Capability error: unknown capability code 65". Понятно, что технически это проблема клиента и его железа (неподдерживаемые capabilities нужно игнорировать), но клиенту от этого не легче. Предполагаю, что не только мы наступаем на эти грабли.
Решение для Сisco:
neighbor <ip-address> dont-capability-negotiate
Решение для Juniper:
set disable-4byte-as (в конфиурации bgp, group или neighbor).

И там, и там это hidden command.
gul

JUNOScripting

На языках программирования, у которых цикл делается только через рекурсию, мне приходилось писать (lisp, exim acl).
Но вот с языком, у которого невозможно изменять значения переменных, встретился впервые. 8-() Непонятно, собственно, почему они называются "переменные". Вспоминается анекдот "а дустом не пробовали?"
Ладно бы я не понимал, как оно внутри работает. Но ведь в своё время достаточно много писал на асме - там есть и переменные, и условные/безусловные переходы, и многое другое, чего вдруг не оказалось в языке "высокого уровня". Я, конечно, знаю термины "алгоритмический" и "функциональный" язык, но всё равно вывернуть свои мозги так, чтобы применять рекурсию вместо цикла было естественно, мне напряжно. А значение переменной почему-то иногда хочется изменить.
Но ничего, освоил SLAX (Stylesheet Language Alternative Syntax) и написал скрипт, который был нужен.

Неприятно удивила низкая эффективность. Я почему-то ожидал, что если скрипты работают через junos api, то у них со скоростью должно быть всё нормально, по аналогии с embedded perl и другими встраиваемыми скриптовыми языками. Нифига - запрос конфигурации выполняется примерно полминуты (как и "show configuration"). Коммит и того больше. Вот не понимаю я, что нужно делать, чтобы текстовый файл размером два мегабайта на современном процессоре парсить целую минуту? Мне и секунду-то на эту задачу трудно представить. И заплатки с dynamic-db - я бы понял, если бы там был двухгиговый файл, а не двухмеговый.

Другие хохмочки, конечно, тоже доставляют. Например, арифметические выражения есть, а деления нет (или я не нашёл, как). Ну тут ладно, вместо деления на два можно умножить на 0.5. Но почему же printf("%d", 6000000000*0.5) возвращает "3e+09", который, естественно, парсером конфига не воспринимается?

Конечно, идеология change/commit в JunOS гораздо удобнее, чем в Cisco IOS. Но почему же нельзя закоммитить только изменения, а не весь конфиг? Или залочить только один из уровней иерархии конфига, а не его весь? Это ведь не rocket science. А как без этого скрипт может надёжно менять конфиг (скажем, апдейтить префикс-листы или что-то по событиям)? Ведь вдруг в это время кто-то что-то конфигурирует? А в результате получается система, которая "как правило, работает корректно", "глючит нечасто" и т.п. :-( Про "configure private" знаю - это хороший способ откатить чьи-то изменения и не заметить этого.

То, что у других всё ещё хуже, утешает, но не сильно. :)

P.S. А вообще, junoscripts - мощная штука, я пропёрся.
gul

Нет идеала :(

Поплачусь.
Пачиму, если на Juniper имя каунтера длиннее 23-х символов, то этот каунтер не доступен по snmp (jnxFWCounter)? Откуда идея такого странного ограничения?
Вот, например, colocall-in-rate-limit есть, а colocall-out-rate-limit - уже нет. :(
При этом из cli этот каунтер можно смотреть без проблем.
MX480, 9.5R2.7
То, что полисер считает только дропнутые пакеты, но не дропнутые байты - неудобно, но с этим уже смирился (приходится умножать кол-во дропнутых пакетов на средний размер пакета). Хотя вот даже с6500 нормально считает и пакеты, и байты.
gul

Что делать с вредными more specific routes

Есть такая старая проблема:
клиент анонсирует /23 апстриму и эту же сетку, как два /24, в IX (например, в UA-IX). В результате получается, что трафик из мира приходит апстриму по /23, а потом идёт клиенту уже по /24 (more specific) через IX. В итоге клиент получает внешний трафик через IX, без ограничений скорости, учёта и пр.
Collapse )