패턴매칭의 문제점과 해법

Negative 패턴매칭

지난 글에서 보안솔루션의 기반 기술인 패턴매칭의 문제점에 대해 살펴봤다. 그리고 그 문제점을 해결하기 위해서는 패턴매칭 룰을 만들 때, 아래 두 가지 조건이 충족되어야 함을 알 수 있었다.

① 공격 패턴의 특성 반영

② 룰이 적용된 구간의 트래픽 패턴 특성 반영

좋은 룰의 필요성에 대해서 살펴봤다. 이중 첫 번째 조건은 그 중요성이 충분히 인식되어 있고, 룰 제작 시충실히 적용되는 편이다. 그러나 두 번째 조건은 아직까지 그 중요성에 대한 인식이 낮은 편. 

좋은 룰을 만드는 두 번째 조건에 대해서 좀더 자세히 살펴보자. 룰 기반 보안솔루션이 사용하는 룰은 크게 'Positive'와 'Negative', 두 가지 방식으로 나뉜다.

	Positive	Negative
개념	안전하다고 정의된 패턴만 허용	위험하다고 정의된 패턴만 거부
장점	알려진 정상 패턴만을 허용함으로써 알려진 공격은 물론 알려지지 않은 공격까지 차단 가능	공격 패턴이 정확하면 서비스 구조 변경 등과 관계없이 적용 가능
단점	서비스 구조 등의 변경 시 정책 반영 필요	알려지지 않은 공격 패턴에 대한 지속적인 연구 필요
적용	방화벽, 웹방화벽 등 è 안전하다고 정의된 패턴을 제외한 모든 트래픽 차단	IDS, IPS 등 è 위험하다고 정의된 패턴을 제외한 모든 트래픽 허용

일반적으로 Positive와 Negative 접근 제어 방식은 위 표와 같이 구분된다. 그러나 반드시 지켜야 되는 강제 조항은 아니며, 실제로 두 방식이 혼용되는 사례는 매우 흔하다.

	Positive 룰 사례	Negative 룰 사례
방화벽	목적지 포트 80으로 유입되는 트래픽만 허용	특정 출발지 IP 차단
웹방화벽	웹 요청 메소드 GET만 허용	특정 공격 패턴 탐지/차단
IDS/IPS	특정 IP/Port에서 발생한 트래픽은 공격 패턴이 일치하더라도 허용(탐지/차단 예외 처리)

그런데 위 표를 자세히 보면 Positive와 Negative 방식이 독립적으로만 사용되고 있으며, 특히 IDS/IPS의 경우 Positive 방식 룰이 IP와 Port라는 매우 제한적인 조건에서만 사용되고 있음을 알 수 있다. 

좀 더 적극적으로 사용할 수는 없을까? 실제 사례를 보자. 다음 룰은 'sql injection' 공격을 탐지하는 수많은 룰 중 하나.

alert tcp any any -> any 80 (uricontent:"%20and%20"; nocase;)

탐지 패턴(%20and%20)의 변별력이 매우 낮아 보이지만, 'and 변수=값' 형식으로 sql 쿼리 구문 중 where 조건절에 사용되는 URI 변수를 조작하여 sql injection 취약점 스캔을 시도하는 공격자들에 의해 매우 자주 사용되는, 의외로 변별력이 높은 패턴이다.

다음은 해당 룰에 의해 1주일간 발생한 IDS 로그의 원시데이터를 탐지 패턴 기준으로 정규화한 결과. 

텍스트 정규화를 통해 탐지 패턴 이후에 발생한 패턴을 일괄적으로 분석함으로써 매우 쉽게 공격 여부 판정이 가능함을 알 수 있다.

1주일간 420건의 공격 시도가 확인됐다. 해당 룰의 정확도는 약 7%. 일 평균 60건의 공격이 발생하고 있지만 800여 건의 오탐에 섞여서 확인이 쉽지 않은 상황. 어떻게 하면 정확도를 높일 수 있을까? 두 가지 방법이 있다. 일단 공격 패턴의 발생 분포는 다음과 같다.

'sleep 함수'를 이용한 시간 지연 또는 '8=8' 등 논리 연산을 유도하는 패턴을 통해 sql injection 취약점을 스캔하는 공격 패턴이 확인됨. 

해당 룰이 적용된 구간에서 발생하는 공격 패턴의 특성이 파악된 듯 하다. 필수 탐지 패턴인 '%20and%20' 이후 'sleep 함수' 또는 '8=8' 등의 패턴이 발생하는 트래픽을 탐지하도록 룰을 수정하면 정확도는 대폭 향상될 것이다. 다음과 같이 룰을 수정해보자.

해당 룰 표현식의 의미는,

① uricontent 옵션을 이용하여 대소문자 구분 없이(nocase) '%20and%20' 패턴이 존재하는 트래픽을 1차 필터링 후(Negative),

