서버 보안을 위한 효과적인 방화벽 정책을 선택하는 방법

소개

방화벽을 사용하는 것은 구문을 배우는 것만큼이나 지능적인 정책 결정을 내리는 것입니다. iptables와 같은 방화벽은 관리자가 설정한 규칙을 해석하여 정책을 시행하도록 설계되었습니다. 그러나 관리자는 인프라에 적합한 규칙 유형을 알아야 합니다.

다른 가이드는 설정 및 실행에 필요한 명령에 중점을 두지만 이 가이드에서는 방화벽을 구현할 때 내려야 할 몇 가지 결정에 대해 설명합니다. 이러한 선택은 방화벽 작동 방식, 서버 잠금 방식 및 발생하는 다양한 조건에 대한 응답 방식에 영향을 미칩니다. 구체적인 예로 iptables를 사용할 것이지만 대부분의 개념은 광범위하게 적용할 수 있습니다.

기본 정책 결정

방화벽을 구축할 때 가장 중요한 결정 중 하나는 기본 정책입니다. 이는 트래픽이 다른 규칙과 일치하지 않을 때 발생하는 상황을 결정합니다. 기본적으로 방화벽은 이전 규칙과 일치하지 않는 모든 트래픽을 ACCEPT하거나 해당 트래픽을 DROP할 수 있습니다.

기본 드롭 대 기본 수락

ACCEPT의 기본 정책은 일치하지 않는 모든 트래픽이 서버에 들어올 수 있음을 의미합니다. 이는 일반적으로 권장되지 않는데, 그 이유는 원하지 않는 모든 트래픽을 차단하면서 역방향으로 작업해야 함을 의미하기 때문입니다. 차단 목록 유형의 접근 방식은 모든 유형의 원치 않는 트래픽을 예상하고 차단해야 하기 때문에 관리하기 어렵습니다. 이로 인해 유지 관리 문제가 발생할 수 있으며 일반적으로 실수, 잘못된 구성 및 기존 정책의 예상치 못한 허점이 발생하기 쉽습니다.

대안은 DROP의 기본 정책입니다. 즉, 명시적 규칙과 일치하지 않는 트래픽은 허용되지 않습니다. 각각의 모든 서비스는 명시적으로 허용되어야 하며 이는 상당한 양의 사전 구성처럼 보일 수 있습니다. 그러나 이는 정책이 보안을 지향하고 서버에서 트래픽을 수신하도록 허용된 항목을 정확히 알고 있음을 의미합니다. 또한 거의 모든 사전 구성된 정책이 이 접근 방식을 따르므로 기존 기본값을 기반으로 구축할 수 있습니다.

기본 삭제 정책 대 최종 삭제 규칙

기본 드롭 정책의 선택은 또 다른 미묘한 결정으로 이어집니다. iptables 및 기타 유사한 방화벽을 사용하면 방화벽의 기본 제공 정책 기능을 사용하여 기본 정책을 설정하거나 규칙 목록 끝에 포괄 삭제 규칙을 추가하여 구현할 수 있습니다.

이 두 가지 방법의 차이점은 방화벽 규칙이 플러시되는 경우 발생하는 상황으로 귀결됩니다.

방화벽의 기본 제공 정책 기능이 DROP로 설정되고 방화벽 규칙이 플러시(재설정)되거나 특정 일치 규칙이 제거되면 서비스에 즉시 원격으로 액세스할 수 없게 됩니다. 이는 규칙이 제거된 경우 서버가 악의적인 트래픽에 노출되지 않도록 중요하지 않은 서비스에 대한 정책을 설정할 때 좋은 생각입니다.

이 접근 방식의 단점은 허용 규칙을 다시 설정할 때까지 클라이언트가 서비스를 완전히 사용할 수 없다는 것입니다. 대안으로 로컬 또는 웹 기반 원격 액세스가 없는 경우 잠재적으로 서버에서 자신을 잠글 수도 있습니다.

기본 제공 정책 기능을 사용하여 삭제 정책을 설정하는 대신 방화벽의 기본 정책을 ACCEPT로 설정한 다음 일반 규칙으로 DROP 정책을 구현하는 것입니다. 나머지 일치하지 않는 모든 트래픽을 일치시키고 거부하는 일반 방화벽 규칙을 체인 끝에 추가할 수 있습니다.

