한 페이지에 소스 두개 안올라간다 -_-;
어쩔 수 없이... 두개의 페이지에ㅋㅋㅋ


'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
D F/F Verilog  (0) 2010.04.07
Computer Design - Digital Logic  (0) 2010.03.20
Socket 모듈을 짜던 중. 오류를 한글로 뿌려줄 필요가 있었다. 근데 코드 번호가 정수이므로 변수 하나를 지정해 놓고 문자열을 싹 밀어 넣은 다음에 스위치로 하나씩 빼질 필요가 있었다. 근데 이렇게 할경우 많은 메모리를 차지하게 된다. 그래서 enum을 이용한 문자열 가져오기를 생각하게 되었다. 근데 이게 C++에서는 원래 불가능 하다. 그래서 사람들이 여러가지 방향으로 돌려서 사용하는 법을 만들었는데 아직도 잘 모르겠더라... 일단은 사용만 하고 분석은 나중에 하는 방식으로;;


'Programming > 이것저것' 카테고리의 다른 글

[Design Pattern] Singleton Pattern  (2) 2010.04.16
typeid 연산자  (1) 2010.04.15
ASCII Table  (0) 2010.04.05
사용자 정의 exception (1)  (0) 2010.03.21
Handshking  (0) 2010.03.19
SOC 설계 시간에 처음 짜본 Verilog HDL 코드입니다. 1bit D Flip/Flop(이하 D F/F)를 짰는데요. 처음 해봐서 그런지 되게 어려웠다는.......
Design Module을 짜고 다시 Test Bench까지 만들었습니다. 아래는 그 소스들이구요 결과 사진도 첨부를 했음ㅋㅋㅋ
겨우 10줄 내외의 소스인데 되게 어려웠다는??;;;
우리 플젝은 수천줄은 될텐데 어떻게 만들지?? ㅎㄷㄷ.....

기억할 것!
1번 module에서 시작해서 endmodule로 끝난다.
2번 negedge(negative edge), posedge(positive edge)
3번 테스트 벤치에서 output은 wire이고 input은 reg이다.

Design Module: DFF.v


Test Bench: test_DFF.v


'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
Digital_Clock TestBench  (0) 2010.04.10
Computer Design - Digital Logic  (0) 2010.03.20


윈속을 사용할 때 WSAGetLastError()함수를 굉장히 많이 사용하게 됩니다. 함수를 호출해서 그때의 반환 값을 보고 코딩을 다시 하거나 소스를 바꾸거나 하죠. 반환 값은 int형인데 그것을 보고 인터넷에서 검색해서 사용하게 됩니다. 
하지만 사용자가 직접 메시지를 넣어 줄 수도 있겠죠?? 그때 아래와 같은 것이 필요합니다. 좋네요 ^^

10004, "블럭킹 윈속이 WSACancelBlockingCall 함수에서 취소되었습니다 ") );

10009, "잘못된 기술자(소켓 핸들)이다 ") );
10013, "브로드캐스트 어드레스를 위한 데이터그램 소켓의 접속시도가 setsockopt 함수로 SO_BROADCAST가 설정되어있지 않은 상태에서 실패 했습니다. ") );
10014, "name 또는 namelen 매개변수가 올바른 형태가 아닙니다. ") );
10022, "accept 하기 전에 listen 함수가 불려지지 않았습니다. ") );
10024, "새로운 소켓에 할당하기 위한 소켓 기술자가 더 이상 남아있지 않습니다 ") );
10035, "소켓 함수가 비블럭킹 모드로 동작중이다 ") );
10036, "블록화 함수가 호출 되는 동안 부적절한 소켓 함수가 호출되었다 ") );
10037, "이미 완료된 비동기 명령에 대한 취소가 시도됨 ") );
10038, "지정한 기술자가 소켓 기술자가 아닙니다 ") );
10039, "해당 함수에 목적지 어드레스가 필요하지만 제공되지 않았음 ") );
10040, "수신된 메시지가 지정된 버퍼에 저장하기에 너무 커서 손실 되었습니다 ") );
10041, "지정된 프로토콜이 잘못되었거나 이 소켓에 대해서 잘못된 형식입니다 ") );
10042, "알 수 없는 옵션이거나, 지원지지 않는 옵션을 사용했습니다. ") );
10043, "지정된 프로토콜이 지원되지 않는 형식입니다 ") );
10044, "지정된 소켓 타입이 지정한 어드레스 체계에서 지원되지 않는 형식입니다 ") );
10045, "socket이 연결지향형 서비스(SOCK_STREAM)형태가 아닙니다. ex) listen이 UDP socket에서 호출 ") );
10046, "지정된 프로토콜 체계가(PF_*) 지원되지 않습니다 ") );
10047, "지정된 어드레스 체계가(AF_*) 지원되지 않습니다 ") );
10048, "지정한 어드레스(IP)가 이미 사용중이다 ") );
10049, "지정된 어드레스는 로컬 머신에서 사용할 수가 없다 ") );
10050, "네트웍 서브 시스템에 에러가 발생했습니다 ") );
10051, "원격 시스템까지 네트웍이 도달할 수 없습니다 ") );
10052, "연산이 진행되고 있는 도중 접속이 끊겨버렸습니다. ") );
10053, "연결이 out-of-band나 다른 실패 때문에 끊어져 버렸습니다. ") );
10054, "원격 연결지에서 "hard"나 "abortive" 종료를 수행해서 리셋되었습니다. ") );
10055, "윈도우 소켓 시스템의 버퍼 공간이 모자라거나, 애플리케이션에 의해 API에게 제공된 공간이 너무 작아서 요청된 정보를 저장 할 수가 없음 ") );
10056, "지정된 소켓이 이미 연결 되어 있음 ") );
10057, "지정된 소켓이 이미 연결 되어 있지 않음 ") );
10058, "소켓이 셧다운(shutdown()) 되었습니다. ") );
10059, "지정한 함수에 대한 인자가 너무 많음") ); 
10060, "접속 시도가 시간초과 되었습니다. ") );
10061, "접속시도가 강제로 종료되었습니다 ") );
10062, "") );                  
10063, "") );                  
10064, "원격 호스트가 다운 되었음 ") );
10065, "네트웍 시스템 장애 등에 의해서 원격호스트까지도 달 할 수 없습니다.") );
10091, "네트워크 서브 시스템이 아직 통신할 준비가 되어 있지 않음(WSAStartup()이 반환)") ); 
10092, "요청한 윈도우즈 소켓 버전이 현재 윈도우즈 소켓 시스템에서 지원하지 않습니다. ") );
10093, "이 함수를 사용하기 전에 성공적인 WSAStartup 함수의 호출이 없었습니다.") ); 
11001, "호스트를 찾아낼 수 없습니다.") );
11002, "요청된 정보가 발견 되지 않음") );
11003, "회복할 수 없는 에러발생") );
11004, "잘못된 이름(name)으로 아무런 데이터가 기록되지 않았습니다. ") );

'NativeCode > api' 카테고리의 다른 글

SendARP  (0) 2010.07.03
[팁] Heap 메모리 검증하기.. | VC++ 일반  (0) 2010.05.09
Sock 정보들  (0) 2010.04.04
소켓 옵션  (0) 2010.04.01
Broadcasting 예제  (0) 2010.03.31

4번 문제 갖고 한 시간 정도 헤맸는데 알고 봤더니…… unpack 문제였다.

사진을 보면 EP Section에 UPX1과 아래 UPX 0.89.6 이라는 문구가 있는 것을 알 수 있다.

예전 기억을 더듬어 보면 패킹이 되어 있으면 항상 ㅎㄷㄷ 했었는데… 지금도 역시 그렇다.

하지만 한번 해보니 UPX1은 블로깅이 많이 되어 있어서 쉽더라.

아무튼 한번 해보겠다.

 

일단 UPX는 시작 시에 PUSHA로 모든 레지스터 내용을 스택에 보존 시킨다.

위 사진이 그것인데 PUSHA로 되어 있는 것을 알 수 있다. 그리고 OEP로 점프하기 전에 POPAD로 레지스터 내용을 복구한다.

여기서 OEP가 무엇이냐 면 Orignal Entry Point의 약자입니다. Entry Point란 프로그램이 최초로 수행되는 코드 즉, 진입점 함수를 말합니다.

C에서 보면 main함수가 되겠네요. (사실 main함수가 아니죠?? Windows에서는 xxmainCRTStartup, 리눅스에서는 __libc_start_main이 main함수를 실행시킵니다._)

아무튼 우리는 OEP를 찾아야 합니다. 왜냐하면 패킹이 되면 EntryPoint가 우리가 원하는 프로그램 시작지점이 아니게 되기 때문입니다.

우리가 원하는 건 main함수 같은 그런 시작지점입니다.

블로깅된 정보를 보니 ESP를 이용해서 하드웨어 포인터를 사용해서 하더군요.

잠깐 unpacking 순서를 쫙 펼쳐보자면……….

ESP에 하드웨어 브레이크 포인트->실행->Olly Dump->Rebuild Import 해제 후 빌드->OEP 저장->패킹된 프로그램 시작->Import REC시작->Attach Process->OEP 입력->AutoSearch->Get Imports->Fix Dump 이 순서로 이루어 지더군요.

하나씩 따라가면서 해보도록 하겠습니다.

 

먼저 원하는 프로그램을 OllyDebuger(이하 올디)로 엽니다.

위 그림과 같이 한번 실행한 후 (step over) Folliow In Dump를 해서 아래 메모리 창에 데이터가 나오게 합니다.

 

그리고 4바이트를 선택한 후 Hardware Break Point를 겁니다. DWORD로요. 왜냐하면 처음 시작 부분에 보시면 알겠지만 PUSHAD라는 명령어가 있죠? 마지막에는 POPAD라는 명령어가 있습니다. 그 후 OEP로 점프하게 되는데 우리는 그 지점을 찾고 싶은 겁니다.

아무튼 하드웨어 브레이크 포인트를 설정하셨으면 F9를 눌러서 실행해 주세요.

 

그럼 위 그림과 같이 점프 구문으로 이동하게 됩니다. 그 곳이 바로 우리가 원하는 OEP로 점프하는 구문입니다.

자 F8을 눌러 봅시다. 어?? 왔네요… PUSH EBP로 시작합니까? 그럼 OEP를 맞게 찾으신 겁니다. 이제 다 성공하셨네요.

이제 Plugins를 눌러서 OllyDump를 실행해 주세요. 없으시면 다운 받으시면 됩니다. 구글에서 검색하니 바로 나오더군요.

이 플러그인의 역할은 현재 메모리를 덤프 뜨는 거라고 합니다. 우리는 현재 엔트리 포인트에 있기 때문에 이 쪽을 덤프뜨게 됩니다.


주의 하실 점은 Rebuild Import를 해제해 주세요. 올디가 IAT를 재구성해 주는데 잘 안 된다고 하네요. 그 후 Dump를 해주시면 됩니다. 파일이름은 대충 맘에 드시는 걸로 지우시되 Entry Point를 저장해 주세요. 저는 41270 이네요.

그 후 Import REC라는 프로그램을 다운 받아서 실행시켜 주세요. 그리고 언패킹할 프로그램도 실행시키시구요.

Import REC는 IAT를 복구 시켜주는 툴인데요. OEP가 필요합니다. 하지만 우리가 아까 OEP를 찾았죠?? 그걸 입력해 주시면 됩니다. 자 해볼께요.

 

OEP에 Entry Point를 입력했습니다. 그 후 AutoSearch, Get Imports를 누르시고 Fix Dump를 누르세요. 파일 저장은 아까 올디에서 메모리 덤프했던 그 파일을 선택해주시면 됩니다. 그러면 성공했다는 메시지와 함께 IAT가 복구됩니다.

실행하면 잘 실행되네요.

'Security > Reversing' 카테고리의 다른 글

CodeEngn 07  (0) 2010.04.12
CodeEngn 06  (0) 2010.04.12
Code Engn L03 Start  (0) 2010.04.05
Reverse L02 Start  (0) 2010.04.05
Code Engn Reverse L01 Start  (0) 2010.04.02

Korea :
비주얼베이직에서 스트링 비교함수 이름은?

 

일단 파일을 다운로드 받고 실행! 하지만 실행이 되지 않더라.

암튼 그 다음 넘어가면 비교하는 곳을 찾으면 된다는 건디??

일단 그냥 막 실행

요런 문제가 뜨고… 그럼 열어봐야겠넹.

 


이거 했더니 바로 나오던데??;;

1번이 제일 어려웠던 듯??

'Security > Reversing' 카테고리의 다른 글

CodeEngn 07  (0) 2010.04.12
CodeEngn 06  (0) 2010.04.12
Code Engn L04 Start  (0) 2010.04.06
Reverse L02 Start  (0) 2010.04.05
Code Engn Reverse L01 Start  (0) 2010.04.02

Code Engn 두번 째!

Korea 
패스워드로 인증하는 실행파일이 손상되어 실행이 안되는 문제가 생겼다. 패스워드가 무엇인지 분석하시오 

 

일단 실행했더니

그리고 한가지 툴을 써서 잘 살펴보니 보이더라ㅋ

더 이상의 블로깅은ㅋㅋ

'Security > Reversing' 카테고리의 다른 글

CodeEngn 07  (0) 2010.04.12
CodeEngn 06  (0) 2010.04.12
Code Engn L04 Start  (0) 2010.04.06
Code Engn L03 Start  (0) 2010.04.05
Code Engn Reverse L01 Start  (0) 2010.04.02
iPoom에 들어갈 스마트폰 알림 모듈을 만들어야 했는데
문제는 통신을 통해 데이터를 받는게 아니라 진동일줄이야 -_-;;;
TCP/IP 모듈은 한 시간만에 만들었는데 햅틱이 하루 넘게 걸렸ㅠㅠㅠㅠㅠ
암튼 그래서 블로깅함... 나중에 쉽게 하려고 -_-;

일단 옴니아2 SDK를 받아야 하는데 여기를 참조해 보세욤ㅋ(승환햄 블로그)
저기서 SDK받아서 Visual Studio에서 설정해주고......

Windows Mobile 6 Professional SDK Refresh과
Windows Mobile 6.5 Professional Developer Tool Kit (USA)를 받아서 설치하고......
(둘중에 하나만 설치해도 될지 모르지만.... 귀찮아서 걍 설치함ㅋ)
또 Visual Studio에서 Include경로, Library경로 설정해주고.

또 http://happyworm.egloos.com/2724751를 참조해서 Active Sync나 Device Center를 깔고, 옴니아 드라이버도 깔고....
(뭐가 이렇게 깔게 많냐!!) 암튼 몽땅 다 깔면 드디어 옴니아 프로그래밍 가능합니다.

진동 예제 소스


위 처럼 하면 쉽게 햅틱을 할 수 있다.. 진짜 쉽나??
아 헤더 파일은
#include <smiSDK.h>
#include <smiHaptics.h>
#pragma comment( lib, "SamsungMobileSDK_2.lib" )
이 세개다

'Programming > __etc' 카테고리의 다른 글

고수님들..  (0) 2011.12.15
C2146 구문오류  (0) 2010.03.18
패킷 만들기  (0) 2010.03.18
인터넷에서 찾기 귀찮아서 -_-;
블로그에 올려야징 -_-ㅋㅋ


'Programming > 이것저것' 카테고리의 다른 글

typeid 연산자  (1) 2010.04.15
enum 문자열  (0) 2010.04.09
사용자 정의 exception (1)  (0) 2010.03.21
Handshking  (0) 2010.03.19
Sliding Window  (0) 2010.03.19
WSAAsyncSelect() 소켓의 I/O 상태 변화 즉, 연결요청, 데이터 수신, 송신 버퍼의 사용가능 등의 이벤트를 시스템이 메시지를 통하여 알려주도록 요청함 
WSAAsyncGetHostByAddr() 호스트 주소로부터 호스트 정보를 얻음 
WSAAsyncGetHostByName() 호스트 이름으로부터 호스트 정보를 얻음 
WSAAsyncGetProtoByName() 프로토콜 이름으로부터 프로토콜 번호를 얻음 
WSAAsyncGetProtoByNumber() 프로토콜 번호로부터 프로토콜 이름을 얻음 
WSAAsyncGetServByName() 서비스 이름으로부터 서비스 정보를 얻음 
WSAAsyncGetServByPort() 포트번호로부터 서비스 정보를 얻음 


DWORD GetWindowThreadProcessId (
HWND       hWnd;
        LPDWORD lpdwProcessId
);
HWND 값을 이용하여 프로세스 ID를 알려주는 함수이다.
hWnd              - PID를 얻고자 하는 윈도우의 핸들
lpdwProcessId - 반환받을 PID의 포인터, NULL로 설정할 경우 PID는 리턴값으로 반환된다.

--------------------------------------------------------------------------------

WSAAsyncGetServByPort

getservbyport

두 함수는 서비스 이름이 등록된 파일에서 입력된 포트번호에 대한 서비스를 리턴해 준다.

http://blog.naver.com/lseykwang?Redirect=Log&logNo=100071270266

위 사이트에서 검색..

WSAAsyncGetProtoByNumber()

--------------------------------------------------------------------------------

문법 HANDLE WSAAsyncGetServByPort(HWND hwnd, UINT wMsg, int port, const char *proto, char *buf, int buflen) ; 

인자

hwnd 함수 호출이 완료되었을 때 메시지를 수신할 윈도우의 핸들 
wMsg 함수 호출이 완료되었을 때 보낼 메시지 
port 서비스 포트 번호 
proto 프로토콜의 이름을 가리키는 문자열의 포인터 
buf servent구조체를 수신할 버퍼의 포인터 
buflen 버퍼의 크기 
설명

getservbyport()의 비동기형 함수로 포트 번호와 프로토콜 이름에 해당하는 서비스 정보 구조체 servent를 만들고 응용 프로그램 윈도우 hwnd에게 메시지 wMsg를 보낸다. 

리턴값

성공 비동기 태스크 핸들 
실패 0 
WSAGetLastError() :

WSANOTINITALISED, WSAENETDOWN, WSAEINPROGRESS, WSAEINVAL WSAEALREADY 

 

windows socket system call 요약 
-----------------------------------------------------------------------------------------------------

BOOL WINAPI GetFileInformationByHandle(
  __in   HANDLE hFile,
  __out  LPBY_HANDLE_FILE_INFORMATION lpFileInformation
);
핸들을 이용해서 파일 정보를 얻어오는 것
hFile : 정보를 얻고자 하는 파일의 핸들
lpFileInformation : BY_HANDLE_FILE_INFORMATION구조체 변수의 주소를 전달. 여기로 전달되는 주소의 변수에 파일 정보가 채워짐.

typedef struct _BY_HANDLE_FILE_INFORMATION {
  DWORD    dwFileAttributes; //파일의 특성 정보
  FILETIME ftCreationTime; //파일의 생성 날짜
  FILETIME ftLastAccessTime; //파일에 마지막으로 액세스 한 날짜
  FILETIME ftLastWriteTime; //파일에 마지막으로 수정한 날짜
  DWORD    dwVolumeSerialNumber;
  DWORD    nFileSizeHigh; //대용량이 이 변수도 읽어와야함
  DWORD    nFileSizeLow; //4G이하 파일의 크기를 얻어올 때
  DWORD    nNumberOfLinks;
  DWORD    nFileIndexHigh;
  DWORD    nFileIndexLow;
} BY_HANDLE_FILE_INFORMATION, *PBY_HANDLE_FILE_INFORMATION;

