Notice
Recent Posts
Recent Comments
Link
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Archives
Today
Total
관리 메뉴

의미없는 블로그

Part 03. 어플리케이션 - DNS, HTTP, FTP, SNMP, DHCP 본문

# 나/pentest (WEB)

Part 03. 어플리케이션 - DNS, HTTP, FTP, SNMP, DHCP

SaltLee 2019. 5. 7. 17:24

 

DNS

 

재귀적(Recursive) 질의, 반복적(Iterative) 질의가 있다

 

재귀적 질의는 [Recursive DNS 서버] 에다가 질의하는건데 무조건 질의하는건 아니고 순서가 있다

1. 로컬 DNS Cache 를 먼저 검색

2. hosts 파일 검색

3. Recursive DNS 서버에 질의

 

여기서 로컬 DNS Cache 란 기존에 DNS 서버에 질의해서 받은 결과가 저장되어 있는 캐시이다

매번 물어보는 부하를 줄이기 위해 먼저 기존 캐시에 정보가 있는지 검색한다

 

[Recursive DNS 서버]는 자신의 캐시에 저장된 정보를 응답하거나 정보가 없으면 최상위 Root 네임서버부터 반복적 질의를 수행하여 응답해 준다

ISP 업체에서 제공하는 DNS 서버가 일반적으로 Recursive DNS 서버에 해당된다고 한다

ex) KT의 kns.kornet.net/168.126.63.1

 

반복적 질의는 [Authoritative DNS 서버] 에다가 질의하는건데 얘네는 특정 도메인 정보만 관리하면서 해당 도메인 정보만 응답해준다

최상위 Root 네임서버부터 계층구조에 따라 순차적으로 반복하여 질의한다

- 존(Zone) : 네임서버가 관리하는 도메인 영역

- 존 파일(Zone File) : 관리하는 도메인에 대한 정보를 담고 있는 파일

- 존 데이터(Zone Data) : 네임서버는 존 파일을 읽어들여 존 데이터를 구성하고 이를 이용하여 질의에 응답한다

각 회사별로 자신의 도메인을 관리하는 DNS 서버가 Authoritative DNS 서버에 해당된다고 한다

ex) Google의 ns1.google.com/216.239.32.10

 

위에서 질의하는 순서가 있다고 했는데

윈도우의 경우는 DNS Cache, hosts.ics, hosts, DNS 서버 순이라고 한다

 

hosts.ics 파일

- 윈도우에서 인터넷 연결 공유 기능 설정하면 IP가 강제로 지정된다고 한다 이것과 관련된 설정 파일

- hosts 파일보다 DNS 질의 우선순위가 높아서 먼저 참조되므로 악성코드에 의해 hosts.ics 파일을 생성하여 파밍사이트로 유도하는 사례가 있다고 한다

 

/etc/resolv.conf 파일

- 서버의 기본 네임서버 설정 정보를 담고 있다

- 192.168.159.2 를 네임서버로 설정해 놓은 상태이다

/etc/hosts 파일

- 도메인과 IP 매핑정보 담고 있는 파일

- 네임서버에 질의하기 전에 참조되는 파일

/etc/host.conf 파일

- DNS 질의 순서를 지정하는 파일

- hosts 파일 먼저 검색 후 bind 네임서버를 검색하도록 설정되어 있다

hosts 파일은 리눅스, 유닉스, 윈도우, 맥 등 OS 마다 경로는 달라고 같은 파일명을 사용한다고 한다

윈도우 7 이상 버전에서는 관리자 외 수정이 불가하다고 함

 

DNS는 53번 포트 쓰는데 응답길이가 512 bytes 이하이면 UDP(53), 이상이면 TCP(53) 쓴다고 함

- 응답값이 158 bytes 이므로 UDP로 응답한다

- www.kiwi99.com 에 대하여 요청을 했고 192.168.159.135 로 응답했다 

- type A는 IP 주소를 요청하는 것을 뜻한다

- 응답값이 543 bytes 로 오버되면 TCP 로 재요청하라고 응답한다

- Truncated 이게 TCP 로 재요청 하라는 뜻이다

