* about Network..

을 받는 것을 의미한다.

이러한 일련의 요청과 응답이 이루어진 후 해당 서버와의 통신은 다시 종료된다. 위와 같은 기본적인 지식을 알고 있다면 다음과 같은 질문을 할 수 있다. HTTP는 비연결유지 프로토콜이라고 하였는데 Session Hijacking 이란 공격은 어떻게 가능한 것인가? 이는 HTTP 세션 관리를 위해 사용되는 Session ID를 통해서 가능하다.


Session ID란 무엇인가?

웹 서버는 다수의 웹 페이지 요청자를 구별하기 위하여 각각의 사용자의 세션에 대해서 임의의 긴 문자열 값인 Session ID를 부여한다. 사용자가 홈페이지 방문시 혹은 인증 로그인시에 생성된다. 이러한 Session ID는 사용자의 계정, 암호, 그 밖의 IP 주소, timestamp 등의 여러 파라미터들을 조합하여 생성할 수 있다.

쿠키

웹 브라우저 주소창의 URL

웹 페이지 폼 소스 상의 hidden field

Trojan Horse

호감이 가는 유용한 프로그램으로 가장하고, 실제적으로는 악의적인 프로그램이나 코드를 포함하고 있는 프로그램을 말한다. 이는 정상적인 동작을 하는 것으로 보이거나 사용자가 쓰는 프로그램등으로 사용자를 현혹시킴으로써 특권을 획득한다.

2. 백도어와 트로이 목마의 차이점

트로이 목마의 경우, 특정 사용자 또는 프로그램이 실행에 의한 수동적인 방법에 의존한 것이며, 이는 사용자의 직간접적인 도움을 통해서 설치되거나 Bind되어진 프로그램이 실행되어 설치된다. 백도어의 경우 예전에는 관리의 목적으로 사용하기도 하였으나, 대부분 크래커들에 의해 권한이 획득된 후, 해당시스템에 추후 접속을 용이하게 하기 위하여 서비스 데몬 등을 수정하여 사용하고 있다.

3. 백도어의 유형

- 네트워크 데몬이나 시스템 유틸리티를 수정한 백도어
- TCP/UDP프로토콜을 이용한 Shell binding 백도어
- Kernel 모듈을 수정한 백도어
- 방화벽을 우회하는 백도어

4. 트로이 목마의 유형

- 인터넷의 자료실이나 warez 사이트 등을 통한 정상적이고 유용한 프로그램, 불법적인 크랙파일 이나 누드 사진 등의 사용자의 관심을 끄는 프로그램에 바인드되어 네트워크를 통한 원격제어
- Hidden Setuid shell
- UDP Bind Shell

5. 트로이 목마의 위험성

최근 들어서도 웜바이러스, 트로이목마형 바이러스등이 많은 부분을 차지 하고 있음을 아래 그림에서 알 수 있다.

[그림1] 2003년 침해사고 통계(참조 : CERTCC)

[그림2] 2003년 침해사고 공격 수법별 통계(참조 : CERTCC)

내용출처 : [기타] (주)코코넛 시큐레터 12월호
(출처 : '[해킹기법과 대응] ⑥ 백도어와 트로이목마 (1)' - 네이버 지식iN)

스니핑이란?

사전적인 의미로 스니핑(Sniffing)이란 ‘코를 킁킁거리다’, ‘냄새를 맡다’ 등의 뜻이 있다. 사전적인 의미와 같이 해킹 기법으로서 스니핑은 네트워크 상에서 자신이 아닌 다른 상대방들의 패킷 교환을 엿듣는 것을 의미한다. 간단히 말하여 네트워크 트래픽을 도청(eavesdropping)하는 과정을 스니핑이라고 할 수 있다. 이런 스니핑을 할 수 있도록 하는 도구를 스니퍼(Sniffer)라고 하며 스니퍼를 설치하는 과정은 전화기 도청 장치를 설치하는 과정에 비유될 수 있다.

TCP/IP 프로토콜은 학술적인 용도로 인터넷이 시작되기 이전부터 설계된 프로토콜이기 때문에 보안은 크게 고려하지 않고 시작되었다. 대표적으로 패킷에 대한 암호화, 인증 등을 고려하지 않았기 때문에 데이터 통신의 보안의 기본 요소 중 기밀성, 무결성 등을 보장할 수 없었다. 특히 스니핑은 보안의 기본 요소 중 기밀성을 해치는 공격 방법이다.

인터넷은 말 그대로 광범위한 네트워크이며 공개된 네트워크이다. 패킷이 송수신될 때, 패킷은 여러 개의 라우터를 거쳐서 지나가게 되며 중간 ISP 라우터에 접근 권한을 가지는 사람이라면 해당 패킷을 쉽게 잡아낼 수 있다. 그런데 문제는 이렇게 쉽게 얻어낼 수 있는 많은 패킷의 내용은 암호화 되지 않는다는 것이다.

물론 xDSL, 케이블 모뎀 등을 사용하는 일반 가정 사용자가 이러한 패킷을 아주 쉽게 볼 수 있는 것만은 아니다. 그러기 위해서는 패킷이 흘러가는 네트워크의 중간 경로를 얻어내야 한다. 전화에 도청기를 설치하는 과정을 연상하면 이해하기 쉬울 것이다. 직접 도청하고자 하는 전화기에 도청기를 설치하는 방법, 그리고 중계 회선에 도청기를 설치하는 방법이 있을 것이다.

두 가지의 차이는 직접 도청하고자 하는 전화기에 설치한다면 그 전화기의 내용만 도청할 수 있다는 것, 중계 회선에 설치한다면 그 중계 회선을 통해 연결된 모든 전화기의 내용을 도청할 수 있다는 것이 될텐데 스니핑 역시 마찬가지이다.

대표적인 시나리오는 다음과 같다.

(1) 다양한 공격 기법을 통해 실제 공격 대상 시스템에 관리자 권한을 얻어낸 후 스니핑 도구를 설치하여 스니핑
(2) 공격 대상 기업의 다른 호스트에 대한 접근 권한을 얻어내서 그 호스트를 이용하여 스니핑
(3) ISP 장비에 대한 시스템 권한을 얻어내어 스니핑 도구를 설치하여 스니핑

다음은 이러한 스니핑 기법을 통하여 FTP 접속을 스니핑함으로 사용자 ID와 패스워드를 얻어낸 화면이다. 이 경우, Ethereal이라는 툴을 이용한 것으로 쉽게 해당 서버에 hackme라는 peace! 패스워드를 사용하는 사용자가 존재한다는 사실을 알았다.

물론 스니핑은 이와 같은 공격만을 위해 사용되는 것은 아니다. 네트워크 트래픽 분석이나 트러블슈팅 등에 사용되며 그 외에도 네트워크 상에 이루어지는 공격을 탐지하는 침입탐지시스템에 쓰일 수 있다. 이 문서에서는 공격 기법으로서의 스니핑을 이야기하고자 한다.

실질적인 스니핑 공격의 예

(1) 허브 환경에서의 스니핑

허브(Hub)는 기본적으로 들어온 패킷에 대해 패킷이 들어온 포트를 제외한 모든 포트에 대해 패킷을 보내는 리피터(Repeater) 장비이다. 사실 여러분의 기업에서 허브를 사용하고 있고 여러분의 시스템이 그 허브에 연결되어 있다면 여러분은 원하던 원치 않던 간에 계속하여 다른 사람의 패킷들을 받아보고 있었던 것이다.

물론 네트워크 드라이버, OS 커널 등의 수준에서 MAC 주소를 보아 자신이 아닌 다른 이들의 패킷은 버려지기 때문에 그것을 쉽게 느낄 수는 없었을 것이다. 하지만 여러분 시스템의 NIC를 promiscuous 모드로 동작하게 한다면 다른 이들의 패킷 또한 버리지 않고 받아볼 수 있다. 이제 스니핑 도구를 통해 해당 패킷을 저장하고 분석하기만 하면 된다.

다음 그림은 이 내용을 설명한 것이다. 모든 패킷은 실제 수신 대상이 아닌 호스트에게도 전달되며 Promiscuous 모드로 동작하는 호스트는 다른 수신 대상의 패킷 또한 볼 수 있다.

[그림 1] 허브 환경에서의 패킷 송신

[그림 2] 스위칭 환경에서의 패킷 송신

