공격자에게 접근을 허용하는 네 가지 일반적인 방화벽 구성 오류

Jody Brazil이 FireMon을 처음 설립했을 때, 그것은 의도하지 않은 접근을 방지하기 위해 방화벽 정책 변경 사항을 기록해야 한다는 필요에서 비롯되었습니다. 20여 년이 지난 지금도 동일한 정책 기반의 방화벽 구성 오류는 여전히 만연해 있으며, 오늘날처럼 점점 더 복잡해지고 때로는 미흡한 사이버 보안 태세에서는 특히 그렇습니다.

FireMon의 기술 제휴 담당 부사장 Tim Woods는 “문제의 원인이든 아니든, 장애가 발생하면 방화벽이 지목되는 경우가 많습니다”라고 말했습니다. 실제로 방화벽에 원인이 있는 경우, 공격자에게 의도하지 않은 접근 경로를 제공하는 방화벽 구성 오류인 경우가 많습니다.

Woods는 “공격자는 자동화를 이용해 인터넷을 스캔하며 구성 오류를 지속적으로 탐색합니다”라며 “이들은 쉽게 악용할 수 있는 통로가 되는 과도하게 허용적인 규칙에 의존합니다”라고 말했습니다.

직원들에게 새로운 애플리케이션을 배포하는 등 정당한 업무 목적의 접근을 허용하기 위해 규칙을 일시적으로 제한 없이 “열어 두는” 경우가 많습니다. 관리자가 해당 애플리케이션에 권한을 부여하기 위해 방화벽 제한을 개방할 수 있습니다.

Woods는 “나중에 다시 돌아와 그 규칙을 조이려는 것이 본래 의도입니다”라며 “문제는 다른 15가지 우선순위가 생기면서 그 규칙을 다시 수정하지 않는다는 점입니다”라고 말했습니다.

모든 것이 정상적으로 작동하는 것처럼 보이지만, 관리자는 공격자가 악용할 수 있는 통로를 남겨 둔 것입니다.

흔히 발생하는 네 가지 방화벽 구성 오류

Woods는 과도하게 허용적인 환경으로 이어질 수 있는 네 가지 유형의 방화벽 구성 오류에 대해 자세히 설명해 주었습니다.

1. 하드웨어 폐기

관리자가 특정 마케팅 서버를 위한 방화벽 접근 규칙을 생성했고, 이후 그 서버가 폐기되었다고 가정해 보겠습니다. 그런데 더 이상 필요하지 않게 된 해당 방화벽 접근 규칙을 제거하지 않았습니다. 그 결과 규칙은 방치된 상태로 남습니다. 한 달 뒤 동료가 예전 서버의 IP를 재사용해 새 장비를 구축하면, 방치되어 있던 규칙이 “되살아나” 결국 의도하지 않은 리소스에 대한 네트워크 접근을 허용하게 됩니다.

2. 중복 규칙

중복 규칙은 말 그대로 기존의 논리적 접근 경로를 중복해서 정의한 규칙입니다. 당장 심각한 문제를 일으키지는 않지만, 시간이 지나면서 중복 규칙이 쌓이면 보안 시행 정책에 불필요한 복잡성을 더하게 됩니다.

3. 가려진 방화벽 규칙

가려진 규칙은 중복 규칙과 비슷하지만 반대되는 동작을 수행합니다. 즉, 접근을 허용하는 규칙이 하나 있고 접근을 차단하는 규칙이 또 하나 있는 상태입니다. 보안 정책을 수동으로 검토하는 방화벽 관리자는 정책의 실제 동작을 잘못 해석할 수 있습니다. 차단 규칙은 보았지만 그 위 어딘가에 있는 허용 규칙은 놓치는 것입니다. 결국 “가려진” 규칙은 전혀 확인되지 않습니다.

Woods는 “그것은 기술적 실수입니다”라며 “규칙이 서로 겹치거나, 어떤 규칙이 맨 아래에 묶여 있게 됩니다”라고 말했습니다. 관리자가 정책 내 어디에 규칙을 배치해야 할지 몰라 기본적으로 맨 아래에 두면서, 상위 수준에서 유사하거나 상충하는 규칙이 사용되고 있다는 사실을 인지하지 못하는 경우가 있다고 Woods는 설명했습니다. 그렇게 되면 정책 규칙의 동작을 오해하기 쉬워집니다.

