Tengo una red secundaria de mi enrutador ER605, que se utiliza para aislar el dispositivo conectado, una Raspberry Pi. Lo uso para poner en cuarentena y escanear archivos entrantes de fuentes dudosas (como las computadoras de mis suegros constantemente afectadas por malware). Necesito poder acceder a pi y extraer archivos escaneados a mi red principal. Planeo usar VNC para acceder y colocar los archivos aceptados directamente en mi QNAP NAS a través del recurso compartido SMB.
La regla 5 de ACL bloquea la comunicación desde la red de cuarentena a mi red principal. Para llevar VNC a mi pi de cuarentena desde mi red principal, inicialmente agregué la regla 4, que era insuficiente (la lectura en línea sugirió que necesitaba una ACL para los mensajes de respuesta), así que agregué una versión de la regla 3 que hacía referencia al servicio VNC, y eso todavía falló. Por capricho, intenté crear la definición del servicio VNC_duplex que intercambia el puerto de origen y de destino y cambia la regla n.° 3 del servicio VNC a VNC dúplex, ¡y viola VNC funcionó!
Estoy muy feliz de que esto esté funcionando, pero no estoy seguro de por qué ni si es seguro. ¿Estoy en lo cierto al entender que la regla 3 de ACL permite que un script malicioso envíe un mensaje desde cualquier puerto de la Raspberry Pi al puerto 5900 de cualquier dispositivo de mi red principal? ¿Cuál es la forma semántica de entender esto? ¿Podría hacerse más seguro?
Mi red y VLAN:
También configuré algunos rangos de IP para describir áreas de mi red a las que quiero segmentar/otorgar acceso:
Mis tipos de servicio (los últimos cuatro los introduzco de forma personalizada):
Y finalmente mi ACL:
Respuesta1
la lectura en línea sugirió que necesitaba una ACL para los mensajes de respuesta), así que agregué una versión de la regla 3 que hacía referencia al servicio VNC, y aún así falló. Por capricho, intenté crear la definición del servicio VNC_duplex que intercambia el puerto de origen y de destino y cambió la regla n.° 3 del servicio VNC a VNC dúplex, ¡y viola VNC funcionó!
Cuando el Pi envía respuestas a su computadora,el Pi es la fuente.
No es sólo que los paquetes de 'retorno' tengan la dirección IP del Pi como "IP de origen", sino que también tienen el número de puerto correspondiente.en el lado picomo el "puerto de origen".
Connection: 192.168.0.PC:54321 <--> 192.168.2.10:5900
Packets from PC: src = 192.168.0.PC:54321, dst = 192.168.2.10:5900
Packets from Pi: src = 192.168.2.10:5900, dst = 192.168.0.PC:54321
Todas las plantillas de servicio originales en su firewall están definidas solo para la dirección "hacia adelante"; por ejemplo, la plantilla "VNC" coincide con 5900 como puerto de destino, que, como se explicó, solo coincide con los paquetes que tienen el servidor VNC como destino, pero no con los paquetes de "retorno".
¿Estoy en lo cierto al entender que la regla 3 de ACL permite que un script malicioso envíe un mensaje desde cualquier puerto de la Raspberry Pi al puerto 5900 de cualquier dispositivo de mi red principal?
No. Lo que permite es lo contrario: permite que un script envíe un mensaje.desde el puerto 5900en la frambuesa pia cualquier puertoen su red principal. (La 'Fuente' en "Puerto de origen = 5900"realmente significala fuente de los paquetes.)
Desde el puerto de origen de una conexiónpoderelegirse arbitrariamente (si se desea), esto significa que la red primaria está abierta a cualquiera quesabesobre la existencia de esta excepción; todo lo que necesitan hacer es pedirle al sistema operativo que vincule una conexión al puerto local 5900. (Pero, por otro lado, dado que el puerto de origen suele ser aleatorio y el rango comienza mucho más allá del 5900, cualquiera quenoEs poco probable que conozca esta excepción y la descubra por accidente).
¿Cuál es la forma semántica de entender esto?
"Fuente" realmente significa la fuente del individuo.paquete, no de toda la conexión. (En realidad, el puerto casi podría considerarse parte de la dirección de la "capa de transporte" del paquete y, de hecho, en varios otros protocolos no IP era literalmente parte de la dirección).
Cada puerto está asociado con un punto final específico, de la misma manera que cada dirección IP está asociada con un punto final específico: si establece una conexión con el Pi, no espera que se siga mostrando un paquete de "retorno" del Pi. la dirección IP del Pi como "destino", y lo mismo se aplica a los números de puerto.
¿Y podría hacerse más seguro?
El enfoque habitual es evitar dichas ACL reflexivas por completo y utilizar unacon estadocortafuegos. La mayoría de los enrutadores son capaces de realizar un seguimiento de las conexiones activas ("estados" o "flujos");tengo quehaga esto si implementan NAT típica 1:muchas, y el filtro de firewall puede tener una regla especial que permita cualquier paquete correspondiente a una conexión "establecida" (como en iptables/nftables), o permita dichos paquetes implícitamente (como en pf).
Parece que el ER603 obtuvo soporte para ACL con estadoen firmware 2.1. (Sin embargo, la gente parece decir que no funciona).
Si usteddebeutilizar ACL sin estado, entonces el enfoque alternativo es permitir solo paquetes de "devolución" que tengan laIndicador "ACK" de TCPcolocar. El paquete inicial de una conexión TCP.nuncatiene esta bandera establecida, mientras que todos los demás paquetes la tienen; basta con tener una única regla que permita paquetes TCP ACK en cualquier puerto.
Naturalmente, este enfoque sólo funciona para TCP; no se puede hacer mucho con UDP sin seguimiento de estado, excepto esperar que nadie descubra el agujero que hace su ACL reflexiva.
También debería tener otra regla que permita la "devolución" de paquetes ICMP (por ejemplo, Echo Reply y los diversos mensajes de "error" ICMP:como mínimoSe debe permitir "Fragmentación necesaria", pero preferiblemente también se deben permitir otros errores como "Inalcanzable").