기사 자격증(알기사, 웹 보안 - HTTP)

HTTP(하이퍼텍스트 전송 프로토콜)

- 웹에서 웹페이지를 가져오기 위해 어떻게 클라이언트 - 서버 프로그램이 작성될 수 있는지 정의하는데 사용

- 서버는 80번 포트, 클라이언트는 임시포트를 사용한다.

- HTTP 1.0은 비영속적 연결, 1.1은 영속전 연결을 사용한다.

 

영속적 연결과 비영속적 연결

1. 영속적 연결

 - 서버는 응답을 전송 후 차후 요청을 위해 연결을 열어놓은 상태를 유지

 - 서버는 클라이언트 요청, 타임아웃 시 연결을 닫을 수 있음

 - HTTP 1.1은 Keep-Alive 옵션이 추가됨 - 연결 상태를 일정시간 지속시킬 수 있음

 

2. 비영속적 연결

 

 - 각 요구 / 응답에 대해 하나의 TCP 연결이 만들어짐 → 하나 응답 후 서버 닫음

 - 서버는 연결마다 다른 버퍼들을 필요로함

 - 오버헤드가 크다.

 

HTTP의 트랜잭션

- 웹 브라우저가 웹 서버에 하나의 요청을 보내고 웹 서버가 요청을 처리하는 응답을 전송하는 한번의 과정

- HTTP의 TCP 서비스를 이용하지만, HTTP자체는 상태가 존재하지 않는 프로토콜이다.

 → 클라이언트에 대한 정보를 서버가 저장하고 있지 않다

- 클라이언트는 요청메시지를 보내어 트랜잭션을 초기화하고 서버는 응답을 보내어 대답을 한다.

- HTTP 트랜잭션 과정

 1. 웹 브라우저가 웹 서버가 설치된 호스트에 연결

 2. 웹 브라우저는 요청 메시지를 만든다.

 3. 웹 브라우저는 요청메시지를 전송하고 대기

 4. 웹 서버는 요청 메시지를 받고 헤더와 데이터로 분리

 5. 웹 서버는 요청을 처리하고 응답 메시지를 만든다.

 6. 웹 서버는 응답 메시지를 웹 브라우저에 보내고 강제로 연결을 끊는다.

 

HTTP의 요청메시지

 

1. 요청 라인

 - 요청 메시지의 첫 줄은 요청 라인이라 한다.

 - 요청 라인에는 Method URL, Version의 필드가 존재한다.(MUV)

 - 세 개의 필드는 공백 문자로 구분되어야 한다.

2. 메소드

 - 요청 유형이라고 부름

 - 메소드 종류

지시자	설명
GET	ㆍ가장 일반적인 HTTP 요청 형태 ㆍ인수를 URL을 통해 전송 ㆍ이름과 값을 &로 결합 ㆍ글자수는 255자로 제한 ㆍ최소한의 보안도 유지되지 않는 방식
HEAD	ㆍ서버 응답시 응답 메시지 바디를 제외한 헤더 부분만 답해주는 메소드 ㆍURL / 링크의 유효성을 검증하기 위해 사용
POST	ㆍURL 요청 데이터를 전달하지 않음 ㆍ바디 영역에 소켓을 이용하여 데이터 전달 ㆍ최소한의 보안은 갖추고 있음 ㆍ게시판 등에서 업로드시 사용
PUT	ㆍ헤더 및 몸체를 포함하여 몸체에 콘텐츠 내용을 덧붙여 원격지 서버에 지정한 콘텐츠를 저장 목적으로 사용 ㆍ악용시 페이지 변조에 사용됨
DELETE	ㆍ클라이언트가 권한이 있으면 서버에서 웹 페이지를 제거하는 것을 혀용함
TRACE	ㆍ디버깅에 사용 ㆍ서버에 에코백을 요청해 서버가 요청을 받고 있는지 여부 확인
OPTIONS	ㆍ시스템에서 지원되는 메소드 종류를 확인할 수 있다.
CONNECT	ㆍ서버에 프락시 기능 요청시 사용

- 바디 존재 유무

