Используя arpwatch для отслеживания в обратном порядке IP доступа прокси к eap-tls сертификату

Необходимо использовать базирующийся виртуальный хостинг имени, Он определяет сайты, с помощью заголовка Хоста, определенного в спецификации HTTP/1.1. Пример confing

 NameVirtualHost *:80 
<VirtualHost *:80>
   ServerName www.example.com 
   DocumentRoot D:\example.com
</VirtualHost>
<VirtualHost *:80>
  ServerName example.example.com 
  DocumentRoot D:\example.com\example
</VirtualHost>
1
задан 18 November 2010 в 00:10
1 ответ

Хорошо, если Вы хотите, чтобы Ваше создание отчетов перечислило доступ идентификационными данными машины затем, я не вижу ничто плохого с той идеей - если у Вас есть журналы с обеих сторон (и метки времени хороши и все это), затем, почему нет. Когда Вы говорите использование EAP-TLS я предполагаю, что Вы имеете в виду 802.1x с EAP-TLS для wired\wireless клиентского доступа.

Относительно того, уязвимо ли целое понятие для отравления ARP или не - хорошо, это - то, для чего ARPwatch, конечно, поэтому, если это не достаточно затем существуют другие решения. Спуфинг MAC должен инициировать 802.1x для переаутентификации интерфейса - предотвращает ли это все нападения спуфинга MAC, или не я не могу сказать, но он вынудит систему повторно пройти проверку подлинности так, у Вас будут журналы EAP-TLS, которые показывают те же идентификационные данные машины, проходящие проверку подлинности с различными MAC-адресами, и Ваш поиск идентификационных данных машины все еще будет точен. В этой точке мое предположение - то, что Ваш сертификат distribution\enrollment механизм был бы большим риском.

Можно использовать те же пароли для и доступа к сети прокси, если можно указать на них обоих на ту же службу каталогов. Существует определенно много способов сделать это в зависимости от Вашей платформы (платформ) - я настроил лабораторную среду acouple несколько лет назад, где доступом к сети управляли 802.1x с EAP-TLS + PEAP, где мы использовали AD учетные данные и имели внешний прокси, который также потребовал AD аутентификации, но существует ли какое-либо конкретное преимущество в добавлении, что дополнительные слои аутентификации - что-то, о чем я никогда не убеждался, лично я буду более доволен более безопасным хранилищем сертификатов и уверенностью в одних только сертификатах. Я вполне уверен существует еще больше опций для этого вида многоуровневой аутентификации сегодня.

2
ответ дан 3 December 2019 в 22:21
  • 1
    это - то, на что я надеялся. Я планирую использовать openldap службу каталогов для аутентификации в моем домене самбы для прокси и peap, но что я хотел знать, если пользователь должен ввести свой пароль и для wlan и для прокси или если можно объединить это так или иначе. –  HalloDu 18 November 2010 в 00:07

Теги

Похожие вопросы