По каким критериям может проводить аутентификацию и авторизацию 802.1x

Давайте для начала вспомним базу, чтобы не путаться в понятиях.

Аутентификация - проверка подлинности пользователя, процесса или устройства, направленная на подтверждение их права доступа к определённым ресурсам или данным.
То есть, user1 подтверждает, что это он, тем, что ввел пароль, и, возможно, еще какой-то фактор (SMS, токен, и т.п.).

Авторизация - проверка прав пользователя на осуществление определённых действий, получение определенного уровня доступа.
Здесь user1, пройдя аутентификацию, получает необходимый уровень доступа (права в систему/приложение, ACL для сетевого доступа, и т.п.).

802.1x может выполнять проверку подключаемого устройства по таким параметрам:

1. MAC-адрес сетевой карты.
Ими относительно легко управлять, вероятность сбоя процесса аутентификации из-за особенностей операционной системы минимальная, но и подделать MAC совсем не сложно.

2. Сертификат.
Все хорошо: и подделать сложно, и криптозащита обеспечивается, и идентификатор отлит в граните, блокировка доступа через revocation list. Но в больших инфраструктурах с приоритетом доступности перед безопасностью процесс управления жизненным циклом сертификатов может стать камнем преткновения, если не предусмотреть возможность оперативного автоматизированного продления сертификатов легитимных устройств без лишнего участия пользователей. Да и выдернуть сертификат из хранилища вместе с закрытым ключом - тоже вполне подъемная задача, если ключ не на смарт-карте или токене.

3. Машинная учетная запись.
При включении(join) в домен AD создается учетная запись устройства, которую можно использовать как идентификатор для 802.1x. Практически не требует дополнительных телодвижений от ИБ, сетевиков и техподдержки рабочих мест, рождается и умирает вместе с вводом и выводом из домена. Но если ноутбук вывалился из домена по давности (не подключался в сеть организации), то при подключении заново придется звать человека с правами на join. В целом, не самое страшное последствие.

4. Учетная запись пользователя.
Выглядит, как будто еще лучше, чем машинная учетная запись, потому что все права нарезаются для пользователя независимо от того, на каком ПК/ноутбуке он работает. Но пользователь может тогда принести и личный ПК, на котором непонятно, как с безопасностью (802.1x не проверяет и не отслеживает уровень безопасности системы). А когда пользователь подключается с корпоративного устройства, то оно сначала попадает в неавторизованный сегмент, и только после ввода логина-пароля может авторизоваться на порту. Но вот ведь незадача: необходимо инициировать реаутентификацию на порту, а по умолчанию этого не происходит, и залогиненный юзер страдает от несправедливости. Соответственно, необходимо предусмотреть сценарий повторной авторизации после успешной аутентификации.

5. CDP bypass.
На коммутаторах Cisco для подключения IP-телефонов Cisco реализован механизм: если оно умеет CDP как телефон, значит, это телефон из своей экосистемы. А ворон ворону глаз не выклюет. Но это касается только попадания в voice VLAN. Злоумышленнику нужно будет имитировать поведение телефона, чтобы его пустило в сеть.

Теперь у вас есть, из чего выбрать.

Давайте рассмотрим, из каких основных компонентов состоит технология доступа в сеть по протоколу 802.1x

1. Подключаемое в сеть устройство (ПК, ноутбук).
На схемах обозначено как Supplicant, подразумевая, что на нем установлен клиент, передающий аутентификационные данные (машинная/пользовательская учётная запись, сертификат) на RADIUS-сервер. Суппликант может быть как встроенным в операционную систему, так и отдельным агентом. На нем настраивается, какие именно атрибуты отправляются на RADIUS. Настройка может быть организована централизованно либо сразу из золотого образа (шаблона), либо через политики AD. Если суппликант не установлен, в дело вступает коммутатор.

2. Коммутатор (свич) с поддержкой 802.1x.
Обозначается как Network Access Server, потому что на нем реализуются политики доступа в сеть подключаемого устройства. Но приходят они с RADIUS-сервера в виде пар Attribute-Value (AV-pairs) в результате авторизации. Есть 2 основных вида реализации доступа в сеть:

- порты доступа не пускают никого никуда, обрабатывая только EAP-запросы и CDP (помним, что ворон ворону...). После аутентификации и авторизации свич получает от RADIUS AV-пары на порт свича в виде VLAN ID либо VLAN name, и дальше ПК получает IP-адрес в соответствующей подсети от DHCP-сервера.
Если устройство не аутентифицировано - либо попадает в специальный non-auth VLAN, либо так и продолжает страдать без какого-либо доступа, автоконфигурируясь с IP-адресом 169.254.x.y (IPv4 для Windows) либо с единственным адресом fe80...(IPv6). В терминологии Cisco это называется strict mode, можете почитать дополнительно.

