Я создал экземпляр AWS в VPC по умолчанию и заблокировал весь трафик UDP в сетевых ACL. Вот как выглядят мои исходящие правила:
| Номер правила | Тип | Протокол | Диапазон портов | Место назначения | Разрешить/Запретить |
|---|---|---|---|---|---|
| 99 | Все UDP-протоколы | УДП (17) | Все | 0.0.0.0/0 | Отрицать |
| 100 | Все TCP | ТКП (6) | Все | 0.0.0.0/0 | Позволять |
| * | Весь трафик | Все | Все | 0.0.0.0/0 | Отрицать |
Если я использую traceroute, то, как и ожидалось, ничего не получаю:
[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 * * *
...
Однако, если я использую nc, яделатьполучаю ответ, который оказывается неожиданным:
[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.
Почему так происходит? Кроме того, ответ всегда приходит через 2 секунды. Почему 2 секунды?
решение1
TL;DR - UDP блокируется правилом NACL. Ответ, который вы получаете, ncобманчив, и я считаю, но не подтверждал, что время 2.01 с - это тайм-аут.
Netcat сообщает, что отправил пакет, что он и сделал. Но ваш NACL действует как брандмауэр на уровне 3/4 для подсети, к которой подключен ваш экземпляр EC2. Пакет отправляется с хоста, но NACL блокирует его (и отбрасывает). Поскольку вы используете флаг -z, он немедленно отключает соединение, и с ним связан двухсекундный тайм-аут. Я предполагаю, что две секунды — это тайм-аут, потому что это всегда возвращаемое значение. (У меня нет времени, чтобы просмотреть это в исходном коде)
Я воссоздал ваш NACL в VPC и получил тот же результат, что и выше, включая точное значение "received". Но когда я пытаюсь выполнить поиск по этому сайту, используя digего, происходит тайм-аут, когда Deny на месте.
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
Когда Deny не установлен, все digработает как и ожидалось. Последнее, что я могу сказать, это то, что если вы запустите nmapсканирование на этом порту UDP, вы получите ответ "open|filtered".
К сожалению, известно, что брандмауэры и фильтрующие устройства также отбрасывают пакеты без ответа. Поэтому, когда Nmap не получает ответа после нескольких попыток, он не может определить, открыт ли порт или отфильтрован.
Рекомендации
Списки контроля доступа сети AWS VPC
Страница пользователя ncat
сканирование nmap UDP
решение2
У вас есть правило с меньшим номером, которое обрабатывается до правила 99, разрешающего UDP. Правила оцениваются в порядке возрастания.
«Номер правила. Правила оцениваются, начиная с правила с наименьшим номером. Как только правило соответствует трафику, оно применяется независимо от любого правила с более высоким номером, которое может ему противоречить».
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-rules