Вопросы и ответы

Короткие ответы на вопросы о серверном оборудовании и инфраструктуре — со ссылками на статьи, где тема разобрана подробно

Вопросов: 668Областей: 4

203 вопроса — область «Безопасность серверов» · все вопросы

Защита сервера от DDoS: firewall, провайдер и действия при атаке(6)

Почему сервер доступен из локальной сети, но недоступен из интернета?

Это возможно, если входящий канал до сервера, порт площадки или сеть хостинга насыщены трафиком. Локальный firewall работает только после того, как пакет дошёл до сетевого интерфейса, и не может освободить уже занятую внешнюю полосу. Поэтому доступ из локальной сети может сохраниться, а интернет-пользователи будут получать потери, задержки или тайм-ауты.

Подробнее в статье →

Поможет ли блокировка IP-адресов, если канал уже перегружен?

Обычно нет. Правило блокировки на сервере отбросит пакет только после того, как он занял часть канала и прошёл сетевое оборудование до хоста. Блокировка IP полезна лишь при небольшом числе стабильных источников, если поток не насыщает канал и правило срабатывает до перегрузки нужного ресурса. Массовые блокировки могут затронуть клиентов и усложнить диагностику.

Подробнее в статье →

Защитит ли CDN или WAF сервер с прямым IP-адресом?

Не всегда. CDN, reverse proxy и WAF защищают только те веб-точки и протоколы, которые принимаются и фильтруются у выбранного поставщика. Если origin-сервер остаётся доступен напрямую по IP, его можно атаковать в обход этой схемы. Прямой доступ к origin нужно отдельно ограничить, а поддержку нужных протоколов и маршрутизации — проверить у поставщика.

Подробнее в статье →

Что передать провайдеру при подозрении на DDoS?

Передайте время начала или предполагаемый интервал, атакуемые IP-адреса и порты, затронутые домены и сервисы, симптомы и влияние на пользователей. Полезны графики входящего и исходящего трафика, потерь, задержек, числа соединений и ошибок, а также журналы firewall, reverse proxy и приложения. Попросите номер обращения и подтверждение следующего шага.

Подробнее в статье →

Стоит ли перезагружать сервер во время атаки?

Нет, не без оценки причины перегрузки. Перезагрузка не освобождает насыщенный входящий канал, может продлить простой и уничтожить полезный контекст диагностики. Сначала сохраните доступные метрики и журналы, определите вероятно перегруженный ресурс и обратитесь к провайдеру или сервису фильтрации. Локальные изменения применяйте только точечно и с подготовленным откатом.

Подробнее в статье →

Как не спутать DDoS с ошибкой приложения или базы данных?

Проверьте, связан ли рост задержек и CPU с аномальным сетевым потоком. При DDoS могут резко вырасти трафик, новые соединения, потери или однотипные запросы. Если CPU и задержки растут без сопоставимого трафика, вероятнее проблема приложения или БД: изучите их журналы, очереди, пул соединений, время операций и недавние релизы.

Подробнее в статье →

Сегментация серверной сети: VPN, bastion host и административный доступ(5)

Как применить принцип наименьших привилегий для админдоступа?

Нужно выдавать доступ не к сети целиком, а конкретной роли, цели и протоколу. Для каждого сценария фиксируют источник подключения, точку входа, сервер или BMC, допустимое действие, срок и владельца согласования. Подключение к VPN само по себе не должно давать право на SSH, RDP или управление оборудованием.

Подробнее в статье →

Какие угрозы снижает сегментация серверной сети?

Сегментация уменьшает число путей к административным интерфейсам и ограничивает область доступных систем при компрометации учётной записи или узла. Она помогает не допустить прямой доступ из интернета к SSH, RDP и BMC и сдерживает боковое перемещение. Однако VPN, bastion и межсетевые правила не исключают компрометацию полностью.

Подробнее в статье →

Даёт ли подключение к VPN доступ к SSH, RDP и BMC?

Нет, не должно давать. VPN создаёт защищённый путь во внутреннюю сеть, но не определяет полномочия пользователя сам по себе. После аутентификации нужно отдельно ограничить маршруты и правила межсетевого экрана, а на целевых системах — проверить роль и права на SSH, RDP или интерфейс BMC.

Подробнее в статье →

Что делать, если VPN или bastion недоступен?

Нужен заранее оформленный аварийный break-glass-доступ. Условия его использования, ответственные лица и способ хранения аварийных учётных данных фиксируют отдельно. Такой канал применяют только при отказе штатного пути, MFA или сетевой связности, а не для обычных работ; его использование должно журналироваться и разбираться после восстановления.

Подробнее в статье →

Как проверить, что доступ не открыт шире нужного?

Проверьте доступ тестовыми учётными записями для каждой роли. Разрешённая цель и протокол должны работать, а подключение к соседнему серверу, другому протоколу или BMC — отклоняться. Затем сверяйте события VPN или bastion с журналами целевых систем и ищите правила, маршруты или членство в группах, создающие неописанный доступ.

Подробнее в статье →

IDS и IPS для сервера: Suricata и OSSEC без ложной уверенности(6)

Как проверить Suricata после настройки на Linux?

Начните с безопасного тестового запроса, который должен соответствовать выбранному правилу. Одновременно проверьте событие alert, статистику захвата пакетов и доступность тестового сервиса. Если правило не сработало, проверьте точку захвата, оба направления трафика, загрузку правила и применимость сигнатуры. Сам факт запуска процесса не подтверждает, что сервис контролируется.

Подробнее в статье →

Нужен ли менеджер OSSEC для одного сервера?

Не обязательно. Для пилота на одном сервере можно оценить локальную установку OSSEC. Схема manager/agent полезна для нескольких узлов, когда нужна защищённая передача данных, централизованное хранение и разбор оповещений. Если центральная схема ещё не подготовлена, не стоит массово разворачивать агентов: сначала подтвердите работу на одном хосте.

Подробнее в статье →

Может ли Suricata блокировать трафик со SPAN-порта?

Нет. На SPAN-порту, TAP или иной точке зеркалирования Suricata получает только копию пакетов и может создавать alert в EVE JSON, но не остановит исходный пакет. Для блокировки трафик должен проходить через корректно настроенную inline-схему, где результат обработки передаётся компоненту, который пропускает или отбрасывает пакеты.

Подробнее в статье →

Почему Suricata не видит HTTP-запросы по TLS?

Потому что TLS шифрует прикладное содержимое. В обычной точке наблюдения сетевой сенсор видит IP-адреса, порты, свойства TLS-сеанса и часть метаданных, но не HTTP-запрос и полезную нагрузку. Для анализа содержимого нужна контролируемая точка после TLS-терминации либо отдельная архитектура расшифрования с оценкой рисков для ключей и персональных данных.

Подробнее в статье →

Что делать, если alert есть, а запрос всё равно дошёл до приложения?

Сначала проверьте размещение сенсора и путь пакета. Для пассивной схемы с зеркалированием это ожидаемое поведение: Suricata только фиксирует событие. Если ожидалась блокировка, убедитесь, что поток проходит через inline-схему, движок работает в соответствующем режиме и пакет получает вердикт отброса. Не включайте блокировки на продуктивном сервисе без тестов и плана отката.

Подробнее в статье →

Как не заполнить диск журналами Suricata?

До включения расширенного EVE JSON определите срок хранения, ротацию, доступ к файлам и способ доставки событий. Включайте как минимум alert, а записи flow, dns, http, tls и другие — только если они нужны для расследований. Контролируйте место на диске; если журнал быстро растёт, уменьшите состав записываемых типов, измените ротацию, хранение или доставку.

Подробнее в статье →

Шифрование данных на сервере: LUKS, BitLocker, TPM и Secure Boot(6)

Почему BitLocker после изменения UEFI или загрузчика просит recovery key?

Это нормальный защитный сценарий. TPM-протектор BitLocker привязан к ожидаемым значениям PCR, связанным с измерениями загрузки. Изменение firmware, настроек UEFI, Secure Boot, порядка загрузки, загрузчика, параметров запуска или некоторых дисков может изменить это состояние. Тогда TPM не выдаёт ключ автоматически, и BitLocker запрашивает ключ восстановления.

Подробнее в статье →

Что означает Secure Boot disabled на сервере?

Это означает, что UEFI не проверяет подписи компонентов загрузочной цепочки в режиме Secure Boot. LUKS или BitLocker при этом могут продолжать защищать данные в покое, но исчезает барьер против запуска неподписанного или подменённого компонента до старта ОС. Для BitLocker с TPM такое изменение также может вызвать запрос recovery key при следующей загрузке.

Подробнее в статье →

Что остаётся незашифрованным при LUKS для root-раздела?

Зависит от дистрибутива и схемы загрузки. До разблокировки LUKS должны быть доступны EFI System Partition с загрузчиком и компоненты, нужные для запуска ядра и initramfs. В типичной UEFI-схеме отдельный /boot также может оставаться незашифрованным. Точный состав разделов нужно сверять с документацией используемых cryptsetup, загрузчика и дистрибутива.

Подробнее в статье →

Влияет ли шифрование диска на производительность сервера?

Да, но универсального процента потери производительности нет. Влияние зависит от процессора и криптографических инструкций, SSD или HDD, очередей ввода-вывода, RAID-контроллера, драйверов, алгоритма шифрования и нагрузки приложения. Перед внедрением измерьте задержки, IOPS, пропускную способность и загрузку CPU на конфигурации, близкой к рабочей.

Подробнее в статье →

Где хранить BitLocker recovery key для Windows Server?

Не на единственном зашифрованном сервере и не рядом с ним. Для доменного сервера recovery-информацию можно резервировать в Active Directory Domain Services при соответствующих политиках или использовать другой утверждённый корпоративный механизм. Для автономного сервера нужен отдельный контролируемый носитель или хранилище секретов с ограниченным доступом и проверенной процедурой выдачи.

Подробнее в статье →

Можно ли включить Secure Boot на уже работающем сервере?

Да, но только после проверки совместимости и подготовки восстановления. Старые загрузчики, драйверы, карты расширения и нестандартные ОС могут не запуститься с включённым Secure Boot. До изменения подготовьте консольный доступ и recovery-материалы, выполните работы в окно обслуживания и используйте руководство производителя для конкретной модели и версии firmware.

Подробнее в статье →

TLS-сертификаты на сервере: как работают и какой выбрать(6)

TLS или SSL: что выбрать?