이 경우 방화벽 규칙이 플러시되면 서비스에 액세스할 수 있지만 보호되지는 않습니다. 로컬 또는 대체 액세스에 대한 옵션에 따라 규칙이 삭제된 경우 서버에 다시 들어갈 수 있도록 하기 위해 필요한 악일 수 있습니다. 이 옵션을 사용하기로 결정한 경우 포괄 규칙이 항상 규칙 세트의 마지막 규칙으로 남아 있는지 확인하십시오.

트래픽 삭제 및 거부

패킷이 의도한 목적지에 도달하지 못하도록 하는 몇 가지 방법이 있습니다. 이들 사이의 선택은 클라이언트가 연결 시도를 인식하는 방식과 요청이 처리되지 않을 것임을 얼마나 빨리 결정할 수 있는지에 영향을 미칩니다.

패킷을 거부할 수 있는 첫 번째 방법은 DROP입니다. 삭제는 기본 정책 또는 일치 규칙의 대상으로 사용할 수 있습니다. 패킷이 삭제되면 iptables는 패킷을 그냥 버립니다. 연결을 시도하는 클라이언트에게 응답을 보내지 않으며 문제의 패킷을 수신한 적이 있다는 표시도 제공하지 않습니다. 이는 클라이언트(합법적이든 아니든)가 패킷 수신 확인을 받지 못한다는 것을 의미합니다.

TCP 연결 시도(예: 웹 브라우저에 의한 연결)의 경우 제한 시간에 도달할 때까지 연결이 중단됩니다. UDP 클라이언트에 대한 응답 부족은 훨씬 더 모호합니다. 실제로 UDP 패킷을 다시 수신하지 않는 것은 종종 패킷이 수락되었다는 표시입니다. UDP 클라이언트가 패킷 수신에 관심이 있는 경우 패킷이 수락되었는지, 전송 중 손실되었는지 또는 삭제되었는지 확인하기 위해 패킷을 다시 보내야 합니다. 이것은 악의적인 행위자가 서버 포트의 상태에 대한 정보를 얻기 위해 소비해야 하는 시간을 증가시킬 수 있지만 합법적인 트래픽에 문제를 일으킬 수도 있습니다.

트래픽 삭제의 대안은 허용하지 않는 패킷을 명시적으로 거부하는 것입니다. ICMP(Internet Control Message Protocol)는 TCP 또는 UDP와 같은 기존 통신 프로토콜에 의존하지 않는 대역외 채널로서 호스트 간에 상태, 진단 및 오류 메시지를 전송하기 위해 인터넷 전체에서 사용되는 메타 프로토콜입니다. DROP 대상 대신 REJECT 대상을 사용하면 트래픽이 거부되고 ICMP 패킷이 발신자에게 반환되어 트래픽이 수신되었지만 수신되지 않음을 알립니다. 수락됩니다. 상태 메시지를 포함하여 이유를 제공할 수도 있습니다.

여기에는 여러 가지 결과가 있습니다. ICMP 트래픽이 클라이언트에 도달할 수 있다고 가정하면 트래픽이 차단되었다는 알림을 즉시 받게 됩니다. 합법적인 클라이언트의 경우 이는 관리자에게 연락하거나 연결 옵션을 확인하여 올바른 포트에 도달하고 있는지 확인할 수 있음을 의미합니다. 악의적인 사용자의 경우 이는 스캔을 완료하고 더 짧은 시간 내에 개방, 폐쇄 및 필터링된 포트를 매핑할 수 있음을 의미합니다.

트래픽을 삭제할지 거부할지 결정할 때 고려해야 할 사항이 많습니다. 한 가지 중요한 고려 사항은 대부분의 악성 트래픽이 실제로 자동화된 스크립트에 의해 실행된다는 것입니다. 이러한 스크립트는 일반적으로 감독되지 않기 때문에 불법 트래픽을 삭제해도 유의미하게 차단되지 않으며 합법적인 사용자에게 부정적인 영향을 미칩니다. 이 주제에 대한 자세한 내용은 Peter Benie의 웹사이트에서 확인할 수 있습니다.

드롭 대 거부 응답 테이블

