Usando o arpwatch para fazer o backtrack do ip do acesso ao proxy para o certificado eap-tls

1

Na minha rede, estou usando a autenticação eap-tls (certificados de máquina) para clientes. Esses clientes estão usando um proxy do squid para acessar a internet. O proxy está registrando a solicitação no access.log. Agora, o que eu quero fazer é voltar atrás de um endereço IP no access.log para o nome do certificado (CN) da máquina que solicita uma página indo primeiro do endereço IP via arpwatch log para o endereço MAC e usando RadAcct registrando arquivos para o nome do certificado (CN) procurando por endereço MAC e data.

É aconselhável e seguro, ou existe uma opção melhor para rastrear quem surfou onde?

Isso é vulnerável a ataques de envenenamento por arp ou spoofing mac / ip ou a outros truques inteligentes?

Se eu também usar uma combinação de nome de usuário / senha para a autenticação (por exemplo, eap-tls & peap), seria possível usar as senhas para ambos os logons (rede e proxy)?

Edit: Idealmente, eu gostaria que os usuários tivessem que inserir as credenciais apenas uma vez.

    
por HalloDu 17.11.2010 / 21:06

1 resposta

2
Bem, se você quiser que seu relatório liste o acesso pela identidade da máquina, não vejo nada de errado com essa ideia - desde que você tenha os logs em ambos os lados (e os timestamps são bons e tudo o mais), por que não. Quando você diz que está usando o EAP-TLS, suponho que você se refere ao 802.1x com EAP-TLS para acesso de cliente com fio sem fio.

Quanto a saber se todo o conceito é vulnerável a envenenamento por ARP ou não - bem, é para isso que o ARPwatch é seguramente, por isso, se isso não for suficiente, existem outras soluções. O spoofing de MAC deve acionar o 802.1x para autenticar novamente a interface - se isso impedir ou não todos os ataques de spoofing de MAC Não posso dizer, mas isso forçará a autenticação do sistema, para que você tenha logs EAP-TLS que mostrem a mesma identidade de máquina autenticar com endereços MAC diferentes e sua pesquisa da identidade da máquina ainda será precisa. Neste momento, meu palpite é que o mecanismo de inscrição / certificado do certificado seria um risco maior.

Você pode usar as mesmas senhas para o proxy e o acesso à rede, desde que possa indicá-las no mesmo serviço de diretório. Há definitivamente muitas maneiras de fazer isso, dependendo da (s) sua (s) plataforma (s) - eu configurei um ambiente de laboratório de anos atrás, onde o acesso à rede era controlado pelo 802.1x com EAP-TLS + PEAP onde usamos credenciais do AD e O proxy externo que também exigia a autenticação do AD, mas se há algum benefício específico em adicionar as camadas de autenticação extra é algo que eu nunca estava convencido, pessoalmente eu teria ficado mais feliz com um armazenamento de certificados mais seguro e dependência de certificados. Tenho certeza de que há ainda mais opções para esse tipo de autenticação em camadas hoje.

    
por 17.11.2010 / 22:35