Выбирайте TLS: это современный протокол защиты данных при передаче по сети. SSL — устаревшее семейство протоколов; SSL 2.0 и SSL 3.0 не следует включать в рабочих конфигурациях. Термины «SSL-сертификат» и «цепочка SSL-сертификатов» часто сохраняются в интерфейсах, но обычно означают сертификаты, используемые для TLS.

Подробнее в статье →

Можно ли использовать самоподписанный SSL-сертификат?

Да, но только когда доверие можно установить и сопровождать явно: например, в изолированном контуре, лаборатории, временном сервисе или для отдельного устройства. Клиенты должны заранее проверить и добавить конкретный сертификат либо его публичный ключ в доверенные. Для произвольных внешних клиентов самоподписанный сертификат не подходит.

Подробнее в статье →

Что такое CSR и заменяет ли он сертификат?

CSR — это запрос на выпуск сертификата, а не готовый сертификат. Он содержит открытый ключ и заявляемые атрибуты, а подпись CSR подтверждает владение соответствующей ключевой парой. CSR не заменяет закрытый ключ и сам по себе не доказывает клиенту право на доменное имя: это отдельно проверяет центр сертификации.

Подробнее в статье →

Что такое OCSP stapling?

OCSP stapling — механизм, при котором сервер заранее получает подписанный OCSP-ответ о статусе сертификата и передаёт его клиенту во время TLS-рукопожатия. Это может сократить обращения клиентов к OCSP-респондеру. Однако не все клиенты обязаны запрашивать, получать или одинаково обрабатывать такой ответ.

Подробнее в статье →

Есть ли в PFX-сертификате закрытый ключ?

Да, контейнер PFX, или PKCS#12, может содержать закрытый ключ, сертификат владельца и сертификаты цепочки. Обычно такой бинарный контейнер защищён паролем и удобен для переноса. Перед импортом или передачей нужно выяснить состав PFX и способ защиты: закрытый ключ нельзя отправлять по незащищённым каналам или хранить рядом с общедоступными сертификатами.

Подробнее в статье →

Что такое mTLS и достаточно ли сертификата клиента для доступа?

mTLS — это двусторонний TLS: клиент проверяет сертификат сервера, а сервер запрашивает и проверяет сертификат клиента. Нет, успешная проверка сертификата клиента не означает автоматический доступ. Сервер должен сопоставить сертификат с субъектом и применить правила авторизации для действий, ресурсов и ролей.

Подробнее в статье →

Антивирус и контроль целостности сервера: Defender, ClamAV, AIDE и rootkit-проверка(6)

Как понять, что Windows Defender Server отключён?

Проверяйте состояние через Get-MpComputerStatus, а не по значку или одной службе. В типичной конфигурации важны AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled, версия и дата security intelligence, а также признаки пассивного режима. Defender может быть отключён политикой, удалён как компонент или перейти в пассивный режим при зарегистрированном стороннем антивирусе.

Подробнее в статье →

Можно ли считать расхождение AIDE признаком взлома?

Нет, не само по себе. AIDE показывает отличие текущего файла или атрибута от доверенной базы, но не определяет, кто и зачем внёс изменение. Обновление пакета, согласованная смена конфигурации и штатная автоматизация могут быть причиной расхождения. Неожиданные изменения ключей SSH, unit-файлов, cron-заданий и исполняемых файлов требуют приоритетного триажа.

Подробнее в статье →

Опасны ли исключения Windows Defender на сервере?

Да, широкие исключения создают неконтролируемую зону без проверки. Особенно рискованно исключать весь диск, пользовательские загрузки, общие хранилища, временные каталоги, интерпретаторы и процессы общего назначения. Исключение допустимо только при подтверждённой несовместимости или измеримой проблеме производительности и должно быть минимальным по пути, процессу, расширению и сроку действия.

Подробнее в статье →

Исключает ли отрицательная проверка rkhunter rootkit?

Нет. Rootkit-сканер ищет известные сигнатуры, подозрительные настройки, свойства файлов и другие типовые признаки, поэтому отрицательный результат не доказывает отсутствие компрометации. Сканер может не знать новый образец, не увидеть скрытый объект или работать уже в недоверенной среде. Его результат используют как источник гипотез вместе с журналами и другими проверками.

Подробнее в статье →

Как проверить каталог загрузок ClamAV?

Для рекурсивной проверки каталога загрузок можно использовать clamscan -r --infected /srv/uploads. Параметр --infected оставит в выводе только обнаруженные объекты. Команду запускают от учётной записи с правом чтения нужных файлов. Для повторяющихся проверок обычно удобнее clamd и клиент clamdscan, поскольку демон держит сигнатурные базы в памяти.

Подробнее в статье →

Что означает несовпадение файлов в rpm -V или debsums?

Несовпадение означает, что отдельные файлы не соответствуют метаданным установленного пакета, но не доказывает взлом. Причиной могут быть легитимная правка конфигурации, локальная автоматизация или неполное обновление. Неожиданное изменение системного бинарника, библиотеки, sudoers, SSH-конфигурации, unit-файла или задания планировщика нужно сначала зафиксировать и расследовать, а не сразу исправлять переустановкой пакета.

Подробнее в статье →

Firewall сервера: default deny, порядок правил и политика доступа(6)

Как ограничить доступ к SSH-порту только определёнными IP?

Нужно создать разрешающее правило для новых подключений, которое одновременно задаёт административный сервис, протокол, порт и разрешённые IP-адреса или подсети источников. SSH не следует открывать для всех, если доступ возможен только через VPN, bastion host или выделенные административные адреса. Для часто меняющихся источников лучше использовать именованную группу или набор адресов.

Подробнее в статье →

Нужны ли отдельные правила для IPv6, если есть белый список IPv4?

Да. IPv4-allowlist не ограничивает доступ по IPv6: это самостоятельный путь к сервису. Если сервис слушает IPv6 и правила созданы только для IPv4, он может остаться доступным неразрешённым клиентам. Нужно отдельно проверить правила для обоих семейств адресов и область действия правила в используемом firewall.

Подробнее в статье →

Почему разрешающее правило firewall не срабатывает?

Чаще всего поток перекрывает более широкое правило, зона, профиль, политика цепочки или другой путь обработки. Проверьте фактические IP-адреса, IP-версию, интерфейс, протокол, порт и состояние соединения, затем найдите все совпадающие правила. Счётчики и журналы помогают подтвердить, дошёл ли пакет до нужного правила.

Подробнее в статье →

Нужно ли блокировать весь ICMPv6 на сервере?

Нет. Нельзя без разбора блокировать весь ICMPv6, поскольку от его типов зависят Neighbor Discovery и Path MTU Discovery. Политика должна разрешать необходимый служебный ICMPv6 в нужных направлениях и ограничивать необоснованные типы с учётом роли сервера. Правила IPv6 нужно проверять отдельно от IPv4.

Подробнее в статье →

DROP безопаснее REJECT?

Не всегда. DROP молча отбрасывает пакет, поэтому клиент ждёт тайм-аут или повторяет попытку. REJECT возвращает явный отказ и может ускорить диагностику для легитимного клиента. Для нежелательных подключений из недоверенной сети выбор зависит от требований к диагностике, поведения клиентов и допустимости ответного пакета; сам по себе DROP не защищает от сканирования или атак.

Подробнее в статье →

Почему старая SSH-сессия работает, а новая после смены правил не открывается?

Старая сессия может сохраняться как уже отслеживаемое соединение, но это не подтверждает доступность новых SSH-подключений. До включения запрета нужно добавить узкое правило для нового административного потока: указать реальный адрес или подсеть администратора, IP-версию, порт и интерфейс. Проверять следует второй новой сессией из разрешённой сети.

Подробнее в статье →

Базовая защита сервера: как составить security baseline(6)

Что такое Zero Trust для одного сервера?

Zero Trust — это подход, при котором доступ не считают доверенным только из-за внутренней сети. Для одного сервера это означает явную проверку идентичности при административном доступе, ограничение прав и разрешение только необходимых сетевых потоков. Zero Trust не заменяет firewall, MFA или security baseline и не является готовым чек-листом hardening.

Подробнее в статье →

Что означает принцип минимальных привилегий на сервере?

Принцип минимальных привилегий означает, что пользователь, служба и автоматизация получают только те права, которые нужны для их задачи. Администраторам следует использовать персональные обычные учётные записи и отдельный контролируемый привилегированный доступ. Это позволяет связать действия с конкретной идентичностью и уменьшить последствия компрометации аккаунта.

Подробнее в статье →

Что считать инцидентом безопасности сервера?

Инцидентом может быть не только подтверждённый взлом. Подозрительное событие тоже требует триажа: например, необычный вход, создание учётной записи, изменение конфигурации, остановка защитной службы или очистка журналов. Для таких случаев заранее определяют контакты, критерии эскалации, допустимые способы изоляции и канал аварийного управления.

Подробнее в статье →

Заменяют ли firewall и патчи журналы, EDR или IDS?

Нет, эти меры дополняют друг друга. Firewall ограничивает сетевой путь, но не исправляет уязвимость доступного приложения. Патчи закрывают известные проблемы, но не отменяют ограничение привилегий. Журналы помогают обнаружить событие, а EDR, IDS или IPS могут сигнализировать или блокировать часть активности, но не заменяют безопасную конфигурацию.

Подробнее в статье →

Можно ли применить CIS Benchmarks или Microsoft Security Baselines без проверки?

Нет, применять такие рекомендации без проверки нельзя. CIS Benchmarks, CIS Controls и Microsoft Security Baselines полезны как ориентиры, но требования должны соответствовать роли сервера, продукту, выпуску и редакции ОС, установленному ПО, доменной политике и правилам организации. Неподходящий профиль может нарушить работу сервиса или зависимостей.

Подробнее в статье →

Что делать, если настройка firewall или SSH заблокировала администратора?

Не оставляйте изменение без контроля: используйте заранее подготовленный резервный канал управления и выполните откат по сохранённой исходной конфигурации. До изменений firewall, SSH/RDP и политик доступа нужны окно обслуживания, аварийная учётная запись, список зависимостей и измеримый план отката. После каждого изменения проверяйте новый вход отдельной сессией.

Подробнее в статье →

Защита BMC: безопасная настройка iDRAC, iLO и сети управления(6)

Как проверить безопасность BMC на сервере?

Проверьте BMC отдельно от операционной системы. Убедитесь, что firmware актуальна, интерфейс не доступен из интернета, сеть управления изолирована, доступ разрешён только доверенным источникам, а ненужные службы отключены. Также проверьте персональные учётные записи, роли, TLS-сертификат, журналы и работоспособность аварийного пути восстановления доступа.

Подробнее в статье →

Что включить в чек-лист hardening BMC?