=================================================
DWORD WINAPI GetFullPathName(
  __in   LPCTSTR lpFileName,
  __in   DWORD nBufferLength,
  __out  LPTSTR lpBuffer,
  __out  LPTSTR *lpFilePart
);
파일 이름을 통해서 파일경로 정보를 얻어야 할 때 사용
lpFileName : Full Path를 확인하고자 하는 파일 이름을 전달한다.
nBufferLength : Full Path를 저장할 버퍼에 저장 가능한 문자열 길이를 지정한다.(바이트크기가 아니라 문자열 길이!)
lpBuffer : Full Path를 저장할 버퍼의 주소값을 지정한다.
lpFilePart : Full Path가 문자열로 버퍼에 저장된 이후, 버퍼의 특정 위치를 가리키는 포인터 값이 저장(특정 위치부터 출력하면 파일명 나옴)
=================================================






함 수 기 능
 select() 소켓의 상태 변화(읽기, 쓰기, 오류 발생)를 알려줌
 gethostbyaddr() 호스트 주소로부터 호스트 정보를 얻음
 gethostbyname() 호스트 이름으로부터 호스트 정보를 얻음
 getprotobyname() 프로토콜 이름으로부터 프로토콜 번호를 얻음
 getprotobynumber() 프로토콜 번호로부터 프로토콜 이름을 얻음
 getservbyname() 서비스 이름으로부터 서비스 정보를 얻음
 getservbyport() 포트번호로부터 서비스 정보를 얻음

위와 같은 blocking 함수들은 소켓의 동작 모드에 관계없이 항상 블록될 수 있는 함수이다
이러한 함수를 사용할 때 프로그램이 블록되는 문제를 해결하기 위하여, 윈속에서는 이들 blocking 함수와 같은 기능을 수행하면서 실제로는 비동기 모드로 동작하는 즉, 함수 실행결과를 비동기적으로 알려주는 비동기 함수들을 제공하고 있다. 
  함 수  기 능
 WSAAsyncSelect() 소켓의 I/O 상태 변화 즉, 연결요청, 데이터 수신, 송신 버퍼의 사용가능 등의 이벤트를 시스템이 메시지를 통하여 알려주도록 요청함 
 WSAAsyncGetHostByAddr() 호스트 주소로부터 호스트 정보를 얻음 
 WSAAsyncGetHostByName() 호스트 이름으로부터 호스트 정보를 얻음
 WSAAsyncGetProtoByName()  프로토콜 이름으로부터 프로토콜 번호를 얻음
 WSAAsyncGetProtoByNumber() 프로토콜 번호로부터 프로토콜 이름을 얻음
 WSAAsyncGetServByName()  서비스 이름으로부터 서비스 정보를 얻음
 WSAAsyncGetServByPort() 포트번호로부터 서비스 정보를 얻음







'NativeCode > api' 카테고리의 다른 글

[팁] Heap 메모리 검증하기.. | VC++ 일반  (0) 2010.05.09
WSAGetLastError()  (0) 2010.04.06
소켓 옵션  (0) 2010.04.01
Broadcasting 예제  (0) 2010.03.31
UDP Server, Client  (0) 2010.03.31

리버싱 시그를 시작했다.

예전부터 하고 싶었던 과목이지만 어렵고 다른 것도 할것이 많아서 못하고 있엇지

이젠 시그로 묶었으니깐 열심히 해야징ㅋㅋ

 

Ezbeat이 추천해준 사이트 중 Code Engn의 문제를 풀어보기로 했다.

한글이고 쉬울거 같아서??ㅋㅋ

 

암튼 시작!!

 

문제:

Korea 
HDD를 CD-Rom으로 인식시키기 위해서는 GetDriveTypeA의 리턴값이 무엇이 되어야 하는가

실행하면 하드를 씨디로 인식하게 하라는 창이 뜨면서 프로그램이 죽는다.

위에 문제를 보면 GetDriveTypeA의 리턴값을 적절하게 수정하면 될 것 같다.

 

어제 ezbeat이 알려준 방법대로 Search for->All Intermodular Calls를 실행한다.

위 기능은 Import된 함수들의 목록을 보여주는 역할을 한다. 고로 API를 잘 하면 더 쉽게 Reversing을 할 수 있겠지??ㅋㅋ

문제에서 나왔던 GetDriveTypeA가 보인다. 일단 우클릭을 해서 브레이크 포인트를 찍고 실행해 보자.
참고로 F2: Break Point, F9: Run, F8: Step Over, F7: Step Into 이다. 잘 기억해 놓자.

암튼 F9를 눌러서 실행해서 리턴값이 뭐가 나오는지 확인해보자.

실행하면 위 GetDriveTypeA에서 멈춘 것을 확인할 수 있다. 이제 우리는 리턴값을 확인하면 되는데.

여기서 잠깐 x86의 Windows와 Linux는 리턴값을 대부분 EAX 레지스터에 저장한다는 것을 알아야 한다.

그래서 우리는 EAX 레지스터를 확인 할 것이다.

위 그림에서 보면 알겠지만 EAX의 값이 0x00000003 인것을 알 수 있다. 이 값이 아마도 HDD를 가리킬텐데 우리는 CD-ROM

으로 바꿔야한다. 어떻게 해야하나? MSDN을 봐야지.

자 위에서 보면 3이 드라이브를 가리킨다는 것을 알 수 있으며 우리가 원하는 것은 5번이라는 것을 쉽게 알 수 있다.

이제 EAX 레지스터를 수정하기만 하면 된다.

EAX 레지스터를 클릭해서 0x00000005로 바꾸고 실행.

올바른 결과가 출력됐다.

1번 문제 끝ㅋ

'Security > Reversing' 카테고리의 다른 글

CodeEngn 07  (0) 2010.04.12
CodeEngn 06  (0) 2010.04.12
Code Engn L04 Start  (0) 2010.04.06
Code Engn L03 Start  (0) 2010.04.05
Reverse L02 Start  (0) 2010.04.05

소켓을 사용하다 보면 옵션이 필요한 경우가 있습니다.

책에서 나오는 예제를 보면 가장 처음에는 send, recv buffer 크기 변경하는게 나오더 군요.

하지만 더 많죠. 거기에 대해서 블로깅 하겠습니다.

 

소켓 옵션 설정하기

 

소켓 옵션 얻기

 

일단 소켓 옵션 사용하는 것은 아래와 같은 함수를 사용합니다.

인자를 설명하자면

소켓, 변경할 옵션의 프로토콜 레벨, 변경할 옵션 이름, 변경할 옵션의 값을 저장한 버퍼, 전달하는 옵션의 바이트 단위 길이.

이렇게 5개가 되네요.

 

소켓 옵션은 크게 세 개가 있습니다.

SOL_SOCKET

IPPROTO_IP

IPPROTO_TCP

소켓에 대한 가장 일반적인 옵션

IP Protocol의 옵션

TCP Protocol의 옵션

 

소켓 옵션 - SOL_SOCKET

 

소켓 옵션 - IPPROTO_IP

 

소켓 옵션 - IPPROTO_TCP

 

SO_REUSEADDR 옵션

소켓을 사용해서 함수를 만들다 보면 bind가 되지 않는 현상을 자주 봤을 것입니다.. 이것은 4Way-handshaking 과정 때문인데 서버가 먼저 강제 종료 된다면 소켓이 바로 종료가 되는 것이 아니라 TIME-WAIT 상태로 빠지게 되기 때문에 그렇습니다. (Handshaking 참조) 그래서 현재 bind가 되어 있는 상태이기 때문에 다시 bind 하려고 하면 에러가 나는 것이죠. 이 상태는SOL_SOCKET의 SO_REUSEADDR을 바꿈으로써 해결 할 수 있습니다.  

실제로 SO_REUSEADDR의 옵션은 default값은 0(FALSE)입니다. 그래서 반드시 TRUE옵션을 주는 것을 추천을 합니다.

'NativeCode > api' 카테고리의 다른 글

WSAGetLastError()  (0) 2010.04.06
Sock 정보들  (0) 2010.04.04
Broadcasting 예제  (0) 2010.03.31
UDP Server, Client  (0) 2010.03.31
Server Socket  (0) 2010.03.19
이번엔 브로드캐스팅 예제입니다. 자신이 속한 세그먼트에 데이터를 한방에 보낼 때 사용하는 프로토콜 이죠.
일단 예제를 보시죠. 아주 아주 간단합니다.
이제까지와 다른 점이라곤 소켓에 옵션을 주는 것 밖에 없는데요. 그 옵션들은 다음에 포스팅 하도록 하겠습니다.


Sender
 

Receiver
 

'NativeCode > api' 카테고리의 다른 글

Sock 정보들  (0) 2010.04.04
소켓 옵션  (0) 2010.04.01
UDP Server, Client  (0) 2010.03.31
Server Socket  (0) 2010.03.19
Client Socket  (0) 2010.03.19
UDP의 가장 큰 특징은 비 연결성이라는 것이겠죠? 아래 소스를 보시면 알겠지만 접속 하는 것이 없어요. 서버는 바인드에서 끝나서 데이터를 받기 위해 recvfrom을 호출하고 있고 클라이언트는 sendto로 전송대기만 하고 있음.
TCP 보다 조금더 간단하게 생겼음

Server

 


Client
 

'NativeCode > api' 카테고리의 다른 글

소켓 옵션  (0) 2010.04.01
Broadcasting 예제  (0) 2010.03.31
Server Socket  (0) 2010.03.19
Client Socket  (0) 2010.03.19
① WSAStartup  (0) 2010.03.19
■ IDS 침입탐지시스템
   IDS는 Intrusion Detection System 의 약자로 한글로 "침입탐지시스템"이라고 불립니다.
   침입탐지를 하기 위해 관찰하고 있는 대상에 따라 H-IDS와 N-IDS의 두가지 분류로 나누고 있습니다.

   Host(컴퓨터)에서 일어나고 있는 일련의 활동들을 감시하고 침입 발생에 대해
   탐지를 하는 IDS를 H-IDS(Host-based IDS)라고 부르며,
   Network 상에서 일어나는 활동들을 감시하고 침입 시도를 탐지하는
   IDS를 N-IDS(Network-based IDS)라고 합니다.

   H-IDS는 감시 대상이 되는 host(컴퓨터)에 탑재가 되며, N-IDS는 지나가는 트래픽들을 볼 수 있는
   감시 대상이 되는 네트워크단에 설치가 됩니다. 
 
■ 기능
   - 일반적으로 시스템에 대한 원치 않는 조작을 탐지하여 준다. 
     ? 침입 탐지 시스템은 전통적인 방화벽이 탐지할 수 없는 모든 종류의 악의적인 
        네트워크 트래픽 및 컴퓨터 사용을 탐지하기 위해 필요하다. 
        이것은 취약한 서비스에 대한 네트워크 공격과 에플리케이션에서의 데이터 처리 공격(data driven attack) 
        그리고 권한 상승(privilege escalation) 및 침입자 로그인 / 침입자에 의한 주요 파일 접근 / 
        멀웜(컴퓨터 바이러스, 트로이 목마, 웜)과 같은 호스트 기반 공격을 포함한다.
 
     ? IDS는 여러개의 컴포넌트들로 구성된다: 

        센서는 보안 이벤트를 발생시키며, 

        콘솔은 이벤트를 모니터하고 센서를 제어하거나 경계시키며(alert), 

        중앙 엔진은 센서에 의해 기록된 이벤트를 데이터베이스에 기록하거나, 시스템 규칙을 사용하여 

        수신된 보안 이벤트로부터 경고를 생성한다. 

 

        IDS를 분류하는 방법은 센서의 종류와 위치 그리고 엔진이 경고를 만드는데 사용하는 방법론에 따라 여러가지가 있다. 

        많은 간단한 IDS들은 위의 세개의 컴포넌트들을 하나의 장치 또는 설비로 구현하고 있다.


 
악용 탐지(Misuse Detection) 대 비정상 탐지(Anomaly Detection)
■ 악용탐지시스템(Misuse Detection System)

   시그니쳐 기반 침입 탐지 시스템으로도 알려진 악용 탐지 시스템은 악의적인 것으로 

   추정되는 트래픽 또는 애플리케이션 데이터의 패턴을 감시하여 침입을 식별한다. 

   이러한 종류의 시스템은 오직 '알려진' 공격만 탐지할 수 있다고 여겨진다. 

   그러나 그들의 규칙 집합에 따라, 시그니쳐 기반 IDS들은 때때로 알려진 공격들과 서로 특징을 공유하는 

   (예를 들어 HTTP GET 요청을 통한 'cmd.exe' 접근과 같은) 새로운 공격들을 탐지할 수 있다.

   IDS는 채집된 정보를 분석하여, 공격 시그니쳐를 저장하는 거대한 데이터베이스를 통해 그것을 비교한다. 

   IDS는 본질적으로 이미 문서화된(알려진) 특정 공격을 찾는 것이다. 

   바이러스 탐지 시스템에서처럼, 악용 탐지 소프트웨어는 단지 패킷을 비교하기 위해 사용되는 

   공격 시그니쳐 데이터베이스나 마찬가지이다.

 

■ 변칙기반침입탐지 시스템(Anomaly Based Intrusion Detection System)

   변칙 기반 침입 탐지 시스템은 네트워크 또는 호스트의 일반적인 동작과 다른것으로 추정되는 트래픽 또는 

   애플리케이션 컨텐트를 시스템 운영자에게 알리는 것으로 침입을 식별한다.

   변칙 기반 IDS는 일반적으로 이것을 스스로 학습하여 이룬다.

   변칙 탐지에서, 시스템 관리자는 네트워크의 트래픽 로드, 고장(breakdown), 프로토콜, 

   그리고 일반적인 패킷 크기에 대한 기준선 또는 일반 상태를 정의한다. 

   변칙 탐지자(anomaly detector)는 네트워크 세그먼트를 모니터하여 정의된 기준과 그들의 상태를 비교하고 변칙을 찾는다.


 
네트워크 기반 시스템 대 호스트 기반 시스템
■ 네트워크기반 시스템

   네트워크 기반 시스템(또는 N-IDS)에서 센서는 모니터할 네트워크 또는 종종 DMZ나 

   네트워크 경계의 초크 지점(choke point)에 위치한다. 

   센서는 악의적 트래픽 탐지를 위해 모든 네트워크 트래픽의 흐름을 캡쳐하여 각각의 패킷 내용을 분석한다. 

   호스트 기반 시스템에서 센서는 보통 그것이 설치된 호스트의 모든 활동을 감시하는 소프트웨어 에이전트로 구성된다.

   이 두가지 형식이 혼합된 하이브리드 시스템 역시 존재한다.

 

   - 네트워크 침입 탐지 시스템은 네트워크 트래픽을 검사하고 여러 호스트들을 모니터하여 침입을 식별하는 독립된 플랫폼이다. 

      네트워크 침임 탐지 시스템은 포트 미러링 또는 네트워크 탭(network tap)을 위해 설정된 허브, 네트워크 스위치에 연결하여 

      네트워크 트래픽에 접근한다.

   - 호스트 기반 침입 탐지 시스템은 호스트에서 시스템 콜, 애플리케이션 로그, 파일 시스템의 수정사항(이진 파일, 패스워드 파일, 

      capability/acl 데이터베이스) 그리고 호스트의 동작과 상태등을 분석하여 침입을 식별하는 에이전트로 구성된다.

   - 하이브리드 침입 탐지 시스템은 위의 두가지 방식을 결합한 것이다. 호스트 에이젼트 데이터는 네트워크의 종합적인 관점을 위해 

      네트워크 정보와 결합된다. 하이브리드 IDS 중 하나로 Prelude가 있다.

 


수동적 시스템 대 반응적 시스템
■ 수동적 시스템

   수동적 시스템에서의 IDS 센서는 가능성 있는 보안 침해 사항을 탐지하여, 정보를 로그로 기록하고 콘솔을 통해 경고 신호를 보낸다. 

 

■ 반응적 시스템

   반응적 시스템에서의 IDS 센서는 의심스러운 동작에 대해 자율적으로 또는 시스템 운영자에 의해 사용자를 로그 오프 시키거나, 

   방화벽을 다시 프로그래밍하여 의심스러운 악의적 출처로부터 네트워크 트래픽을 차단하도록 응수한다.

 

비록 둘다 네트워크 보안과 관련되지만, IDS는 침입 발생 자체를 막기 위한 방화벽과는 다르다. 

방화벽은 침입을 막기 위해 네트워크 사이의 접근을 제한하며, 네트워크 내에서 공격 신호를 보내지 않는다

(does not signal an attack from inside the network). 

반면에 IDS는 일단 의심스러운 침입이 발생하면 그것을 평가하고 경보 신호를 보낸다. 

IDS는 또한 현 시스템 내부에서 발생한 공격에 대해서도 감시한다.

이것은 전통적으로 네트워크 통신을 검사하고, 일반적인 컴퓨터 공격에 대한 휴리스틱과 (시그니쳐로도 알려진) 패턴을 식별하며, 

시스템 운영자에게 경고하기 위한 동작을 취하는 것으로 성취된다. 

네트워크 연결을 끝내는 시스템은 침입 차단 시스템이라 불리며, 이것은 애플리케이션 계층 방화벽의 또 다른 형태이다.

 

 



--------------------------------------------------------------------------------


요약정리

 

IDS 개요

1. 방화벽이 내부망 보안을 수행하는데 있어 그 적용의 한계가 드러나 이를 보완 해줄 시스템의 필요

2. 침입의 패턴 데이터베이스와 Expert System을 사용해 네트워크나 시스템의 사용을 실시간 모니터링 하고 침입을 탐지하는 역할

 

IDS 정의

1. IDS는 단순한 접근제어 기능을 넘어 침입의 패턴 데이터베이스와 Expert system을 사용해 네트워크나 시스템의 사용을 

    실시간 모니터링 하고 침입을 탐지하는 보안 시스템을 의미

2. IDS는 허가되지 않은 사용자로부터 접속, 정보의 조작, 오용, 남용 등 컴퓨터 시스템 또는 네트워크상에서 시도 됐거나 

    진행중인 불법적인 예방에 실패한 경우 취할 수 있는 방법으로 의심스러운 행위를 감시하여 가능한 침입자를 조기에 발견하고

    실시간 처리를 목적으로 하는 시스템

 

IDS의 주요 목적

1. 시스템 자원의 보호

2. 공격 대응 및 복구

3. 통계적 분석 보고

4. 증거 수집 및 역추적

5. 정보 유출 방지

 

IDS 주요 기능

1. 저 수준 필터링, 고 수준 필터링을 이용한 감시자료 수집 기능

2. Misuse(오용) 침입 탐지 기능

3. Anomaly(비정상) 침입 탐지 기능

4. 서비스 거부 탐지 기능

5. 자동 침입 분류 기능

6. 침입 탐지 경보 및 대응

7. 시스템 취약점 점검 및 복구 기능

8. 편리한 사용자 인터페이스 기능

9. 침입자 역추적 기능

 

탑지영역에 따른 IDS 분류

