Part06 - 애플리케이션 보안

728x90

FTP 보안 - 파일 관련 프로토콜 / FTP 보안위협 및 대응책 / FTP 서비스 운영

이메일 보안 - 프로토콜 / 이메일 콘텐츠 보안을 위한 보안 기술 / 스팸 메일 보안 대응 기술 / sendmail

웹 보안 - 개요 / www와 http / SSL,TLS / 웹서버 보안 / 웹 보안위협 및 대응책 / 스프트웨어 개발 보안

DHCP와 DNS보안 - 호스트 설정과 호스트 설정 프로토콜 / DNS / DNS 보안 / DNS서버 보안 설정

데이터베이스 보안 - db / db 보안 요구사항 / db 보안 통제 / dbms보안 관리

전자상거래 보안 - 전자상거래의 정보보호 / SET(Secure Electronic Transaction) / 전자상거래 응용 보안

침해사고대응(디지털포렌식) - 해킹 / 침해사고 대응과 포렌식

각종 애플리케이션 보안위협 및 대응책 - 각종 애플리케이션 보안위협 및 대응책 / 자바 보안

FTP 보안

1. 파일 관련 프로토콜

(1)FTP(File Transfer Protocol)

: 파일 전송 프로토콜은 하나의 호스트에서 다른 호스트로 파일을 복사하기 위해 TCP/IP에 의해 제공되는 표준 기능

- 호스트 간에 두 개의 연결을 설정한다. 하나는 데이터 전송을 위해 사용되고 다른 하나는 명령과 응답 등의 제어 정보를 위해 사용[20,21]

2) FTP 로그인 순서와 인증

3)FTP 연결

(가)능동(Active) Mode(일반 연결)

특

- 일반적으로 능동모드가 FTP 클라이언트의 기본 값으로 설정

클라이언트에서 서버측 21번 포트로 접속하여 제어 채널을 생성하고 데이터는 서버 -> 클라이언트로 접속하여 데이터를 보내는 방식

if) 클라이언트 pc에 방화벽이 설치되어 외부에서의 접속을 허용하지 않는다면 FTP 접속은 되지만 이후 데이터 채널 연결 불가능. 파일 받을 수 없다.

- 동작방식

(나) 수동(Passive) Mode(수동 연결)

특

- 클라이언트에서 서버측 21번 포트로 접속하여 제어 채널을 생성하고 데이터 채널도 클라이언트에서 서버로 접속하여 데이터를 보내는 방식

(2)익명 FTP

(3)TFTP(Trivial File Transfer Protocol)

FTP 발전형

FTP는 TCP, TFTP는 UDP(69번 포트)

FTP, TFTP차이점

전송

한정된 개수의 명령

한정된 데이터 표현 방식

인증의 부족

데이터 전송

연결 설정과 종료 사이에서 수행된다. TFTP는 신뢰성 없는 UDP 서비스를 사용한다.

파일은 데이터와 블록으로 나뉘고, 마지막 블록을 제외한 각 블록은 정확히 512바이트의 크기를 갖는다.

udp는 흐름제어와 오류 제어를 위한 기능이 없으므로 TFTP는 연속적인 데이터 블록으로 파일을 전송하기 위해 흐릅제어와 오류 제어 메커니즘을 생성해야 한다.

(4) NFS와 삼바

NFS(network file system)

: TCP/IP 프로토콜을 사용하여 네트워크상에서 파일시스템을 운영할 수 있도록 해주는 프로토콜

데이터의 보안과 무결성을 보장하면서 인증된 네트워크 사용자가 공유된 네트워크 파일을 마치 자신의 저장 장치에 있는 것처럼 사용할 수 있는 방법을 제공한다.

디스크 공간 절약됨

SAMBA삼바

SMB(Server message Block)을 사용하여 유닉스 계역 시스템과 윈도우 시스템 간에 파일 및 프린터 자원을 공유

2. FTP 보안 위협 및 대응책

1)FTP 보안

- FTP 프로토콜은 보안이 큰 문제가 되기 전에 설계되어 비밀번호가 평문으로 되어 있어 공격자가 가로채어 사용할 수 있다.

- 데이터 전송 연결 또한 봏호되지 않은 평문으로 데이터를 전송한다. 보안을 위해서는 FTP 응용계층과 TCP계층 사이에 보안 소켓 계층을 추가할 수 있다. => SSL-FTP라 부름

2)SFTP(Secure File Transfer Protocol) 프로그램

유닉스 프로그램으로 보안 채널을 사용해 자료를 전송하는 다른 방법(독립된 프로토콜을 사용하는 것)

ssh의 응용 요소의 일부로 FTP처럼 동작할 수 있는 쌍방향 프로그램이며 SSH 클라이언트와 SSH 서버 사이에서 파일을 전송하기 위해 인터페이스 명령 세트를 사용한다.

3) TFTP 보안

보안에 대한 고려가 없고 사용자 확인이나 비밀번호도 없는 문제가 있다.

TFTP가 필요한 경우 secure mode로 운영한다. 이 모드는 chroot기능을 이용하는 것으로 지정한 디렉터리를 최상위 디렉터리로 지정하여 지정한 디렉터리의 상위 디렉터리로 접근하지 못하도록 제한하는 방식

4) Bounce attack
: 제어 채널과 데이터 채널을 다르게 사용하고 데이터 채널을 생성할 때 목적지를 확인하지 않는 FTP 설계의 구조적 취약점을 이용한 공격

- 능동모드에서 FTP 서버의 파일을 요청하면 클라이언트에서 파일을 받을 IP와 포트를 지정해서 전달(PORT명령)

이때 IP와 포트를 요청한 클라이언트가 아닌 임의의 주소로 지정할 수 있는데 이런 FTP 설계의 취약점을 이용한 공격이다.

주로 익명 FTP 서버를 이용해서 PORT 명령을 조작하여 공격대상 네트워크를 스캔하고 FTP 서버로 하여금 공격자가 원하는 곳으로 데이터를 전송하게 한다.

보안대책

- FTP의 원래 규약을 어느 정도 제한하는 방법

- FTP의 원래 규약은 인정하되 다른 서비스가 20번 port 접속을 요청하면 거절하는 방법

5) Anonymous FTP 취약점

보안 절차를 거치지 않은 익명의 사용자에게 FTP 서버로의 접근을 허용한다.

익명 사용자가 서버에 쓰기 권한이 있을 때 악성 코드 생성이 가능하다.

보안 대책

- 보안상 심각한 취약점으로 반드시 사용하는 경우가 아니면 서비스를 제거한다.

- anonymous 사용자의 루트 디렉터리, bin, etc, pub디렉터리의 소유자와 퍼미션을 관리한다.

6) FTP 접근 제어 설정

ftpuser 파일을 통한 접근 제어

- 평문 노출이 있기 때문에 root접근을 제한

- ftpuser 파일은 접속을 제한할 계정정보를 담고 있는 설정 파일이다. 따라서 root 등 중요한 계정을 ftpusers파일에 명시하여 접속을 제한한다.

tcpWrapper를 통한 접근 제어

TCPWrapper의 설정 파일인 hosts.allow, hosts.deny 파일을 이용하여 IP 기반의 접근제어를 수행한다.

FTP 데몬 프로그램별로 연동 설정이 필요하다.

3. FTP 서비스 운영

1) proftpd

특

wu-ftpd의 대안으로 개발, 안정적이고 빠름, xinetd/standalone 형태로 작동 가능

ftp 접속 시 확인 설정

/etc/passwd, /etc/shadow에 사용자 계정이 있는지 검사

/etc/ftpusers에 사용자 id가 있으면 거부

/etc/shell에 등록되지 않은 셸을 사용하는 유저는 접근 거부[RequireValidShell off]

proftpd 설정 파일 옵션

ServerType standalone(inetd) : 서버 타입 설정

RootLogin off : 루트 계정 로그인 허용 안함

User nobody : 데몬 동작 계정

Group nobody : 데몬 동작 그룹

...

2)vsftpd(very Secure FTP Daemon)

기능

가상 IP별 별도의 환경 설정 기능(설정파일의 listen_address = 이용)

가상 사용자 설정

전송 대역폭 지정

PAM 지원

xferlog 표준 로그 파일보다 상세한 자체 로그 파일 형식 지원

Standalone 방식과 inetd를 통한 운영 모두 지원

IP별로 다른 환경 파일 지정 기능(tcp_wrappers와 함께 사용할 때)

이메일 보안

1. 이메일 관련 프로토콜

(1) 전자우편과 구조

UA(user agent) / MTA(Message Transfer Agent) / MAA(Message Access Agent)

(2)SMTP(Simple Mail Transfer Protocol)

: 인터넷에서 MTA클라이언트와 서버를 규정하는 공식적인 프로토콜

- 메일 서버는 SMTP를 가리키며 유닉스에선 SMTP 서버 소프트웨어는 sendmail이다.

특

smtp는 암호화 전송을 지원하지 않아 별도로 암호화해야 한다. 오늘날은 dns를 통해 사용자의 메일 서버를 찾은 후 그 서버로 이메일을 본낸다.

2)명령과 응답

smtp는 명령과 응답을 사용하여 MTA클라이언트와 MTA서버 사이의 메시지를 전송한다.

(3) 메시지 액세스 에이전트(POP, IMAP)

1)pop3(Post office Protocol 버전3) - tcp 110번

2)IMAP4(Internet Mail Access Protocol 버전4) - tcp 143번

2. 이메일 콘텐츠 보안을 위한 보안 기술

(1) PEM(Privacy Enhanced Mail)

: 인터넷 드래프트로 채택한 기밀성, 인증, 무결성, 부인방지를 지원하는 이메일 보안 기술이다.

기존 전자우편 프로토콜을 이용하여 암호화된 정보, 전자서명, 암호화 방법 등의 내용을 본문에 텍스트 형식으로 전송한다.

(2)PGP(Pretty Good Privacy)

말그대로 꽤 잘 보장되는 사생활의 비밀

키링

: PGP에서 사용하는 구조는 각 노드에서 한 쌍의 데이터 구조를 제공해야 한다.

하나는 노드가 소유한 공개키/개인키 쌍을 저장하기 위한 것이고

다른 하나는 이 노드가 알고 있는 다른 사용자의 공개키를 저장하기 위한 것이다.

- 이 두 데이터 구조를 각각 개인키 고리(Private-key ring)와공개키 고리(public-key ring)라고 부른다.

- 지원하는 보안기능

기밀성, 메시지 인증, 사용자 인증, 송신 부인 방지, 수신 부인 방지는 미지원

3)PGP 보안 서비스

기밀성, 인증, 압축, 전자 우편 호환성, 분할 및 재결합

4)동작 과정

인증만 하는경우

기밀성만 제공하는 경우

인증과 기밀성을 제공하는 경우

(3) S/MIME(Secure Multipurpose Internet Mail Extensions)

1) MIME(Multipurpose Internet Mail Extensions)

: 전자 우편을 통해 ASCII가 아닌 데이터가 전송될 수 있도록 허용하는 부가적인 프로토콜

- MIME는 송신 사이트에서 ASCII가 아닌 데이터를 NVT ASCII 데이터로 변환하고 이를 인터넷을 통해 송신할 클라이언트 MTA로 배달한다. 수신자측의 메시지는 원래 데이터로 역변환된다.

NVT(Network Virtual Terminal) : 텔넷 규약에서 정의된 망 가상 단말기, 송신 호스트에서 수신 호스트로 데이터를 전송할 때 두 시스템에서의 데이터 양식이 다르기 때문에 데이터를 변환시키키는 가상 장치이다.

(나)MIME 헤더

: 변환 인수를 정의하기 위해 원래의 전자우편 헤더 부분에 추가될 수 있는 5개의 헤더를 규정한다.

MIME 버전 / 내용 유형 / 내용 전달 인코딩 / 내용 ID / 내용 기술

2) S/MIME(Secure Multipurpose Internet Mail Extensions)

: 기존 전자 우편 보안 시스템의 문제점인 PEM 구현의 복잡성, PGP의 낮은 보안성과 기존 시스템과의 통합이 용이하지 않다는 점을 보완하기 위해 IETF의 작업그룹에서 RSADSI(RSA Data Security Imcorporation)의 기술을 기반으로 개발된 전자 우편 보안 시스템

동작

1 사용자 -> 수신자에게 보낼 메세지 작성(RFC822에 정의되어 있는 MIME 형태로 작성된다)

2 MIME 헤더와 바디로 구성되는 MIME 형태의 메시지를 S/MIME메시지로 변환

3 마지막으로 사용자의 메시지 보내기하면 메일 클라이언트는 전자 우편 서버에 메일을 전송하고 수신자의 메일 서버에 메시지가 전송되어 수신자는 S/MIME 클라이언트를 이용해 메시지를 받는다.

보안 서비스

디지털 서명(RSA, sha-256) / 메시지 암호화(AES-128) / 압축(제한없음) / 이메일 호환성(Radix-64 변환)

기능

- 동봉된 데이터(Enveloped data)

- 서명된 데이터(Signed data)

