어플리케이션 기본학습 3~6

DNS 스푸핑Spoofing 공격
개요
- 희생자에게 전달되는 dns 응답을 조작하거나, dns 서버의 캐시정보를 조작하여 희생자가 의도하지 않은 주소로 접속하게 만드는 공격
   - 1. 스니핑을 이용한 DNS 스푸핑
   - 2. DNS 캐시 포이즈닝foisoning
- DNS 질의/응답에 사용하는 UDP 프로토콜의 비연결 특성 취약점을 이용한 공격
- DNS 질의/응답을 식별하기 위한 Transacton ID, 출발지/목적지 주소만 일치하면 먼저 수신한 응답을 신뢰하고 이후 응답을 폐기하는 특성을 이용

(TCP는 스니핑, 세션 하이재킹, 위변조까지 다 해야 하는데 UDP는 비교적 위변조가 쉽다)

스니핑 기반의 DNS 스푸핑 공격
- 희생자, 공격자, 네임서버
- 희생자가 DNS 질의를 수행하고, 공격자가 도청 후 네임서버 응답보다 빠르게 희생자에게 조작된 DNS 응답 전송
- 이후 도착된 네임서버의 정상 DNS 응답은 폐기됨

- 희생자는 조작된 응답을 기반으로 자신의 로컬 DNS 캐시에 저장하고 조작된 주소로 접속하게 된다
(도청 후 패킷 조작 : 스니핑을 위해 희생자와 같은 로컬에 위치해야 하므로, ARP 스푸핑이 선행됨(=ARP Redirect 공격이라고도 함))

(ipconfig /displaydns 명령어 기억하기)

 

대응책
- dns 스푸핑 공격은 기본적으로 스니핑을 이용하므로 이를 탐지 및 차단
- 중요한 사이트의 ip 주소는 dns 질의보다 우선순위가 높은 hosts 파일에 등록하여 관리

(dns 캐시정보가 우선순위가 높지만, 사용자가 조작할 수 없음. 캐시정보는 dns 응답을 받고 자동으로 등록되는 것임)

 

실습

1. arp 스푸핑 공격
=> fragrouter -B1                                                                          (ip forwarding 기능 활성화)
=> arpspoof -i eth0 -t 192.168.희생자.IP 192.168.gate.way    (gateway mac주소를 공격자의 MAC주소로 위조)
=> arpspoof -i eth0 -t 192.168.gate.way 192.168.희생자.IP    (gateway에, 희생자 mac주소가 공격자 mac주소라고 위조)
주고받는 패킷을 볼 수 있는 상태가 마련됨

2. DNS 스푸핑
=> dnsspoof -i eth0 -f dnsspoof.txt                                   (dnsspoof도구이용. dnsspoof.txt에 조작한 주소 정보가 담겨있음)
(희생자 pc에서 ipconfig /flushdns 명령어로 dns 캐시 정보 다 지워놓고 시작)
(패킷 덤프 뜰 때 promiscuous 모드는 끄고 패킷 보기)
=> 희생자가 목표 ip주소에 접속하면, dnsspoofing 되어 조작한 주소, 피싱사이트로 접속됨
=> ipconfig /displaydns 캐시정보에서도 확인 가능

 

 

DNS Cache Poisoning
개요
- dns 서버 캐시정보를 조작하는 공격을 DNS 캐시 포이즈닝 공격이라 함
- dns 서버는 상위 dns 서버(계층적 구조에 따른)에 빈번하게 반복적 질의를 요청해 부하가 발생하는 것을 막기 위해 캐시를 사용하고, TTL동안 유지한다.
- dns 서버 자체를 공격하기 때문에 조작된 정보가 일정시간 유지되는 동안 다수의 사용자들이 조작된 dns 응답을 수신하여 대규모 보안 사고가 발생할 수 있다

 

과정
- 공격자는 네임서버에 "A 네임서버"에 대한 다수의 DNS 질의 요청 후, "A 네임서버"로 위장한 다수의 조작된 응답을 네임서버로 전송
-> Recursive DNS 서버에 "A 네임서버"에 대한 캐시가 등록되어 있다면 공격 실패.
-> 그러나 캐시가 없다면 Recursive DNS 서버는 "A 네임서버"에 dns 질의를 한다.
-> 이 때 "A 네임서버"의 응답보다 공격자의 조작된 다수 응답이 먼저 수신될 경우 Recursive DNS서버는 조작된 응답을 캐시에 저장
(스니핑이 매우 어렵기(거의 불가능)때문에 이러한 우회공격을 함.

스니핑이 아니기 때문에, Source Port와 Transaction ID를 공격자가 추측/랜덤하게 작성. 운이 좋아 하나라도 공격에 성공한다면 대규모 피해)

 