지시자	요청에 body가 있음	응답에 body가 있음
GET	NO	YES
POST	YES	YES
HEAD	NO	NO
PUT	YES	YES
DELETE	NO	YES
CONNECT	YES	YES
OPTIONS	선택	YES
TRACE	NO	YES
PATCH	YES	YES

 

3. 요청 헤더라인

 - 요청라인 이후 0개 이상 요청 헤더라인을 가질 수 있다.

 - 헤더라인의 주요 요청 헤더정보

  1. host

  2. User-Agent

  3. Referer

  4. 콘텐츠 길이

  5. 쿠키

 

4. 빈 라인

 - 헤더의 끝을 의미하는 개행

 - 헤더의 개수가 가변이기 때문에 빈라인으로 끝을 식별함

 

5. 본체

 - PUT, POST일 때 송신될 주석, 웹사이트에 게시될 파일을 담고 있음

 - GET 방식은 요청데이터가 없기 때문에 본체부분이 존재하지 않음

 

HTTP 트랜잭션 응답메시지

1. 상태라인

 - 응답 메시지의 첫 줄은 상태 라인이라고 부른다

 - Version, Status code, Phrase으로 구분(VSP)

 

Version

  - HTTP 프로토콜의 버전을 의미

  - 현재 HTTP는 1.1이다.

 

Status code

 - 요청의 상태를 정의

 - 요청상태코드

구분	코드	표현	설명
정보	100	continue	요청 메시지 첫 부분이 서버 도착, 클라이언트느 게속 요청 가능
	101	Switching	서버는 upgrade 헤더에 정의된 프로토콜 변환 위해 클라이언트 요청 수락
성공	200	Ok	요청 성공
	201	Created	put 메소드 이용해 서버에 파일이 정상적 생성됨
	202	Accepted	요청 수락, 바로 실행되지 않음
	204	No content	헤더의 바디 부분에 데이터 X
재지정	300	Multiple choice	요청된 URL이 여러개의 데이터 명시
	301	Moved premanently	브라우저 요청을 다른 URL로 항시전달
	302	Moved temporarily	브라우저 요청을 임시 URL로 바꾸고 Location 헤더에 임시로 변경한 URL에 대한 정보를 적음, 클라이언트가 다음에 같은 요청을 하면 기존 URL로 돌아감
	304	Not modified	브라우저가 서버에 요청한 자료에 대해 서버는 클라이언트 내 복사된 캐시를 사용하면 된다는 것을 의미
클라이언트 오류	400	Bad request	요청 메시지의 문법오류
	401	Unauthorized	요청 메시지의 적합한 인증 부족
	403	Fobbiden	클라이언트 요청에 대한 접근 차단
	404	Not Found	클라이언트가 서버에 요청한 자료가 존재하지 않음
	405	Method not allowed	클라이언트 요청에 이용한 메소드가 해당 URL에서 지원하지 않음
	406	Not accepted	요청한 형식 거부
서버 오류	500	Internal server error	메시지 손상과 같은 오류 발생
	501	Not implemented	요청한 메소드 수행 불가
	503	Service unavailable	잠시동안 서비스 사용 불가

 

2. 응답 헤더 라인

 - 상태 라인 이후 0개 이상의 응답 헤더 라인을 가질 수 있다.

 - 각 헤더 라인은 서버에서 클라이언트로 추가적 정보를 보낸다.

 - 주요 헤더 정보

 1. Content - Type

 2. Content - Length

 

3. 빈 라인

 - 헤더의 끝을 의미

 - 헤더 개수가 가변적이기 때문에 빈 라인으로 끝을 식별함

 

4. 본체

 - 서버에서 클라이언트로 전송되는 문서를 포함

 - 응답이 오류 메시지가 아니라면 본체가 존재

 

SSL / TLS

- 클라이언트 - 서버 환경서 TCP 기반 Application에 대한 종단간 보안서비스 제공 위해 만들어진 전송계층 프로토콜이다.

- 대칭키 암호, 일방향 해시함수, MAC, 의사난수 생성기, 전자서명을 조합해 안전한 통신 수행

- 암호 스위트를 변경하여 강력한 알고리즘 사용

※ 암호스위트 : SSL / TLS 암호화 통신에 사용할 여러 가지 알고리즘을 선택하게 되는데 이 때 암호 알고리즘 협의 및 선택된 알고리즘의 집합을 암호스위트라고 한다.

