피해가 확인되면 복구 방안 수립을 통해 향후 재발 방지를 위한 대응 방안을 수립하고 이행 작업을 실행 한다. 대응 방안은 공격 받은 유형에 따라 다양하게 정의 될 수 있다.

패치적용

사용 중인 응용 프로그램이나 운영체제의 취약점으로 인한 사고 발생 시에서는 개별 공급사에서 제공하는 패치를 이용해 대응 방안을 수립 하자.

시스템 설정

운영 중인 애플리케이션의 취약한 설정으로 인해 사고가 발생하는 경우가 많이 있다. 관리자가 기본 설정을 변경하지 않아 공격자가 악용하는 경우나 테스트 과정에서 임시로 변경한 설정을 원복하지 않아 공격자에게 악용되는 사례도 있다.

개별 애플리케이션의 상세 대응 방안은 사용하는 애플리케이션에 종속적이다. 대표적 유형은 다음과 같다.

관리페이지

최근에도 심심치 않게 발생하는 침해 원인으로 기본 관리 페이지를 통한 공격이 발생한다. 공격자의 입장에서 보면 무작위로 자동 프로그램을 이용해 힘들이지 않고 하나만 걸리면 된다. 공격자에게 여러분이 관리하는 시스템이 당첨되는 일이 없도록 하자.

실행 권한 제거

사용자에게 파일 등록 권한을 제공하는 많은 사이트틀이 파일 실행 권한을 적절히 잘 관리하고 있다. 하지만 간혹 한번의 실수로 권한 조정을 누락하는 경우가 있는데 사용자가 업로드한 파일이 시스템에서 실행되지 않도록 권한 제한을 잊지 말자.

이행 점검

조치 해야 하는 것을 계획만 세우고 실행하지 않는 경우가 많다. 조치를 취해야 할 항목을 정의하고 해당 항목에 대한 조치 결과를 문서화해 관리 하자.

공격을 판단하기 위해 침입탐지시스템 엔진은 패킷에 포함된 데이터를 분석하거나 행위 분석을 통해 공격 여부를 판단 한다. 하지만 탐지 오류(이하 오탐이라고 함)가 없다면 좋겠지만 실제 침입탐지시스템에서 탐지된 이벤트 중 오탐(false-positive) 가능성을 배제할 수 없다.

오탐에는 여러 종류가 있다. 정상 통신에 일부 패턴이 공격 시그니처와 동일할 수도 있고, 탐지된 시그니처가 실제로 취약점이 없는 경우도 있고, 공격이 테스트 목적으로 진행 될 수도 있다. 예를 들어 보자.

시스템 명령을 탐지 하기 위해 “cmd.exe” 문자열을 모니터 한다고 가정해 보자. 우리는 cmd.exe 라는 문자열 만을 의미 있게 생각하지만 탐지 엔진에서는 “abcmd.executeable” 문자열도 동일한 의미로 해석하게 된다. 이를 오탐으로 부른다.

다음은 SQL Injection 공격으로 발생되는 공격 패턴이다.

다음 예제를 살펴보자.

4가지 예제 로그가 SQL Injection과 관련된 공격으로 보일 수 있으나 실제 4개 로그 중 공격과 관련된 로그는 단 1개뿐이다. 3번째 로그가 공격 툴을 이용해 데이터베이스의 정보를 유출할 때 발생되는 로그다..

이처럼 공격과 공격이 아닌 상황에 대해 구분이 모호한 경우가 발생할 때는 시스템에 대한 이해와 해킹 유형에 대해 정확한 사전 지식이 있어야 침입시도와 침입시도가 아닌 행위에 대해 구분이 가능하다.

분석한 내역이 실제 공격으로 확인되면 해당 공격으로 인한 시스템의 피해를 점검한다. 공격 재현을 통해 시스템에 발생하는 현황을 확인하고 어떤 결과가 발생하는지 정의 한다.

• 로그 분석을 통한 피해 범위 확인

샘플 로그를 보자. 다음 로그는 SQL Injection 공격에 의해 피해를 받은 시스템의 로그다. 해당 로그를 통해 어떤 피해가 발생했는지 피해 범위를 정의하자.

샘플 로그에서 SQL Injection 공격에 요청된 쿼리문에 패스워드와 관련된 요청이 포함되어 있다.(admin_psw) 실제 패스워드 항목들이 유출되었는지 전후 로그에 대해 분석해서 피해 범위를 정의 한다.