В чек-лист включите инвентаризацию BMC и доступов, проверенный аварийный вход, обновление совместимой firmware, изоляцию сети управления, allowlist источников, персональные учётные записи и роли, TLS, отключение лишних служб и проверку журналов. Все изменения выполняйте в окно обслуживания и проверяйте доступ после каждого шага.

Подробнее в статье →

Можно ли открыть iDRAC или iLO в интернет?

Нет, интерфейс BMC не следует публиковать в интернете. iDRAC и iLO позволяют управлять питанием, консолью, носителями и параметрами загрузки вне контроля ОС. Размещайте их в изолированной сети управления и разрешайте доступ только от утверждённых администраторских рабочих мест, VPN и/или bastion host.

Подробнее в статье →

Что делать, если после обновления BMC пропал доступ?

Не повторяйте обновление вслепую. Сохраните сообщение об ошибке, сверитесь с руководством производителя для точной модели и версии firmware, а для восстановления используйте заранее подготовленный локальный или физический путь. После успешного обновления BMC может перезапуститься и разорвать активные сессии.

Подробнее в статье →

Можно ли отключить все локальные аккаунты после настройки LDAP?

Нет, не отключайте все локальные учётные записи, пока не подтверждён сценарий восстановления. Внешняя аутентификация может стать недоступной из-за проблем LDAP, RADIUS, TACACS+ или MFA. Сохраните минимально необходимый локальный break-glass-доступ, храните его секрет вне BMC и регулярно проверяйте вход.

Подробнее в статье →

Почему браузер показывает предупреждение при входе в BMC?

Предупреждение означает, что проверка TLS-сертификата не завершилась успешно. Причиной может быть несоответствие DNS-имени, истёкший срок, неполная цепочка сертификатов или недоверенный издатель. Не продолжайте работу, пока не установите причину; для самоподписанного сертификата сначала сверьте отпечаток независимым каналом.

Подробнее в статье →

Централизованный сбор журналов безопасности серверов(6)

Как проверить безопасность сервера?

Частично — проверку стоит начать с инвентаризации критичных активов, сценариев обнаружения и владельцев реакции. Централизованные журналы помогают выявлять входы, привилегированные действия, изменения учётных записей, запуск процессов и отключение аудита. При тревоге сначала проверьте исходные события, актив и учётную запись, а не выполняйте немедленную блокировку.

Подробнее в статье →

Могут ли журналы содержать пароли и персональные данные?

Да. Командные строки, параметры HTTP-запросов, PowerShell-транскрипты и журналы приложений могут содержать пароли, токены, адреса электронной почты и другие чувствительные данные. До массового сбора определите поля для маскирования или исключения, права на поиск и выгрузку записей, а также срок хранения.

Подробнее в статье →

Что будет, если коллектор журналов недоступен?

Гарантии сохранности нет. WEF может повторять доставку по закладкам, но события способны перезаписаться в локальном журнале до восстановления связи. Агентская очередь также ограничена диском и настроенными лимитами. Контролируйте задержку последнего события, возраст очереди, ошибки доставки и свободное место.

Подробнее в статье →

Нужно ли хранить исходные журналы после нормализации?

Да, если это разрешено требованиями к защите данных. Нормализация упрощает поиск, но может отбросить важный контекст. Сохраняйте принятую исходную запись в защищённом хранилище на установленный срок либо храните устойчивую ссылку, по которой оригинал остаётся доступным и защищённым.

Подробнее в статье →

Нужно ли сразу блокировать учётную запись по тревоге?

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

Подробнее в статье →

Почему нельзя связывать события только по имени пользователя?

Потому что одинаковые имена могут существовать в разных доменах, локальных системах и приложениях. Для связи событий предпочтительнее использовать SID или UID, идентификаторы сессии, процесса либо уникальный ID запроса. IP-адрес и временное окно применяйте только как дополнительные условия с учётом NAT и расхождения часов.

Подробнее в статье →

Управление секретами сервера: хранение, ротация и отзыв доступов(4)

Как защитить учётные записи Linux, которые запускают сервисы?

Нужно использовать отдельную служебную учётную запись или другую рабочую идентичность для каждого потребителя. Ей следует дать только доступ к нужному секрету или пути, без прав администратора, изменения политик и просмотра всего хранилища. Для файлового способа доставки ограничивают владельца, группу и права доступа, а также учитывают резервные копии.

Подробнее в статье →

Как применить принцип наименьших привилегий к секретам?

Нужно выдавать доступ конкретной идентичности и только к необходимой операции. Приложению обычно достаточно читать один секрет или отдельный путь; ему не нужны перечисление всего хранилища, изменение политик, удаление или доступ к секретам других сервисов. Права человека, CI/CD-задания и аварийного доступа также следует разделять и ограничивать по сроку.

Подробнее в статье →

Что делать, если пароль или токен попал в Git или чат?

Такой секрет следует считать раскрытым: удалить текст недостаточно. Нужно отозвать или заменить значение, перевести всех потребителей на новое, проверить доступ и ограничить исторические копии. Секрет мог остаться в истории Git, клонах, сборках, кэшах, журналах, образах и резервных копиях.

Подробнее в статье →

Можно ли передавать секрет через переменную окружения?

Можно, но только после оценки рисков: переменные окружения не являются изолированным хранилищем. В зависимости от ОС, менеджера служб и средств диагностики они могут попасть дочерним процессам, дампам памяти, отладочной информации или журналам ошибок. Секрет нельзя передавать аргументом командной строки и включать в исходный код, шаблоны или журналы.

Подробнее в статье →

Парольная политика, блокировка учётных записей и MFA в Windows Server(5)

Можно ли включить MFA для RDP одной политикой Windows Server?

Нет. Windows Server не включает MFA одной локальной или доменной настройкой. Для административного RDP-доступа MFA проектируют для конкретного канала: например, через RD Gateway, RADIUS/NPS и поддерживаемого MFA-провайдера. NLA само по себе вторым фактором не является: оно лишь переносит проверку учётных данных на этап до полного RDP-сеанса.

Подробнее в статье →

Может ли RDP заблокировать учётную запись из-за неверного пароля?

Да. Неверные пароли при подключении по RDP учитываются действующей политикой блокировки учётной записи. Сохранённый старый пароль в RDP-клиенте может повторять неудачные попытки и снова блокировать запись после ручной разблокировки. Нужно определить, является ли аккаунт локальным или доменным, и искать источник ошибок, а не только снимать блокировку.

Подробнее в статье →

Можно ли задать отдельную парольную политику доменных пользователей через OU?

Нет. GPO, привязанная только к OU с пользователями, не становится отдельной доменной парольной политикой. Базовые правила паролей и блокировки для доменных пользователей задают GPO, действующей на уровне домена. Если отдельные требования нужны части пользователей, применяют Password Settings Object (PSO), назначенный пользователям или глобальным security-группам AD.

Подробнее в статье →

Где искать причину повторной блокировки доменной учётной записи?

Начните с журналов событий и источников, где мог сохраниться старый пароль: служб, задач планировщика, RDP-клиентов, мобильных клиентов и скриптов. Событие 4625 обычно фиксирует неудачный вход на обработавшей его системе, а 4740 — блокировку, часто на контроллере домена. Для доменных сценариев также могут помочь события 4771 и 4776, если настроен аудит.

Подробнее в статье →

Можно ли назначить PSO на OU или локальную учётную запись?

Нет. Fine-grained password policy через PSO назначают только непосредственно пользователям Active Directory или глобальным security-группам AD. PSO нельзя применить к OU, компьютеру, локальной учётной записи сервера, distribution-группе, универсальной или доменно-локальной группе. Для локальных аккаунтов действуют локальные Password Policy и Account Lockout Policy сервера.

Подробнее в статье →

AppArmor на сервере: профили, enforce и диагностика отказов(5)

Нужно ли сразу включать enforce для нового профиля AppArmor?

Нет. Новый или доработанный профиль безопаснее сначала загрузить в режиме complain, воспроизвести реальные сценарии работы сервиса и разобрать журнал. После добавления только подтверждённых разрешений профиль переводят в enforce. Это снижает риск остановки сервиса из-за неучтённых файлов, helper-программ, сокетов, capabilities или сетевых операций.

Подробнее в статье →

Почему в complain mode AppArmor сервис всё равно получает отказ?

Complain не гарантирует доступ. Явные правила deny продолжают блокировать операции даже в этом режиме. Кроме того, Permission denied может быть вызван обычными правами Linux, ACL, файловой системой, seccomp или другим механизмом защиты. Поэтому отказ нужно сопоставить с полной записью журнала и конкретным процессом, а не считать его автоматически проблемой AppArmor.

Подробнее в статье →

Можно ли отключить только один профиль AppArmor для диагностики?

Да, временно можно отключить один профиль через aa-disable, не затрагивая защиту остальных сервисов. Но процесс при этом лишается слоя MAC-защиты, поэтому нужно ограничить время диагностики, записать причину и заранее запланировать возврат профиля в complain или enforce. Отключать AppArmor на всём сервере ради одного сбоя не следует.

Подробнее в статье →

Почему chmod и ACL не устраняют AppArmor denied?

Потому что AppArmor не заменяет обычные права Linux, а работает вместе с ними. Процесс должен одновременно пройти проверку владельца, режима файла и ACL, а также получить разрешение в своём профиле AppArmor. Поэтому корректные chmod и ACL не помогут, если профиль не разрешает нужное чтение, запись, выполнение или другую операцию.

Подробнее в статье →

Почему профиль AppArmor не применяется к запущенному сервису?

Частая причина — профиль привязан к пути исполняемого файла, а не к имени systemd-службы. После смены пути, разрешения символьной ссылки, запуска через обёртку или выполнения дочерней программы attachment может не соответствовать фактическому процессу. Проверьте реальный бинарный файл через /proc/<PID>/exe и имя профиля в aa-status.

Подробнее в статье →

Обновления безопасности Windows Server: патчи, reboot и поддержка(6)

Нужно ли менять ежемесячный график для критичных серверов?

Да, для внешне доступных и высококритичных хостов нужен более ранний этап развёртывания и более короткий внутренний срок после тестирования. Если есть сведения об активной эксплуатации применимой уязвимости, требуется внеочередное изменение. При этом нельзя пропускать оценку влияния на сервис, согласование окна, план восстановления и проверку после установки.

Подробнее в статье →

Что делать с Windows Server после окончания поддержки?

Нужно запланировать миграцию или вывод сервера из эксплуатации и формально принять остаточный риск на переходный период. Сегментация и ограничение доступа могут временно снизить риск, но не возвращают снятой с поддержки ОС новые исправления. Для такого хоста фиксируют компенсирующие меры, срок устранения и дату пересмотра риска.

