Estrutura do Firewall Vyatta e Direção da Interface

3

Acabei de comprar um Ubiquity EdgeRouter ER-8 e estou trabalhando na configuração do firewall. Em particular, estou confuso sobre a direção "Local" da interface que defini como a WAN e como posso usá-la para evitar a exposição dos protocolos de gerenciamento do roteador (ssh / https) ao mundo externo.

Pelo manual Os conjuntos de regras podem ser aplicado em qualquer interface, em uma das três direções:

  • Em: tráfego chegando em uma porta
  • Fora: tráfego saindo de uma porta
  • Local: tráfego destinado ao próprio roteador

Minhas perguntas são:

  1. Haveria algum tráfego de direção "local" diferente das interfaces web / ssh de gerenciamento? O tráfego de resposta, como NTP, RIP, masq de DNS, etc., originado do próprio roteador entra pela direção "local"?

  2. Se eu aplicar uma regra para descartar todos os pacotes para WAN_LOCAL, isso bloqueará as solicitações para as interfaces de gerenciamento da WAN, mas permitirá solicitações da LAN (já que não há um conjunto de regras LAN_LOCAL)?

  3. O tráfego que chega a WAN_LOCAL é filtrado primeiro por WAN_IN? se eu tiver um filtro de estado padrão no WAN_IN (por exemplo, aceitar respostas NAT, largar todo o resto), evita a necessidade de um conjunto de regras no WAN_LOCAL?

por Frank Thomas 19.05.2015 / 13:55

3 respostas

2

Roteador com boa aparência.

Q1 Resposta: Não. O único tráfego considerado local seria, como você mencionou, o tráfego ssh e webui, bem como o tráfego do servidor DHCP se você estiver utilizando o recurso de servidor DHCP do roteador.

Q2 Resposta: Sim. Isso eliminaria todo o tráfego destinado ao roteador da WAN. Eu sugiro criar uma regra chamada MgmtAccess (ordem acima da regra de queda) que permite o tráfego tcp de uma fonte externa, caso você precise gerenciá-lo remotamente a partir de outro local. Um datacenter, por exemplo, ou sua casa.

Q3 Resposta: Não. Os conjuntos de regras processam as regras separadamente um do outro.

Eu gosto de abordar firewalls com paranóia. Eu começaria criando três conjuntos de regras para cada interface (in, out, local), com a ação padrão de in e local sendo 'drop'. Out pode ser aceito. Eu adicionaria então regras (observe a ordem), para permitir o tráfego enquanto eu vou de lá. Dê-lhes bons nomes. Se eth0 for para a WAN, chame esses conjuntos de regras WAN_IN, WAN_LOCAL, WAN_OUT. Se o eth7 for para a rede de armazenamento, chame-o STORAGE_IN ... Você entendeu. Forneça também os nomes descritivos das regras para facilitar o gerenciamento.

Destruição de conta padrão: crie um novo usuário e exclua o original. Isso impedirá ataques de força bruta contra a conta padrão. Trate seus nomes de usuário como senhas. Mantenha-os em segredo. Mantenha-os em segurança.

    
por 22.05.2015 / 08:09
2
  1. Potencialmente. Por exemplo, se você usar o roteador em uma rede pequena para armazenar em cache solicitações de DNS, o tráfego de DNS atingirá a interface LOCAL. A mesma coisa se você usá-lo para DHCP e qualquer outro serviço de rede.
  2. Veja acima. Se você quiser usar o roteador para armazenar em cache solicitações de DNS, então você terá que permitir que seu LOCAL fale com a WAN, assim como a LAN faz.
  3. Os conjuntos de regras são independentes e pode ser útil para que a clareza da configuração seja explícita com o que está bloqueado. Então eu preferiria ter todas as regras indicando a intenção. Com isso em mente, eu teria WAN_LOCAL.

Algum tempo atrás eu visualizei o processo de raciocínio para o caso em que não há serviços dentro do roteador que precisem de acesso à WAN para o ER POE8.

Ainda está no GitHub, você pode ver se isso ajuda você.

    
por 26.05.2015 / 15:53
1

Para impedir o acesso não autorizado a serviços de roteador da interface WAN, basta alterar a senha padrão na conta de administrador (ubnt).

Veja o artigo Velocidades de Recuperação de Senha . Descreve o tempo máximo de crack para uma senha aleatória, por comprimento de senha e os personagens usados.

Por exemplo, o tempo necessário para decifrar B33r&Mug de uma rede distribuída de supercomputadores (NSA) é estimado em 83 dias, enquanto uma estação de trabalho de alto nível precisará de mais de 2 anos. Isso ocorre porque essa senha usa letras maiúsculas e minúsculas, bem como caracteres numéricos e especiais, sendo ainda bastante curto (8 caracteres).

    
por 22.05.2015 / 09:01