- порты доступа уже живут в определенном VLAN, но доступа никуда нет. После аутентификации и авторизации свич получает от RADIUS AV-пары на порт свича в виде набора строк downloadable ACL (dACL), которые определяют, куда ему можно ходить. В терминологии Cisco это low impact mode. Но будьте осторожны с наполнением ACL: он не рефлексивный (не запоминает установленную сессию), приезжает на каждый порт свича, и суммарное количество строк в памяти свича пропорционально еще и количеству его портов. Если переборщить - можно поймать печаль от переполнения памяти, и тогда impact будет совсем не low.

3. RADIUS-сервер.
На нем и вершится судьба подключаемых устройств, также ведется учет (accounting). Можно настроить выдачу разных наборов AV-пар в зависимости от свича, локации, типа учетных данных, и многого другого. RADIUS может как хранить на борту учетные данные, так и обращаться за ними в AD/LDAP либо другой RADIUS (тогда первый в цепочке является RADIUS-proxy).

А теперь вопрос для самоконтроля усвояемости материала: какая из вышеописанных схем подойдет для авторизации по учетным записям пользователей без специфического суппликанта?

ИБ-оксюморон.

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

Живите теперь с этим.

Плохие новости, пацаны.

Алгоритмы генерации контекстной рекламы научились определять приближение кризиса среднего возраста.

Машины становятся все умнее 🤔 и нам надо держать их в узде, чтобы знали, кто в доме папа.

Интересно комментируют новость о том, что ВСК оказалась не готова к кибератаке, хотя и занимается киберстрахованием.

А теперь давайте честно, граждане ИБшники.
Вот вы лично разве никогда не пренебрегали теми самыми правилами, к которым приучаете остальных?
Прям всегда файл перед открытием проверяете антивирусом, да еще и через песочницу прогоняете?
Средства защиты, которые производите, прям всегда в ногу с патчами используемых операционных систем идут и обновляются не более, чем через 2 недели?

Таких вопросов можно задать еще много.

Я помню время, когда IDS от ISS SiteProtector был в программном исполнении, устанавливался на WinXP, но категорически не дружил с Service Pack 2 и 3. А это во времена распространения Conficker/Kido. И не особо спешил ISS что-то с этим делать. Им было некогда, они продавались IBM'у. Или как раз продались, точно не помню. Плюс компания взяла тогда курс на ПАКи, заморозив агентские решения, и несекурность своего софтового IDS использовала для апсейла апплаенсов. По крайней мере, так мне виделось со стороны заказчика. Нам тогда пришлось навешивать port ACL на свич для защиты интерфейса управления.

А что тогда вы хотите от страховика, который киберстрахование рассматривает исключительно как одно из направлений страхового бизнеса, на случай ситуации, которая произойдёт с кем-то еще, а не с тобой? Конечно, внутренняя готовность непрофильной компании к подобным ситуациям сильно зависит от CISO и желания руководства выделять ресурсы на обеспечение ИБ, но есть немало примеров, когда вполне технологичная компания получала подобный нежданчик.

Из плюсов: как правило, после такого инцидента у себя либо соседа работа по повышению безопасности кратно возрастает, как и готовность руководства выделять ресурсы.

Как говорят, за одного битого двух небитых дают.

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

В итоге, хвалим ИБшников, или укоризненно покачаем головой?

👍 - хвалим
🤔 - качаем головой
🔥 - чем больше мошеннических объявлений в теневом пробиве, тем быстрее снизится спрос
😁 - да там разница в доли процента, считай, плановая индексация тёмной стороны

Интересное наблюдение описано в статье на securitylab: мошенники постепенно переключаются с пенсионеров на студентов, которые:

- уже разобрались в технологиях, но не всегда способны отличить предложение легитимной работы от мошенничества

- внушаемы и склонны к импульсивным решениям

- готовы вписаться в любой блудняк за компанию, если это считается круто

Почитайте, там довольно подробный разбор и рекомендации, как определить волка в овечьей шкуре.

И обязательно передайте своим детям-студентам, либо младшим товарищам.

Вспомните себя в их годы, и трезво оцените, насколько реально вам было бы устоять против таких методов, если бы за вас взялись целенаправленно. А они еще этого не осознают.

Сегодня, 30 ноября, кроме дня защиты информации, в России отмечается ещё и день матери (последнее воскресенье ноября).

Господа ИБшники, все поздравили своих мам?

