7. 서버 보안

웹서버 보안

 

디렉터리 리스팅(Directory Listing) 취약점

: 서버의 인덱싱(리스팅) 기능이 활성화 되어있을 경우, 공격자가 강제 브라우징(디렉터리를 직접 명시)을 통해 서버 내의 모든 디렉터리 및 파일 목록을 볼 수 있는 취약점

 

예시) 디렉터리 리스팅 공격

http://192.168.56.100/home/board/list.php

가 아닌

http://192.168.56.100/home/board/

처럼 디렉터리 경로만 요청

응답코드가 200 OK, 타이틀에 Index of /home/board, 이름/마지막 수정일시/크기/설명 등의 항목이 보이는것으로 보아 공격이 성공한 것을 알 수 있다

 

 

대응방안

1. 아파치 웹서버 설정파일(httpd.conf) Options에 있는 Indexes를 제거하여 디렉터리 인덱싱 기능 제거

<Directory />    Options Indexes(제거 또는 None으로 변경)

</Directory>

*Indexes 제거 후 디렉터리 인덱싱 시도 시 403 Forbidden 오류가 표시됨

 

2. 윈도우 IIS 웹서버 환경에서 디렉터리 인덱싱 기능 제거

* 홈디렉터리 - '디렉터리 검색' 체크 해제

 

 

3. Tomcat 웹서버 환경에서의 디렉터리 인덱싱 기능 제거

* Listings 파라미터를 false로 설정

 

* Apache 웹서버 설정 관련 파일 : httpd.conf

* Apache 웹서버 자원 관련 파일(초기 아파치) : srm.conf

* Apache 웹서버 보안 접근제어 관련 파일(초기 아파치) : access.conf

-------------------------------------

웹 서비스 메소드 설정 취약점

: GET, POST 메소드 의외의 불필요한 메소드(PUT,DELETE)를 허용하였을때 공격자가 이를 악용하여 중요파일의 삭제 및 수정등이 가능한 취약점

 

대응방안

1. 아파치 웹서버 설정파일(httpd.conf)에 GET POST를 제외한 메소드 차단 설정

 

-------------------------------------

관리자 페이지 노출 취약점

: 관리자 페이지가 쉽게 노출되어있으면 무작위 대입 공격등을 통하여 관리자 권한을 획득할 수 있는 취약점

 

대응방안

1. 추측 가능한 명칭 사용 금지(admin, manager 등)

2. 관리자 페이지 접근제어 설정(아파치 웹서버 설정파일 httpd.conf 설정)

 

-------------------------------------

위치공개 취약점

: 백업파일, 로그파일, 압축파일과 같은 파일이 자동적으로 생성되어 웹상에 노출되어 공격자가 유추(또는 무작위) 후 직접 접근할 수 있는 취약점

예시) http://192.168.56.100/source.tar.gz

 

대응방안

1. 불필요한 파일 삭제 및 적절한 접근제어 설정

-------------------------------------

검색엔진 정보 노출 취약점

: 검색엔진에 의해 웹 사이트 새킹에 필요한 정보가 검색되어 해킹의 빌미가 제공되는 취약점

: 검색엔진의 성능향상에 따라 HTML문서 뿐만 아니라 다양한 문파일의 내용까지 검색하여 의도되지 않은 주소록,회원 정보 등의 개인정보 파일이 노출되는 위험성이 증가

: 로봇배제표준은 디렉터리 및 파일들에 대한 검색조건을 명시해놓은 국제규약으로 robots.txt파일에 기술

: 로봇배제표준은 방지기술이 아닌 검색로봇 운영자 간의 약속(규약)이므로 악의적인 검색엔진의 경우 이를 무시하고 컨텐츠를 수집할 수 있다.

 

* robots.txt 설정방법

- 대소문자 구분

-  띄어쓰기 유의

- 웹사이트 최상위 주소(루트 디렉토리)에 저장해야 한다

User-agent: *(모든 검색로봇)Disallow: /(전체 차단)

 

-------------------------------------

웹 서비스 최소 권한 사용자 운영

: 보안 취약점으로 인해 권한 탈취가 발생할 가능성이 항상 존재하기 때문에 최소한의 권한을 가진 사용자/그룹로 웹 서버 프로세스를 실행해야한다

 

대응방안

