Creé una instancia de AWS en la VPC predeterminada y bloqueé todo el tráfico UDP en las ACL de red. Así es como se ven mis reglas de salida:
| Número de regla | Tipo | Protocolo | Rango de puertos | Destino | Permiten negar |
|---|---|---|---|---|---|
| 99 | Todo UDP | UDP (17) | Todo | 0.0.0.0/0 | Denegar |
| 100 | Todo TCP | TCP (6) | Todo | 0.0.0.0/0 | Permitir |
| * | Todo el tráfico | Todo | Todo | 0.0.0.0/0 | Denegar |
Si uso traceroute, no obtengo nada, como se esperaba:
[ec2-user@ip-172-31-32-169 ~]$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
...
Sin embargo, si uso nc,hacerobtener una respuesta, que es inesperada:
[ec2-user@ip-172-31-32-169 ~]$ nc -vzu 1.1.1.1 53
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 1.1.1.1:53.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
¿Por qué sucede eso? Además, siempre se necesitan 2 segundos para recibir una respuesta. ¿Por qué 2 segundos?
Respuesta1
TL;DR: UDP está bloqueado por la regla NACL. La respuesta que recibe nces engañosa y creo, aunque no lo he confirmado, que el tiempo de 2,01 segundos es un tiempo de espera.
Netcat afirma que envió un paquete, y así fue. Pero su NACL actúa como un firewall en la capa 3/4 para la subred a la que está conectada su instancia EC2. El paquete se envía desde el host pero la NACL lo bloquea (y lo descarta). Debido a que está utilizando la -zbandera, inmediatamente se interrumpe la conexión y hay un tiempo de espera de dos segundos asociado. Supongo que los dos segundos es el tiempo de espera porque siempre es el valor de retorno. (No tengo tiempo para ejecutar esto en el código fuente)
Recreé su NACL en una VPC y experimenté el mismo resultado que el anterior, incluido el valor "recibido" exacto. Pero cuando intento realizar una búsqueda en ese sitio, digel tiempo de espera se agota cuando la opción Denegar está activada.
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 1.1.1.1:53.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
[root@ip-10-99-0-198 centos]# dig +short @1.1.1.1 www.google.com
;; connection timed out; no servers could be reached
Cuando el Deny no está implementado, las digobras funcionan como se esperaba. La última indicación es que si ejecuta un nmapanálisis en ese puerto UDP, obtendrá una respuesta "abierto|filtrado".
Desafortunadamente, también se sabe que los firewalls y dispositivos de filtrado descartan paquetes sin responder. Entonces, cuando Nmap no recibe respuesta después de varios intentos, no puede determinar si el puerto está abierto o filtrado.
Referencias
ACL de red de AWS VPC
Página de manual de ncat
Escaneo UDP de nmap
Respuesta2
Tiene una regla de número inferior que se procesa antes de la regla 99 que permite UDP. Las reglas se evalúan en orden ascendente.
"Número de regla. Las reglas se evalúan comenzando con la regla con el número más bajo. Tan pronto como una regla coincide con el tráfico, se aplica independientemente de cualquier regla con un número más alto que pueda contradecirla".
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-rules