- 재요청 결과 1101 bytes 로 응답함을 볼 수 있다

DNS 캐시 관련 명령어가 있다

 

ipconfig /displaydns

- 로컬의 DNS 캐시를 조회한다

- 구글 관련 캐시가 남아있고 TTL 3은 해당 캐시 유지 시간인데 3초이다 3초 지나면 해당 캐시 사라진다는 뜻

- DNS 스푸핑에서 DNS 캐시를 조작할때 여기를 조작하는 것

ipconfig /flushdns

- 로컬의 DNS 캐시 삭제하기

- 삭제하고 다시 /displaydns 해보면 아무것도 없다

순방향 룩업(Forward DNS Lookup), 역방향 룩업(Reverse DNS Lookup)이 있다

 

순방향 : 도메인명 → IP 주소 알아내는 질의

역방향 : IP 주소 → 도메인명 알아내는 질의

 

아까 위에서 Type A 가 IP 주소라고 했는데 이러한 레코드 타입을 DNS Lookup 시 사용한다

A(Address) : IP 주소

ANY : 도메인에 대한 모든 레코드, 요청대비 응답값이 크므로 DNS 증폭 DRDoS 공격에 악용된다

MX(Mail) : 메일서버

NS(Name) : 네임서버

SOA(Start Of Authority) : 존의 기본 속성 정보(존 파일 버전, 존 전송 주기 등)

TXT(Text) : 텍스트 정보, 텍스트 정보라 함은 

PTR(Pointer) : IP에 대한 도메인 정보, A의 반대

AXFR : 존 버전에 상관없이 무조건 존 전송 요청

IXRF : 존 버전을 비교하여 상위 버전일 경우 존 전송 요청

 

nslookup [도메인] [질의할 네임서버]

- 192.168.159.149를 질의할 네임서버로 지정하고 있다 지정안하면 서버 내 기본 네임서버에다가 질의한다

- set type을 ns로 설정하고 google.com 을 질의한다 ns로 설정안했으면 google.com 의 A레코드의 질의를 수행하는데 ns를 설정했으니 네임서버를 질의한다

dig [@네임서버] [도메인] [쿼리유형] [쿼리옵션]

- dig @ns.algisa.com www.algisa.com +norecurse : 네임서버에 반복적 질의를 수행하여 정상 응답 여부 점검

dig @ns.algisa.com www.algisa.com +tcp : 53/tcp 허용 여부를 점검

dig @ns.algisa.com www.algisa.com +trace : 최상위 root 도메인부터 최종 질의대상 도메인까지 계층 구조에 다른 질의 수행

 

whois [도메인]

- 도메인 등록 정보를 알 수 있다

- 어떤 정보들 있는지 키사 역량평가에 나온적 있다..

DNS 스푸핑 공격

- 타겟에게 전달되는 DNS 응답의 IP 주소를 조작하거나, DNS 서버의 캐시를 조작한다

- 타겟은 정상 URL 도메인으로 접속해도 다른 사이트로 접속하게 된다

- DNS 스푸핑은 [UDP 프로토콜의 비연결 특성 취약점]을 이용한다고 하는데 이게 뭐냐면 클라이언트가 DNS 서버와 연결상태를 계속 유지하는 것이 아니라 DNS 질의/응답을 식별하기 위한 Transaction ID, 출발지/목적지 주소만 일치하면 응답을 신뢰하고 그 이후에 수신한 응답을 폐기해버리는 특성을 말한다

- 스니핑 기반, DNS 캐시 포이즈닝 이렇게 2가지 유형 있다

 

스니핑 기반 DNS 스푸핑

- 타겟이 DNS 질의를 하면 공격자가 스니핑 하고 있다가 정상 응답보다 빠르게 타겟에게 조작된 DNS 응답을 보낸다

- 조작된 응답 이후에 도착하는 정상 응답은 위에서 봤듯이 폐기된다

- 일반적으로 스니핑을 통한 DNS 스푸핑은 동일 네트워크 내에서 발생하므로 상대적으로 DNS 서버보다 빠르게 조작된 응답을 보낼 수 있다

대응방법은