Подробнее в статье →

Кто должен согласовать окно обновлений сервера?

Окно согласуют владельцы, отвечающие за работоспособность и простой сервиса. Технический владелец подтверждает работу роли после изменения, владелец сервиса согласует допустимую недоступность, команда эксплуатации выполняет обновление, а владелец риска принимает решение об отсрочке. До начала работ также определяют подтверждение начала и окончания простоя.

Подробнее в статье →

Нужно ли перезагружать сервер после установки патча?

Зависит от конкретного обновления и принятой процедуры, но установку и фактическое применение патча нельзя считать одним событием. Пакет может установиться успешно, однако требовать restart для замены компонентов. Основным источником статуса служит выбранное средство управления; после плановой установки перезагрузку выполняют, если она указана для пакета или предусмотрена процедурой.

Подробнее в статье →

Можно ли считать ping проверкой успешного обновления?

Нет. Ответ на ping подтверждает лишь базовую сетевую доступность и не доказывает работу сервиса после патча. После установки нужно проверить загрузку ОС и ожидаемую сборку, статус служб, прикладной URL или подключение клиента, безопасную тестовую операцию, очереди, репликацию и другие проверки, определённые для роли сервера.

Подробнее в статье →

Что делать, если патч не удаётся установить в срок?

Нужно оформить временное исключение, а не оставлять сервер без статуса. Зафиксируйте причину, затронутые CVE или KB, компенсирующие меры, владельца риска, дату следующего решения и план устранения. Исключение должно иметь срок пересмотра; при этом оцените, применима ли уязвимость к хосту и доступен ли он извне.

Подробнее в статье →

Hardening TLS: версии протокола, cipher suites и проверка настроек(6)

Можно ли временно оставить TLS 1.0 или 1.1 для старого клиента?

Да, но только как документированное временное исключение. Нужно назначить владельца риска, срок отмены и план обновления клиента либо выделения отдельного совместимого endpoint. Оставлять устаревшие версии для всех клиентов без ограничений не следует: они увеличивают поверхность атак и риск небезопасного понижения протокола.

Подробнее в статье →

Почему настройки cipher suites для TLS 1.2 не применяются к TLS 1.3?

Потому что в TLS 1.3 используется другая модель согласования: наборы имеют ограниченный современный состав, а обмен ключами и аутентификация выбираются отдельно. Поэтому список cipher suites для TLS 1.2 обычно не управляет TLS 1.3. Для TLS 1.3 нужны отдельные параметры, если их поддерживают версия сервера и криптобиблиотека.

Подробнее в статье →

Как понять, что TLS 1.0 отключён на endpoint, а не запрещён моей OpenSSL?

Нужно отличить ответ удалённого сервера от локальной ошибки клиента. Отказ с alert о неподдерживаемой версии подтверждает запрет TLS 1.0 на проверяемом endpoint. Если OpenSSL сообщает об отсутствии допустимых шифров или запрещает TLS 1.0 своей политикой, это не характеризует сервер: используйте совместимый клиент или внешний сканер.

Подробнее в статье →

Почему ошибка `ssl handshake failed` не всегда связана со слабым шифром?

Потому что ошибка handshake описывает сбой согласования в целом, а не конкретно cipher suite. Причиной могут быть SNI, клиентский сертификат, цепочка сертификатов, имя хоста или сетевой посредник. Проверяйте имя и сертификат, фактически согласованную версию TLS и набор шифров, а также журналы TLS-терминатора.

Подробнее в статье →

Повлияет ли отключение TLS в IIS на другие службы Windows Server?

Да, может повлиять. IIS использует HTTP.sys и Schannel, а протоколы Schannel и порядок cipher suites обычно задаются на уровне ОС. Изменения способны затронуть другие службы Windows, использующие Schannel, а также исходящие подключения сервера. До применения проверьте эффективные GPO, зависимости приложений и запланируйте окно обслуживания.

Подробнее в статье →

Зачем передавать SNI при проверке TLS на общем IP-адресе?

SNI сообщает серверу имя сайта, к которому обращается клиент. Без него на общем IP сервер может выбрать сертификат и TLS-политику default virtual host, а не проверяемого hostname. Поэтому успешная проверка без -servername не подтверждает настройки нужного публичного endpoint.

Подробнее в статье →

Аудит Windows Server: Security Log, Advanced Audit Policy и PowerShell(6)

Всегда ли Event ID 4625 означает атаку на Windows Server?

Нет. Event ID 4625 фиксирует неудачный вход, который может быть вызван опечаткой, устаревшим паролем службы, задачей, сохранёнными реквизитами или ошибкой настройки клиента. Для оценки нужно сопоставить учётную запись, IP-адрес или имя рабочей станции, тип входа, Status, SubStatus и частоту событий.

Подробнее в статье →

Означает ли Event ID 4624 интерактивный вход пользователя?

Нет. Event ID 4624 означает успешный вход, но он может относиться к службе, сетевому доступу, пакетному заданию или системной операции. Интерпретируйте событие по Logon Type вместе с Account Name, Source Network Address, Workstation Name, Authentication Package и ролью сервера.

Подробнее в статье →

Может ли доменная GPO отменить локальную политику аудита?

Да. На сервере — члене домена локальные настройки аудита могут быть заменены доменной GPO при обновлении политики. Для постоянной конфигурации задавайте нужные подкатегории в применяемой GPO, проверяйте её область действия, наследование и security filtering, а итоговое состояние контролируйте через auditpol на целевом сервере.

Подробнее в статье →

Что означает Event ID 4740 и как найти источник блокировки?

Event ID 4740 означает блокировку учётной записи, но не доказывает перебор паролей извне. Проверьте поля Account That Was Locked Out и Caller Computer Name, затем найдите связанные события 4625. Причиной часто оказывается служба, задача или клиент, где сохранён старый пароль.

Подробнее в статье →

Почему в Event ID 4688 нет командной строки?

Обычно потому, что включён только аудит создания процессов. Подкатегория Audit Process Creation создаёт 4688, но поле Command Line добавляется отдельным параметром, близким по имени к Include command line in process creation events. Также проверьте, не переопределяет ли настройку более приоритетная GPO.

Подробнее в статье →

Доказывает ли Event ID 1102 компрометацию сервера?

Нет. Event ID 1102 означает, что был очищен именно Security Log, но очистка может быть санкционированным действием администратора при обслуживании. Зафиксируйте субъекта, время и компьютер, проверьте причину операции и изучите сохранённую внешнюю копию журнала для анализа событий до очистки.

Подробнее в статье →

Сервер взломали: изоляция, артефакты и первые действия(6)

Где проверить входы SSH на Linux-сервере?

Проверяйте текущие и прошлые сеансы через who, w и last, а также журналы аутентификации. В зависимости от дистрибутива записи могут быть в journald, /var/log/auth.log или /var/log/secure. Сопоставляйте успешные входы, адреса источников и последующие привилегированные действия; необычный вход сам по себе ещё не доказывает компрометацию.

Подробнее в статье →

Нужно ли сразу удалять майнер с сервера?

Нет, если майнер не создаёт немедленный ущерб. До удаления зафиксируйте процессы, сетевые соединения, сеансы, механизмы автозапуска, журналы и сведения о файлах. Удаление процесса или файла не доказывает, что атакующий потерял доступ: на сервере могут остаться другой способ закрепления, учётная запись или исходный вектор проникновения.

Подробнее в статье →

Как распознать ransomware на сервере?

Признаками ransomware могут быть массовая смена расширений файлов, недоступность данных и появление записок с требованием выкупа. Если шифрование продолжается, приоритетом становится остановка ущерба: по утверждённому плану полностью отключите сетевые связи или ограничьте их через инфраструктурную точку управления. Зафиксируйте время, принятое решение и наблюдаемый эффект.

Подробнее в статье →

Можно ли оставить SSH или RDP при изоляции сервера?

Нет, если это обычный административный доступ, который потенциально доступен и атакующему. Оставлять можно только заранее подготовленный, отдельно контролируемый канал управления или расследования, например через bastion host либо внеполосный доступ. Если такой канал гарантировать нельзя, а ущерб продолжается, сервер следует полностью отключить от сети по плану реагирования.

Подробнее в статье →

Является ли обычная резервная копия доказательством взлома?

Нет. Обычная резервная копия не считается криминалистической копией и не заменяет сохранение артефактов расследования. Для проверки инцидента отдельно фиксируют внешние события, процессы, сетевые соединения, сеансы, конфигурации служб и журналы, указывая время, исполнителя, применённые команды и место хранения результатов.

Подробнее в статье →

Доказывает ли одна тревога EDR, что сервер взломан?

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

Подробнее в статье →

Защита RDP на Windows Server: NLA, MFA и ограничение доступа(6)

Можно ли включить двухфакторную аутентификацию для RDP одной настройкой?

Нет. NLA, Credential Guard и Remote Credential Guard не добавляют второй фактор для прямого RDP-подключения. Для MFA обычно нужна контролируемая точка входа, например RD Gateway, с поддерживаемой интеграцией RADIUS/NPS или совместимым MFA-механизмом. При этом MFA не отменяет ограничения источников в firewall, TLS и настройки прав входа.

Подробнее в статье →

Можно ли защитить RDP от перебора только блокировкой учётных записей?

Нет. Блокировка уменьшает число попыток для одной учётной записи, но не гарантирует защиту от password spraying, распределённых атак и входа с уже украденным паролем. Слишком низкий порог также позволяет намеренно блокировать пользователей. Настраивайте её вместе с ограничением источников, NLA, TLS, MFA и мониторингом блокировок.

Подробнее в статье →

Почему пользователь из Remote Desktop Users получает отказ во входе?

Возможно, у пользователя нет права Allow log on through Remote Desktop Services или он, либо одна из его вложенных групп, попал в Deny log on through Remote Desktop Services. Запрет имеет приоритет над разрешением. Проверьте результирующие локальные и доменные GPO, а также фактические группы пользователя командой whoami /groups.

Подробнее в статье →

Нужно ли ограничивать UDP 3389, если TCP уже разрешён только с нужных IP?

Да, если UDP используется активными RDP-клиентами или конфигурацией. Ограничение только TCP не закрывает UDP-правило с областью Any: оно может оставить RDP доступным по UDP из лишних сетей. Проверьте все применимые входящие правила RDP, их профиль, протокол, порт и RemoteAddress, включая IPv6.

Подробнее в статье →

