IP 스푸핑 공격을 예방하는 방법

배송 경로를 확인하는 일과 누가 들어올 수 있는지 결정하는 일은 별개입니다. 출발지 검증과 인증에는 각각의 통제 수단이 필요합니다.

안내 데스크는 배송물이 예상한 경로로 왔는지 확인할 수 있습니다. 이를 받는 사람은 여전히 누가 건물 안으로 들어올 수 있는지 결정해야 합니다. 네트워크에도 비슷한 역할 분담이 있습니다. 트래픽이 어디에서 왔다고 주장하는지 검증한 다음, 서비스 접근을 인증하는 것입니다.

첫 번째 검사를 출발지 가까이에 배치하기

네트워크 운영자는 고객의 연결을 통해 어떤 주소 범위가 들어와야 하는지 알고 있습니다. 무관한 출발지를 주장하는 패킷은 더 멀리 이동하기 전에 그곳에서 거부할 수 있습니다. 이것이 BCP 38에 설명된 출발지 검증 방식입니다.

기업 네트워크에서는 외부에서 들어오는 트래픽뿐 아니라 인터넷으로 나가는 트래픽도 확인하세요. 같은 경계가 한 네트워크에서는 출구이고 다른 네트워크에서는 입구입니다. 모든 곳에 하나의 일괄 규칙을 적용하기보다, 정당하게 위임된 주소 범위를 포함해 각 연결에서 예상되는 출발지를 정의해야 합니다.

범위 검사는 패킷 뒤에 있는 사람이 누구인지 식별하지 않습니다. 허용된 범위 안에서는 위조의 여지를 남길 수도 있습니다. 유용한 경계 통제 수단으로 다뤄야 하며, 신원 증명서로 여겨서는 안 됩니다.

역방향 경로 검사를 실제 경로에 맞추기

유니캐스트 역방향 경로 전달, 즉 uRPF는 패킷의 출발지를 라우팅 정보와 비교합니다. 엄격 모드에서는 들어오는 인터페이스가 선택된 반환 경로와 일치해야 합니다. 경로를 예측할 수 있는 환경에서는 잘 작동할 수 있습니다.

그러나 정상 트래픽이 한 연결로 들어와도 최적의 반환 경로는 다른 연결을 사용할 수 있습니다. 비대칭 라우팅과 여러 제공업체를 사용하는 네트워크에서 이런 일이 발생합니다. 이때 엄격한 검사는 유효한 트래픽을 버릴 수 있습니다. RFC 3704는 이러한 절충점을 설명합니다. 실행 가능한 경로를 고려하는 방식은 허용된 대체 경로도 살펴봅니다. 느슨한 검사는 일반적으로 경로가 존재하는지만 확인하므로 검증 강도가 더 약합니다. 장애 전환을 포함한 실제 토폴로지에 맞춰 모드를 선택하고 검증하세요.

서비스와 사용자 인증하기

주소 제한이 유용한 곳에서는 유지하되, 민감한 접근을 허용하는 유일한 신원 증거로 삼아서는 안 됩니다. 웹 서비스에는 올바르게 검증된 TLS를 사용하고, 관리 작업과 네트워크 피어에는 적절한 인증 프로토콜을 사용하세요. 계정 인증과 권한에는 여전히 각각의 역할이 있습니다.

TLS 1.3은 서버를 인증하며 클라이언트도 인증할 수 있고, 애플리케이션 트래픽을 보호합니다. 하지만 모든 IP 출발지 주소를 보증하거나 트래픽 폭주로 링크가 고갈되는 것을 막지는 않습니다. 암호화와 출발지 검증은 서로 다른 대상을 보호합니다.

반사 공격의 기회 줄이기

재귀 DNS를 운영한다면 서비스를 제공하려는 클라이언트만 재귀 질의를 이용하도록 제한하세요. 이는 자신의 도메인에 대해 일반 대중의 질의에 응답해야 할 수 있는 권한 DNS와는 다릅니다. RFC 5358은 개방형 재귀 기능이 서버를 반사체로 만들 수 있는 이유를 설명합니다.

외부에 노출된 다른 서비스도 불필요하게 접근 가능한 부분이나 지나치게 큰 응답이 있는지 점검하세요. 사고가 나기 전에 상위망의 DDoS 지원을 계획해야 합니다. 트래픽이 서버에 도달하기 전에 연결이 이미 포화되었다면, 서버 자체의 필터링으로 그 연결을 복구할 수 없습니다.

IPv6에도 같은 판단이 필요하다

IPv6로 전환한다고 암호화가 자동으로 켜지거나 출발지 스푸핑이 방지되는 것은 아닙니다. IPsec에는 의도적인 구성과 키 관리가 필요하며, 두 IP 버전 모두에서 사용할 수 있습니다. IPv6 운영 보안 지침은 실제로 필요한 통제 수단을 다룹니다. 듀얼 스택 네트워크에서는 두 경로를 모두 평가하고 시험하세요.

서비스를 해치지 않으면서 보호가 작동하는지 확인하기

예상 주소 범위와 경로를 기록하고, 허가된 트래픽과 장애 전환을 시험한 다음, 패킷 폐기와 서비스 상태를 살펴보세요. 침입 탐지 시스템은 패턴을 알려 줄 수 있지만, 차단에는 예방 기능이나 운영자의 대응이 필요합니다. 로그는 무슨 일이 일어났는지 설명하는 데 도움이 되어야 하며, 주장된 출발지를 추정된 신원으로 바꿔서는 안 됩니다.

일반 인터넷 이용자는 업데이트, 인증된 연결, 계정 보안에 집중하세요. 필요하면 제공업체에 출발지 필터링에 대해 문의할 수 있습니다. 브라우저에서 상위망의 패킷 검증을 고칠 수는 없습니다. 배경을 이해하려면 위조된 출발지가 작동하는 방식이나 각 통제 수단이 대응하는 공격 패턴을 읽어 보세요.