용어사전 : NCHOVY 인터넷 스톰 센터

Bogon Filter

2010-02-24T21:43:20+09:00

Bogon은 공중 인터넷 망으로부터 온 패킷의 발신 주소가 예약된 IP 주소 대역인 IP 패킷을 가리키는 용어입니다. Bogon 패킷은 합법적인 사용이 아니고 보통 실수나 악성 설정으로 인해 발생하기 때문에 많은 ISP와 방화벽에서 이러한 패킷들을 Bogon Filter로 걸러내고 있습니다.

최근에 (2010년 2월 12일) 50.0.0.0/8 대역과 107.0.0.0/8 대역이 ARIN에 할당된 것처럼 할당 내역은 계속해서 변화하고 있고 어제 유효하지 않던 주소가 오늘 유효하게 될 수 있으므로 Bogon Filter는 지속적인 관리가 필요합니다.

최신의 IPv4 주소 공간 레지스트리(IANA IPv4 Address Space Registry)는 아래의 웹 페이지에서 확인할 수 있습니다.

LAND Attack

2009-01-24T17:21:06+09:00

LAND 공격은 주소가 변조된 패킷을 보내어 서비스 거부 상태에 빠지도록 하는 공격 기법입니다. 공격자가 TCP SYN 패킷을 보내면서 출발지와 목적지 주소를 모두 피해자의 주소로 써서 보내게 되면, 자기 자신에게 무한히 응답하는 현상이 발생할 수 있습니다. 1997년에 나온 고전적인 공격 기법이지요.

운영체제의 TCP 스택 결함을 패치하는게 가장 좋은 방법이고, 패치할 수 없는 상황이라면 방화벽 등의 보안 장비를 이용해서 출발지와 목적지가 동일한 패킷을 차단하는 방법으로 대응 가능합니다.

UDP Ping

2009-01-23T20:31:35+09:00

UDP Ping은 하나의 UDP 프레임을 상대방에게 보내고 응답을 관찰하는 방식으로 동작합니다. 만약 응답이 없으면 원격 호스트가 존재하지 않는 것으로 취급하고, ICMP port unreachable 응답이 돌아오면 원격 호스트가 존재하는 것으로 취급합니다.

그런데 원격 호스트의 UDP 포트가 열려 있으면, 임의로 아무렇게나 만든 UDP 패킷을 그냥 무시할 가능성도 있으므로 호스트가 존재하는데도 불구하고 존재하지 않는 것으로 취급하게 되는 오류가 발생할 수 있습니다. 따라서 오류가 적은 결과를 얻고 싶다면, 가급적 닫혀있을 가능성이 높은 포트 번호를 골라서 패킷을 보내야 합니다.

이 방식은 방화벽 등의 보안 장비로 인해 기존의 Ping 방식으로는 경계 너머의 호스트를 식별하기 어려운 경우 사용될 수 있습니다.

Return-to-library

2009-01-11T19:38:54+09:00

스택에 있는 리턴 주소를 실행 가능한 임의의 주소로 바꿔치는 기법을 Return-to-library 공격이라 부릅니다. 유닉스 계열 시스템에서는 C 런타임을 제공하는 libc 공유 라이브러리가 항상 링크된다는 점을 이용하는 경우가 많아서 Return-to-libc 공격이라고도 부릅니다. 이 중에서도 특히 system() 함수는 인자가 하나 뿐인데다가 임의의 프로그램을 실행할 수 있기 때문에 익스플로잇에 많이 사용됩니다.

최근에 DEP/NX를 활성화하여 데이터 영역은 실행하지 못하도록 원천적으로 봉쇄하는 경우가 늘어나고 있는데, Return-to-library 기법을 사용하면 이런 방어 체계를 우회할 수 있습니다. 그러나 ASLR (Address space layout randomization) 기법으로 Return-to-library 공격의 성공 확률을 낮출 수 있습니다. 라이브러리 로딩 순서를 바꾸거나, 부팅할 때마다 이미지 적재 위치를 바꾸면 임의의 리턴 주소를 찍어 맞춰야 하기 때문에 공격하기가 어렵게 됩니다.

SYN 쿠키 (SYN Cookies)

2008-10-02T15:35:11+09:00

SYN 쿠키는 SYN flood 공격을 막을 때 사용하는 TCP 초기 시퀀스 값입니다. 이 기법은 1996년 9월에 Daniel J. Bernstein과 Eric Schenk가 고안한 것입니다. 원래 SYN 큐가 가득 차면 서버는 더 이상 접속을 처리하지 못하고 버리게 됩니다. 이렇게 하는 대신에 SYN 쿠키를 사용하면, 서버는 SYN+ACK 응답에 접속 관련 정보를 써넣은 다음 전송하고 SYN 큐에서 삭제합니다. 이후에 클라이언트로부터 ACK 응답을 받았을 때, 서버는 TCP 시퀀스 번호에 인코드된 정보를 이용하여 SYN 큐 접속 정보를 복원할 수 있습니다.

