최근 한 고객사가 사흘 분량의 방화벽 위협 로그를 내보내 저희에게 보내왔습니다. 경보 1,080건. 그리고 아주 현실적인 질문을 던졌습니다. ‘이거 처리해야 하나요?’
분석을 마친 뒤 저희가 드린 답은 이랬습니다. 우선 경보 처리부터 서두르지 마십시오. 이 로그 자체에 세 가지 문제가 있어서, 거의 쓸 수 없는 상태입니다.
이 세 가지 문제는 이 고객사만의 특례가 아닙니다. 중소기업에서 매우 흔하게 나타나며, 모두 공통점이 하나 있습니다. 겉보기에는 방화벽이 정상 작동하고, 매일 경보가 올라오고, 리포트도 그럴듯해 보이지만, 정작 결정적인 순간에는 쓸모가 없다는 점입니다. 아래에서 세 가지 발견과 각각에 대응하는 자체 점검 방법을 정리하겠습니다.
발견 1: 경보의 88%, 누가 저지른 건지 알 수 없다
가장 먼저 한 일은 ‘공격자’ 필드를 집계하는 것이었습니다. 경보 1,080건 가운데 952건(88%)의 출처를 모두 합쳐도 IP가 11개뿐이었습니다.
이건 정상이 아닙니다. 실제 인터넷 스캔이라면 출처는 수백 개의 흩어진 IP여야 합니다.
그 11개 IP가 무엇인지 살펴보니 — 전부 내부망 게이트웨이 주소였습니다. 즉, 방화벽이 기록한 ‘공격자’는 자사 게이트웨이 장비였습니다.
원인: 트래픽이 방화벽에 도달하기 전에 이미 상위 장비에서 주소 변환이 이루어졌습니다. 실제 출처 IP는 이 단계에서 게이트웨이 자신의 주소로 치환되었고, 방화벽은 변환된 결과만 보게 됩니다.
결과는 매우 현실적입니다: 특정 IP가 수백 번 공격한 것을 보고 차단하고 싶어도 — 차단되는 것은 자사 게이트웨이라서, 막는 순간 전사가 인터넷 단절됩니다. 많은 기업이 ‘경보는 있지만 한 번도 조치한 적이 없는’ 이유가 바로 여기에 있습니다. 조치할 수가 없기 때문입니다.
이것은 방화벽의 문제가 아니라 로그 경로의 문제입니다. 장비 자체는 정상 작동하지만, 장비가 받아든 정보는 이미 상위에서 핵심 부분이 지워진 상태입니다. 1,080건 중 공인 출처를 실제로 확인할 수 있는 것은 128건뿐입니다.
발견 2: 34%는 경보만 하고 차단하지 않았다, 고위험 건도 그 안에
먼저 널리 퍼진 오해 하나를 바로잡겠습니다: 많은 분이 방화벽에 경보가 뜨면 첫 반응이 ‘그래도 막았으니 다행’입니다.
정반대입니다. 방화벽의 위협 대응 동작은 두 가지입니다. 차단과 경보만. ‘경보만’의 의미는 — 보긴 봤고, 기록은 했고, 그냥 통과시켰다는 것입니다.
이 로그에서 369건(34.2%)의 동작이 ‘경보만’이었습니다. 즉 위협의 3분의 1이 그대로 통과된 것입니다.
더 중요한 것은 그 안에 고위험 6건이 있다는 점입니다. 그중 가장 문제가 되는 묶음은 이렇습니다. 특정 공인 IP가 10초 이내에 이미 공개된 고위험 취약점 두 건(데이터베이스 관리 도구 취약점 하나, 네트워크 장비 인가 구성 요소 취약점 하나)을 연속으로 공격했습니다. — 전부 통과되었습니다.
왜 이렇게 되었을까요? 대개 누군가 일부러 차단을 꺼둔 것이 아니라, 다음과 같은 이유입니다.
- 기본 설정이 애초에 ‘경보만’입니다. 많은 보안 정책 템플릿이 출하 시점에 업무 오차단을 피하려 보수적으로 잡혀 있고, 설치 후 아무도 손대지 않습니다.
- 예전에 업무를 잘못 차단한 적이 있어 경보 모드로 되돌려 놓은 경우입니다. 아주 흔합니다 — 어느 날 잘못 차단해서 프린터가 안 되거나 특정 시스템에 접속이 안 되면, 처리 방법이 그 정책을 완화하는 것이고, 그 뒤로 다시 조정하지 않습니다.
- 구역마다 다른 프로파일을 사용해서 어떤 곳은 엄격하고 어떤 곳은 느슨한데, 아무도 주기적으로 대조하지 않습니다.
발견 3: 건수 1위인 경보 유형은 오탐이다
유형별로 정렬하면 비중이 가장 높은 것은 특정 인젝션 공격, 316건으로 29.3%입니다. 이 순위표만 보면 ‘우리가 대량의 인젝션 공격을 받고 있다’는 결론에 이르러, 그쪽만 파고들게 됩니다.
하지만 저희는 한 단계를 더 밟았습니다. 이 316건을 나눠 보면 두 그룹입니다.
- 한 그룹 158건은 송신 방향(내부망의 특정 호스트 → 외부 주소)
- 다른 그룹 158건은 응답 방향(그 주소 → 동일한 호스트)
- 두 그룹의 타임스탬프를 교집합으로 맞춰 보니: 158 대 158이 완전히 1:1로 대응했고, 짝을 못 찾은 건 하나도 없었습니다
→ 이는 동일한 통신 한 묶음이 두 번 기록되었다는 뜻이며, 실제 횟수는 약 158회에 불과하고 316회가 아닙니다.
이어서 양 끝 주소를 보니 더 흥미로운 사실이 나왔습니다. 발신자와 목적지가 사실 같은 호스트였습니다 — 자기 공인 주소를 한 바퀴 돌아 자신의 서비스 포트 하나에 접속한 것입니다. 그리고 그 포트에 대응하는 데이터베이스는, 조회 인터페이스가 마침 쿼리 문장을 URL에 담는 방식이었습니다.
그래서 방화벽 규칙에 걸렸습니다. ‘URL에 쿼리 키워드가 등장’ → 인젝션 공격으로 판정.
즉, 경보량의 거의 3분의 1을 차지한 ‘1위 위협’은 자사 시스템의 정상 통신이 오판된 것이었고, 게다가 두 번 중복 집계되기까지 했습니다. 정작 주의가 필요한 몇 건은 이 소음 더미 아래에 파묻혀 있습니다.
1,080에서 6으로: 경보 건수와 실제 작업량의 격차
이 그림이 말하려는 것은 ‘경보가 모두 쓸모없다’가 아니라, 1,080이라는 숫자가 문제를 부풀리기도 하고 가리기도 한다는 점입니다. 부풀린다는 것은 오탐과 중복이 대량으로 들어 있다는 뜻이고, 가린다는 것은 당장 처리해야 할 몇 건이 소음과 한 표에 섞여 있어 건수 순으로 정렬하면 결코 앞에 오지 않는다는 뜻입니다.
올바른 로그 확인 순서: 등급이 아니라 동작을 먼저 본다
대부분은 위협 로그를 열면 첫 동작이 위협 등급순 정렬이고, ‘고위험’부터 봅니다. 이 순서는 틀렸습니다. 올바른 순서는 이렇습니다.
- 1단계: ‘동작’ 열을 봅니다. 차단이 아닌 것을 전부 먼저 추려냅니다. 이미 차단된 것은 아무리 고위험이어도 ‘처리 완료’이고, 차단되지 않은 것이 지금 열려 있는 구멍입니다. 이 열이 위협 등급보다 훨씬 중요합니다.
- 2단계: 귀속이 가능한지 확인합니다. 출처 IP가 공인 주소인지 자사 내부망 주소인지 봅니다. 전부 내부망 게이트웨이라면 먼저 로그 경로를 해결해야 합니다. 그렇지 않으면 이후의 모든 분석이 잘못된 정보 위에 세워집니다.
- 3단계: 오탐을 걸러낸 뒤 정렬합니다. 비중이 가장 높은 한두 유형을 따로 검증합니다 — 특히 출발지와 목적지가 모두 자사에 있는 경우, 또는 자사 업무 포트에 대응하는 경우입니다. 오탐으로 확인된 것은 먼저 빼고, 남은 것에 우선순위를 매깁니다.
- 4단계: 차단되지 않은 고위험 건을 건별로 판단합니다. 막아야 할 것은 막고, 패치해야 할 것은 패치하고, 오탐으로 확인된 것은 규칙을 정확히 조정합니다. 이 단계의 목록은 보통 몇 건에서 수십 건으로 짧으며, 실제로 끝낼 수 있는 작업량입니다.
중소기업 자체 점검 체크리스트
| 무엇을 확인하나 | 어떻게 확인하나 | 정상 기준 |
|---|---|---|
| 출처를 귀속시킬 수 있는가 | 위협 로그를 내보내고 “공격자” 필드에 서로 다른 IP가 몇 개 있는지 집계 | 다수의 분산된 공인 IP, 소수의 내부 주소에 집중되어 있다면 = 링크에 문제가 있음 |
| 차단되지 않고 경보만 발생한 건수 | “동작” 열 기준으로 그룹 집계 | 고위험은 차단 위주여야 하며, 30% 이상이 미차단이라면 정책 재검토 필요 |
| 1위 비중을 차지한 것이 오탐인가 | 1위 유형의 출발지/목적지가 모두 자사 자산 또는 자사 업무 포트인지 확인 | 자사 자산 간 통신이라면 오탐일 가능성이 높으므로, 먼저 검증한 뒤 위협으로 판단 |
| 중복 집계가 있는가 | 동일 유형 경보를 방향별로 나누어 양측 타임스탬프 비교 | 1:1로 대응되고 짝 없는 항목이 없다면, 한 번의 통신이 두 번 기록된 것 |
| 정책이 완화된 적이 있는가 | 각 영역의 보안 프로파일을 대조하여 동작 설정이 일치하는지 확인 | 영역별 엄격도는 의도된 것이어야 하며, 과거 설정이 그대로 남은 것이어서는 안 됨 |
자주 묻는 질문
Q: 방화벽을 설치했는데 이런 것까지 신경 쓸 필요가 없나요?
A: 설치는 첫 단계일 뿐입니다. 이번 사례에서도 장비 자체는 정상 동작했고 경보도 정상적으로 생성되었지만, 위협의 3분의 1이 허용되었고 출처의 90%는 추적할 수 없었으며, 1위 경보는 오탐이었습니다 — 이런 사실은 누구도 먼저 알려주지 않으며, 로그를 내보내 한 번 분석해야만 알 수 있습니다.
Q: 방화벽 로그는 얼마나 자주 확인해야 하나요?
A: 월 1회 내보내 집계하시길 권합니다(한 줄씩 보는 것이 아니라 위의 비율들을 보는 것입니다). 또한 보안 정책을 조정한 뒤에는 반드시 한 번 확인해야 합니다 — 가장 흔한 문제가 “업무를 잘못 차단하지 않으려고 정책을 완화한 뒤 원래대로 되돌리는 것을 잊는 것”이기 때문입니다.
Q: 왜 중복 집계가 발생하나요? 장비가 고장 난 건가요?
A: 아닙니다. 동일한 트래픽이 서로 다른 영역 경계를 지나면서 각각 기록될 수 있고, 아웃바운드와 리턴 방향이 한 번씩 기록되는데 이는 장비 로직상 합리적입니다. 문제는 집계 시 중복 제거를 하지 않으면 수치가 두 배로 부풀려진다는 점이며, 이는 우선순위 판단에 영향을 줍니다.
Q: “경보만” 발생하는 고위험 항목을 발견했는데 바로 차단으로 바꿔도 되나요?
A: 바로 바꾸지 마십시오. 먼저 이 규칙이 과거에 업무를 잘못 차단한 적이 있는지 확인해야 합니다. 안전한 방법은 먼저 관찰 모드에서 탐지된 항목이 모두 실제 위협인지 확인한 뒤 차단으로 전환하는 것이며, 변경 후 며칠간 업무에 이상이 없는지 지켜보십시오. 보안 정책에서 가장 흔한 사고는 차단 누락이 아니라 잘못 차단하여 업무가 중단되는 것입니다.
자사 방화벽 로그에 실제 위협이 얼마나 되고 노이즈가 얼마나 되는지 알고 싶으신가요?
Siwenlide는 베이징 및 인근 중소기업을 대상으로 네트워크 보안과 IT 운영을 통합한 서비스를 제공합니다. 위협 로그를 내보내 통계 분석하여 “출처를 귀속시킬 수 있는가, 차단되지 않고 경보만 발생한 건수가 얼마인가, 1위 경보가 오탐인가” 이 세 가지를 먼저 확인한 뒤, 실행 가능한 조치 목록과 정책 조정 방안을 제시합니다 — 수백 줄의 경보 표를 던져드리는 것이 아닙니다. 방화벽, 네트워크 장비 및 일상 운영을 패키지로 위탁 관리할 수 있습니다. siwenlide.com을 방문하거나 400-686-2011로 전화하여 상담하십시오.
