1

I've created an AWS instance in the default VPC and I've blocked all UDP traffic in the Network ACLs. Here's how my outbound rules look:

Rule number Type Protocol Port range Destination Allow/Deny
99 All UDP UDP (17) All 0.0.0.0/0 Deny
100 All TCP TCP (6) All 0.0.0.0/0 Allow
* All traffic All All 0.0.0.0/0 Deny

If I use traceroute, I get nothing, as expected:

[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  * * *
 ...

However, if I use nc, I do get a response back, which is unexpected:

[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.

Why does that happen? Also, it always takes 2 seconds to get a response back. Why 2 seconds?

dodov
  • 141
  • 4

2 Answers2

1

TL;DR - UDP is being blocked by the NACL rule. The response you receive from nc is deceptive and I believe, but haven't confirmed, that the 2.01s time is a timeout.

Netcat is stating it sent a packet, which it did. But your NACL is acting as a firewall at Layer 3/4 for the subnet that your EC2 instance is attached to. The packet is being sent from the host but the NACL is blocking it (and dropping it). Because you're using the -z flag, it immediately drops the connection and there is a two-second timeout associated with it. I'm assuming the two seconds is the time out because it's always the return value. (I don't have time to run this down in the source code)

I recreated your NACL in a VPC, and experienced the same result as above including the exact "received" value. But when I try a lookup against that site using dig it times out when the Deny is in place.

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

When the Deny is not in place the dig works as expected. The last tell is if you run an nmap scan on that UDP port you'll get an "open|filtered" response.

Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered.

References
AWS VPC Network ACLs
ncat Man Page
nmap UDP Scan

kenlukas
  • 3,101
  • 2
  • 16
  • 26
0

You have a lower number rule that is processed before rule 99 that allows UDP. Rules are evaluated in ascending order.

"Rule number. Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it's applied regardless of any higher-numbered rule that might contradict it."

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-rules

Greg Askew
  • 35,880
  • 5
  • 54
  • 82