구현

TCP 접속을 시작하려면 클라이언트가 먼저 서버에게 TCP SYN 패킷을 전송해야 합니다. 이에 대한 응답으로 서버는 TCP SYN+ACK 패킷을 클라이언트에게 보냅니다. 이 패킷에 들어있는 값 중 하나가 시퀀스 번호인데, 이 값은 TCP 프로토콜이 데이터 스트림을 재조립하는데 사용합니다. TCP 명세에 따르면, 첫 번째 시퀀스 번호는 전송하는 쪽에서 임의의 값을 사용할 수 있도록 되어있습니다. SYN 쿠키는 아래의 규칙을 따라 만들어진 특별한 초기 시퀀스 번호를 의미합니다:

t = 64초마다 증가하는 카운터 값
m = MSS (Maximum Segment Size) 값. 원래 서버의 SYN 큐 안에 들어가는 정보입니다.
s = 서버 IP 주소와 포트 번호, 클라이언트 IP 주소와 포트 번호, 위의 t 값을 매개변수로 하는 해시 함수. 반환값 s는 반드시 24비트 값이어야 합니다.

초기 TCP 시퀀스 번호 (= SYN 쿠키) 는 아래와 같이 계산됩니다:

첫번째 5비트: t mod 32 (t를 32로 나눈 나머지)
다음 3비트: m을 인코드한 값
마지막 24비트: s

(여기서 m은 3비트 밖에 사용할 수 없으므로, SYN 쿠키를 사용하는 서버는 m 값을 8가지만 사용 가능합니다.)

클라이언트가 서버의 SYN+ACK 패킷에 대응하는 TCP ACK 패킷을 보낼 때에는, TCP 규약대로 반드시 서버가 보낸 초기 시퀀스 번호 n에 1을 더해서 확인 번호(Acknowledgement number)로 사용해야 합니다. 서버는 ACK 패킷을 받아서 1을 빼면 처음에 클라이언트에게 보냈던 SYN 쿠키 값을 확인할 수 있게 됩니다.

이제 서버는 아래와 같은 작업을 수행합니다:

t 값을 이용하여 접속 대기 시간이 초과되었는지 확인합니다.
s 값을 재계산하여 SYN 쿠키가 유효한 값인지 확인합니다.
3비트 인코딩된 m 값을 디코드하여 SYN 큐 엔트리를 생성합니다.

이후에는 일반 접속 절차가 그대로 진행됩니다.

단점

SYN 쿠키는 프로토콜 명세를 위반하지 않기 때문에 모든 TCP 구현과 호환 가능합니다. 그렇지만 서버가 사용할 수 있는 MSS 값이 8가지로 제한된다는 점과, 모든 TCP 옵션을 거부해야 한다는 단점이 있습니다.

이 때문에 성능이 최적으로 나오지 않을 가능성이 있지만, 사실상 클라이언트에 미치는 영향이 미미한데다 서버가 공격 당하고 있는 상황에서만 이 기법을 적용하는 것도 가능하기 때문에 별다른 문제가 되지는 않습니다. 아예 서비스를 사용할 수 없는 상황보다는 나을테니까요.

Port Knocking

2008-08-12T11:17:05+09:00

포트 노킹은 미리 정의된 특정한 순서로 닫힌 포트에 연결 시도를 함으로써 방화벽에서 포트를 개방하는 방식을 말합니다. 미리 정해진대로 정확하게 닫힌 포트를 대상으로 연결 시도를 하면, 해당 호스트가 접속 가능하도록 방화벽 정책이 자동으로 변경됩니다. 마치 들어가기 전에 문을 똑똑 두드리는 것과 유사하다고 해서 포트 노킹이라고 부릅니다. 비슷한 방법으로는 Single Packet Authentication이 있는데, 암호화된 패킷으로 딱 한 번 노크하는 방식입니다.

포트 노킹을 사용하면 포트 스캔을 통해서 취약한 서비스를 찾아내지 못하도록 할 수 있습니다. 포트를 노크하는 순서가 맞지 않으면 그냥 포트가 닫혀있는 것으로 나오니까요. 그리고 접속 허용 대상 IP를 수작업으로 관리하는 대신 자동으로 처리할 수 있다는 장점이 있습니다. 반면에 공개적으로 사용되는 서비스에서는 사용할 수 없는 단점이 있습니다. 정해진 노크 순서가 알려지거나, 노크 순서를 생성하는 방법이 공개되면 의미가 없으니까요.

포트 노킹이 잘 맞는 경우는 원격 터미널 서비스입니다. SSH나 원격 터미널 같은 경우는 포트 스캔 후 집중적으로 패스워드 추측 공격을 당하기 십상인데, 아예 닫혀있는 포트처럼 숨겨버리면 이런 공격을 받지 않을 수 있습니다.

