여러 소스에서 ERSPAN 트래픽을 수신하는 Ubunutu 18.04 LTS 서버가 있습니다.
ERSPAN에 익숙하지 않은 사람들을 위해 설명하자면, 이를 달성하기 위해 GRE 터널을 사용하여 원래 L3 패킷을 다른 L3 패킷으로 래핑하고 원래 패킷 소스/대상 IP, 페이로드, L2 세부 정보 등을 보존합니다.
서버는 개인 인터페이스(이 경우 ens192)에서 트래픽을 수신하지만 IDS가 트래픽을 처리할 때 트래픽을 캡슐화 해제(GRE 헤더 제거)하지 않으며 소스(ERSPAN 소스)와 대상(우분투 서버)만 표시됩니다. ...원본/대상 IP가 발견되면 IDS는 해당 정보 처리를 중지하기 때문입니다.
이 문제를 해결하기 위해 RCDCAP를 사용해 보았지만 메모리 손상 문제로 인해 짧은 시간 내에 충돌이 발생했습니다. 이 문제를 RCDCAP 개발자에게 전달했으며 그들은 이 문제를 해결하려고 노력했지만 아직 성공하지 못했습니다.
나는 현재 이 작업을 수행하는 커널의 능력을 조사하고 있습니다. 커널 모듈 ip_gre에는 ERSPAN Type I, Type II 및 Type III에 대한 지원이 포함되어 있습니다.
우분투 서버에서 다음을 수행했습니다.
#load ip_gre module into kernel
modprobe ip_gre
#create tunnel in gre mode set local and remote ends of tunnel and turn link up
ip tunnel add tun0 mode gre local 10.10.1.20 remote 10.10.1.143 ttl 255
ip link set tun0 up
#assign IP address to tunnel interface
ip addr add 10.10.1.20/24 dev tun0
이렇게 하면 터널이 성공적으로 생성되지만 GRE 트래픽을 처리하지 않고 연결된 GRE 헤더를 유지합니다.
GRE 터널을 생성할 때 예상되는 유형을 알려주는 스위치나 무언가가 누락되었습니까? GRE 타입마다 조금씩 차이가 있는데, 타입 I을 기대한다면 감당이 안 되겠죠...
답변1
해결책을 찾았습니다! 저는 ERSPAN 처리 기능이 내장된 Suricata 5.0.3을 사용하고 있지만 기본적으로 비활성화되어 있습니다. suricata.yml(/etc/suricata/suricata.yml)로 이동하여 다음 줄을 "true"로 업데이트했습니다.
erspan:
typeI:
enabled: true
그런 다음 suricata를 시작하고 fast.log를 확인하여 이것이 해결책인지 확인하십시오.