서버를 보호하기 위한 효과적인 방화벽 정책 선택하는 방법

소개

방화벽을 사용하는 것은 구문 학습만큼 지적인 정책 결정을 하는 것과 관련이 있습니다. 방화벽은 iptables와 같이 관리자가 설정한 규칙을 해석하여 정책을 시행하는 데 설계되었습니다. 그러나 관리자로서 인프라에 어떤 유형의 규칙이 합리적인지 알아야합니다.

다른 가이드는 가동 및 실행에 필요한 명령에 중점을 둡니다. 이 가이드에서는 방화벽을 구현할 때 내려야하는 일부 결정에 대해 논의할 것입니다. 이러한 선택은 방화벽의 동작 방식, 서버의 잠금 상태 및 발생하는 다양한 조건에 대한 응답 방식에 영향을 미칩니다. 특정 예시로 iptables을 사용하지만 대부분의 개념은 일반적으로 적용됩니다.

기본 정책 결정

방화벽을 구축할 때 가장 중요한 결정 중 하나는 기본 정책을 결정하는 것입니다. 이것은 교통이 다른 규칙과 일치하지 않을 때 어떻게 처리할지를 결정합니다. 기본적으로 방화벽은 이전 규칙으로 일치하지 않는 교통을 허용하거나 그 교통을 차단할 수 있습니다.

기본적인 차단 대 기본적인 허용

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

대안은 차단으로 설정하는 것입니다. 이것은 명시적인 규칙과 일치하지 않는 모든 교통을 허용하지 않는다는 것을 의미합니다. 각 서비스는 명시적으로 허용되어야 하며, 이는 처음에 상당한 양의 구성을 필요로 할 수 있습니다. 그러나 이것은 귀하의 정책이 보안 쪽으로 향하고 서버에서 교통을 받을 수 있는 것이 무엇인지를 정확히 알 수 있다는 것을 의미합니다. 또한 거의 모든 사전 구성된 정책은 이 접근 방식을 따를 것이므로 기존의 기본값을 기반으로 구성할 수 있습니다.

기본적인 차단 정책 대 최종적인 차단 규칙

기본적인 차단 정책의 선택은 또 다른 세심한 결정으로 이어집니다. iptables 및 기타 유사한 방화벽을 사용하는 경우, 기본 정책은 방화벽의 내장 정책 기능을 사용하여 설정하거나 규칙 목록 끝에 캐치-올 차단 규칙을 추가함으로써 구현할 수 있습니다.

이 두 가지 방법의 차이는 방화벽 규칙이 플러시되는 경우에 어떤 일이 발생하는지에 달려 있습니다.

만약 방화벽의 내장 정책 기능이 DROP으로 설정되어 있고 방화벽 규칙이 플러시되거나 일부 일치하는 규칙이 제거되는 경우, 또는 특정 일치하는 규칙이 제거된 경우 원격으로 서비스에 접근할 수 없게 됩니다. 비 비상급 서비스에 대한 정책을 설정할 때 종종 좋은 아이디어이며, 규칙이 제거되면 악의적인 트래픽에 서버가 노출되지 않도록합니다.

이 방법의 단점은 클라이언트가 권한이 없는 규칙을 재설정 할 때까지 서비스에 완전히 접근할 수 없게됩니다. 대안으로 로컬 또는 웹 기반 원격 액세스가 없는 경우 서버에서 자체 잠금을 해제 할 수도 있습니다.

내장 정책 기능을 사용하여 드롭 정책을 설정하는 대안은 방화벽의 기본 정책을 ACCEPT로 설정한 다음 일반적인 규칙으로 DROP 정책을 구현하는 것입니다. 체인의 끝에 남아있는 모든 일치하지 않는 트래픽을 매칭하고 거부하는 일반적인 방화벽 규칙을 추가 할 수 있습니다.

이 경우 방화벽 규칙이 플러시되면 서비스는 접근 가능하지만 보호되지 않습니다. 로컬 또는 대체 액세스 옵션에 따라서는 이것이 규칙이 플러시 될 경우 서버에 다시 입력 할 수 있도록하는 필요한 악한 선택일 수 있습니다. 이 옵션을 사용하기로 결정하면 모든 남아있는 규칙 세트에서 catch-all 규칙이 항상 마지막 규칙으로 남아 있는지 확인하십시오.

트래픽 버리기 대 거부하기

패킷이 목적지에 도달하지 못하도록 하는 몇 가지 다른 방법이 있습니다. 이 중에서 선택하는 것은 클라이언트가 연결 시도를 인식하는 방식과 그들이 요청이 서비스되지 않을 것으로 판단하는 속도에 영향을 미칩니다.

패킷이 거부되는 첫 번째 방법은 DROP을 사용하는 것입니다. 드롭은 기본 정책으로 사용되거나 매치 규칙의 대상으로 사용될 수 있습니다. 패킷이 드롭되면 iptables은 그것을 단순히 버립니다. 연결을 시도하는 클라이언트에게 응답을 보내지 않으며 문제가 된 패킷을 심지어 받았다는 표시도 하지 않습니다. 이는 클라이언트(합법적이든 아니든)가 자신의 패킷이 수신되었다는 확인을 받지 못할 것이라는 것을 의미합니다.