구현은 여러가지 방법이 있습니다. 간단하게는 방화벽 로그를 모니터링하고 있다가, 순서가 맞으면 방화벽 룰을 조정하도록 데몬을 만들어 놓는 방법이 있습니다. 제대로 구현하려고 한다면 커널의 TCP/IP 스택에 심어넣는게 좋겠지요.

포트 노킹에 대해 더 자세히 알아보시려면 이 웹페이지에 걸린 글들을 읽어보세요.

CSRF (Cross-site Request Forgery)

2008-07-25T02:13:50+09:00

크로스-사이트 요청 위조 (CSRF) 공격은 원클릭 공격, 사이드 재킹 (sidejacking), 세션 라이딩 (session riding) 등으로도 알려져 있고, 약어로는 CSRF 또는 XSRF로 알려져 있습니다. 이 유형의 공격은 크로스-사이트 스크립팅 (XSS)와 유사한 점이 있지만, XSS의 경우에는 악성 스크립트를 웹사이트에 삽입할 필요가 있는 반면, CSRF 공격의 경우 사이트가 신뢰하는 사용자를 통해 공격자가 원하는 명령을 사이트로 전송하도록 하는 기법을 사용합니다. 공격이 사용자를 통해 이루어지기 때문에, 공격자의 IP는 추적 불가능한 특성이 있습니다.

구체적으로 어떤 식으로 공격이 진행되는지 예를 들어보겠습니다. CSRF 공격은 사용자가 로그인한 상태에서만 접속할 수 있는 웹 페이지나 스크립트를 대상으로 합니다. 공격자 A는 피해자 B가 접속하는 은행 사이트를 공격 대상으로 한 조작된 이미지 태그를 게시판에 남깁니다.

피해자 B가 은행 사이트에 접속하고 나서 아직 세션 정보가 남아있는 상태이고, 이 때 공격자 A가 게시판에 남겨놓은 글을 B가 읽게 되면, 해당 링크가 요청되면서 공격이 실행됩니다. 원래는 이미지를 불러오기 위해 지정된 이미지 링크를 GET 메소드로 요청하게 되는데, 피해자 B가 인증되어 있는 상태인 점을 이용하여 이렇게 우회 공격을 할 수 있게 된 것입니다. 특히 대부분의 게시판들이 자바스크립트는 막아놓지만, 이미지 포스팅은 막지 않는 것도 공격에 유리한 상황을 만들어 줍니다.

공격 조건을 다시 한 번 정리해보도록 하겠습니다.

공격자는 피해자가 로그인한 사이트의 취약점을 잘 알고 있어야 합니다.
사이트가 자동 로그인을 허용하고 있거나, 피해자가 현재 로그인한 상태여야 합니다.
사이트에서 특정 동작을 수행할 때 사용자 세션 외에 다른 확인 절차를 밟지 않습니다.

따라서 CSRF 공격을 막으려면 3번 조건을 차단하는게 가장 확실합니다. 인증용 Hidden 필드를 모든 폼에 박아넣고, 동작을 수행하기 전에 폼에 넣었던 Hidden 필드 값이 들어왔는지 확인하면 공격을 막을 수 있습니다.

메소드가 GET인지 POST인지 구분하는 방법도 있지만, 스크립트를 이용해서 POST를 보내는 방식으로 CSRF 공격을 시도할 가능성도 있으므로 확실히 안전한 방법이라고 할 수는 없습니다.

자바스크립트를 이용해서 POST를 하기 전에 강제로 인증 쿠키값을 얻어와서 삽입하고 이를 검증하는 방법도 있습니다. 여기서 별도의 인증 쿠키값은 신뢰할 수 있는 도메인의 요청으로만 읽는게 가능하고, 다른 도메인에서는 이 쿠키를 읽는 것이 불가능하므로 CSRF 공격을 방지할 수 있습니다.

레퍼러를 확인해서 신뢰할 수 있는 위치에서 온 요청인지 검증하는 방법도 있으나, 레퍼러를 생략하는 경우도 안전하지 않은 것으로 취급해야 하는데 브라우저나 프록시 서버에 따라 레퍼러를 생략하는 경우도 있으므로 그리 좋은 방법은 아닙니다. 게다가 플래시나 익스플로러의 취약점을 이용하여 레퍼러를 조작할 가능성도 있습니다.

지금까지 다룬 것들은 개발자 수준에서 조치할 수 있는 사항들이고, 사용자 측면에서는 다른 사이트에 접속하기 전에 로그아웃하는 방법이 있습니다. 세션이 끊어지면 2번 조건이 성립되지 않으므로 CSRF 공격에서 벗어날 수 있습니다.

최근에 발생했던 옥션의 1800만 명 개인 정보 유출 사고는 CSRF 공격을 당한 것으로 밝혀졌습니다. (원문은 黑客基地을 인용한 Dark Visitor을 참조했습니다.) 중국 해커는 직접 서버를 공격하는 대신, 옥션 운영진을 대상으로 악성 코드를 첨부한 메일을 대량으로 유포했습니다. 운영자가 메일을 확인한 순간 ID를 얻을 수 있었고, 해커는 이 ID를 이용하여 옥션 서버에 로그인할 수 있었다고 합니다. WASC는 이 사고를 CSRF로 분류했는데, "설명이 애매한 점이 있긴 하지만 세션 하이재킹으로 설명하는게 가장 잘 들어맞는다"고 밝혔습니다.