Кто забыл - хоть сообщение напишите, если звонить уже поздно, а мама поймет вашу занятость.

В тему open source и вендорских решений вспомнилась одна история.

Некоторое время назад у моего автомобиля начал заедать замок к багажнику. То работает, то нет. После диагностики в сервисном центре сказали, что нужно менять замок, стоимость в районе 20-25 тысяч. Внутренний жлоб посоветовал мне перед тем, как платить, посоветоваться с соседом, который электрик, и очень хорошо разбирается в автоэлектрике. Нашли время, сняли всю обшивку изнутри багажника, разобрали замок, нашли слабое звено. Им оказался моторчик, который открывал замок, оттягивая защелку на пружинке при нажатии кнопки. Его заклинивало от загрязнения, но при попытке почистить, как водится, мы его окончательно добили.

- Закажи такой моторчик, он недорогой, потом вместе поставим.
- Сколько возьмешь с меня за ремонт?
- Да забей ты. Моторчик будешь заказывать - мне тоже закажи такой, у дочки на машине та же болячка.

Заказал моторчик (1300р), потом нашли время опять, поставили его на место и собрали всю конструкцию заново. Лишних деталей не осталось.

Развилка.

Вендорское решение (замена замка на сервисе):
- записываешься в удобное время
- всю работу делают работники
- детали заказывают работники
- пользуешься результатом
- платишь 20-25 тыр
- ни грамма не понимаешь, как оно все устроено

Open source (замена моторчика с соседом):
- очень зависит от надёжного community (сосед, который разбирается и готов помочь)
- требует гораздо больше времени, чтобы состыковаться с соседом 2 раза
- в промежутках ездишь с багажником, который открывается на веревочке изнутри салона, и ничего серьёзного в него не положишь
- полностью управляешь ценообразованием и результатом
- начинаешь понимать, как оно внутри устроено
- готов поддерживать это опять самостоятельно либо с помощью community (соседа)
- стоимость 2600 (по моторчику себе и соседу)

Что выбираете?

Противодействие горизонтальному перемещению (lateral movement) злоумышленника в одной подсети.

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

Какие могут быть механизмы ограничения горизонтального перемещения внутри одной подсети/VLAN:

1. Host-based firewall. 
Зачастую входит в состав EDR-агента/антивируса. Как правило, управление правилами выполняется централизованно с сервера управления AV/EDR. Функционирование и возможность отключения зависит от особенностей самого софта и операционной системы, на которой он установлен.

2. Port ACL на коммутаторах(свичах).
Работает по аналогии ACL на маршрутизаторах, но применяется к L2-портам свича. Поддерживается не всеми производителями и прошивками. Уже не зависит от софта и хостовой ОС, не получится отключить с помощью уязвимостей на них, но система управления из коробки не предоставляется. Придется раскошелиться, либо своими силами организовать централизованное управление и шаблонирование, иначе замучаетесь управлять и траблшутить. Учтите, что коммутатор имеет ограничения памяти, и бурный рост количества строк на каждом порту съедает ее лавинообразно, рискуя создать проблемы в сети.

3. Downloadable ACL. 
По сути, тот же port ACL, только приезжает на порт со стороны RADIUS-сервера после аутентификации и авторизации по 802.1x. В отличие от port ACL, централизованное управление идет из коробки, которой является RADIUS. Но работает только на 802.1x-enabled интерфейсах, и подключаемые к ним устройства должны аутентифицироваться по MAC/certificate/machine_account/user_account. Подробнее я об этом писал ранее. Риск исчерпания памяти аналогичен port ACL.

4. Switchport protected. 
Одна строчка в конфигурации порта - и взаимодействие подключенного хоста с устройствами того же VLAN на том же свиче отключается полностью, по всем портам и протоколам. Но работает это ограничение только в рамках одного коммутатора.

5. Private VLAN. 
Механизм похож на switchport protected, но имеет более комплексные настройки, вариативность в ограничениях, требует выделения VLAN. Работает в пределах всего VLAN, не ограничиваясь одним устройством.

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

Было?

👍 - было
😁 - ну, было пару раз
🤔 - как так можно, это ж нельзя
😎 - было, есть и будет (я сетевик)

Опубликовали презентации с конференции "Сетевая безопасность". Разглядываю их на досуге.
Привожу интересный слайд. Чем интересен - отмечено:

- термином "регуляторный иммунитет"

- тем, что таки называют IPS IPS'ом, не пытаясь использовать новые термины современного ИБ-маркетинга

Фраза дня, подслушанная на конференции AM Live:

Специалистов по инфобезу никогда не заменят искусственным интеллектом, потому что тогда будет наказать и посадить некого