Почему RDP показывает предупреждение о сертификате после включения TLS?

Предупреждение означает, что клиент не смог проверить срок действия сертификата, цепочку доверия или соответствие имени сервера. Не игнорируйте его: есть риск подключиться не к тому узлу. Назначьте RDP-службе доверенный сертификат и подключайтесь по полному DNS-имени, указанному в сертификате.

Подробнее в статье →

Что делать, если после обновления политик настройки RDP возвращаются?

Проверьте, не переопределяет ли локальные параметры доменная GPO. Сформируйте отчёт gpresult /h C:\Temp\rdp-gpo-before.html, найдите применённые политики Remote Desktop Services, прав входа и firewall, затем изменяйте эффективный источник настройки. Не исправляйте это в единственной RDP-сессии: сохраните доступ через консоль или другой независимый канал.

Подробнее в статье →

Настройка nftables: правила, sets, IPv6 и диагностика(6)

Как ограничить доступ к SSH по IP в nftables?

Используйте отдельные sets с доверенными адресами: IPv4-set для правила ip saddr, IPv6-set для ip6 saddr. В примере admin4 и admin6 работают как allowlist для новых SSH-подключений, поэтому не нужно создавать отдельное правило порта для каждого адреса. Флаг interval позволяет добавлять в set подсети и диапазоны.

Подробнее в статье →

Нужно ли отдельно открывать порт для IPv6 в nftables?

Да, IPv4 и IPv6 нужно проверять отдельно. Таблица inet объединяет правила для обоих стеков, но адресные выражения различаются: ip saddr применяется к IPv4, а ip6 saddr — к IPv6. Открытый IPv4-порт сам по себе не создаёт IPv6-политику; сервис также может слушать только один стек.

Подробнее в статье →

Что показывает nft list ruleset и означает ли пустой вывод, что firewall выключен?

nft list ruleset показывает правила, известные ядру через nftables, включая объекты, созданные firewalld или слоем совместимости iptables-nft. Пустой вывод не доказывает, что firewall и сетевые ограничения отсутствуют: правила может обслуживать другой менеджер, а фильтрация может находиться вне сервера.

Подробнее в статье →

Сохранятся ли добавленные в set IP-адреса после перезагрузки?

Нет, если адрес добавлен только командой nft add element. Такая команда меняет активный ruleset, но не редактирует исходный файл конфигурации; при повторном применении файла или после перезагрузки изменение исчезнет. Постоянные адреса нужно добавить в elements файла и затем проверить и применить его.

Подробнее в статье →

Можно ли выполнять nft flush ruleset на удалённом сервере?

Без аварийного доступа — не стоит. nft flush ruleset удаляет весь активный ruleset и может снять разрешение SSH, правила контейнеров или конфигурацию другого менеджера firewall. Перед изменением сохраните текущие правила, оставьте активную SSH-сессию, откройте вторую для проверки и обеспечьте доступ через консоль провайдера, BMC или физическую консоль.

Подробнее в статье →

Гарантирует ли nft -c, что после применения останется доступ по SSH?

Нет. nft -c -f проверяет синтаксис файла, поддерживаемые выражения и ссылки на объекты, но не моделирует маршрутизацию, адреса источников, порядок правил другого менеджера и доступность SSH. Синтаксически корректная политика всё равно может заблокировать сервер, поэтому после загрузки её проверяют из второй SSH-сессии.

Подробнее в статье →

UFW и firewalld: настройка firewall в Ubuntu и RHEL(6)

Нужно ли разрешать SSH перед `ufw enable`?

Да. До включения UFW разрешите фактический SSH-порт: ufw allow ssh подходит только для стандартного порта 22, а для нестандартного нужен явный порт TCP. Не закрывайте текущую SSH-сессию, откройте вторую для проверки и заранее подготовьте независимую консоль или BMC на случай блокировки доступа.

Подробнее в статье →

Как определить, какая зона firewalld применяется к SSH?

Сначала проверьте активные зоны через firewall-cmd --get-active-zones. Если административный IP или подсеть привязаны к зоне как source, она имеет приоритет над зоной интерфейса. Иначе определите зону интерфейса командой --get-zone-of-interface=<интерфейс> и учитывайте зону по умолчанию. Перед изменениями проверьте её через --list-all.

Подробнее в статье →

Можно ли одновременно использовать UFW и iptables?

Нет, не следует строить независимые политики одновременно через UFW, firewalld, ручные iptables или nftables. Эти средства работают с тем же стеком Netfilter, поэтому один менеджер может изменить либо перезаписать правила другого. Сначала определите, кто владеет текущей конфигурацией, включая автоматизацию и контейнерные платформы, и только затем планируйте миграцию.

Подробнее в статье →

Как ограничить доступ к порту одним IP в UFW?

Добавьте правило с источником, например sudo ufw allow from <доверенный_IP> to any port <порт> proto tcp. Оно разрешает доступ к указанному TCP-порту только этому IPv4- или IPv6-адресу соответствующего формата. Проверьте список через ufw status numbered и убедитесь, что для того же порта нет более широкого разрешения для всех источников.

Подробнее в статье →

Почему правило firewalld пропадает после перезагрузки?

Потому что обычные команды firewall-cmd --add-service и --add-port меняют только runtime-конфигурацию. Для сохранения правила добавьте его также с --permanent, затем примените и runtime-вариант без reload. После этого отдельно сравните runtime и permanent через --list-services или --list-ports с флагом --permanent.

Подробнее в статье →

Нужно ли отдельно проверять правила UFW для IPv6?

Да. IPv4-правило не защищает IPv6-адрес сервера: клиент может подключиться по IPv6 в обход IPv4-маршрута. Проверьте параметр IPV6 в /etc/default/ufw, затем фактические правила через ufw status numbered. После изменения параметра проверьте подключение по IPv6 с разрешённого источника и подтвердите доступ к фактическому SSH-порту.

Подробнее в статье →

Fail2ban: защита SSH, Nginx и Apache от перебора паролей(6)

Почему Fail2ban не блокирует IP?

Зависит от того, на каком этапе прерывается обработка события. Jail может быть не включён, указан неверный журнал, фильтр не распознаёт строку или не извлекает IP, число попыток не достигло maxretry, а адрес может входить в ignoreip. Также проверьте, что Fail2ban запущен и нужный jail отображается в статусе.

Подробнее в статье →

Что показывает команда fail2ban-client status sshd?

Команда показывает состояние jail sshd: его счётчики и обычно список заблокированных адресов. Она помогает убедиться, что jail загрузился после перезапуска и обрабатывается Fail2ban. Однако наличие IP в статусе означает только выполнение action со стороны Fail2ban, а не гарантированную блокировку трафика firewall.

Подробнее в статье →

Нужно ли добавлять VPN-подсеть в Fail2ban ignoreip?

Обычно нет. ignoreip исключает адреса и сети из обработки Fail2ban, поэтому скомпрометированное устройство из добавленной VPN-подсети не будет заблокировано. Добавляйте только минимально необходимый документированный адрес, например стабильный адрес аварийного доступа, и задавайте исключение в конкретном jail, если оно нужно лишь ему.

Подробнее в статье →

Как снять бан с IP в Fail2ban?

Используйте команду sudo fail2ban-client set sshd unbanip 203.0.113.17, заменив имя jail и документационный IP на фактические. Затем проверьте результат через sudo fail2ban-client get sshd banip. Не используйте unban как постоянное решение: выясните причину бана, например неверный пароль, общий NAT, ошибочный фильтр или прокси.

Подробнее в статье →

Как посмотреть список заблокированных IP в Fail2ban?

Выполните sudo fail2ban-client get sshd banip, указав фактическое имя jail вместо sshd. Также список обычно выводится в sudo fail2ban-client status sshd. Этот список показывает адреса, которые Fail2ban считает заблокированными, но для подтверждения эффекта нужно отдельно проверить правила активного firewall и тестовое подключение.

Подробнее в статье →

Можно ли читать события Fail2ban из systemd journal?

Да, если установленная версия Fail2ban поддерживает systemd backend. Для этого используют backend = systemd; logpath в таком режиме не является источником событий. Условия отбора обычно задают через journalmatch в фильтре, используя unit и поля из реальных записей конкретной службы.

Подробнее в статье →

Аудит безопасности Linux: auditd, входы и контроль действий(6)

Где искать записи о входах SSH, если нет auth.log?

Проверьте journalctl и альтернативный файловый журнал. В Debian и Ubuntu сообщения часто находятся в /var/log/auth.log, а в RHEL-совместимых системах — в /var/log/secure. Если файлового журнала нет, события могут храниться только в systemd-journald: используйте journalctl -u sshd.service -u ssh.service --since today и ищите Accepted, Failed, Invalid user, сообщения PAM и адрес источника.

Подробнее в статье →

Как проверить активные сессии Linux?

Используйте who или w: они показывают текущие интерактивные сессии пользователей. Эти команды подходят для оперативной проверки того, кто подключён сейчас, но не заменяют историю входов. Для завершённых успешных сессий используйте last, а для анализа аутентификации и SSH дополнительно проверяйте журналы PAM, SSH, journald и события Linux Audit.

Подробнее в статье →

Как посмотреть неудачные входы Linux?

Начните с sudo lastb, если система ведёт файл btmp: команда показывает учтённые неудачные входы. Для контекста проверьте сообщения SSH и PAM в /var/log/auth.log, /var/log/secure или journald. Если события аутентификации передаются в Linux Audit, используйте sudo aureport --auth --failed -i; наличие результатов зависит от настройки PAM и политики аудита.

Подробнее в статье →

Чем last отличается от lastlog в Linux?

last показывает список учтённых успешных входов из wtmp, то есть историю сессий в пределах сохранённых данных. lastlog выводит только последний зарегистрированный вход каждого пользователя и не является историей подключений. Данные обеих команд зависят от сохранности и ротации файлов; на современных системах механизм хранения может отличаться или иметь ограниченную актуальность.

Подробнее в статье →

Что будет, если журнал auditd заполнит диск?

Зависит от параметров auditd.conf и политики сервера. При нехватке места auditd может журналировать событие, отправлять уведомление, запускать программу, приостанавливать аудит, переводить систему в однопользовательский режим или останавливать её — если такие действия поддерживает версия. Остановка и однопользовательский режим могут вызвать простой, а игнорирование проблемы приведёт к потере наблюдаемости.

Подробнее в статье →

Как долго хранятся логи auditd?

Фиксированного срока нет: он зависит от потока событий, доступного места, требований организации и настроек ротации. Параметры max_log_file и num_logs ограничивают размер и число файлов, а при max_log_file_action = ROTATE старые журналы удаляются после достижения лимита. Режим KEEP_LOGS сохраняет файлы, но может заполнить локальное хранилище.