② 1차 필터링된 트래픽을 pcre(Perl Compatible Regular Expressions) 옵션을 이용하여 '%20and%20' 패턴 이후 'sleep 함수' 또는 '숫자=숫자' 등의 패턴이 존재하는지를, 대소문자 구분 없이(i) 2차 검사한다는 뜻(Negative).

작성된 정규표현식이 복잡해 보이지만 'Regex Coach(www.weitz.de/regex-coach)'란 정규표현식 테스트 도구를 이용하면 다음처럼 정규표현식을 도식화해주기 때문에 그리 복잡하지 않다.

해당 정규표현식의 상세 설명은 다음과 같다. 참고로 '%숫자숫자' 형태는 URL 인코딩 패턴이라 부른다.

전체 표현식	부분 표현식	설명	비고
\(?sleep(\(|%28)\d(\)|%29)	\(?	'('가 있거나 또는 없거나	'('로 시작하거나 또는 시작하지 않는 'sleep(숫자)' 함수 패턴
	sleep	sleep
	(\(|%28)	'(' 또는 '%28'
	\d	모든 숫자
	(\)|%29)	')' 또는 '%29'
('|"|%27|%22)?[\w%]('|"|%27|%22)?(=|%3D|<|%3C|>|%3E|like)('|"|%27|%22)?[\w%])	('|"|%27|%22)?	'작은 따옴표(', %27)' 또는 '큰 따옴표(", %22)'가 있거나 없거나	숫자 또는 문자간 비교(=, <, >, like) 패턴(숫자나 문자 대신 의미 없는 '%' 패턴이 사용될 때도 있음)
	[\w%]	'모든 문자(숫자 포함)' 또는 '%'
	('|"|%27|%22)?	'작은 따옴표(', %27)' 또는 '큰 따옴표(", %22)'가 있거나 없거나
	(=|%3D|<|%3C|>|%3E|like)	'=(%3D)' 또는 '<(%3C)' 또는 '>(%3E)' 또는 'like'
	('|"|%27|%22)?	'작은 따옴표(', %27)' 또는 '큰 따옴표(", %22)'가 있거나 없거나
	[\w%]	'모든 문자(숫자 포함)' 또는 '%'

다음은 Regex Coach를 이용하여 해당 정규표현식을 테스트한 결과. '%20and%20' 패턴 이후, 'sleep 함수' 또는 '숫자=숫자' 등의 패턴이 존재하는 텍스트와 정확하게 매치되고 있음을 알 수 있다.

해당 정규표현식을 이용하면 룰 정확도가 향상될 가능성이 높다는 사실을 알 수 있다. 공격 패턴을 탐지하는 Negative 탐지룰의 사례이자, 룰이 적용된 구간에서 발생하는 공격 패턴을 파악하여 룰에 반영함으로써 좋은 룰의 두 번째 조건을 충족시킨 사례가 되겠다.

그러나 수정된 룰은 한가지 문제점을 가지고 있다. 공격자가 '%20and%20' 패턴 이후 'sleep 함수' 또는 '숫자=숫자' 등의 패턴이 아닌, 다른 공격 패턴을 이용하면 탐지가 안될 가능성이 존재하는 것이다. 

물론 대부분의 벤더들은 sql injection 공격을 탐지하는 또 다른 룰을 제공하므로 그럴 가능성은 낮다. 하지만 해당 룰만 놓고 본다면 가능성은 충분하다. 어떻게 하면 이런 문제를 해결할 수 있을까?

공격을 탐지하는 방법은 두 가지다. 공격 패턴을 탐지하거나, 정상 패턴을 회피하는 것. 룰 제작 시 공격 패턴만을 고집할 필요는 없으며, 정확도와 효율을 따져서 공격 패턴 탐지와 정상 패턴 회피 방식을 적절히 혼용할 필요가 있다. 즉, Negative와 Positive 방식의 적절한 혼용이 해법이란 얘기.

Positive 패턴매칭

Negative 방식의 IDS 룰 제작 사례를 살펴봤다. 이제 Positive 방식 사례를 살펴볼까 한다. 다음은 '%20and%20' 패턴 이후 발생한 정상 패턴의 발생 분포.

'%20and%20' 패턴 이후 일반적인 문자열 패턴들이 발생하고 있다. 즉, '%20and%20' 패턴은 다음처럼 일반적인 '변수값'으로 사용된 문자열이다.

다음은 '%20and%20' 문자열이 일반적인 변수의 값으로 사용되었을 경우, 탐지하지 않는 룰 사례이다.

해당 룰 표현식의 의미는,

① uricontent 옵션을 이용하여 대소문자 구분 없이(nocase) '%20and%20' 패턴이 존재하는 트래픽을 1차 필터링 후(Negative),

② 1차 필터링된 트래픽을 pcre 옵션을 이용하여 '%20and%20' 패턴 이후 일반적인 문자열이 존재하면 탐지하지 않는다는 뜻(Positive).

해당 정규표현식의 상세 설명은 다음과 같다. 참고로 정규표현식 특수 문자인 '?'는 '*, +' 등의 정규표현식 수량자와 쓰일 때는 해당 수량자의 검사 범위가 최소로 제한됨을 의미하지만, 일반 문자와 쓰일 때는 해당 문자가 있을 수도, 없을 수도 있음을 의미한다.

전체표현식	부분 표현식	설명	비고
\(?[a-z&=]*?(%\w{2}\d?)+?&?[a-z]+?	\(?[a-z&=]*?	'('로 시작하거나, 시작하지 않는 'a~z, &, ='로 이루어진 문자열
	(%\w{2}\d?)+?&?	'&'로 끝나거나, 끝나지 않는 1개 이상의 '헥사코드(%\w{2})숫자(\d)' 형태의 문자열	'\w'는 숫자를 포함한 모든 문자
	[a-z]+?	1개 이상의 알파벳(a~z)

다음은 오탐으로 확인된 패턴을 이용하여 해당 정규표현식을 테스트한 결과이다. '%20and%20' 패턴 이후 일반적인 문자열이 존재하는 패턴과 대부분 일치함을 알 수 있다.

다음은 공격으로 확인된 패턴을 이용하여 해당 정규표현식을 테스트한 결과. 공격 패턴과는 일치하지 않음을 알 수 있다.

해당 정규표현식이 오탐, 즉 공격이 아닌 정상 패턴과만 일치함을 확인했으므로 룰에 적용할 때 '!' 옵션을 이용하여 일치하는 정상 패턴을 탐지하지 않도록, 즉 회피하도록 하면 된다. 

지난 시간에 살펴본 Negative 방식만을 적용한 룰과, 오늘 살펴본 Negative와 Positive 방식을 혼용한 룰은 어떤 차이가 있을까?

Positive 방식은 정상 패턴을 모두 정의해야 한다는 어려움 때문에 현실적으로 사용 비중이 낮으며, Negative 방식은 공격 패턴이 범용적일수록 오탐이, 특화될수록 미탐이 증가하는 문제 때문에 효과적인 사용이 어렵다. 

그러나 Negative와 Positive 방식을 혼용하면 범용적 공격 패턴에 의한 1차 필터링과, 정상 패턴에 의한 2차 필터링을 통해 오탐과 미탐을 동시에 줄이는 효과를 얻을 수 있다. 

물론 정상 패턴에 의한 2차 필터링이 완벽하지 못할 경우 상당량의 오탐이 발생할 수 있지만, 범용적 공격 패턴으로 1차 필터링만 하는 룰보다는 적을 것이며, 최소한 미탐은 발생하지 않게 된다. 

그리고 또 하나의 장점은 룰 성능 향상을 위한 표현식의 선택 범위가 넓어진다는 점이다. 당장 이번 사례만 보더라도 Negative 방식 룰이 일반 문자와 사용된 '?' 및 '|' 옵션에 의해 Negative와 Positive 방식을 혼용한 룰보다 'OR 연산'이 과도하게 발생함을 알 수 있다.

① Negative 방식

② Negative + Positive 방식

물론 Negative와 Positive 방식 혼용이 무조건 성능 향상을 의미하지는 않기 때문에, 룰 표현식 작성 방식에 따라 정확도와 효율을 따져보는 절차가 반드시 필요하다.

그리고 처리 가능한 로그 발생량을 기준으로 실시간 대응 또는 사후 감사 등 로그 분석 목표를 명확히 수립한 후, 미탐이 가능하지만 발생량이 적은 로그와, 오탐이 가능하지만 발생량이 많은 로그 중 적절한 선택을 해야 할 것이다.

나가며

룰 기반 보안솔루션의 효과적인 룰 제작 방식에 대해서 살펴봤다. 패턴매칭은 분명 아직까지 가장 효과적인 보안 기술이지만, 모든 트래픽에 대해서 Negative 방식만을, 또는 Positive 방식만을 고집해서는 오탐과 미탐이라는 문제를 쉽게 해결하기 어렵다. 

그러나 이번 사례를 통해 Negative와 Positive 방식의 단계적인 혼용이 패턴 매치 기법의 정확도와 효율을 높여주는 하나의 대안이 될 수 있음을 알게 되었을 것이다. 

마지막으로 Negative와 Positive 방식의 효과적인 혼용을 위해서는 발생하는 공격 또는 정상 패턴을 정확히 파악할 필요가 있다. 결국 로그 전수 검사를 통한 정확한 패턴 발생 현황 파악만이 패턴매칭의 효과적인 사용을 가능하게 할 것이다.

로그가 많아서 문제라면 해결책은 로그를 줄이는 것 뿐이며, 룰이 부정확해서 문제라면 정확도를 높이는 것만이 해결책이 될 수 있다. 결국 '패턴매칭'이 문제라면 '패턴매칭'을 버리든지 또는 개선하든지, 둘 중 하나를 선택해야 한다.

관련 글

• ID 로그 분석
• 왜 네트워크 보안인가?
• 알고 보면 쉬운 이상징후 분석
• 보안솔루션 기반 기술, 패턴매칭
• 보안 분야 연구 방향을 살펴보면