우분투 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 스택에 연결됩니다."
--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
보너스 불만: I생각하다내가 처음 인용한 "패킷 필터"라는 용어는 비록 오랫동안 사용되어 왔지만 명백한 남용입니다. 버클리 패킷 필터는 예를 들어 DHCP 포트에서만 패킷을 수신하도록 원시 소켓에 필터를 설치하는 데 사용되는 메커니즘입니다. 나는 ISC가 때때로 "Linux Packet Filter"를 원시 소켓 자체의 일종인 것처럼 언급한다고 생각합니다. 그렇지 않으며 실제로 일반 UDP 또는 TCP 소켓에서 BPF를 사용할 수 있습니다.