В блоге APNIC обзор исследования про предотвращение DDoS атак при помощи blackhole. Три тезиса:
1. У многих защита срабатывает автоматически в течение нескольких минут после начала атаки.
2. Опять же, многие не сразу возвращают сети из blackholing после завершения атаки. От нескольких часов до суток, кто-то и больше.
3. Даже невысокая интенсивность 100 пакетов в секунду и меньше, может послужить поводом для отправки сетей в blackhole, хотя в общем эта мера применяется к более мощным атакам.

Всё же DDoS это головная боль хостеров и держателей ресурсов, интернет провайдерам для домашних пользователей попроще. Иногда прилетает, конечно, трафик в сторону какого-нибудь абонента так, что все магистрали в полку укладываются, но обычно это не долго, а увести такого абонента в blackhole гораздо проще. Автомата у нас нет, но нескольких минут хватает, если уж видим что совсем всё плохо. Плюс хорошо работают мерой превентивной защиты, спрятать IP абонента от Интернета. Можно PAT, можно ACL прикрыться, подавляющему большинству открытые наружу порты не нужны, а для тех кому нужны можно оставить переключатель в личном кабинете.

Иван Пепельняк напоминает, что если в OSPF использовать только одну area то она не обязана быть ноль. Даже больше, можно использовать две разные не нулевые area на одном устройстве между которыми формально не передаются маршруты, но так как устройство одно, то в таблице маршрутизации будут нужные маршруты до доступа к адресам из любой area. Можно вообще два разных OSPF процесса поднять, главное чтобы трафик смог дойти до конкретно этого маршрутизатора который уже решит куда его дальше отправить, потому что знает обо всём что у него есть. Такое часто встречается в различных промежуточных моментах, когда две сети объединяются, например.

Чем глубже знания и больше практического опыта их применения тем меньше в голове различных запретов, даже если они формально где-то описаны. В своё время этот барьер сломал для меня преподаватель по микроэлектронике когда спросил: "А что будет если на входы RS-триггера подать сигналы одновременно?" - в учебниках и справочниках это запрещённое состояние, так нельзя делать. А правда, что будет? А ничего страшного, в идеальном случае будет идеальный случайный выбор одного из состояний, на практике чаще будет выбираться какое-то одно, никакого бабаха. Нет запретов, но почти всегда есть последствия, а чтобы их осознавать как раз и нужны знания.

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

Мой опыт очень часто сталкивает меня с сетями первого типа, почему-то отечественный заказчик не берёт в расчёт эксплуатацию, от слова совсем. В итоге мы получаем сеть, даже не всегда с дешёвым оборудованием, но совершенно не подготовленную для использования. Очень часто следом за реализацией первого проекта идёт второй, который добавляет что-то ещё, не смотря на то что уже есть и так в несколько слоёв. Потом IT отдел или аутсорсер, пытаясь решить конкретные проблемы сети в рамках своего видения, а не проекта целиком, месяцами выбивает уже дешёвые устройства, чтобы подпереть то что должно было работать с самого начала. Так и живём, сроки планирования вперёд максимум год или два, даже приверженность одному вендору не избавит сеть от зоопарка, как бы это не было грустно. Все хотят потратить потом, а не сразу.

Но единые сети я всё же видел и даже если выкинуть автоматизацию они очень легко эксплуатируются. Можно всё свести к замене неисправного оборудования, не думая - не работает меняй, и почти в 100% случаев это поможет. Админы в этом случае всё же нужны, чтобы в рамках заложенного проекта расширять и масштабировать, как правило это всегда требуется с ростом компании.

Пусть не покажется что это касается только больших сетей, в рамках офиса на 10-20 компьютеров зоопарка чаще больше чем в сети корпорации. И на обслуживание этого зоопарка тратятся вполне реальные средства, которые могли бы быть потрачены изначально на хорошо сделанную сеть без головных болей в дальнейшем.

Amazon купили себе 44.192.0.0/10. История этой сети и её продажи со стороны продавца AMPRNet. В самом конце есть FAQ - дайджест статьи в ответах на вопросы, в том числе "Почему?" и "За сколько?". Продали тем кто больше предложил, себе оставили ещё /9 и /10.
IPv4 адреса всё ещё есть, пока их можно купить.

PuTTY часто стала обновляться, вчера до версии 0.72: security и bug fix.

Если у вас в компании есть процессы связанные с информационной безопасностью, то может быть будет полезно посмотреть на OpenCTI, как на один из инструментов для организации работы по накоплению и анализу данных по киберугрозам. Можно пощёлкать в demo, код доступен на Github. Это для тех кто уже понимает зачем, начать с этого не получится.
Странно может, но за всё время своей работы в различных организациях так и не удалось увидеть ни одного настоящего безопасника, не говоря уже о кибербезопаснике. Но я не теряю надежды :)