1. H-IDS(Host based IDS)

   - 개별 호스트의 O/S가 제공하는 보안감사 로그, 시스템 로그, 사용자 계정 등의 정보를 이용해서 호스트에 대한 공격을 탐지

   - 각 호스트에 상주하는 Agent 와 이들을 관리하는 Agent Manager로 구성

   - 중요한 시스템 파일이나 실행코드에 대한 무결성 검사 기능이나 시스템의 취약점들을 탐지해 주는 취약성 스캐너(Vulerability Scanner)

      등과 결합되어 사용

   - 특정 시스템과의 O/S와 밀접히 결합되어 각종 행위를 분석하므로 정교한 모니터링과 로깅이 가능

   - IDS 문제 발생 시 해당 호스트에 영향을 미치며 IDS로 인해 시스템에 부하를 크게 함.

2. N-IDS(Network based IDS)

   - 네트워크 기반의 공격을 탐지하여 네트워크 기반 구조를 보호하는 것을 목적으로 함

   - 호스트 기반의 IDS처럼 호스트에 대한 공격을 탐지하거나 상세한 기록을 남길 수는 없으며, 네트워크가 분할되어 있는 경우 

      제 기능을 발휘하지 못하거나 적용 범위가 제한되어 실용성이 없는 경우도 있음

   - NIC를 통해 패킷을 수집하여 수동적인 분석을 하기 때문에 기존 네트워크에 영향을 주지 않고 설치가 편리

 

침입 모델에 따른 분류

1. 비정상적인 침입탐지 기법

   - 감시되는 정보 시스템의 일반적인 행위들에 대한 프로파일을 생성하고 이로부터 벗어나는 행위를 분석하는 기법

     ? 통계적인 자료 근거 : 통계적으로 처리된 과거의 경험 자료를 기준으로 특별한 행위 또는 유사한 사건으로 이탈을 탐지

     ? 특징 추출에 의존 : 경험적인 침입탐지 측정 도구와 침입의 예측 및 분류 가능한 침입도구의 집합으로 구성된 침입 탐지 방법

     ? 예측 가능한 패턴 생성 : 이벤트 간의 상호관계와 순서를 설명하고 각각의 이벤트에 시간을 부여하여 기존에 설정된 

                                           침입 시나리오와 하여 침입을 탐지하는 방법

2. 오용(misuse) 침입탐지 기법

   - 과거의 침입 행위들로부터 얻어진 지식으로부터 이와 유사하거나 동일한 행위를 분석하는 기법

   - 방법이 간단하고 효율적이어서 상용제품에 널리 이용되지만 조금만 변형된 공격에도 Signature가 달라 침입을 

      탐지하지 못하는 경우가 있음

     ? 조건부 확률 이용 : 특정 이벤트가 침입일 확률을 조건부 확률을 이용하여 계산하는 방법

     ? 전문가 시스템 : 축약 감사 사건과 일치하는 사건을 명시하며, 공격 패턴을 탐지하고 이미 설정된 규칙에 따라 처리하는 방법

     ? 상태전이 분석 : 공격패턴을 상태전이의 순서로 표현하며, 초기의 상태에서 최종 상태로의 전이 과정

                               즉 침입과정을 규칙 기반으로 탐지 하는 방법

     ? 키스트로크 관찰 방법 : 사용자의 키스트로크를 감시하여 공격패턴을 나타내는 특정 키 스트로크 순서를 패턴화 하여 침입을 방지

     ? 모델에 근거한 방법 : 공격 패턴을 DB화 하고 특정 공격패턴에 대해 DB를 참조하여 침입 여부를 탐지

 

IDS의 장점

1. 해킹 방법을 기반으로 해커의 침입을 감지 하므로 신기술의 적용이 빠름.

   - 외부로부터의 공격뿐만 아니라 내부자에 의한 해킹도 차단할 수 있으며, 이에따라 기존 방화벽이 지원하지 못하는 ID도용을 통한

      내부 공격자의 해킹도 차단

2. 접속하는 IP에 상관없이 침입을 차단할 수 있음

   - 기존 방화벽은 인증된 IP로의 공격은 막지 못하므로 해커들이 인증된 IP로 공격이 성공하면 방화벽이 무용지물이 되었으나

     IDS는 IP에 상관없이 모든 패킷에 대한 검사를 수행하므로 더욱 안전

3. 시스템 침입에 즉시 대응이 가능

   - 해킹 사실이 발견 되었을 때 해킹에 관한 정보를 휴대전화, 무선호출기, 전자우편 등으로 즉시 전송, 

     네트워크 관리자가 부재시에도 시스템 보안을 유지할 수 있으며, 탐지에 그치지 않고 침투경로까지 추적해 해커를 적발하며, 

     데이터를 안전한 곳으로 전환시켜 놓는 등 방화벽의 수동 적인 대처와는 달리 적극적인 보안 기능을 갖출 수 있음.

 

H-IDS의 장점

1. 정확한 탐지가 가능.

   - 실제로 일어난 이벤트를 포함하는 로그를 사용하므로 보다 정확하다.

2. 시스템 이벤트 감시

   - 사용자와 파일의 접근활동, 파일의 허용의 변화, 새로운 실행 파일을  설치하려는 시도 그리고 특정한 서비스의 접근을 감시

   - 공격자가 어떤 명령을 실행시켰는지, 어떤 파일을 open 시켰는지, 어떤 system call을 실행시켰는지, 어떤 위험한 명령어를 실행시켰는지 

     정확히 관리자에게 통보할 수 있다.

3. N-IDS이 놓치는 공격 탐지

   - 중요한 서버의 터미널로부터의 공격

   - 시스템 내부에서 공격

 4. 암호화 / 스위치 환경에서 적합

   - H-IDS는 중요한 호스트에 직접 탑재되므로 스위치된 환경의 Network와 무관

   - N-IDS는 암호화 통신을 하는 구간에서는 많은 제한을 받을 수 있다.

5. 추가적인 하드웨어 불필요

   - 별도의 시스템이나 네트워크 장비가 추가 요구되지 않음.

 

H-IDS의 단점

1. 특정 기기 또는 기관의 정확한 시스템 구성을 알아야 함

2. 툴의 기능 향상이나 다른 시스템에 적용이 어렵다.

3. 네트워크와 관련된 행위는 분석할 수 없다.

4. 감시자료의 보관 및 처리를 위해 디스크, 처리시간 등의 자원이 필요하다.

5. 운영체제가 취약할 경우 툴의 무결성 모장이 어렵다.

6. 특정 기기에 의존하므로 설치 비용이 많이 든다.

7. 다른 방법에 비하여 유지관리 비용이 많이 든다.

 

N-IDS의 장점

1. 저렴한 투자비용

   - Network traffic을 감시할 수 있는 전략적인 위치에만 설치(효과적인 침입탐지 가능)

   - 다양한 호스트를 관리하는 SW필요 없음

2. H-IDS이 놓치는 공격 탐지

   - H-IDS는 모든 패킷의 헤더를 볼 수 없으므로 모든 종류의 공격을 탐지할 수 없다.(TearDrop, IP 기반의 DOS공격)

   - Payload를 검사 함으로써 특별한 공격에 사용되는 Command 와 Syntax를 찾아냄

3. 공격 흔적 제거의 난이

   - Network traffic을 이용하므로 공격자는 흔적을 제거할 수 없다.

   - Capture 된 데이터는 공격의 방법 뿐 아니라 사후 조사에 사용될 많은 정보를 포함하고 있다.

4. 실시간 탐지와 대응

   - TCP Dos 동격을 당하는 시스템이 감지되면 곧바로 TCP reset으로 공격을 중지

   - H-IDS는 공격을 인식 못하기 때문에 공격 행위가 실행된 후에 조치를 취한다.

5. 실패한 공격의 탐지

   - N-IDS를 방화벽 앞단에 설치하면 방화벽이 차단하는 공격도 탐지할 수 있다.

6. 운영체제 독립적

 

N-IDS 단점

1. 특정 기기 내에서 이루어지는 명령어에 대한 탐지는 불가

2. 통신 내용이 암호화된 경우 침입 탐지 불가

3. 랜 스위치 등으로 네트웍 전체의 내용을 감시하는 것이 어려움

4. 현재의 네트워크 기반 IDS는 초고속 네트워크 검사는 어려움

5. 특정 시스템에 대한 정보가 부족하므로 Host-based 도구보다 부정확한 결과를 얻을 수 있다.

6 네트워크 동작과 성능에 영향을 줄 수 있다.(DoS등의 점검시)

7. 침입을 위한 사전 공격 도구로 사용될 수도 잇따.

IPS(Intrusion Prevention System)란:
IDS에서 한발 나아가 공격이 실제 피해를 주기 전에 미리 능동적으로 공격을 차단함으로써 공격 피해를 최소화할 수 있는 능동적 보안시스템

IDS: 특정 패턴을 기반으로 공격자의 침입을 탐지
IPS: 탐지된 공격을 block하여 적극적인 방어활동

가트너그룹의 정의: "IPS는 방지능력과 빠른 반응속도를 위해 인라인에 위치한 제품, 세션기반 탐지 지원, 다양한 종류의 방지 방법 및 방식(시그니처, 프로토콜 어노멀리, 액션 등)을 통해 악의적인 세션을 차단, 세션 기반 탐지를 지원한다"

    IPS의 효과
  1. 웜과 해킹으로부터 유발되는 네트워크 서비스 장애제거
  2. 유해/불필요한 트래픽을 사전 차단하여 네트워크 비용절감
  3. 공격에 대한 적절한 대응및 사전 방어로 관리비용 절감
  4. OS나 애플리케이션의 취약점을 사전에 보완, 한층 높은 보안제공

    기존 주력 제품라인에 따른 구분
  1. 방화벽 기반의 IPS
    -체크포인트의 ‘인터셉트’, 시큐아이닷컴의 ‘NXG 시리즈’ 쥬니퍼의 "IDP"
  2. IDS 기반의 IPS
    - 엔터라시스의 ‘드래곤 IPS’, 윈스테크넷의 ‘스나이퍼 IPS’, NA의 ‘맥아피 인터루쉴드’, LG엔시스의 ‘세이프존 IPS’
  3. 스위칭 기반의 IPS,
    - 라드웨어 ‘디펜스프로’, 탑레이어 ‘AM IPS 5500’
  4. 바이러스월 기반의 IPS - 포티넷의 ‘포티게이트 시리즈’

    하드웨어 타입에 따른 구분
  1. ASIC 기반 IPS
    -티핑포인트의 ‘유니티원’, NA의 ‘맥아피 인터루쉴드’, LG엔시스의 ‘세이프존 IPS’
  2. 서버 기반 IPS
    - 윈스테크넷의 ‘스나이퍼 IPS’, 정보보호기술의 ‘테스 IPS’,넷스크린의 ‘IDP 시리즈’
  3. 스위치 기반 IPS

    설치구성상의 차이점에 따른 구분
  1. 인라인 IPS
    -보호되어야할 시스템과 그 외의 네트워크 사이에서 L2 브리지처럼 작동하며 모든 트래픽은 브리지 장비와 달리 발견해내도록 취약점 검사를 수행한다- 한국ISS, 넷스크린, 티핑포인트, 윈스테크넷
  2. L7스위치
    -침입차단 및 방어 기능에 로드밸런싱 등으로 트래픽을 효과적으로 조절한다는 측면에서 IDS 기반의 IPS보다 선호하는 고객도 많다. -라드웨어, 탑레이어 ,
  3. 호스트기반
    -IPS,NA의 ‘인터셉트’, 조은시큐리티의 ‘싸이폴로’, 임퍼바의 ‘시큐어스피어’
  4. 하이브리드(Hybrid) 스위치
    -호스트 기반의 IPS와 L7스위치의 특성을 함께 가지고 있으며- 앱실드(Appshild), 카바두(Kavado)


    어떻게 선택할 것인가?
    공격에 따라 적절히 대응하는 보안시스템이라는 유연성 측면에서 고려한다면 IDS 기반과 방화벽 기반, 바이러스월 기반 등의 IPS가 우세할 것이며,
    네트워크 퍼포먼스, 성능 측면을 고려한다면 전용 네트워크 프로세서를 탑재한 제품이나 ASIC 기반과 스위칭 기반의 IPS를 선택하는 것이 좋을 것이다.
    퍼포먼스보다 기능측면을 고려하는 소호 등의 소규모사이트라면 방화벽+IDS 등 별도의 부가기능이 추가된 통합적인 형태의 IPS를 구입하는 것도 좋은 대안이다.

    업계의 한 전문가는 “고객들은 자사 네트워크에 맞게 성능의 가이드라인을 세우고 이에 맞는 제품을 선택해야한다”며 “우리 네트워크에서의 문제는 무엇인지, 웜·바이러스 등에 의한 문제가 가장 심각한지, 네트워크 가용성이 중요해 퍼포먼스를 우선해야 하는지 등을 따져보고 이미 기투자된 장비와의 연동성 등도 고려해 선택하는 것이 좋다”고 조언했다.

    하지만 관련 전문가들은 IPS의 기준이 모호하고 다양한 분류에 대한 이견이 분분한 것에 대해 아직 IPS 시장이 본격 형성되지 않았고 선두 업체가 정해지지도 않았기 때문이라고 분석한다. 상반기를 지나 하반기쯤이면 IPS의 대형 레퍼런스가 탄생할 것이고 이를 선점하는 선두업체의 IPS 제품이 IPS의 모델로 시장에서 자연스럽게 자리잡혀 갈 것이라는 전망이다. 따라서 IPS 시장의 진입 초기인 현재의 복잡한 IPS 제품에 대한 분류는 올 하반기를 지나 내년경이면 정리되어 갈 것으로 예측된다.

    한편 관련 전문가들은 사용자들이 IPS를 선정하는 기준으로 최근 가장 중요시하는 것은 웜 차단 기능과 퍼포먼스라고 전한다. 웜이 워낙 기승을 부려 웜에 대한 효과적인 차단기능이 필요해 IPS를 고려하는 경우가 많기 때문이다. 그리고 IPS가 네트워크단에 설치되기 때문에 가용성을 우선해 기가비트급 이상의 성능이 지원되는 ASIC이나 네트워크 프로세서 기반의 IPS 등을 선호한다는 것.

    IPS는 패킷을 바이패스로 미러링해 침입을 탐지하는 IDS와 달리 네트워크의 패킷이 지나가는 길에 설치한다는 특성으로 인해 퍼포먼스가 고객의 최대 관심사가 되고 있다.

    따라서 현재 출시되는 대부분의 IPS들이 기가급을 지원하고 있다. 최소 1Gbps 이상의 속도를 지원하며 올해부터 본격 구현되고 있는 10기가비트 네트워크를 겨냥해 10기가 이상의 속도를 낼 수 있는 IPS를 출시했거나 준비중도 업체들이 많다. 하지만 웜 차단이 IPS 기능의 전부가 아니고 웜이외에도 다양하게 발생할 수 있는 유해 트래픽과 관련된 IPS의 기능들을 눈여겨 봐야하며 피크타임시의 네트워크 대역폭이 최대 500Mbps 정도의 소규모 고객이 기가급 IPS만을 고집하는 것은 과투자가 될 수 있다. 따라서 자사의 네트워크를 잘 살펴보고 이에 맞는 제품을 고르는 지혜가 우선돼야 한다고 관련 전문가들은 지적하고 있다.

    그러나 IPS의 필요성을 느끼는 가장 큰 부분이 바로 웜 차단이며, 전체 네트워크 환경을 고려해 기가급의 IPS를 선호하는 추세는 당분간 이어질 것으로 보인다. 실제로 관련 전문가들은 “현재 웬만한 대학이나 금융, 기업 등에서 기가급 이하의 네트워크를 찾아보기 힘들다”며 “어렵게 기가급 이상의 네트워크를 구축해놓고 저속의 IPS를 네트워크상에 설치해 전체 네트워크의 성능을 떨어뜨리고 싶어하는 고객은 없다. 방화벽도 이런 이유에서 기가로 올라가는 추세”라고 언급한다.



    차세대 IPS에 필요한 10가지 조건

    1. 고도의 정확성
    - 모든 네트워크 트래픽에 대한 완벽하며 철저한 프로토콜 분석
    - 레이어 3에서 레이어 7까지 전방위적인 상태유지(Stateful) 프로토콜 분석
    - 알려진 익스플로잇(exploit)을 정확히 탐지할 수 있는 컨텍스트 기반 다중 트리거, 다중패턴 시그너처(signature) 매치

    2. 단순한 탐지가 아닌 방지
    - 인라인 운영: 공격을 실시간 탐지, 차단하려면 인라인 IPS가 센서를 데이터 트래픽 경로에 위치시켜 모든 패킷을 처리해야한다.
    - 신뢰성 및 가용성 유지: 인라인 IPS의 경우 가동시간이 매우 중요해 안정적 IPS 센서가 필요하다.
    - 고성능 제공: IPS에는 반드시 인라인 탐지 및 방지를 할 수 있는 처리능력, 예를 들면 패킷 지연시간은 1/1000초 이하로 최소화 되야 한다
    - 세밀한 정책적용: IPS는 세밀한 정책설정으로 악의적 트래픽을 차단할지 결정해야한다

    3. 광범위한 공격방지 적용
    현재 또는 앞으로 나타날 모든 공격을 단 하나만으로 막아주는 마법같은 방지는 없다. IPS는 반드시 시그니처 탐지, 이상탐지 및 DoS 탐지 등을 이용, 광범위한 방어범위를 제공해야한다.

    4. 관련된 모든 트래픽 분석
    IPS에는 반드시 광범위한 데이터 캡처 모드를 사용할 수 있는 능력이 있어 탐지 및 방지용으로 모든 관련 트래픽에 액세스할 수 있어야한다.

    5. 고도의 세밀한 탐지 및 대응
    IPS는 특정 호스트에 대한 특정공격을 탐지할 수 있으며 이에 대한 대응책이 시행되도록 해야한다. 세밀성은 보안정책의 실행과 통제에 반드시 필요한 조건이다.

    6. 유연한 정책관리
    오늘날의 엔터프라이즈 네트워크에서 단일 정책은 쓸모가 없다. 세밀한 정책관리를 통해 트래픽을 논리적 그룹으로 나누고 특정공격에 대한 알맞은 대응을 수행해야 한다.

    7. 확장 가능한 위험관리
    IPS는 부하가 많은 상황에도 대응할 수 있는 확장성을 갖춤으로 모니터링할 트래픽, 경고 처리율의 증가를 지원할 수 있어야한다.

    8. 고도의 사후조사 및 보고
    데이터 퓨전에 기반한 강력한 포렌직(사후 조사) 관리는 사고 분석 및 관리를 지원하는데 필요한 인프라를 제공하며 모든 IPS의 필수 요소이다.

    9. 최대 센서 가동시간
    IPS의 가동시간은 안정적인 실시간 탐지 및 방지를 보장하기 위해 신뢰도 높은 센서 등으로 방화벽, 교환기, 라우터 등 보안 및 네트워크 장치와 비슷해야 한다.

    10. ‘와이어 스피드’ 센서 성능
    IPS는 복잡한 네트워크 패킷과 플로우를 검사하는 시스템으로 최고 처리 용량의 방화벽보다 몇 배 이상의 처리 능력을 갖추고 있어야 한다
 
 
 
 
 
==========================================================================================
 
 
IPS 이용사례
 
 
 
