Billion의 모든 포트를 여는 OSX mDNSResponder

Billion의 모든 포트를 여는 OSX mDNSResponder

최근에 라우터를 Billion 7800VDOX로 교체했는데 외부 주소에서 iMac에 대한 연결 시도가 일부 발견되었습니다. 조사 결과 포트 범위 0-0(내부 및 외부)을 사용하여 라우터에서 uPnP 포트가 열려 있음을 발견했습니다. 이는 외부 포트 스캐너로 확인한 결과 라우터의 모든 포트 번호를 열고 다음으로 전달하는 효과가 있습니다. 아이맥. 매핑을 삭제하고 Wireshark를 실행하여 매핑이 복원됨과 동시에 외부 주소 요청을 캡처했습니다.

Frame 496: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
Ethernet II, Src: Apple_d0:7e:eb (d4:9a:20:d0:7e:eb), Dst: BillionE_cb:49:27 (00:04:ed:cb:49:27)
Internet Protocol Version 4, Src: 192.168.1.131, Dst: 192.168.1.254
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5351 (5351)
Source Port: 5353
Destination Port: 5351
Length: 68
Checksum: 0x8527 [validation disabled]
[Stream index: 0]
Port Control Protocol, Map Request
Version: 2
0... .... = R: Request
.000 0001 = Opcode: Map (1)
Reserved: 0
Requested Lifetime: 7200
Client IP Address: ::ffff:192.168.1.131
Map Request
    Mapping Nonce: f88237920f8cd6c0a3765f39
    Protocol: 6
    Reserved: 0
    Internal Port: 9
    Suggested External Port: 0
    Suggested External IP Address: ::ffff:xxx.181.81.112

이는 라우터의 외부 IP 주소를 가져오기 위한 SOAP 요청이 선행되었습니다. lsof로 소스 포트(5353)를 확인해보니 mDNSResponder가 소유하고 있는 것으로 나타났습니다.

무슨 일이 일어나고 있는지에 대한 내 가정은 mDNSResponder가 라우터의 외부 IP 주소를 얻기 위해 이것을 사용하고 있으며 잘못된 포트여야 하는 포트 0을 매핑하기 위해 무해한 것으로 추정되는 요청을 사용하여 그렇게 하고 있다는 것입니다. 그러나 Billion 라우터는 이를 모든 포트를 열어 달라는 요청으로 설계 또는 프로그래밍 오류로 처리하고 있습니다. 라우터에서 uPnP를 끄면 문제가 해결됩니다(지적한 바와 같이 실제로는 uPnP가 아님).

누구든지 다른 제안이 있나요?

답변1

캡처한 패킷은 포트 제어 프로토콜(PCP: NAT-PMP의 IETF 표준 추적 후속 버전) 포트 매핑 요청을 보여줍니다. 요청된 매핑의 클라이언트 포트는 9/TCP입니다. 클라이언트는 외부 포트가 무엇인지에 대한 제안이 없으므로 제안된 외부 포트 필드를 0으로 설정해 둡니다. PCP를 정의하는 IETF RFC 6887에서는 이 필드에서 0이 "제안 없음"을 의미함을 분명히 합니다.

이 Billion 라우터에 PCP를 구현한 사람이 RFC를 잘못 읽은 것 같습니다. 매우 제한적이고 잘 정의된 일부 경우에는 OTHER 포트 필드의 0이 "모든 포트"를 의미할 수 있습니다. 이 매핑 요청에 대한 요청 수명이 0인 경우와 마찬가지로 0 클라이언트 포트는 "이 클라이언트 IP 주소의 모든 포트에 대한 모든 매핑 삭제"를 의미합니다.

그러나 제안된 외부 포트 필드에서 0은 항상 "제안 없음"을 의미하는 것으로 간주됩니다. 이 필드에서는 "모든 포트"를 의미하지 않습니다.

따라서 이 Billion 라우터에서 PCP 버그를 발견한 것이 분명해 보입니다.

여기서 또 다른 이상한 점은 클라이언트 포트입니다. 전통적으로 9/TCP는 discard서비스의 포트이지만 discard서비스는 더 이상 사용되지 않으므로 누가 이 서비스를 더 이상 실행하는지, 왜 포트 매핑을 요청하는지 잘 모르겠습니다.

mDNSResponder가 이러한 요청을 보내는 이유는 mDNSResponder가 일반적인 mDNS, DNS-SD 및 DNS 확인 작업 외에도 macOS에서 PCP/NAT-PMP/UPnP 데몬 역할을 하기 때문입니다. macOS의 프로세스가 라우터에서 포트 매핑을 요청하도록 시스템을 트리거할 때 실제 포트 매핑 요청 패킷을 생성하고 보내는 것은 항상 mDNSResponder의 작업입니다.

관련 정보