3. 스팸 메일 보안 대응 기술

(1) 스팸 메일의 대응 방안

메일 서버 수신차단

[콘텐츠 필터링, 송신자 필터링, 네트워크 레벨 필터링, 발송량 기준 차단, 시간대별 차단]

메일 서버 보안

[릴레이 스팸 방지, anti-spam 솔루션 도입]

메일 클라이언트 보안[콘텐츠 필터링, 송신자 필터링]

2) 메일 서버 등록제 SPF(Sender Policy Framework)

: 메일 헤더에 표시된 발송정보가 실제로 메일을 발송한 서버(IP)와 일치하는지를 비교함으로써 발송자 정보의 위변조 여부를 파악할 수 있도록 하는 기술.

이메일 발송자의 서버를 DNS에 미리 등록하고 수신자의 서버에 메일이 도착하면 등록된 서버로부터 발신되었는지 확인하여 스팸 메일을 차단하는 기술.

특

스팸 메일은 수신자에게 전달되기 전에 각 포털 업체 메일 서버에서 자동으로 차단한다.

필터링 방식에 비해 서버 및 네트워크 자원 소모가 낮고 과오 차단의 가능성이 현저히 낮다.

오픈 소스를 기반

3) 스팸 필터 솔루션

- 메일 서버 앞단에 위치하여 프락시 메일 서버로서 동작하며 SMTP 프로토콜을 이용한 DoS 공격이나 폭탄 메일, 스팸 메일을 차단한다.

또한 전송되는 메일의 바이러스까지 체크할 뿐만 아니라, 내부에서 밖으로 전송되는 메일에 대한 본문 검색 기능을 통해 내부 정보 유출도 방지한다.

기능

메일 헤더 필터링, 제목 필터링, 본문 필터링, 첨부파일 필터링

4) 스팸 메일 방지 보안도구

- procmail : Sendmail.cf에 포함시키거나 사용자 디렉터리에 forward 파일을 위치시켜 실행시키는 plug-in 형식으로 쓰인다.

- Sanitizer

- Inflex

- SpamAssassin

4. sendmail

: 인터넷 전자 메일의 표준규약인 SMTP 프로토콜을 통해서 메일 서비스 기능을 한다. 메일 서버 간에 메일을 주고받는 역할을 함

웹 보안

1. 웹 보안 개요

2)웹 트래픽 보안 방법

- 웹 보안을 제공하는 한 가지 방법은 IP 보안(IPSec)을 사용하는 것이다. - 투명성을 제공, 범용 해결책을 제시 + 필터링 기능으로 선별된 트래픽에서만 IP 보안 처리 하기 때문에 이에 대한 오버헤드만 추가된다.

- 또 다른 범용 해결책은 TCP 바로 위에 보안을 구현하는 것

SSL(Secure Socket Layer)과 전송 계층 보안(TLS, Transport Layer Security)

2. www와 http

(1)하이퍼 텍스트 전송 프로토콜(HTTP)

: 웹에서 웹페이지를 가져오기 위해 어떻게 클라이언트-서버 프로그램이 작성될 수 있는지를 정의하는데 사용

HTTP 클라이언트는 요청, 서버는 응답

2)영속성

http1.0 영속성 연결

http1.1 비영속성 연결

3) HTTP 트랜잭션

요청 메시지

응답 메시지

3. SSL, TLS

: 클라이언트/서버 환경에서 TCP 기반의 애플리케이션에 대한 종단간(E-T-E) 보안 서비스를 제공하기 위해 만들어진 전송계층 보안 프로토콜이다.

- 대칭키 암호, 공개키 암호, 일방향 해시함수, 메시지 인증코드, 의사난수 생성기, 전자서명을 조합해서 안전한 통신을 수행한다.

암호기술에 의존하지 않는데 어느 대칭키 암호가 약하다고 판명되면 앞으로 그 대칭키 암호를 사용하지 않는다.

2) 클라이언트와 서버

3) SSL/TLS상의 HTTP

4) SSL/TLS 보안 서비스

기밀성 서비스

클라이언트와 서버 상호 인증

메시지 무결성 서비스

5) 암호 스위트(cipher suite)

6) SSL(secure socket layer)과 TLS(transport layer security)의 차이

ssl ver.3.0의 취약점 - poodle 공격(CVE 2014-3566) 프로토콜 버전 다운 그레이드 공격

(2)TLS(Transport Layer Security) 프로토콜

2) TLS 구조

핸드셰이크 프로토콜 / 암호명세 변경 프로토콜 / 경고 프로토콜 / HTTP / 하트비트 프로토콜

레코드 프로토콜

TCP

- TCP를 활용하며 2계층에 걸친 프로토콜이다.

Record 프로토콜은 운반자이며, 응용 계층으로부터 오는 데이터뿐만 아니라 TLS의 상위 프로토콜로부터 오는 메시지를 전송

핸드셰이크 프로토콜은 Record프로토콜에 대한 보안 매개변수를 제공한다. 암호 집합을 설정하고 키와 보안 매개변수를 제공한다.

ChangeCipherSpec 프로토콜은 암화학적 비밀을 신속하게 보내는 데 사용된다. Alert 프로토콜은 비정상 조건을 알리는데 사용

Heartbeat 프로토콜은 개체의 가용성을 모니터링 할 때 사용한다.

3) Handshake 프로토콜

- 이 프로토콜을 이용해서 서버와 클라이언트가 서로를 인증하고 암호화 MAC 알고리즘 그리고 TLS 레코드 안에 보낸 데이터를 보호하는데 사용할 암호키를 협상할 수 있다.

유형(Type) - 10개의 메시지 중 하나를 나타낸다
길이(Length) - 메시지의 길이를 바이트로 나타낸다
내용(Content) - 이 메시지와 연관된 매개변수이다.

메시지 유형

[hello_request / client_hello / server_hello / certificate / server_key_exchange / ...]

4단계의 프로토콜

1. 초기협상단계 : 프로토콜 버전, 세션ID, 암호조합, 압축 방법, 초기 랜덤 넘버를 포함한 보안 능력 구축

2. 서버 인증 단계 : 서버가 필요하다고 생각되면, 인증서, 키 교환을 보내고, 인증서를 요청한다. hello메시지 단계를 끝내는 것을 알린다.

-> 서버는 인증서와 키 교환을 전송하고인증서를 요청, Hello 메시지 종료 시그널 전송

3. 클라이언트 인증 단계 : 클라이언트는 요청이 있는 경우 인증서 전송, 키 교환 전송, 인증서 확인 전송

4. 종료 단계 : Cipher Suite 변경하고 핸드셰이크 프로토콜 종료

(나) 단계별 세부 내용

Hello_request

client_hello

server_hello

certificate

server_key_exchange

certificate_request

server_hello_done

certificate_verify

client_key_exchange

finished

완전은 10단계이고 재사용할 때는 단축 협상(abbreviate Handshake) 6단계를 한다.

client_hello

serverhello

changeCipher Spec

finished

changeCipher Spec

finished

4) Record 프로토콜

: 적용/변경된 보안 파라미터를 이용하여 실제 암호화/복호화, 무결성 보호, 압축/압축해제 등의 기능을 제공하는 프로토콜

- 신뢰하는 전송 서비스를 필요로 하므로 TCP 프로토콜을 사용한다.

기밀성 - 핸드셰이크 프로토콜은 TLS 페이로드를 관용 암호화 하는데 쓸 공유 비밀키를 정의한다.
메시지 무결성 - 핸드셰이크 프로토콜은 또한 메시지 인증 코드(MAC)를 생성하는데 사용할 공유 비밀키를 정의한다

MAC(재전송 공격) : SSL/TLS 레코드 프로토콜은 동일한 메시지를 클라이언트 또는 서버가 두번 받는 것을 막기 위하여 시퀸스 넘버를 이용하여 MAC 값을 생성하는 방법을 이용한다.

5)ChangeCipherSpec프로토콜

6) Alert 프로토콜

7) 하트비트 프로토콜

: 정상적으로 동작한다는 걸 나타내기 위해서 또는 시스템의 다른 부분과 동기화를 하기 위해서 h/w나 s/w가 생성하는 주기적 신호

클라이언트와 서버 간의 연결 상태 체크를 위한 OpenSSL 확장 모듈

8) SSL/TLS 공격

(가)OpenSSL의 하트비트 취약점(2014/4)

: openSSL 암호화 라이브러리의 하트비트라는 확장 모듈에서 클라이언트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아 시스템 메모리에 저장된 64kb 크기의 데이터를 외부에서 아무런 제한 없이 탈취할 수 있는 취약점.

- 이는 원격에서 발생 가능한 취약점으로 공격자는 메시지 길이 정보가 변조된 하트비트 request 패킷을 취약한 OpenSSL 버전을 사용하는 서버에 전송할 겨우, 정해진 버퍼 밖의 데이터를 공격자에게 전송하게 되어 시스템 메모리에 저장된 개인정보 및 인증 정보 등을 탈취할 수 있다.

노출 가능한 정보 : SSL 서버 비밀키, 세션키, 쿠키 및 개인정보 등..

대응책 :하트블리드 취약점 대책이 실행된 버전으로 OpenSSL 갱신, 하트비트 확장을 사용하지 않는 옵션을 부착해 재컴파일 하는 등의 조치 필요

SSL/TLS 개인키가 유출될었을 가능성이 있어 인증서 재발급 및 비밀번호 재설정

(나) SSL 3.0 취약점과 Poodls 공격

: 조건하의 통신에서 공격자가 TLS를 SSL3.0으로 다운그레이드 할 수 있다. TLS를 사용해도 SSL 3.0을 사용하게 된다.

- Poodle 공격으로 SSLv3.0을 사용하도록 강제한 후 MITM 공격을 통해 암호화되어 송수신되는 쿠키 정보나 데이터를 추출하는 공격이 가능하다.

또한 블록 암호화 기법인 CBC 모드를 사용하는 경우 발생하는 패딩된 암호블록이 MAC에 의해 보호되지 않는 취약점을 이용

POODLE(Padding Oracle On Downgrade Legacy Encryption) 대응책 : SSL 3.0을 사용하지 않는것

(다) FREAK(Factoring RSA Export Keys) 공격과 암호 수출 규제(2015/02)

[수출용 RSA 키의 소인수 분해] : 프랑스 국립 연구소(INRIA) 및 MS사에서 SSL을 통해 강제로 취약한 RSA로 다운그레이드 시킬 수 있는 취약점을 발견

SSL/TLS 서버에 대한 RSA Export Suites라고 불리는 약한 암호 스위트(suite)를사용하게 하는 공격이다.(MITM 공격을 통해 512비트 RSA로 다운그레이드 시켜 정보 유출)

대응책 : 서버 운영자는 해당 취약점에 영향을 받는 OpenSSL 버전 사용 시 최신 버전으로 업그레이드하고 사용자는 취약점에 영향을 받는 OS 및 브라우저는 업그레이드가 필요하다.

(라)완전 순방향 비밀성(PFS, Perfect Forward Secrecy)

- SSL/TLS 통신의 서버 개인키 노출시 문제점

서버 공개키와 개인키를 이용하여 키 교환을 수행할 경우(RSA 방식) 공격자는 중간자 공격(MITM: Man In The Middle)을 통해 트래픽을 가로채고 서버 개인키를 이용해 세션키/비밀키 및 송수신 데이터를 복호화할 수 있다.
희생자는 유출된 서버 인증서를 폐기해도(CRL 또는 OCSP 프로토콜을 통해) 유출된 서버 개인키로 보호되는 이전 트래픽 정보를 공격자가 보관하고 있다면 이들 모두 복호화되는 문제점이 있다.

-> 이러한 문제를 해결하고자 순방향 비밀성(FS) 또는 완전 순방향 비밀성(PFS)가 나타남

- 완전 순방향 비밀성

: 서버 개인키가 노출되어도 이전 트래픽 정보의 기밀성은 그대로 유지되는(과거의 세션키가 노출되지 않는) 암호학적 성질을 말한다.

(3) HTTPS와 S-HTTP

1)HTTPS

- 웹브라우저와 웹서버 간의 안전통신을 구현하기 위한 HTTP와 SSL의 결합이다.

http 80번 / https 443번

- http를 사용하면 다음과 같은 통신요소가 암호화된다.

요청 문서 URL
문서 내용
브라우저 양식 내용
브라우저가 서버에게 보낸 쿠키와 서버가 브라우저로 보낸 쿠키
HTTP 헤더 내용

- 공격자가 중간에서 스니핑을 하기 어렵게 만들어 주지만 웹 애플리케이션 해킹의 주요 원인인 사용자 입력값에 대한 검증은 하지 못한다.

2)S-HTTP

: EIT(Enterprise Integration Technologies)에 의해 추가된 보안기능으로 두 컴퓨터 사이에 보내지는 각 메시지를 보호하는 기술

(나)원리

일반 HTTP 메시지는 요구되는 보안 기능 정도에 따라 암호화되거나 서명되어 S-HTTP 메시지 내로 캡슐화된다. S-HTTP 메시지는 메시지의 형식과 부호화 방식 등을 표시해 주는 헤더와 함께 전달된다.