Выдыхаем, пацаны.

Регуляторный иммунитет.

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

Тогда получается, что их можно запугать только регулятором. Хакеры-то эфемерные, сделают что-то или нет - вопрос. А регулятор тут, рядом, может и оштрафовать, и деятельность компании приостановить, и даже посадить в особо запущенных случаях.

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

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

Главное - чтобы ниже нуля не получилось, а такое тоже может быть.

Интересные результаты опроса показали вчера на онлайн-мероприятии AM Live "Развитие экосистем кибербезопасности".

Почему-то участники дискуссии не озвучили вывод, который у меня напрашивается сам собой:

За прошедший год заказчики разочаровались в экосистемах кибербезопасности.

Я это понял по сумме процентов ответов, начинающихся на "да, если":

2024 - 58%
2025 - 42%

То есть, разницу не спишешь на погрешность.

Правда, участники как раз были из тех, кто эти экосистемы создает, поэтому не удивительно, что такой вывод не озвучивался.

Это значит, что над текущими экосистемами кибербезопасности еще предстоит хорошо поработать, чтобы они действительно помогли заказчику:

- имели необходимые компоненты для эшелонированной защиты
- снизили порог входа
- сэкономили бюджет
- улучшили измеримые параметры уровня безопасности

Тогда через год маятник качнется в обратную сторону.

Вышел очередной рейтинг ИБ-каналов, ссылку на него можно найти в канале Sachok.

Мой канал попал в этот рейтинг, получив второе место в категории "микроблоги". Меня заинтересовало, почему же категория именно такая, а не "авторские". Я загуглил разницу, и все равно не понял.

Вот такое выдает противоестественный интеллект Яндекса:

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

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

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

Возможно, и был период, когда канал можно было назвать микроблогом, но мне сейчас порой не хватает времени набрать текст за время поездки в метро на работу или с работы (45 минут).

В целом, вопрос классификации не особо критичен, но телеграм-каналы создают те, кто склонен к текстовому эксгибиционизму, поэтому вам пришлось и эти размышления прочитать в довесок к остальным.

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

1. Разные NGFW на стыке с интернет и выполняющие внутреннюю сегментацию

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

Обратите внимание на картинку. Я предложил сегменты DMZ1 и DMZ2 приземлить на пограничный NGFW, но это на ваше усмотрение. Более того, если ресурсы из этих DMZ критичны для внутренних сегментов (так не должно быть, на то и DMZ, но мало ли), то лучше их приземлить на внутренний NGFW, а пограничный оставить двуногим. Тогда в случае его падения из-за DDoS потеряется только связь с интернетом. Неприятно, но хоть не парализует работу внутри.

А вы каким бы оставили пограничный МСЭ?
👍 - так, как на картинке
🤔 - двуногим

#NGFW #DDoS

Продолжаем рекомендации по подготовке своего внешнего периметра к отражению DDoS-атак.

2. Разделите сегменты по направлению трафика в/из интернет.

Например:
- MX домена и smarthost
- DMZ-сервера и точки выхода в интернет (NAT-pool, proxy)
- Авторитативный и рекурсивный DNS

должны быть на разных IP-адресах или даже в разных подсетях, чтобы можно было применять к ним правила на центрах очистки от DDoS.

Почему так.

В общем случае TCP-сессия между клиентом и, например, web-сервером, строится в 3 хода (тройное рукопожатие):

SYN (client IP, src port >1024 —> server IP, dst port 80)

SYN/ACK (server IP, src port 80 —> client IP, dst port >1024)

ACK (client IP, src port >1024 —> server IP, dst port 80)

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

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

Соответственно, если в сети находятся только сервера - можно запретить пакеты SYN/ACK полностью. Таким образом защитив ресурсы от SYN/ACK-флуда на 100% и абсолютно не нарушив работу сервиса. Но только в том случае, если сервер сам не инициирует подключение к интернет-ресурсам, превращаясь в клиента.

Аналогично для тех, кто по жизни клиент, можно без вреда запретить чистые SYN- и чистые ACK-пакеты, защитив их от DDoS-атак типа TCP SYN flood и TCP ACK flood на 100%. Но это если на них нет опубликованных сервисов.

Поэтому разделить их и сообщить об этом своему провайдеру защиты от DDoS будет очень разумным решением.

Конечно, можно не разделять, и постоянно составлять исключения для разных ресурсов, но вы очень быстро замучаетесь управлять актуальным состоянием политик защиты.

Так что, разделяй и властвуй.

Ну как, получается следовать?

👍 - разделяю и властвую
😎 - разгильдяй и господствую над хаосом
🤔 - я только спросить

#DDoS