Подробнее в статье →

Обновления безопасности Linux: APT, DNF, автоматизация и reboot(6)

Можно ли включить Unattended Upgrades без автоматической перезагрузки?

Да. Для Ubuntu и Debian оставьте параметр Unattended-Upgrade::Automatic-Reboot равным false, если автоматический reboot не согласован. Unattended Upgrades сможет загружать и устанавливать разрешённые обновления, но решение о перезапуске служб и перезагрузке сервера останется за администратором. Также нужно проверить разрешённые origins, таймеры, журналы и доставку уведомлений.

Подробнее в статье →

Что делать, если выпуск Linux достиг end of life?

Нельзя считать доступные в старом репозитории пакеты подтверждением актуальной защиты. Сверьте точные ID и VERSION_ID с официальной страницей жизненного цикла поставщика. После окончания стандартной поддержки исправления могут поступать только по условиям extended maintenance или отдельной подписки для конкретного выпуска. Если такой поддержки нет, нужен поддерживаемый путь обновления системы.

Подробнее в статье →

Можно ли выполнять yum update --security на любом сервере?

Нет. Режим yum update --security доступен только при поддерживаемой версии legacy-YUM и наличии security/updateinfo-функций у поставщика. На старых системах также может требоваться соответствующий плагин. Сначала проверьте yum updateinfo list security и симуляцию с --assumeno; не переносите синтаксис DNF на YUM без проверки документации своего выпуска.

Подробнее в статье →

Почему dnf update --security не показывает исправления?

Обычно причина в репозиториях: security-отбор работает, только когда подключённые источники публикуют updateinfo-метаданные и DNF может их использовать. Проверьте включённые репозитории через dnf repolist --enabled, затем выполните dnf updateinfo list --security. Исправленная версия из стороннего репозитория может не иметь security-маркировки и потребовать обычного согласованного обновления пакета.

Подробнее в статье →

Как понять, что обновление из APT действительно закрывает уязвимость?

По одному выводу apt list --upgradable это определить нельзя: там есть обычные исправления ошибок, зависимости и функциональные изменения. Сопоставьте пакет с утверждённым security-источником и advisory, затем проверьте план через apt-get -s upgrade. После установки подтвердите версию командой apt-cache policy имя-пакета и журналом /var/log/apt/history.log.

Подробнее в статье →

Нужна ли перезагрузка после обновлений безопасности Linux?

Зависит от состава обновлений. Новое ядро обычно начинает работать только после загрузки нового ядра, поэтому reboot нужно запланировать в окно обслуживания. В Ubuntu и Debian проверьте /var/run/reboot-required; в RHEL-совместимых системах — needs-restarting -r, если утилита доступна. Для заменённых библиотек может быть достаточно контролируемого restart затронутых служб.

Подробнее в статье →

Windows Defender Firewall: правила, PowerShell и журналирование(6)

Почему правило Windows Firewall не работает?

Зависит от фактического профиля, источника политики и условий правила. Проверьте категорию подключения через Get-NetConnectionProfile, а правило — в ActiveStore, а не только в локальном хранилище. Правило может не применяться из-за GPO, запрета объединения локальных правил, неверных адресов, порта, направления, программы или профиля.

Подробнее в статье →

Где посмотреть, почему Windows Firewall заблокировал подключение?

Проверьте журнал отброшенных пакетов для активного профиля. Включите LogDroppedPackets, задайте путь и размер файла через Set-NetFirewallProfile, затем воспроизведите подключение в зафиксированное время. Журнал поможет подтвердить факт отбрасывания пакета, но также нужно проверить совпадающие block-правила, профиль и источник политики.

Подробнее в статье →

Можно ли отключить Windows Defender Firewall для диагностики?

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

Подробнее в статье →

Разрешит ли входящее правило серверу обратиться к внешнему API?

Нет. Входящее правило управляет тем, кто может начать соединение с сервисом на сервере, и не разрешает исходящие подключения самого сервера. Для внешнего API нужно оценить исходящую политику активного профиля, применённые GPO и при необходимости создать отдельное исходящее правило с удалённым адресом и портом.

Подробнее в статье →

Что сработает при конфликте правил Allow и Block?

Явное правило Block имеет приоритет над совпадающим правилом Allow. Не пытайтесь изменить результат перестановкой правил: Microsoft Defender Firewall не обрабатывает их как пользовательский последовательный список. Ищите блокировку по направлению, протоколу, адресам, портам, программе и профилю, затем проверяйте её источник в активной политике.

Подробнее в статье →

Защитит ли IPv4-правило сервис, доступный по IPv6?

Нет, IPv4-правило не следует считать автоматической защитой IPv6-пути. Если интерфейс и приложение используют IPv6, добавьте в -RemoteAddress необходимые IPv6-адреса или префиксы и отдельно проверьте подключение по обоим семействам адресов. Иначе сервис может остаться доступным по IPv6 при ограничении только IPv4.

Подробнее в статье →

Настройка iptables: открыть порт, ограничить доступ и сохранить правила(6)

Почему правила iptables пропадают после перезагрузки?

Потому что правила, добавленные командой iptables, обычно существуют только в памяти. Для их восстановления после перезагрузки нужно настроить постоянное хранение штатным способом для своего дистрибутива и используемого firewall-стека. Не смешивайте прямые команды iptables с UFW, firewalld или нативным nftables без проверки: менеджер может перезаписать правила.

Подробнее в статье →

Можно ли удалить правило iptables по старому номеру?

Нет, номер нужно получать непосредственно перед удалением. После каждой вставки или удаления номера последующих правил сдвигаются, поэтому старый номер может указывать уже на другое правило. Сначала проверьте iptables -L INPUT -n -v --line-numbers и iptables -S INPUT, сопоставьте правило по протоколу, источнику, порту, состоянию и цели.

Подробнее в статье →

Нужно ли разрешать ESTABLISHED,RELATED для SSH?

Да, при удалённой настройке это правило обычно ставят в начало INPUT. Оно пропускает ответный трафик уже установленных и связанных соединений, включая текущую SSH-сессию. Однако оно не заменяет отдельное разрешение для новых SSH-подключений: для них нужно правило с --ctstate NEW, при необходимости ограниченное доверенным IP-адресом.

Подробнее в статье →

Нужно ли отдельно открывать порт в ip6tables?

Да, если сервис доступен по IPv6 и этот трафик требуется разрешить. Правила iptables фильтруют только IPv4 и не применяются к IPv6. Для IPv6 используется отдельный набор ip6tables, который также нужно проверять, сохранять и при необходимости восстанавливать отдельно от IPv4-правил.

Подробнее в статье →

Чем DROP отличается от REJECT в iptables?

DROP молча отбрасывает пакет, а REJECT отправляет ответ об отказе, подходящий для протокола. Оба действия завершают обработку текущей цепочки и не дают пакету перейти к более поздним правилам. Выбирать между ними следует по роли сервиса и принятой политике доступа, а не как универсальную меру безопасности.

Подробнее в статье →

Почему iptables-save выдаёт Permission denied?

Обычно перенаправление вывода выполняет обычная оболочка пользователя, даже если сама команда запущена через sudo. Создавайте резервный файл от root, например через sudo sh -c 'iptables-save > /root/firewall-backup/iptables.v4.before'. Каталог для снимков должен быть доступен root; аналогично отдельно сохраняйте IPv6 через ip6tables-save.

Подробнее в статье →

Let’s Encrypt на Linux: выпуск, установка и автопродление(6)

Почему certbot renew не выпускает новый сертификат при каждом запуске?

Это нормально: certbot renew не выпускает замену при каждом запуске. Он проверяет сертификаты, которыми управляет текущая установка Certbot, и пытается продлить только те, для которых наступило окно продления. Если продление должно выполняться автоматически, должны сохраняться условия исходной проверки: доступность DNS, порта 80, webroot или DNS API и необходимые права на файлы.

Подробнее в статье →

Как проверить срок действия сертификата Let’s Encrypt?

Используйте sudo certbot certificates. Команда показывает сертификаты, которыми управляет текущая установка Certbot, включая имена доменов, срок действия, путь к сертификату и путь к закрытому ключу. По этому выводу также можно определить точное имя сертификата и актуальные файлы из каталога Certbot, которые должны быть подключены в веб-сервере.

Подробнее в статье →

Можно ли выпустить wildcard-сертификат через HTTP-01?

Нет, для wildcard-имён, например *.example.com, Let’s Encrypt требует DNS-01. HTTP-01 подтверждает доступность ресурса по HTTP на порту 80, но не подходит для wildcard. Для DNS-01 нужно создать TXT-запись _acme-challenge.<домен> вручную либо через DNS-плагин Certbot и API DNS-провайдера.

Подробнее в статье →

Нужно ли создавать CSR через OpenSSL для Certbot?

Нет, при стандартном выпуске через Certbot вручную создавать CSR и закрытый ключ через OpenSSL обычно не нужно. Certbot сам создаёт ключевую пару, формирует CSR и проходит ACME-проверку. Отдельное создание произвольного CSR через OpenSSL требуется для другой задачи, а не для обычного получения сертификата Let’s Encrypt через Certbot.

Подробнее в статье →

Почему Let’s Encrypt не проходит ACME challenge?

Обычно причина в том, что центр сертификации не видит ожидаемый challenge-ресурс. Для HTTP-01 домен должен вести на правильную публичную точку публикации по A и AAAA, порт 80 должен быть доступен, а путь /.well-known/acme-challenge/ не должен подменяться приложением, авторизацией или другим редиректом. Для DNS-01 должна распространиться корректная TXT-запись.

Подробнее в статье →

Что будет, если у домена неверная AAAA-запись?

HTTP-01 может не пройти, даже если A-запись ведёт на работающий сервер. Let’s Encrypt проверяет все опубликованные A- и AAAA-записи имени, поэтому неверная IPv6-запись может направить проверку на точку, которая не отдаёт challenge-файл. Исправьте или удалите ошибочную AAAA-запись и дождитесь распространения DNS перед выпуском сертификата.

Подробнее в статье →

Учётные записи, sudo и парольная политика в Linux(6)

Можно ли настроить sudo без пароля?

Зависит от операции: NOPASSWD допустим для узкой неинтерактивной автоматизации или одной безопасно спроектированной команды, если риск и владелец правила документированы. Для интерактивного администрирования это не должно быть стандартом. Нельзя использовать NOPASSWD: ALL: компрометация обычной сессии сразу даст привилегированный доступ.