- S-HTTP와 HTTPS의 차이

S-HTTP는 HTTP 메시지가 암호화 및 서명되어 기존 TCP/IP 망을 통해 전송된다

(다)동작

HTTP 트랜잭션의 형태를 유지하고 있기 때문에 기존 특성을 유지

여러 가지 암호 지원

협상 과정을 통해 다양한 암호 알고리즘, 모드, 매개 변수 등을 설정할 수 있다.

새로운 프로토콜 지시자로 [shttp~]를 사용한다.

4. 웹서버 보안

(1) IIS 보안 설정

1) 권한 설정

: 특정 자원(폴더, 파일..)에 대해서 읽기, 쓰기, 삭제, 실행 등의 기능을 필요에 따라 부여/회수하는 것을 권한 설정이라고 한다.

2) 관리자 페이지 접근통제

: 웹 애플리케이션의 관리자 페이지가 추측 가능한 형태로 구성되어 있을 경우 공격자가 관리자 페이지를 쉽게 접근할 수 있으며, 무작위 대입 공격(Brute force attack)을 통해 관리자 권한을 획득할 수 있는 취약점이다.

- 웹 서버/페이지 등에 접근하는 사용자를 IP 주소 등을 통해서 통제한다.

3)메소드 제한

사용자에서 서버로 요청값을 보낼 때 포함되는 일종의 명령어로 페이지 요청(Get, put), 페이지 삭제 요청(delete), 헤더값 요청(head), 옵션값(options) 요청 등의 메소드를 제한

get, post를 제외하고 불필요한 메소드 제거

4) 헤더 정보 숨김

사용자 요청에 의해서 서버가 응답을 보낼 때 헤더에 포함되는 정보로, 기본값으로 설정하게 되면 서버에 대한 정보가 포함되어 사용자 쪽으로 전송된다.

서버에 대한 정보등이 포함되므로 공격자가 해당 서버에 공격을 시도할 때 정보로 이용될 수 있다.

(2) Apache 보안 설정

1) 서버 실행 계정 확인

아파치가 root권한으로 실행되는 경우가 많아 nobody 계정을 만들어 아파치 웹 프로세스의 권한으로 할당하였다.

2) httpd.conf 파일(아파치)

ServerType(standalone) :

Timeout

KeepAlive

MaxKeepAliveRequest

KeepAliveTimeout

MinSpareServers

MaxSpareServers

MaxClients

MaxRequestPerChild

User

Port

ServerAdmin

ServerName

DocumentRoot

Options

ErrorLog(/usr/local/apache/logs/error_log)

LogLevel

ServerSignature

ServerTokens

3) 검색엔진 정보 노출 취약점

: 검색엔진에 의해 웹 사이트 해킹에 필요한 정보가 검색되는 취약점이다.

로봇배제펴준은 검색로봇에 대한 웹사이트의 디렉터리 및 파일들에 대한 검색조건을 명시해놓은 국제규약으로 접근제한에 대한 설정을 roboots.txt 파일에 기술한다.

설정방법

반드시 웹사이트의 최상위주소에 저장해야한다. 하위에 둘시 효력없음

5. 웹 보안위협 및 대응책[OWASP top10]

(1)웹 서비스 공격 owasp 10

A1 - Injection

SQL, OS, NoSQL, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분이 인터프리터로 보내질 때 발생한다.

A2 - Broken Authentication

인증과 세션관리와 관련된 애플리케이션으 ㅣ비정상적인 동작으로 인해 패스워드, 키, 세션 토큰 및 사용자 도용과 같은 취약점을 발생시킨다.

A3 - Sensitive Data Exposure

대부분의 웹 애플리케이션과 API는 금융정보, 건강정보, 개인식별정보와 같은 민감정보를 제대로 보호하지 않기 때문에 개인정보 유출과 같은 취약점이 발생하고 있다. 브라우저에서 중요 데이터를 저장 또는 전송할 때 주의해야 한다.

A4 - XML External Entities(xxe)

오래되거나 설정이 미흡한 XML 프로세서는 XML 문서 내에서 외부 개체 참조(external entity references)를 평가한다. 외부 개체는 파일 URL 핸들러, 내부 파일 공유, 포트 검색, 원격 코드 실행 및 서비스 거부 공격을 사용하여내부 파일을 노출시키는데 사용될 수 있다.

A5 - Broken Access Control

인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되지 않은 경우에 발생한다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 액세스하거나 중요한 파일을 보거나 다른 사용자의 데이터를 수정하고 접근 권한을 변경하는 등의 작업을 수행한다.

A6 - Security Misconfiguration

보안 설정 오류

A7 - Cross Site Scripting(XSS)

신뢰할 수 없는 외부값을 적절한 검증 없이 웹 브라우저로 전송하는 경우 발생되는 취약점

A8 - Insecure Deserialization(불안전한 역직렬화)

불안전한 역직렬화는 종종 원격코드 실행의 결과를 만들어 낸다. 역직렬화의 약점이 원격콛 실행의 결과를 못 만들더라도 재생, 인젝션 권한상승 공격을 수행하는데 사용될 수 있다.

A9 - Using Components with Known Vulnerabilities

취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다. 알려진 취약점이 있는 구성 요소를 사용하는 애플리케이션과 API는 애플리케이션을 약화시키고 다양한 공격과 영향을 줄 수 있다.

A10 - Insufficient Logging & Monitoring

불충분한 로깅 및 모니터링은 사고 대응의 누락 또느 ㄴ비효율적인 통합과 함께 공격자가 시스템을 더 공격할 수 있다.

(2)주요 웹 보안위협 및 대응책

1) SQL Injection

: DB와 연동된 웹 응용프로그램에서 입력된 데이터에 대한 유효성 검증을 하지 않을 경우 공격자가 입력 폼 및 URL 입력란에 SQL 문을 삽입하여 DB로부터 정보를 열람하거나 조작할 수 있는 취약점이다.

- 취약점 판단 방법

검색어 필드 및 로그인 필드에 큰 따옴표, 작은 따옴표, 세미콜론을 입력하여 DB에러가 발생하는지 확인한다.

SQL문에서 where로 입력되는 조건문을 항상 참으로 만들수 있는 방법을 사용한다.

'or 1=1#

- 공격 종류

Form SQL 인젝션

: HTML form 기반 인증을 담당하는 애플리케이션의 취약점이 있는 경우 사용자 인증을 위한 쿼리문의 조건을 임의로 조작하여 인증을 우회하는 기법이다.

쿼리문의 조건절(where)을 항상 참이 되게 쿼리문을 조작

Union SQL 인젝션

union select 쿼리를 이용하여 한 쿼리의 결과를 다른 쿼리의 결과에 결합하여 공격하는 기법이다.

union은 2개 이상의 select 문을 결합하고자 할 때 사용하며, 각각의 select문의 필드 갯수가 같아야 하며 필드 타입이 호환 가능해야 한다.

Error-Based SQL 인젝션

: DB 쿼리에 대한 에러값을 기반으로 한 단계씩 점진적으로 DB 정보를 획득할 수 있는 방법이다.

클라이언트에서 조작할 수 있는 파라미터에 SQL Query 관련 특수문자를 삽입하여 SQL에러가 발생한다면 해당 취약점이 있다고 판단할 수 있다.

Blind SQL 인젝션

: 쿼리 결과의 참과 거짓을 통해 의도하지 않은 SQL문을 실행함으로써 데이터베이스를 비정상적으로 공격하는 기법이다.

단순하게 오류 메시지를 자세하게 반환하지 않게 설정해 놓았다면 Error-Based sql injection은 피할 수 있지만 Blind SQL 인젝션에 취약

(라) 대응 방법

- 입력값 검증 절차 문제에 기인하므로 개발 단계에서부터 반드시 모든 입력값에 대해 적절한 검증절차를 설계하고 구현해야 한다.

- sql 서버의 에러 메시지를 표시하지 않는다.

- 애플리케이션에서 DB연결을 통해 데이터를 처리하는 경우 최소 권한이 설정된 계정을 사용해야 한다.

- 외부 입력값이 삽입되는 sql 쿼리문을 동적으로 생성해서 실행하지 않도록 해야 한다.

동적 sql 완성 방식은 변수의 입력값을 연결시켜 sql문을 완성(concatenation of sql)시키는 형태이므로 공격자의 sql문 주입이 매우 용이하므로 사용을 지양

외부 입력값을 이용해 동적으로 sql 쿼리문을 생성해야 하는 경우, 입력값에 대한 검증을 수행한 뒤 사용해야 한다.

- 선처리 질의문(Prepared Statement)을 이용하면 SQL 쿼리문을 선처리하여 이후 입력되는 변수 값을 항상 문자열 변수로 다루기 때문에 사용자가 어떤 악의적인 sql 구문을 변수 값에 삽입하더라도 sql문에 영향을 미치지 않아 sql 인젝션이 발생하지 않는다.

선처리 질의문 : 외부로부터 입력 값을 제외한 쿼리 부분을 미리 컴파일 한 후 반복적으로 입력값만을 설정해서 실행하는 방식으로 성능상의 장점과 더불어 쿼리문 자체는 미리 컴파일되어 입력값에 의해 영향을 받지 않으므로 SQL 인젝션 공격을 방어하는 효과가 있다.

2)사이트 간 스크립팅(XSS)

: 웹 애플리케이션에서 사용자 입력값에 대한 필터링이 제대로 이뤄지지 않을 경우, 공격자가 입력이 가능한 폼(웹 브라우저 URL 또는 게시판 등)에 악의적인 스크립트(javascript, ActiceX, VBScript, Flash 등으로 주로 작성)를 삽입, 해당 스크립트가 희생자 측에서 동작하도록 하여 악의적인 행위를 수행하는 공격 방법이다.

- 공격자는 취약점을 이용하여 사용자의 개인정보 및 쿠키정보 탈취, 악성코드 감염, 웹 페이지 변조 등의 공격을 수행한다.

xss공격은 웹 브라우저가 다운로드한 HTML 문서를 출력할 때에 HTML 문서 속의 javascript 코드가 실행되는 것과 같이 악성코드가 사용자의 실행 행위 없이 자동으로 실행된다는 면에서 매우 위협적이며, 서버가 아닌 클라이언트 컴퓨터를 공격한다.

(나) XSS 공격 종류

Stored XSS(저장형)

: 가장 일반적인 xss로 단순히 게시판 또는 자료실과 같이 사용자가 글을 저장할 수 있는 부분에 정상적인 평문이 아닌 스크립트 코드를 입력하는 방법

- 다른 사용자가 게시물을 열람하는 순간 공격자가 HTML 페이지에 입력해 둔 악성 스크립트가 접속자의 권한으로 실행되어 일반 사용자는 자신의 쿠키정보가 유출되거나 악성 스크립트가 기획한 공격에 속수무책으로 당하게 된다.

- 공격 과정(공격자 글 작성 -> 웹서버에 저장 -> 희생자가 요청 -> 스크립트문 실행)

Reflected XSS(반사형)

: 사용자가 악성 스크립트 코드가 인자 형태로 포함된 URL을 클릭할 때 악성 스크립트 코드가 서버 사이트에 의해 HTML 문서로 반사되어 웹 브라우저에서 실행된다.

공격 스크립트가 포함된 URL을 그대로 전달하면 금방 드러날 수 있기 때문에 공격 스크립트 부분은 주로 인코딩을 한 후 전달하여 사용자가 쉽게 눈치 채지 못하도록 만들다.

- 공격 과정(공격자 -> 희생자 -> 서버 -> 서버가 희생자에게 반환 -> 공격자 서버)

1. 공격자가 다음과 같이 조작된 URL을 공격 대상자에게 이메일로 제공

