☰

UFW/IPTABLES가 DHCP UDP 포트 67을 차단하지 않습니까?

tag-icon • tag-icon iptables dhcp ufw
UFW/IPTABLES가 DHCP UDP 포트 67을 차단하지 않습니까?

저는 우분투 16.04를 실행하고 있습니다. ufw를 설치하고 활성화했습니다. isc-dhcp-server도 설치했습니다. UDP 포트 67을 열지 않았지만 DHCP 클라이언트는 여전히 서버로부터 DHCP 임대를 얻을 수 있는 것 같습니다. 왜 이런거야? ufw가 생성한 IPTABLES를 살펴본 결과 DHCP 클라이언트에 대해 UDP 포트 68은 열렸지만 (내가 아는 한) UDP 포트 67은 열리지 않았습니다. ufw는 브로드캐스트 트래픽을 허용하도록 IPTABLES를 구성하지 않는 것 같습니다. ufw는 브로드캐스트 트래픽을 허용해야 할까요, 아니면 차단해야 할까요?

IPTABLES UDP 포트 67 트래픽에 대한 특별한 예외가 있습니까?

DHCP 클라이언트가 UDP 포트 67의 브로드캐스트에서 먼저 응답을 받지 못하면 UDP 포트 68의 브로드캐스트로 대체됩니까? 그렇다면 나가는 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의 Mark Andrews는 다음과 같이 말했습니다.

"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 서버가 원시 소켓을 사용하기 때문이라고 종종 말합니다. 나는 이 표현이 매우 혼란스럽다고 생각한다. DHCP 서버에 대한 일부 공식 ISC 문서에서는 "원시 소켓"을 광범위한 용어로 사용합니다. 왜냐하면 이 소켓은 다양한 인터페이스를 사용해야 하는 다양한 플랫폼에서 실행될 수 있기 때문입니다. Linux에서는 원시 소켓이라는 두 가지 유형 이상을 들어보셨을 것입니다. 일부는 Linux iptables의 영향을 받고 일부는 Linux iptables의 영향을 받지 않습니다..

나는 Linux TCP/IP 스택이 PF_INET+SOCK_RAW를 사용하여 패킷을 보낼 때 몇 가지 제한을 부과한다고 확신합니다. 나의 모호한 기억은 Linux의 DHCP가 반드시 이러한 유형의 소켓에서 작동하는 것은 아니며 "패킷 소켓"을 사용해야 할 수도 있다는 것입니다. 패킷 소켓은 더 낮은 수준에서 작동합니다. 나는 패킷 소켓이 iptables의 영향을 받지 않는다고 확신합니다.

PF_PACKET 소켓은 TCP/IP 스택을 우회합니다.

PF_INET/SOCK_RAW 소켓은 여전히 ​​TCP/IP 스택을 통과합니다.

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

이 문장은 데이터 패킷을 수신하는 상황에서 작성되었습니다. 예상한 대로 이것이 패킷 전송에 효과가 있다는 증거도 있습니다.

iptables는 PF_INET+SOCK_RAW를 통한 전송을 포함하여 TCP/IP 스택에 적용되는 제한 사항 중 하나인 것으로 보입니다.

사용자 공간에 IP 데이터그램이 있고 send() 시스템 호출을 사용하여 소켓(PF_INET, SOCK_RAW, IPPROTO_RAW)을 사용하여 생성된 원시 소켓을 통해 이를 보내는 경우 패킷이 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 패킷 필터는 예를 들어 원시 소켓에 필터를 설치하여 DHCP 포트에서만 패킷을 수신하는 메커니즘입니다. ISC는 때때로 "Linux 패킷 필터"를 마치 원시 소켓 자체인 것처럼 참조하는 것 같습니다. 이는 사실이 아니며 실제로 일반 UDP 또는 TCP 소켓에서 BPF를 사용할 수 있습니다.

관련 정보