참조: Wikipedia - Cross-site request forgery

Proxy Server

2008-07-07T16:18:04+09:00

익명성을 보장받기 위하여 자신의 IP를 숨기고자 할때 많이들 쓰는 서버지요

우리나라 말로 대행서버라고 하면 되겠죠.

실제로 자신의 IP를숨겨야만 할때(범법행위라던지 , 보안상의 이유라던지 )

프록시 서버를 쓰곤 합니다. 그런데 중요한것은 프록시를 쓴다고 해서

자신의 IP가 무조건 숨겨지는건 아닙니다.

익명을 보장받는 프록시와 서버의ip와 자신의ip둘다 정보를 제공하는 서버도 있으니

잘 보고 선택하셔야합니다.

실례로 중국 Proxy Server에 DNSSoofing을 해놔서 구글사이트에 접속하면

약간 다른 피싱사이트가 뜬경우도 있습니다.

보안상의 이유로 사용하다가 해킹을 당할 뻔한 사례지요. 당하신분들도 계실지도 모르구요

위와같이 Proxy Server는 이용할곳이 꽤 많습니다.

조금만 더 응용을 해보면 자신의 컴퓨터를 프록시 서버로 만들어서 패킷조작도 할수 있겟죠?

Fast Flux Hosting

2008-06-30T15:23:00+09:00

Fast Flux 도메인 호스팅은 봇넷에 속한 광대역망의 봇 IP들을 웹사이트나 네임서버의 리버스 프록시로 사용하는 기법입니다. 고정된 호스트만 사용하게 되면 스팸이나 피싱 메일을 통해 사용자를 웹사이트로 유도하는 도중에 차단당하기 쉬우므로, DNS의 TTL (Time To Live) 값을 1~3분 정도로 아주 짧게 주고 NS 레코드 (네임서버 IP)나 IN 레코드 (웹서버 IP)를 계속 바꾸는 방법을 사용하는데 이를 Fast Flux Hosting이라 부릅니다.

특히 네임서버용 도메인을 별도로 등록하고 네임서버 IP까지 바꾸는 경우(NS 레코드 갱신)를 Double Flux라 부릅니다. 이 네임서버들은 DNS 요청을 받아서 숨겨진 네임서버로 포워딩하고, 숨겨진 네임서버는 응답을 전송할 때 요청을 보낸 네임서버를 거치지 않고 직접 클라이언트에게 보냅니다.

봇들은 리버스 프록시로 동작하기 때문에 실제 웹사이트의 IP가 쉽게 드러나지 않아 추적하기가 어렵고, 단순한 IP 차단만으로는 막기 어렵습니다. 그나마 다행인 것은 도메인을 등록할 때 추적을 피하기 위해 대부분 가짜 정보를 기입하기 때문에, ICANN 규정에 의거하여 도메인 사용을 중지시킬 수 있다는 것입니다.

아래와 같은 방법을 사용하여 피해를 줄일 수 있습니다:
- 네임서버 설정 변경을 허용하기 전에 연락처 확인
- 스크립트를 이용해서 자동으로 네임서버 설정을 변경할 수 없도록 함
- 최소 TTL 값을 30분 이상으로 제한
- 과도한 DNS 설정 변경을 탐지하는 모니터링 시스템 구축
- 등록된 도메인과 호스팅 서비스의 불법적인 사용을 금지하는 약관 공표 및 집행
- 수상한 도메인은 설정 변경을 금지하고 변경 시도를 모니터링
- 도메인 설정 변경 횟수 제한
- 짧은 TTL 설정은 별도로 확인을 거치도록 처리
- 불법적인 도메인 사용으로 차단한 경우 바로 풀어주지 말 것

Arbor Networks에서 ATLAS를 통해 FASTFLUX 모니터링 정보를 제공하고 있습니다. 아래 링크를 따라가시면 됩니다.
http://atlas.arbor.net/summary/fastflux

자세한 내용은 아래 Honeynet Project 문서를 읽어보시기 바랍니다.
http://www.honeynet.org/papers/ff/fast-flux.html

SSH와 SSL/TLS의 차이

2008-06-17T14:13:14+09:00

많은 분들이 혼란스러워 하는 주제입니다.

SSL = Secure Sockets layer
TLS = Transport Layer Security
SSH = Secure Shell

SSL은 원래 HTTP를 보안하기 위해 넷스케이프에서 처음 만든 프로토콜입니다. 브라우저 주소창에서 https로 시작하는 URL에 접속하는 경우 SSL 연결을 통해 HTTP 프로토콜로 통신하게 됩니다.