[http://~.com/?q=<script>alert(test)</script>&x=0..]

2. 공격자에 의해 조작된 URL의 매개변수(스크립트 코드)는 서버 사이트에 해석될 수 없고 서버 사이트는 오류 발생 사유를 전달하기 위해 오류를 발생시킨 스크립트 코드가 포함된 HRML문서를 응답하게 된다.

3. 결론적으로 공격자가 희생자를 통해 URL에 입력한 악성 스크립트 코드는 서버 사이트에서 공격 대상자에게 반사(Reflect)된다.

4. 희생자에게 반사된 악성 스크립트 코드가 실행되어 공격하는 과정은 저장형 xss와 동일.

장점으로 서버 사이트에 악성 스크립트 코드를 남기지 않아도 된다.

DOM based XSS(DOM, Document Object Model 기반)

: HTML 및 XML 문서에 접근방법을 표준으로 정의하는 문서객체 모델이다. DOM은 HTML 문서를 계층적으로 보면서 콘텐츠를 동적으로 변경할 수 있다.

피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 공격 스크립트가 DOM 생성의 일부로 실행되면서 공격한다.

(다) 보안 대책

- 일반적인 경우에는 사용자가 문자열에 스크립트를 사용하는 것을 막기 위해 사용자가 입력한 문자열의 <, >, &, " 등을 문자 변환 함수나 메소드를 사용하여 &lt, &gt, &amp, &quot로 치환한다.

- 사용자 입력값에 대한 검증은 반드시 서버단에서 해야 한다. 클라이언트단에서 검증을 수행하더라도(자바 스크립트 등을 이용한 입력값 검증) 이는 공격자가 웹프락시 툴을 이용해 쉽게 우회 가능하기 때문에 서버단에서 추가적인 검증이 필요

- HTML태그를 허용하는 게시판에서는 지원하는 HTML 태그의 리스트를 선정한 후, 해당 태그만 허용하는 방식을 적용한다.

(라) 코드 예제

1. 파라미터(name)에 script문과 같은 스크립트 코드가 입력되고, 이 값이 그대ㄹ 사용되면 공격자에게 피해자의 쿠키정보가 전송될 수 있다.

String name = request.getParameter("");

2.외부 입력 문자열에서 replaceAll() 메소드를 사용하여 <, >, & 등 과 같이 스크립트 생성에 사용되는 문자열을 &lt, &gt, &amp, &quot로 변경하면 name에 악성코드가 포함되더라도 스크립트가 실행되지 않는다.

String name = request.getParameter("name");

if(name!=null)

{

name = name.replaceAll("<", "&lt");

name = name.replaceAll(">", "&gt");

name = name.replaceAll("<", "&amp");

}

3) 사이트 간 요청 위조(CSRF, Cross Site Request Forgery)

: 공격잔는 세션 탈취, xss 등을 통해 공격자가 의도한 행위(수정, 삭제, 등록 등)를 사이트가 신뢰하는 인증된 사용자의 권한을 통해 실행하게 하는 취약점이다.

웹 응용프로그램에 요청을 전달할 경우, 해당 요청의 적법성을 입증하기 위하여 전달되는 값이 고정되어 있고 이러한 자료가 GET 방식으로 전달된다면 공격자가 이를 쉽게 알아내어 원하는 요청을 보냄으로써 위험한 작업을 요청할 수 있게 된다.

- XSS vs CSRF

xss는 악성 스크립트가 클라이언트에서 실행되는 데 반해 CSRF 공격은 사용자가 악성 스크립트를 서버에 요청한다는 점에서 차이가 있다.

On-Site 요청 변조와 Cross-Site 요청 변조

요청 변조(Request Forgery)는 공격자가 입력한 스크립트를 웹 사이트 방문자가 실행함으로써 해당 방문자의 권한으로 스크립트가 실행되도록 만드는 방식이다.[on-site와 cross-site로 나뉜다]

On-site : 한 사이트내에서 요청 변조가 발생하는 취약점이며, Cross-Site(=CSRF) : 웹 사이트에 악성 스크립트를 입력한 후 해당 사이트에 방문하는 사용자가 악성 스크립트에 의해 특정 행동을 하도록 만든다.

(나) 공격 과정

공격자는 사용자가 인증한 세션이 특정 동작을 수행하여도 계속 유지되어 정상적인 요청과 비정상적인 요청을 구분하지 못하는 점을 악용한다.

웹 응용 프로그램에 요청을 전달할 경우, 해당 요청의 적법성을 입증하기 위하여 전달되는 값이 고정되어 있고 이런 자료가 GET 방식으로 전달된다면 공격자가 이를 쉽게 알아내어 원하는 요청을 보냄으로써 위험한 작업을 요청할 수 있게 된다.

1. [공지사항] 로그인 후 꼭 읽어보세요. -> 같은 문구로 희생자를 유인

안의 내용은 <iframe src="changePw.jsp?newPw=123">으로 비밀번호를 바꾸는 스크립트가 들어있다.

2. 희생자가 악성코드인지 모르고 CSRF 공격 코드가 포함된 [공지사항]의 페이지를 서버에 자동으로 요청[changePw.jsp?newPw=123"]

3. 자동화된 요청이 포함된 응답이 희생자에게 전달된다.

(다) 보안 대책

- 시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지, 아닌지 여부를 판별할 수 있도록 해야 한다.

CSRF 토큰 사용 : 해당 요청이 정상적인 사용자의 정상적인 절차에 의한 요청인지 구분하기 위해 세션별로 CSRF 토큰을 생성하여 세션에 저장하고 사용자가 작업 페이지를 요청할 때마다 hidden 값으로 클라이언트에게 토큰을 전달한 뒤 해당 클라이언트의 데이터처리 요청 시 전달되는 CSRF 토큰값을 체크하여 요청의 유효성을 검사한다.

사용자와 상호 처리 기능 적용 : CSRF 토큰 방식도 XSS 취약점이 있는 사이트를 통해 공격하면 무력화 될 수 있어 CAPTCHA와 같은 사용자와 상호 처리 가능한 기법을 적용하여 위조된 요청이 차단될 수 있다.

CAPTCHA : 사용자 인증 방법으로 자동 계정 생성 방지 기술은 사람은 풀 수 있지만 기계적인 프로그램은 쉽게 풀지 못하는 인지적 단계의 퍼즐을 제공하는 방식

재인증 요구

(라) 코드 예제

- get 방식은 폼 데이터를 URL 뒤에 덧붙여서 전송하기 때문에 GET 방식의 폼을 사용하면 전달 값이 노출된다.

예

</form>

-> post방식을 사용하여 위협을 최소화한다.

</form>

4) 직접 객체 참조[파일 다운로드, 파일 업로드, 리버스 텔넷]

: 파일, 디렉터리, DB 키와 같이 내부적으로 구현된 객체에 대한 참조가 노출될 때 발생한다.

- 접근 통제에 의한 확인이나 다른 보호 조치가 없다면 공격자는 권한 없는 데이터에 접근하기 위해 노출된 참조를 조작할 수 있다.

(나) 디렉토리 탐색 공격(파일 다운로드 취약점)

: 외부 입력값에 대해 경로 조작에 사용될 수 있는 문자를필터링하지 않으면, 예상 밖의 접근제한 영역에 대한 경로 문자열 구성이 가능해져 시스템 정보누출, 서비스 장애 등을 유발할 수 있는 취약점이다.

디렉터리 탐색(Directory Traversal) : 여기저기로 이동한다는 의미로 허가되지 않은 디렉터리나 파일을 경로를 이동하면서 접근하는 공격이다. 보통 확인 가능한 경로의 상위로 타맥하여 특정 시스템 파일을 다운로드한다. -> .../../../

(다) 파일 업로드 제한 부재

클라이언트에서 서버 측으로 임의의 파일을 보낼 수 있다는 것은 웹 서버가 가질 수 있는 가장 치명적인 취약점이다.

공격자는 웹 서버에 악의적인 파일을 전송하고 원격지에서 해당 파일을 실행하여 웹 서버를 장악하며 추가적인 내부 침투 공격을 수행할 수 있기 때문

- 이런 취약점이 존재하는 가장 일반적인 형태는 게시판이다. 게시판에 첨부파일로 악의적인 파일을 업로드하고 실행시킨다. 주로 웹셸

웹셸 : 악의적인 목적의 서버 스크립트 파일(JSP, PHP, ASP 등)이 웹 서버에 명령을 실행하여 관리자 권한을 획득해 행하는 공격방법으로

웹 애플리케이션의 첨부 파일에 대한 부적절한 신뢰와 불충분한 점검으로 인해 악의적인 원격 공격 코드가 웹 서버로 전송, 실행되는 방법으로 관리자 권한을 획득한 후 웹 페이지 소스 코드 열람은 물론 서버 내 자료 유출, 비밀 프로그램 설치 등의 공격을 한다.

- 동작

1. 파일 업로드 취약점이 존재하는 페이지를 통해 웹쉘 파일을 업로드한다.

[업로드된 웹셸 파일을 외부에서 직접 접근이 가능한 경로에 저장한다.]

2. 업로드한 웹쉘 파일을 호출한다.

3. 업로드한 웹셸을 이용하여 시스템 명령을 전송한다.

(라) 리버스 텔넷(리버스 셸, Reverse Shell)

: 웹 해킹을 통해 시스템의 권한을 획득한 후 해당 시스템에 텔넷과 같이 직접 명령을 입력하고 확인할 수 있는 셸을 획득하기 위한 방법.

방봐벽이 존재하는 시스템을 공격할 때 자주 사용

- 일반적으로 웹 서버는 방화벽 내부에 존재하는데 웹 서버는 80번 포트를 이용한 웹 서비스만 제공하면 되기 때문에 방화벽은 외부 인터넷을 사용하는 사용자에 대해 80번 포트만을 허용한다.

방화벽에서 인바운드 정책(외부에서 방화벽 내부로 들어오는 패킷에 대한 정책)은 80번 포트 외에 필요한 포트만 빼고 다 막아 놓지만, 아웃 바운드 정책(내부에서 외부로 나갈때에 대한 정책)은 별다른 필터링을 수행하지 않은 경우가 많다. 리버스 텔넷은 이런 허점을 악용한다.

(마) 보안 대책

- 업로드 되어 저장되는 파일의 크기, 개수, 타입, 실행권한을 제한해야 한다.

업로드 파일의 크기 제한
파일의 타입 제한
업로드되어 저장되는 파일의 실행권한 제거

- 업로드되어 저장되는 파일은 외부에서 식별되지 않아야 한다.

업로드되는 파일의 저장경로는 외부에서 직접 접근이 불가능한 경로 사용
업로드되어 저장되는 파일의 파일명은 랜덤하게 생성하여 사용

- 파일 다운로드 요청 시, 요청파일명에 대한 검증 작업을 수행해야 한다.

파일 다운로드를 위해 요청되는 파일명에 경로를 조작하는 문자가 포함되어 있는지 점검
허가된 사용자의 허가된 안전한 파일명에 경로를 조작하는 문자가 포함되어 있는지 점검
사용자의 요청에 의해 서버에 존재하는 파일이 참조되는 경우 화이트리스트 정책으로 접근 통제

- 다운로드 받은 소스코드나 실행파일은 무결성 검사를 실행해야 한다.

5) 보안 설정 취약점[디렉터리 리스팅, 백업 및 임시 파일 존재, 주석 처리 미흡]

(가) 디렉토리 리스팅(Drirectory Listing)

: 웹 브라우저에서 웹 서버의 특정 디렉터리를 열면 그 디렉터리에 있는 파일과 목록이 모두 나열되는 것을 말한다.

(나) 백업 및 임시 파일 존재

개발자들이 웹 사이트를 개발하고 백업 파일이나 임시 파일을 삭제하지 않은 채 방치하는 경우

(다) 주석 처리 미흡

일반적으로 프로그램의 주석은 개발자만 볼수 있지만, 웹 애플리케이션의 경우에는 웹 프락시를 통해 이용자도 볼 수 있다.

(3) 웹의 취약점 보완

1)특수문자 필터링

- 웹 해킹의 가장 기본적인 형태 중 하나가 인수 조작인데 인수 조작은 예외적인 실행을 유발시키기 위해서 일반적으로 특수문자를 포함한다. 이런 문자를 필터링 해야 한다.

< xss

> xss

& xss

" xss

? xss

' xss과 sql

- - sql

= sql

; sql

* sql

/ xss, 디렉터리 탐색

2) 서버측 통제 적용

파일 업로드 취약점이나 특수문자 필터링을 수행할 때 주의할 점 - 자바 스크립트와 같은 CSS(Client Side script) 기반의 언어로 필터링을 하면 안된다는 것이다.

CSS기반 언어는 웹 프락실르 통해 웹 브라우저에 전달되기 때문에 변조될 가능성이 있음

따라서,필터링 로직을 ASP, JSP와 같은 SSS(Server Side Script)로 필터링을 수행해야 한다.

3) 지속적인 세션 관리

URL 접근 제한 실패를 막기 위해서 기본적으로 모든 웹 페이지에 세션에 대한 인증을 수행해야 한다.

모든 웹 페이지에 대해 일관성 있는 인증 로직을 적용하려면 기업 단위 또는 웹 사이트 단위에서 표준화를 준수해야 한다.

(4) 웹 방화벽(WAF, Web Application Firewall)

: 일반적 네트워크 방화벽과 달리 웹 애플리케이션을 대상으로 시도되는 해킹을 차단해주는 장비

sql 인젝션, XSS과 같은 공격을 탐지하고 직접적인 웹 공격 대응 이외에도 정보 유출 방지, 부정 로그인 방지, 위변조 방지 등 활용

6. 스프트웨어 개발 보안

1)SW 개발 생명 주기(SDLC, S/w Development Life Cycle)

: s/w의 생성에서 소멸까지의 과정을 단계별로 나눈 것으로 각 단계별 주요활동과 산출물을 통해 프로젝트의 진행방향을 명확하게 파악하고 관리를 용이하게 한다.

일반적으로 정의-개발-유지보수 단계이다.

정의 단계(what - 계획 및 요구분석) = 타당성검토 -> 개발 계획 -> 요구사항 분석

개발단계(how - 설계, 개발, 테스트) = 설계 -> 개발 -> 테스트