Сетевые админы массово помешались на Python, забыв что автоматизация это совсем не про языки программирования. Пример того как можно управиться с задачами управления устройствами на Kotlin, используя библиотеки для NETCONF под Java от Juniper.
Главное результат, НО! средства важны в том плане что результат это в том числе и поддержка реализованного решения. Если использовать какой нибудь Brainfuck, то итог выглядит сомнительно.

Иногда производитель не оставляет выбора или оставляет его мало. Поэтому у нас в копилке решений оказался инструмент на Java для Cisco SCE, в условиях без открытого SMARTnet и весьма куцой документации, благо что Java позволяла легко найти хотя бы список методов библиотечного API о роли которых можно было догадаться по названию. Ввиду относительной популярности в России платформы Cisco SCE, решения автоматизации на Java были у заметного числа провайдеров лет 5-7 назад, может и сейчас есть. Не Python'ом единым.

​Когда сделал нечто настолько неправильное, что оно кажется абсолютно логичным.

Чтобы не ползать по коммутаторам вручную сопоставляя mac-table в поиске источника адреса у Cisco есть traceroute mac. У команды достаточно много ограничений, по чужим коммутатором никакого пути не будет показано, естественно. Но её можно использовать, бонусом у Huawei есть аналог.

К счастью, наверное, у меня под рукой нету большой L2 сети и даже маленькой нет, но когда-то была. Не скажу что эта утилита сильно помогала, но таблицы форвардинга приходилось сопоставлять регулярно, медитируя над mac адресами и гадая почему трафика нет, хотя mac есть.

Ничего необычного, просто 2 Терабит/c карточка от Nokia, пока пробничёк. А 36x400Гбит/c уже можно брать.
С большой благодарностью за ссылки нашему читателю.

Наверное уже все знают, что IP адреса это числа и их можно вполне себе записывать числами, а не через точку, и это будет работать.

К этому есть общепринятый подход, точка разделяет самый старший и остальные разряды. Можно написать 1.16535, что равно 1.0.64.151, но нельзя 280.1 или 1.280.1, а вот 1.1.280 можно. То есть, мы всегда идём слева направо начиная со старшего октета весом 2^24 и уменьшая степень с каждым шагом на 8. Если количество октетов меньше 4, то последний октет всегда весом 2^0, даже если предыдущий имеет степень большую чем 8. Это всё про основы позиционных систем счисления.

Так работает для многих утилит, например ping, которые пользуются стандартными библиотеками для преобразования адресов. Но не работает для пакета iproute2 - ip route get 1.1 вернёт 1.1.0.0, вместо ожидаемого 1.0.0.1. Будте внимательны. В любом случае, подобные сокращения не общепринятый путь (не стоит сравнивать с IPv6, там по другому), лучше никого не путать и самому не путаться и писать адреса IPv4 полностью.

Мы ни разу ещё не упомянули про SaltStack, а между тем современный, расширяемый и мощный менеджер управления и конфигураций на Python, который в этом случае стоит знать для применения этой системы.

Несколько простых примеров дружбы с Netmiko и Napalm прямо из консоли. Minion это управляемые узлы, чтобы далеко не лазить в справочники.

Классный проект посвящённый 50-летию документам RFC. Каждый день 2019 года описание одного RFC начиная с первого. Прекрасный способ погрузиться в историю, не сильно погружаясь в сами документы. Блог добрался до номера 147, в общем перечне это ещё не отражено.

Дню сисадмина 20 лет, праздник прижился и продержался. Несомненно, это один из главных героев нашего времени, пусть и немного комичный в своём стереотипе. Сегодня впервые за долгое время собрался отметить с друзьями, хотя по правде говоря настоящим сисадмином я так почти и не был. От эникея через программиста сразу в сети, потом чуть-чуть посисадминил и опять в сети, из которых не выбираюсь уже почти десяток лет.
И даже на текущем моём месте работы, фактически, нет сисадмина. Есть серверы, есть сети, есть телефоны и телевизоры, а сисадмина который поддерживает локальную сеть со всеми её устройствами и принимает заявки от пользователей - нет. Конечно, бухгалтерия и офис у нас есть, но как-то всё происходит относительно гладко, никто (ну почти) не бегает с криками что кончился картридж или 1С затупила. Даже и поздравить некого.

Поэтому я поздравляю всех вас, настоящих сисадминов, своих друзей и знакомых, а также всех тех кто вырос из этой культуры. Пусть 20 лет не самый большой срок, не сравнить с другими отраслевыми праздниками, но я думаю что всё ещё впереди. Вива ла сисадмин!

P.S. В Баларуси не обманули и открыли виртуальный памятник сисадмину. По моему, не очень - не попали в характер, может я конечно от трендов отстал, зато виртуальный.

Whitebox коммутаторы, пока, в основном используются у тройки Google, Facebook и Amazon, за небольшим исключением. И это, всё вместе, дотягивает до 20% коммутаторов в датацентрах, остальное естественно под чьей-то маркой. Эти границы стираются, многие производители как минимум предоставляют раздельно железо под разные версии своего софта или даже не своего, но для многих whitebox всё ещё новинка.