- 스니핑을 탐지 및 차단한다

- 중요 사이트의 IP 주소에 대해서 DNS 질의보다 우선순위가 높은 hosts 파일에 등록해 놓는다

 

DNS 캐시 포이즈닝

- DNS 캐시를 조작한다

- 캐시 정보가 일정 TTL 만큼 유지되는 동안 해당 서버에 접근하는 다수의 사용자들이 조작된 DNS 응답을 수신하여 대규모로 보안사고 발생할 수 있다

- 공격자가 공격 대상 Recursive DNS 서버에 도메인 질의를 다수 보낸다

- Recursive DNS 서버가 반복적 질의를 수행하는 동안에 공격자는 다수의 랜덤한 조작된 응답을 보낸다

- 다수의 응답중 정상 응답보다 먼저 일치하는 응답이 있을 경우 조작된 주소가 DNS 캐시에 저장되게 된다

- 이를 생일 공격(Birtuday Attack) 이라고도 하는데 한반에 23명의 사람이 모여있을 때 생일이 같은 사람이 있을 확률이 50% 이상이라는 생일의 역설에 기반을 둔 공격 방법으로 Transaction ID가 65536 개의 값을 가질 수 있는데 이론적으로 우리가 이를 맞출 확률이 생각보다 높다는 것

 

대응방법은

- 네임서버의 소프트웨어(Bind DNS)를 최신 패치 한다

- Authoritative DNS 서버가 재귀적 질의(너무 많은 다수의 계속된 질의)를 허용하지 않도록 설정한다

- 제한된 사용자만 사용하는 Recursive DNS 서버라면 해당 사용자만 질의하도록 허용한다

- DNSSEC 을 활용한다, DNSSEC이란 기존의 DNS에 공개키 암호화 방식의 보안기능을 추가한 것, 데이터 위변조를 개선하기 위해 개발된 국제표준기술

 

 

<HTTP>

HTTP/1.0 까지는 서버 응답 이후에 TCP 연결을 바로 종료했다고 함

- 서버 연결 자원 확보를 위해

HTTP/1.1 부터는 응답 헤더에 Connection: Keep-Alive 있으면 TCP 연결상태를 일정시간 지속시킴

- 한번의 연결 이후 요청/응답을 반복할 수 있다

- 이미지, 스크립트 등 다수의 추가 자원 요청이 있으므로 연결을 일정시간 유지한다

 

Connection: Keep-Alive

Keep-Alive: timeout=15, max=100 (15초, 최대 100건)

아파치의 경우 http.conf 에서 설정한다

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 15

 

쿠키는 클라이언트 식별

요청 후 서버 응답할 때 Set-Cookie: nickname=test

그 다음부턴 요청에서 Cookie: nickname=test

- 영속쿠키 : 클라이언트에 파일 형태로 저장 --> 설정된 사이트 요청시마다 Cookie: nickname=test 전달

- 세션쿠키 : 클라이언트 메모리에 저장 --> 세션이 유지되는 동안만, 브라우저 종료 등 세션 종료되면 소멸

 

 

<FTP> p.341

FTP 쓸때 안전한 FTP 사용을 권장

- SFTP : S가 앞에 붙으면 SSH 기반, 22/tcp

- FTPS : S가 뒤에 붙으면 SSL/TLS 기반, 990/tcp

 

21/tcp : 제어(control) 채널

20/tcp : 데이터(data) 채널, 데이터를 주고 받는

 

능동(Active) 모드 - Default

클 -> 서 : 서버의 21포트로 제어 채널 형성 (파일 목록 보기위해 ls 입력)

클 -> 서 : 클의 5001 데이터 채널 포트를 서버에게 알려줌 (클이 PORT 5001)

서 -> 클 : 클의 5001포트로 데이터 채널 형성

서 -> 클 : 데이터 채널로 파일 전송

 

수동(Passive) 모드

클 -> 서 : 서버의 21포트로 제어 채널 형성 (파일 목록 보기위해 ls 입력)

서 -> 클 : 서버의 4900 데이터 채널 포트를 클에게 알려줌 (클이 PASV 전송, 서버가 PASV OK 4900)

