В своей сети я использую для клиентов аутентификацию eap-tls (машинные сертификаты). Эти клиенты используют прокси-сервер Squid для доступа в Интернет. Прокси-сервер регистрирует запрос в access.log. Теперь я хочу вернуться с IP-адреса в access.log к имени сертификата (CN) машины, которая запрашивает страницу, сначала перейдя с IP-адреса через журнал arpwatch на MAC-адрес, а затем используя RadAcct. файлы журнала для имени сертификата (CN) путем поиска MAC-адреса и даты.
Это целесообразно и безопасно, или это лучший вариант для отслеживания, кто где серфил?
Уязвимо ли это к атакам отравления arp, спуфингу mac / ip или другим хитрым трюкам?
Если я дополнительно использую комбинацию имени пользователя и пароля для аутентификации (например, eap-tls и peap), можно ли будет использовать пароли для обоих входов в систему (сеть и прокси)?
Изменить: в идеале я бы хотел, чтобы пользователи вводили учетные данные только один раз.
Что ж, если вы хотите, чтобы в вашем отчете был указан доступ по идентификатору машины, тогда я не вижу ничего плохого в этой идее - при условии, что у вас есть журналы с обеих сторон (и временные метки хорошие и все такое), тогда почему бы и нет. Когда вы говорите, что используете EAP-TLS, я предполагаю, что вы имеете в виду 802.1x с EAP-TLS для проводного \ беспроводного клиентского доступа.
Что касается того, уязвима ли вся эта концепция для ARP-отравления или нет - ну, ARPwatch для этого, безусловно, так что если этого недостаточно, есть другие решения. Подмена MAC-адреса должна запускать 802.1x для повторной аутентификации интерфейса - предотвращает ли это все атаки с подменой MAC-адреса или нет, я не могу сказать, но это заставит систему повторно аутентифицироваться, поэтому у вас будут журналы EAP-TLS, которые показывают ту же идентификацию машины аутентификация с разными MAC-адресами и поиск личности машины по-прежнему будут точными. На данный момент я предполагаю, что ваш механизм распространения \ регистрации сертификатов будет представлять больший риск.
Вы можете использовать одни и те же пароли для прокси и доступа к сети при условии, что вы можете указать их оба в одной и той же службе каталогов. Определенно есть много способов сделать это в зависимости от вашей платформы (платформ) - пару лет назад я создал лабораторную среду, в которой доступ к сети контролировался 802.1x с EAP-TLS + PEAP, где мы использовали учетные данные AD и имели внешний прокси, который также требует аутентификации AD, но есть ли какие-либо особые преимущества в добавлении дополнительных уровней аутентификации - это то, в чем я никогда не был уверен, лично я был бы более счастлив с более безопасным хранилищем сертификатов и полагался бы только на сертификаты. Я почти уверен, что сегодня существует еще больше возможностей для такого рода многоуровневой аутентификации.