В рамках разбора ситуации с большим количеством запросов к DNS серверу в локальной сети, помимо выявления основного источника "шума", обратили внимание на один из второстепенных источников, который показался нам странным. Большое количество запросов к DNS серверу прилетало от коммутаторов начального уровня серии Cisco Small Business. Например от коммутатора SG350X-48MP 48-Port Gigabit PoE Stackable Managed Switch местный DNS сервер за пол часа наблюдений словил около 2000 запросов на разрешение разных имён. При этом практически весь этот трафик содержал запросы на разрешение имён как публичных, так и внутренних NTP серверов.
-
Коммутаторы Cisco Small Business и тысячи запросов к DNS серверу
-
Сказ о том, как интерфейс iLO5 у сервера HPE ProLiant DL380 Gen10 терял подключение к сети или "Нет повести печальнее на свете, чем повесть о блуждающем пакете…"
Жила-была одна небольшая производственная площадка со своим скромным сетевым и серверным скарбом, к которому в один прекрасный момент присовокупили новый сервер HPE ProLiant DL380 Gen10 с контроллером удалённого управления iLO5. При первичной настройке сервера местные специалисты обратили внимание на то, что сетевой интерфейс iLO, настроенный на получение IP адресации с DHCP, теряет подключение к сети через несколько минут после начала работы. И тут начались хождения по мукам… -
Лохматим сервер Cisco WSA S690 (Cisco UCS C240 M4 Server) : Получаем root-доступ к AsyncOS, захватываем управление IMC, устанавливаем альтернативную ОС
Программно-аппаратное решение Cisco WSA S690 с аппаратной точки зрения строится на базе серверной платформы Cisco UCS C240 M4, а с программной точки зрения - на базе предустановленной ОС AsyncOS. Владельцы такого решения, оставшиеся без поддержки вендора, и желающие использовать серверную платформу под альтернативные задачи, могут столкнуться с невозможностью использовать сторонние загрузчики инсталляторов операционных систем. В этой статье мы рассмотрим ряд манипуляций, которые позволят нам решить данную проблему. -
Обновление и откат микрокода контроллера CIMC на серверной платформе Cisco UCS
При работе с микрокодом контроллера управления Cisco Integrated Management Controller (CIMC) у администраторов, не искушённых в этой области, иногда могут случаться непредвиденные ситуации. Например, мой первичный опыт попыток обновления прошивки IMC через интерфейс Web UI, встроенный в этот контроллер, в рамках версии 2.0 показал, что после очередного обновления веб-интерфейс IMC начал вести себя нештатным образом (возникли проблемы с работой флэш-содержимого). И в этой ситуации для решения проблемы может быть использован протокол SSH, с помощью которого мы можем произвести откат на предыдущую работающую версию микрокода, либо обновление на более новую версию, где проблема с доступом по HTTP уже исправлена. В этой заметке мы рассмотрим пример обновления и отката микрокода IMC с помощью протокола SSH. -
Второе дыхание для серверной платформы Cisco WSA S695 (Cisco UCS C240 M5 Server)
Пару лет назад в одной динамично развивающейся компании было приобретено некоторое количество серверов Cisco Web Security Appliance (WSA) S695 под задачу построения управляемой инфраструктуры прокси серверов. Под мою опеку попали два таких сервера довольно не слабой конфигурации: 2 процессора Intel Xeon Gold 6126, 64GB ОЗУ PC4-21300, контроллер RAID SAS 12G c 4GB кеша, расширенная корзина с 16 дисками HDD SAS 12G 600GB 10K, дублированное питание/вентиляторы горячей замены и прочие прелести в корпусе RM 2U.
На борту этих серверов была предустановлена среда управления на базе специализированной ОС Cisco AsyncOS. Лицензировалось всё это дело по временно-действующей подписке и функции прокси работали только либо по активированной действующей лицензии, либо в рамках краткосрочного Grace Period. И вот наступил 2022 год … и Cisco, как и ряд других "закадычных друзей", громко хлопнула дверью, прекратив отгрузки, поддержку и активацию лицензий.
-
Сказ про то, как Avito может за-DoS-ить прокси сервер Cisco WSA
Эта небольшая история про то, как произвольный, криво работающий, сайт в Интернете может свести с ума прокси сервер Cisco WSA, который позиционируется как решение класса "кровавый энтерпрайз". Последующее повествование будет идти от лица моего коллеги, работающего в Телеком блоке и обнаружившего ниже описанную аномалию. -
Удалённая эксплуатация службы Cisco Smart Install в коммутаторах Cisco Catalyst
Буквально на днях была опубликована любопытная статья Embedi Blog - Cisco Smart Install Remote Code Execution, описывающая пример эксплуатации уязвимости службы Smart Install в коммутаторах Cisco CVE-2018-0171, которой сам вендор присвоил критический уровень опасности. Приведённый в статье пример содержит скрипт, с помощью которого можно удалённо вызвать отказ в обслуживании устройства Cisco (краш IOS с последующей перезагрузкой устройства), на котором выполняется служба Smart Install. Это очередное напоминание сетевым администраторам о том, что к данной службе нужно строго ограничивать доступ, либо вовсе отключать её в том случае, если её функционал не используется. Безотносительно упомянутой уязвимости, в этой заметке мы рассмотрим наглядный пример несанкционированного удалённого управления коммутатором Cisco, на котором не настроено ограничение доступа к службе Smart Install. -
Настройка Network Bonding с LACP между CentOS Linux 7.2 и коммутатором Cisco 3560G
На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. C точки зрения повышения доступности и балансировки нагрузки, более эффективными методом использования нескольких сетевых интерфейсов сервера является объединение этих интерфейсов в логические сущности с использованием технологий Network Bonding и Network Teaming.В этой заметке на конкретном примере мы рассмотрим то, как с помощью технологии Network Bonding в ОС CentOS Linux 7.2 можно организовать объединение физических сетевых интерфейсов сервера в логический сетевой интерфейс (bond), а уже поверх него создать виртуальные сетевые интерфейсы под разные задачи и сетевые службы с изоляцией по разным VLAN. Агрегирование каналов между коммутатором и сервером будет выполняться с помощью протокола Link Aggregation Control Protocol (LACP) регламентированного документом IEEE 802.3ad. Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потери доступности сетевых сервисов сервера, и с другой стороны, обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера. Настройка в нашем примере будет выполняться как на стороне коммутатора (на примере коммутатора Cisco Catalyst WS-C3560G), так и на стороне Linux-сервера с двумя сетевыми интерфейсами (на примере сервера HP ProLiant DL360 G5 с контроллерами Broadcom NetXtreme II BCM5708/HP NC373i)
-
Сброс настроек на коммутаторе Cisco Catalyst 2950
Это маленькая заметка о том, как сбросить все настройки Cisco IOS версии 12.X на коммутаторах Cisco на примере коммутатора Cisco Catalyst 2950 WS-C2950T-24.Для сброса настроек нам потребуется прямой физический доступ к порту console на задней части коммутатора и соответствующий кабель RJ45-DB9(Female). В случае отсутствия оригинального кабеля изготовить его можно самостоятельно используя схему распиновки, приведённую в документе Catalyst 2950 Switch Hardware Installation Guide (раздел Connectors and Cables):
-
Отделяем трафик Hyper-V Shared Nothing Live Migration
После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-V - Shared Nothing Live Migration для хостов, не являющихся членами кластеров. Здесь я опишу практический пример действий, которые были выполнены для того, чтобы отделить трафик миграции от основного трафика управления хостом виртуализации. В рассматриваемом примере имеется два сервера виртуализации HP ProLiant DL380 G5 с дополнительно установленным двух-портовым гигабитным сетевым адаптером HP NC360T. Таким образом каждый сервер имеет по четыре гигабитных сетевых интерфейса, которые мы будем использовать в следующем порядке:- Port 1 NC373I (On-Board NIC1) – Под трафик резервного копирования DPM
- Port 2 NC373I (On-Board NIC2) – Под трафик Live Migration (LM)
- Port 3 NC360T (PCI-E NIC Port1) – Под трафик управления хостом
- Port 4 NC360T (PCI-E NIC Port2) – Под трафик виртуальных машин
Онлайн-курсы Евгения Лейтана
Внедрение Microsoft System Center Operations (SCOM) 2016/201913 уроков (6 часов видео), лабораторные работы и вручение именного сертификата.
Промокод "IT-KB_60" со скидкой 60%!
RSS - Записи