유지보수 단계(Change-적응, 예방, 폐기) = 유지보수 -> 폐기

2) 주요 모델

(가) 폭포수 모델

(나)프로토타입

(다)나선형

3) s/w 개발 보안 방법론

: 기존의 개발 방법론이 적용된 프로젝트에서 안전한 s/w를 만들기 위해 요구되는 보안활동들을 적용하는 개발 방법

요구사항 분석 - 요구사항 중 보안 항목 식별, 요구사항 명세서

설계 - 위협원 도축을 위한 위협 모델링, 보안설계 검토 및 보안 설계서 작성, 보안 통제 수립

구현 - 표준 코딩 정의서 및 s/w개발 보안 가이드를 준수해 개발, 소스 코드 보안약점 진단 및 개선

테스트 - 모의침투 테스트 또는 동적 분석을 통한 보안 취약점 진단 및 개선

유지 보수 - 지속적인 개선, 보안 패치

4) s/w 보안약점 유형

입력데이터 검증 및 표현

보안 기능

시간 및 상태

에러처리

코드오류

캡슐화

API 오용

DHCP와 DNS보안

1. 호스트 설정과 호스트 설정 프로토콜

2) 호스트 설정 프로토콜 종류

(가) RARP(Reverse Address Resolution Protocol)

arp는 IP주소를 물리 주소로 매핑, rarp는 물리주소를 ip 주소로 매핑

(나) BOOTP(Bootstrap)

DHCP 이전에 사용하던 것

(다) DHCP

BOOTP 프로토콜의 발전형

3) DHCP(Dynamic Host Configuration Protocol, 동적 호스트 구성)

(가) 개요

: UDP 기반 프로토콜로 서버가 네트워크 클라이언트에게 IP 주소를 실시간으로 부여할 수 있도록 한다.

- 서버-클라이언트 패러다임을 사용하는 응용 계층의 프로그램으로 실질적으로 TCP/IP 의 네트워크 계층을 보조한다.

장점

네트워크 설계 변경이 자유롭다

IP 절약 가능

사용자가 TCP/IP 설정을 따로 해주지 않아도 되므로 용이

단점

브로드캐스트 방식으로 트래픽을 전송하므로 네트워크의 성능저하를 발생시킬 수 있음

호스트 전원만 켜줘도 ip 할당

호스트 수가 많아지면 서버의 과부하가 발생

(나) 동작

1. 새롭게 참가하는 호스트는 트랜잭션-ID 필드가 읨의의 숫자로 지정된 DHCPDISCOVER 메시지를 생성한다.

사용자 데이터그램은 근원지 주소가 0.0.0.0, 목적지 주소가 255.255.255.255인 IP 데이터그램으로 캡슐화된다. 그 이유는 참가하는 호스트는 자신의 주소도 서버의 주소도 모르기 때문

2. DHCP 서버는 참가하는 호스트를 위해 your-ip-address 필드를 제안된 ip 주소로 지정하고 server-ip-address 필드는 서버의 ip 주소를 지정하는 DHCPOFFER 메시지로 응답한다.

3. 참가하는 호스트는 하나 혹은 그 이상의 제안을 받고 그 중 가장 좋은 것을 골라 DHCPREQUEST 메시지를 가장 좋은 제안을 보내온 서버로 전송한다.

4. 마지막으로 선택된 서버는 클라이언트가 요청한 ip 가 유효한 경우 DHCP_ACK 메세지로 클라이언트에게 응답한다. 만약 서버가 그 주소를 받아들일 수 없다면(그 주소가 동시에 다른 호스트에게 제안된 경우) 서버는 DHCP_NACK 메시지를 전송하여 클라이언트가 이 과정을 반복하도록 한다.

DHCP Starvation 공격

: DHCP 서버의 할당 가능한 ip를 모두 소진하게 만들어 ip 할당이 불가능하게 하는 공격이다.

discover 메시지를 서로 다른 MAC 주소로 대량으로 보내게 되면 이에 대한 offer가 올 것이고 여기서 request메시지까지 보낸 후에 실제로 할당만 하지 않는다.

2. DNS(Domain Name System)

(2) 네임 공간

1)도메인

: 도메인 네임 공간의 서브트리이다.

최상위 레벨 도메인

com : 영리를 목적으로 하는 기관

edu : 북미의 4년제 학위 수여기관

gov : 미 정부기관

int : 국제협약에 의해 설립된 기구

net : 네트워킹 회사

mil : 미 군용

org : 비 영리기관

kr : 한국에 할당된 최상위 도메인

2) 네임 서버의 계층

(가) 영역

영역(zone) : 전체 도메인 네임 계층을 하나의 서버에 저장할 수 없기 때문에 여러 서버에 나누게 된다. 서버가 책임을 지거나 권한을 가지는 곳을 영역이라 한다.

- 서버는 영역 파일(zone file)이라는 DB를 가지며 그 도메인 내의 모든 노드 정보를 여기에 보관한다.

(나) zone 파일

zone 파일 : 개별 도메인에 대한 DNS 정보가 설정되어 있는 파일

/etc/named.conf 파일의 directory 지시자에 설정된 디렉터리에 존재해야 하며, 하나의 도메인에 하나의 zone 파일을 만드는게 일반적이다.

- DNS의 Record Type

A(Address)주소 : 32비트 ip 주소를 포함한다.AAAA는 IPv6

NS(Name Server)네임 서버 : DNS 존을 위한 권한 DNS 네임 서버의 네임을 나타낸다.

CNAME(Canonical Name)정규 네임 : 노드의 실제 네임을 가리킫록 정의한 별칭(alias)을 위해 사용. DNS 내부 변경을 숨기는데 주로 이용

SOA(Start of Authority)권한 개시 정보 : 모든 존은 하나의 SOA 레코드를 가져야 한다.

PTR(Pointer)포인터

MX(mail Exchange)메일 교환 : 도메인으로 오는 이메일을 처리하는 위치

TXT(text)문자열 : SPF(발송자 메일 서버 인증) 레코드 정보가 있다.(일반적으로 요청 대비 응답이 크기 때문에 DNS 증폭 DRDoS 공격에 악용)

ANY모든 : 도메인에 대한 모든 레코드의 질의 시에 주로 이용한다.(일반적으로 요청 대비 응답이 크기 때문에 DNS 증폭 DRDoS 공격에 악용)

AXFR(Authoritative Zone Transfer)존 전송 : 존 버전에 상관없이 무조건 존 전송 요청(Full Zone Transfer)한다.

IXFR(Incremental Zone Transfer)존 전송 : 존 버전을 비교햐여 상위 버전일 경우 존 전송 요청(Incremental Zone Transfer)한다.

(다) 루트 서버

: 전체 트리를 영역으로 가지는 서버이다.

보통 도메인에 대한 어떤 정보도 가지지 않으며 자신의 권한을 다른 서버들에게 이양하고 자신은 이러한 섭들에 대한 참조만을 가지게 된다.

13개 있음

(라) 일차 및 이차 서버

- DNS는 일차 서버와 이차 서버 두가지로

일차서버(Primary server)는 자신의 권한을 가지는 영역에 대한 파일을 가진다. 이는 영역 파일에 대한 생성, 관리, 갱신에 대한 책임을 가지며 로컬 디스크에 영역 파일을 저장한다.

- 이차 서버(secondary server) : 다른 서버로부터 영역에 관한 완전한 정보를 수신하여 로컬 디스크에 파일을 저장하는 서버이다.

영역 파일을 생성하지도 갱신도 하지 않는다.

(마) 존 전송(Zone Transfer)

: 원본 존 데이터를 슬레이브가 동기화하는 작업 [53번 포트]

마스터 네임 서버상의 레코드는 아무 때나 갱신할 수 있다. 갱신되면 슬레이브 네임 서버상의 정보 중 일부는 쓸모없는 것이 된다.

정기적으로 갱신해야 한다.

(3) DNS 동작 방식

1) 해석

(가) 해석기(resolver) : 네임서버로 질의를 수행하여 그 결과를 응용 프로그램에 반환해주는 s/w 모듈/라이브러리.

- 주소를 이름으로 매핑하기 원하는 호스트는 해석기라고 불리는 DNS 클라이언트를 호출

해석기는 매핑 요구를 보내기 위해 가장 가까운 DNS 서버에 접속한다.

해석기가 매핑 결과를 수신한 후 제대로 온 것인지 아니면 오류가 난 것인지 확인하기 위해 응답을 해석한 다음 최종적으로 그 결과를 요청한 프로세스에 전달한다.

(나) 재귀적 해석(recursive, 귀환적 해석)

- 클라이언트가 네임 서버에게 재귀적 요청을 보내면 서버는 정보가 있는 경우 그 정보로 응답

해당 정보가 서버에 없는 경우 서버는 실제 클라이언트 대신 스스로 클라이언트가 되어 다른 서버에게 새로운 요청을 보내는 방법으로 답변을 찾아내야 한다.

(다) 반복적 해석(iterative)

클라이언트가 네임 서버에게 반복적 요청을 보내면 서버는 요청에 대한 답변 또는 해당 정보를 가지고 있거나 그 정보에 좀 더 가까운 다른 서버(질의를 해석할 수 있을것 같은 서버)의 네임으로 응답한다.

2) DNS 변환 과정

(가) 1순위 : 캐싱

서버는 자신의 도메인에 있지 않은 이름에 대한 문의를 받을 때마다 서버 IP 주소에 대해 DB에 검색을 요구하는데 이 검색 시간의 감소가 효율을 가져온다. DNS는 이를 위해 캐싱(caching)이라는 절차를 이용한다.

ipconfig/displaydns 명령으로 캐시된 DNS 정보를 볼 수 있다.

ipconfig/flushdns 명령으로 캐시된 DNS 정보를 모두 지울 수 있다.

(나) 2순위 : etc/hosts 파일

이 파일은 도메인/호스트명과 ip 주소 매핑정보를 담고 있는 파일로 네임서버에 질의하기 전에 먼저 참조되는 파일이다.

파밍 등의 공격을 통해 파밍 사이트로 접속하도록 hosts 파일을 변조하는 사례가 자주 보고되며 관리상의 주의가 필요.

hosts.ics파일 : 윈도우에서 인터넷 연결 공유(ICS, Internet Connection Sharing) 기능 사용 시 클라이언트의 IP를 강제로 지정하는 기능을 가진 설정 파일이다.

hosts 파일보다 DNS 질의에 대한 검색 우선순위가 높아 질의 시 먼저 참조되는 특성이 있다. 따라서 파밍 공격에 주의해야 한다.

(다) 3순위 : DNS 서버

Recursive DNS 서버 : 재귀적으로 동일한 작업을 조건이 만족될 때까지 반복적으로 처리한다는 의미다.
Authoritative DNS 서버 : 관리하는/위임받은 도메인을 가지고 있는 네임서버다. 특정 도메인에 대한 정보를 관리하며 해당 도메인에 대한 질의만 응답한다.

(라) DNS 변환 과정의 예

1~17과정

(4) DNS 룩업 유틸리티

순방향(forward DNS lookup)과 역방향(reverse DNS lookup)이 있다.

순방향 : 도메인명을 통해서 IP 주소를 알아내는 질의 / 역방향 : IP 주소를 통해서 도메인 명을 알아내는 질의

2) nslookup유틸리티

nslookup <호스트> [서버] 예) nslookup www.naver.com

3) dig(Domain Information Groper) 유틸리티

nslookup의 대체재

dig[서버] <호스트>[Type-기본은 A유형]

4)host 유틸리티

nslookup의 비대화형 모드에서 수행되는 것과 같은 단순 요청에 쓰인다.

host <호스트>[서버] 예)%host www.naver.com

5)whois 명령어

: 도메인의 등록정보, 네트워크 할당 정보 등을 조회하기 위한 명령어[해당 도메인명이 다른 사람에 의해 사용 중인지 여부를 체크하는 용도로 많이 사용된다.]

3. DNS 보안

(1) DNS 보안 위협

공격자는 사용자가 접속하는 사이트의 이름이나 성질을 살피기 위해 DNS 서버의 응답을 읽어볼 수 있다 -> DNS 메시지의 비밀성을 보장해야 한다.
공격자는 DNS 서버의 응답을 중간에서 읽은 뒤 이를 변경하거나 완전히 새로운 위조 응답을 만들어 공격자가 사용자를 접속시키기 원하는 도메인이나 사이트로 가도록 할 수 있다 -> 메시지 송신자 인증 및 메시지 완전 무결성을 사용해 막을 수 있다.
공격자는 DNS 서버가 붕괴되거나 압박받도록 대량 트래픽 공격(flooding)을 할 수 있다 -> DoS 공격 방지책으로 막을 수 있다.

(2) DNS 스푸핑

: 희생자에게 전달되는 DNS 응답(IP주소)을 조작하거나 DNS 서버의 캐시 정보를 조작하여 희생자가 의도하지 않은 주소로 접속하게 만드는 공격이다.

- 희생자는 정상적인 URL로 접속하지만 실제는 가짜로 만든 사이트로 접속하게 된다.