지난해부터 붐이 일어난 IPS는 이제 IDS냐 IPS의 논란 단계를 넘어 고객 사이트에 속속 구현되며 그 기능을 뽐내고 있다. IPS는 네트워크 구성을 변형시키지 않는 인라인 모드로 네트워크에 구현돼 유해 트래픽을 차단하는 것은 물론 이를 통해 네트워크의 안전성과 속도를 높여준다.

그러나 아직도 IPS가 과연 우리 네트워크에서 어떤 식으로 구현될 수 있는지, IPS를 구현하면 어떤 효과를 얻을 수 있는지 의문을 가진 고객들이 더 많을 것이다. 여기서는 IPS의 국내 실제 운영사례를 중심으로 IPS가 어떤 식으로 구현될 수 있으며 어떤 장점을 줄 수 있는지 알아본다.


Case Study 1. 광주시청

네트워크에서 발생 가능한 모든 위협 ‘걱정없다’

광주시청은 전산상으로 2개의 구역을 분리해 체계적인 정보관리를 하고 있어, 보안정책, 보안시스템 구축 시에도 각기 다른 방향으로 접근하고 있다. 2개 분리 구역은 광주시청의 내부 핵심 구간인 B구간과 읍·면·동 사업소, 남한산성, 보건지소 등 광주시청 관할 사업소를 연결하는 A구간이다.

이에 따라 A, B 각 구간과 인터넷 및 경기도청 행정망을 연결하는 구역에 각각 윈스테크넷의 스나이퍼 IPS를 구축해 자체 구조에 적합한 보안정책 설정과 IPS를 통한 능동적 대응으로 보안성을 강화하게 됐다.

광주시청 IPS 네트워크 구성도



네트워크 성능 저하 없이 보안정책 적용

광주시청은 당시 IPS의 필요성은 인지하고 있었지만, 구축 후 망구조의 변화와 트래픽 성능 저하를 우려했다. 이에 윈스테크넷은 기존 네트워크의 라우터와 스위치 사이에 IPS를 설치하는 물리적 망구성과 패킷 우회경로 지정기능을 적용한 논리적 망구성을 병행해 광주시청 네트워크 특성에 효과적인 보안정책을 제시했다.

설치 시, IPS를 경유하도록 연결을 재구성하는 것 이외에 어떠한 물리적인 변경도 하지 않아, 공공기관으로서의 업무 연속성을 유지하면서도 적극적인 보안정책 설정이 가능해졌다.

또한 감시, 차단 대상 네트워크에 어떠한 패킷도 발생시키지 않고, 스나이퍼 IPS를 통과한 정상 패킷에 대해서는 맥 어드레스를 포함한 변경도 일으키지 않음으로써 신규 시스템 설치로 인한 네트워크 정상작동 방해 가능성을 제거했다. 또 IPS의 FOD(Fail Over Device) 기능을 적용해 네트워크 단절을 복구, 네트워크의 안정성을 높였다.


Case Study 2. 한미은행

외부 유해 트래픽 완전 차단으로 고객 보호 ‘이상 무’

한미은행은 외부에서 발생되어 금융권으로 들어오는 각종 웜 바이러스와 악의적인 공격에 대해 방어하고 내부에서 발생되는 유해 트래픽을 감지, 차단 조치하고자 IPS 구축사업을 진행, ‘라드웨어의 애플리케이션 스위치(ASⅢ)’ 도입을 결정했다.

IPS 오작동시에도 네트워크 영향 無

AS III는 네트워크 상에서 일어나는 어떠한 형태의 IP나 웹서비스 애플리케이션에 대해 멀티 기가비트 속도의 보안성을 제공하는 다기능 장비로써 포괄적인 트래픽 전달과 실시간 침입방지 및 멀티 기가비트 속도의 DoS/DDoS 공격 차단기능 등을 제공한다.

이를 활용해 한미은행은 AS III의 구축이 완료되면, 외부로부터 유입되는 유해 트래픽을 완벽히 차단해 고객 및 내부 사용자 보호에 만전을 기할 수 있을 것으로 기대하고 있다.

한미은행 IPS 네트워크 구성도



자동업데이트로 최적 보안상태 유지

한미은행의 IPS 구축사업은 현재 진행중이지만 구축이 완료되면 각종 서버와 라우터 등의 내부자원에 대한 방어 및 차단은 물론이고 내부정보 유출 차단, 내부 유해트래픽 자동 감지로 네트워크를 원천적으로 보호할 수 있게 된다. 또 새로운 바이러스 패턴에 대한 자동 업데이트로 항상 최적의 보안상태를 유지할 수 있으며 보고서 분석으로 유해트래픽의 통계적 관리가 가능하다.


Case Study 3. 구리시청

시정 기밀정보·시민 신상 중요정보 해킹 걱정 ‘끝’

구리시청과 같은 지방자치단체는 상위 관청의 통합 전산망의 일부로 자체 규모는 작으나, 하위에 크고 작은 기관을 관리하고 있어 자체적인 보안관리가 중요해짐에 따라 IPS를 도입하게 됐다.

각 동·출장소 등에서 발생되는 유해 트래픽 차단

구리시청은 시정에 관련된 기밀정보, 시민 개개인의 신상에 관한 중요정보를 보관하고 타 관공서간에 중요한 자료들이 네트워크 상에서 교환되는 등 철저한 보안이 시급한 상황이었다. 또한 각동 출장소 등에서 발생되는 불법적이고 치명적인 유해 트래픽 역시 증가하고 있어 이에 대한 대비책도 시급했다.

이를 시정하기 위해 구리시청은 센타비전의 ‘랩투스 ICS’를 도입, 유해트래픽에 의한 대민서비스 장애를 예방하며 시민정보에 대한 안정성을 높였다.

구리시청 IPS 네트워크 구성도



불필요한 네트워크 트래픽 해소

구리시청은 IPS 도입의 가장 큰 효과로 내부정보 유출을 원천적·능동적으로 차단할 수 있는 점을 꼽는다. 또 불필요하게 네트워크 자원을 소모시키는 트래픽을 해소하고 세션상태 실시간 체크, 차단, 탐지정보, 네트워크 자원 소모량, 트래픽 원인 파악 등의 리포팅으로 네트워크상의 문제점을 제거하고 보다 빠르게 안전한 대민서비스를 개시할 수 있어 만족하고 있다.


Case Study 4. 숭실대

통합보안제품으로 보안 걱정 한방에 ‘끝’

숭실대 전산원은 바이러스, 웜, 트로이 목마 등의 공격으로 인한 트래픽 부하로 하루에도 2∼3번씩 네트워크 다운에 시달렸다. 컴퓨터 실습실은 많은 학생들이 공통으로 사용하다 보니 설치해놓은 백신 소프트웨어를 임의대로 삭제해 바이러스나 웜에 무방비 상태로 노출되기 일쑤였다.

웜·트래픽 공격으로 인한 네트워크 다운 ‘NO’

또, 지적 호기심이 강한 일부 학생들은 바이러스나 웜을 만들어 유포하기도 하고, 내부 서버 해킹을 시도하는 등 보안상의 다양한 문제가 나타나 이를 해결하기 위해 각각의 모듈이 하나의 기본 엔진에 통합된 하드웨어 일체형 통합 보안 제품 ‘포티게이트-500’을 도입했다. 전산원은 포티게이트-500의 기능 중 바이러스월, IPS, QoS, 방화벽 기능만을 사용하고 있다. 방화벽은 30개의 정책을 적용해 수문장 역할을, IPS는 해킹 트래픽 탐지 및 웜 트래픽 차단 역할을 한다.

숭실대 IPS 네트워크 구성도



악성코드 공격에도 네트워크 안전

숭실대 전산원은 포티게이트는 웜, 바이러스에 의한 유발 트래픽을 자동 차단해주고, QoS 기능이 있어 실습실별로 가상랜을 나누어 각각의 인터넷 대역폭을 적용해 네트워크의 안정성을 보장해주는 점이 만족스러웠다고 말했다.

숭실대 전산원은 포티게이트-500을 설치한 이후 단 한 번도 웜이나 바이러스에 의해 네트워크가 다운된 적이 없다. 2003년 최고의 악성 코드로 꼽히는 소빅, 두마루의 출현에도 전산원의 네크워크는 안전하게 유지되고 있다.
 
Case Study 5. LG필립스LCD

네트워크 중단에 의한 업무지연 ‘ IPS ’로 해결

LG필립스LCD는 국내 공장들이 전용선으로 연결되어 있고 전체 인터넷 트래픽이 하나의 관문을 통하여 외부로 나가게 되는 형태로 네트워크가 구성되어 있다. 최상단의 라우터, L4, 이중화 방화벽, L4 순으로 FLB 구성돼 있으며 정상상태에서는 문제없으나 내부에서 웜 트래픽이 유발이 되면 방화벽이 다운되는 문제가 빈번하게 발생했다.

웜 바이러스로 인한 대응방안 부재

또한 내부 바이러스 방역시스템으로 해외 및 외국업체의 백신을 사용하고 있었으나 국외 영업법인과의 연계 때문에 외국의 최신 웜이 국내망으로 유입되거나 특정 웜에 의한 스푸핑이 발생하면 네트워크 레벨에서 적절한 대응 방법을 찾을 수 없어 고심하고 있는 상황이었다. 따라서 LG필립스LCD는 내부/외부에서 발생되는 웜 트래픽에 효과적으로 지속적인 네트워크 서비스가 가능하도록 IPS 도입을 결정했다.

LG필립스LCD IPS 네트워크 구성도



네트워크 전방위에서 능동적 방어 가능

LG필립스는 IPS 설치 위치는 가장 큰 피해를 입고 있는 방화벽 구간으로 결정하고 방화벽 부하를 효과적으로 차단할 수 있는 위치, 즉 내부 L4 스위치 밑에 위치시켜 내부 → 외부로 나가는 웜트래픽 및 IP가 변조된 스푸핑 패킷을 차단시킴으로써 방화벽 구간의 문제점을 해결했고 또한 최근 많이 퍼지는 e메일 관련 웜들에 대한 시그너처를 다수 반영시켜 외부->내부로 유입되는 웜들을 차단토록 설정하여 웜의 확산을 네트워크 전방에서 능동적으로 방어토록 구성했다. IPS 설치 후 LG필립스LCD는 잦은 네트워크 중단으로 인한 업무 지연 때문에 발생할 수 있는 악영향을 IPS 도입을 통하여 제거하고 안정적 네트워크 서비스 제공을 통한 내부 고객 만족도가 향상됐다.


Case Study 6. 한국전산원

초고속국가망 안정성·서비스 질 대폭 향상

한국전산원의 KIX(Korea Internet eXchange)망은 국내 ISP간, 해외 인터넷 연결을 위한 서비스망이기 때문에 신속한 트래픽 소통을 위한 최소한의 보안정책만이 적용돼 있었다. 그러나 전산원은 최근 방화벽 기반의 IPS 시스템인 시큐어닷컴의 ‘NXG4000’을 적용해 국내 인터넷 관문에서 갈수록 고도화되어지는 악성 공격 및 유해 트래픽을 사전에 차단키로 했다.

기 설치된 IDS와 연동으로 ROI 개선

우선 전산원은 IPS 설치로 전체 트래픽(900M~1.2G)의 5~6%정도의 유해 트래픽을 차단, 인터넷 관문에서 정상 트래픽에 섞여 들어오는 유해 트래픽을 차단하여 불필요한 대역폭 낭비 제거했다. 또 기 설치된 정보보호 기술의 ‘테스 IDS’ 시스템과 연동하여 인라인 및 오프라인 장비의 장, 단점을 최대한 활용하는 효율적인 방어 체계 구축, 기존 인프라의 활용도 제고 및 투자보호를 통한 ROI를 개선했다.

한국전산원 IPS 네트워크 구성도



효율적 보안 정책 수립 가능

또 차단된 유해 트래픽을 방화벽의 보안 정책에 의한 것과 IAP(Intrusion Alert Protocol)를 이용한 IDS에 의한 것으로 분리하여 분석할 수 있어 명확하고 효율적인 보안 정책 수립이 가능해졌으며 상시 트래픽 모니터링을 통한 베이스라인 설정으로 갑작스런 유해 트래픽의 발생시에도 차단 정책을 통해 지속적인 서비스가 가능, 서비스의 질을 더욱 향상시킬 수 있게 됐다.


Case Study 7. S통신사

해커로부터 안전한 고객 요금 관리 서비스 유지 가능

S통신사의 네트워크는 전체 통신사의 수입을 관장하는 고객 요금에 관련된 네트워크로서 매우 중요한 자산이다. 평소에 웜의 다량 유입시 네트워크가 불안정했으며, 해커가 항상 목표로 할 수 있는 네트워크로 관리자들의 주의가 필요한 네트워크다.

네트워크 가용성 향상·안정화 달성

따라서 네트워크의 다운이나 지연은 통신사 자체의 매출에 바로 타격을 줄 수 있으며, 고객을 계속해서 유지하기가 힘든 상황이라 S통신사는 탑레이어의 ‘IPS 2000’를 도입, 유해트래픽으로 인한 네트워크 다운을 방지하기로 결정했다.

탑레이어의 IPS 2000은 다량으로 유입되던 웜이 없어짐으로써 네트워크의 가용성이 높아지고 해커로부터의 침입 위험성이 낮아지므로서 완벽한 고객 요금 관리 서비스를 유지할 수 있었다. 또한 비대칭 구조의 네트워크에서 발생할 수 있는 오탐 및 미탐을 제거함으로써 안전한 네트워크 운영이 가능케 됐다.

S통신사 IPS 네트워크 구성도



이중화 네트워크에도 IPS 구현

또한 탑레이어는 이중화 네트워크에 IPS가 도입된 사례가 거의 없는데 반해 S통신사의 이중화 네트워크에 IPS를 설치했다. 이로써 HA 구성으로 따로 IPS를 구성할 경우 발생할 수 있는 오탐과 미탐을 방지, 보다 안전하고 효율적인 IPS를 운영할 수 있게 됐다.

S통신사는 향후 타 네트워크 구간에도 IPS를 도입 예정이며, IPS를 이용하여 네트워크 사용 형태를 분석해 사내 네트워크 건전성을 높이는 데 활용할 예정이다.

 

전용선/ VPN 전용선/ 인터넷 전화/ 멀티PC/ NDAS - '소프트마트' : http://www.soft-mart.co.kr

'scrap' 카테고리의 다른 글

XP 네트워크 명령어  (0) 2010.04.18
IDS  (0) 2010.03.27
IPS  (0) 2010.03.27
[안철수연구소 칼럼] 바이러스 및 악성코드와 백신의 미래  (0) 2010.03.19
[안랩] 파일 기반의 탐지기법  (0) 2010.03.19
IPS란

지난해 발표된 가트너 그룹 보고서에 따르면 1세대 네트워크 IDS 제품은 탐지 성능에 문제가 있어서 신뢰할 수 있는 네트워크에 제한된 소수의 센서만을 설치 가능한 것으로 나타났다. 뿐만 아니라 IDS는 잘못된 탐지 경보를 남발하는 문제가 있어 진짜 공격을 놓칠 위험을 감수하면서도 상당한 자원을 오경보 추적에 소모하게 됨으로써 이미 제한된 보안 인원과 인프라에 심각한 영향을 줄 수밖에 없었다.

고도의 탐지 방법과 공격을 방지할 수 있는 기능이 없는 1세대 IDS는 충분한 성능 지원 없이 단지 보안에 대한 환상만을 제공한다는 점에서 그저 디지털 마지노선에 지나지 않는다. 이에 따라 등장한 것이 바로 침입방지 시스템 ‘IPS’이다.

IPS는 IDS에서 한발 나아가 공격이 실제 피해를 주기 전에 미리 능동적으로 공격을 차단함으로써 공격 피해를 최소화할 수 있는 능동적 보안대책이라는 점이 가장 큰 장점이다. IPS는 OS나 애플리케이션의 취약점을 능동적으로 사전에 보완하고 웜이나 버퍼오버플로우, 특히 비정상적인(Ano-maly) 트래픽이나 알려지지 않은 공격까지 차단할 수 있기 때문에 한층 높은 보안을 제공해준다.

또 IPS의 가장 큰 특징은 기업 외부에서 내부 네트워크로의 침입을 방지하는 것이다. IPS의 도입을 원하는 대부분의 기업들 목표 역시 외부 침입방지이며 효과 역시 유해 트래픽의 원천적인 차단이다.

그렇다면 외부 트래픽을 차단하는 방화벽과 역시 외부 침입을 방지하는 IPS는 어떤 차이가 있는 것일까? 기존 보안시스템인 방화벽은 단순 차단 기능, 알려진 공격패턴 감시 등을 통해 공격을 감지하지만, 님다나 코드레드같은 새로운 공격을 막기에는 역부족이다. IDS 또한 알려지지 않은 공격에 대한 탐지가 곤란하고 내부 공격자를 막기에도 어려움이 있다. 침입탐지의 오판에 따른 시간, 인적, 재정 낭비도 문제점으로 지적된다. 이에 반해 IPS는 알려지지 않은 공격에 대해서 적절하게 대응을 하며 명백한 공격은 사전 방어를 취한다. 또 웜과 바이러스 등의 침입을 네트워크단에서 차단시킴으로 보안 인프라와 네트워크 영향을 제거하며 공격에 대한 사후 조사로 인해 소요되는 관리자 운영 부담을 없애주는 장점이 있다.

이처럼 IPS는 웜 바이러스와 해킹으로부터 유발되는 네트워크 서비스 장애로부터 벗어날 수 있고 부가적으로 유해한 트래픽을 사전 차단함으로써 인터넷 및 네트워크 자원의 효율적 사용을 통한 비용절감을 도모할 수 있다.

하지만 이런 장점에도 불구하고 현재 어떤 기능들을 갖추고 있어야 IPS라고 부를 수 있는가에 대한 기준은 상당히 모호하다.

일선 영업담당자들은 “IPS 제품선정을 위해 BMT를 실시한다는 공고가 뜨면 IPS 전용장비는 물론이고 IDS에 드롭(Drop) 기능을 추가한 제품, L7스위치, 바이러스월 등 각종 장비가 모여든다”며 “최소한 바이러스월과 IPS는 구분된다거나 L7스위치와 IPS의 경계를 지어주는 등 기준이 필요할 것”이라고 언급하고 있다. 즉 IPS의 웜, 바이러스 차단, 네트워크 트래픽 조절 등의 기능으로 인해 바이러스월도 L7스위치도, IDS도 모두 약간의 기능을 추가하면 IPS라고 부를 수 있는 제품으로 둔갑한다는 것이다.


자사 상황 고려 필수

이처럼 현재 출시된 IPS들은 그 출신성분, IPS라는 이름을 달고 내놓은 제품 이전 제품은 어떤 것을 보유하고 있었느냐에 따라 방화벽 기반의 IPS, IDS 기반의 IPS, 스위칭 기반의 IPS, 바이러스월 기반의 IPS 등으로 나눌 수 있다. 또 전용 ASIC 기반, 네트워크 프로세서를 탑재했느냐에 따라 ASIC 기반 IPS, PC 서버 등 서버에 올렸느냐에 따라 서버 기반 IPS, 스위치 기반 IPS 등 하드웨어 타입에 따라 나누기도 한다. 여기서 또 기능상의 분류로 들어가 세션 기반, 패킷 기반, 그리고 스위칭 기반이냐 등으로 분류될 수도 있다.

