Acabo de comprar unEnrutador Ubiquity Edge ER-8y estoy trabajando en la configuración del firewall. En particular, estoy confundido acerca de la dirección "Local" para la interfaz que he definido como WAN y cómo puedo usarla para evitar la exposición de los protocolos de administración del enrutador (ssh/https) al mundo exterior.
Según el manualLos conjuntos de reglas se pueden aplicar en cualquier interfaz, en una de tres direcciones:
- En: Tráfico que llega a un puerto
- Fuera: Tráfico que sale de un puerto
- Local: Tráfico destinado al propio enrutador
Mis preguntas son:
¿Habría tráfico de dirección "local" que no sea hacia las interfaces web/ssh de administración? ¿El tráfico de respuesta como NTP, RIP, máscara DNS, etc., procedente del propio enrutador, llegaría a través de la dirección "local"?
Si aplico una regla para descartar todos los paquetes a WAN_LOCAL, ¿eso bloqueará las solicitudes a las interfaces de administración desde la WAN, pero permitirá solicitudes desde la LAN (ya que no existe un conjunto de reglas LAN_LOCAL)?
¿El tráfico que llega a WAN_LOCAL es filtrado primero por WAN_IN? Si tengo un filtro de estado estándar en WAN_IN (por ejemplo, acepto respuestas NAT, descarto todo lo demás), ¿evito la necesidad de un conjunto de reglas en WAN_LOCAL?
Respuesta1
Bonito enrutador.
Respuesta de la primera pregunta: No. El único tráfico considerado local sería, como mencionó, el tráfico ssh y webui, así como el tráfico del servidor DHCP si está utilizando la función de servidor DHCP del enrutador.
Respuesta Q2: Sí. Eso eliminaría todo el tráfico destinado al enrutador de la WAN. Sugiero crear una regla llamada MgmtAccess (ordenarla encima de la regla de eliminación) que permita el tráfico TCP desde una fuente externa en caso de que necesite administrarlo de forma remota desde otra ubicación. Un centro de datos, por ejemplo, o tu casa.
Respuesta a la tercera pregunta: No. Los conjuntos de reglas manejan sus reglas por separado unos de otros.
Me gusta acercarme a los cortafuegos con paranoia. Comenzaría creando tres conjuntos de reglas para cada interfaz (entrada, salida, local), siendo la acción predeterminada de entrada y local "soltar". Se puede aceptar. Luego agregaría reglas (observar el orden) para permitir el tráfico a medida que avanzo desde allí. Ponles buenos nombres. Si eth0 va a la WAN, llame a esos conjuntos de reglas WAN_IN, WAN_LOCAL, WAN_OUT. Si eth7 va a la red de almacenamiento, llámalo STORAGE_IN... Lo entiendes. Asigne también nombres descriptivos a las reglas para facilitar la gestión en el futuro.
Destrucción de cuenta predeterminada: cree un nuevo usuario y elimine el original. Esto evitará ataques de fuerza bruta contra la cuenta predeterminada. Trate sus nombres de usuario como contraseñas. Mantenlos en secreto. Mantenlos a salvo.
Respuesta2
- Potencialmente. Por ejemplo, si utiliza el enrutador en una red pequeña para almacenar en caché las solicitudes de DNS, el tráfico de DNS llegará a la interfaz LOCAL. Lo mismo si lo usas para DHCP y cualquier otro servicio de red.
- Véase más arriba. Si desea utilizar el enrutador para almacenar en caché las solicitudes de DNS, deberá permitir que su LOCAL se comunique con la WAN, tal como lo hace la LAN.
- Los conjuntos de reglas son independientes y puede resultar útil para mayor claridad de configuración ser explícito con lo que está bloqueado. Por eso preferiría tener todas las reglas que indiquen la intención. Con eso en mente tendría WAN_LOCAL.
Hace algún tiempo visualicé el proceso de pensamiento para el caso en el que no hay servicios dentro del enrutador que necesiten acceso WAN para ER POE8.
Respuesta3
Para evitar el acceso no autorizado a los servicios del enrutador desde la interfaz WAN, simplemente cambie la contraseña predeterminada en la cuenta de administrador (ubnt).
ver el articuloVelocidades de recuperación de contraseña. Describe el tiempo máximo de descifrado para una contraseña aleatoria, por la longitud de la contraseña y los caracteres utilizados.
Por ejemplo, el tiempo necesario para descifrar B33r&Muguna red distribuida de superordenadores (NSA) se estima en 83 días, mientras que una estación de trabajo de alta gama necesitará más de 2 años. Esto se debe a que esa contraseña utiliza mayúsculas y minúsculas, así como números y caracteres especiales, aunque sigue siendo bastante corta (8 caracteres).