- 공격방법

스니핑을 이용한 DNS 스푸핑
DNS 캐시 포이즈닝(Cache Poisoning)

2) 스니핑 기반의 DNS Spoofing 공격

: 희생자가 DNS 질의를 수행하면 공격자가 이를 스니핑하고 있다가 정상 응답보다 빠르게 희생자에게 조작된 웹사이트 IP 정보를 담은 DNS 응답을 보내 정상 주소(URL)를 입력해도 조작된 주소로 접속하게 만드는 기법[이후에 오는 정상 응답은 먼저 수신한 응답을 신뢰하는 특성으로 폐기된다(조작된 응답만 희생자에게 보내진다.)]

- 스니핑을 통한 DNS 스푸핑 공격은 상대적으로 멀리 떨어져 있는 DNS 서버보다 공격자가 더 빠르게 조작된 응답을 보내야 공격이 성공하기 때문에 일반적으로 동일 네트워크에서 발생한다.

- 스니핑(sniffing) : 더미 허브에 모두 연결되어 있어 무차별 모드(Promiscuous)로 동작 시 스니핑이 가능하다.

- 대응책

스니핑을 이용하기 때문에 이를 탐지 및 차단하도록 한다
중요한 사이트의 IP 주소에 대해서는 DNS 질의보다 우선순위가 높은 hosts 파일에 등록하여 관리한다..

3) DNS Cache Poisoning 공격

: DNS 서버의 캐시 정보를 조작하는 공격.

- DNS서버는 부하를 막기위해 캐시로 상위 DNS 서버에 빈번하게 반복적 질의를 요청하고 TTL(Time To Live)동안 이를 유지한다.

- 동작

공격자는 공격 대상 DNS 서버에 조작할 도메인 질의를 다수 보낸다.
공격자는 공격 대상 DNS 서버가 반복적 질의를 수행하는 동안에 다수의 조작된 DNS 응답을 보낸다. [공격자가 다수의 응답을 보내는 이유는 공격 대상 DNS 서버가 반복적 질의 시 사용하는 Transcation ID와 출발지 Port(스니핑 환경이면 쉽게 알아낼 수 있다.)를 모르기 때문에 랜덤한 Transcation ID와 목적지 Port를 다수 생성하여 응답한다.]
공격자의 조작된 응답 중 정상 응답보다 먼저 일치하는 응답이 있으면 조작된 주소 정보가 공격 대상 DNS 서버의 캐시에 저장되고 이를 질의하는 사용자는 조작된 주소의 사이트로 접속하게 된다.

- 대응책

1. 네임 서버의 s/w를 최신 버전 상태로 유지해 알려진 취약점 공격을 막는다.

2. 도메일 관리용 DNS 서버(Authoritative 네임서버)는 재귀적 질의(Recursive Query)를 허용하지 않도록 설정하고 제한된 사용자가 사용하는 Recursive DNS 서버라면 해당 사용자로 제한해서 허용토록 한다.

3. DNSSEC(DNS Security Extensions) 기술 활용

IETF에서 만들었고 메시지 송신자 인증과 전자서명 서비스를 사용해 메시지 완전 무결성을 제공
기밀성을 제공하지 않으며 DoS 방지책도 없지만 캐싱 서비스를 통해 이런 공격에 대해 어느 정도까지는 상위 계층 서버를 보호할 수 있다.

4. DNS 서버 보안 설정

1) 네임서버 주요 구성 파일과 디렉터리들

/etc/named.conf : BIND(가장 많이 사용하는 네임서버 솔루션)의 부트파일로서 각종 옵션과 각 도메인들에 대한 zone 파일 정보들을 가지고 있다.
/usr/sbin/named : BIND 데몬 파일
/usr/sbin/named-check.conf : named.conf 파일을 검사하는 유틸리티
/etc/host.conf : resolver의 옵션을 가지고 있는 파일, 즉 host 파일을 먼저 검색할 것인지 아니면 DNS에 의한 쿼리를 먼저 할 것인지의 순서를 정하는 설정이 order 옵션으로 설정되어 있다.
/etc/resolv.conf : 시스템에서 사용할 네임서버의 주소를 가지고 있다.

2)도메인 쿼리 순서 설정 파일(/etc/host.conf)

: 특정 도메인에 대한 IP를 찾고자 할 때 어디에서 먼저 찾을 것인가에 대한 순서를 정해놓은 파일이다.

3) 사용할 네임서버 지정파일(/etc/resolv.conf)

: 서버가 사용할 네임서버를 지정해둔 파일이다.

4) name 설정 파일(/etc/named.conf)

: named 데몬의 설정 파일

데이터베이스 보안

1. DB 개념

1) DB 정의

통합된 데이터(inteegrated data)

저장된 데이터

운영 데이터

공용 데이터

2) 키의 유형

후보키 : 키의 특성인 유일성과 최소성을 만족하는 키를 지칭

슈퍼키 : 유일성을 만족하는 키를 지칭

기본키 : 여러 개의 후보키 중에서 하나를 선정하여 사용하는 것을 지칭

대체키 : 여러 개의 후보키 중에서 기본키로 선정되고 남은 나머지 키를 지칭

외래키 : 어느 한 릴레이션 속성의 집합이 다른 릴레이션에서 기본키로 이용되는 키를 지칭

3) 무결성의 종류(integrity)

키 무결성 : 한 릴레이션에 같은 키값을 가진 tuple이 있어서는 안된다.

개체 무결성 : 기본키에 속해 있는 전체 또는 일부 애트리뷰트가 널 값을 가질 수 없다는 제약 조건으로 키값의 전부 또는 일부가 널이 된다면 튜플을 유일하게 식벽할 수 없게 되어 기본키의 정의를 위반한다.

참조 무결성 : 외래키는 널이거나 참조 릴레이션에 있는 기본키와 같아야 한다. 이때 외래키가 널이라는 것은 아직까지 참조할 튜플을 결정하지 못했다는 뜻이다.

4) 트랜잭션(Transaction)

: 하나의 논리적 기능을 수행하기 위한 작업의 단위이다. 한꺼번에 모두 수행되어야 할 일련의 데이터베이스 연산이다. 병행 제어 및 회복 작업의 논리적 단위다.(LUW : logical Unit of Work)

트랜잭션 ACID 성질

원자성(atomicity) - 트랜잭션 내의 모든 연산은 반드시 한꺼번에 완료되어야 하며 그렇지 못한 경우 한꺼번에 취소되어야 한다.(all or nothing)
일관성(Consistency) - 트랜잭션이 성공적으로 완료되면 일관성 있는 DB 상태로 변환한다.
격리성(Isolation) - 트랜잭션이 실행 중에 있는 연산의 중간 결과는 다른 트랜잭션이 접근 못한다.
영속성(Durability) - 트랜잭션이 일단 그 실행을 성공적으로 완료하면 그 결과는 영속적이다.

2.DB 보안 요구 사항

(1) DB 보안

(2) 보안 위협

1) DB 보안 위협

사용자가 우연히 혹은 의도적으로 데이터에 접근함으로써 발생될 수 있는 정보의 부적절한 유출, 부적절한 데이터 처리와 수정으로부터 야기되는 데이터의 무결성 손상이 있다.

또한, 사용자가 데이터에 접근하거나 자우너을 사용하지 못하도록 하는 DOS가 있다.

(나) 주요 위협

- 애그리게이션(Aggregation, 집성)

개별적인 여러 소스로부터 민감하지 않은 정보를 수집, 조합하여 민감한 정보를 생성
낮은 보안등급의 정보조각을 조합하여 높은 등급의 정보를 알아내는 행위
최근의 데이터마이닝에 관한 관심이 집성에 대한 관심을 불러 일으킴.
추론에 대한 일부 접근 방식은 유효하다고 증명되었지만 집성에 대한 대응책으로는 제안된 것이 거의 없다.

- 추론(inference)

일반적인 데이터로부터 비밀정보를 획득할 수 있는 가능성을 의미
사용자가 통계적인 데이터 값으로부터 개별적인 데이터 항목에 대한 정보를 추ㄱ적하지 못하도록 해야 함.(통제하기 어려운 위협)
추론 대응책 : Polyinstantiation, Partition, Cell suppression, Noise, Perturbation

Polyinstantiation[다중사례화] : 낮은 등급자가레코드 입력 시 높은 등급자가 존재하고 있다는것을 입력 오류를 통해 확인하는 것을 방지하기 위한 방법이다.

(3) 보안 요구사항

부적절한 접근 방지
추론 방지
무결성 보장
운영적 무결성 보장
의미적 무결성 보장
감사 기능
사용자 인증
기밀성 보장

3. DB 보안 통제

(1) DB 보안 제어

- DB 보호는 흐름제어, 추론제어, 접근제어에 대한 보안측정을 통해 이뤄질 수 있다.

+ 비밀 암호화키로 저장 데이터를 암호화하는 암호기법을 첨가하면 권한 사용자만 데이털르 볼수 있어 비밀성을 보장한다.

2) 흐름제어

: 객체 X의 값을 읽어이를 객체 Y에 기록할 때 객체 X와 객체 Y 간에 정보흐름이 발생하게 된다. 임의의 객체에 포함되어 있는 정보가 명시적으로 혹은 암시적으로 보다 낮은 보호수준의 객체로 이동하는 것을 검사하여 접근가능한 객체 간의 정보흐름을 조정하는 것이다.

3) 추론 제어

- 데이터 사용자가 읽은 데이터 항목 X가 X에 대한 함수 f를 적용하는 Y=f(X)인 데이터 Y를 얻기 위해 사용된다면 추론이 발생하게 되는데 추론 제어는 간접적인 데이터 노출로부터 데이터를 보호하기 위한 것이다.

- 사용자가 Y를 유도하기 위해 X를 찾는 채널인 추론채널에는 간접접근 / 상관 데이터 / 미싱 데이터가 있다.

- 추론 제어 방법

비밀 정보의 은폐
모든 사용자에 대한 정보를 유지하며 사용자가 갖고 있는 데이터를 고려하여 질의 허용여부를 결정하는 사용자의 데이터 지식 추적
DB의 사용자에게 부정확한 혹은 일관성이 없는 질의 결과를 제공함으로써 통계적 추론 공격을 방지하는 데이터 위장

4) 접근 제어

: 시스템 객체에 대한 모든 직접적 접근이 보호정책에서 세운 모드와 규칙에 따라 상호 배타적이게 하는 것이 정보시스템에서의 접근제어이다.

DB의 접근 통제는 운영체제의 접근 통제와 유사하나 실질적으로는 보다 복잡하다.

특

운영체제의 객체(파일)는 다른 객체와 관련성이 없어 운영체제 사용자는 하나의 파일을 읽고 다른 파일의 내용을 결정할 수 없다.

DB의 객체는 상호 관련되어 있어 DB 사용자는 하나의 데이터 요소를 읽고서 다른 데이터의 내용을 결정할 수 있으며 객체의 크기도 상이하다.

(2) 추론과 통계적 DB

: DB 보안에 관련해서 추론은 인가된 쿼리 수행과 합법적 응답을 통해 비인가된 정보를 추론하는 것.

(3)DBMS 보안 통제

1) SQL 기반의 접근 통제(GRANT/REVOKE 접근 통제)

2) 뷰 기반의 접근 통제

: 하나 이상의 기본 테이블로부터 유도되어 만들어지는 가상 테이블이다.

실제 존재하지 않고 뷰에 대한 조작 요구 시마다 기본 테이블의 데이터를 이용하여 그 내용을 만든다.실행시간에만 구체화되는 특수한 테이블이다.

3) DBMS 보안 점검 사항

(가) 기본적인 보안 취약점 점검

디폴트 계정, 패스워드 변경
DB 패스워드 규칙 강화
DBA 권한의 제한
보안 패치 적용

(나)추가적인 보안 점검

사용하지 않는 계정 삭제
개발자 IP 접근 제어
제품별 취약점 제거
데이터의 암호화

(4) DB 보안

1) DB 보안과 다중 수준 보안

- DB에 다중 수준 보안을 추가하면 접근 제어 기능 및 DB 자체의 설계 복잡도가 증가한다. 따라서 세분화를 함

전체 DB
개별 테이블(관계)
개별 열(속성)
개별 행(튜플)
개별 요소

2) DB 암호화 방법

- DB의 데이터를 암호화할 수 있는 방식은 일반적으로 컴럼 암호화 방식과 블록 암호화 방식으로 나눌 수 있다.

컬럼 암호화 방식

암,복호화 위치에 따라 Plug-in, API 및 혼합 방식인 하이브리드 방식

블록 암호화 방식

TDE, 파일 암호화 방식

(나) Plug-in(컬럼 암호화 방식)

: 암, 복호화 모듈을 DB서버 내에 설치하고 이곳에서 암,복호화를 수행하는 구조

장단점 : 적용성이 뛰어나지만 암,복호화 시 DB 서버의 CPU를 사용하기 때문에 부하가 발생할 수 있다.

따라서, 트랜잭션 처리량이 많지 않아 성능에 대한 민감성이 낮은 시스템의 경우 저렴한 비용으로 구축 가능