IDS 기반의 IPS로는 엔터라시스의 ‘드래곤 IPS’, 윈스테크넷의 ‘스나이퍼 IPS’, NA의 ‘맥아피 인터루쉴드’, LG엔시스의 ‘세이프존 IPS’ 등이 속한다. 또 방화벽 기반의 IPS로는 체크포인트의 ‘인터셉트’, 시큐아이닷컴의 ‘NXG 시리즈’ 등이며, 스위칭 기반의 IPS로는 라드웨어 ‘디펜스프로’, 탑레이어 ‘AM IPS 5500’ 등, 바이러스월 기반으로는 포티넷의 ‘포티게이트 시리즈’ 등이 속한다. 한편 전용 ASIC 기반 네트워크 프로세서가 탑재된 제품으로는 티핑포인트의 ‘유니티원’, NA의 ‘맥아피 인터루쉴드’, LG엔시스의 ‘세이프존 IPS’ 등이며, 서버 기반으로는 S/W 형태로 출시돼 별도의 서버에 탑재해야하는 윈스테크넷의 ‘스나이퍼 IPS’, 정보보호기술의 ‘테스 IPS’, 넷스크린의 ‘IDP 시리즈’ 등이다.

혹자는 IPS를 세션 기반이냐 패킷 기반이냐 나누고 세션 기반이 패킷 기반보다 시그니처 분석 등으로 세심한 공격탐지가 가능하다는 식의 주장을 하기도 하지만 이런 분류는 별로 의미가 없다는 것이 전문가들의 주장이다. IPS는 네트워크상에 위치하는 제품인 만큼 세션과 패킷을 동시에 처리해야 하며 대부분의 제품들이 세션과 패킷을 혼용해서 출시돼 있어 세션이나 패킷이냐의 분류는 잘 쓰지 않는다.

한편 IPS의 설치구성상의 차이점과 기능에 따라 인라인 IPS, L7스위치, 호스트기반 IPS, 하이브리드(Hybrid) 스위치 등으로 구분하기도 하는데 인라인 IPS는 보호되어야할 시스템과 그 외의 네트워크 사이에서 L2 브리지처럼 작동하며 모든 트래픽은 브리지 장비와 달리 발견해내도록 취약점 검사를 수행한다. 현재 통용되고 있는 한국ISS, 넷스크린, 티핑포인트, 윈스테크넷 등 국내외 업체들의 IPS 제품들이 대부분 여기에 속한다. 또 L7스위치는 지난 1.25대란을 겪으며 일부 기업과 통신사 등에 공급, 효과적으로 웜 바이러스를 차단할 수 있다는 입소문을 타고 침입차단의 강자로 부상했다.

유독 국내에서는 L7스위치가 IPS 제품으로 통용되고 있는데 침입차단 및 방어 기능에 로드밸런싱 등으로 트래픽을 효과적으로 조절한다는 측면에서 IDS 기반의 IPS보다 선호하는 고객도 많다. 대표적으로 라드웨어, 탑레이어 등 L7스위치 기반의 IPS가 여기에 속한다. 또 보호를 필요로 하는 각 서버에 탑재돼 보안기능을 발휘하며 시큐어 OS와 비슷한 기능을 수행하는 호스트기반 IPS는 NA의 ‘인터셉트’, 조은시큐리티의 ‘싸이폴로’, 임퍼바의 ‘시큐어스피어’ 등이 속한다. 하이브리드 스위치는 호스트 기반의 IPS와 L7스위치의 특성을 함께 가지고 있으며 대개 하드웨어 기반으로 L7스위치처럼 서버의 앞단에 위치한다.

하지만 하이브리드 스위치는 일반적으로 네트워크 IPS 타입의 룰셋보다 호스트 기반의 IPS와 비슷한 정책을 사용하며 여기에 속하는 제품은 앱실드(Appshild), 카바두(Kavado) 등에서 취급한다.

이처럼 많은 분류들이 상존하고 있으나 이런 분류들은 각각의 장단점이 존재하며 이 분류가 절대적 우위를 가리는 판단기준이 되지는 않는다. 공격에 따라 적절히 대응하는 보안시스템이라는 유연성 측면에서 고려한다면 IDS 기반과 방화벽 기반, 바이러스월 기반 등의 IPS가 우세할 것이며, 네트워크 퍼포먼스, 성능 측면을 고려한다면 전용 네트워크 프로세서를 탑재한 제품이나 ASIC 기반과 스위칭 기반의 IPS를 선택하는 것이 좋을 것이다. 퍼포먼스보다 기능측면을 고려하는 소호 등의 소규모사이트라면 방화벽+IDS 등 별도의 부가기능이 추가된 통합적인 형태의 IPS를 구입하는 것도 좋은 대안이다.

업계의 한 전문가는 “고객들은 자사 네트워크에 맞게 성능의 가이드라인을 세우고 이에 맞는 제품을 선택해야한다”며 “우리 네트워크에서의 문제는 무엇인지, 웜·바이러스 등에 의한 문제가 가장 심각한지, 네트워크 가용성이 중요해 퍼포먼스를 우선해야 하는지 등을 따져보고 이미 기투자된 장비와의 연동성 등도 고려해 선택하는 것이 좋다”고 조언했다.

하지만 관련 전문가들은 IPS의 기준이 모호하고 다양한 분류에 대한 이견이 분분한 것에 대해 아직 IPS 시장이 본격 형성되지 않았고 선두 업체가 정해지지도 않았기 때문이라고 분석한다. 상반기를 지나 하반기쯤이면 IPS의 대형 레퍼런스가 탄생할 것이고 이를 선점하는 선두업체의 IPS 제품이 IPS의 모델로 시장에서 자연스럽게 자리잡혀 갈 것이라는 전망이다. 따라서 IPS 시장의 진입 초기인 현재의 복잡한 IPS 제품에 대한 분류는 올 하반기를 지나 내년경이면 정리되어 갈 것으로 예측된다.

한편 관련 전문가들은 사용자들이 IPS를 선정하는 기준으로 최근 가장 중요시하는 것은 웜 차단 기능과 퍼포먼스라고 전한다. 웜이 워낙 기승을 부려 웜에 대한 효과적인 차단기능이 필요해 IPS를 고려하는 경우가 많기 때문이다. 그리고 IPS가 네트워크단에 설치되기 때문에 가용성을 우선해 기가비트급 이상의 성능이 지원되는 ASIC이나 네트워크 프로세서 기반의 IPS 등을 선호한다는 것.

IPS는 패킷을 바이패스로 미러링해 침입을 탐지하는 IDS와 달리 네트워크의 패킷이 지나가는 길에 설치한다는 특성으로 인해 퍼포먼스가 고객의 최대 관심사가 되고 있다.

따라서 현재 출시되는 대부분의 IPS들이 기가급을 지원하고 있다. 최소 1Gbps 이상의 속도를 지원하며 올해부터 본격 구현되고 있는 10기가비트 네트워크를 겨냥해 10기가 이상의 속도를 낼 수 있는 IPS를 출시했거나 준비중도 업체들이 많다. 하지만 웜 차단이 IPS 기능의 전부가 아니고 웜이외에도 다양하게 발생할 수 있는 유해 트래픽과 관련된 IPS의 기능들을 눈여겨 봐야하며 피크타임시의 네트워크 대역폭이 최대 500Mbps 정도의 소규모 고객이 기가급 IPS만을 고집하는 것은 과투자가 될 수 있다. 따라서 자사의 네트워크를 잘 살펴보고 이에 맞는 제품을 고르는 지혜가 우선돼야 한다고 관련 전문가들은 지적하고 있다.

그러나 IPS의 필요성을 느끼는 가장 큰 부분이 바로 웜 차단이며, 전체 네트워크 환경을 고려해 기가급의 IPS를 선호하는 추세는 당분간 이어질 것으로 보인다. 실제로 관련 전문가들은 “현재 웬만한 대학이나 금융, 기업 등에서 기가급 이하의 네트워크를 찾아보기 힘들다”며 “어렵게 기가급 이상의 네트워크를 구축해놓고 저속의 IPS를 네트워크상에 설치해 전체 네트워크의 성능을 떨어뜨리고 싶어하는 고객은 없다. 방화벽도 이런 이유에서 기가로 올라가는 추세”라고 언급한다.

차세대 IPS에 필요한 10가지 조건

1. 고도의 정확성
- 모든 네트워크 트래픽에 대한 완벽하며 철저한 프로토콜 분석
- 레이어 3에서 레이어 7까지 전방위적인 상태유지(Stateful) 프로토콜 분석
- 알려진 익스플로잇(exploit)을 정확히 탐지할 수 있는 컨텍스트 기반 다중 트리거, 다중패턴 시그너처(signature) 매치

2. 단순한 탐지가 아닌 방지
- 인라인 운영: 공격을 실시간 탐지, 차단하려면 인라인 IPS가 센서를 데이터 트래픽 경로에 위치시켜 모든 패킷을 처리해야한다.
- 신뢰성 및 가용성 유지: 인라인 IPS의 경우 가동시간이 매우 중요해 안정적 IPS 센서가 필요하다.
- 고성능 제공: IPS에는 반드시 인라인 탐지 및 방지를 할 수 있는 처리능력, 예를 들면 패킷 지연시간은 1/1000초 이하로 최소화 되야 한다
- 세밀한 정책적용: IPS는 세밀한 정책설정으로 악의적 트래픽을 차단할지 결정해야한다

3. 광범위한 공격방지 적용
현재 또는 앞으로 나타날 모든 공격을 단 하나만으로 막아주는 마법같은 방지는 없다. IPS는 반드시 시그니처 탐지, 이상탐지 및 DoS 탐지 등을 이용, 광범위한 방어범위를 제공해야한다.

4. 관련된 모든 트래픽 분석
IPS에는 반드시 광범위한 데이터 캡처 모드를 사용할 수 있는 능력이 있어 탐지 및 방지용으로 모든 관련 트래픽에 액세스할 수 있어야한다.

5. 고도의 세밀한 탐지 및 대응
IPS는 특정 호스트에 대한 특정공격을 탐지할 수 있으며 이에 대한 대응책이 시행되도록 해야한다. 세밀성은 보안정책의 실행과 통제에 반드시 필요한 조건이다.

6. 유연한 정책관리
오늘날의 엔터프라이즈 네트워크에서 단일 정책은 쓸모가 없다. 세밀한 정책관리를 통해 트래픽을 논리적 그룹으로 나누고 특정공격에 대한 알맞은 대응을 수행해야 한다.

7. 확장 가능한 위험관리
IPS는 부하가 많은 상황에도 대응할 수 있는 확장성을 갖춤으로 모니터링할 트래픽, 경고 처리율의 증가를 지원할 수 있어야한다.

8. 고도의 사후조사 및 보고
데이터 퓨전에 기반한 강력한 포렌직(사후 조사) 관리는 사고 분석 및 관리를 지원하는데 필요한 인프라를 제공하며 모든 IPS의 필수 요소이다.

9. 최대 센서 가동시간
IPS의 가동시간은 안정적인 실시간 탐지 및 방지를 보장하기 위해 신뢰도 높은 센서 등으로 방화벽, 교환기, 라우터 등 보안 및 네트워크 장치와 비슷해야 한다.

10. ‘와이어 스피드’ 센서 성능
IPS는 복잡한 네트워크 패킷과 플로우를 검사하는 시스템으로 최고 처리 용량의 방화벽보다 몇 배 이상의 처리 능력을 갖추고 있어야 한다. 

'scrap' 카테고리의 다른 글

IDS  (0) 2010.03.27
IPS  (0) 2010.03.27
[안철수연구소 칼럼] 바이러스 및 악성코드와 백신의 미래  (0) 2010.03.19
[안랩] 파일 기반의 탐지기법  (0) 2010.03.19
[안랩] 에뮬레이터와 샌드 박스  (0) 2010.03.19
어느 날 운영자님께서 물으셨지....
모스알아?? 네 저 그거 땄는데요?? 
MOSS라고 쳐봐.....;;;
네;;;;;

그때 부터 Windows Server2008 과 MOSS, AD, Exchange Server 와의 동거가 시작될 줄이야;;;
왐마;;;
몇 일간 Windows 64bit로 Exchange 2008과 MOSS로 삽질하다가.....
32bit로 갈아타라고 해서;;; 다시 삽질 반복......
Exchange 서버와 MOSS는 웬만하면 한 서버에 같이 깔지 않는 다는 것을 알고 좌절;;
그걸로 2주간 삽질했는데ㅠㅠ

MOSS 설치 Exchange 설치 20번 넘게 해본듯;;ㅋㅋㅋ
그래서 두개의 설치 메뉴얼을 만들었습니다. 현재는 MOSS 카페에만 올려놨는데 여기다가도 올려야겠네요.

자 그럼 이제 시작하도록 하겠습니다.!
안녕하세요. moltak 입니다. 이번에 진행할 내용은 사용자 정의 Exception 입니다. 

이번 칼럼은 (1) exception 만들기 (2) stl exception 사용하기 (3) stl exception 확장하기 순서로 진행하겠습니다.

C++을 사용할 때 예외처리를 하기 위해 try/catch를 사용하시죠? C에서는 if를 사용하겠죠.
자 일단 STL exception 을 한번 보시죠.


STL exception은 exception 클래스를 상속받아 사용됩니다. 가장 많이 사용하는 exception으로 bad_alloc이 있죠. 
exception 은 좋긴 하지만 정확한 정보를 얻기에는 조금 힘이들죠. exception을 사용하는 방법은 다음에 보도록 하고 여기서는 자신만의 exception class를 만들어 exception 이 발생했을 때 더 많은 정보를 얻도록 해보조.

일단은 자신만의 클래스를 하나 만드는 것이 좋겠죠? 저는 KException 으로 지었습니다. 그리고 아래와 같이 만들었죠.


하지만 우리는 많은 정보를 넣어야하죠. 제가 넣고 싶은 정보는 [Exception Message], [Exception Function], [Exception Line]입니다. 그것들을 받을 수 있게 다시 작성하였습니다.

위에 코드를 잠깐 설명하자면 생성자에서 [exception 종류], [exception 함수], [exception 라인]을 받아서 단순히 저장하는 역할 을 하고 있습니다. 그리고 이것들을 저장시킬 수 있는 멤버 변수들을 선언했고 m_Message에 exception 내용들을 저장해서 what() 함수에서 리턴해 주는 역할 을 하고 있습니다. 일단 예외를 발생 시켜 보죠.


위와 같이 하면 ex.what() 함수가 실행되면서 사용자 정의 메시지와, 에러가 난 함수, 그리고 라인을 볼 수있습니다.
__FUNCTION__ 과 __LINE__ 은 각각 함수와 라인을 보여 주는 매크로입니다.

근데 현재 KException는 아직 조금 부족합니다. 사용자가 what의 출력을 다르게 해주고 싶다거나 다른 변수를 넣고 싶은 경우가 있을 수 있는데 KException은 확장이 조금 어렵죠. STL Exception 을 보면 exception 클래스를 상속받아 여러가지 다른  exception 들이 존재한다는 것을 알 수 있습니다. 우리도 그렇게 만들어 보죠.

KException_File 클래스를 만들었습니다. KException_File클래스는 KException 클래스를 상속받아 구현되며 KException은 
virtual const char* what() = 0; 클래스를 만들어 추상 클래스로 만들었습니다. 이제 KException은 인스턴스화 되지 못하고 다만 자식 클래스의 인스턴스를 사용할 때만 사용됩니다. 

위와 같이 클래스 멤버 함수를 정의했습니다. 이제 어느 정도의 확장성은 가질 수 있게 되었네요. 아직 한참 더 만들어야 하지만.ㅋㅋ exception 이 발생했을 때는 아래와 같은 방법으로 받으면 되죠.

이와 같은 방법으로 자신만의 exception을 만들어서 사용 할 수있습니다. design pattern을 넣어서 조금 더 멋지게 만들면 나중에 사용하기 좋겠네요. 지금은 이쯤에서 마치도록 하겠습니다. 그럼 즐프하세요.

'Programming > 이것저것' 카테고리의 다른 글

enum 문자열  (0) 2010.04.09
ASCII Table  (0) 2010.04.05
Handshking  (0) 2010.03.19
Sliding Window  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
교재(Advanced Digital Logic Design -> Sunggu Lee)

Combinational Logic = 현재의 출력이 현재의 입력에 의해서만 영향 받음(memory element 없음)
Sequential Logic = Combinational Logic + memory element
대부분의 Digital System은 Sequential Logic이다.

F/F = edge-triggered memory element
Latch = level-triggered memory element

hazard = Glitches가 생기는 현상.
static hazard, dynamic hazard

Glitches - 노이즈, 삐침
setup-time: edge 직 전 0.1ns(공정에 따라 다름)
hold-time: edge 직 후 0ns-0.01ns(공정에 따라 다름)
setup-time, hold-time때는 D입력이 valid 해야한다. (값이 유지되고 있어야 한다.)
setup-time, hold-time때 D입력이 valid 하지 못한 상태를 Meta-stable 상태라 한다.

glitches가 clock이나 reset에 들어가면 큰 문제가 되지만 D단자에 들어 갔을 경우에는 큰 문제가 생기지 않는다. setup-time, hold-time 때문에 큰 영향을 미치지 않음.

delay 종류 2개
게이트의 입력에서 게이트의 출력까지 지연되는 시간: propagation delay
전선에서의 지연 시간: wire delay

D F/F = Delayed F/F
보통 propagation delay 의 시간이 hold-time에 비해 10배 정도 길기 때문에 위험하지 않다.

Logic Synthesis = VHDL을 해석해서 로직을 만들어 줌.(컴파일러)
S/W = state state 마다 실행됨. sequential 하고 Delay 개념이 없음
H/W = 모든 state 가 동시에 실행됨. parallel 하다. delay 개념이 있다.(wire delay, propagation delay)


'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
Digital_Clock TestBench  (0) 2010.04.10
D F/F Verilog  (0) 2010.04.07

TCP는 두 호스트들 간에 정보를 전달하기 전에 접속이 먼저 필요하다. 그 때 3Way Handshaking 이라는 방법이 필요하게 된다.

보통 위 그림과 같은 방법이다. 그림을 보면 화살표 세개가 있는 것을 알 수 가 있다. 저게 3Way Handshaking이다. 데이터를 전송하기 전에 서로 연결 설정을 해야하는데 그 때 필요하게된다. TCP 프로토콜을 사용한다면 무조건 저 방법으로 접속을 한 후 데이터 전송이 이루어지게 된다.

두 호스트가 접속을 끊을 때는 4Way Handshaking을 사용한다.

둘이 데이터를 전송하고 있었다고 가정하자. 클라이언트가 전송이 다 되었다고 FIN/ACK를 보낸다.
① B는 A에게 종료 요청의 메시지를 담은 FIN 패킷을 전송한다.
② A는 B에게 종료메시지 FIN을 주는 것이 아닌 응답을 받았다는 의미로 ACK 패킷을 보낸다. 이것은 A가 자신은 아직 끝날 준비가 되지 않았다는 것이다.
③ A는 B에게 자신도 종료할 준비가 다 됐다는 뜻으로 FIN 패킷을 보낸다.
④ B는 알았다는 의미인 ACK를 보내는데 이 후 둘의 연결은 종료된다.

'Programming > 이것저것' 카테고리의 다른 글