- 특정 암호기술에 의존하지 않는다.

- SSL / TLS 상 HTTP 통신 vs 일반 HTTP 통신

1. 일반 HTTP 통신

 

2. SSL / TLS 상 HTTP 통신

 

- SSL과 TLS 차이점

1. SSL 버전 3.0은 POODLE 공격에 취약성이 발견되었기 때문에 안전하지 않다.

2. SSL은 1994년 개발, TLS는 1999년 개발

2. TLS 1.0 = SSL 3.1

3. TLS 1.1에 암호 알고리즘으로 AES 추가

4. TLS 1.2에 인증암호로 GCM, CCM이 추가되고 HMAC-256이 추가, IDEA, DES는 삭제되었다.

 

TLS 프로토콜

- 가장 널리 사용하는 보안 서비스 중 하나

- 현재 버전은 TLS 1.2로 RFC5246에 정의됨

- 안전한 소켓 계층(SSL)에서 진화되었음

- TLS는 TCP에 의존하는 프로토콜로 구현되었다.

- TLS는 응용계층과 전송계층 사이에서 동작

- TLS 구조

 

1. TLS는 TCP를 활용한 2계층 프로토콜이다.

2. Record 프로토콜은 TLS 최하위 계층 프로토콜로서 단편화, 응용계층에서 오는 데이터뿐만 아니라 상위 프로토콜에서 오늘 메시지 전송

3. hand shake 프로토콜은 Record 프로토콜에 대한 보안 매개변수를 제공

4. ChangeCipherSpec 프로토콜은 handshake에서 정한 보안 매개변수를 상대에게 신속히 전송

5. Alert 프로토콜은 비정상 조건을 알리는데 사용

6. Heartbeat 프로토콜은 프로토콜 개체의 가용성을 모니터링 할 때 사용하는 프로토콜

 

Handshake 프로토콜

- 프로토콜에 대한 보안 매개변수 제공하는 프로토콜

- 서버와 클라이언트가 서로 인증, 암호화 MAC 알고리즘, TLS 레코드 안에 보낸 데이터 보호하는데 사용할 암호키 협상을 함

- 핸드셰이크 프로토콜 구성 필드

유형(1byte)

길이(3byte) - 메시지 길이

내용(0byte 이상) - 메시지와 연관된 매개변수

 

- 메시지 유형

유형	매개변수
hello-request	null
client- hello	버전, 랜덤, 세션 id, 암호도구, 압축방법
server-hello	버전, 랜덤, 세션 id, 암호도구, 압축방법
certificate	연속된 X.509v3 인증서
server_key_exchange	매개변수, 서명
certificat_request	유형, 기관
server_hello_done	null
certificate_verify	서명
client_key_exchange	매개변수, 서명
finished	해시값

 

- handshaking 과정

 1. 초기 협상단계 : 프로토콜 버전, 세션 ID, 암호 스위트 압축방법, 초기 난수 등을 포함한 보안 능력 구축

 2. 서버 인증단계 : 서버는 인증서와 키 교환 전송하고 인증서를 요청, hello 메시지 종료 시그널 전송

 3. 클라이언트 인증단계 : 클라이언트는 요청이 있을시 인증서 전송, 키교환 전송, 인증서 확인 전송

 4. 종료단계 : 암호 스위트 변경 후 핸드셰이크 프로토콜 종료

 

- 단계별 세부 내용