생일공격 Birthday Attack
- 랜덤한 Transaction ID를 다수 생성해 DNS Cache Poisoning 공격을 하는 것을 생일공격 기법을 이용했다고 한다. 우리가 예상하는 확률보다 실제 확률이 뜻밖에 높다는 이론. 한 반에 23명이 모여있을 때 그 중 생일이 같은 사람이 있을 확률이 50% 이상이라는 생일의 역설에 기반을 둔 공격 방법. (Transcation ID는 2Byte 65536가지 이상의 경우의 수가 됨)

대응책
- 네임서버의 소프트웨어를 최신 버전 상태로 유지
- 도메인 관리용 dns 서버(Authoritative)는 재귀적 질의를 허용하지 않도록 하고, 제한된 사용자가 사용하는 Recusive dns 서버는 해당 사용자로 제한해서 허용
- DNNSSEC (DNS Security Extensions) 기술 활용
  : IETF에 의해 완성된 국제표준기술. 기존의 DNS에 공개키 암호화 방식의 보안 기능을 추가 부여하여 보안 강화

 

 

3 END --

 

 

DNS 서버(BIND DNS) 보안
1) 마스터Master, 슬레이브Slave, 네임서버DNS의 이해
- 마스터 서버 : Zone file 관리
- 슬레이브 서버 : Zone Transfer(53/tcp)를 통해 동기화됨
- 존 데이터는 관리하는 도메인 영역(Zone) 정보로 다양한 레코드 유형에 따른 데이터를 가진다.
- 존 전송 : 마스터에 있는 원본 존 데이터를 슬레이브가 동기화하는 작업
- 마스터/슬레이버 네임서버는 동일한 기능을 수행하며 부하분산을 통해 안전성을 높인다
- 리졸버Resolver : 네임서버로 질의를 수행해 그 결과를 응용 프로그램에 반환해주는 소프트웨어 모듈/라이브러리

(짤막 복습 - dns 질의시 1. dns 캐시 정보 검색 2. hosts.ics 파일 참조 3. hosts파일 참조 4. dns 서버 질의(53 udp port))

 

 

존 파일 이해하기
예시

zone "test.com" IN {
      type master;
      file "test.com.db";
};
zone "55.166.192.in-addr.arpa" IN {                           => 실제주소는 192.166.55 이런식으로 역순기재
      type master;
      file "test.com.db.rev";
};

- 네임서버 설정파일 named.conf 에 존 설정
- type master는 마스터 네임서버
- file "test.com.db"는 관리하는 도메인(test.com)의 리소스 레코드 정보를 담고 있는 존 파일명
- "55.166.192.in-addr.arpa" 는 리버스 도메인. reverse lookup을 위한 특수 도메인. in-addr.arpa 의 하위 도메인으로 구성 (= ip주소에 대한 도메인명 질의 PTR 레코드)

 

SOA 레코드
ex)

$TTL      1500

@                             IN SOA    {DNS 서버 주소}. {DNS 관리자 메일 주소}.
                                                2017033001          :serial                              <- 존 파일 버전 정보
                                                21600                    :refresh                           <- 존 전송 주기(초)

 

                                 IN             NS                         ns1.test.com.

www             300      IN              A                            192.168.56.11

host_name   TTL    class      record_type                      data

      │              │          │                │                                  └ 유형에 따른 데이터

      │              │          │                 └  레코드 유형

      │              │          └  인터넷 클래스 IN

      │              └  Time to Live 미지정시 첫 행의 @TTL값으로 설정됨

      └  등록할 호스트명

이런 느낌으로 구성

 

(리버스 존 파일의 경우
100      IN     PRT      http://www.test.com
10        IN     PRT      ns1.test.com
20        IN     PRT      mx1.test.com

PRT 레코드를 사용하여 구성)

 

존 파일은 네임서버 설정 시 가장 중요한 도메인 데이터베이스 파일

기동시에 존 파일을 읽어들여 존 데이터를 구성한다

 

(짤막복습 dig @네임서버 "질의할 도메인명"

+short 옵션을 쓰면 결과가 간략해짐 )