ASCII Table  (0) 2010.04.05
사용자 정의 exception (1)  (0) 2010.03.21
Sliding Window  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
패킷이 전달될 때 버퍼가 사용이 된다는 것은 다들 알고 있을 것이다. 하지만 데이터 순서가 어떻게 되는지 어떤 방식으로 전송이 되는지에 대해서는 잘 모를 수도 있다. TCP와 같이 데이터 전송에 대해 보장하는 프로토콜 같은 경우는 슬라이딩 윈도우 라는 방식을 사용한다. 그럼 이게 무엇인지 부터 알아보자. 아래는 위키 백과에서 긁어온 내용이다.

슬라이딩 윈도

위키백과 ― 우리 모두의 백과사전.

슬라이딩 윈도(Sliding window)는 두 개의 네트워크 호스트간의 패킷의 흐름을 제어하기 위한 방법이다.

TCP와 같이 데이터의 전달을 보증하는 프로토콜에서는 패킷 하나하나가 전달되었음을 확인 신호(acknowledgement, 이하 ACK)를 받아야하며, 만약 패킷이 중도에 잘못되었거나 분실되어 확인받지 못하는 경우, 해당 패킷을 재전송해야하는 필요가 있다. 슬라이딩 윈도는 일단 '윈도(메모리 버퍼의 일정 영역)'에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도를 옆으로 옮김(slide)으로서 그 다음 패킷들을 전송하는 방식이다.

슬라이딩 윈도는 아직 확인을 받지 않고도 여러 패킷을 보내는 것을 가능케 하기 때문에, 매번 전송한 패킷에 대해 확인을 받아야만 그 다음 패킷을 전송하는 방법(stop-and-wait)을 사용하는 것보다 훨씬 네트워크를 효율적으로 사용할 수 있다.

http://ko.wikipedia.org/wiki/슬라이딩_윈도


쉽게 풀어 써보겠다. 우리가 100바이트의 데이터를 전송한다고 가정해 보자. send함수를 호출하면 전송될 데이터가 전송이 되는 것이 아니라 전송측 버퍼에 저장되게 된다. 그리고 수신측 연락을 기다린다. 왜냐면 수신측 버퍼가 비어있어야 데이터를 전송하면 받을 수 있기 때문이다. 수신측에서 버퍼가 30바이트 비었다고 보내라고 하면 송신측에서 30바이트를 전송한다. 또 수신측에서 50바이트를 받을 수 있다고 하면 송신측에서는 50바이트를 보낸다. 이런 식으로 데이터가 전송이 되게 된다. 


이때 송,수신측 버퍼는 모두 커널에 의해 생성된다.

'Programming > 이것저것' 카테고리의 다른 글

사용자 정의 exception (1)  (0) 2010.03.21
Handshking  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
펜티엄부터 린필드 i5까지, 인텔 어떻게 걸어왔나  (0) 2010.03.18
소켓 소스입니다. 이번엔 Server 구요. 가장 기본형이죠.

'NativeCode > api' 카테고리의 다른 글

Broadcasting 예제  (0) 2010.03.31
UDP Server, Client  (0) 2010.03.31
Client Socket  (0) 2010.03.19
① WSAStartup  (0) 2010.03.19
소켓 함수 정리  (0) 2010.03.19
우리가 자주 사용하게 되는 소켓. 근데 보통 책에 있는 모양대로 사용하게 되죠? MFC는 CSocket이 있고 QT에는 QSocket이 있어서 WinSock을 직접 조작해서 플그래밍 할 일이 별로 없죠. 

하지만 가끔 WinSock을 이용해서 프로그래밍 할 필요가 있는데요. 그때마다 책에 있는 것을 참조 해서 사용하죠. 그리고 책에는 대부분 C스타일로 사용하고 있구요. 

근데 C++ 플그래밍 하는데 C스타일은 좀 어색하지 않나요? 나만 그런가? ㅋㅋ 암튼 전 아래와 같은 방식으로 사용한답니다. C++ 스타일이라고 해봐야 try/catch가 섞여 있는 것 뿐이지만요. 이 블로그 찾아보면 Exeption을 클래스로 전달하는 것으로 대신하고 있는 소스도 있습니다. 참고 하실 분은
http://moltak.tistory.com/entry/C-Style-Socket 여기를 참고 하세요.

암튼 모두들 즐프~~ 하세요ㅋㅋ

 

'NativeCode > api' 카테고리의 다른 글

UDP Server, Client  (0) 2010.03.31
Server Socket  (0) 2010.03.19
① WSAStartup  (0) 2010.03.19
소켓 함수 정리  (0) 2010.03.19
C++ Style Socket  (0) 2010.03.19

C, C++ 소스를 올리려는데 가독성이 너무 안좋군요... 예전 블로그는 어떻게 하는 지 잘 몰랐는데...
티스토리는 정보가 많더군요. 우허허허허ㅋ 그래서 검색했습니다.

http://withrobot.tistory.com/180 여기서 참조를 했습니다.

우리의 목표는 바로 아래 화면ㅋㅋ



자 그럼 시작해 볼까요.
순서는 withrobot 님과 동일 합니다.

설치 방법은 3단계.
1. 다운로드 받아 압축 풀기
2. 티스토리의 스킨에 업로드
3. 스킨 수정하기

1. 다운로드 받아 압축풀기
SyntaxHighLighter의 홈페이지, 다운로드
압축을 해제 하면 아래 그림과 같이 세개의 폴더가 나옵니다.


2. 티스토리의 스킨에 업로드
네 이젠 Scripts 폴더와 Script 폴더에 있는 모든 파일을 올려야 해요.
티스토리의 관리자로 이동해서 스킨탭의 HTML/CSS 편집을 선택해 주세요.

스킨 탭의 HTML/CSS 편집으로 들어가서

파일 업로드를 선택해 주세요


Scripts 폴더와 Styles 폴더의 파일을 모두 업로드해주세요.
전 근데 IE8에서는 업로드가 안되더라구요? 그래서 IE7에서 작업했습니다.


3. 스킨 수정하기
이젠 HTML/CSS를 편집해야 할 차례입니다.
다시 스킨탭에서 HTML/CSS 편집을 선택합니다.
위에 밑줄친 부분에 <link type="text/css" rel="stylesheet" href="./images/SyntaxHighlighter.css"></link> 를 삽입합니다.

그 다음 옆의 슬라이드 바를 끝까지 내리면
</body>
</html> 로 끝나는 것을 확인할 수 있다.

</body> 앞에 다음 문장을 추가한다.

<script class="javascript" src="./images/shCore.js"></script>
<script class="javascript" src="./images/shBrushCSharp.js"></script>
<script class="javascript" src="./images/shBrushCpp.js"></script>
<script class="javascript" src="./images/shBrushCss.js"></script>
<script class="javascript" src="./images/shBrushDelphi.js"></script>
<script class="javascript" src="./images/shBrushJScript.js"></script>
<script class="javascript" src="./images/shBrushJava.js"></script>
<script class="javascript" src="./images/shBrushPhp.js"></script>
<script class="javascript" src="./images/shBrushPython.js"></script>
<script class="javascript" src="./images/shBrushRuby.js"></script>
<script class="javascript" src="./images/shBrushSql.js"></script>
<script class="javascript" src="./images/shBrushVb.js"></script>
<script class="javascript" src="./images/shBrushXml.js"></script>
<script class="javascript">
dp.SyntaxHighlighter.ClipboardSwf = '/flash/clipboard.swf'; 
dp.SyntaxHighlighter.HighlightAll('code');
</script>


자 수고 하셨습니다. 이제 글 쓰시면 되요. 마쳤으면 [저장하기] 버튼을 클릭하고 블로그 화면이 원래대로 나오는지를 확인한다.

자 이제 적용 단계이다.

아쉽게도 위지윅 모드에서 바로 적용하는 방법은 없다. 글을 쓰다가 소스 코드를 넣고 싶은 부분에서 메뉴바에 [EDIT] 버튼을 클릭하여 HTML 편집 모드로 전환한다. 그 다음 다음과 같은 문장을 추가한다.

<textarea name="code" class="Python" cols="60" rows="10">
코드는 여기에 복사한다.
</textarea>

http://withrobot.tistory.com/180 님이 python을 하셨기 때문에 저도 그렇게ㅋㅋㅋ 저 부분을 C++이나 C로 입맛에 맞게 바꿔 주세요.
수고 하셨습니다. 이젠 http://moltak.tistory.com/entry/Server-Socket-1 처럼 만들 수 있을 겁니다. 즐프 하세요~

보안 제품의 기능 확장·웹 보안과 결합 지속

컴퓨터를 사용하는 사람들은 누구나 한 번쯤은 바이러스에 걸려서 고생을 하거나 애드웨어 때문에 원하지 않는 광고 창을 닫느라 땀을 흘린 경험을 가지고 있다. 또 스파이웨어는 사용자가 알아차리지 못하게 정보를 빼돌린다. 이러한 악성코드는 나름대로 각각 ‘성격’을 가지고 있다. 이 ‘성격’은 탄생 초기에는 어설펐지만 수많은 운영체제와 사용자 환경을 겪으면서 ‘진화’해 가고 있는 것이다.


단, 스파이웨어는 사용자가 알아차리지 못하게 정보를 빼돌리고 있었으니 눈에 띄는 직접적인 피해나 번거로움은 없었을지도 모르지만, 쇼핑 사이트나 이동통신 사이트의 사용자 정보 유출 뉴스를 듣고 나면 며칠 후부터 메일과 SMS를 통하여 증가하는 스팸과 광고에 짜증내 본 기억도 떠오를 것이다. 


사용자를 불편하게 하고 정보를 빼내려는 이러한 악성코드가 사라진다면 얼마나 좋을까? 하지만 마치 사회에서 도둑이나 강도가 없길 바라지만 사라지지 않듯이, 운영체제를 만드는 마이크로소프트가 ‘신뢰할 수 있는 컴퓨팅’을 내세우며 보안을 강화해 나가더라도 악성코드는 줄어들지 않고 더욱 교묘하고 은밀하게 정보를 빼내가려고 하고 있다. 도둑이나 강도가 없는 세상은 사람들이 모두가 천사가 되는 영화나 소설 속에서나 가능할 것 같다.
 


영화나 소설과 같은 이야기가 나왔으니 이어서 비유를 해보자면 베트맨에 나오는 악역인 조커의 캐릭터처럼 악성코드도 ‘성격’을 가지고 있다. 그리고 이 ‘성격’은 탄생 초기에는 어설펐지만 수많은 운영체제와 사용자 환경을 겪으면서 ‘진화’해 가고 있다. 사실, 운영체제가 점점 더 거대해지고 많은 기능을 제공하면서 악성코드가 가질 수 있는 ‘성격’은 점점 더 다양해지고 있는 현실이다.
 


그렇다면 최근에 등장하는(또는 등장한 걸 모를 수도 있는) 악성코드들은 어떤 ‘성격’을 가지고 있을까? 악성코드의 미래를 이야기하기 전에 이들의 성장과정인 필모그라피(filmography)를 먼저 아는 것이 도움이 될 것이다.


악성코드, 점점 자신을 숨기다

초기의 악성코드들은 순진한 ‘성격’을 가지고 있었다. 바이러스에 감염되면 벽에 낙서를 하듯이 “아무개 여기 다녀가다”라는 식으로 표시를 하거나 프로그램 내부에 특정한 문자열을 심어서 자신의 사인으로 남기기도 했다. 그냥 어디엔가 자신의 이름이 나온다는 것이 재미있는 그런 호기심 많은 사춘기와 같은 시기였을 테니까. 


그렇게 얌전했던 성격은 1990년대 후반에 들어서면서부터 심각하게 삐뚤어지기 시작했는데, 컴퓨터 운영 체제가 도스(DOS)를 사용하던 것에서 윈도우(Windows) 형태로 바뀌면서부터 더 악동 같은 짓을 하게 되었다. 왜냐하면 윈도우 환경은 집에서 혼자 장난감을 가지고 놀다가 동네 놀이터에 나가서 놀게 되는 것처럼 더 넓고, 더 다양하고, 더 많은(사실 이것이 중요하다! 공격할 수 있는 대상이 무지막지하게 늘어났으니!) 환경을 제공해 주었다. 그뿐만 아니라 인터넷의 대중화는 이러한 놀이터를 연결해서 놀이 동산에 입장한 것처럼 사람들을 쉽게 연결할 수 있게 되었고 악성코드를 만들어서 시험해볼 수 있는 좋은 놀이터를 제공하게 되었기 때문이다.
 


그럼 악성코드는 왜 놀이터를 헤집고 다니게 되었을까? 아이러니컬하게도 악성코드를 만들기 쉬워진 것은 GUI(Graphic User Interface)를 제공하는 운영 체제와 Visual C 등으로 편리해진 프로그래밍 덕분이다. 왜냐하면 악성코드도 사용자가 의도하지 않은, 하지만 그 프로그램을 만든 누군가가 원하는 무엇인가를 수행하는 하나의 소프트웨어이기 때문이다.
 


악성코드들이 순진함에서 점점 삐뚤어진 성격을 가지게 되면서 좀 더 강렬하고 자극적이고 치명적인 모습으로 진화해가기 시작했다. 왜냐하면 보안 회사들의 방어 능력도 점점 좋아지고 빨라졌고 운영 체제를 만들던 마이크로소프트도 자사 운영 체제의 취약점을 보완하기 위해서 많은 노력과 투자를 하기 시작했기 때문이다.

쉽게 이야기하면 초기에 지은 집들은 방범이 허술해서 도둑이 쉽게 들어올 수 있었지만, 경비원을 두고 주인이 직접 문을 점검하고 다니니 악성코드들은 문을 열고 들어오기 위해서 더 힘들게 고생을 해야 했다. 마치 영화 ‘미션 임파서블’에서 컴퓨터에 접근하기 위해서 줄을 타고 내려와서 대롱대롱 힘들게 매달려 있어야 했던 것처럼 말이다.


악성코드, 당신의 안방을 노리다

위에서 간단하게 살펴본 것처럼 악성코드들은 점점 지능적으로 변해갔다. 들키지 않고 오래 남아 있어야 하고 사용자 몰래 무엇인가를 해야 하기 때문이다. 더 강화된 방범 시스템을 피하기 위해서 더욱 높은 수준의 변장과 다양한 침투 도구들이 필요하게 되었다. 사용자들도 한 두 번쯤은 악성코드에 당하게 되면서 인식이 높아졌기 때문에 악성코드를 쉽게 만들어서 마구 뿌릴 수 있던 그런 시절은 지나가버렸다. 


무척 힘들게 집에 침입한 도둑이 그냥 벽에 낙서만 하고 돌아설까? 그냥 가기엔 도둑 입장에서 무언가 허전하고 아쉽고 바보 같은 느낌이 든다. 그렇다. 힘들게 집에 들어갔으니 돈이 될만한 무엇인가를 좀 들고 나가야겠다. 사실 악성코드를 만들 수 있는 정도의 수준이면 사용자의 컴퓨터에서 무엇인가를 집어 나가는 것은 어려운 일도 아니다.(만들어진 것을 이용하는 사용자와 그것을 만들어주는 개발자의 차이란 참으로 크지 않던가?)
 


그래서 처음에는 그 집에 있는 돈이 될만한 정보들을 들고 나가기 시작했다. 대표적으로 사용자의 개인 정보를 노리기 시작했고 사용자에게 광고를 보여주고 돈을 벌어보기도 했다. 그 다음에는 사용자의 금융 정보, 그리고 나중에는 사용자의 데이터 파일까지 내보내기 시작했다.(이쯤 되면 악성코드의 성격이 참 많이 빗나가고 있다.)


악성코드, 크게 한 방을 노리다

보안 소프트웨어의 방어 노력과 사용자의 높아진 경각심으로 인하여 악성코드들은 새로운 방법을 모색하기 시작했는데 그것은 바로 눈에 띄지 않게 더 숨어버리는 것이었다. 처음부터 들어가서 노골적으로 무엇인가를 가져가려고 하니 잘 들키게 되어서, 이젠 몰래 들어간 후에, 훗날을 기약하는 원격 조정 폭탄(?)을 조심스럽게 심어놓는 것이다. 


악성코드가 사용자의 PC를 조금씩 조금씩 장악해 나가면서 자신만의 꿈을 키워 나갔는데 그것은 바로 사용자 PC에 심어놓은 원격 조정 폭탄들을 동원하여서 한 탕 크게 하는 것이다. 말하자면 은행강도 정도로 크게 한탕하고 도망가는 것이라고 할까? 힘들게 한 탕을 하려니 개인 사용자 수준의 정보로는 부족하고 기업이나 기관의 큰 데이터베이스를 노리거나, 공격에 대한 예고를 통해 돈을 요구하는 형태로 발전하게 되었다. 지금도 특정 사이트를 공격하는 D-day가 되면, 많은 개인 사용자 PC들이 사용자도 모르게 좀비가 되어서 공격에 동원되는지 알 수 없을 정도이다.
 


여기까지 오게 되면 순진하게 시작되었던 악성코드의 성격은 수많은 좀비를 앞세운 무장강도 수준으로 삐뚤어진 성격이 되어버린 것이라고 할 수 있겠다. 지금은 악성코드들이 사용자의 PC를 원격으로 조정하기 위하여 영화 ‘마이너리티 리포트’에 나오는 작은 스파이 로봇들을 뿌리는 것처럼 작지만 알아차리기 힘든 에이전트들을 몰래 몰래 뿌리고 있는 중이다. 언제, 어느 사이트를 공격할지는 알지 못하는 채로.


악성코드의 유비쿼터스 시대; 언제 어디서나, 보이지 않게

그렇다면 앞으로 시간이 좀 더 흐르고 나면 이러한 악성코드들을 싹 없애버릴 수 있을까? 안타깝게도 대답은 ‘아니다’이다. 오히려 악성코드들이 활약할 수 있는 분야는 더 다양해지고 있다. 사람들이 PC뿐만이 아니라 노트북을 사용하고(사실 노트북은 PC랑 운영 체제 기반과 환경이 거의 같다), 핸드폰, MP3P, PDA, PMP, PDP, 내비게이션 등 무수히 많은 디지털 기기를 사용하고 있다. 


사용자들은 앞으로 더 많은 개인화한 디지털 기기들을 이용하게 될 텐데, 이들은 모두 운영 체제를 가지고 있고 또 그 취약점을 가지고 있다. 하드웨어 제품을 만드는 회사와 종류는 다를지 몰라도 운영 체제는 마이크로소프트가 거의 독과점을 하고 있는 상황에서 악성코드들에게는 더 다양한 놀이터를 제공하는 것일지도 모른다.
 


사실, 개인화한 기기뿐만 아니라 홈 네트워크가 더 많이 보급되고 가정의 가전 제품들도 급속히 네트워크화한다면 냉장고가 악성코드에 감염되어서 문을 열어 주지 않거나, 반찬을 녹여 버리거나, 냉각기를 세워서 냉장고 앞을 흥건하게 적셔놓을지도 모르는 일이다. 디지털 도어 락이 입력을 거부하거나 디지털 텔레비전이 마음대로 온라인 주문을 하지 않을 거라고 제조업체가 보장할 수 있을까?


사용자 삽입 이미지


악성코드와 보안 제품의 가상화