지난 원고에 이어서 스위치를 사용하는 스위칭 환경에서의 스니핑 기법 중 몇가지 공격 기법에 대해 소개를 하도록 하겠다.

1) Switch Jamming

스위치는 원래 앞서 말한 바와 같이 실제 수신 대상으로만 패킷을 보내는 브리지 장비이다. 그러나 엉뚱한 MAC 주소를 가진 패킷을 계속하여 보냄으로써 스위치가 허브처럼 동작하도록 만들 수 있다. 많은 종류의 스위치가 주소 테이블이 가득 차게 되었을 때 패킷을 모든 포트로 브로드캐스팅하는 성질을 이용한 것이다.

2) ARP Redirect

대표적인 툴로 Dsniff와 같은 툴이 이 방법에 의한 스니핑을 제공한다. 네트워크 상에서 패킷이 보내질 때 목적지의 IP 주소를 갖고 해당 목적지가 어떤 MAC 주소를 사용하는지를 요청하는데 이를 ARP request라고 한다. 쉽게 말해서 교실에 선생님이 들어와서 '이 반에 코코넛이라는 학생이 누구인지 손들어 봐요' 하는 것과 같다.

ARP request는 네트워크 상에 브로드캐스팅되어 모든 호스트가 그 패킷을 받게 되고 해당 IP를 가진 호스트는 그런 IP를 사용하는 것은 나라고 ARP reply를 주게 된다. 코코넛 학생이 '저요!'하고 손드는 것과 마찬가지이다. 하지만 코코넛 학생 대신 오렌지라는 학생이 '저요!' 하고 손든다 해도… 그렇다. 순진한 선생님은 그대로 믿게 되는 것이다.

[그림 1] ARP request 과정

[그림 2] ARP reply 과정

[그림 3] 조작된 ARP reply 과정

위와 같은 경우 두 개의 Reply를 받게 된다. 이 경우, 패킷이 도달한 순서에 따라 그리고 구현에 따라 10.1.1.1의 응답 혹은 10.1.1.3의 응답을 믿게 될 것이다. 만약 10.1.1.3의 응답을 믿었다면 패킷은 10.1.1.1로 보내지는 것이 아니라 10.1.1.3으로 보내지게 될 것이다.

그런데 문제는 ARP Request가 오기 전에 ARP reply가 위와 같은 식으로 보내지게 되었을 때 공격 대상이 되는 시스템의 ARP cache에 그런 내용이 저장이 되고 ARP cache에 10.1.1.1에 대한 정보가 있다면 굳이 ARP request를 하지는 않는다는 것이다. 이 점을 이용하여 공격자는 위와 같은 거짓 응답을 주기적으로 계속하여 보내게 된다. 물론 ARP request가 있기 전부터...

10.1.1.1로 가게 될 패킷은 10.1.1.3으로 가게 된다. 물론 10.1.1.1 입장에서는 통신이 제대로 되지 않게 되므로 이런 시도를 금방 알아차릴 수 있을 것 같지만 10.1.1.3은 해당 패킷의 내용을 받고 저장한 후 바로 아무 일 없었다는 듯이 10.1.1.1로 포워딩하므로 통신에는 문제 없다.

공격 대상 시스템이 라우터였다면 치명적이다. LAN 상의 시스템이 인터넷으로 주고 받는 모든 패킷을 훔쳐 볼 수 있다는 것이다.이 방법에서 공격자는 10.1.1.1에 대한 ARP Reply를 속였기 때문에 이를 ARP Spoofing이라고 하기도 한다.

3) ICMP Redirect

Ping 프로그램을 사용할 때 ICMP Echo 메시지와 ICMP Echo Reply 메시지가 사용된다는 것은 많은 분이 알고 계실 것이다. 이처럼 ICMP 프로토콜은 네트워크 상의 오류 메시지 전송, 트러블슈팅 등을 위해 사용되는데 그 중 ICMP Redirect 메시지를 이용한 스니핑 방법이며 일단 기본적으로는 ARP Redirect의 경우와 마찬가지로 공격 대상 시스템으로 패킷이 오도록 만드는 것이다.

네트워크 상에 라우터가 여러 대 존재할 때 비효율적인 라우팅 경로가 존재한다면(즉 1 hop 만으로 보낼 수 있는데 3 hop으로 보내게 설정되었다든지) 라우터에 대해 이를 수정할 것을 권고하는 ICMP Redirect 메시지가 보내진다. 공격자는 이를 악용한 ICMP Redirect 메시지를 보냄으로써 패킷이 자신으로 보내지도록 한다.

4) ICMP Router Advertisement

ICMP Redirect와 비슷한 방법이나 ICMP Router Advertisement 메시지는 특정 호스트가 자신이 라우터라고 다른 호스트들에 대해 알리는 메시지이다. 공격자는 이를 악용하여 다른 호스트들이 자신을 라우터로 생각하게 하여 패킷이 자신으로 보내지도록 한다.

5) MAC 스푸핑

앞서 스위치는 기본적으로 MAC 주소를 통해 패킷이 어떤 목적지로 보내질지를 결정한다고 하였는데 이런 MAC 주소를 학습하는 방법은 다음과 같다. 특정 목적지 MAC 주소를 갖는 패킷을 보내고자 할 때,

  ① 해당 MAC 주소가 자신의 MAC 주소 테이블에 존재하는지 확인
  ② 존재한다면 테이블에 등록된 포트로 패킷을 보냄
  ③ 존재하지 않는다면 패킷이 유입된 VLAN과 동일한 모든 VLAN으로 패킷을 일단은 보냄

그리고 MAC 주소 테이블을 갱신하는 방법은 패킷이 유입되었을 때, 해당 패킷의 출발지 MAC 주소를 참고하여 해당 패킷이 들어오게 된 포트와 MAC 주소 정보를 테이블에 등록하는 방법으로 한다.

따라서 위와 같은 경우 응답으로 패킷이 오게 되면 MAC 주소 테이블에 해당 정보가 입력되어 다음부터는 응답이 오게 된 포트로 보내게 된다. 그러나 공격자가 공격 대상 시스템의 MAC 주소를 가지는 패킷을 출발지 MAC 주소로 하는 패킷을 계속하여 보내면 스위치의 MAC 주소 테이블에는 그러한 내용이 등록된다. 따라서 스위치는 패킷을 공격자에게 보내게 된다.

6) 스위치에서의 SPAN/Monitor port 설정

대다수의 스위치는 port monitoring 기능을 가지고 있는데, 이는 특정 포트(들)로 주고 받아지는 패킷을 또 다른 모니터 포트로 전송해주는 옵션이다. 공격자가 스위치에 접근 권한을 얻어내어 위와 같은 설정을 적용함으로 공격자 시스템에 연결된 포트로 보낼 수 있다.

이는 매우 어려운 일이 될 것 같지만 디폴트로 설정된 스위치의 경우에는 매우 쉬운 일이다. 왜냐하면 해당 스위치의 사용자 ID, 패스워드는 인터넷 검색 사이트를 통해 쉽게 얻어낼 수 있기 때문이다.

편에서는 스니핑 공격 도구들과 스니핑 방어에 대해 알아보도록 하겠다.

스니핑 도구들

으로 직접 연결함으로 중간에 도청되는 것을 막는 것이 사설망이다. 하지만 이는 거리가 멀어질수록 인터넷을 이용하는 것에 비해 비용이 매우 비싸질 수 밖에 없다. 인터넷 회선을 이용하며 사설망의 효과를 줄 수 있는 것이 VPN입니다. VPN 장비 간의 암호화를 통해 도청을 막을 수 있다.


결론

스니핑은 다양한 형태로 네트워크 상에서 이루어질 수 있으며 다음과 같은 두 가지 단계로 볼 수 있다.

- 패킷 가로채기
- 가로챈 패킷 디코딩을 통해 주요 정보 획득

패킷을 가로채는 시도는 차단하기 매우 어려우며 디코딩을 통해 주요 정보를 얻어내는 것을 막기 위해 SSL, SSH, VPN, PGP 등 다양한 기법이 이용될 수 있다.

내용출처 : [기타] (주)코코넷 시큐레터 10,11,12월호
(출처 : '[해킹기법과 대응] ⑤ 스니핑 (sniffing)' - 네이버 지식iN)