클 -> 서 : 서버의 4900포트로 데이터 채널 형성

서 -> 클 : 데이터 채널로 파일 전송

 

FTP Bounce Attack

능동(Active) 모드에서 해당

클 -> 서 단계에서 PORT 명령으로 클라이언트 ip, port 알려주는데 이때 임의 ip, port 로 조작

 

아래처럼 get test.c 명령으로 test.c 파일 요청하는데 (클 -> 서) 과정이고

그 담에 PORT 192,168,197,1,18,214 이건 IP 192.168.197.1, 포트 18, 214 알려주는 과정 (클 -> 서)

이때 얘를 다른걸로 조작

공격예시 - 1

서버에 스팸메일 업로드하고 해당 파일 요청한 담에

PORT 로 수신측 조작해서 SMTP 서버로 지정하면

해당 파일이 SMTP 서버로 간다(스팸메일 발송)

 

공격예시 - 2

PORT 로 내부 시스템의 다양한 포트 입력해보면서 네트워크 스캔 시도

 

TFTP Attack (Trivial)

TFTP 라고 워크스테이션에 설치될 수 있는 간소한 FTP 프로토콜 있다

자체디스크 없는 워크스테이션에 부팅이미지 전달 목적으로 주로 사용

TFTP 는 69/udp 포트 사용

 

별도의 인증 과정이 없어서 접근제어를 제대로 해야한다

아니면 불필요한 경우 TFTP 삭제해야 한다

정말 필요하면 secure mode 로 운영한다 -> 최상위 디렉을 강제로 지정해서 그 이상 못올라가게 하는것

 

inetd 환경에서는 /etc/inetd.conf 에서 tftp 주석처리

xinetd 환경에서는 tftp 파일에서 disable = yes

secure 모드로 운영할거면

inet 환경에서는 /etc/inetd.conf 에서 tftp 에 -s /tftpboot 추가

xinetd 환경에서는 tftp 파일에서 server_args = -s /tftpboot

 

Anonymous FTP Attack

익명 계정 anonymous 는 비번 없거나 아무비번 입력 가능

아무나 접근 가능하므로 서비스 제거 필요

 

vsftpd.conf 파일에서 anonymous_enable=NO 설정

 

FTP 접근제어 방법

1) ftpusers 파일에서 하는 방법

2) TCP Wrapper 사용하는 방법

 

ftpusers

FTP 는 계정정보 평문으로 송수신 -> root 등 중요계정 직접 접속 차단해야

ftpusers 파일에 차단할 계정 작성

TCP Wrapper

vsftp.conf 파일에 tcp_wrappers=YES 로 설정하고

hosts.allow, hosts.deny 파일에 접근제어 설정 -> in.ftpd : 192.168.35.140 이런식으로

 

<SNMP>

네트워크 관리 프로토콜이고 MRTG 프로그램으로 관리

SNMP Manager : 162/udp (엠이), Agent 에 필요한 정보를 요청

SNMP Agent : 161/udp (에이원), 설치된 시스템에서 정보를 수집해서 MIB 형태로 보관, Manager 에 전달해줌

 

Polling 방식 : Manager 가 Agent 에게 정보를 요청, Agent 가 응답, 161/udp 사용 (수신하는놈 포트)

Event Reporting 방식 : Agent 가 이벤트 발생 시 Manager 에게 알림, 162/udp 사용 (수신하는놈이 Manager)

 

<DHCP>

DHCP 서버는 67/udp (서치)

DHCP 클라이언트는 68/udp 

 

DHCP Starvation 공격

DHCP 서버의 할당 가능한 IP를 모두 소진하게 만드는 것

 

DHCP Discover 메시지 -> DHCP 서버 찾으려고 자신의 MAC 을 브로드캐스팅 하는

DHCP Offer 메시지 -> 응답으로 IP 보내주는

DHCP Request 메시지 -> 그 IP 를 쓰겠다고 보내는 것

 

discover 메시지를 서로 다른 MAC 으로 대량 보내면 이에대한 Offer 가 오고

여기서 Request 까지 보낸 후에 실제로는 할당하지 않는다

Comments