В этой небольшой заметке мы рассмотрим пошаговый план действий по миграции двух серверов на базе ОС Windows Server 2012 R2 с ранее настроенной и работающей высоко-доступной конфигурацией DHCP Failover на более новую ОС Windows Server 2016. В качестве исходной конфигурации имеется два виртуальных сервера KOM-DHCP1 и KOM-DHCP2 на базе ОС Windows Server 2012 R2 Standard с работающими меж-серверными отношениями DHCP Failover в режиме Load balance.
Требуется поднять на обоих серверах версию ОС до уровня Windows Server 2016, не прерывая при этом доступность сервиса DHCP для клиентов.
-
План миграции высоко-доступной конфигурации DHCP Failover из двух серверов на базе Windows Server 2012 R2 на Windows Server 2016
-
Сказ о том, как интерфейс iLO5 у сервера HPE ProLiant DL380 Gen10 терял подключение к сети или "Нет повести печальнее на свете, чем повесть о блуждающем пакете…"
Жила-была одна небольшая производственная площадка со своим скромным сетевым и серверным скарбом, к которому в один прекрасный момент присовокупили новый сервер HPE ProLiant DL380 Gen10 с контроллером удалённого управления iLO5. При первичной настройке сервера местные специалисты обратили внимание на то, что сетевой интерфейс iLO, настроенный на получение IP адресации с DHCP, теряет подключение к сети через несколько минут после начала работы. И тут начались хождения по мукам…
-
Сказ про то, как Avito может за-DoS-ить прокси сервер Cisco WSA
Эта небольшая история про то, как произвольный, криво работающий, сайт в Интернете может свести с ума прокси сервер Cisco WSA, который позиционируется как решение класса "кровавый энтерпрайз". Последующее повествование будет идти от лица моего коллеги, работающего в Телеком блоке и обнаружившего ниже описанную аномалию.
-
Сканирование сети на предмет выявления модулей управления ИБП APC уязвимых к Ripple20
В прошлом году компанией JSOF была публично раскрыта информация о целом наборе уязвимостей, корни которых уходят в древнюю библиотеку компании Treck, реализующую функции стека протоколов TCP/IP. Эту библиотеку на протяжении многих лет использовали разные производители аппаратного обеспечения для обеспечения работы TCP/IP во встроенном микрокоде firmware на множестве разных типов устройств. Данный пакет уязвимостей получил общее название Ripple20.
Уязвимости, входящие в состав Ripple20, имеют разные уровни критичности и среди них есть некоторые опасные уязвимости, позволяющие удалённо вызвать отказ в обслуживании или даже получать полный доступ над устройством со всеми вытекающими последствиями.
Данная проблема была освещена на множестве интернет-ресурсов, связанных с темой информационной безопасности. Вот некоторые из них:
- Блог Касперского - Ripple20: 19 уязвимостей в библиотеке TCP/IP
- SecurityLab - Уязвимости Ripple20 затрагивают миллиарды устройств по всему миру
- "Хакер" - Сотни миллионов IoT-устройств в опасности из-за уязвимостей Ripple20
Часть вендоров на протяжении нескольких месяцев после огласки Ripple20 выпустили обновления микрокода для своих продуктов, в которых закрываются данные уязвимости. Однако некоторые производители намеренно отказались от обновления микрокода некоторых своих продуктов, снятых с текущей поддержки. Таким образом, все уязвимые устройства, не имеющие обновления, но по прежнему эксплуатируемые в рамках локальных/глобальных сетей, вошли в группу повышенных рисков нарушения режима ИБ.
Проблема с уязвимостями Ripple20 заключается в том, что работа по снижению рисков в рамках больших корпоративных сетей с множеством устройств разных производителей и моделей, требует комплексного подхода с применением разных методик защиты, таких как обновление микрокода, ужесточение правил меж-узлового взаимодействия на уровне сети, использование систем обнаружения сетевых аномалий и т.д.
Применительно к вопросу обновления микрокода на эксплуатируемых сетевых устройствах, требуется отдельное планирование и немалый объём работы по устройствам каждого отдельно взятого производителя и модели. В данной заметке мы рассмотрим вариант сбора информации относительно модулей управления источников бесперебойного питания (ИБП) марки APC ("APC by Schneider Electric"), которые широко используются для защиты электропитания серверного и сетевого оборудования.
-
Уязвимость CallStranger (CVE-2020-12695) в Universal Plug and Play (UPnP) и PowerShell скрипт для сканирования сети по протоколу SSDP
На прошлой неделе в Российском сегменте Интернета снова заговорили о проблемах безопасности в технологии Universal Plug and Play (UPnP). Например, можно ознакомится со статьями Уязвимость в UPnP, подходящая для усиления DDoS-атак и сканирования внутренней сети и Уязвимость UPnP, позволяющая сканировать сети и организовывать DDoS-атаки, признана официально. В разных источниках проблемы безопасности UPnP рассматриваются в большей степени в контексте устройств и ПО, подключенных к глобальной сети Интернет. Однако, хочется отметить тот факт, что неконтролируемые администраторами технологии UPnP несут в себе определённые риски и в рамках локальных корпоративных сетей. В этой статье мы рассмотрим простейший пример возможности эксплуатации уязвимости UPnP в локальной сети и поговорим о том, как можно выявить уязвимые устройства в сети для последующей их защиты.
-
Базовая настройка брандмауэра Debian GNU/Linux 10 Buster с помощью nftables
Согласно документа в Debian Wiki фреймворк nftables представляет собой механизм, используемый ОС Debian 10 Buster по умолчанию для управления встроенного в ядро Linux брандмауэра Netfilter. Nftables может рассматриваться, как современная, более продвинутая и функциональная замена таким инструментам, как iptables, ip6tables, arptables и ebtables. Читать далее...
-
Ошибки Event ID 1026 и 1000 с исключением lbfoadmin.exe при попытке редактировать свойства NIC Team с отсутствующими сетевыми адаптерами в оснастке Server Manager в Windows Server 2012 R2
При использовании технологии NIC Teaming в Windows Server 2012 R2 можно столкнуться с проблемой потери возможности управления свойствами созданного ранее тима через графическую оболочку Server Manager в том случае, если сетевые адаптеры, являющиеся членами тима, стали недоступны. Рассмотрим пример такой ситуации и способ решения проблемы.
-
1С:Предприятие 8.3 и приоритизация протокола IPv4 над IPv6 в Windows Server 2012 R2
Анализируя содержимое технологического журнала сервера 1С:Предприятие 8.3 можно обнаружить события проверки соединения с рабочим сервером кластера 1С. В случае, когда сервер проверяет сам себя мы можем заметить, что используется IPv6, несмотря на то, что, возможно, ранее мы отключали использование этого протокола в свойствах сетевого подключения в Windows. Читать далее...
-
Превращаем старый сервер в iSCSI Target с помощью Enterprise Storage OS (ESOS)
Продолжая тему полезного использования старого серверного оборудования, на этот раз поговорим об использовании сервера модели IBM System x3200 4362 в качестве сетевого хранилища, доступного по протоколу iSCSI в качестве iSCSI Target. В прошлый раз мы уже рассматривали такой сервер в роли хранилища резервных копий виртуальных машин с программной дедупликацией от Quadstor. Однако в нашем случае ситуация усугубилась тем, что на некоторых удалённых площадках, где была развёрнута описанная конфигурация, виртуальные машины, подвергавшиеся резервному копированию, со временем получили дополнительный диск под хранение контента для точки распространения SCCM. А, как известно, содержимое дисков, которые используются под распространение контента в SCCM может временами очень активно меняться (загружаются новые обновления SUP, удаляются просроченные обновления, загружается какое-либо ПО для развёртывания и т.п.). Поэтому, учитывая то обстоятельство, что используемое ПО Veeam Backup Free Edition не позволяет исключать из резервной копии виртуальных машины отдельные виртуальные диски, принадлежащие этой ВМ, пришлось решать вопрос об увеличении дискового пространства на этих самых серверах IBM. Параллельно встал вопрос о полезности дедупликации, которая в случае часто меняющееся контента теряет свой КПД.