등의 다른 여러가지 공격을 수행 가능하게 한다.

이번 회에서는 스프핑 공격의 종류를 알아보고, 해당 공격이 어떤 것인지 간략하게 알아보도록 하겠다. 스프핑 공격의 종류를 알아보면 다음과 같다. 어떤 정보를 속이느냐에 따라 세분화될 수 있다.

① IP 스프핑

IP 스프핑은 말 그대로 IP 정보를 속여서 다른 시스템을 공격하는 것이다. IP 스프핑을 통해 서비스 거부 공격(TCP Syn flooding, UDP flooding, ICMP flooding)을 수행할 수도 있으며, 공격대상 컴퓨터와 서버 사이의 연결된 세션에 대해서 세션 끊기도 가능하다. TCP/IP 상의 프로토콜 취약성은 1985년 Robert T. Morris의 논문 “A Weakness in the 4.2 BSD Unix TCP/IP Software”에 업급이 되었으며, 특히 희대의 해커 케빈미트닉은 실제 해킹에서 IP 스프핑 공격을 통해 모토롤러, 선마이크로시스템즈, NEC, 노벨 등의 컴퓨터 전산망에 침투, 소프트웨어 및 각종 자료 등을 훔친 혐의로 1995년 체포되었다.

케빈 미트닉은 정확하게는 TCP Syn flooding + TCP 순서 번호 예측(TCP Sequence Nubmer Guessing)

+ IP 스프핑을 사용하였다. 이는 클라이언트와 서버와의 통신 사이에 해커 컴퓨터가 끼어들어 클라이언트를 TCP Syn flooding 서비스 거부 공격으로 전혀 반응하지 못하게 한 후, 해커가 이 클라이언트인 것으로 가장하여 서버와 통신하는 기법이다. 이러한 공격은 TCP/IP 프로토콜의 문제점인 TCP 순서 번호 생성이 매초당 일정하게 증가한다는 것과 호스트에 대한 인증시 IP의 소스 주소만을 사용한다는 것으로 인하여 가능하였다.

순서 번호는 연결 지향형 프로토콜인 TCP 프로토콜에서 두 호스트 간의 패킷 전달이 손실 없이 이루어졌는지 체크하기 위한 일종의 패킷 번호표이다. 해커는 일단 클라이언트를 TCP Syn flooding 공격으로 봉쇄한다. 이후 서버의 순서번호를 예측하여 IP 스프핑된 위조 패킷을 발송함으로써 서버를 속여 침투하는 것이다. IP 기반의 인증만을 제공하는 Unix의 rlogin, rsh 등의 r 계열 서비스들은 이러한 IP 스프핑 공격에 취약할 수 밖에 없다.

② APR 스프핑

ARP 프로토콜은 32bit IP 주소를 48bit의 네트워크 카드 주소(Mac Address)로 대응시켜 주는 프로토콜이다. 우리가 실제로 IP 주소를 통해 네트워크 연결을 시도하면 TCP/IP에서는 해당 IP에 해당하는 네트워크 카드 주소를 찾아 연결하게 된다. 이러한 IP 주소와 네트워크 카드 주소의 대응 테이블은 스위치나 기타 네트워크 장비 및 사용자 컴퓨터에서 arp cache 테이블이라는 곳에 위치하게 된다.

해커가 이 테이블 상의 정보를 위조하게 되면 공격 대상 컴퓨터와 서버 사이의 트래픽을 해커 자신의 컴퓨터로 우회시킬 수 있다. 우회된 트래픽으로부터 해커는 패스워드 정보 등 유용한 정보를 마음껏 획득할 수 있다.

③ 이메일 스프핑

이메일 발송시 송신자의 주소를 위조하는 것이다. 간단한 방법으로는 이메일 송신자 From 필드에 별칭(alias) 필드를 사용할 수 있다. 이메일 발송시 별칭을 설정한 경우에는 별칭 주소로 이메일이 발송된다. 이러한 경우 메일을 받아보는 사람은 실제 이메일 송신자가 아닌 별칭 필드만을 확인하는 경우에는 이메일의 송신자가 별칭 필드에서 온 것으로 알게 된다.

요즘 들어서 극성인 대량의 스팸 메일과 바이러스 감염 메일은 송신자의 주소가 아예 존재하지 않는 이메일 주소를 사용한다. 또한 이메일을 발송한 메일 서버 또한 직접적인 메일 발송 서버가 아닌 중계 서버이므로 메일을 발송한 자를 추적하기란 쉽지 않다.

④ DNS 스프핑

DNS 프로토콜은 인터넷 연결시 도메인 주소를 실제 IP 주소로 대응시켜 주는 프로토콜이다. 인터넷 연결시 사용하는 DNS 서버가 IP 주소를 찾아달라는 요청을 받았을 때, 자기 자신의 도메인이 아닌 주소에 대해서는 보다 상위 단의 DNS 서버로부터 재귀적(recursive)

인 방식으로 IP 주소를 찾아 알려준다.

만약 해커가 어떤 도메인의 DNS 컴퓨터를 장악하여 통제하고 있다면 최종적으로 얻어진 IP 주소는 원래 사용자가 찾아가고자 하였던 홈페이지가 아닌 다른 홈페이지로 연결되게 된다. 이는 요청을 발송했던 DNS와 응답을 주는 DNS 사이의 트래픽을 해커가 스니퍼링함으로써 Query ID라는 값을 통해 해커의 사이트 IP를 최종 응답으로 넘겨주도록 하는 것이다.

사용자가 쇼핑몰을 이용하고자 하였다면 해커에 의해 조작된 홈페이지 내에서 자신의 아이디와 필드, 신용 카드 정보를 기입함으로써 개인 정보를 탈취당할 수 있다. 위와 같은 스프핑 공격들은 실제로 인터넷 상의 툴로써 공개가 되어 있으며 여러가지 다른 복합적인 공격과 같이 사용될 수 있다.

그러나 각각의 공격 방법에 있어서 제약 및 전제 사항이 있으므로 모두 완벽하게 성공되지는 않는다. 스프핑 공격은 패킷 필터링 접근 제어와 IP 인증 기반 접근제어, 취약점 서비스 사용의 제거, 암호화 프로토콜의 사용을 통해서 방어가 가능하다. 인터넷 상에 떠돌아다니는 정보는 항상 안전한 것이 아니므로 스프핑 공격과 같은 것을 통해 언제라도 위조되었을 가능성도 있을 수 있음을 간과해서는 안되겠다.

에 의해 비교적 쉽게 해결이 가능했다.

최근 해킹의 화두는 웹 애플리케이션의 취약성을 이용하는 것이다. 그러한 이유를 위에서 언급된 내용을 토대로 말하자면 요즘 대부분의 기업이나 기관들은 시스템의 패치나 구성설정 변경을 제대로 하고 있지 못하더라도 접근 통제 솔루션을 하나 이상은 갖추고 있어서 외부로부터 유입되는 부적절한 접근으로부터 내부의 시스템을 보호할 수 있는 장치를 마련하고 있다. 그러나 이러한 솔루션이 갖추어져 있더라도 필수 불가결하게 서비스해야 하는 것이 바로 웹 서비스이다. 접근 통제 솔루션은 웹 서비스로 접근하는 패킷을 통제하지 않고 내부로 유입시키기 때문에 만약 통과되는 패킷에 악의적으로 패킷을 조작해서 보낸다면 정상 패킷으로 간주하여 적절한 통제를 하지 못하게 된다.

웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration)

1. 검증되지 않은 파라미터의 허용(Unvalidated Parameters)

클라이언트로부터 웹 애플리케이션이 요청을 받았을 때 그 요청이 적절한 값인지 여부를 검증하지 않음으로 인해 백엔드에 존재하는 허가되지 않은 자원에 접근할 수 있는 취약성이다. url, 쿼리 문, HTTP 헤더, 폼 필드, 쿠키, 그리고 숨겨진 필드 등의 웹 요청(HTTP request) 들을 강제로 브라우징 한다거나 명령어 삽입, SQL 문 삽입, 쿠키 위/변조등을 통해서 보안 메커니즘을 우회할 수 있게 된다.

[예방 방법]

웹 요청에 대한 잘못된 예외 규칙을 다음과 같이 정하여 소스 코드에서 철저하게 검증을 하는 것이다.