GUI 환경을 통해 사용자들에게 편리한 환경을 제공했듯이(물론 악성코드에게도 편리한 환경), 최근에는 가상화 환경을 통해 시스템을 절약하고 한정된 자원으로 더 많은 일들을 할 수 있도록 해주는 노력들이 이어지고 있다. 가상화를 통해 구현되는 환경은 사용자 입장에서는 큰 차이를 느끼지 못할 수도 있지만, 시스템의 활용성을 더 높이고 돈을 더 많이 들이지 않아도 된다는 점에서 매우 매력적인 환경이 될 것이다. 


그런데 사용자에게 편리한 환경은 악성코드에게도 편리한 환경이 될 수 있다는 점에서 편리함과 보안성은 동전의 양면과 같은 성격을 가지고 있다. 악성코드가 가상화 환경에서 존재한다면 쉽게 폐기할 수 있을 것이라고 생각할 수도 있지만 가상화 환경에 숨어들어가서 더 찾기 힘들고 치료하기 어려워질 수도 있다. 가상화가 점점 실용적으로 이용될수록 우리가 이제까지 경험하지 못한 새로운 악성코드의 패턴이 등장할 것이라 예상할 수 있다. 


그렇다면 사이버 세상의 미래는 헐리우드식 영화들이 보여주는 것처럼 암울하고 비관적이기만 한 것일까? 아니면 아시아권의 영화들이 보여주는 것처럼 인간적이고 자연적인 모습을 기대할 수 있는 것일까?
 


이에 대한 한 가지 답으로 안티바이러스 및 통합보안 제품의 가상화 기술을 제시할 수 있다. 가상화는 이미 1960년대에 시작된, 생각보다 오래 묵은 기술이다. 오래된 만큼 기술적으로 성숙되어 있고 가상화 개념이 적용된 분야 또한 광범위하다. 보안 업계에서도 이미 오래 전부터 화두였다. 가상화 기술을 도입한 서버, 네트워크 등 여러 가지 솔루션의 등장으로 그 취약점 또한 점점 늘고 있다. 가상화 기술을 확보하지 않고서는 이를 위한 보안 제품도 만들 수 없으며 악성코드는 이 점을 노릴 것이다. 이에 대비하기 위해 안철수연구소를 비롯한 보안 업체는 어느 때보다 기술 확보에 노력하고 있다. 


안티바이러스 분야에서 현재 가장 많이 적용된 가상화 기술은 에뮬레이티드 머신(Emulated Machine) 또는 샌드박스 머신(Sandbox Machine)을 이용한 악성코드 분석 기법이다. 이것들은 각각 나름의 가상화 방법을 가지고 구현되어 있다. 또한 이를 통한 자동 분석 시스템 또한 각광을 받고 있다. 엄청나게 폭주하고 있는 악성코드 샘플을 효과적으로 처리하고 늘어만 가는 악성코드를 효과적으로 처리하기 위해 가상화 기술에서 방법을 찾고 있다. 


현재 안철수연구소는 악성코드 샘플 처리 자동화 시스템에 Light-weight Virtualized Environment 기술을 적용하고 있다. 이 기술은 엔진의 진단율을 높이는 데도 적용하고 있다. 또한 제너릭 디텍션(Generic Detection), 휴리스틱 디텍션(Heuristic Detection), 프로액티브 프리벤션(Proactive Prevention) 등의 기법을 테스트하고 있다. 이런 기술로 악성코드에 더 효과적으로 대응할 수 있으며 더 많은 악성코드를 차단할 수 있다.


통합보안 제품, 더 가볍고 더 빨라지다

한편, 백신 및 통합보안 제품의 변화 추세를 보자면 급변하는 인터넷 환경과 고객의 요구에 대응하며 포인트 솔루션에서 토털 솔루션으로, 다시 웹 2.0 기술을 접목한 서비스 형태로 지속적인 진화를 하고 있다. 단순 안티바이러스 툴을 넘어 사용자의 PC 사용을 더욱 안전하고 편하게 하는 방향으로 변화를 거듭하고 있는 것이다. 특히 최근 통합보안 제품의 변화를 주도하는 방향은 크게 ‘경량화와 가속화’, ‘케어 영역의 확대’로 나누어볼 수 있다. 


인터넷의 급속한 성장과, PC와 PC가 네트워킹된 상황에서 악성코드의 유포 채널이 미디어를 통한 수동적인 방법에서 사이트를 통한 능동적인 방향으로 바뀌어 가고 있다. 그에 따라 악성코드가 기하급수적으로 늘어나고 있다. 이에 대한 대응으로 통합보안 제품이 진단하는 악성코드 DB도 1년에 2배 정도씩 늘어나고 있다.  


최근 PC를 사용하는 주된 목적은 인터넷 쇼핑이나 뱅킹, 동영상, 게임 등 금융과 엔터테인먼트로 집중되고 있다. 이에 따라 운영체제나 타 프로그램 때문에 PC 작동이 끊기거나 지연되는 일이 없기를 바라는 요구가 증가하고 있다.
 

이와 같이 PC 사용의 목적 및 패턴이 변화함에 따라 통합보안 제품에 대한 요구가 기능 중심에서 PC 사용에 미치는 영향을 최소화하는 경량화로 이동하고 있다. 악성코드가 증가함에 따라 통합보안 제품 엔진의 크기가 커지므로 경량화에 대한 요구가 지속적으로 확대될 것으로 보인다. 보안 업체는 엔진 파일 크기의 증가를 최소화하고 행위 기반, 가상화 등의 기술을 접목하는 한편, 파일/프로세스 검사 시 파일 I/O(Input/Output), CPU 사용량을 최소화하기 위한 다양한 방법을 찾고 있다. 


지난해 안철수연구소가 출시한 ‘V3 365 클리닉 2.0’의 경우가 최근 통합보안 제품 업계의 경량화 트렌드를 가장 먼저 반영, 시장에 선보인 예로 들 수 있다. 공통 요소의 모듈화, 최적화를 통해 CPU, 메모리 등 주요 리소스의 사용을 최소화했다. 이로써 용량은 1/10로 줄어들고, 실행과 검사 속도가 이전 버전과 비교해 2-3배 빨라졌다. 특히 메모리 점유율을 개선하여 실시간 감시 중에도 속도 저하를 전혀 느낄 수 없는 수준으로 개선하였다. 


시만텍의 노턴 2009의 경우도 시스템 리소스에 대한 부하를 줄이는 데 초점을 맞춰 통합보안 제품 가동에 따른 PC 속도 저하 문제를 줄이는 데 중점을 두었다고 강조하고 있다. 실질적으로 300MB가 넘는 용량이 100MB로 크게 줄어들었으며 검사 속도 또한 확연히 줄어들었다고 시만텍 측은 설명하고 있다. 


이러한 통합보안 제품의 ‘Lighter and Faster’의 추구는 실시간 감시만 켜두면 버벅거리는 PC 때문에, 그리고 두세 시간의 시스템 검사 시간 때문에 답답해하던 사용자들에게 ‘보안이냐 편리함이냐’란 딜레마를 훌훌 털어버리게 할 수 있는 반가운 성과라고 할 수 있다.


단순 백신을 넘어 토털 PC 케어로

사람들은 컴퓨터를 사용하면서 늘 궁금하고 답답하다. ‘늘 내 PC는 느린 것 같아’, ‘왜 나만 하면 인터넷이 이렇게 느려지지?’ PC에서 발생하는 문제의 원인은 매우 다양하다. 그 해결 방법 또한 원인만큼 복잡하고 다양하다. 하지만 그 원인을 알고 해결할 수 있는 파워유저보다 일반 초보 유저가 절대적으로 많아지고 있다. 단순히 백신 고유의 기능인 악성코드 치료만으로는 ‘편리하고 안전한 PC의 사용’에 어려움을 겪는 사용자가 대부분이라는 것이다. 


이에 보안 업체의 고민이 있고 여기서 통합보안, 토털 케어로의 미래를 엿볼 수 있다. 물론 현재도 레지스트리, 디스크 등 리소스에 대한 최적화, 드라이버 업데이트 등으로 기능 확장을 해 나가고 있으나 아직은 운영체제에서 제공해 주는 기능의 확장에 머물러 있다.
 


향후 보안 업계는 이와 같은 기능 확장과 웹 보안과의 결합이 지속적으로 이루어질 것으로 보인다. 백신이 초기 의료 체계를 모델링해서 나왔듯이 지속적인 모니터링과 관리를 받을 수 있는 서비스 형태로 진화할 것으로 전망된다. 또한 PC에 문제가 있을 때 사용자가 조치하는 수동적인 방법에서 자체적으로 판단하고 능동적으로 대응하는 형태의 ‘능동형 서비스’로 발전해 나갈 것으로 보인다.


도전과 응전은 계속된다

자동차를 타는 사람들이 처음에는 사고에 대응하지 못했지만 점차 안전벨트를 메고, 에어백을 달고, 후진 센서를 달고 하는 식으로 안전에 대한 노력을 해 온 것처럼, 우리가 생각할 수 있는 미래는 지금보다 더 편리한 환경을 제공할 것이다. 


마찬가지로 악성코드가 사라지지 않을 것이 자명하지만, 또 분명한 것은 악성코드들을 막기 위한 인간의 노력은 더 많은 발전을 이룰 것이고, 보안을 전문적으로 연구하는 좋은 기업들의 노력이 빛을 발할 것이라는 점이다. 


악성코드가 들어오는 방법, 악성코드가 숨어 있는 것을 찾는 방법, 악성코드가 최종적으로 노리는 목표를 찾아내고 위험을 제거하기 위한 기술 등 실질적인 방어를 위한 연구를 쉬지 않고 고민하고 찾아내고 있는 전문가들이 있기 때문이다. 그리고 인류의 역사는 끊임없는 공격과 방어에 대한 연구에서 발전하여 왔고 그러한 노력을 통하여 더 살기 좋은 세상을 만들어 왔기 때문이다. 

'scrap' 카테고리의 다른 글

IPS  (0) 2010.03.27
IPS  (0) 2010.03.27
[안랩] 파일 기반의 탐지기법  (0) 2010.03.19
[안랩] 에뮬레이터와 샌드 박스  (0) 2010.03.19
Exploit Site  (0) 2010.03.19
[기획 특집]알려지지 않은 악성코드 탐지 기법

2006년은 컴퓨터 바이러스가 제작 된지 20주년을 기념하는 한 해였다.
이 20년이라는 긴 세월 속에서 컴퓨터 바이러스는 파일 감염을 목적으로 하는 바이러스(Virus)로부터 네트워크를 통한 급속한 확산을 시도하는 웜(Worm) 그리고 데이터 유출을 위한 트로이목마(Trojan Horse)에 이르기까지 다양한 모습으로 발전하였다. 이러한 악성 코드의 위협은 해가 갈수록 증가 추세를 이루고 있으며 기술적인 면에서도 더욱더 위험성을 더해 가고 있어 컴퓨터 사용자들을 불안하게 만들고 있는 것이 사실이다. 그러나 이렇게 증가하는 악성 코드의 위협 에 맞서는 안티 바이러스(Anti-Virus) 업체 역시 새로운 악성 코드의 위협들로부터 컴퓨터 시스템을 보호하기 위해 다양한 대응 방안들을 활발하게 연구하고 있다.
이러한 다양한 대응 방안들의 기본 전제가 바로 “급속하게 확산되는 알려지지 않은 새로운 악성 코드에 어떻게 대응할 것인가?”라는 점이다. 이 명제는 결국 새로운 악성 코드를 어떻게 효과적으로 탐지할 것인가의 문제로 볼 수 있다. 이러한 문제를 해결하기 위해 안티 바이러스(Anti-Virus) 업체의 알려지지 않은 악성 코드 위협에 대응하기 위한 다양한 안티 바이러스(Anti-Virus) 탐지 기법들과 그 탐지 기법들의 특징들에 대해서 알아 보도록 하자.

[1] 악성코드의 증가와 조기 대응의 필요성
[2] 파일기반의 탐지 기법
[3] 에뮬레이터와 샌드박스
[4] MIME 필터링 탐지 기법
[5] 행위 기반 탐지 기법



2. 파일기반의 탐지 기법(File Base Detection Tech)

현재까지 알려진 안티 바이러스(Anti-Virus) 소프트웨어 대부분이 파일 기반(File Base)의 진단법을 사용하고 있다. 이는 대부분의 악성 코드가 특정 운영체제에서 실행되기 위해서는 해당 운영체제에서 실행이 가능한 특정한 파일 형태로 되어 있다는 점에서 기인한 것이다. 그러므로 악성 코드가 윈도우 시스템(Windows System)에서 실행되기 위해서는 윈도우 시스템에서 실행 가능한 파일 포맷인 PE(Portable Executable) 형식을 가지고 있어야 된다는 것이다.


[그림 3] PE(Portable Executable) 형식의 악성 코드 파일

이러한 PE(Portable Executable) 형식의 악성 코드를 진단하기 위해서는 안티 바이러스(Anti-Virus) 소프트웨어 역시 이러한 파일 형식을 인식하고 악성 코드로 판단을 내릴 수 있는 특정 형식의 시그니처(Signature)를 가지고 있어야 된다. 이러한 진단법이 대부분의 안티 바이러스(Anti-Virus) 소프트웨어가 사용하는 시그니처 기반(Signature Base) 또는 스트링(String – 여기서 말하는 스트링이란 일반적인 문자열이 아닌 파일의 헥사코드(Hex Code)를 의미하는 것이다.) 검사 방식이라고 이야기하는 진단법이다. 이러한 시그니처 기반(Signature Base)의 진단법은 악성 코드로 분류된 파일의 특정 부분 또는 고유한 부분을 검사의 대상으로 삼으므로 오탐(False Positive)과 미탐(False Negative)을 최소화하는 정확한 진단이 가능하다는 것과 파일 검사 시에 파일들의 특징적인 부분들만 비교 함으로 빠른 스캐닝(Scanning)을 장점으로 들 수 있다.

그러나 이러한 시그니처 기반(Signature Base) 진단법은 악성 코드의 파일 자체가 몇 백 바이트(Byte)만 바뀌어도 진단이 되지 않는 미탐(False Negative)이 발생함으로 파일이 조금만 변경된 새로운 변형에 대해서는 대응을 할 수가 없게 된다. 그리고 기존에 알려진 악성 코드에 대해서만 대응을 할 수 있으므로 새로운 형태의 알려지지 않은 악성 코드에 대해서는 대응을 할 수 없다는 단점을 가지고 있다.

1) 휴리스틱 탐지 기법 (Heuristic Detection Tech)

이러한 시그니처 기반(Signature Base)의 진단법이 가지고 있는 한계를 극복하고자 개발한 탐지 기법 중 하나가 휴리스틱 탐지(Heuristic Detection) 기법이다. 휴리스틱 탐지(Heuristic Detection) 기법은 일반적인 악성 코드가 가지고 있는 특정 폴더에 파일 쓰기와 특정 레지스트리 부분에 키 생성과 같은 명령어(Instruction)들을 스캐닝 엔진(Scanning Engine)에서 시그니처(Signature)화하여 파일을 검사할 때 이를 사용한다. 그래서 검사 대상 파일이 휴리스틱 시그니처(Heuristic Signature - 이 것을 부스터(Booster)라고도 한다.)와 비교를 통하여 일반적으로 알려진 악성 코드와 얼마나 높은 유사도를 가지고 있는지를 판단하여 알려지지 않은 새로운 악성 코드를 탐지하는 기법이다.
이러한 휴리스틱 탐지(Heuristic Detection) 기법은 검사 대상이 되는 파일에 대해서 휴리스틱(Heuristic) 검사 시에 스캐닝 엔진(Scanning Engine)이 어떠한 형태를 취하는가 에 따라서 아래와 같이 크게 2가지 형태로 나누어서 볼 수 있다.

- 동적 휴리스틱 탐지 기법 (Dynamic Heuristic Detection Tech)
동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 검사 대상이 되는 파일을 가상화된 영역 또는 운영체제와 분리된 특정 공간에서 파일 실행(File Execution)을 통해 수집한 다양한 정보들을 휴리스틱 시그니처(Heuristic Signature)와 비교를 통하여 검사를 수행하는 기법이다. 즉 검사 대상이 되는 파일이 어떠한 형식으로든 실행이 되어야 하며 이러한 점으로 인해 런 타임 휴리스틱 탐지 (Run-Time Heuristic Detection) 기법이라고도 불리고 있다. 이러한 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 이 후에 다룰 에뮬레이터(Emulator)과 샌드박스(Sandbox)에서 조금 더 자세하게 알아 보도록 하자.

- 정적 휴리스틱 탐지 기법 (Static Heuristic Detection Tech)
정적 휴리스틱 탐지(Static Heuristic Detection) 기법은 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과는 반대로 파일에 대해서 어떠한 형식의 파일 실행(File Execution) 없이 파일 자체를 그대로 스캐닝 엔진(Scanning Engine)에서 읽어 들여 휴리스틱 시그니처(Heuristic Signature)와 비교를 수행하는 탐지 기법이다.


[그림 4] 정적 휴리스틱(Static Heuristic)과 동적 휴리스틱(Dynamic Heuristic)

이 외에도 네거티브 휴리스틱(Negative Heuristic – 이 것을 스토퍼(Stopper)라고도 한다.)탐지 기법도 있다. 이는 이제까지 기술한 휴리스틱 탐지(Heuristic Detection) 기법과는 반대로 악성 코드에서 전형 사용하지 않은 윈도우 팝업 창 생성과 같은 명령어(Instruction)들이 존재 할 경우에는 악성 코드로 판단하지 않는 기법이다. 즉, 휴리스틱 시그니처(Heuristic Signature)와 동일한 명령어들이 존재하지 않는 부정의 경우에만 악성 코드로 판단한다.
이러한 형태들의 휴리스틱 탐지(Heuristic Detection) 기법은 기존에 알려진 악성 코드도 탐지가 가능하며 알려지지 않은 새로운 악성 코드 역시 탐지가 가능하다는 점에서 매력적인 탐지기법이라고 할 수 있다. 그러나 이 탐지 기법은 정상 파일을 악성 코드라고 판단하게 되는 오탐(False Positive)의 발생이 가장 큰 단점으로 작용한다. 특히나 파일을 삭제하고 치료하는 안티 바이러스(Anti-Virus) 소프트웨어의 특성상 오탐(False Positive)율이 높게 된다면 컴퓨터 시스템 자체에 큰 문제를 유발할 수 있게 됨으로 이는 치명적인 문제점이라고 볼 수 있다.

2) 제너릭 탐지 기법 (Generic Detection Tech)

앞서 설명한 휴리스틱 탐지(Heuristic Detection) 기법 외에도 알려지지 않은 악성 코드를 탐지하기 위한 기법 중에는 제너릭 탐지(Generic Detection) 기법이라는 것이 있다. 이 탐지 기법은 유사한 형태의 악성 코드 집합을 탐지하기 위해 해당 집합을 이루는 악성 코드 파일들의 공통된 코드 영역(Code Section)을 진단하도록 한다. 그러므로 소스 코드(Source Code)상에서 사용자 코드(User Code)의 변화가 없거나 약간의 수정만 가하여 컴파일(Compile)만 새롭게 하여 생성한 새로운 악성 코드 변형들에 대해 탐지가 가능함으로 유사한 형태의 악성 코드 변형들이 지속적으로 제작되더라도 시그니처(Signature) 업데이트 없이 탐지가 가능하다는 장점이 있다.

