fa
Feedback

فریب کلاهبرداران را نخورید! تل‌متریو این کانال‌ها را شناسایی و برچسب‌گذاری می‌کند 👉 برای مشاهده برچسب، اشتراک تهیه کنید

Патчкорд

Патчкорд

رفتن به کانال در Telegram

Блог сетевого инженера. Новости телеком, IT и около IT. Связь - @UrgentPirate

نمایش بیشتر
2 930
مشترکین
+124 ساعت
+47 روز
+1830 روز
آرشیو پست ها
Что такое SRE от обратного, если вдруг есть сомнения, что вы делаете именно это.

Как включить и настроить использование геоинформации в BIND. В качестве базы - MaxMind и при желании её можно подправить. Статья обзорная, но все нужные ссылки с деталями есть внутри.

​​Флешка, которая в случае опасности прожигает кумулятивной струёй свою печатную плату, создана АО "НПП Краснознаменец". Говорят, что их вариант безопасен, в отличие от остальных. Идеи, как говорится, витают в воздухе.

Уставшим от вендорлока и мечтающим о EVPN/VxLAN датацентровой фабрике, посвящается. И пусть тут объясняют только как уехать с цисковской fabricpath, наверняка кому-то это в жизни пригодится. https://stubarea51.net/2021/11/18/migrating-from-fabricpath-to-evpn-vxlan/

SAD DNS Группа ученых из Калифорнийского университета и Университета Цинхуа обнаружила ряд критических недостатков безопасности, которые могут привести к возобновлению атак с отравлением кеша DNS Этот метод, получивший название "SAD DNS-атака" (сокращение от Side-channel AttackeD DNS), позволяет злоумышленнику выполнить атаку вне пути, перенаправляя любой трафик, первоначально предназначенный для определенного домена, на сервер находящийся под контролем злоумышленника. тем самым позволяя им слушать трафик, вмешиваться в данный тип коммуникаций Информация от первого лица (видео прилагается): https://www.cs.ucr.edu/~zhiyunq/SADDNS.html

www.saddns.net - спуфинг плюс скорость. С первым можно и нужно бороться и когда-нибудь это будет побеждено, возможно тотальным подписыванием всего, с нулевым доверием источнику без этого. Второе стало возможно с ростом вычислительной мощности, в том числе и полосы пропускания, когда методы защиты хорошо работавшие 10 лет назад сейчас ломаются простым перебором и я подозреваю мы увидим возрождение ещё не одной атаки.

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html - ох… Впрочем, это только драфт, каких их только не бывает. Два года прошло и никого это не спасёт, а организует кучу проблем - читайте очень обширную секцию Security в этом же документе. А ещё лучше потратьте время на IPv6, в любом случае это придётся сделать.

Виртуальные лабы на academy.apnic.net, если ещё не видели не проходите мимо. Нужна регистрация: почта, пароль и короткая анкетка. Ничего кроме браузера не требуется, разные темы, разные устройства, доступ в консоль и пошаговые инструкции. Плюс ссылки на курсы по теме, там же на academy.apnic.net.

​​IPv6 в следующие 10 лет, прогнозы с NANOG83.

Просто напоминание что нужно делать резервные копии и проверять их тоже нужно даже если это занимает почти 6 дней.

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

Хорошая вводная в понимание iptables, без лишних упрощений, но и не перегибая палку погружения в детали.

Замечательный доклад представленный на ENOG18 теперь можно почитать на Habr - про циклы маршрутизации в Интернет. Помимо теории, особенна хороша последняя часть про различные "необъяснимые" странности, которые вот прямо сейчас присутствуют в Интернет.

Если нужно скопировать что-то с одного сервера на другой, которые между собой на взаимодействуют, но при этом доступны с третьего. Вот способ с rsync, не самый простой - присутствуют socat и ssh туннели.

В блоге VyOS появилась статья про настройку динамического VPN, который позволяет избежать spoke-to-spoke маршрутизации через хаб, это раз. И два, новые лучи будут добавляться по щелчку пальцев. Слава DMVPN и BGP. https://blog.vyos.io/using-dmvpn-and-bgp-to-interconnect-multiple-sites

Правила жизни операторов ресурсов поддержки RPKI от MANRS. В приложении табличка как этим правилам соответствуют ARIN, APNIC, LACNIC, AFRINIC и RIPE, по пунктам. Про то же самое, но языком попроще в блоге, плюс немного мотивации и предпосылок.

Почти наверняка на собеседовании на любую должность связанную с сетями, а может и не только, вас спросят про семиуровневую модель OSI. Это настолько въедается и постоянно незримо присутствует вокруг в профессии с повсеместно используемыми терминами L2 и L3 в любой языковой среде, что не надо никому ничего объяснять и доказывать что они значат. При этом любимое занятие убить несколько часов это поспорить про: "OSI не нужна, TCP/IP наше всё", "На каком уровне работает ICMP", ещё можно про близкую тему "маршрутизация против коммутация" и "что за зверь L2+ коммутатор?" В любом случае в статье, наверное, вы вряд ли найдёте что-то новое для себя, за исключением мнемоник для запоминания порядков уровней от седьмого к первому: - All People Seem To Need Data Processing - All Pros Search Top Notch Donut Places - A Penguin Said That Nobody Drinks Pepsi - A Priest Saw Two Nuns Doing Pushups и от первого к седьмому: - Please Do Not Throw Sausage Pizza Away - Pew! Dead Ninja Turtles Smell Particularly Awful - People Don’t Need To See Paula Abdul - Pete Doesn’t Need To Sell Pickles Anymore Но я уверен, многие и так это прекрасно помнят.

Мне коллеги напоминают про обязательную внимательность и аккуратность, за что им большое спасибо и что я должен напомнить всем нам. Трижды, а лучше семь раз убедитесь что вы представляете что произойдёт после применения любых команд, особенно команд которые что-то фильтруют, особенно uRPF, которая помимо блокировки трафика может ещё и CPU ваш нагрузить так, что останетесь без доступа к устройству. Проверки, проверки и проверки - на столе, в виртуальной лабе, тестовой среде и только потом на прод. У Juniper, не забывайте, есть commit confirm. Ваша сеть и ваши абоненты не должны генерировать трафик, который им не принадлежит, будьте к этому строги, способов этого достигнуть много и проще всего это сделать в точке подключения, иногда это единственное место, так что всё в наших руках.

Никогда не поздно включить uRPF на Juniper или Cisco, тем более что не так давно по этому поводу обновились Best Current Practice 84 / RFC8704, что, скорее, говорит о печальном состоянии в плане спуфинга, что заставляет применять что-то новое и напоминать об этом.