☰

UFW/IPTABLES не блокирует DHCP UDP-порт 67?

tag-icon • tag-icon iptables dhcp ufw
UFW/IPTABLES не блокирует DHCP UDP-порт 67?

Я использую Ubuntu 16.04. У меня установлен и включен UFW. У меня также установлен ISC-DHCP-сервер. Я не открыл UDP-порт 67, но DHCP-клиенты, похоже, все еще могут получать DHCP-аренду с сервера. Почему так? Я просмотрел IPTABLES, которые создает UFW, и в нем открыт UDP-порт 68 для DHCP-клиента, но не UDP-порт 67 (насколько я понимаю). Мне также не кажется, что UFW настроил IPTABLES для приема широковещательного трафика. Должен ли UFW разрешать или блокировать широковещательный трафик?

Есть ли в IPTABLES какое-то особое исключение для трафика UDP-порта 67?

Возвращается ли DHCP-клиент к широковещательной передаче на UDP-порт 68, если он сначала не получает ответа от широковещательной передачи на UDP-порт 67? Если это так, то это может иметь смысл, так как DHCP-запросы направляются на сервер, поскольку тогда правило UFW для разрешения исходящих DHCP-клиентских запросов разрешит входящие DHCP-клиентские запросы.

Статус ufw status verboseесть

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere

решение1

Я был слишком уныл, чтобы открыть нужные порты на своем брандмауэре, прежде чем начать тестировать свой новенький DHCP-сервер, и мне потребовалось время, чтобы понять, что он пока не должен работать. Я никогда не открывал порт 67 на брандмауэре своего сервера.

...

Простой ответ заключается в том, что DHCP действительно особенный. Если процитировать незнакомца,

По словам Марка Эндрюса из isc.org:

«DHCP использует пакетные фильтры, которые подключаются к стеку IP до брандмауэра».

http://thr3ads.net/netfilter-buglog/2011/07/1961358-Bug-730-New-DHCP-request-and-other-traffic-bypasses-iptables-netfilter

--https://www.centos.org/forums/viewtopic.php?t=8728

Часто утверждается, что это происходит из-за того, что DHCP-сервер использует сырые сокеты. Я думаю, что эта формулировка довольно запутанная. Некоторые официальные документы ISC для своего DHCP-сервера используют "сырые сокеты" как широкий термин, потому что он может работать на нескольких различных платформах, где он должен использовать несколько различных интерфейсов. В Linux есть более одного типа, которые вы могли слышать как сырые сокеты. На некоторые из них влияет Linux iptables, а на некоторые — нет..

Я уверен, что стек TCP/IP Linux накладывает некоторые ограничения при отправке пакетов с PF_INET+SOCK_RAW. Я смутно помню, что DHCP в Linux не обязательно работает с этим типом сокета, и вместо этого может потребоваться использовать «пакетные сокеты». Пакетные сокеты работают на более низком уровне. Я уверен, что пакетные сокеты не подвержены влиянию iptables.

Сокеты PF_PACKET обходят стек TCP/IP.

Сокеты PF_INET/SOCK_RAW по-прежнему проходят через стек TCP/IP.

--https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html

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

Похоже, что iptables — это одно из ограничений, применяемых к стеку TCP/IP, в том числе к отправке с помощью PF_INET+SOCK_RAW.

Если у меня есть IP-датаграмма в пользовательском пространстве и я отправляю ее через необработанный сокет, созданный с помощью socket(PF_INET, SOCK_RAW, IPPROTO_RAW) с помощью системного вызова send(), пройдет ли этот пакет через цепочки netfilter?

...

Похоже, это хорошие новости:

ipt_hook: happy cracking.
ipt_hook: happy cracking.
ipt_hook: happy cracking.
ipt_tcpmss_target: bad length (10 bytes)

Таким образом, ваши пакеты будут проходить через iptables.

https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html

И доказательства направления приема:

Оказывается, использование сырых сокетов дает мне пакеты после NAT, поэтому IP-адреса возвращаются в частный диапазон (10.xxx в моем примере). Возможно, это общеизвестно, но я с трудом нашел документацию. Если я использую libpcap/tcpdump, я получаю пакеты до NAT

[NAT выполняется iptables]

--https://lists.gt.net/iptables/user/62529#62529

Бонусное ворчание: ЯдуматьТермин «пакетный фильтр» в моей первоначальной цитате — это прямое злоупотребление, хотя и давнее. Berkeley Packet Filter — это механизм, используемый для установки фильтра на raw-сокет, например, чтобы он получал пакеты только на порту DHCP. Я думаю, что ISC иногда ссылается на «Linux Packet Filter», как будто это тип raw-сокета. Это не так, и вы на самом деле можете использовать BPF на обычных UDP- или TCP-сокетах.

Связанный контент