(다) API 방식

: 암, 복호화 모듈을 애플리케이션 서버 내에 설치하고 이곳에서 암,복호화를 수행하는 구조로 애플리케이션의 수정을 동반한다.

따라서 기존에 운영 중인 시스템 보다 차세대 시스템 개발에 전면적인 수정이 가능한 경우 적용하면 효과적이다.

(라) 하이브리드 방식

: plug-in 방식의 단점인 배치 업무의 성능 저하를 보완하기 위해 API 방식을 이용하는 구성.

sql은 API 방식을 이용해 최적의 성능을 보장하도록 하고나머지 대부분은 DB내의 Plug-In 방식을 이용하여 애플리케이션 수정을 최소화 하도록 암,복호화 모듈을 DB 서버와 애플리케이션 서버에 설치한다.

(마) TDE 방식

: DBMS에 추가 기능으로 제공되는 암호화 기능을 이용하여 DB 내부에서 데이터 파잉ㄹ 저장 시 암호화하고, 파일에 저장된 내용을 메모리 영역으로 가져올 때 DBMS에 의해 자동으로 복호화되는 방식.

- DBMS 커널 레벨이서 처리되어 애플리케이션에 대한 수정이 없고 인덱스의 경우 DBMS 자체 인덱스 기능과 연동이 가능하다.

(바) 파일 암호화 방식

: OS 상에서 확인이 가능한 개체인 파일을 암호화하는 방식.

- OS에 대한 의존도가 높으나 파일에 대해 직접적으로 암호화를 수행하므로 DB의 데이터 파일 뿐 아니라 로그파일, 이미지파일, 음성/영상 등의 비정형 데이터에 대한 암호화 적용이 가능하다.

4. DBMS 보안 관리

응용 프로그램을 통해 운영체제의 파일이나 명령을 실행시킬 수 있는 것들 - MS-SQL, xp-cmdshell

xp-cmdshell : DB를 통해 운영체제의 명령을 실행하고, 파일 등에 접근할 수 있도록 MS-SQL 에서 지원하는 확장 저장 프로시저이다.

- MS-SQL 관리자 계정(sa)에 의해 실행되는데 관리자 계정 패스워드가 취약한 경우 문제가 큼

저장 프로시저의 역할(stored Procedure)

: 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합으로 일반적인 쿼리 문장을 사용하는 것보다 성능상의 이점을 제공받을 수 있다. 일반 쿼리 문장은 길이에 따라 네트워크 전송 시간이 길어지는 반면, 저장 프로시저 이름과 필요한 몇몇 변수만을 DB서버에 전송하면 추가적인 소모를 최소화할 수 있다.

2) 인증

- windows 인증 모드 : 윈도우에 등록된 로그인 계정으로 sql 서버에 별다른 로그인 절차 없이 접속하는 모드

sql 서버가 설치된 해당 시스템 또는 도메인 환경 내부에서 접속하는 경우에 사용하며 서버 인증을 추가로 이용하는 경우 관리 지점이 늘고 도메인 외에서 접근이 가능한 만큼 보안사고의 가능성도 커지기 때문에 필요한 경우가 아니라면 윈도우 인증 방식 사용을 권장한다.[계정 정보 노출 시 보안 취약점]

SQL 서버 기본 인증 모드
DB의 인증 절차를 윈도우 사용자 인증 방법 사용
윈도우 사용자 또는 그룹에 따라 sql 서버에 대한 액세스 부여
DBA가 사용자에게 접근 권한 부여 가능
윈도우 인증 로그인 추적 시 sid 값 사용

- 혼합 인증 모드 : 윈도우 인증을 선택하면 현재 윈도우에 로그인 하고, sql 인증을 선택하면 sql 서버에 별도의 로그인 아이디를 지정하여 로그인함

윈도우 인증과 sql 서버 인증을 혼용하여 사용
sql 서버로 인증된 사용자으 ㅣ사용자 이름과 암호쌍은 sql 서버 내에 유지
표준 윈도우 로그인을 사용할 수 없는 경우 이용

3) 고정 DB의 역할

db_owner
db_accessadmin
db_datareader
db_datawriter
db_ddladmin
db_securityadmin
db_backupoperator
db_denydatareader
db_denydatawriter

전자상거래 보안

1. 전자 상거래의 정보 보호

2) 전자상거래의 보안 공격 유형

인증에 대한 공격 - 네트워크를 통해 접근한 사용자가 적절하지 못한 인증을 통해 다른 사용자로 위장하는 것 ex) 가짜 은행 사이트를 만들어 은행 사용자의 공인인증서 정보를 획득하여 악용하는 사례..
송,수신 부인 공격 - 네트워크를 통해 수행한 인증 및 거래 내역에 대해 부인하는 것
기밀성에 대한 공격 - 네트워크를 통해 전달되는 인증 정보 및 주요 거래 정보가 유출되는 것
무결성에 대한 공격 - 네트워크의 도중에 거래 정보 등이 변조되는 것

3)전자상거래 보안 요구사항

- 원격의 거래 상대를 신뢰하기 어려워 신분 확인 수단이 필요하다.

(2) 전자 화폐

: 디지털 데이터 기반의 사회에서 가상 공간의 동전/지폐의 역할을 수행하는 디지털 데이터로 구성된 화폐이다.

발행 단계 - 지불 단계 - 결제 단계

2) 전자화폐의 요구 조건

- 기본적 요구조건

1. 디지털 정보화(Independence) : 완전하게 디지털 정보만으로 실현되는 것.

컴퓨터를 매개체로 인터넷과 같은 네트워크상에서 사용할 수 있기 위해서 전자화폐는 다른 물리적인 형태에 의존해서는 안 되며 디지털 데이터 자체로서 완벽한 화폐가치를 가져야 한다.

2. 재사용 불가능성(안전성, security) : 복사, 위조 등으로 인한 부정사용을 할 수 없는 것.

3. 익명성(Privacy, Untraceability : 프라이버시 보호, 추적 불가능성) : 이용자의 구매에 관한 프라이버시가 상점이나 은행이 결탁해도 노출되지 않는 것.

전자화폐 사용자의 사생활은 보호되어야 하며 그것은 사용자와 사용자의 구입내용과의 관계가 어느 누구에 의해서도 추적 불가능해야 한다.

4. 오프라인성(Off-line) : 상점에서의 지불시 처리를 오프라인으로 처리할 수 있는 것.

사용자가 상점에 지불 행위를 할 때, 사용자와 상점 사이에서의 거래는 오프라인 방식으로 수행이 이뤄져야 한다. 이는 상점이 사용자의 지불 수행을 하는 호스트에 접속하지 않고서 거래가 이뤄져야 한다는 것을 의미한다.

5. 양도성(Transferability) : 타인에게 양도가 가능한 것

전자화폐를 받은 상점이나 사용자는 다시 해당 전자화폐를 다른 상점이나 제 3의 사용자에게 사용할 수 있어야 한다.

6. 분할 이용 가능성(Divisibility) : 합계 금액이 액면 금액이 될 때까지 분할해서 사용할 수 있는 것.

이런 기능은 기존 화폐에선 볼 수 없는 기능으로 금액의 크기만큼 자유롭게 분할되어 사용될 수 있어야 한다.

7. 부정 사용자의 익명성 취소(Anonymity Revocation of illegal user)

익명성 취소는 익명성 조절 파라미터에 의해 제공되며 선택적으로 익명성을 취소할 수 있다. 즉 어떠한 전자화폐의 익명성은 취소가 되고 어떤 전자화폐는 계속해서 익명성을 유지시킬 수가 있다는 것.

8. 이중사용 방지(Double-spending Unreusability) : 부정한 사용자가 전자화폐를 불법적으로 복사하여 여러 번 반복적으로 사용하는 부정한 행위는 은행에 의해 검출될 수 있어야 한다.

(3) 전자지불 시스템

1) 개요

전자상거래에서 가장 핵심적인 수단인 전자지불 시스템은 은행, 고객, 상점, 인증기관으로 구성

은행 : 전자화폐를 발행하고 결제하는 기관
고객 : 전자화폐를 은행으로부터 발급받아 사용하는 주체
상점 : 상품을 공급하고 전자화폐를 구매대금으로 받는 자
인증 기관 : 신분인증, 거래내용 부인 방지 등을 위한 기관

2) 전자지불 시스템의 종류

(가) 기술적인 분류

신용카드를 이용한 지불

전자화폐를 이용한 지불

계좌이체를 이용한 지불

휴대폰을 이용한 지불

- 모바일 지불 방식에는 휴대폰 번호를 이용한 지불방식과 UIM(User Identity Module)을 이용한 지불방식 등이 있다.

UIM : 이동 전화 가입자 정보를 포함하고 있는 이동 통신용 스마트 카드, 전 지구적 이동 통신 시스템(GSM)의 가입자 정보 모듈(SIM)을 부호 분할 다중 접속(CSMA)에 적용할 수 있도록 변경한 것으로 가입자 정보, 인증, 보안, 로밍 모듈 및 단말기 제어 명령을 저장하고 있다.

(나) 지불브로커의 유,무에 따른 분류

Payment Broker 시스템 : 독립적인 신용구조와는 달리 신용카드나 은행계좌를 이용한 전자적 지불을 말하며 그 종류로는 SET, cyber cash, first virtual 등과 ssl/tls, s-http 등의 보안 프로토콜을 이용한 지불이 있다.

SET : 인터넷과 같은 공개된 네트워크에서 신용카드 거래를 안전하게 하기 위한 표준 프로토콜

퍼스트 버추얼 : 신용카드를 이용한 전자 결제 시스템의 한 유형, 신용카드 번호화 같은 정보를 인터넷으로 전송하지 않고 전자 우편을 통해 소비자의 구매 의사를 확인하는 절차로 구성된 신용카드 모형에 기반을 둔 인터넷 상거래 결제 시스템.

전자화폐 시스템 : 지불 브로커 없이 독립적인 신용구조를 가지는 현금과 유사한 개념의 전자적 지불수단을 말한다. 종류 = Mondex(IC카드형), E-cash(네트워크형), Millicent(소액지불), Proton(선불형)

3)전자지불 시스템의 정보보호 요구사항

1. 위조불가능

2. 부인방지

3. 누명면제

4. 무결성/인증

5. 프라이버시/익명성

6.이 외에도 원자성, 감사, 분할성, 양도성, 효율적 규모, 상호운영성/교환성...

2.SET(Secure Electronic Transaction)

1) 개요

- 신용카드 회사인 비자와 마스터카드가 합동으로 개발했으며 인터넷상에서 신용카드를 이용한 상품구매 시 안전한 대금결제과정 처리를 위해 RSA 암호화와 인증기술을 이용.

전자봉투와 이중 서명 기술 사용

- 목적

정보의 기밀성 확보
지불 정보의 무결성 확보
상인과 고객의 상호 확인

2) SET 참여주체

카드소지자(Cardholder) - 발행사에 의해서 허가된 지불카드를 사용한다.
발행사(Issuer) - 카드 소지자의 계정을 만들어주고 카드를 발급해주는 금융기관
가맹점(Merchant) - 상인은 지불에 대한 대가로 상품과 서비스를 제공한다.
지불 은행(매입사, Acquirer) - 상인과 계정을 체결하고 카드결제에 대한 신뢰성과 지불을 담당하는 금융기관이다.
지불 게이트웨이 - 지불처리 은행 또는 제3자에 의해 운영되는 장치로서 상점이 요청한 카드소지자의 지급 정보를 이용하여 해당 금융기관에 승인 및 결제 요청하는 기준의 카드 지불 네트워크의 통로이다.
인증기관(CA, Certification Authority) - SET 참여자에게 공개키 인증서를 발행하는 기관.

3) 이중서명 프로토콜

(가) 목적

카드 사용자가 구매정보와 지불정보를 각각 해시한 후, 두 해시값을 합한 뒤 다시 해시한다. 그리고 최종 해시값을 카드 사용자의 개인키로 암호화(서명)한다. -> 이중 서명값이 생성됨.

이중 서명의 목적은 상점이 카드 사용자의 계좌번호와 같은 지불정보를 모르게 하는 동시에 상점에 대금을 지불하는 은행은 카드 사용자가 상점에서 산 물건을 모르지만 상점이 요구한 결제 대금이 정확한지 확인할 수 있게 하는 것이다.

(나)상세 절차

1. 우선 카드 사용자는 하나의 비밀키(대칭키)를 생성. 그리고 비밀키로 지불정보를 암호화하고 비밀키는 은행이 운영하는 지불 게이트웨이의 공개키로 암호화한다.

2. 이제 카드 사용자는 결제를 위한 데이터를 모두 생성했다.

[구매정보 / 지불정보[비밀키로 암호화한 지불정보] / 구매정보 해시값 / 지불정보 해시값 / 구매정보와 지불정보의 해시값 / 구매정보와 지불정보의 해시값으로 만든 최종 해시값(사용자의 비밀키로 암호화)]

