В нашу лабораторию небольшим, но стабильным потоком потекли железки, которые раньше обслуживались в сервис-центрах производителей. Вместе с ними появились и новые загадочные случаи с почти необъяснимыми багами. Скажу честно, что мы не были к этому готовы, но стараемся изо всех сил. Сегодня расскажу о том, как искали причины и устраняли одну такую странную поломку в ASA, а заодно объясню, как наш отдел справляется со сложившейся ситуацией.
Старина IPv4… В сетевом мире он распространён так же, как и воздух на Земле. Однако несмотря на то, что миллионы людей используют этот протокол в повседневной жизни, у IPv4 всё ещё есть пара сюрпризов в рукаве. Сегодня мы рассмотрим один из них.
В предыдущей заметке я описал, как можно заткнуть дыру в кривом дизайне OSPF – костылём, который усложняет и так запутанный OSPF.
NSSA-зона ещё больше усугубляет ситуацию: OSPF использует Forwarding Address в Type-5 LSA, которые транслированы из Type-7 LSA, чтобы обеспечить оптимальную маршрутизацию.
В первой заметке я описал типичный (насколько его проповедуют в интернете) сценарий использования Forwarding Address (FA): два ASBR подключены к одному внешнему сегменту, причём redistribution маршрутов настроен только на одном из них.
Очевидно, что такой дизайн плох с точки зрения отказоустойчивости, но, возможно, существуют сценарии, когда использование OSPF FA уместно?
Один из моих читателей прислал мне любопытный вопрос об NSSA (подробнее в будущей статье), который побудил меня копнуть глубже вопрос о том, зачем понадобилось поле OSPF Forwarding Address (FA) в Type-5 и Type-7 LSA.
Внедрение Inter-AS Multicast VPN сопряжено с рядом узких мест в случае, когда в ядре сети не используется протокол BGP. Эта статья описывает распространённое решение таких проблем, реализованное на базе Cisco IOS с использованием расширений протоколов MP-BGP и PIM.
Всем доброго времени суток!
Захотелось поделиться реализацией Hun-and-Spoke VPN между Cisco ISR (в качестве споков) и Linux+StrongSwan swanctl (в качестве хабов).
Небольшая предыстория.
На данный момент, в нашей инфраструктуре используется моновендорная среда, базирующаяся на решениях Cisco. В свете последних событий, начали подыскивать возможные варианты замещения как на стороне бранчей (споков), так и на стороне хабов.
Хабы располагаются в ДЦ в виде Cisco CSR. И вот с ними и была основная проблема, так как отечественные решения не могут пока предложить что-то наподобие полностью готового виртуального роутера (поправьте в комментариях, если я ошибаюсь).
В итоге, пока остановились на решении Linux+StrongSwan+FRR.
Для того, чтобы повысить уровень отказоустойчивости своей сети на уровне маршрутизации, сетевые администраторы в большинстве случаев используют протоколы семейства FHRP. В рамках данной статьи ты узнаешь как пентестер может атаковать домены отказоустойчивости FHRP
Добрый день.
Меня зовут Василий и я сетевой инженер.
В данной статье хочу рассказать вам про шишки, которые мы насобирали, чтобы достичь удобного в администрировании и поддержке корпоративного VPN.
Хочу сразу предупредить, что в статье будет больше слов чем кода, так как больше хочется показать подход, нежели чем предоставить готовое решение.
Итак, поехали.
В моей статье ты узнаешь, что может значить наличие протокола GLBP в сети для пентестера. А также, будут рассмотрены превентивные меры, позволяющие повысить уровень безопасности домена GLBP. Эта работа содержит в себе теоретическую часть и практическую, в которой будет раскрыт импакт при проведении атаки.
Это первая статья из цикла “BlueTeam Trainings”. CyberDefenders является учебно-тренировочной платформой, которая предоставляет возможность на практике проверять уже имеющиеся навыки и приобретать новые в области информационной безопасности.
Если вы хоть раз настраивали MPLS L3VPN, то у вас не возникнет сомнения в том, что весь подход вертится вокруг BGP. Будучи протоколом маршрутизации с развитым чувством собственного достоинства (в конце концов, он является основой для интернета), BGP использует внушительный список атрибутов префикса, которые лежат в основе алгоритма выбора лучшего маршрута. Несмотря на неприличную длину этого списка, большинство параметров предназначены для обеспечения детерминированности результата алгоритма, а не для управления трафиком руками инженера. Впрочем, иногда даже самые популярные параметры не подходят для решения определённой задачи. Если вы видите EIGRP в связке с L3VPN, возможно, это наш сегодняшний пациент.
Недавно встретил среди своей команды некоторое непонимание принципов работы ремарок в списках доступа. Ремарки расценивались, как еще еще одна строка с правилом. Не было понимания, как работать с блоками правил под одной ремаркой и т.п.
Хотел найти внятное описание по этой теме, но к своему великому удивлению, ничего не нашел. Поэтому решил описать данную тему сам.
Роли LSA довольно подробно разобраны в разных источниках: router LSA описывает узлы графа, network LSA предназначен для широковещательных сегментов сети, summary LSA обеспечивает взаимодействие разных зон между собой… Однако собрать эти структуры данных воедино в целостный граф кажется мне достаточно нетривиальной задачей. Безусловно, RFC является источником абсолютного знания в такого рода вопросах, но лично мне сравнительно долго не удавалось его полноценно осознать. В этой статье я хотел бы поделиться своим представлением о назначении типов LSA, а также процессом построения графа на основе LSDB.
Привет! Меня зовут Дмитрий, в Росбанке я занимаюсь автоматизацией сетевой инфраструктуры. Этим постом я начинаю серию публикаций о NetBox — популярном опенсорс-инструменте для документирования инфраструктуры на уровне IP-адресации (IPAM) и железа (DCIM). NetBox ценен тем, что даже с базовой функциональностью «из коробки» он предоставляет множество возможностей, не говоря уже о допиливании через форки. Далее я представлю NetBox подробнее и на нашем примере расскажу, с чего начинать работу.
Хотелось ли вам когда-нибудь выборочно фильтровать LSA5? Надоело, что исключать внешние префиксы можно только на ASBR? Вы обратились по адресу! Сегодня я бы хотел рассказать про подход, позволяющий фильтровать LSA5 в том числе на ABR.
Жил да был один Банк. В Банке была хорошая профессиональная команда ИТ-служб, но, как это часто бывает, эксплуатационных задач было больше, чем ресурсов для их решения. В результате вычислительная и сетевая инфраструктуры Банка развивались достаточно стихийно, реагируя на запросы бизнеса «здесь и сейчас».
В какой-то момент в Банке осознали, что риски растут, и...