TLS는 SSL 3.0에서 갈라져 나온 IETF 프로토콜 표준입니다. RFC 2248로 문서화 되어있습니다. TLS는 SSH Transport와 User Authentication 프로토콜과 유사한 목적과 기능을 가지고 있습니다. TLS는 암호화를 통해 기밀성과 무결성을 보장하는 양방향 바이트스트림을 제공합니다. 인증은 선택사항입니다. 아래 링크를 참조하시기 바랍니다.
http://www.ietf.org/rfc/rfc2246.txt

SSH와 TLS의 주요 차이점은 아래와 같습니다:

- TLS 서버 인증은 선택사항입니다. 서로 신원을 밝히지 않고 통신할 수 있습니다. 대신 이렇게 하는 경우 MITM (man-in-the-middle) 공격에 취약합니다. SSH-TRANS의 경우에는 서버 인증이 필수적입니다. (물론 클라이언트 쪽에서 서버가 제공한 서버 공개키를 검증하지 않을 수는 있습니다.)

- TLS에서는 클라이언트와 서버 모두 X.509 공개키 인증서를 사용합니다. 이것 때문에 SSH에서 키 생성하고 관리하는 것에 비하면 쓰기가 좀 번거롭습니다. PKI를 사용해야 하지만, 대신에 확장성 있는 키 관리 기능을 제공한다는 이점이 있습니다.

- TLS는 SSH처럼 다양한 클라이언트 인증 옵션을 제공하지 않습니다. 오로지 공개키만 사용 가능합니다.

- TLS는 다른 SSH 컴포넌트가 제공하는 부가적인 기능을 가지고 있지 않습니다. SSH Connection Protocol (SSH-CONN)은 하부의 SSH-TRANS 연결을 이용해서 어플리케이션에 대한 여러 개의 논리적인 데이터 채널을 제공하고, 원격 프로그램 실행 지원, 터미널 관리, TCP 연결 터널링, 흐름 제어 등이 가능합니다만, TLS는 이런 기능을 지원하지 않습니다.

참조 : http://www.snailbook.com/faq/ssl.auto.html

Salami Attack

2008-06-13T15:19:46+09:00

Salami Attack은 관리자가 눈치채지 못할만큼 아주 작은 공격을 연결해서 커다란 공격을 수행하는 기법을 뜻합니다.

가장 유명한 예는 인터넷 뱅킹과 같은 각종 재무 시스템을 대상으로 한 공격입니다. 재무 트랜잭션이 발생할 때 1센트에 가까운 값이 반올림 되는 것을 이용하여, 아주 적은 양의 돈을 지속적으로 훔치는 것입니다. 이 기법은 "penny shaving"으로도 불립니다.

이론적으로만 가능한 것이 아니라 실제로 2008년 5월 28일 PC Pro 잡지에 $50,000을 Salami Attack으로 벌어들인 해킹 사건이 실린 적이 있습니다. E-trade나 Schwab 같은 회사들은 온라인 중개 거래 계정을 개설할 때 보통 몇 센트에서 몇 달러 정도 되는 얼마 안 되는 양의 지불을 전송해서 사용자가 실제로 은행 계정에 접근 권한을 가지고 있는지 검증합니다. Google Checkout이나 Paypal 같은 서비스들도 마찬가지 방법을 사용하고 있습니다.

캘리포니아에 거주하는 Michael Largent 씨는 자동화 된 스크립트를 이용하여 5만 8천개의 계정을 개설한 다음, 여기에 들어오는 돈을 개인 계좌로 이체했습니다. Google의 Checkout 서비스에도 동일한 방법을 사용해서 $8,000 이상의 돈을 긁어모았습니다. Largent 씨는 약관대로 서비스를 사용했을 뿐이라고 주장했지만, 계좌 개설에 가짜 이름, 가짜 주소, 가짜 사회보장번호 등을 사용한 것으로 드러나면서 유죄 판결을 받았습니다.

자세한 내용은 아래 링크를 참조하시기 바랍니다.
http://www.pcpro.co.uk/news/201252/hacker-takes-50000-a-few-cents-at-a-time.html

* 참고문헌
http://en.wikipedia.org/wiki/Salami_attack
http://all.net/CID/Attack/papers/Salami2.html

Blended Threat

2008-06-10T01:12:33+09:00

여러가지 다른 맬웨어 컴포넌트(웜, 트로이 목마, 컴퓨터 바이러스 등)를 조합하여 공격과 전파에 다양한 기법을 사용하도록 만들어진 맬웨어를 "blended threat"이라고 합니다. 여러가지 기법을 사용하기 때문에 대단히 빠른 속도로 퍼지면서 광범위한 피해를 입히는 특성을 가지고 있습니다.

이런 유형의 공격은 이메일의 첨부파일을 통해 바이러스를 전파할 수도 있고, HTML에 포함된 트로이 목마를 통해 컴퓨터에 손상을 입힐 수도 있습니다. Nimda, CodeRed, Bugbear 익스플로잇 모두 "blended threat"의 예입니다.

