[웹 방어 레시피] 4장, 평판 및 서드파티 연관성

클라이언트가 사이트에 최초로 접속할 때 클라이언트에 대한 정보를 미리 알 수 있다면 좋지 않을까? 어디서 왔는가, 그리고 웹사이트에서 무엇을 하길 원하는가. IP 주소는 사람이 아닌 컴퓨터를 위한 정보다. DNS가 IP 주소를 이해하기 쉬운 이름으로 매핑하는 데 도움을 주고자 만들어진 것처럼, 컴퓨터의 IP 주소를 기반으로 한 위치 정보 서비스(GeoOP) 주소 변환은 실제 클라이언트의 물리적인 위치에 대한 매우 중요한 정보를 제공할 수 있다.

 

우리는 클라이언트가 웹사이트와 상호작용하는 것을 바탕으로 로컬 위협 프로파일을 만들 수 있으며, 애플리케이션으로 로그인할 경우 알려진 사용자로 매핑할 수 있다. 이는 평판 시스템의 개념을 제공해준다.

 

의심스러운 소스 식별

클라이언트의 지리적인 위치를 식별하는 것은 사용자의 의도에 대한 단서를 제공할 수 있다. 이 절의 레시피는 클라이언트의 IP 주소 정보로부터 얻은 GeoIP 데이터를 사용하는 방법을 보여준다.

 

IP 주소는 컴퓨터의 트래픽을 라우팅하는 데 사용된다. IP 주소는 정확도 논쟁의 여지가 있지만 지오로케이션을 통해 실제 지리적 위치와 연결될 수 있다. 지리적 위치 데이터는 다양한 커뮤니티와 상업적인 절차를 통해 생성된다. 이는 ISP 네트워크 블록 등록, 사용자 계정 등록을 통해 캡처된 물리적 주소, 수동 매핑을 통해 확인된 Wi-Fi 액세스 포인트와의 상관관계를 포함한다.

 

레시피 4-1, 클라이언트의 지리적 위치 정보 데이터 분석

이 레시피는 클라이언트의 지리적 위치를 식별하기 위해 맥스마인드 GeoIP 데이터 베이스 데이터를 사용하는 방법을 설명한다.

 

GeoIP 데이터를 ModSecurity에서 활용하려면 SecGeoLookupDb 지시자를 이용해 데이터를 불러와야 한다. SecGeoLookupDb 지시자를 설정한 후 클라이언트 IP 주소를 ModSecurity의 @geoLookup 연산자로 전달하는 규칙을 작성해야 한다.

 

부정 사용/위험 점수 할당

클라리언트의 국가에 따라 부정 사용 가능성을 평가하기 위해 공공 부정 사용 조사 데이터를 사용함으로써 특정 지리적 지역에 일반적인 위험 점수를 할당할 수 있다. 다음의 국가들은 클라이언트 소스 기준으로 종종 높은 위험성을 가진 것으로 분류되는 지역이다.

 

• 중국
• 우크라이나
• 인도네시아
• 유고슬라비아
• 리투아니아
• 루마니아
• 불가리아
• 터키
• 러시아

이와 같은 국가의 클라이언트 접근을 명시적으로 거부하는 대신 이와 같은 국가에서 발생하는 요청이나 세션에 증가된 이상 징후 점수를 할당할 수 있다.

 

사용자별 GeoIP 추적

부정 사용 탐지를 위해 GeoIP 데이터를 사용하는 또 다른 방법은 정상적인 지리적 위치 데이터를 추가하는 것이다. 이 아이디어는 단순히 사용자가 애플리케이션에 로그인하는 시점의 사용자 위치 정보를 추적하는 것이다. 위치 정보가 반복돼 임계치에 도달하면 이 지역을 정상적이라고 분류한다. 그리고 차후 로그인 시 현재 지역이 정상 목록에 포함돼 있지 않다면 부정 사용 경고를 발생시킬 수 있다.

 

세션별 GeoIP 추적

GEO 국가 코드 데이터가 세션 연결 중에 변경됐는지 알아내는 방법을 보여준다. 이 예시는 일반적인 자바의 JSESSIONID 세션 쿠키를 사용한다. 이 규칙 집합의 핵심 개념은 애플리케이션이 세션ID를 설정하기 위해 HTTP 응답 헤더에 Set-Cookie를 포함한 경우 GEO:COUNTRY_CODE를 저장하는 것이다. 후속 요청에서 국가 코드가 변경되지 않았는지 확인할 수 있다.

 

레시피 4-2, 의심스러운 공개 프락시 사용 여부 식별

