Я пытаюсь создать правило брандмауэра на сервере Ubuntu 10.04, на котором запущен isc-dhcpd. Я хочу, чтобы dhcp был доступен только для одного узла ретрансляции (172.1.1.1). У меня iptables настроен так:
# iptables -vnL
Chain INPUT (policy ACCEPT 5325 packets, 523K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 172.1.1.1 0.0.0.0/0 udp dpt:67
1497 533K DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
Это моя попытка отбросить весь UDP-трафик, предназначенный для порта 67, если он не исходит от 172.1.1.1.
Однако с этим правилом, когда я запускаю dhcpd, я сразу вижу, что запросы DHCP начинают поступать через широковещательную рассылку (в журнале указано, что через eth0).
Нужно ли мне другое правило брандмауэра для перехвата широковещательного трафика? Я пробовал добавить правило вроде
iptables -A INPUT -p udp -d 255.255.255.255 -j DROP
который должен отбросить весь широковещательный трафик UDP. Но снова, когда я запускаю dhcpd, я вижу множество запросов через широковещательную рассылку.
РЕДАКТИРОВАТЬ: Согласно эта страница:
Для большинства операций программное обеспечение DHCP взаимодействует со стеком IP Linux на уровне ниже Netfilter. Следовательно, Netfilter (и, следовательно, Shorewall) не может эффективно использоваться для контроля DHCP.
Так есть ли способ добиться здесь того, что я хочу?
Он не работает на чистом IP-уровне, нужно знать, как работает DHCP:
Сначала клиент DHCP отправляет пакет (DHCPDISCOVER) от 0.0.0.0 до 255.255.255.255 (локальный широковещательный адрес).
DHCP-сервер предложит IP-адрес (DHCPOFFER); с точки зрения iptables, это будет пакет с адреса DHCP-сервера, также нацеленный на локальный широковещательный адрес 255.255.255.255. Кадр Ethernet адресуется по MAC-адресу DHCP-клиента.
Клиент DHCP выбирает из любых предложений, отправленных на его MAC-адрес Ethernet, и отправляет DHCPREQUEST на сервер DHCP; для iptables это еще один пакет из 0.0.0.0, все еще нацеленный на локальный широковещательный адрес 255.255.255.255.
Сервер DHCP подтверждает назначение IP-адреса (DHCPACK). Результирующий IP-пакет поступает с IP-адреса DHCP-сервера, IP-адрес назначения - еще раз 255.255.255.255, адрес кадра Ethernet будет адресован по MAC-адресу DHCP-клиента.
Когда клиент DHCP хочет продлить аренду DHCP, он отправляет еще один запрос DHCPREQUEST от 0.0.0.0 до 255.255.255.255 и запрашивает текущий IP-адрес. Он будет делать это до тех пор, пока не истечет срок аренды DHCP, а затем снова запустит DHCPDISCOVER.
Скорее всего, вы ищете что-то вроде этого:
iptables -A INPUT -m mac --mac-source xx: xx: xx: xx: xx: xx -p udp --dport 67 -j ACCEPT iptables -A INPUT -p udp --dport 67 -j DROP
Это приведет к отбрасыванию любых запросов DHCP, направленных на ваш сервер, которые исходят не с указанного MAC-адреса.
Проблема также может быть решена на другом уровне: удалите пул IP-адресов с DHCP-сервера и назначьте только статические сопоставления для ваших соответствующих MAC-адресов. Таким образом, DHCP-сервер не будет отвечать никому из перечисленных и будет назначать IP-адреса только известным хостам.
Поскольку кажется, что netfilter (iptables) не эффективен для фильтрации рассылок DHCP, попробуйте использовать ebtables, инструмент Linux для фильтрации фреймов Ethernet на нижнем уровне. У меня нет прямого опыта работы с ebtables, но беглое прочтение справочной страницы предполагает, что в вашем случае может быть эффективным следующее:
ebtables -A INPUT --protocol ipv4 --ip-proto udp --ip-src \! 172.1.1.1 --ip-dport 67 -j DROP
это должен заставить ядро Linux отбрасывать все кадры Ethernet, содержащие пакеты UDP IPv4, которые не относятся к 172.1.1.1 и предназначены для порта 67.