아래 표는 방화벽으로 보호되는 서버가 대상 포트에 적용되는 정책에 따라 다양한 요청에 어떻게 반응하는지 보여줍니다.

첫 번째 열은 클라이언트가 보낸 패킷 유형을 나타냅니다. 두 번째 열에는 각 시나리오를 테스트하는 데 사용할 수 있는 nmap 명령이 포함되어 있습니다. 세 번째 열은 포트에 적용되는 포트 정책을 나타냅니다. 네 번째 열은 서버가 다시 보낼 응답이고 다섯 번째 열은 클라이언트가 받은 응답을 기반으로 포트에 대해 유추할 수 있는 것입니다.

ICMP 정책

거부된 트래픽을 삭제할지 또는 거부할지를 결정할 때와 마찬가지로 서버로 향하는 ICMP 패킷을 수락하거나 거부할 수 있습니다.

ICMP는 많은 일에 사용되는 프로토콜입니다. 언급했듯이 다른 프로토콜을 사용하는 요청에 대한 상태 정보를 제공하기 위해 종종 다시 전송됩니다. 가장 많이 사용되는 기능 중 하나는 네트워크 핑을 보내고 응답하여 원격 호스트에 대한 연결 가능성을 확인하는 것입니다. 널리 알려지지는 않았지만 여전히 유용한 ICMP의 다른 많은 용도가 있습니다.

ICMP 패킷은 \유형\으로 구성되고 \코드\로 구성됩니다. 유형은 메시지의 일반적인 의미를 지정합니다. 예를 들어 유형 3은 대상에 도달할 수 없음을 의미합니다. 코드는 종종 유형에 대한 추가 정보를 제공하는 데 사용됩니다. 예를 들어 ICMP 유형 3 코드 3은 대상 포트를 사용할 수 없음을 의미하고 ICMP 유형 3 코드 0은 대상 네트워크에 연결할 수 없음을 의미합니다.

일부 ICMP 유형은 더 이상 사용되지 않으므로 무조건 차단될 수 있습니다. 그 중에는 ICMP 소스 퀀치(유형 4 코드 0)와 대체 호스트(유형 6)가 있습니다. 유형 1, 2, 7 및 유형 15 이상은 모두 더 이상 사용되지 않거나 향후 사용을 위해 예약되거나 실험적입니다. 많은 업스트림 방화벽 템플릿이 기본적으로 이를 처리합니다.

네트워크 구성에 따라 차단할 유형

일부 ICMP 유형은 특정 네트워크 구성에서 유용하지만 다른 유형에서는 차단되어야 합니다.

예를 들어 ICMP 리디렉션 메시지(유형 5)는 잘못된 네트워크 설계를 밝히는 데 유용할 수 있습니다. 클라이언트에서 더 나은 경로를 직접 사용할 수 있을 때 ICMP 리디렉션이 전송됩니다. 따라서 라우터가 동일한 네트워크의 다른 호스트로 라우팅되어야 하는 패킷을 수신하면 ICMP 리디렉션 메시지를 보내 클라이언트에게 향후 다른 호스트를 통해 패킷을 보내도록 지시합니다.

이는 로컬 네트워크를 신뢰하고 초기 구성 중에 라우팅 테이블의 비효율성을 발견하려는 경우에 유용합니다. 신뢰할 수 없는 네트워크에서 악의적인 사용자가 잠재적으로 ICMP 리디렉션을 보내 호스트의 라우팅 테이블을 조작할 수 있습니다.

일부 네트워크에서는 유용하고 다른 네트워크에서는 잠재적으로 유해한 다른 ICMP 유형은 ICMP 라우터 광고(유형 9) 및 라우터 요청(유형 10) 패킷입니다. 라우터 광고 및 요청 패킷은 호스트가 네트워크를 부팅하거나 가입할 때 사용 가능한 라우터를 동적으로 검색할 수 있도록 하는 시스템인 IRDP(ICMP 인터넷 라우터 검색 프로토콜)의 일부로 사용됩니다.