이 레시피는 클라이언트가 실제 거주 지역과 다른 위치에 있는 공개 프락시 서버를 사용하고 있는지 식별하기 위해 맥스마인드의 GeoIP 데이터베이스 데이터를 사용하는 방법을 보여준다.

 

공개 프락시 서버를 사용하는 것 자체는 악의적인 의도로 볼 수 없다. 클라이언트가 합법적인 프라이버시상의 이유로 웹사이트에 직접 접속하는 것을 원치 않을 수 도 있다. 게다가 프프락시를 사용하는 다수의 시나리오는 인터넷 서비스 공급자(ISP)가 모바일 클라이언트를 동적으로 캐시 프락시 서버로 재라우팅시킨 후 콘텐츠가 존재하지 않는 경우에만 대상 데이터로 이동하는 것과도 관련이 있다. 이와 같은 경우는 주로 같은 지역 내에 있는 프락시를 이용한다. 반면 악의적인 클라이언트는 주기적으로 다른 국가에 있는 프락시 서버를 통해 트래픽을 라우팅한다. 그들의 동기는 IP를 추적하는 것을 더욱 힘들게 만들기 위함이다.

 

X-Forwarded-For: 72.14.199.171, 116.14.162.189

첫 번째 IP 주소 72.14.199.171은 소스 주소며 116.14.162.189는 다른 오픈 프락시 호스트의 주소다. 소스 코드는 국가 코드 US(미국)에 해당한다.

 

이러한 작업 방식을 이점으로 사용할 수 있다. 프락시 서버를 사용하는 클라이언트를 식별할 수 있고, 실제 우리의 웹 서버에 요청하는 최종 클라이언트와 소스 클라이언트의 국가 코드를 비교할 수 있다.

 

레시피 4-3, 실시간 블랙리스트 조회(RBL)

이 레시피는 현재 클라이언트 IP 주소에 대한 정보를 수집하기 위해 원격 RBL을 사용하는 방법을 보여준다.

 

Spamhaus 블랙리스트 사용

RBL은 정보를 공유하기 위해 DNS 프로토콜을 사용한다. RBL 클라이언트는 클라이언트의 IP 주소의 역순을 조회 이름으로 해서 RBL 서버로 DNS 요청을 보낸다.

 

규칙의 첫 번째 섹션에서 클라이언트의 IP 주소를 가지고 sbl-xbl.spamhaur.org RBL 목록을 대상으로 검사한다. 만약 true 값을 리턴한다면 다음을 수행한다.

 

• IP 컬렉션 내에 이 클라이언트가 의심스럽다고 표시하는 변수를 설정한다.
• 의심 클라이언트 변수의 만료 기간을 하루로 설정한다.
• IP 컬렉션 내에 @rbl 검사를 수행했다고 표시하는 변수를 설정한다. 이는 동일한 IP 주소에 대해 반복적으로 원격 DNS 요청을 보내지 않도록 @rbl 검사를 제한하는 데 사용한다.
• @rbl 검사 변수의 만료 기간을 하루로 설정한다.

이 규칙의 최종 결과는 IP 주소당 하루에 한 번 RBL 검사를 수행하는 것이다. 만약 클라이언트가 RBL 목록에서 발견되면 알려진 의심스러운 소스에서 트래픽이 발생했다는 경고를 생성한다.

 

허니팟 HTTP 블랙리스트 프로젝트 사용

우리의 목적을 달성하기 위해서는 악성 HTTP 클라이언트에 초점을 맞추고 있는 RBL 목록을 찾는 것이 더욱 현명하다.

 

SecHttpBlKey는 우리의 API 키를 지정해줘야 하는 부분이다. API를 생성하려면 등록을 해야 한다. 

 

위험 점수가 임계치인 20보다 높으면 경고가 생성된다. 또한 이 규칙 집합은 IP 컬렉션 데이터 변수에 이 클라이언트가 의심스럽다고 지역적으로 저장해둠으로써 이 클라이언트에 대한 RBL DNS 요청을 추가적으로 발행하지 않도록 한다.

 

레시피 4-4, 자신만의 RBL을 실행

이 레시피는 jwall-rbld 패키지를 사용해 고유의 내부 RBL 서버를 구축하는 방법을 보여준다.

 

기존 레시피에서 보여준 것처럼 클라이언트 IP 주소에 대한 정보를 얻기 위해 서드파티 RBL 저장소를 사용하는 것은 명백한 가치가 있다. 자신만의 내부 RBL 시스템을 구동해 동적으로 공동의 정보를 조회하고 업데이트할 수 있는 추가적인 보안 계층을 구현할 수 있다.

 

ModSecurity의 영구 컬렉션 데이터베이스