대부분 아래와 같은 요소들을 포함하고 있습니다:
* 여러가지 전파 수단 : 이메일로 전파될 뿐 아니라, 웹 서버를 감염시켜 특정 사이트에 접속하는 모든 방문자들에게 전파를 시도합니다.
* 실제 피해를 유발하려는 의도로 제작 : 특정 목표를 대상으로 서비스 거부 공격을 하거나, 특정 날짜에 실행되는 트로이 목마를 담고 있습니다.
* 취약점 익스플로잇

이런 공격을 방어하기 위해서는 패치가 나오는대로 즉각 적용해야 될 뿐 아니라, 방화벽을 잘 운영하는 동시에 맬웨어를 탐지하는 서버 소프트웨어를 사용할 필요가 있습니다. 사용자 교육도 중요합니다. 잘 모르는 메일이나 사이트는 열어보지 않도록 해야 합니다.

Ingress Filtering

2008-06-05T18:57:33+09:00

네트워크는 다른 네트워크로부터 패킷을 받습니다. 패킷에는 어떤 컴퓨터가 보낸 것인지 IP 주소 정보가 포함되어 있습니다. 그런데 출발지 IP 주소를 단순히 다른 IP 주소로 바꿔쓰는 것으로 출발지를 속일 수 있습니다. 이렇게 되면 공격 당하는 컴퓨터는 실제로 공격이 어디에서 왔는지 알 길이 없어집니다.

유입 필터링 (Ingress Filtering)은 출발지 IP 주소가 해당 네트워크에서 보낼 수 없는 IP 대역인 패킷을 필터링하는 기법을 말합니다. 이게 가능하려면 한 네트워크에 연결되어 있는 네트워크들로부터 보낼 수 있는 IP 주소들을 모두 알고 있어야 하는데, 항상 가능한 것은 아닙니다. 가령 인터넷에 연결된 경로가 하나 뿐인 경우 이 패킷이 가짜인지 아닌지 알 방법이 없습니다.

엣지 네트워크 (Edge Network)에서는 실제로 사용하는 IP 주소 범위가 제한되어 있습니다. 이런 엣지 네트워크에서는 모든 패킷의 출발지 IP 주소가 해당 네트워크에 할당된 IP 주소 범위 내에 있는지 확인해야 합니다. 기업이나 대학처럼 엣지 네트워크를 운영하는 경우 유입 필터링을 수행해야 합니다. 이 기능은 접근 제어 목록 (ACL)만 가지고도 쉽게 구현할 수 있습니다.

tACL : Transit Access Control List

2008-06-05T16:02:16+09:00

전송 접근 제어 목록(Transit Access Control List)은 네트워크에서 꼭 필요한 트래픽만 명시적으로 허용하는 방법으로 네트워크 보안성을 향상시키는 기법입니다. 일반적으로 네트워크 유입 지점에 해당하는 엣지 라우터 (Edge Router)에서 접근 제어 목록 (ACL)을 이용하여 구현합니다.

아래는 시스코의 문서를 요약한 것입니다. 전체 내용은 아래 주소를 참조하시기 바랍니다.
http://www.cisco.com/application/pdf/paws/44541/tacl.pdf

전송 접근 제어 목록은 아래와 같이 구성합니다:

* 외부에서 들어올 가능성이 없는 출발지 IP를 거부합니다. 예약된 주소 영역 (RFC 1918), 특별한 목적으로만 사용되는 주소 (RFC 3330), 그리고 안티-스푸핑 가이드라인에 따라 부적절한 IP들을 차단 (deny) 합니다.
* 내부에서 외부로 나간 트래픽의 응답으로 들어오는 트래픽을 명시적으로 허용합니다.
* 내부의 보호되는 주소 영역을 목적지로 하는 외부의 트래픽을 명시적으로 허용합니다.
* 나머지는 명시적으로 차단해줍니다. 물론 모든 ACL이 암시적으로 deny를 지정한 효과가 있기는 하지만, show access-list 명령을 쳤을 때 차단된 패킷 통계를 보여주므로, 명시적으로 지정하는게 좋습니다.

= 전송 접근 제어 목록을 만드는 방법

정상적인 트래픽이 사용하는 프로토콜 정보를 모두 알고 있어야, 정상적인 트래픽을 잘못 차단하는 불상사가 발생하지 않습니다. 이를 위해 먼저 네트워크 현황을 조사할 필요가 있습니다. 가장 흔한 예로 DMZ 세그먼트의 웹 서버를 들 수 있겠습니다. 외부에서 접속할 수 있어야 되니까요. 그리고 ACK 비트가 설정된 채로 돌아오는 TCP 트래픽도 허용해야 합니다.

= 필수 프로토콜의 식별

1. 일단 현재의 로컬 보안 정책 / 서비스 정책을 확인하세요. 허용되거나 거부되는 서비스 기준이 있을 것입니다.