1. 웹서버 프로세스를 실행할 별도의 사용자/그룹을 생성, 해당 사용자로 시스템에는 로그인 할 수 없도록 설정

- /etc/passwd 에서 로그인 불가 사용자 설정

apache:x:48:48:Apache-httpd:/var/www:/sbin/nologin (또는 /bin/false)

 

- 아파치 웹서버 설정파일(httpd.conf)에 서버 프로세스의 실행권한을 해당 사용자 및 그룹으로 설정

 

-------------------------------------

심볼릭 링크 사용 설정 제거

: 웹에서 허용하는 디렉터리 외에 다른 디렉터리를 참조하는 링크가 존재하는 경우 해당 링크를 액세스할수 있는 위험성이 존재한다

: 만약 시스템 자체의 루트 디렉터리에 심볼릭 링크를 걸게 되면 웹서버 구동 사용자 권한으로 모든 파일 시스템의 파일에 접근할 수 있게 되는 문제점이 발생한다

 

대응방안

1. 아파치 웹서버 설정파일(httpd.conf)에 모든 디렉터리(/) options지시자에 FollowSymlinks 설정이 되어있으면 제거(또는 None 으로 설정)

 

-------------------------------------

웹 서비스 정보 숨김

: 웹서버 응답 헤더나 에러메시지등에 웹서버 버전, 종류, OS정보 등을 전송하는데 이러한 정보들은 공격에 이용될수 있기 때문에 숨기는 것이 안전하다

 

대응방안

1. 웹서버 응답 헤더에 정보가 제공되지 않도록 아파치 웹서버 설정파일(httpd.conf) ServerTokens Prod로 설정한다

(Prod로 되어있으면 웹서버 종류만 전송)

(Full로 되어있으면 OS정보+설치된 모듈/프로그램 정보를 모두 보낸다는 의미로 매우취약)

 

2. 에러 메시지에 정보가 제공되지 않도록 아파치 웹서버 설정파일(httpd.conf) ServerSignature Off로 설정한다

(On으로 되어있으면 불필요한 정보 제공) 

 

-------------------------------------

웹서버(Apache) 설정파일(httpd.conf) 주요 지시자

 

1. ServerRoot "/etc/httpd"

: 웹 서버가 설치된 최상위 디렉터리 경로를 지정

 

2. Listen 80

: 클라이언트가 접속할 웹서버의 리스닝 포트를 지정

 

3. User nobody

Group nobody

: 서비스를 제공하는 서버 프로세스를 실행할 사용자/그룹을 지정

 

4. ServerTokens Prod

: HTTP 응답 헤더에 최소한의 정보만 제공하도록 Prod 설정

 

5. ServerSignature Off

: 에러메시지에 정보를 제공하지 않도록 Off 설정

 

6. ServerAdmin admin@algisa.com

: 클라이언트 에러메시지에 관리자에게 메일을 보낼수 있는 주소를 전달

 

7. DocumentRoot "/var/www/html"

: 웹 어플리케이션 자원들이 위치하는 최상위 디렉터리를 설정

: 클라이언트 요청 URL상에 명시되는 최상위 디렉터리가 /var/www/html이 되게끔 하는 설정

 

8. DirectoryIndex index.php index.html

: 사용자가 디렉터리만 명시하여 요청할 경우(디렉터리 인덱싱 공격) 이를 처리할 자원 목록을 지정

: 위 설정은 클라이언트가 디렉터리만 명시한 호출에 대해서 해당 디렉터리에 index.php 파일이 있는지 검색하고 없으면 index.html 파일을 검색해서 반환한다.

 

9. LimitRequestBody 5000000

: HTTP 요청 메시지 바디부에 데이터를 담아서 전달할 수 있는 전체 크기를 제한하기 위한 목적(byte 단위)

-------------------------------------

타임아웃 관련 설정

 

1. Timeout 600

: 아무것도 하지 않았을때 끊어지게끔 하는 시간(초 단위)

 

2. KeepAlive On

: 클라이언트와 서버 연결을 일정 조건에 따라 지속시키는 기능을 사용할지 여부를 지정

 

3. MaxKeepAliveRequests 100

: KeepAlive On 시 프로세스 연결 간 허용할 최대 요청 건수

 

4. KeepAliveTimeout 15

: KeepAlive On 시 연결을 지속할 시간(초 단위)

 