- 데이터 형식(문자, 정수, 실수 등)
- 허용되는 문자셋
- 최소, 최대 허용 길이
- NULL 값의 허용 여부
- 파라미터의 허용 여부
- 허용되는 숫자 범위
- 정규 표현식 등


2. 부적절한 접근 통제(Broken Access Control)

인증되지 않은 사용자가 시스템에 접근하여 중요한 파일 읽거나 권한 없는 기능들을 수행할 수 있는 취약성이다. 예를 들자면 허가되지 않은 사용자가 웹 요청을 통해서 유닉스 시스템의 /etc/passwd 파일을 읽거나 윈도우 시스템의 웹 루트 디렉터리를 읽을 수 있는 등의 경로 유출(Path Traversal)을 허용하는 것이다. 이러한 취약성은 웹 컨텐츠와 기능에 적절한 접근 통제를 하지 못하는 것이 원인이다.

[예방 방법]

다음과 같은 접근 통제를 점검한다.

- 안전하지 않은 ID 점검
- 절대 경로를 통한 인증 회피 가능 점검
- Path Traversal 가능 점검
- 웹 컨텐츠의 퍼미션 점검
- 클라이언트 측의 케싱 점검


3. 부적절한 계정과 세션 관리(Broken Account and Session Management)

계정에 대한 증명(Account Credential)

과 세션 토큰이 적절히 보호되지 못함으로 인해 패스워드나 키, 세션 쿠키, 그리고 다른 토큰 등을 악용하여 인증 메커니즘을 무력화 시키거나 다른 사용자의 아이디를 추측할 수 있는 취약성이다. 예를 들자면 사용자의 패스워드 변경, 패스워드 분실, 사용자 정보 수정 등을 포함하는 증명서와 동적 세션 관리가 적절히 개발되지 않아서 다른 사용자에 의해 추측되거나 가로채기를 당하는 것이다.

[예방방법]

다음과 같은 항목들에 대해 보안 정책을 강화한다.

- 패스워드 변경 통제
- 패스워드 복잡성
- 패스워드 저장
- 전송 중인 증명서 보호
- 세션 아이디 보호
- 계정 목록
- 신뢰 관계
- 백엔드 인증

4. 크로스 사이트 스크립팅 허점(Cross-Site Scripting(XSS) Flaws)

Cross-site Scripting 취약점은 공격자가 웹 애플리케이션을 사용해서 다른 최종 사용자에게 자바스크립트와 같은 악성 데이터를 보낼 때 발생한다. 그 데이터는 클라이언트에서 실행되는 Java스크립트, VB스크립트, ActiveX, Flash등을 실행하는 코드들이 존재하게 된다. 최종 사용자들은 이렇게 악성 코드들이 포함된 웹 사이트의 링크를 클릭하거나 이메일에 포함된 내용을 읽거나 BBS에 게시된 게시물을 클릭하는 것만으로도 사용자의 환경 설정사항을 변경하거나, 쿠키(cookie)를 가로채고 잘못된 광고들 게시하는 등의 일들을 할 수 있다.

[예방 방법]

해당 취약점을 예방할 수 있는 최선의 방안은 모든 코드들을 상세히 검증하는 것이다. 즉, 헤더, 쿠키, 질의문, 폼 필드와 숨겨진 필드등과 같은 모든 파라미터들을 엄격한 규칙에 의해서 검증한다. 또한 다음과 같이 왼쪽의 필드의 입력 데이터를 오른쪽의 필드로 변환해서 필터링한다.

From	To
<	& l t;
>	& g t;
(	& # 4 0;
)	& # 4 1;
#	& # 3 5;
&	& # 3 8;

5. 버퍼 오버플로우(Buffer Overflows)

버퍼오버플로우의 자세한 내용은 코코넛 시큐레터 6월호의 "해킹기법 제2회 버퍼오버플로우"를 참조하기 바란다.

[예방 방법]

운영하고 있는 웹 서버 버전을 가장 최신버전으로 업그레이드 하거나 알려진 취약점을 제거할 수 있는 패치를 적용한다. 정기적으로 취약점 스케너를 통해서 취약점 여부를 점검하여 발견된 취약점에 대해서는 구성 설정을 변경하거나 패치를 적용하여 취약점을 제거한다.

6. 시스템 명령어 삽입 허용(Command Injection Flaws)

웹 애플리케이션에서 HTML 형식이나 쿠키, URL 파라미터 형식으로 시스템 명령어를 삽입 허용함으로써 웹 상에서도 시스템 명령을 실행할 수 있는 취약점이다. SQL 쿼리문을 삽입 허용하게 되면 DB인증 메커니즘을 무력화시켜서 중요한 데이터베이스 정보를 외부로 유출할 수 있다. 또한 데이터베이스의 DML(Data Manipulation Language), DDL(Data Definition Language) 언어가 모두 사용 가능하므로 데이터베이스의 유출뿐만이 아니라 무결성을 파괴할 수도 있다.

다음은 시스템 명령 삽입 허용 취약점을 악용할 수 있는 스크립트, 프로그래밍 언어의 함수들이다.

PHP
- require()
- include()
- eval()
- preg_replace() (/e 옵션과 함께 사용)
- exec()
- passthru()
- `` (backticks)
- system()
- popen()

Shell Scripts
- 모두 실행 가능

Perl
- open()
- sysopen()
- glob()
- system()
- '' (backticks)
- eval()

Java(Servlets, JSP s)
- System.* (특별히 System.Runtime)

C,C++
- system()
- exec**()
(strcpy strcat sprintf vsprintf gets strlen (특별히 null 바이트와 함께 사용될 경우) scanf() fscanf sscanf vscanf vsscanf vfscanf realpath getopt getpass streadd strecpy strtrns)

Python
- exec()
- eval()
- execfile()
- compile()
- input()

[예방 방법]

- 반드시 필요하다면 모든 시스템 명령을 사용하는 모든 사용자의 입력값을 점검한다.
- 점검되지 않은 사용자 입력을 시스템 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 파이프(|)로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 perl의 open() 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 C 언어와 PHP의 popen() 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 ``(backticks)

과 함께 사용하지 않는다.
- 운영체제의 시스템 명령이 사용자 입력에 존재하는지 점검한다.
- 모든 웹 애플리케이션엔 쉘 스크립트를 허용하지 않는다.

7. 잘못된 오류 처리(Error Handling Problems)

적절하지 못한 오류 처리는 웹 사이트에서 다양한 보안 문제를 야기한다. 가장 보편적인 문제는 데이터베이스 덤프, 에러 코드등과 같은 상세한 내부 메시지들이 사용자에게 노출된다는 것이다. 이러한 정보들은 바로 악용 가능하지는 않지만 향후 발생할 수 있는 공격에 정보를 제공하게 된다. 이러한 문제를 야기하는 원인은 다음과 같다.

- 스크립팅 엔진의 설정 오류
- Servlet/JSP Runner의 설정 오류
- 웹 서버의 설정 오류
- 데이터베이스의 설정 오류

이러한 문제를 통해 유출될 수 있는 정보들은 다음과 같다.

- 애플리케이션의 흐름
- 추가적인 웹 서버 정보
- 데이터베이스 형식 및 버전
- 운영체제 형식 및 버전
- Scripting/Programming 언어의 형식 및 버전
- 물리적인 경로
- 변수 이름과 값
- 변수 형식
- 변수의 사용 목적
- 스크립트 소스 코드의 세그먼트
- SQL 쿼리의 세그먼트
- 데이터베이스와 테이블의 구조

[예방 방법]

웹 애플리케이션이 잘못된 요청을 받았을 때 자체 제작한 오류 페이지로 이동하도록 설정한다.

8. 안전하지 않은 암호화 메커니즘 사용(Insecure Use of Cryptography)

대부분의 웹 애플리케이션은 패스워드, 신용카드 번호, 계정 기록과 같은 중요한 정보나 데이터베이스를 저정하고 있기 때문에 암호화 기술을 이용하여 보호하고 있다. 이러한 암호화 기술이 웹 애플리케이션에 적용될 때 다음과 같은 구현상의 오류로 인하여 보안 허점들을 내포하게 된다.

- 안전하지 않은 키, 인증서와 패스워드 저장
- 적절하지 못한 메모리상의 기밀 저장
- 잘못된 난수 소스
- 중요 데이터 암호화 실패
- 새로운 암호화 알고리즘 개발 시도
- 암호화 키 변경과 같은 추가적인 지원 부재