4. 정책 비대화

Woods는 “대기업에서 방화벽 정책의 30-40%가 사용되지 않는 경우는 드물지 않습니다”라고 말했습니다.

20년 전에는 200-300줄의 규칙이 있었다면, 오늘날의 정책은 10,000줄에서 100,000줄에 이를 수 있습니다. 여기에 전체 방화벽 수를 곱하면 규칙의 총량은 감당하기 어려운 수준이 됩니다. 정책 비대화의 상당 부분은 사용되지 않는 규칙, 중복 규칙, 가려진 규칙, 과도하게 허용적인 규칙이 누적된 결과입니다. 이러한 비대화는 보안 시행 정책의 전반적인 건전성을 저하시킵니다.

보안 조직의 사일로가 구성 오류를 유발합니다

위와 같은 이유와 더불어, 최근 몇 년 사이 보안 책임이 분산되면서 조직이 더 이상 중앙 집중적인 보안 체계를 유지하지 못하게 된 점도 있습니다.

과거에는 모든 통제를 관리하는 중앙 보안 팀이 있었지만, 이제는 비즈니스 책임자, 이해관계자, devops, 보안 클라우드 팀, IT 보안 조직이 애플리케이션, 워크로드, 리소스를 배포할 때 각자 보안 통제 적용을 책임집니다. 오늘날 대규모 “하이브리드 엔터프라이즈” 환경에서는 보안 책임이 모호한 영역이 될 수 있다고 Woods는 말했습니다.

Woods는 “이제는 더 이상 하나의 악보를 보고 노래하지 않는 경우가 많습니다”라며 “이러한 사일로, 즉 지금까지 진행된 분절화가 보안 공백을 만들어냅니다”라고 말했습니다.

시간이 지날수록 복잡성 격차는 더욱 벌어집니다. 규칙의 양이 늘어나면 사용되지 않는 규칙, 중복 규칙, 과도하게 허용적인 규칙도 함께 증가합니다.

그 격차가 커질수록 사람의 실수가 개입할 확률이 높아지고, 구성 오류가 발생해 시스템에 영향을 미칠 확률도 높아진다고 Woods는 말했습니다.

자동화된 보안 정책 관리로 구성 오류를 해결합니다

구성 오류 문제에 선제적으로 대응하려면, 모든 방화벽 정책 변경 사항을 식별하고 라벨을 부여하는 네트워크 보안 정책 관리 솔루션을 사용할 것을 Woods는 권장합니다.

Woods는 “변경이 발생할 때마다 반드시 답해야 하는 질문이 하나 있습니다”라며 “그 질문은 ‘방금 내 네트워크에서 발생한 변경이 해를 끼치는가? 예 또는 아니오’입니다”라고 말했습니다.

다시 말해, 그 정책 변경이 조직의 보안 태세에 부정적인 영향을 미쳤는지 여부입니다. 복잡성에 라벨을 부여하는 것이 결국 복잡성을 줄이는 데 도움이 된다고 Woods는 말했습니다. 변경이 발생할 때 이를 분석할 수 있는 역량은 가시성을 제공합니다. 그러나 사람인 관리자가 방대한 양의 알림을 모두 따라잡을 수는 없습니다. 바로 이 지점에서 목적에 맞게 설계된 자동화 플랫폼이 공백을 메웁니다. 변경이 발생할 때마다 애플리케이션은 이를 기존 규칙과 비교하고, 변경 기록을 생성하며, 정책 맥락에서 해당 규칙에 대한 평가를 수행합니다.

요약

방화벽 구성 오류는 여러 가지 이유로 발생합니다. FireMon의 Tim Woods는 구성 오류의 네 가지 일반적인 원인을 짚고, 이러한 유형의 구성 실수로 이어질 수 있는 보안 인력 운영의 복잡성에 대한 맥락을 덧붙였습니다. 끝으로 방화벽 정책 구성 오류를 해결하기 위해, Woods는 모든 방화벽 정책 변경 사항의 가시성과 분석을 자동화할 수 있는 목적 기반의 네트워크 보안 정책 관리 플랫폼을 권장했습니다. 이러한 일반적인 함정을 피하기 위해 방화벽을 올바르게 구축하는 방법에 대한 종합 안내는 방화벽 구축: 단계별 가이드를 참조하십시오.