OpenNDS: um Captive Portal OpenSource - Como Funciona?

O openNDS (Open Network Demarcation Service) é um Captive Portal de alto desempenho e tamanho reduzido.

Esse post é baseado no post original do OpenWrt.

O que é um Captive Portal?

Um Captive Portal é uma técnica de segurança usada em redes Wi-Fi públicas ou privadas, onde o acesso à internet é bloqueado até que o usuário se autentique ou aceite os termos de uso. Normalmente, ao conectar-se à rede, o dispositivo do usuário é redirecionado automaticamente para uma página de login, que pode exigir informações como um nome de usuário e senha ou a aceitação de políticas de uso. Esse processo é comum em cafés, hotéis, aeroportos e outros locais que oferecem Wi-Fi gratuito, garantindo o controle de acesso e a conformidade com as regras da rede.

Temos dois termos/palavras comumente usados que merecem uma definição, uma explicação seus significados:

cativo ou captive: referente ao Captive Portal, “cativo” é o usuário que está “preso” ou “cativo” à rede até que realize a autenticação ou aceite os termos de uso.
tela splash: é a página de captura que o usuário vê ao tentar acessar a internet, onde ele deve interagir, geralmente com um login ou aceitação, para ser liberado e acessar a rede.

Documentação do OpenNDS

Segue link de documentação do OpenNDS: https://opennds.readthedocs.io

Como o OpenNDS (NDS) funciona?

Qualquer Portal Cativo (captive portal), incluindo NDS, terá dois componentes principais:

Algo que faça a captura
Algo para fornecer um Portal para que os usuários do cliente façam login.

Um roteador sem fio normalmente executa o OpenWrt ou alguma outra distribuição Linux. Ainda, um roteador, por definição, terá duas ou mais interfaces de rede, pelo menos uma para se conectar à rede de longa distância (WAN) ou ao feed da Internet, e pelo menos uma para se conectar à rede local (LAN).

Cada interface LAN também deve atuar como o Gateway IP Padrão para sua LAN, idealmente com a interface servindo endereços IP para dispositivos clientes usando DHCP.

Várias interfaces LAN podem ser combinadas em uma única interface de ponte(bridge). Por exemplo, redes ethernet, 2.4Ghz e 5Ghz são tipicamente combinadas em uma única interface de ponte. Nomes de interface lógica serão atribuídos como eth0, wlan0, wlan1 etc. com a interface de ponte combinada nomeada como br-lan.

O NDS gerenciará um ou mais deles. Isso normalmente será br-lan, a ponte para a LAN sem fio e com fio, mas pode ser, por exemplo, wlan0 se você quiser que o NDS funcione apenas na interface sem fio.

Resumo da Operação do OpenNDS

Por padrão, o NDS bloqueia tudo.

Um cliente descobrirá que está em um estado capturado por um dos dois métodos básicos. Vamos falar sobre esses dois modos logo a seguir:

Método 01: Captive Portal Detection (CPD)

CPD é um processo orientado ao cliente disponível em todos os dispositivos móveis modernos, na maioria dos sistemas operacionais de desktop e na maioria dos navegadores. O processo CPD emite automaticamente uma solicitação de porta 80 na conexão a uma rede como um meio de sondar um estado cativo.

Às vezes conhecido como “teste canário”, esse processo, conduzido pelo cliente, evoluiu ao longo de vários anos para se tornar um padrão confiável de fato. O openNDS detecta essa sondagem e serve uma sequência especial de página da web “splash” para o dispositivo cliente conectado.

Método 02: Identificação de Portal Cativo (CPI) ou, em inglês, Captive Portal Identification (CPI)

Observação: muito poucos dispositivos cliente oferecem suporte a CPI no momento da redação deste artigo (novembro de 2021)

Atualização: A maioria dos novos dispositivos agora suporta CPI pelo menos até certo ponto, indicando uma provável adoção da curva “S”. (Janeiro de 2023).

CPI é um processo controlado por Gateway conforme definido nos padrões RFC8910 (Captive-Portal Identification in DHCP and Router Advertisements) e RFC8908 (Captive Portal API). Um roteador de gateway informa a um cliente conectado que ele está em um estado cativo, fornecendo uma URL na qual um cliente pode acessar para autenticação. Um cliente pode acessar essa URL para receber a mesma sequência de páginas “splash” do portal que receberia no método CPD tradicional.

Como alternativa, um cliente pode usar essa URL para acessar a API do Captive Portal RFC8908, recebendo uma sequência de página inicial para autenticação.

A partir do openNDS v9.5.0, o método CPI é suportado em ambas as formas e habilitado por padrão. Ele pode ser desabilitado em uma opção de configuração.

Sobre o Portal

O navegador do cliente é redirecionado para o componente Portal. Este é um serviço web que é configurado para saber como se comunicar com o mecanismo central do NDS. Isso é comumente conhecido como “Splash Page”.

O NDS tem seu próprio servidor web integrado e é usado nos modos básicos de operação para servir as páginas “Splash” do Portal para o navegador do cliente. Como alternativa, um servidor web separado pode ser usado.