[예방 방법]

이러한 취약점을 예방하기 위해서는 암호화 사용을 최소화 해야한다. 즉, 신용카드 번호와 그와 관련된 정보와 같이 중요하다고 판단되는 정보만을 암호화한다. 또한 저장된 암호화된 패스워드를 사용하는 대신 단방향 함수인 SHA-1과 같은 해쉬함수를 사용한다.

9. 원격 관리 허점(Remote Administration Flaws)

웹 애플리케이션을 관리하기 위해 강력한 기능을 갖는 원격 관리 도구들이 많이 존재한다. 그러한 기능들은 사용자들, 데이터, 그리고 웹 사이트의 컨텐츠들을 관리 가능하게 한다. 이러한 강력한 기능 때문에 원격 관리 도구들은 내/외부에서 공격자들의 주요 목표가 된다. 가장 일반적인 문제점은 원격 관리에 접근할 수 있는 강력한 인증 메커니즘이 갖춰져 있지 못한 이유로 인해 허가되지 않는 사용자에 의해서 웹 애플리케이션의 기밀성과 무결성, 그리고 가용성이 파괴될 수 있다.

[예방 방법]

ACL(Access Control List)을 이용하여 원격 관리 도구에 접근할 수 있는 대상을 엄격히 제한한다. 또한 VPN를 사용하여 관리자와 원격 관리 도구간에 암호화 통신을 한다.

아래 그림은 단계별 방어가 적용되기 전(그림 1)과 단계별 방어가 수립된 후(그림 2)

의 네트워크 구성을 나타낸 것이다. 그림 2처럼 단계적으로 방어 대책이 수립된다면 관리자와 일반 사용자의 네트워크가 분리되며 시스템 용도별로 네트워크가 분리되어 단계별로 보안 대책이 수립되기 때문에 안전한 네트워크 운영이 가능하게 된다.

[그림1] 방화벽의 단계별 보안(Layered Security)

이 적용 안 된 상태

[그림2] 방화벽의 단계별 보안(Layered Security)

가 적용 된 상태

[그림 출처] Information Security 2002년 6월호

10. 웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration)

웹 서버와 애플리케이션의 구성 설정은 보안 측면에서 중요한 의미를 가진다. 그러한 구성 설정들이 다음과 같은 여러 가지 요인들로 인해 보안 문제를 야기할 수 있다. 이러한 보안 문제들은 자동화된 스케닝 도구에 의해 공격자들에 의해 공격 당할 가능성이 매우 높다.

- 서버 소프트웨어에 있는 패치되지 않은 보안 취약점들
- 디렉터리 리스팅과 디렉터리 경로 유출을 허용하는 잘못된 서버 구성 설정
- 스크립트, 애플리케이션 환경 설정 파일과 웹 페이지가 포함된 불필요한 기본 파일, 백업 파일, 샘플 파일들
- 부적절한 파일, 디렉터리 권한 설정
- 컨턴츠 관리와 원격 관리가 가능한 불필요한 서비스 활성화
- 기본 패스워드로 설정된 기본 계정
- 관리와 디버깅 목적의 기능들
- 정보가 유출될 수 있는 잘못된 에러 처리
- 잘못 설정된 SSL 인증서와 암호화 설정
- 기본 인증서 사용 등

[예방 방법]

① 여러 보안 관련 사이트(SANS institute, OWASP, CERT)나 자료 등에 언급되어 있는 보안 가이드라인을 참고하여 다음과 같은 조치들을 취한다.
   - 고려할 수 있는 모든 보안 메커니즘들 구성
   - 모든 불필요한 서비스 중지
   - 역할(roles), 퍼미션(permissions), 계정(accounts)

설정
   - 로깅과 경고

② 1번과 같이 보안 가이드라인이 만들어졌다면 다음과 같은 작업들을 주기적으로 실시한다.
   - 가장 최근에 발표된 보안 취약점 모니터링
   - 가장 최신의 보안 패치 적용
   - 보안 가이드라인의 업데이트
   - 정기적인 내/외부 취약점 스캐닝

이 글을 마무리 하며

서두에도 언급했듯이 최근의 해킹 동향은 웹 애플리케이션을 이용한 해킹이 전체 피해 건수의 약 3/4를 상회하고 있다. 이러한 배경으로 인해 기업에서는 추가적인 보안 솔루션(웹 애플리케이션 취약점 스캐너, 웹 애플리케이션 방화벽 등)을 도입하고 있거나 도입 계획을 세우고 있다. 그러나 모든 보안이 그렇듯이 솔루션을 도입한다고 해결되는 것도 아니고 사람이 뛰어나다고 해결되는 것도 아니다.

도입된 솔루션이 제대로 운영되기 위해 끊임없이 관리자들은 노력해야 할 것이며 웹을 개발하는 개발자들은 만들어진 보안 가이드라인을 준수하여 개발해야 하며 일반 사용자들 또한 보안 가이드라인에 준하는 행동으로 발생할 수 있는 인지된 사고를 미연에 방지해야 한다. 이처럼 기업의 모든 구성요소들이 적절하게 조화를 이뤄 야지만이 투자된 비용만큼의 보안 수준을 유지할 수 있게 된다.

[참고 자료]

