지난 며칠 동안 저는 iptables의 훌륭한 대안이자 더욱 개선되고 안전한 필터링 방법인 PF에 대해 많이 읽었습니다. 그럼에도 불구하고 보안 문제일 수 있다고 생각되는 다음 진술을 발견했습니다.
UDP에서 상태 유지: "UDP는 상태 비저장 프로토콜이기 때문에 UDP를 사용하여 상태를 생성할 수 없습니다!"라는 말을 듣습니다. UDP 통신 세션에는 상태(명시적인 통신 시작 및 중지) 개념이 없습니다. , 이는 UDP 세션에 대한 상태를 생성하는 PF의 기능에 영향을 미치지 않습니다. "시작" 및 "종료" 패킷이 없는 프로토콜의 경우 PF는 일치하는 패킷이 들어온 이후 경과한 시간만 추적합니다. 시간 초과에 도달하면 상태가 지워집니다. 시간 초과 값은 pf.conf 파일의 옵션 섹션에서 설정할 수 있습니다.
내 우려사항:UDP에는 SequenceNr이 없습니다. 따라서 공격자가 UDP 스트림(pf의 상태 테이블에서 상태를 수신한 후)을 도청하면 스푸핑된 패킷을 쉽게 삽입한 다음 방화벽을 통과할 수 있습니다. 그렇지 않습니까?
이것은 큰 보안 문제가 아닌가? 아니면 제가 pf 메커니즘에 대해 뭔가 오해하고 있는 걸까요?
답변1
사례 1: 방화벽 내부의 UDP 클라이언트가 UDP 서버와의 통신을 시작합니다. 방화벽은 대화를 계속할 수 있도록 매핑 항목을 만듭니다. 공격자는 이를 사용하여 일부 패킷을 역스푸핑합니다.
첫째, 패킷은 서버에서 오는 것처럼 스푸핑되어야 합니다. 그렇지 않으면 원격 주소와 일치하지 않습니다. 또한 클라이언트의 IP 및 UDP 포트로 연결되어야 합니다. 그렇지 않으면 방화벽을 통과할 수 없습니다. 따라서 이러한 스푸핑된 패킷은 서버에서 온 것으로 생각하는 클라이언트에 도착합니다. 클라이언트 응용 프로그램의 데이터그램 소켓이 서버에 연결된 것으로 표시되어 있어도 클라이언트 응용 프로그램에서 패킷을 수신합니다. 애플리케이션이 안전하게 작성되면 무결성 검사(암호화 및 체크섬)에 실패하므로 결국 내부 프로토콜 수준에서 폐기됩니다. 물론, 스푸핑된 UDP 데이터그램은 본질적으로 안전하지 않은 애플리케이션에 큰 타격을 줄 수 있습니다. 이는 방화벽의 잘못이 아닙니다.
사례 2: 방화벽 내부의 UDP 서버에는 영구 포트 전달 기능이 있습니다. 물론 누구나 UDP를 보낼 수 있습니다. 패킷의 유효성을 검사하고 안전하고 인증된 세션만 지원하면 됩니다.
답변2
다른 모든 방화벽은 패킷이 NAT 뒤의 장치로 반환될 수 있도록 일종의 "상태"를 유지해야 하거나 다른 유형의 인바운드 차단(응답은 허용하지만 새 데이터는 차단)을 유지해야 한다는 점에서 PF와 동일한 문제를 겪게 됩니다. 가방) .
답변3
설명하는 시나리오에서는 이는 심각한 위험이 아닙니다.
UDP 트래픽을 도청할 수 있는 공격자는 이미 매우 유리한 위치에 있습니다. 실제로 연결 추적 테이블에 연결이 나열되는지 여부는 특별히 관련이 없습니다.
네트워크 관점에서 공격자는 종종 a) 호스트에 들어오고 나가는 트래픽과 데이터를 관찰하고 b) 해당 데이터 중 일부를 특정 목적에 맞게 수정하기를 원합니다. 대상에 따라 이 정보는 호스트나 엔터티를 가장하고, 호스트를 손상시키려는 시도, 다른 호스트를 공격하는 데 사용될 수 있습니다.