Подробнее в статье →

Почему sudo возвращает permission denied, хотя пользователь добавлен в группу?

Обычно причина в старой пользовательской сессии, неподключённом или неверно оформленном файле sudoers.d, либо в несовпадении команды, аргументов, целевого пользователя или хоста с правилом. Проверьте id <user>, getent group <group> и откройте новую сессию. Затем выполните sudo -l именно от имени проверяемого пользователя.

Подробнее в статье →

Что делать при ошибке sudoers syntax error?

Не закрывайте работающую привилегированную сессию. Откройте правило через visudo, исправьте строку и проверьте файл командой visudo -c. Если основной файл уже повреждён и sudo не работает, используйте сохранённую привилегированную сессию или независимый консольный аварийный доступ.

Подробнее в статье →

Можно ли дать sudo на `systemctl *` для оператора?

Нет, такое правило обычно слишком широкое. Запись вида /usr/bin/systemctl * может позволить запускать или изменять другие службы, а не только согласованный сервис. Разрешайте конкретную команду с абсолютным путём, точным именем службы и нужными аргументами либо используйте отдельный root-owned скрипт с фиксированной логикой.

Подробнее в статье →

Действует ли локальная PAM-политика на пользователей LDAP или Active Directory?

Не всегда. Политика локальных паролей PAM прежде всего относится к локальной парольной аутентификации. Для LDAP, Active Directory, SSSD и Kerberos правила паролей, членство в группах и сроки действия могут задаваться каталогом или стеком интеграции. Проверьте источник учётной записи через getent passwd <user>.

Подробнее в статье →

Как не потерять доступ при изменении sudo или PAM?

Оставьте открытой текущую привилегированную сессию и заранее проверьте независимый путь восстановления: консоль гипервизора, BMC, физическую консоль или аварийную учётную запись. Изменения тестируйте во второй сессии проверяемого пользователя. Открытое SSH-подключение не считается аварийным каналом, так как PAM или учётная запись могут его затронуть.

Подробнее в статье →

SELinux на сервере: Enforcing, контексты и устранение отказов(6)

Можно ли отключить SELinux, чтобы убрать Permission denied?

Нет. Режим Disabled не следует использовать как обычное исправление доступа: он отключает проверки политики, скрывает причину отказа и снимает слой защиты. Сначала сопоставьте ошибку с AVC, затем примените узкое исправление — восстановите контекст, задайте правило для пути, включите подходящий Boolean или назначьте тип нестандартному порту.

Подробнее в статье →

Можно ли оставить SELinux в Permissive после диагностики?

Нет, не как постоянное решение для работающего сервера. Permissive не блокирует действия, запрещённые политикой, хотя AVC могут продолжать записываться. Используйте его кратко для проверки гипотезы, зафиксируйте время теста и AVC, затем верните setenforce 1 и устраните конкретный отказ.

Подробнее в статье →

Почему веб-служба не запускается на нестандартном порту при открытом firewall?

Возможно, номер порта не связан с SELinux-типом, который разрешён домену службы. Открытый firewall не заменяет проверку SELinux. Сначала убедитесь, что порт предназначен для сервиса и не занят, проверьте AVC и существующие сопоставления через semanage port -l; не добавляйте номер повторно и не меняйте его тип без проверки другого сервиса.

Подробнее в статье →

Нужно ли включать httpd_can_network_connect для исходящих запросов веб-службы?

Зависит от AVC и назначения приложения. httpd_can_network_connect — пример Boolean, который может разрешить исходящие подключения домену веб-службы, но его нельзя включать автоматически. Сначала подтвердите AVC с операцией вроде name_connect, домен процесса и реальную потребность, например обращение приложения к API или локальному backend.

Подробнее в статье →

Можно ли сразу установить модуль, созданный audit2allow?

Нет. audit2allow строит разрешения по наблюдавшимся отказам, но не определяет, было ли действие корректным. Такой модуль может замаскировать неверную метку или конфигурацию и дать слишком широкие права. Сначала исключите проблемы контекста, Boolean, метки порта, Unix-прав и конфигурации, затем проверьте правила модуля в изолированной среде.

Подробнее в статье →

Почему setenforce 1 не включает SELinux?

Если SELinux имеет статус Disabled, setenforce 1 не сможет включить защиту: политика не загружена. Команда переключает только активный SELinux между Enforcing и Permissive. Для Disabled требуется отдельная постоянная процедура включения, relabel файловой системы и перезагрузка по документации конкретного дистрибутива и версии.

Подробнее в статье →

Управление уязвимостями сервера: CVE, сканирование и приоритизация(6)

Что такое CVE и чем она отличается от CWE?

CVE — это идентификатор конкретной записи об уязвимости, который помогает сопоставить отчёт сканера, бюллетень производителя и задачу на исправление. CWE описывает не отдельную уязвимость, а класс слабости, например ошибку контроля доступа. CWE не является рейтингом серьёзности и не заменяет CVE.

Подробнее в статье →

Что такое CVSS и можно ли по нему определить срочность исправления?

CVSS — стандарт FIRST для оценки технических характеристик уязвимости. Использовать только его для определения срочности нельзя: балл не учитывает внешнюю доступность сервиса, критичность сервера, наличие эксплуатации и действующие защитные меры. Также CVSS v3.1 и v4.0 используют разные метрики, поэтому их баллы нельзя считать полностью эквивалентными.

Подробнее в статье →

Что такое exploit и означает ли его наличие атаку на сервер?

Exploit — это код или последовательность действий для использования конкретной уязвимости. Нет, наличие публичного proof of concept или сообщения об exploit не доказывает, что сервер уже атакован. Однако доступный практический exploit или достоверные сведения об эксплуатации повышают приоритет проверки и устранения применимой CVE.

Подробнее в статье →

Что такое уязвимость нулевого дня?

Уязвимость нулевого дня — это ранее неизвестная разработчику или защитникам уязвимость, раскрытая либо используемая до подготовки исправления и защитных мер. Отсутствие патча у давно известной CVE само по себе не делает её zero-day. В такой ситуации особенно важны временные ограничения доступа и наблюдение.

Подробнее в статье →

Почему сканер показывает уязвимость после установки обновления?

Это возможно из-за ложноположительного срабатывания. Например, сканер мог определить версию по баннеру, хотя дистрибутив уже перенёс исправление в пакет через backport, либо баннер относится к proxy, а не к проверяемому компоненту. Подтвердите выпуск ОС, релиз пакета и статус исправления по бюллетеню производителя.

Подробнее в статье →

Что делать, если уязвимость не исправляется?

Если патча нет, он несовместим с приложением или его нельзя установить сразу, примените компенсирующие меры для конкретного пути атаки. Это могут быть ограничение источников доступа, отключение функции, сегментация, усиленная аутентификация, дополнительное обнаружение или виртуальный патч. Назначьте владельца, срок повторной оценки и условие установки основного исправления.

Подробнее в статье →

Hardening Windows Server 2019, 2022 и 2025: базовая защита(6)

Как не потерять удалённый доступ при настройке Windows Firewall?

Сначала сохраните текущую конфигурацию правил и проверьте рабочий административный канал. Входящий доступ ограничивайте по роли сервера, доверенным источникам и необходимым протоколам, а изменения применяйте в контролируемом порядке. До смены правил должны быть проверены RDP, PowerShell Remoting, консольный доступ или BMC, а также путь отката.

Подробнее в статье →

Почему локальная политика не работает на сервере в домене?

Обычно её переопределяет доменная GPO. Локальная политика имеет меньший приоритет, а итоговое значение зависит также от привязки GPO, порядка обработки, наследования, принудительного применения, фильтрации и OU. На сервере — члене домена локальные настройки подходят для диагностики или временной проверки, но корпоративные требования следует закреплять доменной политикой и проверять эффективный результат.

Подробнее в статье →

Что проверить перед отключением SMBv1 на Windows Server?

Сначала проверьте фактическое состояние SMBv1 и инвентаризируйте клиентов файловых ресурсов. Устаревшие NAS, МФУ, промышленные устройства, старые версии Windows и приложения могут поддерживать только SMBv1. Также проверьте резервное копирование, подготовьте обновление или изоляцию несовместимых устройств, выполните перезагрузку после отключения и повторно подтвердите состояние компонента.

Подробнее в статье →

Можно ли сразу отключить NTLM на рабочих серверах?

Нет, сначала переведите ограничение в аудит или протестируйте его в отдельном контуре. Запрет NTLM способен отключить старых клиентов и приложения, поэтому до изменений нужны журналы протоколов, пилотная группа, проверка сервисов и заранее подготовленный откат. Расширять применение можно только после выявления затронутых учётных записей, клиентов и приложений.

Подробнее в статье →

Что будет, если включить обязательную подпись SMB?

Подключения клиентов или серверов без поддержки SMB signing перестанут устанавливаться. Требование подписи проверяется отдельно для серверной и клиентской стороны SMB: сервер контролирует входящие подключения к своим ресурсам, а клиент — подключения этого хоста к удалённым ресурсам. Поэтому настройку нужно проверять с учётом обеих ролей и совместимости всех участников.

Подробнее в статье →

Почему после отвязки тестовой GPO настройки не вернулись?

Потому что прекращение применения GPO не гарантирует возврат всех параметров к прежним значениям: часть настроек безопасности может сохраниться после выхода политики из области действия. Для отката заранее подготовьте обратную GPO, предыдущую версию с нужными значениями или иной проверенный способ восстановления. Перед использованием отката подтвердите фактические значения параметров на сервере.

Подробнее в статье →

Hardening Linux-сервера: чек-лист для Ubuntu, Debian и RHEL(6)

Можно ли применять CIS Benchmark Ubuntu без проверки роли сервера?

Нет, не следует переносить CIS-профиль или готовый baseline без проверки. Сначала нужно зафиксировать роль хоста, опубликованные сервисы, зависимости и допустимые изменения. Универсальные запреты могут отключить нужную службу, нарушить доступ приложения к данным, мониторинг, резервное копирование или удалённое управление.

Подробнее в статье →

Можно ли использовать EOL-версию CentOS для нового сервера?

Нет, неподдерживаемую ветку CentOS не стоит использовать для нового сервера без отдельно принятого и документированного риска. Перед настройкой baseline нужно проверить, получает ли конкретный выпуск security updates. Статус поддержки зависит от версии ОС, а для части продуктов Red Hat — также от подписки.

Подробнее в статье →

Можно ли одновременно управлять firewall через UFW, firewalld и nftables?

