В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.
Инструкций-рецептов намеренно не прикладываю, так как многое ищется очень легко по ключевым словам.
1. Усильте безопасность инфраструктуры Windows
Не создавайте локальные учетные записи доменными политиками
Это сильный повтор, но тут нужно повторять и повторять, так как эта ошибка очень частая – не создавайте доменной групповой политикой локальные учетные записи на хостах в домене. Опасность этого действия крайне высокая. Про это много где написано, но написано обычно на ресурсах, сугубо связанных с практической безопасностью, а не ИТ.
Причина высокой опасности – сведения об этой учетной записи, в том числе ее пароль, хранятся в открытом виде в файле groups.xml, в ресурсе sysvol контроллера домена, который по умолчанию доступен ВСЕМ участникам домена на чтение. Пароль зашифрован, но шифрование симметричное, а ключ один для всех копий Windows, и написан в открытом виде в MSDN. Отсюда следует: любой пользователь может скачать этот файл, и путем простых манипуляций узнать пароль от распространяемой учетной записи. Обычно так распространяется учетная запись с правами администратора, и часто она создается без разбора везде…
Решение – групповыми политиками добавляйте только доменные учетные записи в локальные группы на хостах. Пример расшифровки такого пароля вручную в ходе пентеста, обратите внимание на количество манипуляций до получения пароля:
Противодействие угону доменных учетных записей через mimikatz/wce
Администраторы, не связанные с пентестами и практической ИБ, редко знают про такие утилиты, как mimikatz и wce. Кратко об их работе – обладая правами локального администратора, можно извлечь из оперативной памяти билет доступа Kerberos, хеш пароля и даже сам пароль в открытом виде от учетных записей, которые недавно производили вход на этот хост. А так как администраторы совершают вход часто и много где, это приводит к высокому риску компрометации их полномочий.
Часто в компаниях есть машины, где по каким-то причинам пользователи работают с правами администратора, и при этом не штате подразделений ИТ и ИБ. Как они получили эти права, это отдельный вопрос, иногда это неизбежное зло. Обычно администраторы в таких случаях видят угрозу установки неавторизованного ПО, заражения вирусами, максимум угрозу запуска кейлоггеров с целью кражи паролей, но не подозревают, что их полномочия доступа уже под угрозой.
Против этих утилит есть меры разной степени эффективности, например, такие, но часто они не применимы по разным причинам: старая схема AD, «зоопарк» в сети, который дошел до стадии метастаз, слишком большая инфраструктура, где есть слабо контролируемые участки.
Дополнительно надо отметить, что для атаки в отдельных случаях даже необязательно устанавливать данные утилиты на хост. Пользователь с администраторскими правами может легко снять дамп нужного участка оперативной памяти, и производить все манипуляции вне рабочей сети. Это многократно увеличивает риски компрометации учетных записей более привилегированного пользователя.
Решение без дополнительных затрат: заводить для управления инфраструктурой даже не 2-3 учетные записи, как принято (надеюсь, у вас так?):
— для локальной работы;
— для администрирования серверов и ПК;
— для контроллеров домена,
а как минимум 4 учетные записи (а то и больше), в соответствии с условными «зонами доверия» в домене, и не применять их вне своей зоны. То есть, держать отдельные учетные записи:
— для работы со своей личной машиной;
— для входа на контроллеры домена и управлением ими.
— для серверов;
— для рабочих станций;
— для удаленных филиалов, если там оказался ваш домен, но при этом вы не уверены, что там происходит в конкретный момент времени;
— для зоны DMZ, если вдруг доменные хосты оказались в DMZ;
— если вы частый посетитель клуба анонимных параноиков – разбить эти зоны еще на меньшие группы, либо менять свои пароли очень часто.
Запрет на ввод «тестовых» хостов в домен
По схожей причине (см. пункт выше) по возможности лучше не заводить общественные «тестовые» хосты в домен. Такие хосты наиболее часто встречаются в компаниях с подразделениями по разработке софта, «для ускорения» и экономии лицензии они часто не снабжаются антивирусами (которые, кстати, «ловят» нешифрованные mimikatz и wce), а все причастные разработчики и тестировщики имеют на них права администратора, с целью осуществления разных сомнительных действий. Используя свои администраторские права, они могут легко похитить доменные учетные записи других администраторов.
Детализация прав сервисных учетных записей
Учетные записи в Windows имеют набор различных прав входа в систему. Это локальный вход, вход в качестве пакетного задания, в качестве службы, и др. В крупном домене всегда есть служебные учетные записи, которые необходимы для массовой работы различного ПО, служб, запуска заданий, и так далее. Обязательно нужно не полениться и минимизировать права данных учетных записей под свою область применения, и явно запретить ненужные полномочия. Это снизит риски быстрого распространения угроз в случае утечки контроля над такой записью.
Обращение к SMB по именам и запрет использования NTLM
К файловым ресурсам (SMB) в домене лучше обращаться только через доменное имя, а не через IP. Помимо удобства администрирования, так вы явным образом заставите хост аутентифицироваться по протоколу Kerberos, который хоть и имеет свои недостатки, но является значительно более защищенным, чем протокол NTLMv2, который задействуется при обращении по IP файлового ресурса. Перехват NTLMv2 хеша опасен тем, что можно словарной атакой неспешно восстанавливать пароль пользователя оффлайн, то есть, никак не беспокоя атакуемую инфраструктуру. Очевидно, что это не заметно для администраторов, в отличие онлайн-атак по перебору паролей.
Касательно протокола NTLM (который без «v2») – он должен быть запрещен. Помимо атак по перебору паролей, можно использовать атаку типа «Pass-the-hash». Эта атака по сути разрешает переотправку хеша NTLM без изменения и попыток подобрать пароль на произвольный хост, где разрешен NTLM. Сам хеш может быть украден из другой сессии в ходе атаки. Если у вас разрешены оба протокола NTLM, возможна ситуация, когда атакующий может понизить предпочтение с NTLMv2 до NTLM, и хост-жертва выберет самую слабую аутентфикацию.
Будьте внимательны, многие инфраструктуры представляют собой медленно модернизируемый «зоопарк», который с непонятными целями сохраняет старые традиции образца начала 2000х годов, поэтому там возможно все.
Блокировка механизма WPAD
Есть два механизма, которые включены по умолчанию, и в совокупности позволяют проводить атаку «человек посередине», причем практически не обнаруживая атакующего. Это механизм автоматического обнаружения прокси через специальное сетевое имя (WPAD), и механизм широковещательного разрешения имен LLMNR.
Через WPAD некоторое ПО (в домене это чаще всего служба обновлений WSUS и некоторые браузеры) выполняет поиск HTTP прокси, и готово при необходимости прозрачно авторизоваться на нем при помощи NTLM(v2). Таким образом, оно добровольно «выдает» хеш учетной записи, которая инициировала подключение. Его можно в последствии перебирать по словарю, и восстановить пароль. Либо применять атаку «Pass-the-hash», описанную выше, если не отключен NTLM (про это см. пункт выше).
Устройства выполняют поиск сервера WPAD через DNS, и, если это не сработает, задействуют широковещательный запрос LLMNR или NetBIOS. И тут атакующему уже значительно проще ответить на вопрос хоста, где же находится «правильный» сервер конфигурации прокси. Дополнительный негативный эффект — такой поиск прямо замедляет скорость подключения, так как тратится время на поиск прокси.
Решение – в групповых политиках запретить и автообнаружение прокси для ПО, и протокол LLMNR. На DNS адрес WPAD (wpad.domain.name) в DNS поставить заглушку. LLMNR это фактически имитация DNS на сегменте сети L2 путем широковещательных запросов. В доменной сети при нормально работающем DNS он не нужен. С NetBIOS все сложнее, он до сих пор используется во многих случаях, и его выключение может обрушить работу, так что здесь все же остается лазейка для навязывания WPAD.
Включение UAC на максимум
Не выключайте User Account Control (UAC), а лучше наоборот, установите его на максимум. UAC, конечно, реализован не очень удобно и не информативно, но вы не представляете, как обидно пентестеру получить формальную возможность удаленного выполнения команд от имени пользователя с администраторскими правами, но без фактической возможности выполнения именно привилегированных действий, которые как раз при «обычной» работе надоедают запросами о подтверждении. Обойти UAC или повысить права конечно, возможно, но это лишние препятствия.
Отключение скрытых файловых ресурсов
Хотя бы для машин администраторов, «важных» пользователей и серверов обязательно отключайте скрытые ресурсы $ADMIN, C$, D$, и т.д. Это первоочередная излюбленная цель любой сетевой malware и злоумышленников при получении более-менее привилегированных прав в домене.
Сетевые диски как ярлыки
Спорное решение, и явно не всем подходит, но был случай, когда это спасло от эпидемии шифровальщиков. По возможности, предоставлять пользователям удаленные общие файловые ресурсы не как сетевые диски, а как ярлыки на рабочем столе. Причина простая – malware иногда перебирает буквы дисков, и при этом не всегда в состоянии найти ресурсы, не подключенные в виде дисков.
2. Почтовая система. SPF
Ревизия содержимого SPF
Проверьте SPF-запись вашего почтового домена. А потом проверьте ее еще раз.
Многие недооценивают значимость этой записи, и при этом не понимают работу протокола SMTP. SPF запись показывает, какие ресурсы могут легитимно отправить почту от имени вашего домена. Для частного случая отправки писем на ваш домен от вашего домена (то есть, для внутренней переписки внутри вашего же домена) эта запись показывает, кто (т.е. конкретные хосты) может отправлять письма без авторизации, от имени любого пользователя. Чаще всего здесь делают две незначительные на вид ошибки, приводящие к огромным проблемам.
1) «~all» в конце SPF записи почтового домена. Не знаю почему, но большинство публичных мануалов рекомендуют оставить такую настройку. Такая настройка дает письму статус «не прошло проверку, но помечено как опасное и все равно доставлено» при отправке почты от ресурсов, прямо не указанных в SPF домена. Это говорит получателю, что решение о легитимности отправляемой почты перекладывается на жесткость настроек его спам-фильтра и других механизмов фильтрации. Далее, есть вероятность, что ваш собственный спам-фильтр настроен мягко (особенно часто это бывает с «публичными» пользователями компании, которые боятся «прозевать» письма), и это приводит к тому, что любой хост Интернета отправит вам же письмо от вашего же домена, и с некоторой вероятностью оно пройдет во входящие, а не в спам. Очень забавно видеть пользователей и даже ИТ-администраторов, беспрекословно выполняющих срочные указания от «важного начальства» из подобных поддельных писем при пентестах с социальной составляющей. Конечно же, не исключена ситуация со слабыми спам-фильтрами и у ваших контрагентов, и тогда уже вы будете делать им заманчивые предложения без своего ведома.
SPF для подавляющего большинства компаний должна содержать только –all в конце, разумеется, после тщательной сверки своего содержимого.
2) Бывает, что по ошибке в SPF корпоративного домена оказываются внешние адреса, через которые пользователи компании выходят в интернет. Последствия понятны – возможность нелегитимной отправки писем от кого угодно из корпоративного домена, куда угодно. Обычно администраторы в таких ситуациях говорят – «но у нас же есть авторизация на почте», напрочь забывая про сам механизм протокола SMTP.
Один раз видел ситуацию, когда в SPF оказался выход гостевого WiFi. Это сразу дает возможность злоумышленнику слать легитимную почту от целевого домена, даже без получения привилегированного доступа во внутреннюю сеть компании-жертвы.
Для борьбы с такими атаками дополнительно поможет система подписей DKIM, показывающая, кто есть на самом деле отправитель, но ее внедрение процесс не моментальный, поэтому начать стоит именно с настроек SPF – ужесточить ее и сделать полную ревизию по разрешенным адресам.
3. Дизайн локальной сети
Организуйте DMZ
Организуйте DMZ, и навсегда перестаньте «пробрасывать» порты из Интернет в основную сеть. Правильная DMZ эта та, ресурсы в которой с двух сторон закрыты файерволами (как от внутренней сети, так и от Интернет), а трафик разрешен крайне выборочно, и только минимально необходимый. На мой взгляд, настоящий специалист по ИБ должен думать, что его хост из DMZ по уже взломан, и оценивать риски исходя из этого. На такие мысли наводит тот факт, что в DMZ очень часто оказываются нестандартные приложения, которые несут специфичную бизнес-логику, ставятся подрядчиками на потоке, как вариант – делаются на заказ и очень плохо проверяются, например, на банальные для WEB уязвимости. Штатный специалист по ИБ чаще всего в состоянии создать DMZ, но не в состоянии проверить приложения на уязвимости. Исходя из этого и нужно действовать.
Типичный вариант правильно организованной DMZ и общий принцип движения трафика. Стрелки – направления инициации трафика из/в DMZ.
Бюджетный дизайн DMZ для параноиков, в которой каждый ресурс находится в отдельной изолированной сети, и ресурсы не «кушают» много трафика:
Что касается «проброса» портов, то помимо риска «взлома» сервиса, существует неявный риск сбора информации о внутренней сети. Например, в ходе пентестов зачастую видно порты RDP, которые были «скрыты» путем смены со стандартного 3389 на какой-нибудь 12345. Разумеется, они легко обнаруживаются сканерами, легко идентифицируются именно как RDP, но помимо простого обнаружения, они могут, например, предоставить информацию об имени компьютера и домена (путем просмотра сертификата службы RDP), или информацию о логинах пользователей.
Полностью изолированный гостевой WiFi
Гостевой WiFi должен быть максимально изолирован от основной сети (отдельный VLAN, отдельный провод от маршрутизатора интернет до точки доступа, и т.д.). Дополнительно, по возможности, выключайте гостевой WiFi в нерабочее время по расписанию на оборудовании.
Здесь есть один нюанс. Многие правильно выделяют гостевой WiFi в отдельный изолированный VLAN, но при этом зачем-то выдают клиентам адреса DNS серверов Active Directory. Наиболее рациональное оправдание – «чтобы работали ресурсы из DMZ по внутренним адресам». Однако, это является уязвимостью, и это хорошо помогает злоумышленнику при несанкционированном анализе внутреннего устройства сети, ведь запросы к DNS (PTR по внутренним диапазонам IP) обычно никак не ограничиваются.
Решение – создать легкий внутренний DNS сервер специально для WiFi, либо использовать публичные DNS в Интернет.
Не создавайте «корпоративный» WiFi на едином Preshared-ключе
Это очень частая проблема. Один ключ от WiFi часто живет годами, ведь «нельзя же беспокоить пользователей лишний раз». Это неизбежно снижает безопасность такой конфигурации до нуля с течением времени. Основные причины – текучка сотрудников в организации, кражи устройств, работа malware, возможность перебора пароля сети.
Решение: авторизация на WiFi только через WPA2-Enterprise, для того, чтобы каждый пользователь имел свои персональные, легко блокируемые учетные данные, которые контролируются централизованно. Если внутренняя сеть на самом деле не нужна для WiFi устройств, а нужен только Интернет, нужно сделать WiFi по типу гостевого. Сам дизайн аутентификации WPA2-Enterprise это предмет отдельной статьи.
Правильная сегментация сети
Максимально сегментируйте сеть на VLAN, максимально ограничьте широковещательный трафик. Об этом пишут все мануалы по дизайну сети, почему-то это редко кем соблюдается, особенно в малом и среднем сегменте компаний, но это крайне полезно как с точки зрения удобства администрирования, так и с точки зрения безопасности.
В любом случае обязательно нужно держать ПК пользователей отдельно от серверов, иметь отдельный VLAN для management-интерфейсов устройств (сетевых устройств, интерфейсов iLO/IMPI/IP KVM, и т.д.). Все это снизит возможности подделки адресов, упростит настройку сетевого доступа, снизит вероятность атак за счет широковещательных запросов, а значит повысит и стабильность работы.
На мой взгляд как безопасника (но уже чувствую летящие помидоры от сетевиков), количество VLAN для пользователей больше зависит от количества коммутаторов доступа и от количества условных групп пользователей по административному признаку, а не от самого количества пользователей. Имеет смысл сделать количество пользовательских VLAN на уровне числа коммутаторов доступа (даже если они собраны в стек). Так очень сильно ограничится широковещательный трафик, не будет «размазывания» одного VLAN по множеству коммутаторов доступа. Это не сделает для сети лишней работы, так как чаще всего трафик пользователей идет либо в серверный сегмент, либо в Интернет (т.е. в любом случае в сторону уровня ядра сети или уровня распределения), а не между самими пользователями. В таком случае легче отлаживать сеть, и предотвращать атаки, связанные с широковещательными пакетами.
Для малых сетей ситуация сильно отличается – зачастую сегментировать нечего, сеть слишком мала. Однако, во всех организациях, где появляется минимальных набор серверов, обычно вместе с серверами закупаются управляемые коммутаторы, иногда с функциями L3. Почему-то они используются как просто коммутаторы, зачастую даже без минимальной настройки, хотя настройка L3 для простой маршрутизации между 2-3 сетями очень проста.
Защита от ARP spoofing и поддельных DHCP серверов
Два механизма, на языке технологий Cisco: DHCP snooping и ARP Inspection, помогут расстроить разных шутников-пользователей и реальных злоумышленников. После их внедрения вы получите предотвращение появлений ложных DHCP серверов в сети (которые могут появиться как по ошибке — кто-то перепутал настольный «домашний» маршрутизатор форм-фактора «мыльница советская» с такого же типа коммутатором, так и в результате атаки), и атак типа «человек посередине» через ARP протокол. В сочетании с малыми размерами VLAN (предыдущий пункт) это отлично снизит возможный ущерб.
Если такие функции невозможно настроить, как минимум стоит указать жесткую привязку MAC адреса шлюза сети с физическим портом коммутатора.
Port security
Если кабельная сеть и оборудование позволяют, настройте на коммутаторах доступа port security. Это хорошо защищает, хоть и не полностью, от подключения «левых» и «лишних» устройств, несанкционированного перемещения компьютеров в пространстве.
Противодействие «левым» устройствам
Даже с описанными выше защитными мерами (port security, dhcp snooping, arp inpection), возможно появление «левых устройств», причем, как показывает практика, наиболее вероятное устройство в этом случае – «домашний» роутер с функцией «клонировать MAC-адрес компьютера на внешний интерфейс». Поэтому, есть следующий шаг развития сетевой тирании – 802.1x. Однако, это уже серьезное решение, требующее хорошего планирования, поэтому возможен более простой способ выявления самовольных роутеров (именно выявления, а не пресечения). Здесь хорошо поможет анализ трафика на промежуточном звене сети на предмет параметра протокола IP — TTL. Можно сделать span порт на коммутаторе, зеркалирующий трафик в сервер со снифером, и анализировать этот трафик на наличие пакетов с аномальным TTL. В этом поможет банальный tcpdump/Wireshark. Трафик с таких роутеров будет иметь TTL меньше на 1, чем легальный трафик.
Либо же, можно настроить правило фильтрации по конкретным TTL, если сетевые устройства это позволяют. Конечно, от серьезных злоумышленников это не спасет, но чем больше препятствий, тем лучше для защищенности.
Удаленный доступ
При организации удаленного подключения к сети забудьте про протокол PPTP. Он, конечно, настраивается быстро и легко, но помимо наличия уязвимостей в самом протоколе и его составляющих, он плох тем, что очень хорошо виден сканерами сети (из-за работы на TCP на одном и том же порте), зачастую плохо проходит через NAT за счет транспорта на GRE, от чего на него жалуются пользователи, и по своему дизайну не содержит второго фактора аутентификации.
Чтобы внешнему злоумышленнику было удобнее работать, аутентификацию на таком VPN обычно привязывают к доменным учетным записям, не вводя второй фактор аутентификации, что часто и эксплуатируется.
Решение-минимум: использовать протоколы на UDP (либо свободно инкапсулирующиеся в UDP), которые не так видны при сканировании, с предварительной аутентификацией по PSK, либо по сертификату (L2TP/IPSec, OpenVPN, разные вендорские реализации IPSec). Обязательно нужно настроить перечень адресов и портов внутри сети, куда можно получить доступ, используя VPN.
Запретите прямой произвольный доступ в интернет для «пользовательской» сети
Прямой выход в интернет для пользователей – это зло, хотя с удешевлением каналов Интернет его становится все больше и больше, особенно в малых и средних компаниях. Многие администраторы ограничивают исходящие порты для пользователей на минимальный набор, вроде 80, 443, пытаясь экономить полосу. С точки зрения Malware и злоумышленников, это ничем не отличается от свободного доступа в Интернет.
На мой взгляд, всегда нужен прокси-сервер, пусть без кеширования и авторизации, даже в самых маленьких сетях, и запрет на прямой выход в интернет для пользователей. Основная причина — множество всяческой malware обращается на свои центры управления именно по HTTP(S), либо по чистому TCP c популярными портами (80/443/25/110…), но при этом она зачастую не в состоянии обнаружить настройки прокси в системе.
Возьмите под контроль IPv6
Если вы не интересовались использованием IPv6, повторите все действия по фильтрации трафика применительно к IPv6, либо запретите его. Ваша инфраструктура может неявно использовать его, но вы можете и не знать об этом. Это опасно проблемами несанкционированного получения доступа в сети.
Трафик в межфилиальных сетях
Если у вас под контролем крупная сеть с удаленными филиалами, и в ней настроен Site-to-Site VPN, не поленитесь максимально ограничить трафик, который идет к вам в центр, причем именно на центральном оборудовании, а не в филиалах. Не воспринимайте каналы с удаленными филиалами как «свою родную» сеть. Обычно в компаниях филиалы защищены меньше центра, и большинство атак начинаются именно с филиалов, как с «доверенных» для центра сетей.
Ограничение icmp ping
Ограничьте список адресов, которые могут «пинговать» важные сервисы. Это снизит обнаружение ваших хостов, хоть и ненамного. При этом не забудьте, что ping – это не весь протокол icmp, а только один вид сообщений в icmp, и не нужно его (icmp) запрещать целиком. По крайней мере, вам точно будут нужны для корректного взаимодействия со всеми сетями некоторые сообщения видов Destination Unreachable. Не создавайте полным запретом ICMP на своих маршрутизаторах так называемую MTU Discovery Black Hole.
4. Шифрование трафика
Сертификаты SSL для всего и везде
Не ленитесь защищать шифрованием все сервисы, куда можно пристроить SSL/TLS. Для хостов из домена Active Directory можно настроить AD Certificate Services, либо распространять сертификаты служб через групповые политики. Если нет денег для защиты публичных ресурсов, воспользуйтесь бесплатными сертификатами, например, от startssl.
Для себя, т.е. администраторов, всегда можно пользоваться легким самодельным удостоверяющим центром, например, easy-rsa, либо самоподписанными сертификатами. Вы же заметите, что на вашем внутреннем администраторском ресурсе внезапно возникла ошибка доверия к ранее одобренному сертификату?
Если вам кажется, что вашему сайту-визитке ничего не угрожает, то надо учесть, что шифрование спасет вас не только от кражи учетных данных, но и от подмены трафика. Все наверно видели на сайтах с доступом по открытому HTTP заботливо встроенную операторами связи рекламу? А если вам встроят не рекламу, а «правильный» скрипт?
Wildcard SSL сертификат
Если вы стали счастливым обладателем wildcard-сертификата (для доменов «*.ваш-домен»), не торопитесь его распространять по всем публичным серверам. Сделайте себе отдельный сервер (или кластер), к примеру, на Nginx, который будет «разгружать» от шифрования входящий трафик. Так вы сильно снизите количество каналов утечки закрытого ключа вашего сертификата, и в случае его компрометации, не будете менять его сразу на множестве сервисов.
5. Пару слов про веб-серверах на основе Linux
Linux-хосты чаще всего видно в роли веб-серверов, классической связки LAMP (Linux + Apache + Mysql + PHP, или любой другой скриптовый язык), которую чаще всего и ломают за счет дыр в веб-приложении, поэтому опишу самый минимум для данной связки, который относительно легко внедряется, и не требует большого опыта настройки и отладки (вроде мер типа SELinux/AppArmor).
Доступ к серверу
Не поленитесь запретить вход по ssh для root, настроить авторизацию только по сертификатам и сместить порт ssh куда-нибудь далеко со стандартного 22.
Если на сервере не один администратор, активируйте для каждого механизм sudo, а для root используйте пароль, который никто не знает, кроме бумаги, которая все время лежит в конверте и в сейфе. В этом случае вход через ssh по паролям категорически нельзя разрешать.
Если же наоборот, администратор один, то деактивируйте sudo (особенно в том случае, если у вас по каким-то причинам сохранился вход через ssh по паролю), и для администраторских задач используйте аккаунт root.
Ну и конечно, классика — не работайте под рутом.
Iptables
Не поленитесь настроить iptables, даже если вам кажется, что iptables ничего не решит, например, если на сервере из сетевых приложений работают только Web и ssh, которые и так должны быть разрешены. В случае получения минимальных полномочий злоумышленником на сервере, iptables поможет предотвратить дальнейшее распространение атаки.
Правильно настроенный iptables, как и любой другой файервол, разрешает только минимально необходимое (включая исходящие соединения через цепочку правил output). На случай минимальной конфигурации Web-сервера в iptables будет не более 10 строк. По сложности, это значительно проще настройки firewall для доменного хоста Windows, где можно нечаянно запретить динамические RPC порты, доменные службы и другие важные для работы коммуникации, так как не всегда очевидна даже последовательность коммуникации. Поэтому, для настройки iptables под web-сервер не нужны особые знания по сетям, и можно настроить файервол значительно легче.
Противодействие повышению прав в случае взлома
Отправьте Apache работать в chroot. Как вариант, сделайте отдельные разделы в файловой системе для /var/ и /tmp, смонтируйте их с флагами noexec,nosuid. Так вы защитите сервер от исполнения локальных эксплоитов в бинарном виде, которые могут повысить права атакующего. Запретите исполнение интерпретаторов скриптовых языков типа Perl, Python для «других пользователей» (chmod o-x), куда относится веб-сервер, если это не требуется веб-серверу и другим службам. Чем меньше в системе «других служб», а соответственно, пользователей под них, тем проще это сделать.
Пара слов о настройке web-сервера на примере Apache
Здесь перечислено то, что может сделать системный администратор для защиты веб-приложения, даже не зная специфики веб-программирования.
— Запретите наличие VirtualHost, который отвечает на запросы вида http(s)://ip-адрес/, даже если приложение на сервере одно. Так вы значительно снизите возможность обнаружения приложения.
— Запретите в конфигурации apache вывод ошибок (опции ServerSignature Off, ServerTokens Prod), это затруднит определение версии ОС и Apache.
— Установите через mod_headers опции для Cookies HTTP_only и Secure для вашего веб-приложения, даже если у вас веб-приложение делает это само. Это защитит вас от перехвата Cookies через прослушку нешифрованного HTTP и части атак XSS.
— Отключите вывод ошибок на страницы сайта в конфиге языка сайта (это в первую очередь касается PHP). Это затруднит атакующему изучение слабых мест вашего веб-приложения.
— Контролируйте, чтобы индексы директорий были выключены (опция «–Indexes» в настройках сайта или файлов .htaccess).
— Дополнительно сделайте basic-авторизацию на директорию с администраторской панелью сайта.
— Установите принудительное перенаправление с 80 порта на 443, если у вас есть настроенный TLS. Запретите устаревшие алгоритмы SSL (SSLProtocol all -SSLv2 -SSLv3), слабые алгоритмы шифрования и вариант его полного отсутствия через директиву SSLCipherSuite. Это защитит от атак на «понижение» уровня шифрования.
Проверить свою настройку SSL можно, например, через https://www.ssllabs.com/ssltest/
Настройте аудит системы
Включите и настройте auditd по показательным событиям (создание пользователя, изменение прав, изменение конфигурации) с отправкой уведомлений на удаленный сервер. Все взломы не производятся одномоментно, поэтому периодически осматривая логи, пусть даже и вручную, можно обнаружить подозрительную активность. Дополнительно это поможет при «разборе полетов» в случае инцидентов.
Ставьте только минимально необходимое в системе
ОС на основе Linux хороши тем, что можно гибко выключать/удалять ненужные компоненты. С точки зрения безопасности, в первую очередь, это относится к сетевым и локальным демонам. Если вы видите, что на вашем только что установленном сервере работают демоны, которые явно или косвенно не относятся к задаче данного сервера, задумайтесь – действительно ли они нужны. Для большинства случаев это всего лишь стандартная установка, и они легко и без последствий выключаются и/или удаляются. Например, не всем нужен RPC, который включен по умолчанию в Debian. Не ждите, пока под такие сервисы найдут уязвимости и сделают эксплойт, а вы забудете обновиться.
6. Самоконтроль
Даже не обладая навыками специалиста по тестированию на проникновение, можно дополнительно включить в самоконтроль минимальные «пентестерские» действия. Вам помогут:
Сканеры безопасности
Проверьте действительную видимость открытых портов при помощи nmap/zenmap. Иногда это дает результаты, которых вы не ожидаете, например, в случае ошибочной настройки правил фильтрации трафика, или в случае, когда сеть большая и сегментация персонала по зонам ответственности также очень значительна.
Проверьте хосты в сети на типовые уязвимости при помощи сканера OpenVAS. Результаты также бывают неожиданными, особенно в крупных сетях, где обычно существует хаос разной степени. Главное при использовании сканеров безопасности – отличать ложные срабатывания от настоящих уязвимостей.
Все перечисленные утилиты бесплатны. Делайте это регулярно, не забывайте обновлять сканеры.
Брутфорс учетных записей
Проверяйте учетные записи сотрудников на предмет слабых паролей. В минимальной комплектации в этом поможет файловый ресурс, доступный любому доменному пользователю после авторизации, и утилита THC Hydra. Сформируйте словари из паролей, которые подходили бы под вашу парольную политику, но при этом были бы простые, вроде «123QAZxsw». Количество слов в каждом – не более числа допустимых попыток авторизации в домене, минус 2-3 для запаса. И пропустите через брутфорс все учетные записи домена, уверен, найдете много интересного.
Разумеется, на эти проверки заранее нужно получить официальное (желательно, «бумажное») разрешение от руководства, иначе это будет походить на попытку неавторизованного доступа к информации.
Минутка юмора
Напоследок, пентестерская байка касательно паролей. Осенью 2015 года мы делали социальный пентест с применением фишинга – выманивали доменные пароли. У двух попавшихся пользователей пароль был «Jctym2015» («Осень2015»). Посмеялись, забыли. В ноябре 2015 года делаем подобный пентест в другой организации, никак не связанной с первой, опять те же пароли, и опять сразу у нескольких пользователей. Начали что-то подозревать, нашли в одной оранжевой социальной сети такое вот руководство к действию:
Надеюсь, кому-нибудь эти простые советы помогут существенно защитить свою инфраструктуру. Конечно, есть еще масса различных технических и организационных тонкостей, касающихся вопросов «как надо делать», и «как делать не надо», но все они могут быть раскрыты только в рамках конкретной инфраструктуры.
Комментарии (86)
Sabin
13.05.2016 11:24Хотелось бы получить совет по двум вопросам, оба относятся к очень маленьким фирмам (менее 10 сотрудников) с одноранговой сетью. В 1 очередь
1) Что лучше и безопаснее использовать для удалённого доступа извне? Использую Litemanager Free, иногда люди сами запускают разово тимвьюер. Интернет на удалённой стороне как правило медленный, vnc через ssh или подобное думаю будет не рабочим вариантом.
2) Что посоветуете для удалённого доступа уже внутри сети? Командной строки достаточно. Я склоняюсь к freesshd (простая настройка, можно ставить батником или надиктовать инструкцию по телефону), но так же рассматриваю powershell (пока не получается по непонятной причине соединяться в нём по https, стандартный kerberos отпадает по причине отсутствия домена).
chupasaurus
13.05.2016 13:02+11) vnc даже поверх ssh хватит 256-512 Kib/s для работы с преферансом и куртизанками, что укладывается даже в upstream у ASDL1
2) На гитхабе есть ansible winrm bat-скрипт, включающий возможность PSRemote.
LoadRunner
13.05.2016 11:42У меня вопрос по пункту 2.1.
Я бы с радостью использовал -all, но у нас есть крупный клиент, у которого почта управляется провайдером, а у провайдера железки письма пересылают от своего имени на почтовый сервер, и с этим никто из нас не в силах ничего поделать, в итоге приходится использовать ?all (рекомендация админов клиента, как сказали — тогда наши письма будут к ним доходить).
И про ?all в статье не написано — в чём тут минусы со стороны безопасности?
Просто в последнее время на некоторые почтовые ящики (около 5 — самые засвеченные, я так понимаю) приходят письма от них же. То есть, отправляют сами себе письма, как и написано в статье. По заголовку — отправлены с левого хоста. Да, такие письма попадают в спам автоматически, а вложения удаляются антивирусом, но сам факт беспокоит.
ValdikSS
13.05.2016 12:25+2SPF не особо полезен сам по себе, без DMARC:
https://habrahabr.ru/post/270159/#comment_8643345
https://habrahabr.ru/post/270159/#comment_8644311LoadRunner
13.05.2016 12:32Спасибо за ссылки (хотя вроде читал уже эту статью и комментарии к ней), но мой мозг пока так до конца и не въехал, как DMARC грамотно настроить (самостоятельно пытался разобраться, гуглил, но нужно объяснение «на пальцах», для лучшего понимания. Без этого пока не получается вникнуть). Есть у Вас в запасе ссылка, которая может помочь?
И правильно ли я понимаю, что у принимающей стороны должна быть встречная настройка — проверка DMARC?ValdikSS
14.05.2016 02:14Ссылок нет. DMARC поддерживается всем современным софтом и, наверное, всеми публичными крупными email-сервисами.
pavelsupr
13.05.2016 13:01Это да, я имел ввиду тот случай, когда «настраивают» SPF (и DMARC), а фактически там шлак прописан.
pavelsupr
13.05.2016 13:18?all — это еще хуже, чем ~all. Последнее хоть намекает, что письмо поддельное, а первое «разводит руками». Частичное спасение — проверка подписью DKIM. Частичное потому, что при общей неправильной политике DMARC ваши письма не будут доходить по получателей.
Нужно пересмотреть ваши маршруты почты, и четко определить, кто доверенный, исходя их этого писать DMARC.LoadRunner
13.05.2016 13:48Для начала я бы хотел разобраться, что такое DMARC. В общих чертах понимаю, а в деталях — уже начинается «не понимаю».
Со своей стороны наши письма подписываются DKIM. Только опять же — это для получателя, он должен корректно обрабатывать и DKIM, и DMARC с SPF. Если я правильно понимаю.
А как избавиться от ?all, но чтобы клиент получал письма, при условии, что изменения возможны только с нашей, отправителя, стороны?
Alexeyslav
13.05.2016 13:51С той стороны изменения тоже возможны, но только они ленятся. Надо продавливать эти изменения, хотябы через клиентов.
LoadRunner
13.05.2016 14:20На уровне руководства фирмы продавливать? Клиент крупный, филиалы по всей России. Кто отвечает за решения, где размещать почту?
Связаться с хостером почты и попросить настроить железо так, как удобно нам?
Это ситуация, когда нам приходится подстраиваться под крупного клиента, а не наоборот.
tbp2k5
14.05.2016 03:20+1Вы не правы: ?all — просто утверждает что ваши пользователи могут быть за пределами вашей сети, он-же обеспечивает нормальную пересылку почты(forward), он-же ограничивает фривольную интерпретацию вашего SPFа у получающей стороны, и т.д. Собственно такие политики — стандартная практика научных/университетских учреждений.
Пара примеров:
# dig txt yale.edu
…
yale.edu. 10800 IN TXT «v=spf1 ip4:130.132.50.0/24 ip4:130.132.232.0/24 include:_spf.google.com include:spf.protection.outlook.com include:_spf.qualtrics.com ~all»
# dig txt princeton.edu
…
princeton.edu. 43200 IN TXT «v=spf1 ip4:128.112.128.212 ip4:128.112.128.213 ip4:128.112.128.214 ip4:128.112.128.215 ip4:128.112.128.216 ip4:140.180.223.12 ip4:140.180.223.155 ip4:140.180.223.156 mx ?all»pavelsupr
14.05.2016 08:15>?all — просто утверждает что ваши пользователи могут быть за пределами вашей сети
SPF не предназначен для пользователей. Пользователи абсолютно легитимно авторизуются на Mail submission agent через SMTP с авторизацией, либо через веб-клиент из любой локации. SPF предназначен для получателя, чтобы тот смог оценить достоверность писем от вас.
>он-же обеспечивает нормальную пересылку почты(forward)
Тут сложнее. SPF по механизму действия ломает «классический» форвард, но с другой стороны, это в первую очередь проблема кривой настройки сервера-форвардера, а не владельца SPF.
Насчет примеров — намного лучше по некторым вопросам ни на кого не смотреть. Я не говорю, что в Вэльсе или Принстоне кривой SPF. Я имею в виду, что если они так сделали, это их решение, и почему они его приняли, мы не узнаем. Для другой системы подобная настройка может привести к легкому засылу фишинга.tbp2k5
14.05.2016 13:57+2«и почему они его приняли, мы не узнаем»:
Собственно я вам написал почему. У меня / у нас та-же ситуация: научное/университетское учреждение, почтовая система используется практически с момента создания протокола. За десятилетия складываются определенные традиции:
— почта ученых перенаправляется вслед за ними (они публикуют свои адреса в научных статьях)
— выпускники (алюмни) получают пожизненные адреса
и т.д.
Все это в разумных пределах конечно.
Видимо создатели SPF надеялись что весь инернет все переделает. Так обычно не бывает и в конкретном случае для прозрачного перехода требуются гигантские ресурсы при совершенно не очевидном/посредственном результате.
ПС С фишингом борются так-же как с обычным спамом. SPF в этом контексте имеет практически нулевую эффективность.pavelsupr
14.05.2016 21:55Спасибо за интересную информацию.
Что же поделать, если SMTP и другие почтовые протоколы разрабатывали очень давно, когда все было белое и пушистое, авторизаций не было, спуфингом никто не занимался. Остается только добавлять костыли, которые будут все усложнять.
Добавлю небольшую историю про фейлы SPF. Мои коллеги нашли у одного очень крупного почтового сервиса, который предоставляет услуги типа «почта для вашего домена» интересный баг (передаю привет автору находки randomib). Есть домен с spf, где в конце стоит ~all, остальные настройки говорят сомнительным письмам строго валиться в спам. Так оно и происходит, за исключением одной ситуации. При отправке внутридоменного фишинга на групповой ящик рассылки происходит форвардинг письма сервисом самому себе, SPF приобретает статус pass вместо softfail. Письмо радостно попадает в инбокс как правильное. Производитель сервиса это багом не считает, говорит, сами смотрите заголовки, проверяйте DKIM. А строгий DKIM мало кто может сделать, так как назло найдется что-то, что его не умеет применять.
Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов.tbp2k5
14.05.2016 23:08«Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов. »:
SPF декларировать безусловно нужно хотя-бы потому что SPF используется большинством анти-спам систем и в случае отсутствия SPF записи, зачастую, применяются параметры хуже любой пермисив политики SPF. С дугой стороны я-бы поостерегся советовать не ставить "?all" или "~all": «рядовые компании» тоже пишут письма клиентам/партнерам. Эти письма будут/могут теряться при перенаправлениях возникающих регулярно и оправданно (компании покупают и продают, они сливаются и разделяются, возникают/исчезают филиалы, ребрендеринг и т.д.). Установка систем которые переписывают шапку или перепаковывают письмо — скорее исключение чем правило. Просто нужно помнить что мир не будет подстраиваться под «рядовые компании» и если нашей гипотетической «рядовой компании» важно/нужно держать связь с миром надо принимать мир таким как он есть.
PS Если хочется запретить письма с вашим «from»ом приходящие к вам из вне — просто запретите их на вашем MXе — это куда надежней.
Merkat0r
13.05.2016 12:14И к сожалению, как минимум в 90% ничего из этого не выполнимо.
Начиная от *бухгалтерша тетя Глаша(да вообще любой юзер) не будет и недолжна заморачиваться, а вводить 123456 !* до *Apple ето круто и поэтому у нас все будет на Apple Extreme\etc*. В большинстве случаев просто найдут нового студента-типаадмина. Тут надо исправлять в мозгах в 1 очередь с софтом и так все давно известноpavelsupr
13.05.2016 12:21Не согласен. Я делал упор на то, что делается своими руками, и без дозакупок. Не уверен, что тетя Глаша у вас создает кривые групповые политики, и конфигурит ssh.
Задача безопасника/админа — организовать правильную настройку того, на что можно повлиять, а про остальное — вовремя и правильно донести риски тому, кто «выше». Если вы все сделали правильно — риски уже не ваши, вы сделали все, что от вас зависело.Merkat0r
13.05.2016 12:34Тетя Глаша, конечно же, ничего не создает, но обязана(потому что хочет) войти под 123456, потому что *я не буду ничего запоминать сложного(или начнет постоянно «забывать») и конечно же раструбит пароль всем своим «девочкам» *, а также подключить Айфончик и чтоб айтюнс стоял и чтоб контакт играл и т.д. и т.п.
Я, в принципе, и имел ввиду что до подавляющего большинства это донести просто не возможно, как в анекдоте про собаку — «она же хочет, так дай ей». \
К ОГРОМЕННОМУ сожалению это суровая реальность почти всего, что не «жесткий „энтерпрайз… или нет хороших отношений напрямую с генеральным, а иначе вас просто заменят на “мальчика, который сказал, что все это можно, значит он умнее да и денег просит в 5 раз меньше, пиши короче по собственному». как то так :)ildarz
13.05.2016 13:26+1Выдайте тете Глаше токен с сертификатом, и ей логиниться будет даже проще, чем пароль набирать. Попутно «раструбить пароль девочкам» становится более затруднительно. Как раз этот текст выгодно отличается адекватными рекомендациями, из которых в конторе со средней руки бардаком можно выполнить очень многое.
Alexeyslav
13.05.2016 13:48+1Будет этот токен с сертификатом лежать возле монитора и гулять по девочкам. Как например закрытая цифровая подпись директора для взаимодействия с банк-клиентом, и с подписанным паролем на той же дискете ЧТОБЫ ЕГО НЕ ЗАБЫТЬ.
ildarz
13.05.2016 14:06Да и пусть лежит. Внутренняя безопасность — отдельный большой вопрос, а вот для атакующего, не имеющего доступа к токену (любого внешнего, например) задача серьезно усложняется.
scarab
15.05.2016 01:04+2У токена есть ещё один большой плюс — проще установить ответственность, особенно в маленьких конторах. Лежит этот токен у директора в сейфе, отдал он его тёте Глаше — та может ходить; забрал — не может. Передала девочке — не может работать сама, ну и плюс для далёкого от ИТ директора передача токена — весомее и понятнее, чем разглашение пароля.
NRinat
13.05.2016 21:11Поддерживаю.
У своих клиентов мы реализовали 90% того, что описано в этой замечальной статье. +802.1x и WPA2-Enterprise Wifi.
Необходимо докрутить NTLMv2 и WPAD., хотя, вроде они усилены или даже погашены. Надо будет еще раз проверить.
NRinat
14.05.2016 18:57+4Павел, большое спасибо за очень полезную статью.
Очень нравится ваш стиль изложения информации, — все понятно, ничего лишнего.
От себя хочу немного добавить.
Active Directory
Учетные записи локальных админов необходимо либо блокировать совсем при помощи механизма Restricted Groups, либо использовать механизм LAPS для ротации паролей.
Также, при помощи Restricted Groups необходимо регулировать состав привилегированных доменных и локальных групп (Domain Admins, Enterprise Admins, Schema admins, “Local” Administrators, Guests и так далее). При помощи этого же механизма необходимо очищать встроенные группы (Printer operators, backup operators и так далее), так как пользователь, входящий в данные группы наделяется очень большими правами и через его учетную запись возможно повышение привилегий.
Желательно удалять с контроллеров домена и других серверов GUI и WoW64. Не всегда такое возможно, но желательно.
В домене очень желательно настроить центральное хранилище ADMX-шаблонов.
Центральное логирование
В сети желательно выделить изолированный хост, на который все системы сети будут слать свои логи. К данному хосту должен быть по возможности закрыт любой сетевой удаленный доступ, чтобы уменьшить вероятность его взлома. Если это windows-система, она не должна быть подключена к домену и должна иметь самый строжайший профиль безопасности.
На данном хосте можно запускать анализаторы логов сразу для всех систем инфраструктуры. И в случае компрометации сети, можно будет понять, откуда и как был произведен взлом.
Сетевые устройства
На коммутаторах и маршрутизаторах хорошо бы подвергать автоматическому аудиту файлы конфигурации. Тот же сервер логирования, может периодически подключаться к данным устройствам и проверять была ли изменена конфигурация. Если была изменена, то обязательно высылать предупреждение о данном событии группе администраторов.
Единая аутентификация/авторизация
На всех сетевых устройствах желательно настроить единую аутентификацию/авторизацию. Связка Radius+NPS работает отлично, если есть AD.
DMARC
После того, как настроены и протестированы DKIM и SPF, очень желательно прописать для доменов компании DMARC настройки, чтобы уменьшить спуфинг адресов из ваших доменов.
Предложение
Может быть объединим усилия и напишем по каждой главе по отдельной статье?
Думаю, многим было бы узнать, как правильно развернуть взрослый PKI (с поднятием автономного ADCA, раздачей сертификатов для SubCA и т. д.), потом настроить WPA2-Enterprise, 802.1x.
Все, что вы описали, в моих системах реализовано и по некоторой части проектов есть документация.
Еще раз спасибо за статью.
whiplash
13.05.2016 23:03+1Откуда вообще вот это миф про бухгалтеров и тем более 123456 в виндовой среде?
Если ИТ и просто менеджмент — вменяемый, то все будет хорошо. Речь конечно про более-менее крупные компании.
imbasoft
13.05.2016 12:53+1Хорошие рекомендации.Хотел дополнить про DMZ.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
navion
13.05.2016 14:22Сомнительное решение, лучше поставить нормальный FW с анализом протокола и выделить изоалированный VLAN для каждого сервера в DMZ.
imbasoft
13.05.2016 16:12В чем сомнительное?
VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.navion
13.05.2016 17:00В чем сомнительное?
В сложности настройки и необходимости ставить дополнительный софт на серверы.
Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Он сейчас есть в любом NGFW, а раньше был в модуле IPS для ASA и других файрволов.imbasoft
13.05.2016 17:56NGFW, IPS — это устройства, цена покупки которых (не считая подписок на обновления и тех. поддержку) измеряется в килобаксах. Конечно если у вас есть на это деньги — здорово. SSH/VPN туннели (как вариант OpenVPN) — бесплатны. Настройка back connect через SSH — занимает пару часов (практический опыт).
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI? Вопрос риторический :)
Применение SSH/VPN — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.navion
13.05.2016 19:01NGFW, IPS — это устройства, цена покупки которых (не считая подписок на обновления и тех. поддержку) измеряется в килобаксах.
Эти модули входят в состав устройств через которые компания выходит в интернет и даже на сервер с FreeBSD можно натянуть snort или ещё какой опенсорсный IPS/IDS.
Настройка back connect через SSH — занимает пару часов (практический опыт).
Как вы будете его настраивать на контроллере домена и куда вас пошлют админы с просьбой поставить туда OpenVPN?
И проблема никуда не денется — правило файрвола server1:* -> server2:53/UDP просто помещается внутрь туннеля и при взломе server1 доступ к server2:53/UDP у него остаётся.
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI?
Для защиты процессинга наверняка есть свои решения.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи.
IPSec.imbasoft
13.05.2016 19:45Эти модули входят в состав устройств через которые компания выходит в интернет...
Подавляющее число компаний в России выходит в Интернет через бытовые роутеры а-ля DlInk или Linux-box, а те кто побогаче ставит Cisco типа ISR 2800. Устройства подобного класса реализуют Statefull firewall не более.
К NGFW относятся устройства уверенно работающие с deep packet inspection например железки Palo Alto которые по заверению производителя могут отличить HTTPS трафик от IE от HTTPS трафика Chrome и т.д. Open Source решения подобного плана, чтобы «скачать из Интернета и работало» ( без необходимости допила и НИОКРа) я не видел.
Как вы будете его настраивать на контроллере домена и куда вас пошлют админы с просьбой поставить туда OpenVPN?
Единственный вариант, когда нужно из DMZ разрешать доступ к контролеру домена внутри сети — это когда RO DC (read only domain controller) из DMZ хочет реплицироваться с полнофункциональным доменом внутри сети. Остальные случаи небезопасны by design. Проблем поставить OpenVPN на контролеры домена я не вижу. Работать он может как сервис, если нормально настроить то и связь устойчиво держит.
И проблема никуда не денется
Back connect туннели не защищают сервера от взлома, они призваны избавить от необходимости создания дыр в DMZ FW (то есть правил, пример которых вы указали) между DMZ и внутренней сетью.
Для защиты процессинга наверняка есть свои решения.
Конечно есть, но это не массовый NGFW. Поэтому просто «анализатор протокола», который есть в массовых решениях позволит вам защитить только массовые протоколы — TCP, HTTP и некоторый ряд других. Но подчеркну еще раз это не универсальное решение.
IPSec.
IPSec в чистом виде для back connect не подойдет. Почему? В нем нет понятия сервера (как компьютера, ожидающего подключения со стороны других компьютеров), туннель строится как по запросу сервера 1 (DMZ), так и по запросу сервера 2 (вн. сеть). Рассмотрим случай когда между сервером 1 и сервером 2 долго нет сетевого обмена и по тайм-ауту (или по другим причинам) туннель упал. Затем сервер 1 понял, что он хочет что-то передать серверу 2 он пытается к нему обратится, но поскольку дыры в DMZ нет — сделать он это не может.navion
15.05.2016 16:00Open Source решения подобного плана, чтобы «скачать из Интернета и работало» ( без необходимости допила и НИОКРа) я не видел.
ИБ вообще штука недешевая, хотя ASA 5506-X стоит пару килобаксов и тоже что-то умеет.
Back connect туннели не защищают сервера от взлома, они призваны избавить от необходимости создания дыр в DMZ FW (то есть правил, пример которых вы указали) между DMZ и внутренней сетью.
Чем плохи правила на файрволе? У куча VPNов есть куча минусов — сложность, ненадёжность и отсутствие центральной точки контроля.
Это решение для подключения к сторонним оргазациям над которыми нет контроля. Например, чтобы избежать ситуации когда у подрядчика изменился IP-адрес и об этом забыли сообщить.
IPSec в чистом виде для back connect не подойдет.
Цитата была про защиту транспорта, с ней IPSec прекрасно справляется.
navion
13.05.2016 17:05А вообще, лучше призвать в пост JDima и узнать мнение нормальных сетевиков.
JDima
13.05.2016 17:21+2Призвался.
imbasoft, странное предлагаете.
С годами DMZ превращается в решето и теряет эффективность
C какой стати? Можно завести политику вычищать все ни разу за полгода не сработавшие правила, и при выведении из эксплуатации хостов подтирать за ними правила. Даже если правила громоздятся — ничего особо страшного от этого нет, если на уровне доступа не давать спуфить адреса.
туннелирующий back connect
Что-что? Четыре фронта и четыре бекенда — это уже 16 туннелей городить, по четыре на хост? А что вообще даст этот туннель? И как ими централизованно управлять — например, ограничивать протоколы, исходя из того, что сервер в DMZ похакан?imbasoft
13.05.2016 18:17С годами DMZ превращается в решето и теряет эффективность......C какой стати?
Под дырами в DMZ — подразумеваются легитимные «дыры» используемые легальными серверами для легальных целей. В вашем примере (если я вас правильно понял) есть фронт, который стоит в DMZ и есть back который находится внутри сети, причем фронт должен иметь возможность достучаться до бека. Для этого на DMZ FW вы разрешаете хождение трафика между фронтом в DMZ и бэокм внутри сети. Вот это правило я и называю дырой в DMZ.Если сеть растет (становится больше сервисов) таких правил становится все больше и больше.
Опасность дыры в том, взломанные сервера из DMZ могут ими воспользоваться, с помощью IP/MAC спуфинга для атак серверов внутри сети.
туннелирующий back connect… Что-что? Четыре фронта и четыре бекенда — это уже 16 туннелей городить, по четыре на хост? А что вообще даст этот туннель?
Подобный подход позволяет вообще не делать дырок в DMZ (то есть открытия маршрутизации из DMZ ко внутренней сети), а также защитить трафик от перехвата и модификации (ARP spoof и др MiTM-атак).
И как ими централизованно управлять
Не совсем понятно чем вы хотите управлять. Туннель строится на двух точках 1 — сервер в DMZ и 2 — сервер в внутрисети. Если сервер 1 похакан — управлять тунелями не надо, а надо восстанавливать контроль над сервером. Если имеется ввиду оперативная блокировка, то ее можно сделать на DMZ FW полностью заблокировав весь трафик до взломанного сервера.JDima
13.05.2016 21:49взломанные сервера из DMZ могут ими воспользоваться, с помощью IP/MAC спуфинга для атак серверов внутри сети.
Ну уж от такого защититься на-а-амного проще, чем на каждое соединение городить по туннелю. Прямо на уровне порта реального или виртуального сервера. При желании и фильтрацию доступа можно там же организовать, чем, кстати, исключаются прыжки с одного сервера внутри DMZ на другой, и без головной боли с VACLами или pvlan'ами.
Подобный подход позволяет вообще не делать дырок в DMZ
Так ведь ничего особо не меняется (кроме надежности, которая очевидно падает). Туннель создает дырку, по которой будут обратные соединения. Туннелей будет много, катастрофически много.
а также защитить трафик от перехвата и модификации (ARP spoof и др MiTM-атак).
Все выпущенные где-то начиная с начала века более-менее приличные свитчи не позволят спуфить арп и делать mitm. Если правильно настроить. При наличии виртуализации и нормальных vswitch'ей всё даже проще.
Туннель строится на двух точках 1 — сервер в DMZ и 2 — сервер в внутрисети
Ок. У меня сотни серверов в DMZ и сотни серверов внутри сети. И бригада админов приложений, которые и с апачами-томкатами не всегда могут сладить, а заставить их оформить полную матрицу доступов для сервиса менее чем с третьей попытки вообще невозможно. Вы будете требовать от них поддерживать руками это нагромождение, когда иногда они забывают запустить сервис и орут про «файрвол дропает наш трафик»? Да весь бизнес после такого колом встанет.
Разрешить новому серверу мониторинга доступ к нескольким сотням серверов для вытягивания разных метрик — это надо несколько сотен новых туннелей городить? Кто этим будет заниматься? Это не поддается ручному сопровождению. В нормальном ентерпрайзе пяток разношерстных систем мониторинга точно найдется, и в любой данный момент времени что-нибудь новое наверняка будет тестироваться. Закладывать месяц на предоставление доступов?
Если сервер 1 похакан
Тут кстати тоже интересный момент. Туннель не позволит стороннему FW или IDS смотреть на обмен и видеть тревожные звоночки, к примеру — нехарактерные HTTP или SQL запросы. Обнаружить факт похаканья сервера в DMZ становится несколько сложнее. Незаметно поиметь только фронт проще, чем и фронт, и бек.
cagami
14.05.2016 09:57+1Ребята, Вы спорите об мягком и тёплом (=
у каждого из ваших примеров есть свои + и — Я с каждым из вас согласен, но применять это все нужно с умом
если у вас есть офис и конечное и статичное кол-во серверов, можно использовать
тунели для удобства it-support
если же у вас динамика в серверах (каждый день все меняется), то больше то меньше
нужно уже городить динамику(анализаторы, скрипты и прямые руки)
tbp2k5
14.05.2016 23:23Бест практики и глобальные тенденции подразумевают что сегодня практически любой коннект клиент-сервер или сервер-сервер завернут в TLS туннель (ну или как-либо иначе зашифрован). Что именно и как вы собираетесь анализировать?
navion
14.05.2016 23:32Можно расшифровать при необходимости.
tbp2k5
14.05.2016 23:57Вам не кажется что ваше «решение» хуже «проблемы»? У нас тут тоже кроме всего прочего ваш «расшифровать» стоит (тот самый за много сотен килобаксов). Были попытки пропихнуть эту функцию в продакшен… не прошло. Не буду расписывать — просто посмотрите топовые фаерволы за последний 10 лет и найдите хотя-бы один который (задним числом конечно) не оказался-бы критически дырявым — это общая проблема «черных ящиков». Нельзя своими руками ослаблять «реальную» защиту в борьбе с «гипотетическими» рисками.
navion
15.05.2016 16:09Я же написал «при необходимости», в ентерпрайзе её испытывают и готовы платить.
А баги находят везде и задача ИБ в снижении рисков, так как невозможно создать абсолютно надёжное решение.tbp2k5
16.05.2016 14:20Я надеялся что вы представите пример реалистичного сценария при котором экспозиция ключей шифрования третей стороне (= серьезное глобальное ослабление безопасности) компенсируется чем-либо другим (укрепляющим безопасность и невозможным получить другим способом (более простым и безопасным))
Безусловно оставим в стороне потребности вроде цензуры/шпионажа/контроля пользователей: такие сценарии изначально исходят из потребности ослабить безопасность до уровня допускающего внедрение «наблюдателя»…navion
17.05.2016 14:24Например, мы хотим фильтровать трафик от всякой гадости через специальную железку. Или укрепить безопасность компании внедрив DLP-систему, чтобы пользователи не кидали рабочие файлы в дропбокс.
tbp2k5
20.05.2016 23:52Ваш пример, по большому счету, опять из области «цензуры/шпионажа/контроля пользователей»: если ваши пользователи могут себе ставить «дропбокс» то они без труда себе поставят как «обходилку» вашего мониторинга так и нахватаются всякой другой малвари. Последняя кстати тоже успешно обходит все эти «специальные железки» уже не первый год банально интегрируя свой трафик в параметры тех-же GET/POST обычного веб-трафика.
Обеспечение безопасности рабочих станций надо на них и реализовывать — именно там где есть наиболее полная информация о контексте и адекватности того или иного действия пользователя. Если-бы эффективность ваших железок была-бы сколько-нибудь значимой то, я думаю, все страны уже давно бы скинулись на парочку: одна-бы уничтожила все вирусы а вторая весь спам ;-)apkotelnikov
21.05.2016 00:05Обходилки быстро и качественно ловятся и блокируются простым действием — ставим прокси и всех во внешний мир через него. На нем же обламывается малварь. А если вернемся к NGFW то сейчас они ещё по анализу того что в GET/POST положили, а также по тому какие FQDN пытается резолвить хост прекрасно детектирует зараженные малварью рабочие места.
ildarz
13.05.2016 13:42+1> Противодействие угону доменных учетных записей через mimikatz/wce…
> Против этих утилит есть меры разной степени эффективности, например, такие
К сожалению, в реальности толку от этих мер мало. Домен целиком на 2012 R2 c рабочими станциями на 8.1 и старше — явная экзотика, а все способы защиты на младших ОС подразумевают настройки на локальной машине, что, очевидно, полностью бесполезно против пользователя с правами локального админа (и вряд ли стоит рассчитывать, что человек, пользующийся mimikatz, не осилит изменение ключа реестра или запрет групповых политик). Так что по факту защита только одна — разные учетных записи для администрирования разных участков инфраструктуры.
> Обращение к SMB по именам и запрет использования NTLM
Ууу… а вот это проблема из проблем. Уж не помню, сколько раз мне хотелось придушить разработчиков всякого ПО, которые во второй декаде 21 века умеют только NTLM (некоторые ещё LDAP simple bind).navion
13.05.2016 14:17+2Домен целиком на 2012 R2 c рабочими станциями на 8.1
Они тоже не защитаят от всего:
Tufed
13.05.2016 13:53+11. «Сетевые диски как ярлыки.» — оно как бы может и хорошо и правильно с одной стороны, а с другой своевременные бэкапы справляются с этой напастью, а про них в статье забыли.
2. «Полностью изолированный гостевой WiF» поддерживаю, но и не гостевой я тоже бы изолировал. Внутри сети воздушки быть не должно (имхо), т.к. я не знаю пока невзлымываемых WIFI, а если они есть то не на долго, контролировать радиосети несравненно сложнее.Dobryak88
13.05.2016 17:12Бэкапы — средство устранения проблемы (аварии, сбоя, взлома, вируса/шифровальщика), а не средство предотвращения
navion
13.05.2016 14:43авторизация на WiFi только через WPA2-Enterprise, для того, чтобы каждый пользователь имел свои персональные, легко блокируемые учетные данные, которые контролируются централизованно
У Ruckus есть прекрасное решение с DPSK, когда устройству выдаётся персональный ключ с привязкой к MAC-адресу после самостоятельной регистрации.
По надёжности не хуже сертификатов — их всё равно можно упереть с правами админами через тот же mimikatz, а управляется из центральной панели где видно какое устройство кому принадлежит (в отличии от ADCS). Единственный минус в необходимости перерегистрации после истечения срока действия PSK, но для среды с зоопарком ОС и BYOD — это меньшее из зол.
daocrawler
13.05.2016 19:19+1Сервис https://www.ssllabs.com/ssltest/ имеет dev версию, которая прямо сейчас (в отличие от основной), например, детектит OpenSSL Padding Oracle vulnerability (CVE-2016-2107), понижая статус сервера с A+ до C.
whiplash
13.05.2016 21:34По части винды опередили меня со статьей, сам думал примерно подобное описать.
И вот еще любимая картинка:
http://3.bp.blogspot.com/-fwCJdKDZQUc/Uh8axR2QJVI/AAAAAAAAMvQ/-eEyZz1aHlE/s1600/20%20SC.png
Но, как писал arkanoid — ваш домен всё равно поломают, в первую очередь)
Alexsandr_SE
13.05.2016 22:34+1Чем плох проброс портов?
Есть ресурсы для проверки открытости сети из вне?
titulusdesiderio
14.05.2016 15:581. тоже задаюсь вопросом по поводу проброса портов
2. я не ИБшник, но для мелких проверок пользуюсь сервисом Open Port Check Tool Для чего-то более серьёзного есть специальные утилиты аля nmap
pavelsupr
14.05.2016 22:26— Плох тем, что:
1. Видно внутренние сервисы через инет. Их можно исследовать, вынимая скрытую информацию, вплоть до критическо значимой для потенциальной атаки. Их можно ломать, и, если нет изоляции типа DMZ, то привет вся внутренняя сеть, и дальнейшие атаки.
2. Без VPN с шифрованием — еще добавляется вероятность атаки типа Mitm на подключающегося во внутреннюю сеть через интернет. Тут и кражи прав доступа, и прослушка трафка, и другие прелести.
3. Если пробрасывать порт, и таким образом давать удаленный доступ, например, по RDP без VPN, вы не сможете устроить хороший разбор полетов в случае проблем. VPN же добавит в логи конкретное имя пользователя на сетевую железку, а они обычно более устойчивы к взломам, чем серверы.
— Ресурсы — google: nmap online. Можно делать самостоятельно от другого подключения к инету, но со сканом даже своего адреса надо аккуратнее, это не то, что можно легко советовать.Alexsandr_SE
14.05.2016 23:06Как внутренние сервисы видно? проброс идет только на нужный сервер и только нужного порта. В случае взлома первого фаервола, второй не окажется проблемой ибо они с высокой вероятностью будут одинаковыми, включая схожие настройки по портам. Не уверен, что вариант с двумя фаерволами в данном случае будет намного устойчивее. Тогда как мне кажется вариант для параноиков интереснее, но затратнее. Взлом сервиса по открытым портам возможен и тогда сети конечно будет хуже.
Если контора разбогатеет, то может два фаервола и возьму на заметку, но боюсь, боюсь это будет очень не скоро.
Найти бы ПО для поиска уязвимостей извне. Внутри сети и так в курсе, что все почти как швейцарский сыр.
maxzhurkin
16.05.2016 11:45Одного сервиса, в общем случае, достаточно для полного контроля хоста.
Если взломанный сервер в DMZ, взломщику доступен только этот сервер и, возможно, сеть DMZ, если же он в LAN, у взломщика праздник.
По поводу «взлома первого фаервола»: каким это вы образом делаете эту ситуацию, которая должна быть гипотетической, настолько реальной?Alexsandr_SE
16.05.2016 11:49Это все теория по поводу взлома фаервола. Хотя на некоторые судя по рассказам таки проходят любопытные. т.е. это не панацея похоже.
Запугали (точнее предупредили) статьей, теперь буду лениво думать (денег нет) где брать еще фаерволы и сетевые карты. Встроенные в материнки сетевые нагрузки не держат даже весьма средней :(
sledopit
14.05.2016 14:41Если же наоборот, администратор один, то деактивируйте sudo (особенно в том случае, если у вас по каким-то причинам сохранился вход через ssh по паролю), и для администраторских задач используйте аккаунт root.
По мне, так взаимоисключающие пункты.
Ну и конечно, классика — не работайте под рутом.
Можно как-нибудь обосновать, чем sudo не подоходит для одного администратора?
pavelsupr
14.05.2016 22:11+1Это все-таки мое личное мнение, не пытаюсь его возвести в абсолютную истину. Я рассуждал так. Предположим наличие двух наиболее частых вариантов авторизации через ssh — по сертификату, и по паролю. Во втором случае, зная только один пароль пользователя, можно получить root. С сертификатом авторизация, конечно, спасет от такого сценария. Но. Есть вариант авторизации на консоли сервера (физ. доступ, IP KVM). Тогда даже с сертификатом на ssh sudo опять даст прямой root при авторизации через консоль. Конечно я привел много условностей, пароль root можно точно так же похитить, а консоль защитить, но все-же, отдельный root это дополнительный полуфактор авторизации.
Вопрос применения sudo/чистого root для одного админа, кмк, остается на совести конкретного администратора, его привычек, опыта и оценки других факторов защиты сервера. У sudo однозначно есть свои большие плюсы, которые лучше всего себя проявят в многопользовательском сервере.
alexkbs
17.05.2016 10:55+1Это ничего что с помощью
sudoпарольrootменяется на раз-два-три? Зачем его хранить в конверте в этом случае? Зачем его вообще знать?
Про пароли у ключей не написали. Ведь ключи можно скопировать.
k3NGuru
16.05.2016 11:07Как при отключенном WPAD, можно «Запретите прямой произвольный доступ в интернет для «пользовательской» сети»?
Вручную прописывать на хостах адрес прокси сервера?
А если это ноутбук директора который уехал в командировку, а после звонит с благим матом, что у него ничего не работает, потому что забыли убрать галочку в свойствах обозревателя?
Ок, если у вас стоит TMG со своим клиентом, а если простой Squid? И его не поставить в качестве прозрачного прокси сервера на шлюз?pavelsupr
16.05.2016 12:29Атака через WPAD в общем случае возможна, когда он не настроен. Т.е. клиенты ищут прокси, а инфраструктура не предлагает сервер конфигурации. В этом случае возможно навязывание злоумышленником своего сервера. Чтобы ее предотвратить, можно либо отключить WPAD (там где прокси не было и не будет), либо настроить WPAD, для случаев, когда используется прокси.
Кстати, путешествующий за пределы офиса ноутбук из домена не самое лучшее решение для безопасности сети.
Godless
16.05.2016 14:52А как вы относитесь (я имею ввиду не только личное отношение, но и, возможно, из практики) к технологиям port knocking, web-knocking и т.п. ?
alexkbs
17.05.2016 11:08Про iptables на линуксовых серверах никто не написал, ну, значит, я напишу.
Были случаи когда всевозможные сервисы открывали порты на всех интерфейсах сразу, а не только на localhost. Да ещё и без паролей. Так, любой желающий смог бы просканировать ваш сервер на предмет известных портов и скачать всё, что ему хочется. Из последнего можно вспомнить redis.
Вывод из этого простой: закрывайте всё, кроме того, что вам явно нужно.
grossws
17.05.2016 15:27В нормальных дистрибутивах по умолчанию всё кроме ssh и icmp закрыто из коробки. Если это не так — к мейнтейнерам.
kvo
«Сам дизайн аутентификации WPA2-Enterprise это предмет отдельной статьи.» — надеюсь, она скоро выйдет? Тема очень интересная.
paulsv77
Поддерживаю. Очень интересно было бы почитать.
navion
На самом деле именно с WPA2-Enterprise всё просто, 90% занимает планирование и настройка CA для раздачи сертификатов.
maxzhurkin
Автор, IMHO, намекает, что там такое же непаханное поле для ИБ, как и в других областях.
apkotelnikov
Планирование и настройка CA? Все что введено в домен, все уже с сертификатом и делать ничего не надо. А вот с принтерами и прочим, не поддерживающим 802.1x точно придётся что то делать. И если возникнет желание (а оно возникнет)
apkotelnikov
Планирование и настройка CA — самая вершина айсберга. Гораздо больше времени потратится на решение вопросов с принтерами и теми кто так же не поддерживает 802.1x. Потом появится желание аутентифицировать не только рабочее место (это самое простое — ввели машину в домен, она тут же получила сертификат и прекрасно им аутентифицируется), но и пользователя. А заодно, в зависимости от того что за пользователь, совать его в тот или иной VLAN, а потребует пересмотр сетевой архитектуры. Потом найдется что нибудь все еще живущее под XP ( хотя сейчас уже проще с ним).
Но в любом случае не стоит преувеличивать — внедрение 802.1x не так страшно если не полениться и выпустить проект на внедрение, в начале которого просто перечислить все подключенное, а в теле по каждому типу прописать что делаем(впрочем это касается любого внедрения).
navion
Осталось выяснить причем тут 802.1x с принтерами, если разговор был в контексте беспроводной сети.
apkotelnikov
Ну хотя бы потому что в статье автора речь про 802.1x идет в разделе «Противодействие «левым» устройствам» где обсуждается вопрос о мерах защиты в проводной сети.
navion
Вот только первый комментарий в ветке про другой раздел :-)
А для 802.1x есть готовые решения, вроде Cisco ISE, но для их внедрения надо знать не меньше, чем для правильного ЦС на базе AD CS (см. комментарии).
apkotelnikov
WPA2-Enterprise одинаково применимо :-) ибо что в WiFi, что в лане один и тот же 802.1x. На заре XP приходилось на десктоп ставить Atherosовские WiFi дрова чтоб на лане появилась возможность включить 802.1x.
Что касается решений «из коробки» для аутентификации рабочих мест прекрасно работает связка MS AD + Radius + коммутатор с поддержкой 802.1x никаких «танцев с бубном» не нужно. Подняли Radius, натравили его на AD, на Radius натравили коммутатор, на рабочем месте подняли 802.1x. Если рабочее место в домене его авторизуют, нету в доме, нет авторизации. Впрочем тоже самое относится и к юзерам. Дополнительно можно присылать VLAN ID и коммутатор будет совать порт в соответствующий VLAN, но он должен быть на коммутаторе, должен быть в транке, его надо маршрутизировать. У XP была проблема связанная с тем что сначала авторизуется рабочее место, его суют в один VLAN там он получает адрес, потом приходит юзер, логингится, его перекладывают в другой VLAN и XP «забывало» еще раз получить адрес, уже в новом VLAN. Со второго (может быть и уже и с первого сервиспака проблема пофиксена).
Ну а дальше, как я уже говорил, начинается решение проблем с принтерами и прочим без поддержки 802.1x. Можно всех скопом засунуть в один Guest VLAN, как неавторизовавшихся (не очень секьюрно и есть проблемы), можно «взводить» на портах, куда оно подключено, MAC Security, но тогда при замене принтера надо еще и сетевой отдел беспокоить. В общем есть место для творчества :-)
navion
Я подумал вы про более глобальное, чтобы вести пользователя от подключения к порту до выхода в интернет. Не думаете написать статью про набивание шишек с 802.1X?
apkotelnikov
Ну в Core Network нет уже смысла применять какие либо меры, подразумевается, что порты мониторятся и подключение к ним невозможно в силу того что коммутаторы находятся в защищенном периметре (кроссовая/серверная).
Что касается шишек с 802.1x — я бы не сказал, что их там много, скорее нету вообще. Внимательное изучение документации на коммутаторы конкретного производителя дает ответы абсолютно на все вопросы. Кроме того в 802.1x, по счастью, все косяки без проблем исследуются тем же Wireshark, что обмен между коммутатором и радиусом, что обмен между хостом и коммутатором. Пошаговая инструкция, как правило, гарантия появления головной боли потом, когда рассыпется по той или иной причине и придется собирать назад.
Что касается вокруг лежащего — оно само всплывет в процессе, как те же, упомянутые мной, принтера. Сейчас специально поднял самый первый проект по внедрению аж 2005 года, актуален до сих пор, за исключением разделов про Windows 98/ME. Судя по проекту и по воспоминаниям, с ними шишек на стенде было набито не мало, 2000 и XP SP2, клиент встроенный, аутентификация по сертификатам поддерживается, работает «из коробки».