TCP 연결 시도(예: 웹 브라우저에 의한 연결)의 경우, 연결은 타임아웃 한계에 도달할 때까지 지연됩니다. UDP 클라이언트의 경우 응답이 없는 것이 더욱 모호합니다. 실제로 UDP 패킷을 다시 받지 못하는 것은 종종 패킷이 수락된 것을 의미합니다. UDP 클라이언트가 패킷이 수신되었는지 신경 쓰는 경우, 수락되었는지, 전송 중에 손실되었는지 아니면 드롭되었는지를 확인하기 위해 다시 보내야 합니다. 이는 악의적인 행위자가 서버 포트의 상태에 대한 정보를 얻기 위해 소비해야 할 시간을 증가시킬 수 있지만, 합법적인 트래픽에도 문제를 일으킬 수 있습니다.

대역 트래픽을 버리는 대안은 허용하지 않는 패킷을 명시적으로 거부하는 것입니다. ICMP 또는 인터넷 제어 메시지 프로토콜은 인터넷 전체에서 호스트 간에 상태, 진단 및 오류 메시지를 보내기 위해 사용되는 메타 프로토콜로, TCP 또는 UDP와 같은 전통적인 통신 프로토콜에 의존하지 않는 다른 채널로 작동합니다. DROP 대상 대신 REJECT 대상을 사용하면 트래픽이 거부되고 보낸 사람에게는 ICMP 패킷이 반환되어 그들의 트래픽이 수신되었지만 허용되지 않음을 알립니다. 상태 메시지를 포함하여 이유를 제공할 수도 있습니다.

이로 인해 여러 가지 결과가 발생합니다. ICMP 트래픽이 클라이언트에 도달하는 것이 허용된다고 가정하면, 그들은 즉시 자신의 트래픽이 차단되었음을 알 수 있습니다. 합법적인 클라이언트의 경우, 이는 관리자에게 연락하거나 올바른 포트에 연결되었는지 확인할 수 있는 연결 옵션을 확인할 수 있음을 의미합니다. 악의적인 사용자의 경우, 이는 스캔을 완료하고 열린, 닫힌 및 필터링된 포트를 보다 짧은 시간에 매핑할 수 있음을 의미합니다.

트래픽을 삭제하거나 거부할지 결정할 때 고려해야 할 사항이 많이 있습니다. 중요한 고려 사항 중 하나는 대부분의 악성 트래픽이 사실상 자동화된 스크립트에 의해 수행된다는 것입니다. 이러한 스크립트는 일반적으로 감시되지 않으므로, 부정한 트래픽을 삭제하는 것은 그들을 의미있게 방지하지 않을 뿐만 아니라 합법적인 사용자에게 부정적인 영향을 미칠 것입니다. 이에 대한 자세한 내용은 Peter Benie의 웹사이트에서 찾을 수 있습니다.

드롭 대 거부 응답 테이블

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

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

ICMP 정책

드롭할지 거부할지 결정할 때 거부된 트래픽처럼 서버로 전송된 ICMP 패킷을 수락하거나 거부할 수 있는 옵션이 있습니다.

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

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

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

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

예를 들어, ICMP 리디렉션 메시지 (유형 5)는 나쁜 네트워크 디자인을 밝히는 데 유용할 수 있습니다. ICMP 리디렉션은 클라이언트에게 직접적으로 더 나은 경로가 있는 경우 전송됩니다. 따라서 라우터가 동일한 네트워크의 다른 호스트로 라우팅해야 하는 패킷을 수신하면 미래에 패킷을 다른 호스트를 통해 보내도록 클라이언트에게 ICMP 리디렉션 메시지를 보냅니다.

이것은 로컬 네트워크를 신뢰하고 초기 구성 중에 라우팅 테이블의 비효율성을 확인하려는 경우 유용합니다. 신뢰할 수 없는 네트워크에서는 악의적인 사용자가 호스트의 라우팅 테이블을 조작하기 위해 ICMP 리다이렉트를 전송할 수 있습니다.

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

대부분의 경우, 호스트가 사용할 게이트웨이에 대한 정적 경로가 구성되어 있는 것이 좋습니다. 이러한 패킷은 ICMP 리다이렉트 패킷과 같은 상황에서 허용되어야 합니다. 실제로, 호스트는 발견된 경로의 트래픽에 대한 우선 경로를 알지 못하기 때문에, 리다이렉트 메시지는 발견 직후에 종종 필요합니다. 라우터 요청 패킷을 보내는 서비스를 실행하거나 광고 패킷에 기반하여 경로를 수정하는 서비스를 실행하지 않는 경우 (rdisc와 같은), 이러한 패킷을 안전하게 차단할 수 있습니다.

허용하는 것이 안전한 유형

보통 허용하는 ICMP 유형은 아래와 같지만, 필요 시 추가 조심하려면 이를 비활성화할 수 있습니다.

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