3. 카드 사용자로부터 위와 같은 정보를 받은 상점은 카드 사용자가 신청한 물건에 대한 구매정보의 해시를 구하고, 카드 사용자가 보내온 한 쌍의 해시값(구매정보와 지불정보의 해시값)을 새로 구한 해시로 대체시킨 뒤 새로운 이중 해시를 구한다.

4. 이 카드 사용자의 개인키로 암호화된 해시값을 복호화하여 새로 구한 이중 해시값과 비교한다. 카드 사용자가 보내온 구매정보가 그 카드 사용자의 것인지 또는 구매정보가 변조되지 않았는지 확인한다.

5. 이렇게 구매정보를 확인한 상점은 다시 데이터 셋을 만들어 지불 게이트웨이로 보낸다.

6. 상점이 지불 게이트웨이로 보내는 데이터는 구매정보만 빼면 최초 카드 사용자가 상점에 전송한 데이터와 같다. 이러한 데이터를 상점에게 받은 지불 게이트웨이는 자신의 개인키로 비밀키를 복호화하여 지불 정보를 확인한다.

7. 그리고 상점이 한 것처럼 받은 지불정보를 해시한 값으로 한 쌍의 해시값을 대치하여 이중 해시값을 비교하고 지불정보의 변조 여부를 확인한 뒤 대금을 지불한다.

4)SET의 장단점

- 장점

전자거래의 사기를 방지한다.
기존의 신용카드 기반을 그대로 활용한다.
SSL의 단점(상인에게 지불정보 노출)을 해결한다.

- 단점

암호 프로토콜이 너무 복잡하다.
RSA 동작은 프로토콜의 속도를 크게 저하시킨다.
카드 소지자에게 전자지값 s/w를 요구한다.
지불 게이트웨이에 거래를 전자적으로 처리하기 위한 별도의 h/w와 s/w를 요구한다.

3. 전자상거래 응용 보안

1) e-business를 위한 ebXML 보안

: 전자상거래 기반 기술을 토대로 특정한 응용분야 기술이 개발되고 있는데 그 중에 하나이다.

이를 통해 인터넷 표준 브라우저만으로 장소에 구애 없이 어디서나 전자상거래를 할 수 있으며 저렴한 구현 비용, 개방된 네트워크로 전자거래 교환을 위한 국제 표준을 제공한다.

2) e-Business를 위한 ebXML

- 구성 요소

비즈니스 프로세스
핵심 컴포넌트
등록 저장소
거래 당사자
전송, 교환 및 패키징

(나) ebxml 효과

1. 재활용성

2. 비즈니스 프로세스 활용

3) 무선 플랜폼에서의 전자상거래 보안

(가)WPKI(Wireless Public Key Infrastructure)

: WAP에서 서버와 클라이언트 간의 인증을 위한 무선 환경에 적합한 인증서를 발급, 운영, 관리하는 무선망의 공개키 기반 구조.

(나) 구성요소

CA 서버 시스템 : 인증서 발급, 관리
RA 서버 시스템 : 인증서 발급, 관리 요청 중계
Client 시스템 : 인증서 발급, 관리 요청
Directory 서버 시스템 : CA가 발행한 인증서 정보를 저장, 관리

침해사고대응

1. 해킹

(1) 개요

: 어떠한 의도이든 상관없이 다른 컴퓨터에 침입하는 모든 행위로 전산망을 통하여 타인의 컴퓨터 시스템에 액세스 권한 없이 무단 침입하여 부당행위[불법적인 시스템 사용, 불법적인 자료열람, 유출 및 변조 등..]를 하는 것.

2) 해커의 분류

(가) 수준별 분류(Gilbert Alaverdian의 5등급 분류)

Elite - 최고 수준의 해커로 시스템에 존재하는 취약점을 찾아내고 그것으로 해킹에 성공하는 자.
Semi Elite - 해킹 흔적을 남겨 추적을 당하기도 한다.
Developed kiddie - 학생들이 대부분으로 여러 번 시도 끝에 시스템 침투에 성공 자랑목적
Script Kiddle - 지식이 부족하여 GUI OS 밖으로 나온적이 없음. 다른 사람이 개발한 프로그램을 쓰는 애들
Lamer - 해커가 되고 싶지만 경험, 기술이 없는 자

(나)기타 해커 관련 용어

white hat : 다른 해커들로부터 공격을 받기 전에 도움을 줄 목적으로 보안상 취약점을 찾아내어 알리는 해커

Black hat : 크래커

gray hat : 중간

(2) 해킹 기법

- 일반적인 해킹 순서

대상 선정 - 취약점 수집 - 취약점 선정 - 취약점 Exploit - 권한 획득 - back door 설치 - 타 시스템 공격 - 침입 log 삭제

APT(Advanced Persistent Threas, 지능형 지속해킹 공격)

: 사용자에게 노출되지 않은 상태에서 지속적으로 대상을 공격해서 정보 수집 및 악의적인 행위를 하는 공격.특정 대상

2. 침해사고 대응과 포렌식

(1) 컴퓨터 침해 대응팀

1) CERT(Computer Emergency Response Team)개요

: 해킹과 바이러스에 대항하는 보안기술을 개발하고 서비스하는 컴퓨터 응급 대응센터다.

2) CERT의 역할

침해 사고 예방/대응 기술연구 및 전파
취약점 진단 및 조치, 모니터링, 교육 등 침해사고 예방 활동
KrCERT/CC 등 외부 기관의 대응협력 활동
침해사고 접수, 분석, 피해복구 등의 침해사고 대응 활동

- 하지 말아야 할 일

개개인에 대한 조사
해결책 없이 취약점 관련정보 전달
승인 없이 사법당국에 정보 전달
관할지역 구성원의 문제를 수정

- cert 구축의 어려운 점

조직 내에서 CERT 필요성에 대한 인지 부족
관련 조직의 협력 부족
기술 인력의 확보

3) 사고대응 7단계 절차

사고 전 준비 과정
사고 탐지
초기 대응
대응 전략 체계화
사고 조사
보고서 작성
복구 및 해결

(2) 디지털 포렌식(Digital Forensics)

1) 개요

: 다양한 디지털 장치에서 범인과 연관된 자료를 발견하고 분석하여 법적인 문제를 해결하는 작업.

- 범죄의 증거를 찾기 위해 컴퓨터, 휴대폰, 이메일, SNS, 웹, CCTV, 블랙박스 등 조사하고 분석

2) 포렌식의 기본 원칙

: 포렌식을 통해서 증거를 획득하고 이 증거가 법적인 효력을 가지려면 그 증거를 발견하고 기록하고 획득하고 보관하는 절차가적절해야 한다.

(나) 기본 원칙

정당성의 원칙 : 모든 증거는 적법한 절차를 거쳐서 획득한 것이어야 하며, 위법한 절차를 거쳐 획득한 증거는 증거 능력이 없다.
재현의 원칙 : 똑같은 환경에서 다른 결과가 나오면 증거로 제시할 수 없고 증거는 어떤 절차를 통해 정제되는 과정을 거칠 수 있다. ex) 시스템에서 삭제된 파일을 복구하는 과정
신속성의 원칙 : 컴퓨터 내부의 정보는 휘발성을 가진 것이 많기 때문에 신속하게 이뤄져야 한다.
연계 보관성의 원칙 : 증거는 획득되고 난 뒤 이송/분석/보관/법정 제출이라는 일련의 과정이 명확해야 하며, 이러한 과정에 대한 추적이 가능해야 한다.[범정 제출의 각 단계를 담당하는 책임자 명시]
무결성의 원칙 : 수집된 정보는 연계 보관성을 만족시켜야 하고 각 단계를 거치는 과정에서 위조 및 변조되어서는 안 되며 매번 확인해야 한다.[하드디스크는 해시값을 구해 각 단계마다 그 값을 확인해 무결성을 입증할 수 있다.]

3) 포렌식 수행 절차

사전 준비 - 전문가를 소집하고 각종 장비, s/w 또는 h/w를 준비하고 점검하는 단계.[툴 테스트, 인력 및 장비 확보, 협조체계 확립, 계획 수립]
증거물 획득(증거 수집) - 불법 행위가 발생한 장소에서 네트워크 시스템 또는 행위자가 사용한 컴퓨터를 압수하여 각종 저장매체로부터 디지털 증거를 획득하는 단계이다.[증거의 무결성이 중요하다.-현장 분석, snapshot, disk imaging, 증거물 인증, 무결성 유지, 저장매체 분리]
보관 및 이송 - 획득된 증거는 연계 보관성을 만족시키며 보관 및 이송되어야 한다. 증거가 연계 보관성을 만족시키려면 우선 안전한 장소에 보관되어야 하는데 안전한 장소(Evidence sage)라고 한다.
조사 및 분석 - 포렌식과 관련해서 증거를 관리할 때는 최량 증거 원칙(The Best Evidence Rule)을 따른다. 최량 증거 원칙 = 복사본 등의 2차적인 증거가 아닌 원본을 제출하도록 요구하는 영미 증거법상의 원칙이다. 획득한 디지털 증거물을 조사하고 분석하는 단계로서 디스크 브라우징, 데이터 뷰, 파일 복구 등 다양한 기법들이 활용되고 있다.[데이터뷰, 디스크 브라우징, 파일 복구]
보고서 작성 - 모든 단계의 내용을 문서화하는 단계

디스크 브라우징 : 저장 매체 또는 디스크 이미지에 존재하는 파일을 GUI 환경에서 쉽고 편리하게 다룰 수 있도록 기억장치에 저장된 이진 데이터를 폴더, 파일 단위로 출력하는 등, 수집한 저장 매체 또는 디스크 이미지 내부에 있는 정보를 가독성 있는 형태로 변환하여 출력하는 기술이다.

데이터 뷰 : 저장 매체나 디스크에 저장된 방대한 파일을 열어서 확인할 수 없기 때문에 브라우징 과정에서 파일을 인식하여 텍스트, 그림 등의 형식으로 볼 수 있도록 하는 자동 뷰 기능을 제공하는 기술이다.

파일 복구 : 복구 s/w를 이용하여 파일 원본을 복구시키는 기술로 파일이 손상 또는 삭제되더라도 디스크 내에는 관련 정보가 보존되어 있기 때문에 파일 복구가 가능하다.

4) 포렌식 기술

디스크 포렌식
시스템 포렌식
네트워크 포렌식
인터넷 포렌식
모바일 포렌식
데이터베이스 포렌식
암호 포렌식

5) 디지털 포렌식 도구

EnCase
FTK

6) 역할

1차 대응자의 역할
수사자의 역할
범죄 현장 기술자의 역할

(3) 증거(Evidence)

1) 증거 규칙(Rules of Evidence)

증거를 수집하고 조사하고 보존하고 제시하는 것은 법적 절차이기 때문에 그 지역의 법을 따라야 한다.

2) 보호관리 사슬(Chain of Custody) = 증거 담당자 목록

: 증거의 연속성으로 수사관은 현장에서 수집된 증거가 법정에 제출될 때까지 거쳐간 경로, 그 증거를 다룬 모든 사람, 증거가 옮겨진 장소와 시간을 추적할 수 있어야 한다.

3) 디지털 증거물 분석

- Timeline 분석(MAC time 분석) : 파일 생성, 변경, 접근, 삭제 시간 등..

mtime : 파일을 생성 및 최근 수정한 시간

atime : 최근 파일을 읽거나 실행시킨 시간

ctime : 파일 속성이 변경된 시간

- 시그니처 분석 : 의도적으로 파일 확장자를 변경해 놓은 파일을 간단히 파악

- Hash 분석 : 시스템 내의 파일이 변경되었는가를 확인

기존에 알려진 파일과 같은 파일이 존재하는가를 확인 : 파일에 대해서 해시값을 계산한 후, 미리 준비된 해시값들과 비교하여 대상 파일을 검색

- 로그 분석 : 웹 브라우저 로그, 메일 로그, FTP 로그 등

- 프로세스 분석 : 현재 수행되고 있는 프로세스의 메모리 내용을 조사, 의심되는 실행 파일 조사

4) 사라지기 쉬운 데이터 보존

: RAM(휘발성 데이터)으로 메모리(랜덤 접근 메모리, 캐시 메모리, 비디오 카드 또는 NIC..)

5) 디지털 증거 보존

증거가 저장된 매체의 완전한 비트스트림 이미지를 만드는 것.

비트스트림 이미지 : 원본 저장 장치에 기록됐던 모든 데이터의 사본.

(4) 디지털 증거 복구

(5) 데이터 복구 기법 피하기(Data Sanitization)

각종 애플리케이션 보안위협 및 대응책

1. 각종 애플리케이션 보안위협 및 대응책

2. 자바 보안

'교육 및 자격증 > 정보보안기사 : 필기' 카테고리의 다른 글

다시보기 (0)	2022.10.06
Part07 - 정보보호 관리 및 법규 (0)	2022.09.01
Part05 - 네트워크 보안 (0)	2022.09.01
Part04 - 시스템 보안 (0)	2022.09.01
Part03 - 접근 통제 (0)	2022.09.01