핵심 요구 사항은 "-i any에서 슬레이브 인터페이스를 필터링합니다"로 표현될 수 있습니다.
이 경우 bond0의 VLAN을 떠나는 패킷도 bond0 또는 기본 물리적 인터페이스에 의해 검색되어서는 안 되며, ppp 인터페이스의 경우 ifb 인터페이스에서 트래픽을 다시 보고 싶지도 않습니다.
(다소 복잡한) 구성의 세부 사항:
- bond0은 슬레이브 enp1s0f1 및 enp1s0f1(2 x 10Gbps)을 사용하여 802.3ad에서 실행됩니다.
- 이 외에도 여러 개의 VLAN이 관련되어 있습니다(문제를 일으킬 만큼 충분함). 경우에 따라 이중 표시가 가능합니다.
- 약 50개의 pppoe 서버가 있습니다.
- 다른 VLAN에는 일반 IP/네트워크만 할당됩니다.
- 활성 pppoe + pppol2tp 연결(~200).
- 대부분의 ppp 인터페이스에는 tc를 사용한 수신 형성을 위한 관련 ifb-ppp 인터페이스가 있습니다(미러링 작업 필요).
현재 기본 tcpdump 명령:
tcpdump -vnei any -s0 port 53 and host $loopback_ip
"ether proto 0x0800"을 사용하면 작동하지 않습니다. 이는 물리적 및 bond0에서 802.11q의 에테르 유형이 실제로 0x0800이 아니라 0x8100이기 때문에 거의 이상적입니다(그러나 중첩 유형은 여전히 0x0800이므로 tcpdump 또는 bpf가 일반적으로 여기에서 프레임을 반환하는 이유라고 생각됩니다).
아이디어는 로컬 시스템에 들어가거나 나가는 모든 DNS 패킷의 단일 복사본을 캡처하는 것입니다(방금 라우팅된 패킷과 반대).
출력은 다음과 같습니다(ppp 링크에서 로컬 노드로 단일 패킷이 이동하고 응답이 다시 돌아오는 경우).
12:33:43.996592 ppp155 In ifindex 1428484 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 63, id 14910, offset 0, flags [none], proto UDP (17), length 60)
a.b.c.d.54070 > e.f.g.h.53: 38860+ A? www.google.com. (32)
12:33:43.996598 ifb-ppp155 Out ifindex 1428485 00:00:3f:11:16:20 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 63, id 14910, offset 0, flags [none], proto UDP (17), length 60)
a.b.c.d.54070 > e.f.g.h.53: 38860+ A? www.google.com. (32)
enter code here
12:33:43.996649 ppp155 Out ifindex 1428484 ethertype IPv4 (0x0800), length 96: (tos 0x0, ttl 64, id 18785, offset 0, flags [DF], proto UDP (17), length 76)
e.f.g.h.53 > a.b.c.d.54070: 38860 1/0/0 www.google.com. A 216.58.223.132 (48)
이것은 질문 1입니다. 우리는 ifb 장비를 사용하여 tc 입구 트래픽을 조정합니다. 예, 여기에는 경찰 캐스팅 이상의 것이 있습니다. 그래서 우리는 이 프레임을 두 번 봅니다. ifb-ppp155의 중복은 신경 쓰지 않습니다.
응답은 한 번만 제공되지만 tc가 트래픽을 "리디렉션"하지 않는다는 점을 보면 이는 예상된 결과입니다. 그러면 트래픽이 pppoe로 캡슐화되므로 필터는 관련 VLAN에서 기본 인터페이스(수신과 유사)의 bond0으로 나가는 pppoe 프레임도 필터링합니다.
문제는 트래픽이 원래 VLAN에 있을 때 호스트 아웃바운드를 원격 서버로 쿼리하면 가장 쉽게 설명됩니다.
12:38:55.396412 bond0.2 Out ifindex 7 00:11:0a:69:8f:b0 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 62, id 3629, offset 0, flags [none], proto UDP (17), length 60)
a.b.c.d.36796 > e.f.g.h.53: 21853+ A? www.google.com. (32)
12:38:55.396413 bond0 Out ifindex 6 00:11:81:00:00:02 ethertype IPv4 (0x0800), length 84: IP8 (invalid)
12:38:55.396414 enp1s0f0 Out ifindex 2 00:11:81:00:00:02 ethertype IPv4 (0x0800), length 84: IP8 (invalid)
12:38:55.396476 enp1s0f1 In ifindex 3 48:df:81:00:00:02 ethertype IPv4 (0x0800), length 100: IP15 (invalid)
12:38:55.396476 bond0 In ifindex 6 48:df:81:00:00:02 ethertype IPv4 (0x0800), length 100: IP15 (invalid)
12:38:55.396476 bond0.2 In ifindex 7 48:df:37:3d:f5:c4 ethertype IPv4 (0x0800), length 96: (tos 0x0, ttl 64, id 47664, offset 0, flags [DF], proto UDP (17), length 76)
e.f.g.h.53 > a.b.c.d.36796: 21853 1/0/0 www.google.com. A 172.217.170.100 (48)
강조를 위해 추가 줄 바꿈을 추가합니다. 이 "6" 패킷은 실제로는 2개에 불과합니다. 나는 "(잘못된)" 출력을 제공하는 것을 원하지 않습니다. 이상적으로는 커널에서 사용자 공간으로 세 번 복사되지 않고 한 번만 복사되도록 bpf 필터를 통과해서는 안 됩니다.
현재로서는 bond0.2에서 캡처하는 트래픽만으로는 DNS 기반 공격(특히 오늘날 헤드라인을 장식하는 대규모 중단)에 대한 정보를 수집하기에 충분하지 않으므로 필터를 -i로 확장하면 어떤 이유로든 너무 많은 트래픽이 캡처됩니다. 결국 일을 엉망으로 만듭니다. 하나 이상의 클라이언트 라우터가 특수하게 조작된 조회를 수행하여 바람직하지 않은 동작이 발생하는 것으로 의심됩니다. 알려진 DNS 권한 있는 호스트로 향하지 않는 네트워크 에지에서 인바운드 DNS 쿼리를 차단하고 있습니다.
지금 당장 생각할 수 있는 유일한 다른 가능성은 실제로 iptables의 NFLLOG를 사용하여 관련 INPUT 및 OUTPUT 프레임을 특수 제작된 사용자 공간 애플리케이션에 보내는 것입니다. 이는 결국 좋은 방법이 될 수 있지만, 우리가 사용할 수 있을지 생각합니다. tcpdump를 사용하여 원시 데이터를 수집한 다음 Wireshark 또는 유사한 도구를 사용하여 공격 벡터를 추적할 수 있어야 합니다. 그리고 전용 애플리케이션을 구축하는 것보다 더 빨라야 합니다.