아래의 유형은 일반적으로 방화벽을 구성하여 요청에 대한 응답을 허용하는 conntrack 모듈을 사용하여 암시적 규칙 없이 허용할 수 있습니다.

• 유형 0 – Echo 응답 : 이는 Echo 요청 (핑)에 대한 응답입니다.
• 유형 3 – 대상 도달 불가능 : 합법적인 대상 도달 불가능 패킷은 서버에서 생성한 요청에 대한 응답으로서 패킷이 전달되지 않았음을 나타냅니다.
• 유형 11 – 시간 초과 : 이는 TTL 값이 초과되어 목적지에 도달하기 전에 서버에서 생성한 패킷이 손실된 경우에 반환되는 진단 오류입니다.
• 유형 12 – 매개변수 오류 : 이는 서버에서 발신된 패킷이 잘못되었음을 의미합니다.
• 유형 14 – 타임스탬프 응답 : 이는 서버에서 생성된 타임스탬프 쿼리에 대한 응답입니다.

아래는 일부 보안 전문가들이 여전히 권장하는 들어오는 ICMP 트래픽 차단에 대한 내용입니다. 그러나 많은 사람들은 현재 지능적인 ICMP 수용 정책을 촉구하고 있습니다. 이 두 Stackexchange 쓰레드에는 더 많은 정보가 있습니다.

연결 제한 및 속도 제한

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

연결 제한

연결 제한은 connlimit와 같은 확장을 사용하여 클라이언트가 열어 놓은 활성 연결 수를 확인하여 구현할 수 있습니다. 이를 사용하여 한 번에 허용된 연결 수를 제한할 수 있습니다. 연결 제한을 부과하려면 몇 가지 결정을 내려야 합니다:

• 주소당, 네트워크당 또는 전역적으로 제한할 것인가요?
• 특정 서비스 또는 서버 전체에 대한 트래픽을 일치시키고 제한할 것인가요?

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

비율 제한

비율 제한을 사용하면 서버에서 트래픽을 수락하는 속도나 빈도를 관리하는 규칙을 설정할 수 있습니다. 비율 제한에는 limit, hashlimit, recent 등 다양한 방화벽 확장이 있습니다. 사용하는 확장 프로그램은 주로 트래픽을 제한하는 방식에 따라 다를 것입니다.

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

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

recent 확장은 규칙이 일치할 때 클라이언트 IP 주소를 동적으로 목록에 추가하거나 기존 목록과 비교할 수 있습니다. 이를 통해 복잡한 패턴에 대한 제한 로직을 여러 다른 규칙에 분산시킬 수 있습니다. 다른 제한자와 마찬가지로 히트 카운트와 시간 범위를 지정할 수 있지만 추가 트래픽이 감지되면 시간 범위를 재설정할 수도 있어 클라이언트가 제한을 받으면 모든 트래픽을 중지하도록 강제할 수 있습니다.

Monolithic vs Chain-Based Management

모든 iptables 및 nftables 방화벽 정책은 본질적으로 기본 체인을 확장하는 데 중점을 둡니다. 일반적으로 이는 기존 체인의 기본 정책을 변경하고 규칙을 추가하는 것을 의미합니다. 더 복잡한 방화벽의 경우 종종 추가 체인을 생성하여 관리 프레임워크를 확장하는 것이 좋습니다.

사용자가 만든 체인은 보조로 불리며, 그들이 유래된 “호출 체인”과 본질적으로 연결되어 있습니다. 사용자가 만든 체인에는 기본 정책이 없으므로 패킷이 사용자가 만든 체인을 통과하면 호출 체인으로 돌아가 평가를 계속합니다. 이를 염두에 두고 사용자가 만든 체인은 주로 조직적인 목적으로 유용하며 규칙 일치 조건을 더 유지보수 가능하게 만들고 일치 조건을 분할하여 가독성을 향상시키는 데 사용됩니다.

일부 규칙에 대한 특정 일치 기준을 반복하는 경우 공유 일치 기준이 있는 점프 규칙을 새로운 체인으로 만드는 것이 좋을 수 있습니다. 새로운 체인 내에서 중복된 일치 기준이 제외된 규칙 세트를 추가할 수 있습니다.

규칙 집합을 내장된 체인 중 하나로 통합할지 또는 추가적인 체인을 만들고 활용할지는 규칙 집합이 얼마나 복잡한지에 따라 달립니다.

결론

서버에 대한 방화벽 정책을 설계할 때 내려야 할 결정에 대한 더 나은 이해를 가져야 합니다. 방화벽에 투자하는 시간은 일반적으로 초기 설정으로 치우쳐집니다. 필요에 가장 잘 부합하는 정책을 만들려면 약간의 시간과 실험이 필요할 수 있지만, 이를 통해 서버의 보안을 더 잘 통제할 수 있습니다.

방화벽 및 특히 iptables에 대해 더 알고 싶다면 다음 기사를 확인하세요:

• Iptables 방화벽 작동 방법
• A Deep Dive into Iptables and Netfilter Architecture

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

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