의미없는 블로그
Part 03. 어플리케이션 - DNS, HTTP, FTP, SNMP, DHCP 본문
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 까지 보낸 후에 실제로는 할당하지 않는다
'# 나 > pentest (WEB)' 카테고리의 다른 글
Part 02. 네트워크 - DoS, DDoS, DRDos, 무선랜, VPN, IPsec, SSL/TLS, 라우터 (0) | 2019.05.10 |
---|---|
Part 04. 침해사고 분석 및 대응 - snort, iptables (0) | 2019.05.08 |
AD 서버 원격 명령어 테스트 (1) | 2019.04.10 |
SSRF(Server Side Request Forgery) (8) | 2019.02.12 |
PsExec 로 원격 명령어 실행 (0) | 2019.01.21 |