존 파일의 주요 리소스 레코드 유형 및 역할
A : IPv4
AAAA : IPv6
MX : 메일서버
NS : 네임서버
SOA : 존의 시작을 표현하는 레코드. 파일버전, 전송주기 등.
HINFO : CPU, OS 정보
CNAME : 별명alias
TXT : SPF 레코드, DKIM 디지털 이메일 서명 추가, DMARC 발신 스팸방지
PTR : 리버스 존 파일에 설정하는 레코드. IP에 대한 도메인 정보.

 

 

재귀적 질의 Recusive Query에 대한 제한
1) 과도한 재귀적 질의 요청이 발생하면 DoS 형태의 공격으로 악용될 수 있고 DNS Cache Poisoning 공격에 노출될 수 있다 (+DNS Query Flooding 대역폭 소진 공격)
2) 사내 dns 서버 등 사용자가 제한이 있다면 재귀적 질의에 대한 적절한 접근제어를 해 줄 필요가 있다
3) 접근제어 설정 /etc/named.conf

acl internal {127.0.0.1; 192.168.56.0/24};
options {
   recursion no;
   #allow-recursion {none;};
   #allow-recursion {127.0.0.1; 192.168.56.0/24};
   #allow-recursion {internal;};
}

recursion no 또는 allow-recursion none 으로 재귀적 질의를 허용하지 않게 할 수 있다
일부 허용의 경우 ip 대역을 명시하거나, 별도의 acl을 정의하고 acl 명을 명시해도 된다

 

 

 

존 전송Zone Transfer에 대한 제한
- 지속적 요청으로 네트워크 및 시스템 자원을 소모시켜 DoS 공격으로 악용될 수 있다. 또 Zone 데이터에 있는 도메인의 서버정보가 그대로 노출될 수 있다.
- Master DNS 서버만 운영할 경우엔 존 전송을 허용하지 않고, Slave 서버가 있으면 지정된 Slave 서버만 허용하도록 한다

 

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

}

 

실습
dig @192.168.156.11 test.com axfr
dig @192.168.156.11 test.com ixfr=20240326
(ip와 주소는 물론 가짜임. 형식만 외울것.)
axfr : 버전 상관없이 존 전송 요청
ixfr : 버전비교 후 상위 버전일 때만 존 전송 요청

 

dig @192.168.55.11 chaos version.bind txt +short              (chaos는 ch로 줄여쓸수있다)
=> 버전정보를 물어보는 명령어인데, 보안상 나오면 안됨

 

options {

   #version "BIND 9.3.1";
   version "unkonwn";

}

 

버전은 노출하지 않는 것이 권고됨

 

 

4 END --

 

 

HTTP(Hyper Text Transfer Protocol)
개요
가) HTTP 프로토콜은 웹상에서 클라이언트와 서버간에 통신을 위해 개발됨
1) WEB웹 : 월드 와이드 웹WWW:World Wide Web 전세계에 거미줄처럼 연결된 망이라는 뜻
2) 하이퍼 텍스트 : 참조 혹은 링크를 통해 한 문서에서 다른 문서로 접근할 수 있는 문서. HTML: Hyper Text Markup Language
3) 주로 80/tcp 포트를 사용
4) HTTP 통신은 클라이언트 요청과 서버 응답으로 이루어져 있다

나) 비연결형 Connectionless 프로토콜

HTTP/1.0 버전까지의 요청-응답 구조
1) 웹브라우저 요청 (index.jsp)
2) TCP 연결 설정
3) HTTP 요청 메시지 GET /index.jsp HTTP/1.1
4) 웹서버 요청 처리
5) HTTP 응답 메시지 HTTP/1.1 200 OK
6) TCP 연결 종료
7) 응답 메시지 분석 Parsing
8) TCP 연결 - 종료
8) 추가 자원 요청을 위해 TCP 연결-종료 반복 ...

 

본래는 TEXT 전송을 위해 만들어졌었는데, 현대에 이르러 HTML에는 TXT 뿐만 아니라 다양한 미디어(이미지, 스크립트 등등)들이 포함된다. 서버는 다수의 클라이언트 요청을 동시에 처리하기 위해 TCP 연결 응답을 준 뒤 바로 연결을 끊는다. 첫 HTTP 요청시 HTML에 대한 TEXT만 전송되고, HTML 내부에 있는 IMG, SCRIPT 등은 클라이언트가 응답 메시지를 분석하면서 서버에 추가로 TCP 연결을 요청하게 된다 (= 서버 부하가 커짐)

(응답코드 304 Not modifyed 수정할 내용이 없음)

 