5. RequestReadTimeout header=5 body=10

: 지정한 시간(초 단위)에 요청 메시지의 헤더부와 바디부를 모두 수신하지 못한 경우 408(RequestTimeout) 에러 응답 메시지를 반환한다

: slow 계열 http 도스 공격에 효과적으로 대응할 수 있다

 

-------------------------------------

로그 관련 설정

 

1. ErrorLog logs/error_log: 에러 로그(error log) 파일 경로를 지정
: logs/error_log 는 웹서버 최상위 디렉터리 /etc/httpd/ 를 기준으로 /etc/httpd/logs/error_log 를 의미

 

2. CustomLog logs/access_log combined: 액세스 로그(access log)를 저장하기 위한 로그파일의 경로를 지정

-------------------------------------

웹 로그 분석

: 클라이언트 요청으로 웹서버가 응답한 내용은 액세스 로그(access log)에 기록됨

: 웹서버에 오류가 발생했을 경우 에러 로그(error log)에 기록됨

 

웹 로그 종류

1. NCSA CLF: Apache 및 Tomcat의 기본 포맷2. NCSA ELF: CLF에 Referer값과 User-Agent 값이 포함된 포맷

3. W3C ELF

: 윈도우 IIS 기본 포맷, Referer 와 User-Agent를 비롯한 Cookie 및 사용자 정보를 추가로 남길수 있다

 

웹 로그 포맷(Apache의 ELF 포맷)

Host : 클라이언트 호스트명 또는 IP주소Ident : 클라이언트 이름, 보통 - 로 대체Authuser : 인증 요청된 원격 사용자 이름, 보통 - 로 대체Date and Time : 날짜와 시간 정보Request : Client가 보내온 요청 라인 정보(요청메소드  요청URI  HTTP버전<개행>)Status : Client 요청에 대한 상태코드Bytes : 응답데이터의 크기Referer : 요청된 URL이 참조되거나 링크된 URL(이전 페이지 정보)User-Agent : 클라이언트 OS 및 브라우저 버전 정보

 

로그 예시)

 

-------------------------------------

보안서버

: 인터넷상에서 정보를 암호화하여 송수신하는 기능이 구축된 웹서버(SSL/TLS 기반 https 웹서버)

 

* 인증서 확인 과정

1. 신뢰할 수 있는 인증기관이 서명했는지?

2. URL상의 도메인과 인증서/CN/도메인이 일치하는지?

3. 인증서 유효기간 체크

4. 인증서 상태(해지 또는 효력정지 여부 확인) 체크

 

 

* SSL/TLS 관련 보안 가이드

1. 공개키/개인키 생성 시 2024-Bit 이상의 키를 사용하고 서버 개인키에 대한 접근은 최소화하며 안전하게 관리

(개인키 노출 시 폐지해야함)(서버 개인키는 대칭키로 암호화해서 보관)

2. 인증서 발급 시 인증서 서명 알고리즘을 SHA-2(256-bit) 이상으로 설정

(인증서의 내용을 SHA-256로 해쉬 후 해쉬값을 RSA 개인키로 서명)

3. 인증서 발급 시 주체(Subject)/소유자의 CN(Common Name)을 서브 도메인까지 정확히 명시한다

(ex : *.kisa.or.kr 이 아닌 www.kisa.or.kr  로 명시)

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

 

 

* OpenSSL 라이브러리 보안 가이드

1. 취약한 버전의 OpenSSL 라이브러리 버전을 사용할 경우 보안 업데이트를 수행

 

 

* SSL/TLS 웹서버 설정 보안 가이드

1. 취약한 암호화 통신방법으로 알려진 SSL2.0, SSL3.0 프로토콜을 비활성화 하고 TLS1.0~TLS1.3 프로토콜을 사용.

아파치 웹서버 ssl.conf 파일에서 'SSLProtocol -all +TLSv1 +TLSv1.1 + TLSv1.2'  로 설정 시 TLSv1, TLSv1.1, TLSv1.2만 활성화하고 이를 제외한 모든 SSL프로토콜(-all)을 비활성한다는 뜻

2. 취약한 암호방식을 사용하는 암호도구목록(Cipher Suite)을 제거

 

!aNULL : 인증을 하지 않는 Cipher Suite 제거

!eNULL : 암호화를 하지 않는 Cipher Suite 제거

!EXP : 약한 암호키를 사용하는 수출용(EXPORT) Cipher Suite 제거!ADH : ADH(Annoymous Diffie-Hellman)  Cipher Suite 제거, 인증을 안해서 중간자 공격에 취약(EDH 또는 ECDHE 권장)!DES, !RC4, !MD5 : 취약한 암호화 올기리즘 및 해시 알고리즘을 사용하는 Cipher Suite 제거

 

-------------------------------------

이메일 보안

 

주요 프로토콜

SMTP - 메일 전송 프로토콜

: 클라이언트(MUA)와 메일 서버(MTA) 또는 송수신 메일 서버(MTA)간 메일 전송을 위해 사용하는 프로토콜

: TCP/25 port 사용

: SMTP + SSL/TLS = SMTPS (TCP/465 port 사용)

 

POP3 - 메일 접근 프로토콜

: 클라이언트(MUA)에서 메일서버(MTA)로부터 메일을 수신할 수 있도록 해주는 프로토콜

: TCP/110 port 사용

: 서버로부터 메일을 다운로드하고 서버에서 해당 메일을 삭제하기 때문에 다른곳에서 메일 확인이 불가능하다

: POP3 + SSL/TLS = POP3S (TCP/995 port 사용)

 

IMAP - 메일 접근 프로토콜

: 클라이언트(MUA)에서 메일서버(MTA)로부터 메일을 수신할 수 있도록 해주는 프로토콜

: TCP/143 port 사용

: 서버로부터 메일을 복사하기 때문에 메일을 가지고와도 서버에는 해당 메일이 계속 남아 있게 된다

: IMAP + SSL/TLS = IMAPS (TCP/993 port 사용)

 

 

메일 서버 구조

MUA (Mail User Agent)

: 사용자가 메일을 송수신하기 위해 사용하는 메일 클라이언트 프로그램

: 웹메일 프로그램, 아웃룩, 선더버드 등이 있다

 

MTA (Mail Transfer Agent)

: 메일 서버프로그램

: 수신자가 자신의 메일 주소라면 MDA를 통해 각 사용자 메일함에 저장하도록 한다

: 수신자가 자신이 아닌 메일주소면 해당 주소의 메일서버로 전송(SMTP 릴레이 기능)

: 메일을 전송하기 전 보관하기 위한 메일 큐가 있다(메일 큐 경로 : /var/spool/mqueue)

: 센드메일, 큐메일 등이 있다

 

MDA (Mail Delivery Agent)

: 사용자 메일함에 메일을 저장해주는 프로그램(메일함 경로 : /var/spool/mail)

: 프록메일 등이 있다

 

MRA (Mail Retrieval Agent)

: 메일 클라이언트(MUA)가 확인을 요청하는 메일을 사용자 메일함에서 사용자로 전달해주는 프로그램

: POP3, IMAP 프로토콜 사용

 

 

SMTP 메일 형식

- 봉투는 메일서버 간에 메일을 주고받기위한 메일주소 정보를 담고있는 부분

- Mail From과 From은 발신자 메일주소로 악의적으로 조작되는 경우가 있기 때문에 신뢰성이 낮다

- Received 헤더 : 실제 메일이 전송된 경로, Received 헤더가 여러개인 경우 여러 메일서버(MTA)를 경유했다는 의미

(가장 아래쪽에 보이는 헤더가 처음 메일을 발송한 메일서버이고 위로 올라갈수록 거쳐 온 메일서버를 보여준다)

(SMTPS의 경우 SSL/TLS 버전과 Cipher Suite암호도구목록을 확인할 수 있다)

 

- Received-SPF 헤더 : 수신자 메일서버에서 SPF인증 결과를 기록하는 헤더

- Authentication-Results 메시지 헤더 : 수신자 메일서버에서 SPF, DKIM, DMARC 인증 결과를 기록하는 헤더

 

 

SMTP 취약점 및 대응기술

1. 발신 메일서버 조작(스푸핑): 메일 봉투의 MAIL From정보는 조작이 가능

- 대응기술 : 전달받은 메일주소가 실제 서버로부터 온 메일인지 검사할 수 있는 SPF(Sender Policy Framework)를 적용

* SPF 동작방식

- 1. 발신자 도메인 DNS 서버(txt 레코드)에 정보(발신자 메일서버,수신측 처리방식)를 담고있는 SPF 레코드를 등록

- 2. 수신자 메일서버는 메일 수신 시 발신자 도메인 DNS서버에 SPF 레코드를 조회하여 수신여부 결정

 

2. 메일 메시지 훔쳐보기(스니핑) 및 조작(스푸핑)

: 평문 텍스트로 전송하기 때문에 스니핑되거나 스푸핑되는 중간자공격(MITM)이 발생할 수 있다

- 대응기술

: 통신 구간 암호화 적용이 가능한 SMTPS, POP3S, IMAPS 등의 SSL/TLS 기반 프로토콜을 설정

: 발신자 측에서 메일의 메시지에 대한 전자서명을 추가하여 메일의 위변조여부를 검사할 수 있는 DKIM(DomainKeys Identified Mail) 적용

* DKIM 동작방식

- 1. 발신자 도메인 DNS 서버(txt 레코드)에 디지털서명을 검증할 수 있는 정보(공개키, 서명 알고리즘)를 담고 있는 DRIM 레코드를 등록

- 2. 발신자 메일서버에서 발신 메일의 메시지 헤더와 바디를 개인키로 서명한 후 서명값을 DKIM-Signature에 추가하여 전송

- 3. 수신자 메일서버는 발신자 도메인 DNS서버에 DKIM 레코드를 조회하고 DKIM-signature에 있는 서명값을 검증

 

* DMARC(Domain-based Message Authentication, Reporting and conformance) 메일 인증 기술

: 인증 정책을 통해 SPF, DKIM 인증 기술을 모두 적용할 수 있고 인증 결과에 대한 모니터링이 가능한 기술

동작방식

- 1. 발신자 도메인 DNS서버(txt 레코드)에 SPF레코드와 DKIM 레코드를 등록하고 인증정책 정보를 담고있는 DMARC 레코드 정보를 등록

-2. 수신자 메일서버는 SPF,DKIM 및 DMARC 레코드를 조회하고 DMARC정책에 따라 인증을 수행

-------------------------------------

메일서버(sendmail) 보안 설정

: SMTP 릴레이란 메일서버를 경유하여 다른 메일서버로 메일을 발송하는 것을 의미한다. 이때 경유현 메일서버를 SMTP 릴레이 서버라고 한다

: 오픈 릴레이 서버는 발신자에 대한 IP/메일계정 인증 없이 모든 메일을 릴레이 해주는 메일서버로 스팸메일 발신자의 메일서버로 악용된다

 

센드메일(sendmail) 서버 스팸메일 및 릴레이 차단 설정

: 센드메일(sendmail)은 SMTP 프로토콜을 통해서 메일 서버 간 메일을 주고받는 역활을 하는 무료 오픈소스 소프트웨어

: sendmail 8.9 버전 이후부터는 스팸 차단과 관련된 기능이 추가 되었으며 access DB라는 데이터베이스를 이용해 특정 메일의 차단 및 릴레이 제한을 설정할 수 있다

 

/usr/sbin/sendmail : sendmail 주 데몬 실행파일

/usr/sbin/makemap : sendmail 맵 생성 실행파일(access, virtusertable 등의 db파일 생성)

/var/spool/mqueue : 수신한 메일을 임시 저장하는 디렉터리

/var/spool/mail : 개별 사용자 메일함

/etc/mail/access : 스팸메일 및 릴레이 차단을 위한 설정파일

( access 파일은 설정을 위한 텍스트 파일로 실제 정책을 적용하기 위해서는 makemap명령을 이용하여 access.db 파일을 생성해야 한다)

/etc/mail/sendmail.cf : sendmail 설정 파일

 

access 파일 설정

형식 : 적용대상 지정(IP,IP대역,도메인,메일주소) 처리방식 지정

* 처리방식

OK : 지정한 대상의 메일을 조건없이 모두 허용
RELAY : 지정한 대상의 메일 릴레이를 허용

REJECT : 지정한 대상의 메일을 모두 거부(거부 후 거부 메시지를 보냄)

DISCARD : 지정한 대상의 메일을 모두 폐기(거부 메시지를 안보냄)(상대는 정상적으로 처리된것으로 인식)

501 message : 지정한 메일주소(발신자 또는 수신자)와 일치 할 경우 메일을 거부하고 설정한 거부 메시지(message)를 전송

 

예시)192.168.56   RELAY192.168.52.10   REJECTspammail.com   REJECTspam@hacker.com   DISCARD

spam@hacker.com   501   "501 message - you are not allowed"

 

access 파일 적용

: access 파일을 적용하기 위해서는 makemap 명령을 이용하여 access.db 데이터베이스 파일을 생성해야한다

형식 : makemap hash /etc/mail/access.db < /etc/mail/access

 

-------------------------------------

데이터베이스 보안

 

데이터베이스 보안 위협

- 집성(Aggregation) : 낮은 보안 등급의 정보 조각들을 조합하여 높은 보안 등급의 정보를 알아내는 것

- 추론(Interence) : 보안으로 분류되지 않은 정보를 정당하게 접근하여 기밀정보를 유추해내는 행위

 

데이터베이스 보안 통제

- 접근 통제 : 접근 권한의 범위내에서 데이터 접근을 허용하는 기술적인 방법

- 추론 통제 : 통계 정보 등 간접적으로 노출된 데이터를 통해서 기밀/민감 정보가 유추되어 공개되는것을 방지

- 흐름 통제 : 정보의 흐름을 조정하는 것, A테이블의 데이터가 B테이블에 기록되는것을 흐름이라고 한다, 보안 등급이 높은 객체에서 보안등급이 낮은 객체로의 정보 흐름을 제어해야 한다

 

데이터베이스 보안 요구사항 5가지

1. 부적절한 접근 방지(접근 통제)

2. 추론 방지

3. 데이터 무결성

4. 감사 기능

5. 사용자 인증

 

뷰(view) 기반 접근 통제

: 특정 사용자에게 보여줄 컬럼에 대해서만 뷰를 제공함으로써 권한 없는 사용자로부터 민감한 데이터를 은닉시킬 수 있다

ex : CREATE VIEW viewname AS select id, name FROM member

 

SQL 기반의 접근 통제(DCL문 - Grant/Revoke 기법)

: 특정 사용자에게 사용할 수 있는 권한(sql문)을 통제

ex : GRANT select,create,drop,update ON member TO subadmin@localhost WITH GRANT OPTION;

( WITH GRANT OPTION는 부여받은 권한을 사용자가 또 다른 사용자에게 부여할 수 있는 권한 )

( show grants for subadmin@localhost; 명령으로 부여된 권한 확인 가능 )

ex : REVOKE select,create,drop,update ON member TO subadmin@localhost;

 

MySQL 데이터 백업 방식 : 핫 백업(DB서버를 중단하지않고 백업), 콜드 백업(DB서버를 중지 후 백업)

MySQL 데이터베이스 핫 백업 방식 도구 : mysqldump

 

 

데이터베이스 암호화 기술

 

컬럼 암호화 방식 : 테이블의 컬럼 단위로 데이터를 암호화하여 저장하는 방식

1. API 방식

: 응용프로그램에서 암/복호화 모듈을 호출하는 방식

: DB서버 성능저하가 적은 편이지만 구축 시 응용프로그램 전체 또는 일부의 수정이 필요하다

 

2. Plug-In 방식

: 외부에서 제공해주는 암/복호화 모듈을 플러그인으로 호출하는 방식

: 기존 테이블 이름과 동일한 뷰(view)와 변경된 이름의 암호화된 테이블이 생성되고 기존 테이블은 제거된다

: DB서버에서 암/복호화 모듈을 플러그인으로 호출할 떄 추가적인 부하가 발생하여 성능이 저하될 수 있기 때문에 성능에 대한 민감성이 낮은 시스템에 적용하기 적합한 방식

 

3. Hybrid 방식

: API 방식과 Plug-In 방식 혼용

: 대용량 트랜잭션 처리는 API방식을 사용, 나머지 부분은 Plug-In 방식을 사용하여 어플케이션 수정을 최소화

 

 

블록 암호화 방식 : DBMS 블록 또는 파일 블록 단위로 암호화하여 저장하는 방식

1. TDE(Transparent Data Encryption) 방식

: DBMS에 내장되어있는 암/복호화 기능을 이용

: DBMS 커널수준에서 처리되므로 응용프로그램 수정이나 DB스키마 변경이 거의 필요하지 않고 DBMS 엔진에 최적화된 성능을 제공

: DBMS 종류 및 버전에 따라 기능 지원 여부가 결정된다

 

2. 파일 암호화 방식

: 운영체제에서 파일을 암호화하는 방식

: DB뿐만 아니라 이미지,로그 등 다양한 비정형 데이터에 대한 암호화 적용이 가능

: DB서버에 추가적인 부하가 발생할 수 있다

: 운영체제에 따라 지원 여부가 결정된다

 

 

 

My-SQL DBMS 취약점 점검

1. 디폴트 관리자(root) 패스워드 및 계정명을 변경한다(root는 초기에 비밀번호가 없어서 설정한다)

root 비밀번호 변경 : update user set password=password('alpass123!') where user='root';

변경사항 즉시 반영 : flush privileges 

root 계정명 agssk로 변경 : update user set user='agssk' where user='root';

변경사항 즉시 반영 : flush privileges 

 

2. My-SQL 설치 시 서버에 자동으로 생성되는 mysql 계정의 로그인을 차단한다

mysql:x:27:27MySQL Server:/var/lib/mysql:/bin/bash

vi /etc/passwd 명령어로 쉘 /bin/false(또는 /sbin/nologin)로 수정

-> mysql:x:27:27MySQL Server:/var/lib/mysql:/bin/false

 

3. 원격에서 My-SQL 서버로의 접속을 차단한다

: 디폴트 서비스 포트인 TCP/3306 port를 차단하여 로컬에 설치된 어플리케이션에 의해서만 접근 가능하도록 설정

: netstat -antp | grep mysql 명령을 입력하면 3306 port가 열려있는것을 볼 수 있는데 my.cnf 설정파일 mysqld 항목에 'skip-networking' 을 추가 후 재기동하면 네트워크 기능을 비활성화기 때문에 3306 port가 오픈되지 않는다

(하지만 로컬 호스트에서 어플리케이션을 통한 3306 port 접근은 가능하다. 로컬에서는 mysql.sock라는 유닉스 도메인 소켓을 이용해서 통신하기 떄문이다)

 

4. 데이터베이스의 사용자별 접속/권한 설정을 확인한다

: user 테이블에 있는 host 컬럼은 해당 사용자가 데이터베이스에 접근할 수 있는 호스트를 지정하는 컬럼

( host컬럼에 localhost, %(모든 호스트), 특정IP, IP대역 등을 선택해서 제한 가능 )

: 중요 권한인 File_priv(파일에 데이터를 읽고 쓸 수 있는 권한, 외부로 출력 가능), Process_priv(쿼리 모니터링 권한, 비밀번호 변경쿼리도 볼수있기 떄문에 위험), Shutdown_priv(서버를 종료시킬수 있는 권한) 컬럼은 일반 사용자 권한에서 제외

( select user, file_priv, process_priv, shutdown_priv from user; 로 권한 Y 인지 N 인지 확인)

 

5. My-SQL 버전 확인 및 보안패치 적용여부 점검

: mysql -V 또는 mysql --version 명령으로 확인 가능

 

6. My-SQL 데이터 디렉터리 보호여부 점검

: My-SQL 테이블 데이터 및 로그는 파일 형태로 관리되며 권한을 잘못 설정할 경우 일반 사용자 또는 해커에 의해 중요데이터가 삭제되는 사고가 발생할 수 있다

( my.cnf 파일 mysqld 항목에 datadir=/var/lib/mysql 과 같이 My-SQL파일이 저장되는 경로를 알 수 있다 )

( mysql 디렉터리 권한 권장설정은 750 )

 

-------------------------------------

클라우드 컴퓨팅

: 집적/공유된 정보통신기기, 정보통신설비, 소프트웨어 등 정보통신자원을 이용자의 요구나 수요 변화에 따라 정보통신망을 통하여 유동적으로 이용할 수 있도록 하는 정보처리체계를 의미한다

: 가상화를 이용하여 데스크톱, 애플리케이션, 서버, 스토리지, 네트워크 등을 가상화하여 IT자원을 사용할 수 있게 해준다

 

서비스 모델 : 클라우트 컴퓨팅 서비스에 접근할 수 있는 형태에 따른 분류

1. IaaS(Infrastructure as a Service)

: 서버/스토리지/네트워크 등의 하드웨어 인프라 자원만을 사용량 기반으로 제공하는 서비스

ex) 아마존 웹 서비스 - AWS

 

2. PaaS(Platform as a Service)

: 어플리케이션을 개발/테스트/실행 하는데 필요한 OS, 환경 플랫폼(WEB/WAS/DB 등), 개발 언어 프레임워크(스프링, Node.js 등) 등을 제공하는 서비스

ex) MS Azure, Google AppEngine, Oracle Paas Platform 등

 

3. SaaS(Software as a Service)

: 클라우드 환경에서 동작하는 어플리케이션/소프트웨어를 제공하는 서비스

ex) 웹 기반 개인용 스토리지 서비스(n 클라우드, 구글 드라이브, dropbox), 세일즈포스닷컴의 CRM 등

 

 

배치 모델 : 구현방식에 따른 분류

1. 퍼블릭 클라우드 모델

: 불특정 다수를 대상으로 하는 서비스

 

2. 프라이빗 클라우드 모델

: 내부자에게 제한적으로 서비스를 제공하는 형태

 

3. 하이브리드 클라우드 모델

: 퍼블릭 클라우드 모델 + 프라이빗 클라우드 모델, 공유를 원하지 않는 일부 데이터 및 서비스에 대해 프라이빗 정책을 설정하여 서비스를 제공

 

 

클라우드 기반 보안 서비스 : SecaaS (Security as a Service)

: 클라우드를 통해 기존 IT환경(온프레미스)의 인프라 및 서비스에 대한 정보보호 서비스를 제공

 

-------------------------------------

홈페이지 보안 취약점 대응 가이드 - 불안전한 암호화 저장(Insecure Cryptographic Storage)

- 점검방법

1. DB에 저장된 중요정보가 SQL Query 로 열람 가능한지 확인

2. 세션 ID나 암호화된 쿠키값이 명백히 랜덤하게 생성되는지 확인

3. 적절한 암호화 알고리즘이 제대로 적용되었는지 검증

- 조치사항

1. DB에 저장할 중요한 정보(비밀번호, 주민등록번호 등)는 암호화하여 저장

2. 암호화 관련 기능이나 코드 적절성의 구현 가능성을 검증한 후 사용

3. 암호화가 요구되는 정보는 가능하다면 저장하지 않는다

4. 기밀 정보는 최소한 두 군데 이상 분산 저장하고 실행할 때 이를 합쳐서 사용

5. AES, RSA, SAH-256 등 인정받는 알고리즘 사용

-------------------------------------

윈도우 시스템 서비스별 로그파일 경로

IIS 웹 서비스 로그 : %SystemRoot%\system32\LogFiles\W3SVC1

IIS 웹 서비스 오류 로그%SystemRoot%\system32\LogFiles\HTTPERR

IIS FTP 서비스 로그 : %SystemRoot%\system32\LogFiles\MSFTPSVC1

 

DHCP 로그 : %SystemRoot%\system32\dhcp

 

DNS 로그 : %SystemRoot%\system32/dns

-------------------------------------

++

데이터 디들링(data diddling) : 프로그램에서 처리할 원시 데이터 자체를 위변조하거나 미리 바꿔치기할 데이터를 준비해두었다가 데이터를 추가하는 수법, 데이터에 접근 가능한 모든 내부인에 의해 발생할 수 있다

 

살라미 기법 : 프로그램을 악의적으로 변조하여 금액 연산 과정에서 발생하는 끝자리를 반올림 혹은 버림하면ㅅ너 매우적은 금액을 자신의 계좌로 보내는 수법

 

OAuth 2.0

: 인증을 위한 개방형 표준 프로토콜

: 제3자 프로그램에 리소스 소유자를 대신하여 리소스 서버에 제공하는 자원에 대한 접근권한을 위임하는 방식

ex : 구글, 페이스북, 카카오, 네이버 등을 이용해 간편 로그인

주요용어

Authentication(인증) : 클라이언트 신원을 검증

Authorization(인가) : 접근할 권한을 부여

Access Token(접근 토큰) : 리소스 소유자의 보호된 자원을 획득할 때 사용하는 만료기간이 있는 토큰

Refresh Token(갱신 토큰) : Access Token 만료 시 이를 갱신하기 위한 용도로 사용하는 토큰