2. 다음엔 방화벽 설정을 확인하세요. 현재 방화벽 설정을 살펴보면 명시적으로 서비스 허용 설정을 해놓았을 것입니다. 이 설정을 ACL 포맷에 맞게 바꾸기만 하면 됩니다. 주의할 것은 상태 유지 방화벽 (Stateful Firewall)의 경우 현재 세션 정보를 모두 추적할 수 있기 때문에, 나갔다가 들어오는 트래픽에 대해 별도의 룰이 없다는 점입니다. 라우터 ACL은 보통 상태 유지 기능이 없으므로 돌아오는 트래픽에 대해 명시적으로 허용해 줄 필요가 있습니다.

3. 현재 사용하고 있는 응용 프로그램들을 확인해보세요. DMZ에서 호스팅하고 있는 프로그램이나 내부에서 사용되는 프로그램들을 조사해봐야만 정확히 어떤 트래픽을 허용할지 결정할 수 있습니다.

4. 분류 ACL을 사용하세요. 내부 네트워크를 목적지로 하는 다양한 프로토콜을 명시적으로 ACL에서 허용해주고, 나중에 show access-list 명령을 쳐서 통계를 보면 어떤 프로토콜이 실제로 사용되고 있는지 확인할 수 있습니다.

5. Netflow 기능을 사용하세요. Netflow를 켜놓으면 show ip cache flow 명령을 쳐서 프로토콜 목록 정보가 로그로 남은 것을 확인할 수 있습니다. Netflow가 모든 프로토콜을 식별할 수 있는 것은 아니므로, 다른 기법과 같이 사용하셔야 합니다.

아래의 트래픽 유형을 고려하시기 바랍니다.

1. 엣지 라우터에서 통신할 때 사용되는 외부의 프로토콜과 IP 주소
- ISP 영역의 IP 주소에서 들어오는 ICMP
- 라우팅 프로토콜 (BGP 등)
- IPSec VPN (엣지 라우터가 종점인 경우)

2. 내부에서 외부로 나갔다가 돌아오는 트래픽
- ICMP
- 외부로 DNS 쿼리하고 난 뒤 돌아오는 응답
- TCP 접속에 대한 응답
- UDP에 대한 응답 트래픽
- FTP 데이터 연결
- TFTP 데이터 연결
- 멀티미디어 연결

3. 외부에서 내부의 보호되는 주소 영역으로 향하는 트래픽
- VPN 트래픽 (ISAKMP, NAT, ESP, AH 등)
- 웹 서버 HTTP 트래픽
- 웹 서버 SSL 트래픽
- FTP 서버 접속
- 내부로 들어오는 FTP 데이터 연결
- 내부로 들어오는 FTP 패시브 데이터 연결
- SMTP
- 내부로 들어오는 DNS 쿼리
- 내부로 들어오는 DNS 영역 전송

= 배포 가이드라인

1. 먼저 분류 ACL을 이용해서 네트워크 프로토콜을 식별합니다.

알려진 프로토콜로 ACL을 만들어서 전부 허용으로 설정해놓습니다. 출발지 IP는 any로 하고 목적지 IP는 내부의 서브넷으로 해야겠지요. ACL 마지막 항목을 ip any any log로 해놓으면 추가로 어떤 프로토콜을 허용해야 될지 알아내는데 도움이 됩니다.

단, 로깅을 수행하는 도중에는 라우터에서 CPU 사용량이 급등하므로 아주 짧게 짧게 사용하시기 바랍니다.

2. 식별된 패킷을 확인해보고 내부 네트워크에 대한 접근을 필터링하기 시작합니다.

예약된 주소 영역이나 특별한 목적의 주소 영역, 스푸핑 거부 항목들을 ACL에 추가합니다. 기존에 허용으로 되어있던 ACL 항목들을 하나씩 거부로 바꿉니다. 중간 중간 show access-list 를 치면서 특정 접근 차단 룰에 대해 얼마나 많은 패킷이 걸렸는지 확인합니다. 이렇게 하면 굳이 로깅을 켜지 않더라도 네트워크 접근 시도가 얼마나 있었는지 알아낼 수 있습니다. ACL 마지막 줄은 deny ip any any로 되어야 할 것입니다. 마지막 항목도 통계를 살펴보면서 접근 시도가 얼마나 있었는지 확인할 수 있습니다.

3. 모니터링하면서 ACL을 갱신합니다.

모니터링하면서 어떤 공격이 있었는지 확인하고, 시간이 지나면서 허용할 프로토콜이 새로 생기는 경우에는 ACL을 변경합니다.

DNS Zone Transfer

2008-06-01T01:34:11+09:00

DNS Zone Transfer (DNS 영역 전송)는 DNS 트랜잭션의 한 유형으로서, 여러 대의 DNS 서버 간에 DNS 데이터베이스를 복제하는데 사용되는 방법입니다. 영역 전송은 전체 전송 (AXFR) 과 증분 전송 (IXFR)하는 2가지 유형이 있습니다.