O NDS vem com várias opções de Splash Page padrão

Uma sequência trivial de página inicial “Clique para Continuar” (configuração padrão)
Um formulário de Usuário Cliente que requer que Nome e Endereço de E-mail sejam inseridos.
Sequências de páginas temáticas definíveis pelo administrador, suportando conteúdo remoto opcional

Uma única opção de configuração uci é usada para escolher a sequência de página inicial padrão para login do cliente.

Para as páginas simples “Clique para continuar”:

 option login_option_enabled '1'

Para as páginas “nome de usuário/e-mail”:

option login_option_enabled '2'

Para páginas Themespec definidas pelo administrador:

option login_option_enabled '3'

As opções padrão da página inicial podem ser personalizadas ou um Portal especializado completo pode ser escrito pelo instalador (consulte ThemeSpec, FAS, PreAuth na documentação no site OpenWrt).

FAS(Forward Authentication Service) ou Serviço de Autenticação de Encaminhamento

O AS, ou Forward Authentication Service, pode usar o servidor web incorporado no NDS, um servidor web separado instalado no roteador NDS, um servidor web residente na rede local ou um servidor web hospedado na Internet.

O usuário do dispositivo cliente sempre deverá concluir algumas ações na página inicial ou no portal cativo. Depois que o usuário no dispositivo cliente tiver concluído com sucesso as ações da página inicial, essa página será vinculada diretamente de volta ao NDS.

Por segurança, o NDS espera receber um token, com hash, usando uma chave pré-compartilhada. Se esse token com hash for válido, o NDS então “autentica” o dispositivo cliente, permitindo o acesso à Internet.

Extensões de processamento de pós-autenticação podem ser adicionadas ao NDS (veja BinAuth na documentação). Uma vez que o NDS tenha recebido o token válido, ele irá, se habilitado, chamar um script BinAuth. O processamento de pós-autenticação do BinAuth é usado com mais frequência para fornecer um mecanismo para gerar logs de acesso de clientes locais.

O Binauth pode substituir o FAS e negar acesso ou substituir cotas e restrições de taxa de dados que podem ser definidas pelo FAS ou globalmente na configuração.

Se o FAS Secure estiver habilitado (Níveis 1 (padrão), 2 e 3), o token de autenticação do cliente será mantido em segredo o tempo todo. Em vez disso, o faskey é usado para gerar um valor de id com hash (hid) e este é enviado pelo openNDS para o FAS. O FAS deve então, por sua vez, gerar um novo id de hash de retorno (rhid) para retornar ao openNDS em sua solicitação de autenticação.

Se definido como “0”, o FAS é imposto pelo NDS para usar o protocolo http.

O token do cliente é enviado ao FAS em texto simples na sequência de consulta do redirecionamento, juntamente com authaction e redir. Este método é fácil de ignorar e útil apenas para os sistemas mais simples, onde a segurança não importa.

Se definido como “1”, o FAS é imposto pelo NDS para usar o protocolo http.

Uma string de consulta codificada em base64 contendo o hid é enviada ao FAS, junto com os parâmetros e variáveis clientip, clientmac, gatewayname, client_hid, gatewayaddress, authdir, originurl, clientif e custom.

Caso o utilitário sha256sum não esteja disponível, o openNDS será encerrado com uma mensagem de erro na inicialização.

Se definido como “2”, o FAS é forçado pelo NDS a usar o protocolo http.

clientip, clientmac, gatewayname, client_hid, gatewayaddress, authdir, originurl e clientif são criptografados usando faskey e passados para o FAS na string de consulta.

A sequência de consulta também conterá um vetor de inicialização gerado aleatoriamente para ser usado pelo FAS para descriptografia.

A cifra utilizada é “AES-256-CBC”.

O pacote “php-cli” e o módulo “php-openssl” devem ser instalados para o nível 2 do fas_secure.

O openNDS não depende deste pacote e módulo, mas sairá normalmente se este pacote e módulo não estiverem instalados quando este nível for definido.

O FAS deve usar o vetor de inicialização passado pela string de consulta e a fas_key pré-compartilhada para descriptografar a string de consulta. Um script php FAS nível 2 de exemplo (fas-aes.php) é armazenado no diretório /etc/opennds e também fornecido no código-fonte. Ele deve ser copiado para a raiz da web de um servidor web adequado para uso.

Se definido como “3”, o FAS é imposto pelo openNDS para usar o protocolo https.

O nível 3 é o mesmo que o nível 2, exceto que o uso do protocolo https é imposto para o FAS. Além disso, o daemon “authmon” é carregado. Isso permite que o FAS externo, após a verificação do cliente, atravesse efetivamente os firewalls de entrada e a tradução de endereços para obter a autenticação NDS sem gerar avisos ou erros de segurança do navegador. Um script php FAS nível 3 de exemplo (fas-aes-https.php) é pré-instalado no diretório /etc/opennds e também fornecido no código-fonte. Ele deve ser copiado para a raiz da web de um servidor web adequado para uso.

