Utilizador de MikroTik VPN chega demasiado longe: limite a um host e uma porta

O túnel sobe, o início de sessão tem sucesso e todos os hosts da rede respondem. Isso não é uma VPN avariada; é uma VPN sem modelo de permissões. O RouterOS autentica a conta e depois encaminha os seus pacotes como os de qualquer outra pessoa, por isso a firewall tem de fornecer o limite. Acrescentar esse limite sem quebrar o início de sessão é todo o trabalho.

A autenticação termina onde a permissão começa

Assim que a sessão PPP está estabelecida, os pacotes do cliente entram na cadeia forward como o tráfego de qualquer outra interface. Se a política forward do router for permissiva, o consultor herda essa permissividade no início de sessão. A conta nunca transportou um âmbito, por isso não há nada na conta para alterar. O conjunto de regras foi escrito para funcionários e a nova sessão simplesmente juntou-se a ele.

Verifique a que caminho se refere o pedido antes de escrever seja o que for. O tráfego para hosts atrás do router atravessa forward, enquanto o tráfego para o próprio router, incluindo winbox e SSH, atravessa input. Um âmbito que só cobre forward deixa o dispositivo aberto ao mesmo cliente.

Ambas as cadeias precisam de uma decisão, mesmo que a decisão seja deixar input fechado. Essa escolha pertence ao pedido de acesso, não a um pensamento posterior.

Associe a sessão a uma lista com nome

Um perfil PPP pode colocar o endereço que entrega numa lista de endereços com nome quando a sessão começa. Isso transforma um endereço de túnel transitório em algo que a firewall pode emparelhar por nome, e a entrada desaparece quando a sessão termina. A conta herda então o âmbito do seu perfil em vez de uma regra que codifica um endereço de forma rígida.

Crie primeiro o perfil e depois associe o secret a ele de forma explícita. Um secret que ainda aponta para o perfil predefinido reproduz o problema original.

Dê nome ao perfil e à lista para que as suas tarefas sejam óbvias, e comente ambos com a referência do pedido. Um perfil pode servir várias pessoas com o mesmo âmbito, enquanto a lista continua a identificar cada sessão viva. É mais barato de rever do que uma regra por pessoa.

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Registe o serviço permitido numa lista

Coloque o servidor permitido na sua própria lista de endereços em vez de incorporar o endereço numa regra de filtro. A lista pode ser auditada, ampliada e comentada, e a regra que a consome não muda quando o servidor se desloca. Uma única entrada parece excessiva até chegar o segundo host, o que costuma acontecer.

Emparelhe uma lista quando o endereço é dinâmico ou balanceado, e emparelhe o endereço diretamente quando está reservado e é estável. Qualquer das opções lê-se com clareza se o comentário nomear o serviço e o proprietário.

Limite o protocolo e a porta, além do host. Um accept para um host sem restrição de porta abre todos os serviços que esse host executa, o que é mais amplo do que a maioria dos pedidos de acesso pretende. A porta faz parte da permissão, não é um detalhe a acrescentar depois.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Ordene o salto antes de qualquer accept amplo

Uma regra de salto envia o tráfego reencaminhado da lista limitada para uma cadeia privada onde toda a política cabe em três linhas. A primeira regra aceita o destino e a porta permitidos, e a última descarta tudo o resto. O salto tem de ficar acima de qualquer accept amplo em forward, porque um accept anterior significa que o salto nunca corre. Mantenha o accept para established e related antes do salto para que o tráfego de retorno continue a fluir.

Verifique que nenhuma regra fasttrack pode levar este tráfego para lá da cadeia limitada. O fasttrack contorna o resto do caminho do filtro, e uma sessão limitada que passa por fasttrack não está limitada de todo.

Repita a decisão para a cadeia input se os serviços do próprio router devem ficar inacessíveis. Um âmbito que bloqueia o tráfego reencaminhado e deixa o winbox aberto está apenas meio terminado.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Verifique com contadores e pertença à lista

A partir do cliente, teste o serviço permitido e um que deve falhar, e depois leia as estatísticas de regras no router. Os contadores accept e drop mostram que caminho cada pacote seguiu, o que o cliente não consegue ver. Confirme também que o endereço da sessão viva apareceu na lista limitada.

Uma lista vazia significa que a conta está noutro perfil ou que o perfil perdeu a definição de lista de endereços. Um contador drop a subir com um serviço permitido a falhar significa que o destino ou a porta não correspondem ao que o cliente envia.

Teste o mesmo serviço por nome e por endereço antes de concluir o que quer que seja. Uma falha de resolução de nomes parece exatamente uma porta bloqueada do lado do cliente. Depois registe o perfil, ambas as listas e o único serviço permitido no pedido de acesso, para que a revisão seguinte compare em vez de reconstruir.

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients