1. DNS 보안
 |
| DNS 동작과정 (출처: 알기사 정보보안기사 실기 책) |
사용자가 Recursive 네임서버로 질의하면 자신의 캐시 데이터에서 질의한 도메인의 주소를 검색하고, 없으면 hosts 파일 검색, 그러고도 없으면,
Iterative 방식으로 순서대로 root DNS 서버, TLD DNS 서버(com, ca 등), 위의 그림 처럼 algisa.com의 도메인 관리 네임서버로 질의하여 도메인의 주소를 알아냄.
- DNS 스푸핑 공격 & DNS Cache Poisoning 공격
" 정보보안기사 정리 25 - DoS, DDoS, 포트스캐닝, 스니핑, 스푸핑, HTTP 세션하이재킹"에서 DNS 스푸핑 정리함.
- 도메인 쿼리 순서
URL 입력 → host.conf → hosts → 있으면 IP 주소 획득.
없는 경우 → resolv.conf(네임서버 지정 파일) → 네임 서버 설정이 있으면 →질의 → 응답 오면 IP 주소 획득.
네임 서버 설정이 없는 경우 → 결과: 호스트 이름 알 수 없음 획득.
네임서버 설정이 있어도 질의 후 응답이 없는 경우 → 결과: 호스트 이름 알 수 없음 획득.
- DNS 서버 보안: Bind DNS
① Recursive 질의 제한: 과도한 재귀적 질의 요청은 DNS Cache Poisoning 공격에 노출될수 있으므로 이를 제한함.
named.conf 파일에서 특정 IP 대역만 질의가 가능하게 하거나 질의를 제한함.
② zone 파일(named.conf 같은.)은 네임서버 설정시 가장 중요한 도메인 DB 파일이고 네임서버 가동시에 zone 파일을 읽어 들여 네임서버 서비스가 동작함.
zone 파일은 도메인을 IP 주소로 변환해 주는 역할을 함.
네임서버가 보통 마스터와 슬레이브 관계로 구성되는데 zone 파일이 상호간에 TCP를 통해 오고 감.
따라서 zone 파일 전송을 요청하는 것에 대해 제한을 걸어야 저장되어 있는 도메인의 정보들이 노출 안됨.
* zone 파일 부분은 정확히 이해가 안감. 잘 모르겠음.
2. FTP (File Transfer Protocol)
- FTP는 TCP/IP 기반의 서버와 클라이언트 사이의 파일 전송을 위한 프로토콜.
FTP 서비스는 아이디와 패스워드가 암호화 없이 전송되어 스니핑으로 노출되므로 FTP 사용을 제한해야 함.
- 암호화된 통신을 수행하는 FTP 서비스는 SFTP(SSH FTP) 또는 FTPS(FTP SSL/TLS)이므로 이를 이용해야 함.
- FTP 동작모드: Active mode, Passive mode
① Active mode: 클라이언트는 서버측에 21번 포트로 접속하여 제어 채널 생성. 서버는 클라이언트에서 알려준 포트로 접속하여 데이터를 보냄.
② Passive mode: 클라이언트가 서버측의 21번 포트로 연결하여 제어 채널 생성. 사용자는 Passive mode로 연결하기 위해 PASV 명령을 전송함.
서버는 PASV 명령을 받고, 데이터 전송에 사용될 포트 번호를 클라이언트에게 알려줌. 클라이언트는 데이터 포트에 연결하여 데이터 채널 생성 후 데이터 받음.
- FTP 보안 취약점: FTP bounce attack
FTP 프로토콜은 제어 채널과 데이터 채널을 다르게 사용하고, 데이터 채널 생성시 목적지를 확인하지 않으므로 이를 이용한 공격.
일반적으로 Active mode를 많이 사용하는데, Active mode에서는 클라이언트가 데이터를 받을 IP와 포트를 서버에 전달함.
서버에 전달하는 IP와 포트를 다른 임의의 주소로 지정하면 공격이 될 수 있음.
공격 방법: FTP 서버에 스팸메일 파일 업로드하고, 해당 파일을 요청하면서 데이터 받는 IP와 포트를 요청자가 아닌 다른 호스트로 하면 그쪽으로 스팸메일이 감.
- FTP 보안 취약점: TFTP(Trivial FTP) 공격
TFTP는 단순한 파일 송수신 프로토콜/어플리케이션으로 자체 디스크를 가지고 있지 않은 워크스테이션에 부팅이미지를 전달하거나
라우터 같은 장비를 초기화할 때처럼 기본적인 파일 전송에 주로 사용됨.
TFTP에 접근 제어를 제대로 하지 않으면 보안 기능이 없는 TFTP를 이용해 공격자가 임의의 파일에 접근 가능.
- FTP 보안 취약점: Anonymous FTP 공격
익명 계정으로 FTP 접속이 가능한 것을 의미함.
이것은 인증없이 FTP 파일에 접근가능하게 하므로 Anonymous 계정이 필요 없다면 반드시 삭제해야 함.
- FTP 접근제어
FTP에 접속하는 사용자가 정해져 있다면 해당 사용자 계정만 접근하게 설정하거나, 특정 계정에 대해 접속 차단을 하여 접근제어를 하는 것이 좋음.
3. DHCP Starvation 공격
- 동적으로 클라이언트의 IP 주소를 설정하기 위한 프로토콜
- 할당 절차
-1) 클라이언트는 DHCP 서버를 찾기 위해 자신의 MAC 정보를 담아 브로드캐스트함.
-2) DHCP 서버가 브로트캐스트 메시지를 받으면 클라이언트에게 IP 정보를 브로드캐스트 하여 제공함.
-3) 클라이언트가 해당 IP를 사용하겠다고 서버에 요청함.
-4) 서버는 해당 MAC과 IP 정보를 테이블에 저장하고, 다시한번 할당된 주소정보를 클라이언트에게 전송하며, 클라이언트는 이 IP 정보로 인터넷 접속을 함.
- DHCP Starvation 공격: DHCP 서버가 할당 가능한 IP 주소를 모두 소진하게 만드는 공격. 서로다른 MAC 주소로 패킷을 설정하여 대량으로 보내면 됨.
4. 웹 어플리케이션 취약점
- OWASP를 기본적으로 볼것.
- 파일 업로드 취약점
웹쉘(Webshell)은 악의적인 목적으로 웹서버 내 임의의 명령을 실행할 수 있는 서버 스크립트 파일로써 JSP, ASP, PHP 등으로 만들어 질수 있음.
파일 업로드 기능이 확장자 필터링을 제대로 안하면 공격자가 웹쉘을 업로드하여 시스템을 제어할 수 있음.
대응: 업로드 파일의 확장자 검증. 업로드를 허용할 파일 확장자 리스트를 지정하여 해당 확장자를 가진 파일만 업로드 가능하게 함.
업로드되는 파일을 저장하는 전용 디렉터리를 만들고, 파일의 실행 가능 설정을 제거하여 악성 스크립트가 업로드 되도 실행되지 않게 함.
- 파일 다운로드 취약점
파일 다운로드 시, 파일의 경로 및 파일명을 파라미터를 받아(예: www.xx.com/home/download/down.php?num=2&realname=../abc.php) 처리하는 경우
이를 필터링 하지 않으면 공격자는 경로를 조작하여 허용되지 않은 파일을 다운받을 수 있음.
대응: 파일 경로를 변경할 수 있는 문자열(예: ../ , ./ , ..\ , .\)을 필터링 함.
- 파일 삽입 취약점
include 함수를 사용하는 경우. include 함수가 파라미터로 지정된 페이지를 현재 페이지에 포함시켜 실행해 주므로 편리하지만
만약 파라미터를 외부에서 입력 받을 때 검증하지 않는다면 악성 스크립트를 포함한 페이지를 파라미터로 전달하여 실행되게 할 수 있음.
대응: 소스코드에 include 같은 함수가 있다면 php의 경우 allow_url_fopen을 off로 설정하면 됨.
- URL/파라미터 변조 취약점
URL/파라미터 변조는 사용자 입력 값에 대한 검증 누락이 발생할 경우 관리자 계정 정보 노출 등으로 이어질 수 있음.
예: 웹 사이트 로그인 후 로그인 한 사용자가 계정의 정보 수정을 위해 "정보수정" 버튼 클릭시, 웹 서버로 전송되는 POST 방식의 계정 파라미터를
흔히 쓰는 관리자 계정 파라미터인 'admin'으로 고쳐서 전송하면 관리자 계정의 정보수정 페이지가 나오게 됨.
대응: 사용자 재인증 과정 추가
- 약한 문자열 강도 취약점
admin, master 등 유추하기 쉬운 계정 사용
쉽게 유추가능한 패턴으로 비밀번호 설정
생일, 전화번호 등으로 비밀번호 설정. 등이 있음.
대응: 패스워드 주기적 변경 및 최대 사용기간 설정, 기본적인 계정 이름은 변경, 패스워드 설정시 규칙을 적용하여 어렵게 만들게 해야 함.
- 웹 어플리케이션 개발시
최종 통제 메커니즘(입력값 검증, 사용자 검증 등)은 서버에서 하고, 중요 정보 전송은 POST 메소드 및 SSL(HTTPS)를 사용한다.
중요한 트랜젝션이 발생하는 프로세스에서는 사용자 검증을 다시하게 하고, 중요 정보를 보여주는 페이지는 캐싱을 못하게 함.
암호화를 꼭 한다.
5. 웹 서버 취약점
- 디렉터리 인덱싱/리스팅 취약점
웹 서비스를 제공하는 서버에 인덱싱 기능이 활성화 된 경우 공격자가 강제로 경로를 검색하여 서버 내의 디렉터리와 파일 정보를 볼수 있음.
예: http://192.168.159.12/home/board 처럼 URL 입력. board/xxx.php 같이 특정 파일이 와야 되는데, board 같이 입력하면 board 폴더 하위의 파일 리스트가 노출됨.
대응: 아파치 웹서버의 경우 httpd.conf 파일에서 인덱싱/리스팅을 제한하면 403 Forbidden 응답 페이지를 뜨게함.
Get, Post 외에 Delete, Options, Put 메소드를 통해 웹 서버에 파일 생성, 삭제, 수정을 하는 것.
예: telnet <ip addr> <80 port> 로 접속하여 options 메소드 요청을 전송하면, options 메소드를 지원하는 경우
200 OK응답과 함께 Allow 헤더 필더에 지원하는 메소드 리스트를 보내줌. 이를 이용하여 공격 함.
대응: 아파치의 경우 httpd.conf 파일에서 허용하는 메소드를 Get, Post로 제한함. 이 외의 메소드 사용은 응답으로 403 Forbidden을 받게됨.
- 관리자 페이지 노출 취약점
관리자 페이지가 추측 가능한 형태로 구성된 경우 Brute force 공격으로 관리자 권한 획득 가능.
예: 관리자 페이지 URL이 .../admin.php, .../manager.php 과 같이 쉬운 경우 사용자도 접근함.
대응 1: 관리자 페이지 이름을 어렵게하거나, httpd.conf에서 특정 ip에서만 관리자 페이지에 접근하도록 설정함.
특정 IP 허용: Allow from <IP>
여러 IP 허용: Allow from <IP, IP, ...>
IP 대역 허용: Allow from 192.168.159 또는 192.168.159.0/24
* 허용안된 IP에서 관리자 페이지 접근시 403 Forbidden 뜸.
대응 2: httpd.conf 에서 디렉터리 접근 제어. (Oder 뒤에 나열된 것 중 뒤에 것부터 먼저 참조함)
예1 예2
Order Deny, Allow Order Allow, Deny
Allow from all Allow from all
Deny from 192.168.159.1 Deny from 192.168.159.1
예1은 Allow부터 참조해서 문법상 틀리지는 않지만 ~.159.1 IP를 deny 한 것이 의미가 없어짐. 논리적으로 틀림.
예2는 Deny가 먼저 적용되서 ~.159.1 IP 접근을 먼저 차단 후 매칭 안 된 것은 Allow from all을 적용함.
- 아파치 기준 웹 서버 보안 대책
① 최소 권한 사용자 운영: 웹 서버를 관리할 별도의 계정 및 그룹을 생성하여 운영.
② 심볼릭 링크 사용 금지
③ 웹서버의 응답 패킷이 나타나는 헤더에서 웹서버의 버전이나 응용프로그램 버전 등의 정보를 최소화 시킴.
댓글 없음:
댓글 쓰기