초기 인증단계

 1. HelloRequest

  - 서버가 클라이언트에게 Client hello 메시지를 보내어 협상을 시작하자고 요구하는단계

  - 현재 협상이 진행 중이면 클라이언트는 이 메시지 무시

  - 서버는 HelloRequest를 보내고 이에대한 Handshake 끝나지 않은 상태에서 또 다시 HelloRequest를 보내면 안된다.

 

 2. ClientHello

  - 클라이언트가 서버에 처음 연결 시작 또는 HelloRequest 메시지 대한 응답으로 보내는 메시지

  - 세션 식별자, 암호 스위트 리스트, 클라이언트가 지원하는 압축 알고리즘 리스트, 클라이언트 SSL 버전, 클라이언트가 생성한 난수를 서버에 전달

   1. random : 재전송 공격을 막기 위함(randomnumber에 시간과 날짜를 포함하는 이유 = 재전송 공격을 막기 위함), 각각의 연결마다 비밀키 새롭게 생성 가능

   2. session_id : 클라이언트가 처음 세션 생성시 empty전송, 이미 생성된 세션 재사용시 재사용하고자 하는 세션 ID를 전송

   3. 암호 스위트 : 서버에게 자신의 암호스위트를 전송, 서버는 암호스위트 중 하나 선택

 

 3. ServerHello

  - 서버는 클라이언트의 HelloRequest 응답으로 Server Hello를 보내게 된다.

  - 세션식별자, 선택한 암호스위트, 선택한 압축방법, 서버 SSL 버전, 서버가 생성한 난수를 클라이언트에게 전달

   1. server_version : 서버가 지원하는 SSL/TLS 버전과 Client_version중 낮은버전을 선택

   2. random : 재사용 공격 막고, key_block 만들 때 사용

   3. session_id : 현재 접속중인 세션 ID, 만약 empty이면 새로운 세션 ID 생성해 보내어 Full Handsake 진행, 그렇지 않으면 받은 session_id에 새로이 연결을 생성하는 abbreviate handshake 진행

   4. 암호스위트 : 클라이언트가 보낸 암호스위트 목록 중 한 개 선택

1단계가 끝나면 서버와 클라이언트가 알게 되는 정보 1. SSL 버전 2. 암호스위트 3. 압축방법 4. 키 생성을 위한 2개의 난수

 

서버 인증 단계

1. ServerCertificate

 - 서버의 인증이 필요한 경우 ServerHello뒤에 서버 인증서가 포함된 Certificate를 보냄

 - 서버의 인증서는 선택된 암호스위트 키 교환 알고리즘과 타입이 맞아야함

 

2. ServerKey Exchange

 - 서버의 인증서를 보내지 않거나, 보낸 인증서에 키 교환에 필요한 정보가 부족할 때 전송되는 msg

 

3. Certificate Request

 - 서버가 자신을 클라이언트에게 인증과 동시에 클라이언트의 인증서를 통한 요구를 할 수 있다.

 - 이 msg 사용시 서버와 클라이언트의 상호 인증이 가능해짐

 - 필수 단계는 아니고 클라이언트의 요청이 들어왔을 경우 실행

 

4. ServerHelloDone

 - 서버가 인증을 위한 msg를 모두 보냈다고 알려주는 msg

 - Certificate Request msg가 선택적으로 사용되기 때문에 클라이언트는 이 msg가 도착할 때 까지 기다린다.

2단계(서버인증과 키교환)후에 1. 서버는 클라이언트에 대해 인증이 된다. 2. 클라이언트는 필요하다면 서버의 공개키를 알 수 있다.

 

3단계 : 클라이언트 인증

1. ClientCertificate

 - 서버가 클라이언트의 인증을 요구하는 경우 클라이언트가 보내는 msg

 

2. ClientKeyExchange

 - 클라이언트가 세션키를 생성하기 위해 비밀정보 48byte생성

 - 선택된 공개키 알고리즘을 이용하여 서버와 pre_master_key를 공유

 

3. CertificateVerify

 - 클라이언트 인증서의 명백한 확인을 위해 클라이언트는 핸드쉐이크 msg를 전자서명해 전송

3단계(클라이언트 인증과 키 교환)후에 1. 클라이언트는 서버에 대한 인증 2. 클라이언트와 서버 양측은 마스터 비밀키를 알게 된다.

 

4단계 : 종료단계

1. ChangeCipherSpec, Finished

 - ChangeCipherSpec 메시지는 handshake 프로토콜에 포함되는 것은 아니고 이 메시지 이후 전송되는 msg는 새롭게 협상된 알고리즘과 키를 이용할 것임을 나타냄

 - Finished msg는 ChangeCipherSpec msg 이후 전송되며 협상된 알고리즘과 키가 처음으로 적용됨

 - Finished msg로 상대방은 협상 결과를 확인하게 된다.

 - 서버는 ChangeCipherSpec, Finished msg를 클라이언트에게 보내고 TLS 핸드셰이크 프로토콜 수행을 마친다.

 - TLS 연결이 마치게 되면 연결을 통해 데이터가 전송되기 시작

