Três portas, em ordem

Uma porta autenticada tem três jeitos de abrir. O 802.1X autentica um dispositivo que tem suplicante, com um método escolhido pela credencial que ele porta. O MAC Authentication Bypass admite uma coisa sem suplicante, pelo endereço, contra uma lista. A autenticação web é para o caso restante, uma pessoa num dispositivo que tem navegador mas não tem suplicante configurado para esta rede: um visitante, um terceirizado num notebook pessoal, um estudante num campus. A configuração usual tenta as três nessa ordem em cada porta, e este artigo é sobre a terceira. O guia de configuração de segurança do Catalyst 9300 da Cisco descreve o recurso, conhecido como web authentication proxy, como o jeito de autenticar usuários finais em sistemas que não rodam o suplicante 802.1x.

Um intermediário operado pela rede, de propósito

O projeto é uma interceptação. A seção Device Roles do guia diz que o switch age como intermediário (proxy) entre o cliente e o servidor de autenticação, pedindo informações de identidade ao cliente, verificando-as com o servidor de autenticação e repassando uma resposta ao cliente. Os três papéis são o cliente que pede acesso, o servidor de autenticação que valida a identidade, em geral por (Remote Authentication Dial-In User Service), e o switch que controla a porta e executa a interceptação.

Antes que qualquer coisa possa ser interceptada o switch precisa notar o host. A seção Host Detection do guia lista os gatilhos numa interface de camada 2: um gatilho baseado em , que permite à autenticação web detectar hosts com endereço IP estático ou dinâmico; a inspeção dinâmica de ARP; e o , em que a autenticação web é avisada quando o switch cria um vínculo para o host. A criação da sessão então confere as listas de exceção e qualquer dispensa de autorização, e ativa a lista de acesso de interceptação HTTP para aquele host.

O login, passo a passo

A seção Authentication Process do guia é a sequência que todo hóspede de hotel conhece do outro lado. O usuário inicia uma sessão HTTP. Então o tráfego HTTP é interceptado e a autorização é iniciada, e o switch envia a página de login ao usuário. O usuário digita nome de usuário e senha, e o switch os envia ao servidor de autenticação. No sucesso, o switch baixa e ativa a política de acesso do usuário a partir do servidor de autenticação e envia uma página de sucesso; a política é o que o Access-Accept do RADIUS carregou, tipicamente uma (rede local virtual) pelos atributos de túnel ou uma lista de acesso pelo nome. Na falha, o switch envia a página de falha de login, o usuário tenta de novo e, se o número máximo de tentativas falha, o switch envia a página de login expirado e o host é colocado numa lista de observação. As quatro páginas, na seção de páginas personalizáveis do guia, são Login, em que as credenciais são pedidas; Success; Fail; e Expire, mostrada quando a sessão de login expirou por excesso de falhas. Um Local Web Authentication Banner pode carregar o texto ou um logotipo de uma organização na página de login e nas janelas de resultado, num modo legado e num modo novo.

A sessão termina do jeito que começou, com o switch observando o host. O guia diz que o switch reautentica um cliente quando o host não responde a uma sonda ARP numa interface de camada 2, ou quando o host não envia tráfego algum dentro do tempo ocioso numa interface de camada 3, e um Session-Timeout vindo do servidor RADIUS ou uma ação de término também a encerram.

Local e central

Duas formas de implantação compartilham o nome. Na autenticação web local o switch ou a controladora sem fio serve as páginas por conta própria e fala diretamente com o servidor RADIUS, que é o fluxo acima. Na autenticação web central o switch redireciona o navegador a um portal hospedado no motor de política, o motor autentica a pessoa, muitas vezes com uma conta de visitante patrocinada ou um fluxo de autocadastro, e então muda a autorização da sessão no switch, o que na prática significa um Change of Authorization do RADIUS. A autenticação web central é o produto mais rico e o que a maioria dos sistemas de visitantes usa; é também aquele a que se refere o limite da próxima seção, porque depende de redirecionar a primeira requisição.

O limite que está quebrando a interceptação