정확한 피해 범위 확인을 위해 필요한 경우 공격 로그를 테스트 시스템에 수행 시켜 시스템에 미치는 영향을 정확히 분석한다.

탐지된 로그를 정확히 확인하기 위해 실행 함수(exec(@s)를 출력 함수(print(@s)로 변경해서 공격에 사용된 SQL문을 분석하자.

SQL 구문을 확인해 보면 데이터베이스에서 어떤 행위가 일어났는지 확인이 가능해 진다. 그럼 시스템 피해범위를 확인할 수 있다.

침입시도가 공격은 맞지만 시스템에 영향을 줄 수 없는 경우도 있다. 대부분 시스템의 취약점과 관련이 없는 공격들이 이에 해당된다. 주로 무작위 스캔 시도, 단순 포트 스캔 시도들이 해당된다.

영향도를 평가하기 위해서는 애플리케이션이나 시스템의 동작 방식에 대해 이해할 필요가 있다.

가장 많은 공격이 발생하는 웹 서비스의 경우 웹 서비스의 응답 결과에 따라 시스템에 발생한 결과는 틀려진다.

응답코드점검

웹 취약점 공격 시도의 경우는 대부분 응답코드를 통해 취약한지 여부를 판단하게 된다. 예를 들어 SQL Injection 공격을 시도하였지만, 500에러코드가 발생하지 않는다면 시스템에 취약점이 없는 경우가 대부분이고, 공격자가 파일을 업로드 시도하여 해당 파일을 요청하였지만 404 응답코드가 발생했다면 실제로 파일이 업로드 되지 않았다는 것을 의미한다. 이처럼 HTTP 통신에서 사용되는 응답코드에 대해 알지 못하면 침입시도가 성공한지 판단을 할 수 없다

영향받는 시스템 점검

단순히 공격 유형을 파악한 것으로 사고 분석이 끝나면 안되고, 피해 시스템이 취약해 내부 데이터가 유출이 되었는지, 데이터가 조작되었는지, 아니면 데이터베이스를 이용해 시스템 명령을 실행하고, 또 다른 공격을 행했는지 등 영향 범위에 대해 파악을 해야 가능한 후속조치를 취할 수 있다.

침해사고 분석 시 가장 먼저 해야 할 일은 서비스를 제공 중인 이상이 생겼는지 확인하는 것이다.

서비스에 대한 영향이 없다라고 판단된 후에 공격의 영향 범위를 정의 한다.

영향 범위까지 파악이 되면 전체 후속 조치와 취약점을 제거하기 위한 방안을 세운다. 세부 대응방안은 공격 유형에 따라 다양하다. IT환경에 적합한 솔루션으로 대응 방안을 수립하자.

실제 대응과정에서 많은 변수와 환경적인 조건에 따라 상황이 조금씩 차이가 발생될 수 있지만 침입시도에 대해 대응하는 과정을 앞서 살펴본 과정을 거치게 된다. 침입시도에 대해 모니터를 통해 공격여부를 판단하고, 공격을 받은 시스템에 어떠한 피해가 발생했는지 확인하고, 조치 하기 방안을 세우는 과정까지가 일련의 과정이 보안사고를 분석하는 과정이다.

확인된 공격이 위험한지 아닌지 검증하는 방법은 크게 2 가지로 구분된다. 동적 분석과 정적 분석이 있다. 동적 분석은 공격 행위나 악성 프로그램을 다시 재현하여 실제 어떤 위험을 미치는지 검증하는 방법이고, 정적 분석은 재현 없이 공격 구문 또는 악성 프로그램의 바이너리 코드만을 가지고 위험 여부를 확인하는 방법이다.

공격재현

네트워크를 통해서 이뤄지는 많은 수의 공격들 중 대부분은 무작위 대상으로 취약점 여부를 시도하는 경우가 많다. 그렇기 때문에 보안 솔루션이나 시스템 로그에서 위협의 징후가 포착되었다면 실제 위협이 되는지 여부에 대해 재현을 통해 점검을 진행해야 한다.

2013년 발생했던 취약점 공격 중 위험도가 매우 높았던 공격이 아파치 취약점을 이용했던 공격이 CVE-2013-[1]2251이다. 당시 많은 수의 아파치 서버들이 해당 공격에 취약했고, 빠른 시간에 공격이 자동화된 형태로 확산 되었다.

당시 공격 시 사용되던 공격 구문은 다음과 같다.

실제 기업이나 조직에서는 해당 공격에 의한 피해를 막기 위해 운영 중인 소프트웨어의 취약점을 점검했다. 점검하는 방식은 동일한 공격 방식에 취약점 확인을 위해 특정 사이트로 리다이렉션을 시켜서 명령이 실행 되는지 확인을 통해 취약 여부를 가늠했다.

이처럼 공격 구문이 확보가 가능한 경우에는 동일한 방식으로 재현을 통해 운영하는 시스템의 취약점이 존재하는지 쉽게 확인 할 수 있다.

공격 유형 분석

공격 유형 분석은 체계적으로 위협에 대응하기 위해 필요한 항목 이다. 앞서 얘기 했듯이 보안 분석가는 이벤트 분석을 통해 공격 유형 및 위험도를 평가한다. 공격 유형에 맞는 대응 방안을 수립해 일관된 위협 대응 정책을 유지 한다.

• 공격단계별 구분

공격자는 목적 시스템에 침투하기 위해 정보를 수집하는 단계를 거친다. 이후 수집된 정보를 이용해 취약 시스템을 공격하고, 권한을 획득하는 과정을 거친다.

침입탐지시스템 이벤트 분석 시 현재 공격이 어떤 단계에 포함되는지 정의하여 대응 우선 순위를 정의 한다. 우선 순위에 따라서 대응 방식이 달라진다. 공격이 정보 수집 단계에 해당하면 사전 예방 활동에 초점을 맞춰서 사고 발생을 예방한다. 공격이 성공 또는 확산되는 상황이라면 최대한 피해복구에 초점을 맞춰 대응 한다.

다음은 단계별 공격 유형과 분석 및 대응에 필요한 점검 항목이다.

[1] http://struts.apache.org/release/2.3.x/docs/s2-016.html

윈도우 시스템 점검 시 각종 애플리케이션 로그와 함께 점검하는 중요한 로그가 이벤트 로그다. 시스템점검 시 초기에 파일로 수집하는 항목 중 하나이기도 하다.

일반적으로 이벤트 로그를 점검하는 방법은 점검 대상 시스템의 로그를 파일로 저장(확장자 evt)해 점검 PC에서 불러와 분석 한다. 점검 과정에서 발생할 변경 사항을 최소화 하고, 원본 파일 손상을 막기 위해 위와 같은 방식으로 점검 한다.

애플리케이션 로그와 마찬가지로 이벤트 로그에 대한 기본적인 형식과 각 항목에 대한 이해가 있으면 좀더 효율적으로 분석 작업이 가능하다. 특히 이벤트 로그의 경우 이벤트 ID별로 각각이 의미하는 내용이 틀리다. 기본적으로 Windows Server 제품군 운영 체제를 실행하는 컴퓨터는 다음과 같은 세 가지 종류의 로그에 이벤트를 기록한다. 사용자의 로그인 성공/실패를 기록하는 보안로그, 시스템 구동 중에 발생되는 응용프로그램의 오류 및 특이 사항을 기록하는 응용프로그램, 드라이버 충돌 및 오류관련 로그를 기록하는 시스템 로그 총 3개의 이벤트 로그를 기록 한다.

언급한 로그 외에도 사용 프로그램이나 환경에 따라 이벤트 로그에 추가적으로 다른 종류의 로그가 생길 수 있다. 예를 들어 윈도우 운영체제에 디렉터리 서비스를 운영하거나 파일 복제 서비스(파일서버)를 운영할 경우 해당 로그가 추가적으로 발생된다.

윈도우 이벤트 로그는 Windows를 시작할 때 이벤트 로그 서비스가 자동으로 시작된다. 또한 이벤트 로그에 대해 접근 권한을 설정할 수 있어서 그룹정책 편집기(gpedit.msc)를 이용해 이벤트 로그에 대한 엑세스 사용 권한을 설정 할 수 있다. 로그 훼손을 막기 위해 사용하면 좋다.

윈도우와 마찬가지로 리눅스도 여러 종류의 로그가 존재한다. OS에 의해 발생되는 로그는 물론 애플리케이션에 의해 로그가 발생하는 것은 유사하다. 일반적인 로그 종류를 살펴보면 다음과 같다.

로그 종류는 운영환경과 사용중인 애플리케이션에 따라 일부 항목은 차이가 발생할 수 있다.

• 애플리케이션 로그

가장 대표적인 애플리케이션 로그가 웹 로그다. 윈도우의 대표적인 애플리케이션인 인터넷정보서비스(IIS) 웹 서버 로그를 살펴보자.

IIS 로그는 속성 설정을 통해 실제 기록하고자 하는 로그항목을 선택적으로 사용할 수 있다. 로깅 속성에서 제공하는 로깅 옵션을 살펴보면 다음 표와 같다. (옵션의 버전에 따라 차이가 있다)

IIS에서 기록하는 웹 로그가 어떤 것들이고, 또 내용은 무엇인지 알아야 여러분이 로그를 점검하거나 분석할 때 정확하고 효과적으로 분석 할 수 있다. 예를 들어 웹 요청 중에 메소드 형식이 틀린 웹 로그를 검색한다고 가정해보자. 로그를 검색하기 위해서는 메소드가 무엇이고 메소드가 로그에 기록되는지 알아야 한다. 다음과 같은 로그를 찾는다고 가정하자.

물론 로그 파일을 열어 각행을 일일이 검색할 수 있다. 하지만 로그 사이즈에 따라서 일일이 검색하기 불가능할 수 있다.

효과적으로 로그를 분석하기 위해 대부분 로그 분석 툴을 이용하게 된다. 이때 웹 로그 형식을 이해하고 검색을 통해 원하는 결과를 빠른 시간에 찾는 것이 로그 분석의 핵심이다.

다음은 아파치 웹 로그 형식을 표로 설명한 자료다. IIS로깅 옵션과 마찬가지로 클라이언트 IP에서부터 시간, 메소드, 쿠키정보, 헤더정보 등 로그에 기록되는 정보는 다양하다.

다음은 아파치에 기록된 로그 예제다.

예제 로그의 각각의 정보들이 의미하는 내용은 다음과 같다.

예제에서 살펴본 항목 외 아파치 웹 서버에서 기록 가능한 항목이다.

아파치 로그 형식을 파악했으니 앞서 소개했던 로그 검색 예제를 참고해 여러분이 분석 시 상황에 맞게 원하는 결과를 검색하기 바란다.

• 운영체제 로그

SSH를 통한 로그인 시도에서부터 시스템에 마지막으로 로그인 했던 내역까지 시스템에 남아 있는 로그를 통해 확인이 가능하다. 대부분의 사전식 대입 시도는 “secure” 로그를 통해 확인이 가능하다. 시스템 로그 분석 시 점검하는 항목을 확인해 보자.

시스템에 로그인한 계정 정보를 점검해보자. wtmp로그는 시스템에 로그인, 로그아웃 내역을 누적해서 기록한다. 해당 항목을 통해 시스템에 로그인한 사용자, IP, 로그인 시간에 대해 확인이 가능하다. 침해사고 발생 시 공격자에 발생한 로그인 내역 분석 시 활용한다.

다음은 샘플로 wtmp로그를 실행 시킨 내역이다.

네트워크와 로그를 통해 분석에 필요한 정보를 충분히 확보한 후에는 이벤트 분석 작업을 수행 한다. 수집된 정보의 양이 많은 경우는 효율적인 분석을 위해 먼저 데이터를 가공하는 작업이 선행되기도 한다.

선별된 정보를 분석해 위협 징후를 확인 하고, 침해사고완 연관된 일련의 정보들을 조합 한다. 분석 과정에서는 공격과 관련된 특징으로 정보를 선별하거나 통계학적인 관점에서 임계치를 기준으로 정보를 분석 한다. 만약 침해사고와 관련된 근거 정보를 충분히 확보 할 수 없다면 정보 수집 과정을 반복할 필요가 있다. 처음 수집할 정보를 선별하는 과정에서 정보 수집 범위가 잘못됐을 수도 있고, 혹은 수집된 정보를 가공하는 과정에서 정보가 누락 됐을 수 도 있다. 이런 경우 처음 정보 수집 대상을 다시 한번 검토하고 제외된 대상에 대한 정보 재가공을 통해 분석 작업을 반복 한다.

[1] http://httpd.apache.org/docs/2.0/ko/mod/mod_log_config.html#logformat