HTTP 1.1 버전부터의 요청-응답 구조

1) 웹브라우저 요청 (index.jsp)
2) TCP 연결 설정
3) HTTP 요청 메시지 GET /index.jsp HTTP/1.1
4) 웹서버 요청 처리
5) HTTP 응답 메시지 HTTP/1.1 200 OK
6) 응답 메시지 분석 Parsing
7) 추가 자원들 request - response 반복

8) TCP 연결 종료

 

Connection 헤더에 Keep-Alive 옵션이 추가됨
TCP 연결 상태를 웹 서버 설정에 따라 일정시간 지속시키는 옵션.

 

- TCP 연결 설정 및 종료에 대한 부하를 줄이면서 효율적으로 클라이언트 요청 처리
- 아파치 웹서버 설정httpd.conf파일의 Keep-alive
KeepAlive On (또는 Off)
MaxKeepAliveRequests 100
KeepAliveTimeout 15

 

HTTP는 상태정보를 유지하지 않는 Stateless 프로토콜
- 클라이언트의 현재 요청과 이전 요청을 식별하지 못한다는 의미
- 상태정보 유지가 필요할 때를 위해, 클라이언트의 쿠키Cookie와 서버의 세션Session 기술을 사용

 

 

상태정보 유지 기술
가) 쿠키 Cookie 기술
 1) 클라이언트의 HTTP 요청
 2) 서버는 클라이언트 식별을 위한 쿠키 정보 생성
 3) HTTP 응답에 쿠키 셋팅 Set-cookie : name=test
 4) 클라이언트는 쿠키정보를 저장 Cookie : name=test
 5) 서버에 이후부터 HTTP 요청 헤더에 쿠키 셋팅

- 쿠키 : 개별 클라이언트 상태정보를 HTTP 요청/응답 헤더에 담아 전달하는 작은 정보/데이터
- 서버의 Set-Cookie 응답 헤더 / 클라이언트의 Cookie 요청헤더
- 영속 쿠키Persistent : 클라이언트에 파일형태로 지속적으로(또는 일정기간) 존재하는 쿠키
- 세션 쿠키Session : 클라이언트 메모리상에 세션이 유지되는 동안 존재하는 쿠키. 세션 종료시 소멸
- 보안 취약점
 1) 클라이언트 상태정보를 클라이언트에 저장하므로 해킹 및 스니핑 공격에 의한 변조와 외부 노출에 취약
 2) 중요정보를 저장할 경우 서버에 상태정보를 저장하는 세션 방식이 안전하고 부득이하게 쿠키를 쓸 때는 암호화를 적용

 

나) 세션Session 방식

 1) 클라이언트 로그인 요청
 2) 서버는 회원 세션 객체 생성 (세션 타임아웃 설정) 후 세션 ID를 담아 세션쿠키 설정 응답 Set-cookie
 3) 클라이언트는 메모리상에 세션쿠키 저장
 4) 클라이언트는 서버에 이후부터 HTTP 요청 헤더에 Cookie : jsessionid=abc 설정

(php는 sessid jsp는 jsessionid)
 5) 세션 종료시 세션쿠키 소멸

 

- 세션은 개별 클라이언트 상태정보를 서버에 저장하는 기술
- 개별 클라이언트 세션을 식별하기 위해 세션ID를 부여하고 세션쿠키를 이용해 서버-클라이언트가 주고받음
- 쿠키방식보다는 보안상 안전

HTTP Session Hijacking
세션id를 탈취해 정상적인 사용자처럼 위조할 수 있다

 

 

5 END --

 

 

HTTP 쿠키 관련 보안 속성
가) httponly 속성
- Set-Cookie 응답 헤더에 설정하는 속성. 클라이언트에서 스크립트를 통해 해당 쿠키에 접근하는 것을 차단해준다. (헤더의 Set-Cookie의 맨 마지막에 ;HttpOnly 로 확인가능)
- 세션 ID를 저장하고 있는 세션 쿠키를 탈취하기 위한 XSS(Cross site script)공격에 대응
- 환경설정 파일(php의 경우 php.ini의 session.cookie_httponly=1) 또는 개발자가 코드에 설정

나) secure 속성
- Set-Cookie 응답 헤더가 설정. (;secure 로 확인 )
- 네트워크를 통해(스니핑) 세션ID 탈취하는 것을 막기 위해, 클라이언트가 https(SSL/TLS) 통신을 할 때만 쿠키를 전송하는 속성 (php의 경우 php.ini의 session.cookie_secure = 1)