O guia o declara numa frase: a interceptação de tráfego HTTPS para redirecionamento de autenticação web central não é suportada. Um navegador cuja primeira requisição é a um site HTTPS não pode ser redirecionado a uma página de login sem que se apresente um certificado para um nome que a rede não possui, o que todo navegador hoje recusa com um aviso; e a primeira requisição da maioria dos navegadores é HTTPS. O mesmo vale para aplicativos que fixam seus certificados e para clientes usando DNS cifrado. A interceptação que fez a autenticação web funcionar por vinte anos está sendo fechada como um ataque, porque é indistinguível de um. O verbete portal cativo deste site descreve a experiência do usuário nesse declínio; a consequência de projeto é que um portal interceptador só pega com confiabilidade um navegador que ainda faz uma requisição HTTP simples, e é por isso que os sistemas operacionais passaram a fazer uma de propósito, uma sonda a um endereço conhecido, para detectar a situação.

A substituição: avisar o dispositivo, não enganá-lo

A resposta do foi fazer do portal algo que a rede anuncia. A 8952, Captive Portal Architecture, publicada em novembro de 2020 por Larose, Dolson e Liu, descreve cinco componentes: o equipamento do usuário, um serviço de provisionamento, um servidor da API do portal cativo, um dispositivo de imposição e um sinal de portal cativo. O serviço de provisionamento avisa ao dispositivo, quando ele entra na rede, onde está a API do portal; o dispositivo pergunta à API se está cativo e aonde ir para ser liberado; o dispositivo de imposição, o switch ou a controladora, segura a sessão até que a API diga que está aberta. A arquitetura estabelece uma regra que encerra o truque antigo: as soluções não devem exigir a falsificação de respostas de servidores DNS ou HTTP. Ela é igualmente clara sobre o escopo: não descreve como um dispositivo negocia acesso irrestrito, só como ele fica sabendo que precisa.

A RFC 8910, Captive-Portal Identification in DHCP and Router Advertisements, publicada em setembro de 2020 por Kumari e Kline, dá ao serviço de provisionamento seu veículo. A opção 114 do DHCPv4, a opção 103 do e a opção 37 do anúncio de roteador IPv6 carregam uma URI, e a RFC exige que ela seja o ponto de acesso da API de portal cativo definida por sua companheira RFC 8908. O documento substitui uma RFC 7710 anterior que usava a opção 160 do DHCPv4, depreciada porque dispositivos em campo se comportaram mal com ela. Um sistema operacional que implementa a RFC 8910 fica sabendo do portal no momento em que recebe um endereço, abre o portal numa visualização isolada e não precisa de interceptação alguma. Redes que fornecem a opção e mantêm um portal interceptador para clientes antigos levam as duas populações pela porta.

O que devolver, e o que manter separado

A identidade que um portal estabelece é a de uma pessoa, em geral um visitante, e a autorização que se segue deveria ser a de um visitante: uma VLAN ou um filtro que alcança a Internet e nada interno, um tempo de sessão que expira com a visita e nenhum acesso ao diretório que a autenticou. Onde o portal autentica funcionários em dispositivos não gerenciados, a mesma regra vale com mais força, já que o dispositivo mostrou estar fora da gestão. Os registros de contabilização Start e Stop das sessões autenticadas por web carregam o nome de usuário e o identificador de estação como qualquer outra sessão RADIUS, e são o registro de quem estava na rede de visitantes e quando, que é a pergunta que se faz a um local de eventos depois de um incidente.

Onde se encaixa

A ordem na porta é o resumo. 802.1X primeiro, porque autentica o dispositivo com uma credencial e deriva chaves para o enlace; MAC Authentication Bypass em seguida, para as coisas numa lista, com autorização restrita; autenticação web por último, para as pessoas em dispositivos que não fazem nem um nem outro, com a autorização de um visitante e, cada vez mais, a opção da RFC 8910 anunciada para que dispositivos modernos encontrem o portal sem serem enganados. O artigo sobre 802.1X cobre as duas primeiras portas e o artigo sobre o RADIUS o lado do servidor das três.

Fontes