В одной из прошлых заметок мы рассматривали процедуру обновления экземпляра HPE B-series SAN Network Advisor 12.4.1 до более новой версии 12.4.2 методом in-place upgrade. Принципиальных отличий процедура обновлений не претерпела и до текущих релизов 14 версии продукта. Однако между под-версиями 14.2 и 14.3 произошли некоторые изменения уровня безопасности, в результате которых процесс обновления может завершиться ошибкой.
-
Ошибка "Server failed to start. HPE B-series SAN Network Advisor will be rolled back to previous version" при обновлении с версии 14.2 на версию 14.4
-
ИТ Вестник #TheEnd
Представляем вашему вниманию очередной небольшой обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере за прошедшие два с половиной месяца, а также информацию об обновлениях нашего Вики-сайта. За помощь в подготовке выпуска благодарю Алексея Максимова, Виталия Якоба и Антона Мосягина.Скорее всего Вы заметили, что выпуски “ИТ Вестника” последние два месяца не выходили. Причиной тому служила перестройка подачи ИТ новостей с нашего ежемесячного поста в блоге на канал https://t.me/ITKBnews и соц. группах https://vk.com/blogitkb и https://www.fb.com/blog.it.kb.
Это означает, что больше в блоге не будет данной тематики. Почему это произошло:
- Во-первых, актуальная новость – свежая (1-2 дня, возможно часы или даже минуты) новость, а не месячной давности.
- Во-вторых, с учетом очень большого количества ИТ новостей и даже с учетом отбора наиболее интересных статей нашими силами, получается огромная нагрузка в конце месяца на читателя. А как известно, лучше принимать и усваивать информацию небольшими порциями.
- В-третьих, разбивать на более мелкие партии, т.е. каждую неделю, тоже не комильфо (уходит много времени), а время – деньги!
Поэтому поступило от нас предложение подключиться Вам, уважаемые подписчики, к более современным и удобным каналам поставки информации https://t.me/ITKBnews и соц. группах https://vk.com/blogitkb и https://www.fb.com/blog.it.kb. Для каждого есть свое мобильное приложение с возможностью чтения его на любом из устройств. Готовы выслушать ваши пожелания в комментариях к данному посту, в чате https://t.me/chatitkbru или в соц. группах https://vk.com/blogitkb и https://www.fb.com/blog.it.kb.
Итак, поехали…
-
Ошибка проверки подлинности при подключении к удалённому рабочему столу Windows RDS …"Причиной ошибки может быть исправление шифрования CredSSP"
Информация об уязвимости в провайдере безопасности CredSSP ОС Windows была опубликована 13.03.2018 в документе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability. В этом документе можно найти ссылки на обновления безопасности, которые были выпущены для закрытия этой уязвимости. Выпущенные обновления относятся к механизмам CredSSP, как в клиентских, так и в серверных ОС Windows. При этом неправильная последовательность развёртывания обновлений, касающихся CredSSP, может привести к неожиданным последствиям. -
Удалённая эксплуатация службы 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. -
Обход некоторых видов ограничений запуска приложения через механизмы Software Restriction Policies (в режиме Unrestricted) в групповых политиках Active Directory
Некоторые администраторы применяют в своей инфраструктуре Active Directory (AD) функционал Software Restriction Policies (SRP), имеющийся в составе Group Policy, для того, чтобы явным образом ограничивать запуск и исполнение каких-либо приложений. То есть используется сценарий ограничительных мер по типу "разрешено всё, кроме того, что явно запрещено". Например, в рамках мероприятий по противодействию новомодным комплексным шифровальщикам, у некоторых администраторов может возникнуть желание явно запретить запуск некоторых исполняемых файлов, используемых вредительским ПО, не запрещая при этом запуск всех прочих приложений и не используя механизмы проверки цифровых подписей.В данной заметке мы поговорим о том, почему мероприятия подобного рода могут оказаться малоэффективны, наглядно продемонстрировав пример того, как любой непривилегированный пользователь может без особых сложностей обойти некоторые механизмы защиты. В качестве наглядного примера мы рассмотрим ситуацию с запретом исполнения небезызвестной утилиты PsExec из пакета PsTools Sute.
-
Опрос сети на предмет поиска уязвимых версий службы управления ключами SafeNet Sentinel License Manager (HASP License Manager)
Многим администраторам так или иначе приходилось в своей работе сталкиваться с аппаратными ключами защиты Alladin HASP/SafeNet Sentinel и приходилось устанавливать поставляемый в составе ПО поддержки этих ключей программный пакет HASP License Manager/Sentinel License Manager. Это приложение отвечает за контроль лицензий всевозможного ПО, используемого во множестве самых разных приложений, начиная с бизнес-систем типа 1С и заканчивая разнообразными критичными для производственных процессов системами АСУ ТП.Как правило, единожды установив это ПО, администратор не задумывается о необходимости его периодического обновления, так как не для всех очевидно то, что такое ПО может стать источником серьёзных проблем информационной безопасности, делая систему, на которой оно установлено, критически уязвимой и открывая новые векторы для возможных атак.
-
Способы смены пароля учётной записи пользователя в RDP-сессии
При использовании удалённого подключения к операционным системам Microsoft Windows/Windows Server по протоколу RDP в некоторых случаях может возникать потребность в смене пароля учётной записи пользователя. При этом инициатором смены пароля в разных ситуациях может выступать как сам пользователь, так и администратор Windows-системы. В некоторых сценариях может получиться так, что, казалось бы, несложная задача смены пароля может стать не такой уж и простой. Поэтому в данной записи я попробую собрать информацию о самых разнообразных способах смены пароля учётной записи пользователя в RDP-сессии. -
О мальчике Бобби, который любил деньги или ещё раз про добровольно-принудительный веб-майнинг
Опубликовав последнюю заметку об Icinga, я решил поискать в русскоязычном сегменте Интернета последние материалы по теме Icinga и попал на сайт, который уже как-то ранее мне попадался на глаза (ссылку на сайт не привожу намеренно, хотя дальше всё итак будет понятно). Попытавшись просмотреть последние заметки на этом сайте, я обратил внимание на появившуюся через несколько минут звуковую индикацию материнской платы моего компьютера, характерную для ситуаций с перегревом процессора. Это меня несколько смутило, ибо, как я думал, ничего ресурсоёмкого в моей пользовательской сессии в этот момент не выполнялось. Читать далее... -
Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory
Представим себе ситуацию, что есть некий сервер на базе Debian GNU/Linux, который уже введён в домен Active Directory с помощью SSSD и realmd и на нём уже имеется keytab-файл, который используется для механизмов аутентификации Kerberos и Single sign-on (SSO) при подключении к серверу по протоколу SSH. И вот возникает необходимость на данном Linux-сервере дополнительно настроить роль веб-сервера для служебных администраторских задач и организовать Kerberos SSO при подключении к веб-узлам этого веб-сервера. По ранее описанным примерам (здесь, здесь и здесь), предполагается, что для целей Kerberos-аутентификации веб-сервера Apache в домене Active Directory (AD) создаётся отдельная сервисная учётная запись типа User, для которой генерируется keytab-файл и в последствии привязывается к настройкам Apache на стороне Linux-сервера. С точки зрения аспектов безопасности такой поход (отдельный Linux-сервис = отдельная учётная запись в AD со своим keytab-файлом) можно считать вполне правильным. Но что, если Linux-сервис, использующий Kerberos-аутентификацию, используется не широким кругом пользователей, а исключительно для административных целей парой-тройкой системных администраторов? В таком случае создание отдельной учётной записи типа User в домене со своим keytab-файлом может показаться избыточным. В этой заметке мы рассмотрим пример того, как добавить дополнительную нужную нам запись servicePrincipalName (SPN) (на примере SPN-записи типа HTTP/) в уже имеющийся на Linux-сервере keytab-файл, ориентированный на сам хост (содержащий SPN-записи типа HOST/). В результате мы получим Kerberos аутентификацию на веб-узлах нашего Linux-сервера и при этом не будем плодить в домене лишние сервисные учётные записи типа User. -
Получаем право SeDebugPrivilege для успешной установки Microsoft SQL Server 2012 при ограниченной доменной политике "Debug programs"
В свете недавних событий с повышением вирусной активности многие организации стали уделять больше внимания вопросам всестороннего усиления мер безопасности в собственных ИТ-инфраструктурах. При этом некоторые из применяемых мер могут создать дополнительные сложности в работе самих ИТ-специалистов.
Последние комментарии