- 쿠키에 대한 기밀성을 보장하기 위한 목적

 

 

HTTP 요청 메시지 구조

요청라인: 요청메소드(공백0x20)요청URI(공백0x20)HTTP버전(CRLF 0x0d0a 개행)
요청헤더: 헤더명:헤더값(개행)
                헤더명:헤더값(개행)
                 ...
빈 라인: (개행)
요청 메시지 바디: 메시지 내용


가) 구문형식
1) 요청라인 : 한 행으로 구성되며 요청 메소드, 요청 URI, HTTP 버전 정보를 담음
2) 요청헤더 : 여러 헤더들이 구성되며 개행으로 구분한다. Host(도메인명, 호스트명, 포트), User-Agent(os 정보), Referer(현재 요청 URL 정보를 담고 있는 이전 문서 URL) 등이 있다
3) 빈 라인 : 헤더의 끝을 의미하는 개행
4) 요청 메시지 바디 : GET은 메시지 바디가 없다

 

 

나) 주요 요청 메소드
GET : 요청 URL로 지정한 자원을 서버에 요청하는 메소드. (필요시 쿼리 스트링으로 간단한 데이터는 전달 가능)
POST : 요청 URL로 지정한 자원에 데이터를 전달하여 이를 처리한 결과를 서버에 요청하는 메소드.
HEAD : 헤더부만 응답해주는 메소드. 주로 URL/링크 유효성 검증을 위해 사용
OPTIONS : 서버가 지원하는 메소드를 확인
CONNECT : 클라이언트-서버간 터널링 목적 (웹서버가 Proxy 역할)
PUT : 메시지바디의 데이터를 요청 URL로 지정한 자원으로 저장
TRACE : 수신한 메시지를 서버에서 그대로 반환 (루프백 테스트 용도)
DELETE : 요청 URL로 지정한 자원을 서버에서 삭제하도록 함

(알아두되 실무에서는 GET POST 외엔 사용하지 않는 추세)

 

HEAD의 경우 GET과 달리 응답에 데이터부가 없다 <CRLF>만 덜렁 있음
OPTION은 Allow: GET, HEAD, OPTION 같은 정보가 있음

 

실습

telnet 192.168.서버.ip
GET /index.html HTTP/1.1

OPTIONS * HTTP/1.1

 

다) Query String 요청 문자열

- ? : 식별자, param=value : 파라미터명=값, & : 파라미터 구분자

- get 방식의 쿼리 스트링은 요청 URI 끝에 추가해서 전달하기 때문에 주소창에 정보가 노출되고 액세스 로그상에 그대로 남아있다. 보안상 취약하므로 POST 방식 권장

 

 

응답 메시지 구조
상태라인: HTTP버전(공백0x20)상태코드(공백0x20)응답구문(CRLF 0x0d0a 개행)
응답헤더: 헤더명:헤더값(개행)
                헤더명:헤더값(개행)
                 ...
빈 라인: (개행)
응답 메시지 바디: 메시지 내용

 

- 요청 메시지 구조와 다르게 상태라인에 HTTP 버전이 제일 먼저 나옴

- 응답 헤더의 주요 정보
1. Content-Type : 데이터 형식
2. Content-Length : byte 단위 전체 크기

 

 

*** HTTP 응답 코드

1xx : Infomation (정보)	100	Continue (일부 요청 받았고 나머지 정보 계속 요청)
2xx : Success (성공)	200	OK (요청이 성공적으로 수행됨)
	201	Created (PUT 메소드에 의해 원격지 서버에 파일생성됨)
	202	Accepted (웹 서버가 명령 수신)
3xx : Redirection (재지정 응답 코드)	301	Moved Permanently (요청 자원의 위치가 영구적으로 변경. Location 등으로 변동된 URL 전달)
	302	Found (요청 자원 위치가 임시로 변경. Location 등으로 변동된 URL 전달)
	304	Not Modifyed (요청 자원이 변경되지 않았으니 클라이언트 로컬 캐시를 이용하라)
4xx : Client Error (클라이언트 오류 응답)	400	Bad Request (요청 메시지 문법 오류)
	401	Unauthorized (요청 자원에 대한 인가 필요. 권한이 없음)
	403	Forbidden (요청 자원에 대한 접근 차단)
	404	Not Found (요청 자원 존재하지 않음)
5xx : Server Error (서버 오류 응답)	500	Internal Server Error (내부 서버 오류)

 

 

6 END --