4단계가 끝나면 서버와 클라이언트는 데이터 교환을 위한 준비가 완료됨

 

Record 프로토콜

- TCP 프로토콜 이용

- 적용 / 변경된 보안 파라미터 이용하여 실제 암호화 / 복호화, 무결성 보호, 압축 / 압축해제 등 기능 제공

- TLS Record 프로토콜이 제공하는 2가지 서비스

 1. 기밀성

 2. 무결성

 3. 단편화

 

ChangeCipherSpec 프로토콜

- ChangeCipherSpec 메시지는 바로 직전에 협상된 CipherSpec과 키에 의하여 보호될 후속 레코드를 상대에게 알리기 위하여 클라이언트 또는 서버에 의해 전송

- 종단 간 협상된 보안 파라미터를 이후부터 적용 / 변경함을 알리기 위해 사용하는 프로토콜

- 1byte로 구성 1을 갖는 한 개의 msg로 구성

 

Alert 프로토콜

- SSL / TLS 통신 과정서 발생하는 오류를 통보하기 위해 경고 할 때 사용

- Alert는 경고 msg와 경고에 대한 상세 정보 전달(치명적 레벨의 Alert msg는 연결을 즉시 단절하게 됨

 

Heartbeat프로토콜

- 정상적으로 동작한다는걸 나타내기 위해 다른 부분과 동기화 하기 위해 H/W나 S/W가 생성하는 주기적 신호

- Heartbeat 프로토콜은 가용성을 모니터링 할 때 사용함

 

SSL/TLS 공격

- heartbeat프로토콜의 확장이라는 기능에 요구 데이터 길이에 대한 점검 결여로 인해 메모리상 관계없는 정보까지 상대방에게 넘어가 버리는 공격

- 공격자는 heartbleed 공격으로 서버의 정보를 일정범위까지 훔칠 수 있다.

- 대책으로는 취약성 대책이 실행된 버전으로 OpenSSL 갱신, heartbeat 확장 사용을 하지 않는옵션을 부착해 재컴파일 하는 방법이 있다.

- 또한 이미 유출되었을 가능성이 있기 때문에 인증서 재발급, 취약점 조치 완료 후 비밀번호 재설정울 유도하여 추가피해를 막아야 한다.

 

POODLE 공격

- 공격자가 TLS를 SSL 3.0으로 다운그레이드한 통신을 강요하여 MITM(중간자 공격)을 통해 암호화 되어 송ㆍ수신되는 쿠키정보, 데이터를 추출하게 하는 공격

- POODLE 공격을 막는 방법으로는 SSL 3.0을 사용하지 않는 것이다.

 

FREAK 공격과 암호 수출 규제

- 프랑스 국립 연구소와 MS사에서 SSL을 통해 강제로 취약한 RSA로 다운그레이드 시킬 수 있는 취약점을 발견했다.

- FREAK는 SSL / TLS 서버에서 약함 암호스위트를 사용하게 하는 공격이다.

- 대응책으로는 OpenSSL 최신버전 업그레이드 취약점에 영향 받는 OS 및 브라우저 업그레이드가 있다.

 

완전 순방향 비밀성(PFS)

- SSL / TLS 통신시 서버 공개키와 개인키를 이용한 키 교환시 공격자는 MITM공격으로 트래픽 가로채고 송ㆍ수신 데이터를 복호화가 가능하다.

- 희생자는 유출되었다는 것을 알고 유출된 서버 인증서를 폐기하여도 유출된 서버 개인키로 보호되는 이전 트래픽 정보를 공격자가 보관하고 있다면 이들 모두 복호화 된다는 문제점이 있다.

- 이를 해결하기 위한 암호학적 성질을 PFS, FS(순방향 비밀성)이라고 한다.

- PFS는 서버 개인키가 노출되어도 이전 트래픽 정보의 기밀성은 그대로 유지되는 암호학적 성질을 말한다. → 서버 개인키 노출이 되어도 공격자는 통신 내용 확인이 불가능하다.

 

HTTPS

- SSL을 이용하는 HTTP를 HTTPS라고 한다.

- 현재 HTTPS는 모든 웹브라우저에 내장되어 있다.

- HTTP와의 차이라면 HTTP는 http://로 시작하지만 HTTPS는 https://로 시작한다.

- 또한 HTTP는 포트번호 80번을 이용하지만 HTTPS는 포트번호 443번을 이용한다.

- HTTPS는 기밀성, 클라이언트, 서버 인증, 데이터 무결성을 제공한다.

- HTTPS 사용시 암호화되는 통신요소

 1. 요청문서 URL

 2. 문서 내용

 3. 브라우저 양식 내용

 4. 브라우저가 서버에게 보낸 쿠키와 서버가 브라우저에게 보낸 쿠키

 5. HTTP 헤더내용

- HTTPS는 중간자공격은 어렵게 하지만, 사용자 입력값 검증은 하지 못 한다.

 

S-HTTP

- 기존 HTTP에 보안기능을 추가하기 위해 확장함

- HTTP로 전송되는 내용을 보안하는데 중점을 두었음

- HTTPS는 안전한 전용 통신망을 통해 메시지를 보내지만 S-HTTP는 메시지가 암호화 서명이 되어 기존 TCP / IP망을 이용한다.

- HTTPS는 통신채널과 메시지 둘다 보호하지만, S-HTTP는 메시지만 보호한다.

- S-HTTP의 중요 특징

 1. 기존의 HTTP 특성을 유지하고 있음

 2. 여러 가지 다양한 암호기능 지원

 3. 협상과정을 통해 다양한 암호 알고리즘 모드, 매개변수 설정 가능

 4. shttp:// 사용

 

IIS 보안설정

1. IIS

 - 마이크로소프트 윈도우를 사용하는 서버들을 위한 인터넷 기반 서비스들의 모임

 - IIS의 보안설정

 

2. 권한설정

 - 특정자원에 대해서 읽기, 쓰기, 삭제, 실행 등의 기능을 필요에 따라 부여 / 회수

 - 만약 적절한 권한을 부여하지 않으면 비인가자나 공격자에 의해 주요 자원이 훼손될 수 있다.

 

3. 관리자 페이지 접근통제

 - 웹 어플리케이션의 관리자 페이지가 추측 가능한 형태로 구성되어 있을 경우, 공격자가 관리자 페이지에 쉽게 접근이 가능하고 무작위 대입공격을 통해 관리자 권한을 쉽게 획득할 수 있다.

 - 웹 / 서버 페이지등에 접근하는 사용자 IP주소 등을 통해서 통제한다.

 - 아파치에서 관리자 페이지 접근통제하는 방법

<Directory "var/www/html/admin"> Order Deny,Allow Deny from all Allow from 192.168.20.1 </Directory> Order 지시자는 Allow, Deny의순서로 명시 → Deny의 설정이 우선

 

4. 메소드 제한

 - 불필요한 메소드 설정을 할 경우 서버측의 주요 자원이 삭제가 되는 등 피해를 입을 수 있다.

 - 그러므로 필요한 경우가 아니면, GET, POST를 제외한 모든 메소드는 제거하는 것이 좋다.

<LimitExcept GET,POST> Order Allow, Deny Deny from all </LimintExcept>

 - 아파치에서 메소드 제한하기

 

5. 헤더정보 숨기기

 - 사용자 요청에 의해서 서버가 응답을 보낼 때 헤더에 포함되는 정보에는 서버에 대한 정보(서버명, 버전)등이 포함되므로 공격자가 해당서버에 공격을 시도할 때 정보로 이용될 수 있다.

 

Apache 보안설정

- 예전 Apache에서는 root 권한으로 실행되는 경우가 많았는데 이럴 경우 웹 프로세스는 막강한 권한을 가지게되어 보안사고가 빈번히 발생하였다.

- 이를 막기위해 최소권한의 사용자ID와 그룹을 생성하는 것이 안전한데 이때 사용하는 게저이 nobody 계정이다.

 

hpptd.conf

- 아파치의 설정파일로써 아파치 보안설정을 담당함

- 주요 내용

 1. ServerType : 서버를 standalone방식, inetd 방식으로 운영할지 결정, 일반적인 웹은 standalone 형태로 운영된다.

  ※standalone : 사용자 요청을 직접 웹 데몬이 받아서 처리

      inetd : 사용자 요청을 inetd 데몬이 받아서 처리

 

 2. Timeout : 클라이언트에서 완벽한 처리를 하지 못할 때 클라이언트와 연결을 헤제하는데 기다려주는 시간

 

 3. KeepAlive(On) : 사용자의 요청 연결에 대해 한번의 요청만 처리할지 아니면 또 다른 요청을 기다리게 할지를 설정, Off 설정시 클라이언트로부터 한 번의 요청을 받은 후 바로 접속을 해제하게됨

 

 4. MaxKeepAliveRequest : KeepAlive 상태서 처리할 최대 요청 처리 건수

 

 5. KeepAliveTimeout : KeepAlive 상태를 유지할 시간을 초단위로 설정

 

 6. MinSpareServer : 아파치가 실행될 때 최소 예비프로세스 수 설정

 

 7. MaxSpareServer : 아파치 실행될 때 최대 예비프로세스 수 설정

 

 8. MaxClients : 동시 접속자 수 정의, 최대값은 256, 만약 256이상의 값을 설정하려면, httpd.h 헤더파일의 HARD_SERVER_LIMIT 부분을 수정하고 아파치 다시 컴파일

 

 9. MaxRequestsPerChild : 아파치의 자식 프로세스가 처리할 수 있는 최대 요청 처리건수 0은 무제한

 

 10. User : 자식 프로세스가 생성될 때 그 프로세스의 소유자와 소유그룹을 결정

 

 11. Port : 아파치가 사용할 기본포트 정의

 

 12. Options : 지정한 디렉터리 이하에 모든 파일과 디렉터리들에 적용할 접근제어 설정

  ※ Indexes : 디렉터리 내 파일목록리스트를 웹 브라우저로 보여줌, 서버보안을 위해 사용하지 않는 것이 좋음(제거는 Options -Indexs)

       FollowSymlinks : 심볼릭 링크를 허용, 이 옵션 지정시 웹브라우저의 링크파일 경로까지 확인이 가능함, 보안상 설정을 하지 않는 것이 좋다(제거 : Options -FollowSymlinks)

 

 13. ErrorLog : 아파치 서버 접속 에러를 기록할 이름 설정하는 곳

 

 14. ServerSignature : 서버 배너 정보를 나타내는 곳, 서버 정보 은닉을 위해 Off로 변경

 

 15. ServerTokens : 서버의 정보 표시제한 설정

  1. ProductOnly : 웹 서버 종류만 표시

  2. Minimal : 웹 서버 종류와 버전 정보 표시

  3. OS : 웹 서버 종류와 버전, 운영체제 정보 표시

  4. Full : 웹 서버 종류와 버전, 운영체제, 설치된 모듈 정보 표시

 

- 아파치 보안 모듈

 1. mod_setenvif : 요청의 성격이 정규표현식에 해당여부로 환경변수 설정

 2. mod_rewrite : 규칙기반 URL 동적전환 및 재작성 할 수 있게 해주는 확장모듈

 3. mod_security : 웹 공격에 대한 침입탐지 및 침입방지 기능 추가

  - mod_security 기능

   1. 요청 필터링

   2. 우회방지 기술

   3. HTTP 프로토콜 이해

   4. POST 페이로드 분석

   5. 감사로깅

   6. HTTP 필터링

 

 4. mod_dosevasive : Dos 공격을 막기 위해 사용하는 모듈

 

- 아파치 로그 기록내용

 1. 접속한 클라이언트 IP, 도메인 주소

 2. 사용자 이름

 3. 클라이언트 접속시간 정보

 4. 클라이언트 요청메시지(POST,GET)

 5. 클라이언트가 요청한 홈페이지 URL 주소

 6. 프로토콜 버전

 7. 상태코드

 8. 전송 데이터 크기

 

- Apache Web log의 LogFormat 변수명

 1. %m : 요청 메소드

 2. %H : 요청 프로토콜

 3. %u : 클라이언트 사용자

 4. %U : 요청한 URL

 5. %s : HTTP 실행결과 코드

 6. %h : 클라이언트 도메인 또는 IP주소