대부분의 경우 호스트가 사용할 게이트웨이에 대해 정적 경로를 구성하는 것이 좋습니다. 이러한 패킷은 ICMP 리디렉션 패킷과 동일한 상황에서 수락되어야 합니다. 실제로 호스트는 검색된 경로의 트래픽에 대해 선호하는 경로를 알지 못하기 때문에 검색 직후 리디렉션 메시지가 필요한 경우가 많습니다. 라우터 요청 패킷을 전송하거나 광고 패킷(예: rdisc)을 기반으로 경로를 수정하는 서비스를 실행하지 않는 경우 이러한 패킷을 안전하게 차단할 수 있습니다.

종종 허용하기에 안전한 유형

일반적으로 허용해도 안전한 ICMP 유형은 다음과 같으나 더 주의해야 할 경우 비활성화할 수 있습니다.

• 유형 8 — 에코 요청: 서버로 향하는 핑 요청입니다. 일반적으로 이러한 패킷을 허용하는 것이 안전하지만(이러한 패킷을 거부해도 서버가 숨겨지지는 않습니다. 사용자가 호스트가 작동 중인지 확인할 수 있는 다른 방법이 많기 때문입니다.) 이러한 패킷을 차단하거나 응답하는 소스 주소를 제한할 수 있습니다. 원한다면.
• 유형 13 — 타임스탬프 요청: 이 패킷은 클라이언트가 대기 시간 정보를 수집하는 데 사용할 수 있습니다. 일부 OS 핑거프린팅 기술에 사용될 수 있으므로 이를 차단하거나 응답하는 주소 범위를 제한할 수 있습니다.

아래 유형은 일반적으로 요청에 대한 응답을 허용하도록 방화벽을 구성하여 명시적인 규칙 없이 허용할 수 있습니다. 트래픽).

• 유형 0 — 에코 응답: 에코 요청(핑)에 대한 응답입니다.
• 유형 3 - 대상에 도달할 수 없음: 적법한 대상에 도달할 수 없는 패킷은 패킷을 전달할 수 없음을 나타내는 서버에서 생성한 요청에 대한 응답입니다.
• 유형 11 — 시간 초과: 서버에서 생성된 패킷이 TTL 값을 초과하여 대상에 도달하기 전에 죽은 경우 반환되는 진단 오류입니다.
• 유형 12 - 매개변수 문제: 서버에서 나가는 패킷의 형식이 잘못되었음을 의미합니다.
• 유형 14 — 타임스탬프 응답: 서버에서 생성한 타임스탬프 쿼리에 대한 응답입니다.

일부 보안 전문가는 들어오는 모든 ICMP 트래픽을 차단하는 것을 권장하지만 현재 많은 사람들이 지능적인 ICMP 수락 정책을 권장합니다. 스레드에 더 많은 정보가 있습니다.

연결 제한 및 속도 제한

일부 서비스 및 트래픽 패턴의 경우 클라이언트가 해당 액세스를 남용하지 않는 경우에만 액세스를 허용할 수 있습니다. 리소스 사용을 제한하는 두 가지 방법은 연결 제한과 속도 제한입니다.

연결 제한

connlimit와 같은 확장을 사용하여 연결 제한을 구현하여 클라이언트가 열어 놓은 활성 연결 수를 확인할 수 있습니다. 한 번에 허용되는 연결 수를 제한하는 데 사용할 수 있습니다. 연결 제한을 적용하기로 결정한 경우 몇 가지 결정을 내려야 합니다.

• 주소당, 네트워크당 또는 글로벌 기준으로 제한합니까?
• 특정 서비스 또는 서버 전체에 대한 트래픽을 일치시키고 제한합니까?

호스트별로 연결을 제한하거나 네트워크 접두사(예: 전체 조직의 IP 주소 범위)를 제공하여 네트워크 세그먼트에 대한 제한을 설정할 수 있습니다. 서비스 또는 전체 시스템에 대한 전역 최대 연결 수를 설정할 수도 있습니다. 연결 번호를 제어하기 위해 보다 복잡한 정책을 생성하기 위해 이들을 혼합하고 일치시킬 수 있음을 명심하십시오.

속도 제한

속도 제한을 사용하면 서버에서 트래픽을 허용하는 속도 또는 빈도를 제어하는 규칙을 구성할 수 있습니다. limit, hashlimit 및 recent를 포함하여 속도 제한에 사용할 수 있는 다양한 방화벽 확장이 있습니다. 사용하는 확장 프로그램의 선택은 주로 트래픽을 제한하려는 방식에 따라 달라집니다.