Нет, для одной политики нужно выбрать один поддерживаемый способ управления. UFW, firewalld, ручные команды nftables, iptables и скрипты приложений используют Netfilter, но могут перезаписывать правила или формировать неочевидный итоговый ruleset. После изменения проверяйте фактически действующие правила и доступность сервисов.

Подробнее в статье →

Что делать, если SELinux или AppArmor заблокировал приложение?

Не отключайте MAC-контроль глобально. Сначала определите по журналам, какой процесс и какая операция были заблокированы, затем исправьте конфигурацию, метку, Boolean или профиль штатной процедурой дистрибутива. После исправления проверьте режим MAC, отсутствие отказов в журналах и реальный сценарий работы приложения.

Подробнее в статье →

Почему нельзя менять SSH и firewall в единственной сессии?

Потому что ошибка в правилах SSH или firewall может сразу оборвать удалённое управление сервером. Перед изменениями оставьте текущую SSH-сессию открытой, подготовьте независимую консоль или другой аварийный канал и проверьте вход в новой сессии с разрешённого источника. Рабочую сессию закрывайте только после успешной проверки.

Подробнее в статье →

Нужно ли отдельно проверять firewall для IPv4 и IPv6?

Да. Разрешённые административные и прикладные потоки нужно оценивать отдельно для IPv4 и IPv6. Правило, которое сохраняет доступ по одному протоколу, не гарантирует его по другому. После изменения проверьте новое SSH-подключение, опубликованный сервис и фактический набор правил.

Подробнее в статье →

Безопасная настройка SSH: ключи, root и ограничение доступа(6)

Почему SSH пишет Permission denied (publickey) после добавления ключа?

Зависит от настройки: не отключайте пароли, пока не найдёте причину. Проверьте путь к закрытому ключу, имя пользователя, содержимое authorized_keys, владельца и права домашнего каталога, ~/.ssh и authorized_keys. Также посмотрите журналы аутентификации. Для проверки подключайтесь в новой сессии с явно указанным ключом и IdentitiesOnly=yes.

Подробнее в статье →

Отключает ли PasswordAuthentication no вход через keyboard-interactive?

Нет, не обязательно. PasswordAuthentication no запрещает парольный метод SSH, но keyboard-interactive является отдельным методом и может использовать PAM для пароля или MFA. Если password-вход должен быть полностью исключён, отдельно проверьте значение KbdInteractiveAuthentication и эффективную конфигурацию через sshd -T.

Подробнее в статье →

Чем PermitRootLogin no отличается от prohibit-password?

PermitRootLogin no полностью запрещает аутентификацию учётной записью root всеми методами. PermitRootLogin prohibit-password запрещает root-вход по паролю и keyboard-interactive, но может оставить вход root по ключу или другому разрешённому непарольному методу. Для полного запрета прямого root-входа используйте no.

Подробнее в статье →

Защищает ли смена порта SSH от взлома?

Нет, смена порта не заменяет защиту SSH. Она может сократить шум массового сканирования и число записей в журнале, но не защищает от целевой атаки. Нужны ключевая аутентификация, ограничение доступа, обновления и сетевая политика. При смене порта заранее обновите настройки клиентов и firewall, сохранив аварийный способ доступа.

Подробнее в статье →

Защищает ли MaxAuthTries от перебора паролей?

Только частично. MaxAuthTries ограничивает число неудачных попыток в одном SSH-соединении, но не поток новых подключений с новыми попытками. Для реакции на повторяющиеся ошибки входа можно применять Fail2ban с осторожно подобранными порогами. Параметр также не следует уменьшать без проверки: SSH-агент с множеством ключей способен исчерпать лимит.

Подробнее в статье →

Могут ли AllowUsers заблокировать резервное копирование или SFTP?

Да. После добавления AllowUsers вход смогут выполнять только явно разрешённые учётные записи при соблюдении остальных правил. Служебный пользователь резервного копирования, автоматизации или SFTP может потерять доступ, если его не включить в allowlist. До применения проверьте все такие сценарии в новой сессии и не закрывайте текущую рабочую сессию.

Подробнее в статье →

SELinux или AppArmor: какую систему MAC выбрать(4)

Как проверить AppArmor на Ubuntu Server?

Проверьте AppArmor командой aa-status с правами администратора. В штатной конфигурации команда показывает загруженные профили и число профилей в режимах enforce и complain. Если команды нет или профили не загружены, проверьте установленные пакеты, состояние службы и параметры загрузки ОС по документации для конкретного выпуска Ubuntu.

Подробнее в статье →

Можно ли включить SELinux и AppArmor одновременно?

Нет, не следует включать оба механизма самостоятельно. Возможность совместной работы LSM зависит от ядра, сборки и дистрибутива, включая порядок и совместимость модулей. Использовать SELinux и AppArmor параллельно можно только при документированной поддержке конкретного выпуска ОС и полного набора политик.

Подробнее в статье →

Что делать, если сервис работает без MAC, но получает отказ с ним?

Не отключайте MAC сразу. Найдите событие отказа: AVC для SELinux или DENIED для AppArmor, затем сопоставьте процесс, операцию и объект. Исправлением обычно становится корректная метка SELinux, разрешённый путь, штатная настройка приложения или узкое правило политики либо профиля.

Подробнее в статье →

Можно ли оставить SELinux в Permissive или AppArmor в complain?

Нет, постоянным решением это не считается. Permissive и complain подходят только для ограниченной диагностики при внедрении, проверке нового сервиса или локализации отказа. Соберите события, исправьте метки, конфигурацию или правила и повторно проверьте сервис в Enforcing или enforce.

Подробнее в статье →

Ошибки SSL/TLS-сертификатов: expired, chain incomplete и mismatch(6)

Как проверить сертификат через openssl s_client?

Используйте openssl s_client с именем в -servername, нужным портом и -showcerts. Для проверки имени добавьте -verify_hostname, а для остановки при ошибке — -verify_return_error. Смотрите список в Certificate chain и Verify return code: они показывают сертификаты, которые endpoint фактически отдал, и результат проверки OpenSSL.

Подробнее в статье →

Нужно ли отправлять корневой сертификат в серверной цепочке?

Обычно нет. Корневой сертификат должен находиться в trust store клиента, а сервер обычно передаёт сертификат сервиса и необходимые промежуточные CA. Передача корня сама по себе не делает его доверенным. Лишние или не связанные с путём сертификаты могут мешать отдельным клиентам, поэтому состав цепочки нужно проверять на реальном endpoint.

Подробнее в статье →

Почему клиент не доверяет CA после обновления корневых сертификатов Linux?

Потому что обновление системного trust store может не затрагивать хранилище конкретного клиента. Java, браузер, контейнер или само приложение способны использовать собственный набор доверенных CA. На Debian и Ubuntu обычно используют .crt в /usr/local/share/ca-certificates/ и update-ca-certificates; на RHEL-совместимых системах — anchors и update-ca-trust. Затем проверяйте именно проблемным клиентом.

Подробнее в статье →

Как проверить, совпадает ли SSL-сертификат с закрытым ключом?

Сравните SHA-256-хеши открытых ключей, извлечённых из сертификата и закрытого ключа. Для сертификата используйте openssl x509 -pubkey, для ключа — openssl pkey -pubout, в обоих случаях с DER и openssl dgst -sha256. Одинаковые хеши означают совпадение пары. Несовпадение обычно мешает загрузке TLS-конфигурации или handshake.

Подробнее в статье →

Может ли неверное время сервера вызвать ошибку у удалённого клиента?

Обычно нет: удалённый клиент сравнивает даты предъявленного сертификата со своими часами. Поэтому при ошибке срока сначала проверяйте время на клиенте, который отклонил соединение. Время сервера всё равно важно для выпуска и продления сертификатов, журналов, выбора сертификата приложением и работы OCSP stapling, поэтому его также нужно синхронизировать.

Подробнее в статье →

Что проверять при ошибке certificate revocation check failed?

Проверьте точный текст ошибки, политику отзыва проблемного клиента, URI OCSP и CRL в сертификате, а также stapled OCSP-ответ через openssl s_client -status. Причиной может быть настоящий отзыв сертификата, недоступный или просроченный OCSP/CRL либо некорректный stapling на TLS-терминаторе. Поведение зависит от того, работает ли клиент в режиме fail-open или fail-closed.

Подробнее в статье →

SSH не подключается: Permission denied, host key changed и другие ошибки(6)

Как убедиться, что клиент предлагает нужный ключ SSH?

Нужно явно указать закрытый ключ и ограничить использование ключей агента: ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@example.example. В подробном выводе должна быть попытка использовать этот файл. Если подключение после этого работает, проблема была в выборе идентичности клиентом или в лишних ключах агента.

Подробнее в статье →

Нужно ли ставить chmod 777, если SSH не принимает закрытый ключ?

Нет. Права 777 небезопасны и могут позволить другим пользователям подменить ключи. Для личного закрытого ключа обычно используют chmod 600 ~/.ssh/id_ed25519, а для каталога ~/.ssh — chmod 700 ~/.ssh. Если ошибка сохраняется, проверьте владельца, ACL, файловую систему и сообщения клиента.

Подробнее в статье →

Можно ли удалить known_hosts при SSH host key changed?

Только после независимого подтверждения нового отпечатка ключа хоста. Сначала получите отпечаток через консоль, BMC, инвентаризацию или подтверждённый канал с владельцем и сравните его с предупреждением клиента. Затем удалите только устаревшую запись конкретного имени или адреса через ssh-keygen -R.

Подробнее в статье →

Почему возникает Too many authentication failures в SSH?

Обычно клиент или SSH-агент предлагает слишком много ключей до нужного, и сервер исчерпывает лимит попыток MaxAuthTries. Безопаснее явно передать правильный ключ через ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@example.example, чем увеличивать лимит или отключать защиту на сервере.

Подробнее в статье →

Как проверить конфигурацию sshd с учётом Match?

Проверьте синтаксис командой sudo sshd -t, затем выведите эффективную конфигурацию: sudo sshd -T -C user=user,host=client.example.example,addr=192.0.2.10. Подставьте параметры реального подключения: правила Match могут менять доступ, путь к ключам, PAM и другие настройки для конкретного пользователя или адреса.

Подробнее в статье →

Можно ли понять причину Connection closed by remote host только по клиенту?

Нет. Сообщение фиксирует только закрытие сокета: разрыв мог инициировать sshd, промежуточное сетевое устройство или другая удалённая сторона пути. Зафиксируйте время, повторите одну попытку с ssh -vvv и сопоставьте результат с журналами сервера, прокси или сетевого устройства.

Подробнее в статье →