Физический интерфейс всегда передаёт на своей скорости. Для 100Мбит/c нет такого, что физическая (фактическая, мгновенная) скорость отличается от этого значения. Но, есть моменты когда трафик не передаётся так как нет данных, есть моменты когда растут очереди когда данных слишком много. Скорость которую показывает система мониторинга не реальная, а рассчитанная по данным усреднённым за некоторое время, часто 5 минут, иногда 1 минута, иногда меньше.

Простая утилита, которая очень часто читает состояние /proc/net/dev и выводит результаты в размерности миллисекунд. Можно попытаться погоняться за micro-burst - моментами когда очереди переполняются из-за резкого наплыва трафика и происходят потери. Если настроен QoS, то будет видно как растёт счётчик отброшенных пакетов в какой-то из очередей. Если не настроен, то можно ощутить как спонтанно ломается трафик в самые неподходящие моменты.

Для мониторинга таких состояний существуют специальные возможности коммутаторов, например у Cisco Nexus. А можно просто за счётчиками буферов следить и количеством отброшенных пакетов, т.е. настроить QoS в минимальном виде.

Код программы очень простой и больше подходит как заготовка и его ещё придётся cкомпилировать на Go.

APNIC в своём блоге пишет что простой blackhole менее эффективен в случае IXP, чем если на стороне IXP будут развёрнуты специальные механизмы для ограничения DDoS трафика.

В чём собственно проблема, посмотрим как это организовано у MSK-IX и у многих других вероятно. Route Server подменяет next-hop в анонсируемом префиксе на специальный настроенный, чтобы анализировать или отбрасывать трафик. Таким образом участники получающие данный префикс посылают трафик в другое место, а не тому кто этот префикс анонсировал. Но, не все участники его могут получать, так как обычно длина для него /32, такое фильтруется из интернета. Собственно в примечаниях для MSK-IX так и написано, что надо разрешить приём префиксов /32 с некоторым типом community. Если этого не сделать, то трафик так и будет бежать по единственному короткому префиксу и эффект от blackhole будет смазан, как и описано в статье на APNIC.

Оператору под атакой можно прекратить анонсировать короткий префикс, но тогда смысл blackhole в этом виде, уменьшения разрушительного воздействия на свою сеть, пропадает.

Понятно и без APNIC, что если IXP начнёт сильнее вмешиваться в проходящий трафик не надеясь на анонсы, а безоговорочно анализируя и отлавливая, отмеченный оператором который защищается, будет эффективнее. Но также очевидно что это будет дороже, посыл для новой платной услуги полноценной защиты от DDoS.

Наши подписчики (не устаю говорить спасибо всем нашим подписчикам за то что читаете и за то что не забываете присылать интересные комментарии, спасибо огромное) из MSK-IX делятся статистикой, что /32 принимают не менее половины участников и напоминают, что фильтрация до /24 для IPv4 и до /48 для IPv6 это не с бухты-барахты, а целый пункт 6.1.3 в BCP 194 "BGP Operations and Security", который не грех регулярно перечитывать. В RFC 7999 "Blackhole community" про это знают, пункт 3.3, но настаивают что чем длиннее префикс тем лучше. Вот такие вот противоречия, в сети где всё держится на доверии.

И ещё про /32 в "диком" интернете и опять с большой благодарностью нашему подписчику. По данным RIS RIPE, конкретно RRC00, топ ASn с анонсами /32:

~> bgpscanner latest-bview.gz | awk -F'|' '/\/32/{print $2" "$3}' > 32prefix
~> grep -v : 32prefix -c
62286

~> awk -F'/32 ' '!/::/{print $NF}' 32prefix | sort -n | uniq -c | sort -rn
60843 37989 56300
421 49673 24811 3216
148 49673 24811
66 37989 56300 132132
40 49673 24811 3216 24482 4628 4765
33 49673 24811 3216 5588
29 32097 22356 263444 53062 262481
25 11708 12200 33070
23 49673 24811 20485 49063
18 49673 24811 52201
17 57381 50304 36351
17 50304 36351
17 32097 36351
17 11708
16 49673 24811 3216 36351
16 32097 29802
16 32097 14061
14 49673 24811 8595 43319
14 49673 24811 20485 48347
13 49673 24811 20485 50340
12 49673 24811 20485 47165
11 49673 24811 20485 60139
10 49673 24811 3216 24482 138608 58820 137331
10 32097 14361
10 32097 12883 15626 48031

На втором месте Билайн. Но не сравнить с первым местом, у которого явно что-то не то.

Бонусом, практическое использование bgpscanner.

Сегодня день рождения у Mailman, повсеместного, на сегодняшний день, менеджера списков рассылки. Оригинальный анонс.