limit 확장은 제한에 도달할 때까지 문제의 규칙을 일치시키고 그 후에 추가 패킷이 삭제되도록 합니다. 5/초와 같은 제한은 초당 5개의 패킷 일치를 허용하며 그 이후에는 규칙이 더 이상 일치하지 않습니다. 이는 서비스에 대한 전역 속도 제한을 설정하는 데 유용합니다. Fail2ban과 같은 추가 서비스를 배포하여 반복되는 연결 시도를 차단할 수도 있습니다.

hashlimit 확장은 더 유연하여 일치를 평가하기 위해 iptables가 해시할 일부 값을 지정할 수 있습니다. 예를 들어 소스 주소, 소스 포트, 대상 주소, 대상 포트 또는 이러한 네 가지 값의 조합을 확인하여 각 항목을 평가할 수 있습니다. 패킷 또는 수신된 바이트로 제한할 수 있습니다. 이는 클라이언트별 또는 서비스별 속도 제한을 유연하게 제공합니다.

recent 확장은 동적으로 클라이언트 IP 주소를 목록에 추가하거나 규칙이 일치할 때 기존 목록을 확인합니다. 이를 통해 복잡한 패턴에 대한 다양한 규칙에 제한 논리를 분산시킬 수 있습니다. 다른 리미터와 마찬가지로 적중 횟수와 시간 범위를 지정하는 기능이 있지만 추가 트래픽이 표시되면 시간 범위를 재설정하여 클라이언트가 제한된 경우 모든 트래픽을 중지하도록 할 수 있습니다.

모놀리식 대 체인 기반 관리

모든 iptables 및 nftables 방화벽 정책은 기본적으로 내장 체인 확장에 뿌리를 두고 있습니다. 처음에는 일반적으로 기존 체인에 대한 기본 정책을 변경하고 규칙을 추가하는 것을 의미합니다. 보다 복잡한 방화벽의 경우 추가 체인을 생성하여 관리 프레임워크를 확장하는 것이 좋습니다.

사용자가 만든 체인은 2차적으로 호출되며 본질적으로 해당 체인이 시작된 \호출 체인\에 연결됩니다. 사용자가 만든 체인에는 기본 정책이 없으므로 패킷이 사용자가 만든 체인을 통과하면 이를 염두에 두고 사용자가 만든 체인은 규칙 일치 조건을 보다 유지 관리하기 쉽게 만들고 일치 조건을 분할하여 가독성을 향상시키는 조직 목적에 주로 유용합니다.

많은 수의 규칙에 대해 특정 일치 기준을 반복하는 경우 공유 일치 기준을 사용하여 새 체인에 점프 규칙을 만드는 것이 좋습니다. 새 체인 내에서 중복 일치 기준이 생략된 규칙 집합을 추가할 수 있습니다.

모든 규칙을 내장된 체인 중 하나로 묶을 것인지 또는 추가 체인을 만들고 활용할 것인지에 대한 결정은 규칙 세트가 얼마나 복잡한지에 따라 달라집니다.

결론

이제 서버에 대한 방화벽 정책을 설계할 때 내려야 할 결정에 대해 더 잘 이해할 수 있을 것입니다. 일반적으로 방화벽과 관련된 시간 투자는 초기 설정에 크게 치우칩니다. 요구 사항에 가장 적합한 정책을 찾는 데 약간의 시간과 실험이 필요할 수 있지만 그렇게 하면 서버의 보안을 더 잘 제어할 수 있습니다.

방화벽과 iptables에 대해 자세히 알고 싶다면 다음 문서를 확인하세요.

• Iptables 방화벽 작동 방식
• Iptables 및 Netfilter 아키텍처에 대한 심층 분석

다음 가이드는 정책을 구현하는 데 도움이 될 수 있습니다. 방화벽과 일치하는 가이드를 선택하여 시작하세요.

• Ubuntu 22.04에서 Nftables를 사용하여 방화벽을 설정하는 방법
• Ubuntu 22.04에서 UFW로 방화벽을 설정하는 방법
• Rocky Linux 9에서 FirewallD를 사용하여 방화벽을 설정하는 방법