The Ten Most Critical Web Application Security Vulnerabilities(http://www.owasp.org/asac)
A Guide to Building Secure Web Applications (http://www.owasp.org)
Security at the Next Level (http://www.spidynamics.com/whitepapers.html)
Information Security (http://infosecuritymag.techtarget.com/2002/jun/insecurity.shtml)
CERT (http://www.cert.org)
SANS Institute (http://www.sans.org)

Hacking Exposed - Web Applications


내용출처 : [기타] (주)코코넛 시큐레터 8월호
(출처 : '[해킹기법과 대응] ③ 웹 애플리케이션 해킹 (Web Application Hacking)' - 네이버 지식iN)

에서 매년 발표하는 TOP20 공격기법 가운데 상당수를 차지하면서 해커들의 꾸준한 사랑을 받아오고 있다.

"버퍼 오버플로우"는 어떻게 이루어지는가?

버퍼 오버플로우의 정확한 동작원리를 이해하기 위해서는 프로그램에 의해 데이터가 어떻게 저장되는가를 우선 이해해야 한다. 하나의 프로그램은 수많은 서브 루틴들로 구성되는데 이런 서브 루틴이 프로그램에 의해 호출될 때, 함수 변수와 서브 루틴의 복귀 주소(return address) 포인터를 스택(stack)이라는 논리적 데이터 구조에 저장하게 된다. 스택은 실행중인 프로그램이 필요로 하는 정보를 저장하는 메모리 영역이다. 서브 루틴이 종료될 때 운영체제는 그것을 호출한 프로그램에 제어권을 반환해야 하기 때문에, 복귀 포인터를 통해서 프로그램이 서브 루틴의 실행을 마치고 나서 되돌아갈 주소를 가리키게 된다.

버퍼는 할당된 메모리 공간의 높은 주소에서 낮은 주소로 채워지며, 스택 영역에 마지막으로 들어가 데이터가 제일 먼저 빠져 나오는 LIFO(Last in, First out) 특정을 가지고 있다. 이런 LIFO 특성에 의해 가장 먼저 들어가 것(복귀 포인터)이 스택에서 가장 나중에 제거된다는 것을 기억해야 한다. 서브 루틴이 실행을 마치면 가장 나중에 행해지는 것은 복귀 포인터를 스택에서 제거하여 서브 루틴을 호출한 함수로 반환하는 것인데, 만약 이 포인터가 사용되지 않는다면 서브 루틴이 실행을 마쳤을 때 프로그램은 더 이상 어디로 진행해야 할지를 알 수 없을 것이다.

포인터(pointer)는 메모리의 위치를 저장하는 변수이다. 프로그램 실행을 위한 목적으로 다른 코드로 이동할 때 어디에서 떠났는지를 기억하기 위해 포인터를 사용해야 하며, 만약 포인터를 사용하지 않는다면 서브 루틴의 실행이 끝나고 어디로 돌아와야 할지를 알 수 없을 것이다.

이제 스택을 조작하게 되면 어떤 일이 일어나는지를 살펴 보겠다. 프로그램이 변수의 할당된 공간에 저장될 데이터의 크기를 검사하지 않고 크기에 제한을 두지 않는다면, 변수 공간은 넘치게 될 것이다. 즉, 버퍼에 오버플로우가 발생하면 저장된 데이터는 인접한 변수 영역도 침범할 것이며 결국에는 포인터 영역까지 침범하게 될 것이다. 해커는 이러한 데이터의 길이와 내용을 적절히 조정함으로써 버퍼 오버플로우를 일으키고 운영체제의 스택을 붕괴시켜 특정 코드가 실행되도록 한다. 해커가 보낸 데이터는 대개의 경우 특정 시스템에서 실행될 수 있는 기계어 코드와 복귀 포인터에 저장될 새로운 주소로 구성되어 있으며, 복귀 포인터에 저장될 새로운 주소는 다시 메모리의 스택 영역을 가리켜서 프로그램이 서브 루틴에서 반환될 때 해커가 작성한 명령어를 실행하게 되는 것이다.

이때 고려해야 할 것은 공격 대상이 되는 프로그램이 무엇이든 간에 해커가 공격 코드는 프로그램이 실행되고 있는 권한으로 실행될 것이라는 점이다. 따라서 해커는 공격을 성공시켰을 경우에 시스템에 대한 최상위 권한을 얻기 위해, root 또는 administrator 권한으로 실행 중인 프로그램을 공격 대상으로 삼을 것이다.

이론상으로는 매우 직관적인 것 같지만 실제로 이 공격을 실행하는 것은 간단한 작업이 아니다. 하지만 이런 과정이 어떻게 이뤄지는지 제대로 이해하지 못 하는 스크립트 키디(script kiddie)

도 쉽게 공개된 공격 코드를 이용하여 버퍼 오버플로우 공격을 시도할 수 있으니 보안 관리자들에게 보다 많은 업무를 주는 상황이라고 할 수 있다.

"버퍼 오버플로우" 취약성이 많은 이유는?

많은 프로그램이 취약성을 갖는 중요한 이유는 오류 검사를 제대로 수행하지 않기 때문이다. 오류 검사를 수행하지 않는 큰 이유 중의 하나는 개발자가 근거 없는 특수한 가정을 하기 때문이며, 정상적인 환경에서 변수에 할당된 메모리의 크기가 충분하다고 과신하는 것도 문제가 된다. 취약한 프로그램일지라도 사용자들이 올바르게 사용하여 발표된 지 수 년이 지나도 아무런 문제 없이 동작해온 경우도 있다. 그러던 중 누군가가 갑자기 "만일 프로그램에 원래와 다른 종류의 정보를 넣으면 어떤 일이 생길까?", "프로그램에 기대되는 크기보다 더 많은 데이터를 넣으면 어떤 일이 일어날까?"하는 식의 궁금증을 갖게 되었고 오류 검사를 수행하지 않는 프로그램들은 그런 궁금증의 실험대상이 되어 해킹의 목표가 되고 있다.

이 글을 마무리하며

"버퍼 오버플로우" 공격은 취약한 프로그램을 대상으로 공격자가 원하는 코드를 실행시킬 수 있다는 측면에서 매우 위험하며, 그 결과로 얻는 피해 범위는 시스템을 중지시키는 것에서부터 관리자 권한을 얻는 것까지 다양하다.
보안 관리자는 "버퍼 오버플로우"가 어떻게 동작하는지 이해하고, 평상시에 벤더에서 제공하는 소프트웨어 관련 패치 적용, 최소 권한으로의 프로그램 실행, 불필요한 서비스 제거, 침입차단시스템을 통한 유해 트래픽 차단을 통해 공격 피해 가능성을 최소화해야 한다.
오늘 아무런 문제가 없었다 하더라고 내일 역시 안전할 것이라는 맹신을 버려야 한다. 지금 이 시간에도 지구 저편에서는 열심히 공격코드를 테스트하는 누군가가 있을 테니까….

과 같은 자동화된 공격도구가 사용되는 경우가 많다. 따라서 공격도구의 특성을 제대로 파악하면 이에 대한 대응방법도 마련될 수 있기 때문에 이러한 연구활동도 전세계적으로 활발하게 진행되고 있다.

기술적인 대응방법뿐만 아니라 가장 중요한 것은 사전에 증후 발견이다. 이러한 공격은 대규모 네트워크를 이용하기 때문에 비정상적인 네트워크 흐름을 유발하여 초기에 이상징후를 탐지한다면 이에 대한 빠른 대응이 가능하게 된다.

이를 위하여 기본적인 보안솔루션을 구축하는 것은 물론, 적절한 관리와 운영이 병행해야 할 것이다. 또는 전세계적인 망을 가지고 있는 침해 사고 대응팀, 혹은 보안서비스 전문업체와 긴밀한 관계를 유지하여 기업보안 대책을 지속적으로 업데이트 시켜 주는 것이 무엇 보다 중요하다 하겠다.

데이터 복구가 어떻게 해서 가능하게 되는지....

일반적인 파일시스템(FAT,NTFS)의 경우엔 파일의 정보값들을 가지고 있는 부분이 있고 실질적 데이터가 있는 부분이 있습니다.

우리가 윈도우 탐색기로 윈도우를 열어서 볼때 탐색기는 하드디스크의 파일이나 디렉토리등의 정보 값이 있는 부분을 불러 오게 됩니다. 즉 이 부분은 실제 데이터와 사용자간을 연결해주는 고리라고 보시면 되겠습니다.

그리고 이부분은 만약의 경우 데이터 유실을 대비하여 복사본(Mirror)을 가지고 있고, 일반적인 데이터 복구 프로그램들에서는 이부분을 사용하게 되는것입니다.

우리가 일반적으로 데이터를 삭제했을때 실제로는 우리가 사용하는 데이터가 삭제가 되는것이 아니고 파일의 정보만을 없애게 되는것입니다.

실제 데이터를 지우는거라면 시간이 많이 걸리기 때문이죠. 영화나 음악등을 다운받거나 다른 하드디스크로 옮길때는 시간이 무척이나 오래걸리지만 파일을 삭제한다거나 같은 하드디스크에서 다른폴더로 이동을 시킬때에는 순식간에 쏴악 지나가 버리죠. 바로 실제 데이터를 이동시키거나 삭제 되는것이 아니라 디스크의 정보값을 삭제하는것이기 때문입니다. 휴지통에 버리거나 삭제를 시켰다 하더라도 실제 데이터는 아직 그 영역에 남아 있다는 거죠.

그럼 지워버린 데이터들은 100% 복구가 될까요? 물론 꼭 그렇지만은 않습니다. 지워도 실제 데이터가 아직 그곳에 남아 있긴 하지만 수많은 데이터들이 지워도 그자리에 계속 있다면 하드디스크가 아무리 용량이 크다 하더라도 언젠간 꽉 차서 쓸모가 없게 되버리겠죠

데이터가 지워졌을 경우 실제 데이터는 남아있지만 지워지고 난후에 다른 데이터를 하드디스크에 복사하셨다거나 다운을 받으셨다면 이야기는 조금 틀려 질수 있습니다. 만약 500메가짜리 하드디스크가 있는데 거기에 있던 데이터를 모두 지우고 다시 500메가 용량의 데이터를 저장했다면 이미 전에 있던 데이터는 사라졌을테니까요.. 물론 이경우는 아주 최악의 경우이겠지만요..

요즘의 보통 하드디스크는 용량이 크기 때문에 그 하드디스크를 한꺼번에 지우고 다시 일일히 하나씩 넣어서 꽉채우는건 쉬운일이 아닐테지요.. 삭제시킨 데이터는 파일 목록에서 사라지고 그공간은 공용의 공간으로 남게 됩니다. 언제든 다른 데이터가 들어갈수 있게 됩니다...

하드디스크에 많은 파일들을 저장하고 또 파일들을 지우다보면 하나의 문제가 생기게 됩니다.. 바로 작은 용량의 파일과 큰 용량의 파일이 있는데, 작은 파일이 저장 되어 있었다가 사용자의 삭제로 공용화 되어버린 공간안에 큰 파일이 들어갈순 없지 않겠느냐 하는거겠죠.. 작은 공간에 전부 들어 갈수 없으니 다른 공간에라도 나눠서 저장을 해야 되겠죠.. 이런 문제로 파일의 조각이 생기게 되는 것이고 FAT32 시스템의 FAT영역이나 NTFS의 MFT영역에서 이 조각들의 연결정보를 가지게 되는겁니다.. 참고로 윈도우의 디스크 조각모음은 이렇게 조각이 난 파일들을 한군데로 끌어 모아서 정리하는 작업을 해주게 되는것이구요.. 한군데 모여 있다면 여기저기 검색할 필요가 없으니 하드디스크 리딩 타임이 빨라지는것또한 당연한 일이되겠지요... 단순히 인터넷에 접속해서 웹서핑을 하는것만으로도 파일들이 하드디스크로 전송이 되기도 하고 삭제가 되기도 하기 때문에 단 몇일이라도 하드디스크를 사용한 경우라면 하드디스크에는 여기저기 조각이 발생하게 되는거구요...

이런 공간들이 많기 때문에 재설치나 파일 삭제후 PC를 사용하셨더라도 복구는 가능하게 되지만 앞서 설명했듯이 삭제된후 다시 저장되는 데이터들의 저장 위치는 같은 데이터라 하더라도 랜덤하게 저장이 되기 때문에 약간의 데이터라할지라도 덮어 씌워지게 되면 기존의 데이터는 손상이 될수도 있습니다. 그래서 손실로 인한 문제가 생겼을 경우엔 최대한 사용을 자제 하시는게 좋습니다.

포맷을 한 경우도 같은 맥락으로 보시면 되겠습니다. 포맷은 퀵이건 로우 포맷이건 실제 데이터 영역을 지우진 않습니다. 바로 FAT혹은 MFT를 완전히 날려 버리는 것입니다. 이경우 역시 데이터는 그곳에 그대로 존재하기 때문에 복구가 가능하게 되는 것이겠구요..

정리하자면 윈도우에서 파일을 지우거나 포맷하게 될경우 데이터는 남아 있게되고 이 파일은 당장에라도 복구가 가능 할수 있게 됩니다. 또한 아주 예전에 지운 데이터라도 조각난 공간의 어딘가에 남아 있다면 복구가 가능하게 되는것이구요. 중요한건 데이터가 삭제가 되었을 경우엔 최대한 컴퓨터를 사용하지 않으시는게 중요한 데이터를 살리실수 있는 확률이 높아지게 되는겁니다.. 정말 중요한 데이터라면 포기하지 마시고 의뢰하셔서 무료진단을 해보시길 바랍니다. 어떠한 최악의 경우에라도 복구는 가능할수도 있으니까요..

마지막으로 FAT과 NTFS란 어떤 것들이길래 라는 의문이 드시는 분들을 위해 설명을 드리자면

FAT(File Allocation Tabe) : 디스크는 클러스트단위로 관리가 되게 되는데 이 클러스트들의 사용 상황을 기억하는곳이 바로 파일할당테이블(FAT)입니다. FAT에는 클러스트들의 사용상황이 기술되어 있고, 또 사용중이라면 다음클러스터와의 연결정보또한 포함하고 있습니다. 클러스터 하나의 용량은 매우 작고 데이터의 용량이 클경우 하나의 클러스터에만 데이터가 저장이 될수 없기 때문에(FAT의 경우 16이냐 32이냐 혹은 디스크 용량에 따라 하나의 클러스터의 크기가 1K~32K 정도로 다릅니다) 연결되는 클러스터 들의 정보값또한 존재 하고 있습니다.. 컴퓨터를 일정기간 오래 사용하시다 보면 파일들이 여기저기 흩어져 있기 때문에 연결되는 클러스터들에 대한 정보값은 필수적인 요소가 되겠죠..

NTFS(NT File System) : NT에서 사용되는 고유의 파일 시스템으로  FAT과는 달리 마스터 파일 테이블 (MFT: Master File Table)이 존재하고 이에 대한 미러(mirror)와 파일 로그가 유지되므로 파일 복구가 가능합니다. 한 클러스터는 FAT32와 같이 최소 1KB에서 최대 4KB로 디스크 손실이 적다. 또한 반대의 경우로 지나친 단편화(fragmentation)를 막기위해 FORMAT명령어를 이용하여 더 큰 클러스터로 초기화할 수 있습니다. (멀티미디어 데이터 등의 큰 파일을 다룰 경우에는 작은 클러스터를 사용하면 조각이 발생하므로 클러스터 크기가 클수록 효과적입니다. )

작성자 : 임수현

내용출처 : [직접 서술] 블로그 집필 - 데이터 복구 
(출처 : '데이터 복구 - 소프트' - 네이버 지식iN)

"PC 보안 PART ii - 폴더 접근 계정 및 그룹 설정 ①" 에서는 폴더의 사용자 권한을 설정하는 방법에 대해서 배웠다.

컴퓨터를 많이 사용하는 분이라면 아마도 "헉, 권한 설정할 폴더가 수십개는 될텐데, 언제 다하나;" 이런 생각을 했을 것이다.

다행이도 권한 설정은 "부모 폴더"와 "자식 폴더" 개념을 사용하여 부모폴더에 설정한 권한을 자식 폴더에도 그대로 자동적용 하도록 되어 있다.

"부모 폴더"란, 상위의 위치에 있는 폴더 전체를 말하며 "자식 폴더"는 반대로 하위 위치에 있는 폴더 전체를 말한다.(부모폴더 = 상위폴더, 자식폴더=하위폴더)

즉, C 드라이브 자체는 부모 폴더가 되며 C 드라이브 안에 있는 모든 폴더는 C 드라이브의 "자식 폴더"가 되는 것이다.

더 설명하자면, C드라이브 안의 Program Files 라는 폴더가 있는데, C드라이브의 입장에서 볼 때, Program Files 라는 폴더는 자식 폴더이고, Program File 입장에서 봤을때는 C드라이가 부모 폴더가 되는 것이다.

하나 더 나아가서 Program Files 안에도 여러개의 폴더가 있게 되는데, Program Files 폴더의 입장으로 볼 때, 이 폴더들이 "자식 폴더"가 되고, 그 폴더들의 입장에서는 Program Files가 부모 폴더가 되는 것이며, 또한 Program Files 의 부모 폴더는 C 드라이브가 되므로, Program Files 안에 있는 모든 폴더의 부모 폴더는 둘("C드라이브"와 "Program Files") 인 셈이다.

Windows 2000 에서, 드라이브나 폴더의 "등록정보"창에서 [보안]탭을 보면 맨 아래에 다음과 같은 체크박스가 보인다.

"□ 부모로부터 상속 가능한 사용 권한을 이 개체로 전파할 수 있음"

Windows XP는 조금 달라서, 위의 체크박스 메시지가 보이지 않는다.

Windows XP는 [고급] 버튼을 클릭하면 아래와 같은 창이 뜨고, 그 창에 위의 체크박스 메시지가 보인다.

Windows 2000과 XP에서 위의 "부모 어쩌고" 하는 체크박스를 해제하면 아래와 같은 메시지가 뜬다.

[Windows XP에서]

그 이유는 "사용자 계정"이라는 정책을 사용하고, 폴더 접근 권한을 따로 설정할 수 있기 때문이다. (컴퓨터를 좀 아는 분들은 Unix 계열 시스템의 chmod 명령어를 떠올릴 것이다.)

보통 가정의 PC는 단 1명만 사용하는 일이 거의 드물다. 자녀가 2명 이상이면 더욱 그러하다. 뭐, 돈좀 버는 집안이라면 자녀마다 PC를 각각 사주겠지만;;

아무튼 대다수의 가정용 PC는 어머니도 쓰시고(고스톱 등), 아버지도 쓰시고(고스톱, 바둑 등), 2명 이상이 사용하게 된다.

그래서 다른 사용자들이 자칫 나의 프라이버시를 침해할 수 있게 된다. 아무튼 필자는 감출게 좀 있어서(ㅋㄷㅋㄷ) 다른 사용자들의 접근 권한을 다양하게 설정했다.

그러기 위해서는 먼저, "다른 사용자"가 사용할 "사용자 계정"을 새로 만들어 줘야 한다.

#주의! Windows XP Home 버전은 XP Professional과 달라서 아래의 작업을 할 수가 없다. Home 버전은 아에 "그룹정책"자체가 없기 때문이다. 필자는 개인적으로 Home 버전을 증오한다.-_-#

Q: 저도 XP인데, Pro인지 Home인지 모르겠어요. 어떻게 알 수 있죠?

A: 바탕화면 또는 시작버튼안에 있는 [내컴퓨터]에서 마우스오른쪽 버튼을 눌러 "속성"

을 클릭하시고, [일반]탭을 보시면 "시스템"이라는 항목이 있습니다.

Microsoft Windows XP 라는 글씨 밑에 Home 또는 Home Edition 이라고 써있으면 Home Edition이고 Professional 이라고 써있으면 Pro 입니다.

1. 이전글에서 알려준 "컴퓨터 관리"를 실행한다.

[사용자]폴더를 선택하고 마우스 오른쪽 버튼을 누른다음 "새 사용자"를 클릭한다.

(사용자 폴더를 선택한 뒤, 오른쪽 부분의 빈칸에서 마우스 오른쪽 버튼을 눌러도 된다.)

- 사용자 이름: 사용자 계정의 이름이다. 가족이 계정명을 까먹지 않도록 쉽게 정하자

- 전체이름: 입력할 필요가 없다.

- 설명: "이게 누구의 계정이더라?" 하고 까먹지 않기 위해서 짧게 설명을 넣어줘도 괜찮겠다.

- 암호는 반드시 설정하자.(이전글에서 우리는 암호의 중요성을 좀 배우지 않았는가!)

- "다음 로그온할 때 반드시 암호 변경"의 체크는 해제하고 "암호 사용 기간 제한 없음"을 선택.

- [만들기]버튼을 누르면 사용자 계정이 생성된다.

2. 이제 사용자 별로 폴더 및 파일에 대한 권한을 설정해보자.

먼저 윈도우 탐색기(Explorer.exe)를 실행시킨다.

윈도우 탐색기는 시작버튼 > 프로그램 > 보조프로그램 > 윈도우 탐색기를 클릭하면된다.

(가끔 누군가가 친절하게 그놈을 끌어다가 바탕화면이나 작업표시줄에 놓는 경우도 있다.)

* 윈도우 팁 한가지: 윈도우 탐색기의 단축키는 "윈도우키"+E 를 누르면 된다.

* "윈도우 키"는 스페이스바 왼쪽의 ALT 키와 CTRL 키 사이에 있는 윈도우 로고가 찍힌 키다.

윈도우 탐색기를 처음 보는 사람들을 위하여 간단하게 설명하겠다.

윈도우 탐색기의 왼쪽부분은 모든 드라이브와 폴더를 나열한 부분이고, 왼쪽에서 드라이브나 폴더를 선택하면 오른쪽 부분에 그 드라이브나 폴더안의 내용들을 보여준다. 몇 번 해보면 뭔지 안다.

윈도우 탐색기 왼쪽 부분에 보이는 드라이브나 폴더들을 보면, 아이콘 앞에 + 표시가 보일것이다. 이 표시는 해당 폴더나 드라이브 안에 또다른 폴더가 존재 한다는 뜻이다.

그 + 표시를 클릭하면 - 표시로 바뀌면서 안에 들어있는 폴더목록을 쭉~~ 늘어 놓는다.

이런 작업을 "폴더를 확장시켰다" 라고 말하기도 한다.

- 설명 끝 -

아무튼 윈도우 탐색기를 실행했으면 [내 컴퓨터] 안에 각각의 드라이브가 보인다.

보통 로컬드라이브와 CD-ROM이 보인다. 로컬드라이브는 운영체제 설치시에 두개 이상으로 나눌 수 있는데, C, D 이런식으로 영문 이름이 붙게 된다. 그것들을 우리는 C드라이브, D드라이브 이렇게 부르기도 한다.(근데 "우리"가 누구지 -_-?)

일단 C드라이브를 선택하고 마우스 오른쪽 버튼을 누른뒤 "등록정보"를 클릭한다.

(XP 사용자들은 "등록정보"가 아니라 "속성"으로 보일것이다. 이전에 설명했으니 잘 기억하자.)

등록정보창의 [보안] 탭으로 이동한다. 여기서 XP 사용자들은 주의를 해야 한다. 왜냐면, 별도의 폴더 설정이 없이는 그 [보안]탭이라는게 보이지 않기 때문이다.

#XP에서는 폴더옵션을 수정하여 [보안]탭을 보이게 할 수 있다. 수정해보자.

1. 윈도우 탐색기의 맨 위의 메뉴줄에서 [도구] 메뉴 안의 "폴더 옵션"을 클릭한다.

2. [보기]탭으로 이동한다.

3. "모든 사용자에게 동일한 폴더 공유 원한을 지정(권장)"이 체크되어 있을 것이다.

  내 생각엔 권장할만한게 아닌데 (권장) 이랜다. 킁. 체크를 해제하자.

4. 이제 드라이브의 등록정보(속성)를 다시 누르면 [보안]탭이 보인다.

위의 그림이 등록정보 창의 [보안]탭이다.

"어?? [그룹 또는 사용자 이름] 부분이 나랑 다르네??" 라는 분들이 거의 전부일 것이다.

아마도 여러분들의 보안탭에는 "Everyone" 이라는 놈 딱 하나만 보일것이다. 이것이 Windows 설치의 기본설정값이다.(보안에 좀 취약하다.) "Everyone"을 선택하고 [제거]해 버리자.

그다음 [추가]버튼을 누른다.

사용자 개체를 선택하라는게 보인다. Administrators 를 선택하여 [추가]버튼을 누른다.

(주의! Administartor가 아니라 Administrators 다. 즉, 사용자가 아니라 그룹을 추가시킨것이다. 사용자 개체에서 아이콘 모양이 사람머리 하나이면 "사용자"이고 머리가 둘이면 "그룹"이다.왜 사용자가 아니라 그룹을 넣느냐면, 사용자를 넣으려면 여러번 추가해줘야 하니까 귀찮아서다.그러니까 그룹을 넣어서 그 그룹에 속한 모든 사용자가 자동 추가되도록 하는것이다.)

(또 주의! Windows XP에서는 사용자 개체를 보여주지 않고 직접 써넣으라고 그런다. 건방지게..사용자 개체를 검색하여 선택, 추가하는 방법이 있지만 조금 복잡하니 그냥 입력하자.)

그런다음 다시 [보안]탭에서 Administrators 를 선택하고 아랫부분에 보이는 "사용 권한"을 보자. "모든 권한"의 "허용" 부분을 체크하자. 그러면 자동으로 아래의 항목이 모두 체크된다.

Administratos 그룹을 추가했으면 이제는 Users 그룹만 추가하면 된다. Users 그룹은 집안 식구들 이 사용자는 계정(아까 처음에 우리가 새로 생성한 그 계정들)이 기본적으로 속해지는 그룹이다.

Users 그룹의 권한은 모든 권한을 줘도 상관없고 알아서 주고 싶은 권한만 따로 줘도 된다.

(일단 C드라이브에 대해서는 모든 권한을 줘버리자. 그들도 나름대로 자기가 설치하고 싶은 프로그 램이 있을 수 있으니까. 만일 C드라이브에 쓰기권한이 없으면 프로그램 설치가 안되고, 그럴때마다 "내"가 일일이 설치해줘야 하는 번거로움이 생길 수 있다.)

다 끝났으면 [확인]버튼을 누른다.

지금까지의 [보안]설정은 모든 드라이브(C, D 등등)도 가능하고 폴더에서도 가능하다. 폴더를 선택하고 "등록정보"를 눌러 [보안]탭으로 들어간 뒤, 위와 같은 작업을 하면 된다.

가족들이 보지말았으면 하는 그런 것들은 따로 폴더를 만들어 넣어놓은다음, [보안]탭에서 내계정만(또는 Administrators 그룹) 남기고 다른 계정은 모두 제거해 버리면 된다.

이런 보안 설정은 Administrators 그룹에 속한 사용자들만이 가능하다. Users 이하의 그룹에 속한 사용자들은 이런 설정작업을 하지 못한다.

#주의! 폴더의 보안 설정을 바꾸다 보면 "부모로 부터 권한을 상속받아서 ~~ 할 수 없다" 라는 경고창이 뜨게 된다.

이런 경우에 대한 설정과 좀 더 자세한 설명은 "PC 보안 PART ii - 폴더 접근 계정 및 그룹 설정 ②" 에서 하기로 하겠다.