A opção faskey tem um valor padrão. É recomendado que isso seja definido como algum valor secreto no arquivo de configuração e o script FAS definido para usar um valor correspondente, ou seja, faskey deve ser pré-compartilhado com FAS.

Observações sobre detecção de portal cativo (CPD)

Todos os dispositivos móveis modernos, a maioria dos sistemas operacionais de desktop e a maioria dos navegadores agora têm um processo CPD que emite automaticamente uma solicitação de porta 80 na conexão a uma rede. O NDS detecta isso e serve uma página web especial “splash” para o dispositivo cliente de conexão.

A solicitação HTML da porta 80 feita pelo cliente CPD pode ser uma das muitas URLs específicas do fornecedor.

Os URLs de CPD típicos usados são, por exemplo:

É importante lembrar que o CPD foi projetado principalmente para dispositivos móveis para detectar automaticamente a presença de um portal e acionar a página de login, sem precisar recorrer à quebra de segurança SSL/TLS, exigindo que o portal redirecione a porta 443, por exemplo.

Quase todas as implementações atuais de CPD funcionam muito bem, mas alguns compromissos são necessários dependendo da aplicação.

A grande maioria dos dispositivos anexados a um Captive Portal típico são dispositivos móveis. O CPD funciona bem, fornecendo a página de login inicial.

Em um Wi-Fi típico para visitantes, por exemplo, uma cafeteria, bar, clube, hotel etc., um dispositivo se conecta, a Internet é acessada por um tempo e, então, o usuário tira o dispositivo do alcance. Quando colocado fora de alcance, um dispositivo móvel típico começa a pesquisar periodicamente o espectro sem fio em busca de SSIDs que ele conhece para tentar obter uma conexão novamente, sujeito a tempos limite para preservar a vida útil da bateria.

A maioria dos portais cativos tem um limite de duração de sessão (incluindo o openNDS).

Se um dispositivo previamente logado retornar para dentro da cobertura do portal, o SSID usado anteriormente será reconhecido e o CPD será acionado e testará uma conexão de Internet da maneira normal. Dentro do limite de duração da sessão do portal, a conexão de Internet será estabelecida, se a sessão tiver expirado, a página inicial será exibida novamente.

As primeiras implementações de CPD em dispositivos móveis costumavam pesquisar sua URL de detecção em intervalos regulares, normalmente em torno de 30 a 300 segundos. Isso acionaria a página inicial do Portal bem rápido se o dispositivo permanecesse no alcance e o limite da sessão tivesse sido atingido.

No entanto, percebeu-se muito rapidamente que essa pesquisa mantinha o WiFi no dispositivo ativado continuamente, tendo um efeito muito negativo na vida útil da bateria, então essa pesquisa enquanto conectado era aumentada para um intervalo muito longo ou removida completamente (dependendo do fornecedor) para preservar a carga da bateria. Como a maioria dos dispositivos móveis entra e sai do alcance, isso não é um problema.

Um problema comum levantado é:

“Meus dispositivos mostram a página inicial quando se conectam pela primeira vez, mas quando a autorização expira, eles apenas anunciam que não há conexão com a internet. Tenho que fazê-los “esquecer” a rede sem fio para ver a página inicial novamente. É assim que deveria funcionar?”

Isso é normal, mas você descobrirá que apenas desconectar ou ligar e desligar manualmente o WiFi simulará uma “saída de alcance”, inicializando um gatilho imediato do CPD. Uma ou qualquer combinação dessas soluções deve funcionar, novamente dependendo da implementação do CPD do fornecedor em particular.

Em contraste, a maioria dos sistemas operacionais de laptop/desktop e versões de navegador para eles ainda implementam a pesquisa CPD enquanto estiver online, pois as considerações sobre bateria não são tão importantes.

Por exemplo, o Gnome desktop tem seu próprio navegador CPD integrado com um intervalo padrão de 300 segundos. O Firefox também tem como padrão algo como 300 segundos. O Windows 10 é similar.

É assim que deveria funcionar, mas envolve alguns compromissos.

A melhor solução é definir o tempo limite da sessão para um valor maior do que o tempo esperado que um dispositivo cliente provavelmente estará presente. A experiência mostra que um limite de 24 horas cobre a maioria das situações, por exemplo, bares, clubes, cafeterias, motéis etc. Se, por exemplo, um hotel tem hóspedes que ficam regularmente por alguns dias, aumente o tempo limite da sessão conforme necessário.

A equipe do local pode ter seus dispositivos adicionados à Lista de Confiáveis (Trusted List), se for apropriado, mas a experiência mostra que é melhor não fazer isso, pois eles aprendem muito rápido o que fazer e podem ajudar os hóspedes que encontrarem o problema. (Qualquer coisa que reduza as chamadas de suporte é boa!)

A maioria desses problemas com CPD são potencialmente resolvidos pelo uso de CPI, mas exigiria sua adoção por todos os fornecedores de dispositivos clientes. CPI é um novo padrão que está evoluindo à medida que é universalmente adotado. No momento em que este artigo foi escrito, a maioria dos novos dispositivos o suportava até certo ponto.

Fonte: openwrt

OpenNDS: um Captive Portal OpenSource – Como Funciona?