ModSecurity의 영구 저장소 매커니즘은 SDBM 라이브러리를 사용한다. 이는 ARP에 이미 포함돼 있고 동시에 트랜잭션 사용을 허용하기에 선택됐다. 영구 저장소 매커니즘은 의도된 목적을 제공하지만 한 가지 단점이 있다. 바로 로컬 아파치 인스턴스의 데이터만 포함하는 것이다. 이는 수백 대의 아파치 서버 팜이 있는 경우 개별적인 각 아파치 인스턴스는 고유의 로컬 영구 저장소 파일을 갖는다는 의미다. 만약 특정 클라이언트를 악성적이라 표시하고 차단을 구현하려 한다면 문제가 있다. 따라서 자신만의 RBL을 구동하는 것이 가치가 있다.

 

로컬 DNS 캐시를 jwall-rbld와 함께 사용하기

구조적으로 ModSecurity 호스트에서 동작한느 로털 DNS 캐실 프로세스를 가지고 중앙 RBL 서버로 쿼리하도록 하는 것이 좋다. 이와 같은 구성은 더 나은 성능을 제공한다. dnsmasq 캐싱 서버는 이와 같은 목적인 경우 최고의 선택이며, 특정 DNS 쿼리를 로컬 jwall-rbld에게 전송하도록 구성할 수 있다. 이와 같은 구성의 장점은 다은 DNS 쿼리는 표준적인 해석기를 사용하도록 반면, 선택적으로 특정 쿼리에 대해서만 경로를 다르게 지정할 수 있다는 점이다.

 

RBL 업데이트

jwall-rbld의 굉장히 유용한 기능 가운데 하나는 클라이언트가 RBL에서 동적으로 IP 주소를 추가하거나 제거할 수 있다는 점이다. 이는 모든 ModSecurity 클라이언트에 대해 글로벌한 공유 블록 리스트 기능으로 동작할 수 있다.

 

레시피 4-5 악성코드 탐지

이 레시피는 서드파티 RBL을 사용해 클라이언트가 보내거나 사이트에서 제공되는 악성 URL을 식별하는 방법을 보여준다.

 

의심스러운 URL 식별

RBL을 사용해 알려진 악성 클라이언트를 식별하는 것은 분명한 장점이 있다. 이 정보는 클라이언트의 성향에 대한 즉각적인 정보를 제공하지만, 악성적인 클라이언트는 지속적으로 소스 위치를 변경하기 때문에 이 자체만으로는 부족하다. 그들은 토르 네트워크 또는 감염된 호스트와 같은 익명 시스쳄을 통해 쉽게 IP 주소 정보를 변경할 수 있는 다양한 방법을 사용한다. 떄때로 악성 행위를 구별하는 주요 방법은 데이터가 어디에서 오는지 아닌 무엇을 전송하는지를 이용한다.

 

응답 페이지 내에서 악성 코드 탐지

일반 사용자에게 드라이브 바이 다운로드 공격을 수행하기 위해 합법적인 웹사이트 내에 악성 링크를 심는 것은 심각한 우려 사항이다. 웹사이트 소유자에게 불행하게도 악성코드 및 링크는 사이트 내에서 다양한 방법으로 제공될 수 있다.

 

악성 링크와 다양한 유형의 크로스 사이트 스크립트 페이로드 간에는 큰 차이가 있다. 이 링크는 직접적으로 브라우저 기반의 취약점을 악용하려고 하지 않는다. 오히려 공격자의 실제 악성코드가 동작할 수 있는 외부 장소에 대한 경로만 제공한다. 이 링크는 순진한 사용자를 감염시키는 경로로 보내는 첫 번째 단계다.

 

악성 링크 탐지

웹사이트 소유자에게는 사이트에 전달된 데이터 내에 악성 가능성이 있는 링크를 검사하고 클라이언트에 전달되기 전 아웃바운드 페이지를 검사할 수 있는 평판/검증 기반의 매커니즘이 필요하다. 

 

GSB API v1

웹 사이트는 사이트 내에서 원격으로 GSB API를 동적으로 쿼리할 수 있지만, 실시간 HTTP 트랜잭션에 대해 실시간으로 이 작업을 수행하는 것은 명백히 지연 시간이 있을 수 있다. 그러나 GSB 데이터베이스를 로컬 시스템으로 다운로드해 로컬 시스템에서 빠르게 조회할 수 있다.

 

악성 링크 제거

악성 링크가 있는 경우 HTTP 302 리다이렉트 응답을 사용했다. 보안 및 일반 사용자 경험의 관점에서 응답 바디를 검사해 공격적인 데이터를 제거하고 사용자에게 페이지를 제공하면 이상적일 것이다.

 

 

---

출처: ModSecurity를 활용한 웹 애플리케이션 방어 레시피, 라이언 바넷 지음