Cisco IOS BVI ACL: разрешить только установленный UDP

Связанный: Cisco IOS ACL: не разрешать входящие соединения только потому, что они от порта 80

Я знаю, что мы можем использовать established ключевое слово для TCP... но что мы можем сделать для UDP (если не считать замену моста или BVI на NAT)?

Ответ

Я узнал, что означает "UDP не имеет связи".

DNS использует UDP, например.

  1. named (DNS-сервер) находится на порте 53
  2. nslookup (DNS-клиент) начинает прослушивание на некотором случайном порте и отправляет пакет на порт 53 сервера и отмечает исходный порт в этом пакете.
  3. nslookup повторите попытку 3 раза, если это необходимо. Также пакеты настолько малы, что не нужно беспокоиться о том, что они поступили в неправильном порядке.
  4. Если nslookup получает ответ на этот порт, который приходит от IP-адреса сервера и порта, а затем прекращает прослушивание. Если сервер попытается отправить два ответа (например, ответ и ответ на повторную попытку), то серверу будет все равно, если один из них сделает это, потому что у клиента есть задание на повторную попытку. На самом деле... если пакет ICMP 3/3 не пройдет через сервер, он не узнает об ошибке. Это отличается от TCP, где вы получаете соединение закрыто или ошибки тайм-аута.

DNS позволяет легко повторить попытку с клиента, а также с небольшими пакетами... поэтому UDP является отличным выбором, поскольку он более эффективен. В UDP вы увидите

  1. nslookup отправляет запрос
  2. named отправляет ответ

В TCP вы увидите

  1. nslookupмашина отправляет SYN
  2. namedмашина отправляет SYN-ACK
  3. nslookupмашина отправляет ACK и просьба
  4. namedмашина отправляет ответ

Это намного больше, чем необходимо для крошечного пакета DNS

2 ответа

Решение

UDP-пакеты не устанавливают соединение, они буквально срабатывают и забывают! Просто permit udp host XX.xx.xx.xx host xx.xx.xx.xx eq xx должно быть все, что требуется.

Случайно наткнулся на эту страницу при поиске чего-то другого и подумал добавить пару центов...

Если не использовать брандмауэр с сохранением состояния в IOS, вы можете использовать существующую длинную функцию, называемую "рефлексивный ACL" - где пакет в одном направлении пробивает дыру в ACL, и это позволяет пакетам в другом направлении.

Руководство по настройке описывает функцию в деталях, но в двух словах:

  • у вас может быть запись в списке доступа, которая, помимо разрешения пакетов, также может отражать этот трафик в рефлексивном ACL (который является полностью динамическим объектом)
  • в другом ACL вы можете оценить этот рефлексивный ACL как часть процесса сопоставления ACL вместе с обычным разрешением и отказом.

Вот простой пример конфигурации:

interface Dialer1
  ip address negotiated
  ip access-group V4-GATE in
  ip access-group V4-REF out
!
ip access-list extended V4-GATE
  permit icmp any any echo-reply
  permit icmp any any unreachable
  permit icmp any any ttl-exceeded
  permit icmp any any packet-too-big
  evaluate V4-REFLECTOR
  deny   ip any any log
!
ip access-list extended V4-REF
  permit udp any any eq domain reflect V4-REFLECTOR timeout 10
  permit ip any any reflect V4-REFLECTOR
!

Это даст вам почти столько же состояния, сколько и перегрузка NAT.

НТН.

(РЕДАКТИРОВАТЬ: видя, что вы упомянули BVI - возможно, применимость этого будет зависеть от вашей конфигурации. То, что я проиллюстрировал выше, это где Dialer1 является выходным интерфейсом, подключенным к Интернету. Если вы делаете роутер на палочке, вам может понадобиться адаптировать это - хотя я думаю, что это все еще применимо. Это непригодно, если интерфейсы, соединяющие две пары соединения, являются членами одной и той же группы мостов)

Другие вопросы по тегам