이러한 제너릭 탐지(Generic Detection) 기법에서는 일반적으로 파일에 대한 OPcode(Operation Code) 명령어 비교 방식이 많이 사용되고 있다. 이 OPcode(Operation Code) 명령어 비교 방식에는 크게 와일드카드 비교(Wildcard Matching – Don’t Care 비교라고도 한다)와 미스매칭(Mismatching) 방식으로 나누어진다. 먼저 와일드카드 비교(Wildcard Matching)는 유사한 형태의 악성 코드 변형들의 특정 코드 영역(Code Section)에서 사용되는 OPcode(Operation Code) 명령들이 조금씩만 다르고 동일할 경우 해당 다른 OPcode(Operation Code) 명령어 부분에 와일드카드를 적용하여 다른 OPcode(Operation Code) 명령어가 사용되어도 이를 무시하겠다는 것이다.


[그림 5] 메모장(Notepad.exe) 프로그램의 OPcode(Operation Code) 명령어들

[그림 5]를 예로 들어 메모장 프로그램을 원본 악성 코드라고 가정을 한다면 이 원본 악성 코드의 일부 OPcode(Operation Code) 명령어들은 [그림 5]의 붉은색 박스 영역의 순서대로 진행된다. 이렇게 PUSH, PUSH, PUSH, PUSH 순서로 진행되는 OPcode(Operation Code) 명령어들이 다른 악성 코드 변형들에서는 PUSH, PUSH, PUSH, MOV가 사용된다면 마지막 MOV 부분을 와일드카드(Wildcard)로 적용하여 마지막 4번째 OPcode(Operation Code) 명령은 어떠한 것이 사용되더라도 이에 구애 받지 않겠다는 것이다. 이렇게 적용하게 되면 원본 악성 코드와 변형 악성 코드의 전체 OPcode(Operation Code) 명령어 진행 순서는 유사한데 일부가 조금 틀리더라도 모두 진단하게 되는 효과를 구현할 수가 있다. 그러나 미스매칭(Mismatching) 방식은 와일드카드 비교(Wildcard Matching)와는 반대로 MMX(Multi Media eXtension) 명령어 또는 FPU(Floating Point Unit) 명령어와 같이 악성 코드에서 잘 사용되지 않는 명령어들이 [그림 5]의 해당 붉은색 박스영역과 같이 특정 부분에 사용 될 경우, 해당 파일을 악성 코드 변형으로 판단하지 않겠다는 것이다. 이런 미스매칭(Mismatching) 방식은 앞서 설명한 네거티브 휴리스틱(Negative Heuristic) 탐지 기법과 기본적인 개념은 동일하다고 볼 수 있다.

그러나 이러한 제너릭 탐지(Generic Detection) 기법은 악성 코드의 공통된 코드 영역을 진단함으로 새로운 악성 코드 변형들이 제작되더라도 탐지가 가능하다는 장점이 있지만 새로운 악성 코드 변형들이 완전히 새로운 OPcode(Operation Code) 명령어 순서로 진행된다던가 아니면 안티 디버깅(Anti-Debugging)과 암호화(Encryption) 등과 같이 실행 파일 보호 기법을 통해 OPcode(Operation Code) 명령어의 진행 순서를 뒤섞어 놓게 된다면 스캐닝 엔진(Scanning Engine)에서는 이를 탐지하지 못하게 되는 문제가 발생할 수가 있다.

이상으로 파일을 기반으로 알려지지 않은 악성 코드 탐지 기법들에 대해서 알아 보았다. 다음으로는 파일 실행을 통해서 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법 설명 시에 잠시 언급한 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아보도록 하자.[Ahn]

[저자] 안철수연구소 ASEC 장영준 주임연구원 

'scrap' 카테고리의 다른 글

IPS  (0) 2010.03.27
[안철수연구소 칼럼] 바이러스 및 악성코드와 백신의 미래  (0) 2010.03.19
[안랩] 에뮬레이터와 샌드 박스  (0) 2010.03.19
Exploit Site  (0) 2010.03.19
DDOS 개요 및 기법 요약  (0) 2010.03.19

3. 에뮬레이터(Emulator)과 샌드박스(Sandbox)

앞 장에서 설명한 새로운 악성 코드 탐지기법들은 모두 실행 파일(Executable File) 자체를 대상으로 한 탐지 기법들이다. 그러나 이번 장에서 설명하는 에뮬레이터(Emulator)와 샌드박스(Sandbox)는 모두 실행 파일(Executable File) 자체에 관한 탐지 기법이 아니라 해당 실행 파일(Executable File)의 실행을 통해 수집한 정보들을 이용하여 새로운 악성 코드를 탐지하는 기법들이다. 그러므로 앞서 이야기한 바와 같이 실행 파일(Executable File)의 실행을 통하여 새로운 악성 코드를 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과도 상당히 밀접한 연관 관계를 가지고 있는 것이다.

1) 에뮬레이터(Emulator)

사전적인 의미에서 에뮬레이터(Emulator)는 대리 실행기 라는 의미를 가지고 있다. 대리 실행기 라는 의미에서와 같이 에뮬레이터(Emulator)는 실제 컴퓨터 시스템 상에서 실행 파일(Executable File)을 직접적으로 실행하는 것이 아니라 실제 컴퓨터 시스템에 가상(Virtual)의 환경이나 가상의 하드웨어(Hardware) 이미지를 생성하여 해당 가상 하드웨어(Hardware)를 통하여 간접적으로 실행하는 것을 의미한다. 이러한 의미로 인해 일부에서는 에뮬레이터(Emulator)를 이용한 탐지 기법을 코드 에뮬레이션(Code Emulation) 또는 CPU 에뮬레이션(CPU Emulation) 이라고도 이야기 한다.

이 탐지 기법은 실제 컴퓨터 상에서 스캐닝 엔진(Scanning Engine)이 검사를 수행하지만 컴퓨터 시스템 내부에 가상의 CPU와 메모리 등의 가상의 환경을 제공하여 실행 파일(Executable File)을 실행하고 정보를 수집함으로 실제 컴퓨터 시스템에서는 악성 코드로 인한 어떠한 감염 피해도 발생하지 않는다. 이러한 점으로 인해 알려지지 않은 악성 코드를 탐지하기 위한 부분에서는 상당히 강력한 방법이라고 할 수 있다.
이러한 가상의 환경을 이용하는 에뮬레이터(Emulator)가 컴퓨터 시스템에서 구현되기 위해서는 크게 다음과 같은 4가지가 포함 되어야 한다.

- 가상 CPU 환경
실행 파일을 실제 CPU를 이용한 연산과 동일하게 처리하기 위해 일반적인 모든 명령어들뿐만이 아니라 MMX(Multi Media eXtension) 명령어와 FPU(Floating Point Unit) 명령어까지도 모두 처리 할 수가 있어야 한다.

- 가상 메모리 환경
32비트(Bit) 주소 체계에서는 최고 4 기가바이트(GB)까지 확장이 가능하지만 가상의 메모리 환경에서는 이렇게 많은 메모리는 필요하지 않다. 다만, 실행 파일(Executable File)이 실행되었을 때 변경하는 메모리 주소들에 대해 모두 기록하고 이를 추적할 수 있어야 하며 논리적인 메모리 주소와 물리적인 메모리 주소들을 모두 제공할 수 있어야 한다.

- 가상 저장 장치 환경
물리적인 저장 장치와 동일하게 실행 파일(Executable File) 실행 시 발생하는 저장 장치에 대한 파일 읽기 및 쓰기처럼 저장 장치에 대한 I/O(Input/Output)가 발생할 때 에뮬레이터(Emulator)에서는 실제 하드웨어와 동일한 환경을 제공 할 수 있어야 한다.

- 에뮬레이션 제어기(Emulation Controller)
에뮬레이션 제어기(Emulation Controller)는 에뮬레이터(Emulator)에서 가장 핵심이 되는 부분이다. 실행 파일(Executable File)이 가상 환경에서 실행 시 악성 코드로 판단 할 수 있을 정도의 충분한 정보를 수집하고 이를 제어하는 것이 바로 에뮬레이션 제어기(Emulation Controller)이기 대문이다. 그래서 에뮬레이션 제어기(Emulation Controller)에서는 실행 중인 악성 코드를 어느 시점에서 실행을 중단할 것인가와 얼마 정도의 시간을 실행에 소비할 것인가를 판단하고 제어할 수 있어야 한다. 일반적으로는 인텔 X86 CPU에서 에뮬레이션(Emulation)을 수행 하기 위해서는 최소 1,000개에서 최대 30,000개의 CPU 명령어 수행과 함께 45초 정도의 시간 소요를 기본으로 설정 한다.

이렇게 가상의 환경에서 실행 파일(Executable File)을 실행하고 수집된 실행 결과들을 통해서 악성 코드로 판단하는 에뮬레이터(Emulator)는 실제 시스템에 전혀 감염의 피해를 입히지 않고 알려지지 않은 악성 코드를 탐지할 수 있다는 점에서는 상당히 강력한 방법이라고 이야기 하였다. 하지만 에뮬레이터(Emulator)는 스캐닝 엔진(Scanning Engine)이 실행 파일(Executable File)을 검사 할 때마다 모두 가상의 환경에서 실행을 하고 분석을 해야 된다는 점에서는 컴퓨터 시스템에 대한 자원 소모가 커지게 되는 부담을 안고 있다. 이 문제로 인해 전반적인 스캐닝 엔진(Scanning Engine)의 검사 속도 저하로 이어지는 점이 가장 큰 단점이라고 할 수 있다.

2) 샌드박스(Sandbox)
에뮬레이터(Emulator)와 샌드박스(Sandbox)는 실행 파일(Executable File)의 실행을 통하여 수집된 정보를 통하여 악성이라고 판단하는 점에서는 유사한 형태라고 할 수 있다. 그러나 에뮬레이터(Emulator)와 샌드박스(Sandbox)의 가장 큰 차이점은 어떠한 형태로 실행 파일(Executable File)을 실행하고 어떠한 방식으로 악성 코드로 판단할 수 있는 정보들을 수집하는가에 가장 큰 차이점을 가지고 있다.
일반적으로 샌드박스(Sandbox)는 어플리케이션 에뮬레이터(Application Emulator)라고도 알려져 있는데 이러한 명칭에서 알 수 있듯이 샌드박스(Sandbox)는 에뮬레이터(Emulator)와는 달리 가상의 공간을 생성하는 것이 아니라 실제 컴퓨터 시스템상에서 바로 실행 파일(Executable File)을 실행하고는 정보를 수집한다는 점에서 가장 큰 차이점을 가지고 있다.


[그림 6] CWSandbox의 기본 구조

일반적인 어플리케이션 에뮬레이터(Application Emulator)로 널리 알려져 있는 CWSandbox는 [그림 6]과 같은 기본적인 구조로 되어 있다. CWSandbox의 경우 실행 파일(Executable File)이 실행되면 해당 파일의 스레드(Thread)로 모니터링 모듈인 CWMonitor.dll 파일을 인젝션(Injection) 시킨다. 인젝션(Injection) 이 후 해당 실행 파일(Executable File)이 실행되는 되는 모든 절차를 추적하여 해당 정보를 모두 CWSnadbox로 전달하게 된다.


[그림 7] CWSnadbox에서 윈도우 API 호출의 후킹(Hooking)

그리고 실행 파일(Executable File)이 실행되는 과정에서 발생하는 윈도우 API(Windows API) 호출 모두를 API 후킹(API Hooking) 기법을 이용하여 가로챈 후 CWSandbox로 전달 된 다. 전달 된 윈도우 API(Windows API) 호출은 CWSandbox를 통해 윈도우 커널 레벨(Windows Kernel Level)로 전달하는 정상적인 절차를 수행하게 되고 호출되는 윈도우 API(Windows API) 역시 호출한 해당 실행 파일(Executable File)로 바로 전달하는 것이 아니라 CWSandbox를 거쳐서 전달하게 되는 것이다. 이러한 과정을 표현한 것이 바로 [그림 7]과 같다.

그런데 여기에서 바로 어플리케이션 에뮬레이터(Application Emulator)인 샌드박스(Sandbox)의 가장 큰 특징이 나타난다. 호출 되는 윈도우 API(Windows API)가 CWSandbox를 통해 실행 파일(Executable File)로 전달 된 후 다시 그 리턴 값이 윈도우 운영체제로 바로 전달 되는 것이 아니라 CWSandbox를 통해 전혀 다른 리턴 값을 윈도우 운영체제로 전달하게 된다는 것이다. 이러한 다른 리턴 값을 전달하게 됨으로 실행 파일(Executable File)이 악성 코드여서 감염으로 인해 발생하는 악의적인 기능들이 모두 CWSandbox에 의해 걸러지게 됨으로 실질적인 컴퓨터 시스템에는 감염으로 인한 피해가 발생하지 않게 된다. 그리고 수집된 윈도우 API(Windows API) 호출과 리턴된 값과 같은 정보들을 통하여 CWSandbox는 해당 실행 파일(Executable File)이 알려지지 않은 악성 코드인지 판단을 하게 된다.
그러나 에뮬레이터(Emulator)와 같이 가상의 공간이 아닌 실제 컴퓨터 시스템의 환경에서 실행 파일(Executable File)을 실행하는 샌드박스(Sandbox) 역시 윈도우 응용 프로그램이다. 그러므로 샌드박스(Sandbox)가 특정 악성 코드를 정상적으로 제어하지 못하게 될 경우에는 그 감염으로 인한 피해가 고스란히 실제 시스템으로 전달되게 됨으로 예측하지 못하는 문제가 발생할 가능성이 크다.

이제까지는 실행 파일(Executable File)의 실행을 통해서 알려지지 않은 악성 코드를 탐지 할 수 있는 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아 보았다. 하지만 다음 장에서는 일반적인 윈도우 실행 파일 포맷이 아닌 전자 메일로 형태는 급속한 확산을 시도하는 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)을 탐지 할 수 있는 기법에 대해서 알아 보도록 하자.[Ahn] 

'scrap' 카테고리의 다른 글

[안철수연구소 칼럼] 바이러스 및 악성코드와 백신의 미래  (0) 2010.03.19
[안랩] 파일 기반의 탐지기법  (0) 2010.03.19
Exploit Site  (0) 2010.03.19
DDOS 개요 및 기법 요약  (0) 2010.03.19
ICMP Flooding  (0) 2010.03.19

1. packetstorm.linuxsecurity.com
2. synnergy.net
3. unsecure.altervista.org
4. www.blacksheepnetworks.com
5. www.circlemud.org
6. www.dsinet.org
7. www.metasploit.com
8. www.nostarch.com
9. www.packetstormsecurity.org
10. www.rosiello.org
11. www.safemode.org
12. www.security-corporation.com
13. www.thc.org

'scrap' 카테고리의 다른 글

[안랩] 파일 기반의 탐지기법  (0) 2010.03.19
[안랩] 에뮬레이터와 샌드 박스  (0) 2010.03.19
DDOS 개요 및 기법 요약  (0) 2010.03.19
ICMP Flooding  (0) 2010.03.19
SYN Flooding  (0) 2010.03.19

D-DOS란 "Distribute Denial of Service attack"의 약자로 우리말로는'서비스 분산 거부 공격' 이라고한다.
단적으로 특정 기법을 통해 대량의 네트워크 접속을 유발해 해당 네트워크, 서버등의 시스템을 마비시키는 악의적인 네트워크에 대한 공격이다.
결과적으로 네트워크 마비 등으로 인해 정상 이용 고객들의 접속 자체도 이루어지지 않는 상태가 되는것으로
다음의 기법들이 대표적으로 많이 사용되고 있다.

1. SYN Flood
특정 TCP 포트로  허용치 보다 초과된 수의 연결 요청(SYN) 전송
대부분 Source IP가 Spoofing 되어 있음

2. UDP Flood
허용치 보다 초과된 수의 UDP 패킷

3. ICMP Flood
허용치 보다 초과된 수의 ICMP 패킷

4. Fragment Flood
허용치 보다 초과된 수의 fragmented IP  패킷

5. Connection Flood
Connection 수가 정상의 경우보다 매우 높은 경우

6. Source Flood
단일 Source 가 허용치보다 많은 수의 IP 패킷을 전송하는 경우

7. Zombie 공격 
너무 많은 합법 IP Source로부터 합법적인 TCP 패킷을 전송하는 경우

8. Slammer 공격 
허용치 보다 초과된 수의 패킷이 UDP 포트 1434로 전송

9. DNS 공격 
허용치 보다 초과된 수의 패킷이 UDP 포트 53으로 전송

10. My Doom 공격 
Zombie로부터 허용치보다 높은 수의 HTTP 패킷 전송

11. Smurf 공격
대상 서버의 소스 주소를 위조하여 다수의 Echo(Ping) 메시지를 IP Broadcast트 주소로 전송. 
해당 Broadcast주소로 트래픽을 전달하는 라우팅 장치가 Layer 2 Broadcast 기능에 대해 IP Broadcast를 
수행하기 때문에 대부분의 네트워크 호스트는 각각 ICMP Echo 요청을 받아들여 Echo 응답을 수행하게 되므로 응답 중인 호스트 수에 비례하여 트래픽이 증가

12. Fraggle 공격  
Fraggle은 UDP (7)Echo  메시지를 사용한다는 점을 제외하곤 smurf와 유사함. 
멀티액세스 Broadcast 네트워크에서는 수백 대의 시스템이 각 패킷에 응답할 수 있음.
Echo(7) 및 Chargen(UDP 19)를 이용하여 Loop 형성 가능 

특히 최근에는 악성코드 혹은 바이러스를 통한 Bot 감염에 의한 좀비PC들(BotNet)이 D-dos 공격에 많이 이용되는 7번 이후의 공격이 증가하고 있으며 IDC내로 최근에 유입되는 트래픽이 수G를 넘는 경우도 흔하다.

현재 국내외의 많은 네트워크 장비업체, 솔루션 업체에서 D-Dos 방어 장비, 솔루션이 출시되고 있으나 워낙 다양한 공격에 대처하기에는 기반 기술자체의 한계로 인해 효용성이 떨어지고 있다.

기존의 대부분 IDS, IPS,  백신등의 기본 아키텍처가 Signature 를 기반으로 패킷 비교를 통한 차단방식을 사용하고 있으나 근본적으로  D-Dos 공격 자체가 TCP, UDP 프로토콜 자체의 취약성 혹은 매커니즘을 이용한 대량 패킷을 전송해서 시스템 혹은 네트워크에 과부하를 일으키는 방식을 사용함에 따라 Signature가 없거나 수집이 되었다 해도 해당 패턴이 장비에 업데이트가 되는데 수시간 혹은 수십일이 소요되는 현실을 감안할때 일명 "Zero Day 공격"에는 근본적으로 대처할 수가 없는것이 현실이다.

단, 현재 해외에서 각광받는 RBIPS(Rate-Based Intrusion Prevention System) 장비가 큰 효과를 얻고 있다고 하는데 해당 장비에 대해서 조만간 소개해 보겠다.

'scrap' 카테고리의 다른 글

[안랩] 에뮬레이터와 샌드 박스  (0) 2010.03.19
Exploit Site  (0) 2010.03.19
ICMP Flooding  (0) 2010.03.19
SYN Flooding  (0) 2010.03.19
UDP Flooding  (0) 2010.03.19

+ Recent posts