DNS 레코드를 복제하는데 영역 전송 외에도 여러가지 방법이 있을 수 있습니다. 단순히 수작업으로 일일이 데이터를 맞춰주는 방법도 있고, NFS를 이용해서 같은 파일을 공유하는 방법도 있으며, 최근엔 SQL 데이터베이스를 뒷단(back-end)으로 쓰는 경우가 많으니 데이터베이스 자체의 복제 기능을 이용하는 방법도 있습니다. 영역 전송은 예전엔 많이 쓰였으나 지금은 다른 데이터베이스 복제 방식에 밀려서 점점 역사의 뒷편으로 사라지고 있는 복제 방식입니다.

원래 DNS 쿼리는 UDP 53번 포트를 이용하지만, 영역 전송은 TCP 53번 포트를 이용합니다. 초기에 슬레이브 서버를 셋업하고 나면, 마스터 서버에게 AXFR 요청을 보내어 전체 영역 정보을 전송 받습니다. SOA (start of authority) 리소스 레코드 속성에는 시리얼 번호가 써있는데, 이것이 버전처럼 사용됩니다.

슬레이브 서버에서 SOA의 리프레시 속성 값만큼 시간이 지나고 나면, 마스터 서버에게 영역 상태 정보를 요청하는 SOA 쿼리를 보냅니다. 마스터 서버는 SOA 레코드를 응답으로 전송하는데, 여기에 역시 시리얼 번호가 포함되어 있습니다. (네임서버에 따라 다르지만 BIND 같은 경우 레코드 변경이 있을 때마다 시리얼 번호를 직접 손으로 고쳐야 하기 때문에 여기서도 실수하는 경우가 상당히 많습니다.)

슬레이브 서버는 시리얼 번호를 대조해보고 만약 변경된 것이 있으면 IXFR 요청을 보내는데, 마스터 서버는 현재 슬레이브가 가진 시리얼 값과 마스터 서버가 가진 시리얼 값 사이의 기간동안 일어난 변경 사항을 슬레이브 서버에게 전송해줍니다. 이렇게 해서 영역 전송이 이루어지게 되는 것입니다.

그런데 영역 전송 자체가 보안 문제가 될 수 있습니다. 적절히 접근 제한을 걸어놓지 않으면, 사내의 중요 서버에 대한 DNS 별칭과 IP가 쉽게 노출될 수 있습니다. 이것은 아무나 회사 전직원의 전화번호부를 얻을 수 있는 것과 같은 상황입니다. 침입자는 어렵게 네트워크를 헤집고 다니면서 어디에 원하는 정보가 있는지 찾을 필요도 없이, 영역 전송을 받아서 서버 목록을 훑어보는 작업만으로도 공격 대상을 쉽게 정할 수 있습니다.

따라서 복제 자체가 필요 없는 경우에는 반드시 영역 전송 기능을 비활성화 하고, 꼭 필요한 경우에는 최소한 접근 가능한 IP 목록을 설정하여 접근 통제를 실현해야 합니다. BIND 네임 서버를 사용하는 경우 allow-transfer 설정을 통해 접근 가능한 네트워크 대역 (CIDR 포맷)이나 IP를 지정할 수 있습니다. IP를 직접 쓰는 것 외에도, 필요 없는 경우에는 none, 아무 IP나 열어줘도 괜찮은 경우는 any, 로컬에서만 가능하도록 할 경우는 localhost, 네임서버와 직접 연결된 호스트만 접근 가능하도록 할 경우는 localnets를 설정할 수 있습니다. 이 옵션은 전역적으로 설정할 수도 있고, 영역 별로 설정할 수도 있습니다. 예를 들면 아래와 같이 설정할 수 있습니다.

options {
allow-transfer { none; };
};

zone "nchovy.kr" {
type master;
file "nchovy.zone";
allow-transfer { 222.122.43.40; };
}

국내에서 네트워크 관리자들이 가장 흔하게 실수하는 유형으로는 마스터 서버에서는 접근 제어를 제대로 걸어놓고, 막상 슬레이브 서버에서 접근 제어를 하지 않는 경우라고 합니다. 슬레이브 서버에서 다시 복제하는 경우는 거의 없을테니 반드시 allow-transfer를 none으로 해주어야 될 것입니다.

이 외에도 BIND9로 가면서 DNS Transaction Signatures (TSIG) 지원 기능이 추가되었습니다. 공유 비밀키를 걸어놓고 MD5 해시를 이용해서 안전한 복제를 구현한 것이니 DNS 보안을 더 강화하려는 경우 TSIG을 사용해보시기 바랍니다.

마지막으로, 영역 전송을 하는 과정에서 수 M 정도의 데이터 전송이 일어날 수 있기 때문에 DNS를 대상으로 많은 양의 트래픽을 일으켜서 서비스 거부 공격(DoS)을 할 수 있으니 굳이 접근 제어가 필요하지 않은 경우라도 접근 가능한 IP를 제한하시길 권장합니다.

아래 한국인터넷진흥원(NIDA)의 DNSSEC 사이트도 참고하세요.
http://dnssec.nida.or.kr/