Apache 웹 서버 강화 및 보안 가이드

게시 됨: 2015-02-14

Apache HTTP Server를 보호하고 강화하기 위한 실용적인 가이드입니다.

웹 서버는 웹 기반 응용 프로그램의 중요한 부분입니다. Apache Web Server는 종종 네트워크의 가장자리에 위치하므로 공격에 가장 취약한 서비스 중 하나가 됩니다.

기본 구성을 사용하면 해커가 응용 프로그램 공격에 대비하는 데 도움이 될 수 있는 많은 민감한 정보를 제공할 수 있습니다. 웹 애플리케이션 공격의 대부분은 XSS, Info Leakage, Session Management 및 SQL Injection 공격을 통해 이루어지며, 이는 취약한 프로그래밍 코드와 웹 애플리케이션 인프라를 살균하지 못하기 때문입니다.

Positive Technologies의 흥미로운 연구에 따르면 스캔한 애플리케이션의 52%가 높은 취약점을 가지고 있었습니다.

취약점 보고

이 기사에서는 Linux 플랫폼에서 Apache HTTP 서버를 보호하기 위한 몇 가지 모범 사례에 대해 설명합니다.

다음은 Apache 2.4.x 버전에서 테스트되었습니다.

  • 이것은 UNIX 플랫폼에 Apache를 설치했다고 가정합니다. 그렇지 않은 경우 설치 가이드를 참조할 수 있습니다.
  • 이 가이드 전체에서 Apache 설치 디렉토리를 /opt/apache라고 $Web_Server로 부를 것입니다.
  • 수정하기 전에 기존 구성 파일을 백업하는 것이 좋습니다.

청중

이것은 미들웨어 관리자, 응용 프로그램 지원, 시스템 분석가 또는 강화 및 보안 지침을 배우고자 하는 모든 사람을 위해 설계되었습니다.

Apache Web Server 및 UNIX 명령에 대한 공정한 지식은 필수입니다.

메모

일부 구현 확인을 위해 HTTP 헤더를 검사하려면 몇 가지 도구가 필요합니다. 두 가지 방법이 있습니다.

  1. 브라우저에 내장된 개발자 도구를 사용하여 HTTP 헤더를 검사합니다. 일반적으로 네트워크 탭 아래에 있습니다.
  2. 온라인 HTTP 응답 헤더 검사기 도구 사용

서버 버전 배너 제거

사용 중인 웹 서버 버전을 노출하고 싶지 않기 때문에 이것이 가장 먼저 고려해야 할 사항 중 하나라고 말하고 싶습니다. 버전을 노출한다는 것은 해커가 정찰 프로세스를 가속화하는 데 도움이 된다는 의미입니다.

기본 구성은 아래와 같이 Apache 버전 및 OS 유형을 표시합니다.

아파치 서버 배너

  • $Web_Server/conf 폴더로 이동
  • vi 편집기를 사용하여 httpd.conf 수정
  • 다음 지시문을 추가하고 httpd.conf를 저장하십시오.
 ServerTokens Prod ServerSignature Off
  • 아파치 재시작

ServerSignature 는 Apache에서 생성한 페이지에서 버전 정보를 제거합니다.

ServerTokens 는 헤더를 프로덕션 전용(예: Apache)으로 변경합니다.

아래에서 볼 수 있듯이 버전 및 OS 정보가 사라졌습니다.

아파치 서버 배너 마스크

디렉토리 브라우저 목록 비활성화

브라우저에서 디렉토리 목록을 비활성화하면 방문자가 루트 또는 하위 디렉토리 아래에 있는 모든 파일과 폴더를 볼 수 없습니다.

기본 설정에서 어떻게 보이는지 테스트해 보겠습니다.

  • $Web_Server/htdocs 디렉토리로 이동
  • 폴더를 만들고 그 안에 몇 개의 파일을 만듭니다.
 # mkdir test # touch hi # touch hello

이제 http://localhost/test를 통해 Apache에 접근해 봅시다.

아파치 디렉토리 목록

당신이 볼 수 있듯이 그것은 당신이 가지고 있는 모든 파일/폴더를 드러내고 당신이 그것을 드러내고 싶지 않다고 확신합니다.

  • $Web_Server/conf 디렉토리로 이동
  • vi를 사용하여 httpd.conf 열기
  • 디렉토리를 검색하고 옵션 지시문을 없음 또는 -인덱스로 변경하십시오.
 <Directory /opt/apache/htdocs> Options -Indexes </Directory>

(또는)

 <Directory /opt/apache/htdocs> Options None </Directory>
  • 아파치 재시작

참고 : 환경에 여러 Directory 지시문이 있는 경우 모두에 대해 동일한 작업을 수행하는 것을 고려해야 합니다.

이제 http://localhost/test를 통해 Apache에 접근해 봅시다.

비활성화된 디렉토리 목록

보시다시피 테스트 폴더 목록을 표시하는 대신 금지된 오류를 표시합니다.

에탁

원격 공격자가 Etag 헤더를 통해 inode 번호, 다중 부분 MIME 경계 및 자식 프로세스와 같은 민감한 정보를 얻을 수 있습니다.

이 취약점을 방지하기 위해 아래와 같이 구현해보자. PCI 규정 준수를 위해 수정해야 합니다.

  • $Web_Server/conf 디렉토리로 이동
  • 다음 지시문을 추가하고 httpd.conf를 저장하십시오.
 FileETag None
  • 아파치 재시작

권한이 없는 계정에서 Apache 실행

기본 설치는 nobody 또는 daemon으로 실행됩니다. Apache에 대해 권한이 없는 별도의 사용자를 사용하는 것이 좋습니다.

여기에서 아이디어는 보안 허점이 발생할 경우 실행 중인 다른 서비스를 보호하는 것입니다.

  • apache라는 사용자 및 그룹 생성
 # groupadd apache # useradd –G apache apache
  • 아파치 설치 디렉토리 소유권을 새로 생성된 권한 없는 사용자로 변경
 # chown –R apache:apache /opt/apache
  • $Web_Server/conf로 이동
  • vi를 사용하여 httpd.conf 수정
  • User & Group Directive 검색 후 비권한 계정 아파치로 변경
 User apache Group apache
  • httpd.conf 저장
  • 아파치 재시작

http 프로세스를 실행하기 위한 grep 및 아파치 사용자로 실행 중인지 확인

 # ps –ef |grep http

하나의 프로세스가 루트로 실행되고 있는 것을 볼 수 있습니다. Apache가 포트 80에서 수신 대기 중이고 루트로 시작해야 하기 때문입니다.

바이너리 및 구성 디렉토리 권한 보호

기본적으로 바이너리 및 구성에 대한 권한은 서버의 모든 사용자가 구성을 볼 수 있음을 의미하는 755입니다. 다른 사용자가 conf 및 bin 폴더에 들어가는 것을 허용하지 않을 수 있습니다.

  • $Web_Server 디렉토리로 이동
  • bin 및 conf 폴더의 권한 변경
 # chmod –R 750 bin conf

시스템 설정 보호

기본 설치에서 사용자는 .htaccess를 사용하여 아파치 구성을 재정의할 수 있습니다. 사용자가 Apache 서버 설정을 변경하지 못하도록 하려면 아래와 같이 AllowOverride 를 None 으로 추가할 수 있습니다.

이 작업은 루트 수준에서 수행해야 합니다.

  • $Web_Server/conf 디렉토리로 이동
  • vi를 사용하여 httpd.conf 열기
  • 루트 수준에서 디렉토리 검색
 <Directory /> Options -Indexes AllowOverride None </Directory>
  • httpd.conf 저장
  • 아파치 재시작

HTTP 요청 방법

HTTP 1.1 프로토콜은 필요하지 않을 수 있는 많은 요청 방법을 지원하며 그 중 일부는 잠재적인 위험이 있습니다.

일반적으로 웹 애플리케이션에 GET, HEAD, POST 요청 메서드가 필요할 수 있으며, 이는 해당 Directory 지시문에서 구성할 수 있습니다.

기본 구성은 HTTP 1.1 프로토콜의 OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT 방법을 지원합니다.

  • $Web_Server/conf 디렉토리로 이동
  • vi를 사용하여 httpd.conf 열기
  • 디렉토리를 검색하고 다음을 추가하십시오.
 <LimitExcept GET POST HEAD> deny from all </LimitExcept>
  • 아파치 재시작

추적 HTTP 요청 비활성화

기본적으로 Trace 방법은 Apache 웹 서버에서 활성화됩니다.

이 기능을 활성화하면 Cross Site Tracing 공격을 허용하고 잠재적으로 해커에게 쿠키 정보를 훔칠 수 있는 옵션을 제공할 수 있습니다. 기본 구성에서 어떻게 보이는지 봅시다.

  • 수신 포트가 있는 텔넷 웹 서버 IP 수행
  • 아래와 같이 TRACE 요청을 합니다.
 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 200 OK Date: Sat, 31 Aug 2013 02:13:24 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 20 TRACE / HTTP/1.1 Host: test 0 Connection closed by foreign host. #

위의 TRACE 요청에서 볼 수 있듯이 내 쿼리에 응답했습니다. 비활성화하고 테스트해 보겠습니다.

  • $Web_Server/conf 디렉토리로 이동
  • 다음 지시문을 추가하고 httpd.conf를 저장하십시오.
 TraceEnable off
  • 아파치 재시작

수신 포트가 있는 텔넷 웹 서버 IP를 수행하고 아래와 같이 TRACE 요청을 합니다.

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 405 Method Not Allowed Date: Sat, 31 Aug 2013 02:18:27 GMT Server: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1> <p>The requested method TRACE is not allowed for the URL /.</p> </body></html> Connection closed by foreign host. #

위의 TRACE 요청에서 볼 수 있듯이 HTTP 405 Method Not Allowed로 내 요청을 차단했습니다.

이제 이 웹 서버는 TRACE 요청을 허용하지 않으며 Cross Site Tracing 공격을 차단하는 데 도움이 됩니다.

HttpOnly 및 Secure 플래그로 쿠키 설정

쿠키에서 HttpOnly 및 Secure 플래그를 사용하여 일반적인 교차 사이트 스크립팅 공격의 대부분을 완화할 수 있습니다. HttpOnly 및 Secure가 없으면 웹 응용 프로그램 세션 및 쿠키를 도용하거나 조작할 수 있으며 위험합니다.

  • httpd.conf에서 mod_headers.so가 활성화되어 있는지 확인하십시오.
  • $Web_Server/conf 디렉토리로 이동
  • 다음 지시문을 추가하고 httpd.conf를 저장하십시오.
 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
  • 아파치 재시작

클릭재킹 공격

클릭재킹은 잘 알려진 웹 애플리케이션 취약점입니다.

  • httpd.conf에서 mod_headers.so가 활성화되어 있는지 확인하십시오.
  • $Web_Server/conf 디렉토리로 이동
  • 다음 지시문을 추가하고 httpd.conf를 저장하십시오.
 Header always append X-Frame-Options SAMEORIGIN
  • 아파치 재시작

아파치 x 프레임 옵션

X-Frame-Options는 여기서 설명한 두 가지 추가 옵션도 지원합니다.

서버 측 포함

SSI(서버 측 포함)는 서버의 부하를 증가시킬 위험이 있습니다. 환경과 트래픽이 많은 웹 응용 프로그램을 공유한 경우 옵션 지시문에 포함을 추가하여 SSI 비활성화를 고려해야 합니다.

SSI 공격은 HTML 페이지에 스크립트를 삽입하거나 원격으로 코드를 실행하여 웹 애플리케이션의 악용을 허용합니다.

  • $Web_Server/conf 디렉토리로 이동
  • vi를 사용하여 httpd.conf 열기
  • 디렉토리를 검색하고 옵션 지시문에 Include를 추가하십시오.
 <Directory /opt/apache/htdocs> Options –Indexes -Includes Order allow,denyAllow from all </Directory>
  • 아파치 재시작

참고: 환경에 여러 Directory 지시문이 있는 경우 모두에 대해 동일한 작업을 수행하는 것을 고려해야 합니다.

X-XSS 보호

XSS(교차 사이트 스크립팅) 보호는 많은 브라우저에서 우회할 수 있습니다. 사용자가 비활성화한 경우 웹 응용 프로그램에 대해 이 보호를 적용할 수 있습니다. 이것은 Facebook, Twitter, Google 등과 같은 대다수의 거대 웹 회사에서 사용합니다.

  • $Web_Server/conf 디렉토리로 이동
  • vi를 사용하여 httpd.conf를 열고 다음 헤더 지시문을 추가하십시오.
 Header set X-XSS-Protection "1; mode=block"
  • 아파치 재시작

보시다시피 XSS-Protection은 응답 헤더에 삽입됩니다.

아파치-xss

HTTP 1.0 프로토콜 비활성화

보안에 대해 이야기할 때 최대한 보호해야 합니다. 그렇다면 이전 HTTP 버전의 프로토콜을 사용하는 이유는 무엇입니까? 또한 비활성화합시다.

HTTP 1.0은 세션 하이재킹과 관련된 보안 취약점이 있습니다. mod_rewrite 모듈을 사용하여 이것을 비활성화할 수 있습니다.

  • httpd.conf 파일에 mod_rewrite 모듈을 로드해야 합니다.
  • 다음과 같이 RewriteEngine 지시문을 활성화하고 HTTP 1.1만 허용하도록 Rewrite 조건을 추가합니다.
 RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1.1$ RewriteRule .* - [F]

시간 초과 값 구성

기본적으로 아파치 타임아웃 값은 300초로, 슬로우로리스 공격과 DoS의 희생양이 될 수 있다. 이를 완화하기 위해 시간 초과 값을 60초 정도로 낮출 수 있습니다.

  • $Web_Server/conf 디렉토리로 이동
  • vi를 사용하여 httpd.conf 열기
  • httpd.conf에 다음을 추가하십시오.
 Timeout 60

SSL

SSL을 갖는 것은 웹 애플리케이션에 추가하는 보안의 추가 계층입니다. 그러나 기본 SSL 구성은 특정 취약성을 유발하므로 이러한 구성을 조정하는 것을 고려해야 합니다.

SSL 키

SSL 키를 깨는 것은 어렵지만 불가능한 것은 아닙니다. 그것은 단지 계산 능력과 시간의 문제일 뿐입니다.

아시다시피 2009년 시대의 PC를 약 73일 동안 사용하면 512비트 키를 리버스 엔지니어링할 수 있습니다.

따라서 키 길이가 길수록 SSL 키를 깨는 것이 더 복잡해집니다. 대부분의 거대 웹 회사들은 아래와 같이 2048비트 키를 사용하는데 우리는 왜 안쓰나요?

  • 아웃룩닷컴
  • 마이크로소프트닷컴
  • 라이브닷컴
  • 스카이프닷컴
  • 애플닷컴
  • 야후닷컴
  • 빙닷컴
  • Hotmail.com
  • 트위터닷컴

OpenSSL을 사용하여 아래와 같이 2048비트로 CSR을 생성할 수 있습니다.

 openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

서명하기 위해 인증 기관에 보내야 하는 CSR을 생성합니다. 서명된 인증서 파일을 받으면 httpd-ssl.conf 파일에 추가할 수 있습니다.

 SSLCertificateFile #Certificate signed by authority SSLCertificateChainFile #Certificate signer given by authority SSLCertificateKeyFile #Key file which you generated above
  • Apache 웹 서버를 다시 시작하고 https로 URL에 액세스하십시오.

SSL 암호

SSL Cipher는 인터넷을 통해 두 컴퓨터 간의 키로 사용되는 암호화 알고리즘입니다. 데이터 암호화는 일반 텍스트를 비밀 암호 코드로 변환하는 프로세스입니다.

웹 서버 SSL Cipher 구성을 기반으로 데이터 암호화가 수행됩니다. 따라서 더 강력하고 취약하지 않은 SSL Cipher를 구성하는 것이 중요합니다.

  • $Web_Server/conf/extra 폴더로 이동
  • 더 높은 암호화 알고리즘만 허용하도록 httpd-ssl.conf의 SSLCipherSuite 지시문을 아래와 같이 수정합니다.
 SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4
  • 구성 파일을 저장하고 Apache 서버를 다시 시작하십시오.

참고: SSL 감사 보고서에 약한 암호가 많은 경우 !를 추가하여 빠르게 거부할 수 있습니다. 처음에.

SSL v2 및 v3 비활성화

SSL v2 및 v3에는 많은 보안 결함이 있으며 침투 테스트 또는 PCI 규정 준수를 위해 작업하는 경우 SSL v2/v3을 비활성화하기 위해 보안 검색 결과를 닫아야 합니다.

모든 SSL v2/v3 통신은 데이터 변조 또는 공개를 허용할 수 있는 중간자 공격에 취약할 수 있습니다.

최신 TLS만 수락하고 SSL v2/v3 연결 요청을 거부하도록 Apache 웹 서버를 구현해 보겠습니다.

  • $Web_Server/conf/extra 폴더로 이동
  • TLS 1.2+만 허용하도록 httpd-ssl.conf의 SSLProtocol 지시문을 아래와 같이 수정합니다.
 SSLProtocol –ALL +TLSv1.2

SSL 구성이 끝나면 온라인 SSL/TLS 인증서 도구로 웹 애플리케이션을 테스트하여 구성 오류를 찾는 것이 좋습니다.

모드 보안

Mod Security는 Apache와 함께 사용할 수 있는 오픈 소스 웹 응용 프로그램 방화벽입니다.

컴파일하고 설치해야 하는 모듈로 제공됩니다. 상업용 웹 애플리케이션 방화벽을 사용할 여유가 없다면 탁월한 선택이 될 것입니다.

일반 웹 애플리케이션 보호를 제공하기 위해 핵심 규칙은 다음 기술을 사용합니다.

  • HTTP 보호 – HTTP 프로토콜 및 로컬에서 정의된 사용 정책 위반 감지
  • 실시간 블랙리스트 조회 – 타사 IP 평판 활용
  • 웹 기반 맬웨어 감지 - Google Safe Browsing API에 대한 검사를 통해 악성 웹 콘텐츠를 식별합니다.
  • HTTP 서비스 거부 보호 – HTTP 플러딩 및 느린 HTTP DoS 공격에 대한 방어.
  • 일반적인 웹 공격 보호 – 일반적인 웹 애플리케이션 보안 공격 탐지
  • 자동화 탐지 – 봇, 크롤러, 스캐너 및 기타 악성 표면 활동 탐지
  • 파일 업로드를 위한 AV 스캐닝과 통합 – 웹 애플리케이션을 통해 업로드된 악성 파일을 식별합니다.
  • 민감한 데이터 추적 – 신용 카드 사용을 추적하고 누출을 차단합니다.
  • 트로이 목마 보호 – 트로이 목마에 대한 액세스를 감지합니다.
  • 애플리케이션 결함 식별 – 애플리케이션 구성 오류에 대한 경고.
  • 오류 감지 및 숨기기 – 서버에서 보낸 오류 메시지를 위장합니다.

다운로드 및 설치

Apache와 함께 Mod Security를 ​​사용하려는 서버에 다음 전제 조건이 설치되어 있어야 합니다. 이들 중 하나라도 존재하지 않으면 Mod Security 컴파일이 실패합니다. Linux 또는 Centos에서 yum install을 사용하여 이러한 패키지를 설치할 수 있습니다.

  • 아파치 2.x 이상
  • libpcre 패키지
  • libxml2 패키지
  • liblua 패키지
  • libcurl 패키지
  • libapr 및 libapr-util 패키지
  • Apache 웹 서버와 함께 번들로 제공되는 mod_unique_id 모듈

이제 안정적인 최신 버전의 Mod Security 2.7.5를 여기에서 다운로드해 보겠습니다.

  • 다운로드한 파일을 /opt/apache로 전송
  • modsecurity-apache_2.7.5.tar.gz 추출
 # gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –
  • 압축을 푼 폴더로 이동하십시오. modsecurity-apache_2.7.5
 # cd modsecurity-apache_2.7.5
  • 기존 Apache에 대한 apx 경로를 포함하여 구성 스크립트를 실행합니다.
 # ./configure –with-apxs=/opt/apache/bin/apxs
  • make 스크립트로 컴파일 및 설치
 # make # make install
  • 설치가 완료되면 /opt/apache 아래의 모듈 폴더에 mod_security2.so가 표시됩니다.

이제 이것으로 기존 Apache 웹 서버에 Mod Security 모듈을 설치했습니다.

구성

Apache에서 Mod 보안 기능을 사용하려면 httpd.conf에 mod 보안 모듈을 로드해야 합니다. mod_unique_id 모듈은 Mod Security의 전제 조건입니다.

이 모듈은 Mod Security에서 추적하고 사용하는 각 요청에 대한 고유 식별자가 있는 환경 변수를 제공합니다.

  • httpd.conf에서 Mod Security용 모듈을 로드하고 구성 파일을 저장하려면 다음 행을 추가하십시오.
 LoadModule unique_id_module modules/mod_unique_id.so LoadModule security2_module modules/mod_security2.so
  • 아파치 웹 서버 다시 시작

이제 Mod Security가 설치되었습니다!

다음으로 해야 할 일은 Mod Security 핵심 규칙을 설치하여 해당 기능을 최대한 활용하는 것입니다.

최신 핵심 규칙은 다음 링크에서 무료로 다운로드할 수 있습니다. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • 다운로드한 핵심 규칙 zip을 /opt/apache/conf 폴더에 복사합니다.
  • 핵심 규칙 파일 압축 풀기
  • 폴더 이름을 짧고 기억하기 쉬운 이름으로 변경할 수 있습니다. 이 예에서는 이름을 crs로 변경하겠습니다.
  • crs 폴더로 이동하여 modsecurity_crs10_setup.conf.example의 이름을 modsecurity_crs10_setup.conf로 바꿉니다.

이제 이러한 규칙을 활성화하여 Apache 웹 서버에서 작동하도록 합시다.

  • httpd.conf에 다음을 추가하십시오.
 <IfModule security2_module> Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf </IfModule>

위 구성에서 Mod Security 기본 구성 파일 modsecurity_crs_10_setup.conf와 Mod Security Core Rules에서 제공하는 기본 규칙 base_rules/*.conf를 로드하여 웹 애플리케이션을 보호합니다.

  • 아파치 웹 서버 다시 시작

Apache로 Mod Security를 ​​성공적으로 구성했습니다!

잘했어요. 이제 Apache 웹 서버는 Mod Security 웹 응용 프로그램 방화벽으로 보호됩니다.

시작하기

웹 애플리케이션을 강화하고 보호하기 위해 Mod Security의 몇 가지 중요한 구성을 시작하겠습니다.

이 섹션에서는 /opt/apache/conf/crs/modsecurity_crs_10_setup.conf에서 모든 구성 수정을 수행합니다.

이 섹션에서는 /opt/apache/conf/crs/modsecurity_crs_10_setup.conf를 예시 목적으로 setup.conf로 참조합니다.

무료로 제공되는 OWASP 규칙이 무엇인지 이해하는 것이 중요합니다. OWASP에서 제공하는 규칙에는 두 가지 유형이 있습니다.

기본 규칙 – 이 규칙은 엄격한 테스트를 거쳤으며 아마도 오경보 비율이 더 낮을 것입니다.

실험 규칙 – 이 규칙은 실험 목적을 위한 것이며 높은 오경보가 있을 수 있습니다. 프로덕션 환경에서 사용하기 전에 UAT에서 구성, 테스트 및 구현하는 것이 중요합니다.

선택적 규칙 – 이러한 선택적 규칙은 전체 환경에 적합하지 않을 수 있습니다. 귀하의 요구 사항에 따라 사용할 수 있습니다.

CSRF, 사용자 추적, 세션 하이재킹 등 보호를 찾고 있다면 선택적 규칙 사용을 고려할 수 있습니다. OWASP 다운로드 페이지에서 다운로드한 crs zip 파일을 추출한 후 기본, 선택 및 실험 규칙이 있습니다.

이러한 규칙 구성 파일은 crs/base_rules, crs/optional_rules 및 crs/experimental_rules 폴더에서 사용할 수 있습니다. 몇 가지 기본 규칙에 대해 알아보겠습니다.

  • modsecurity_crs_20_protocol_violations.conf: 이 규칙은 허용되지 않는 프로토콜(HTTP 1.0)을 사용하여 응답 분할, 요청 밀수와 같은 프로토콜 취약성으로부터 보호합니다.
  • modsecurity_crs_21_protocol_anomalies.conf: 헤더에 Host, Accept, User-Agent가 없는 요청으로부터 보호하기 위한 것입니다.
  • modsecurity_crs_23_request_limits.conf: 이 규칙은 요청 크기, 업로드 크기, 매개변수 길이 등과 같은 특정 애플리케이션에 종속됩니다.
  • modsecurity_crs_30_http_policy.conf: CONNECT, TRACE, PUT, DELETE 등과 같이 허용되거나 허용되지 않는 방법을 구성하고 보호합니다.
  • modsecurity_crs_35_bad_robots.conf:악의적인 로봇 탐지
  • modsecurity_crs_40_generic_attacks.conf: OS 명령 주입, 원격 파일 포함 등으로부터 보호하기 위한 것입니다.
  • modsecurity_crs_41_sql_injection_attacks.conf: SQL 및 블라인드 SQL 주입 요청을 보호하기 위한 이 규칙입니다.
  • modsecurity_crs_41_xss_attacks.conf: Cross-Site Scripting 요청으로부터 보호.
  • modsecurity_crs_42_tight_security.conf: 디렉토리 탐색 탐지 및 보호.
  • modsecurity_crs_45_trojans.conf:이 규칙은 일반 파일 관리 출력, HTTP 백도어 페이지 업로드, 알려진 서명을 감지합니다.
  • modsecurity_crs_47_common_exceptions.conf: Apache 내부 더미 연결, SSL 핑거 등으로 인해 발생할 수 있는 일반적인 오탐지를 제거하는 예외 메커니즘으로 사용됩니다.

벌채 반출

로깅은 Mod Security가 수행하는 작업에 대한 로그를 생성할 수 있도록 구성할 첫 번째 항목 중 하나입니다. 사용 가능한 로깅에는 두 가지 유형이 있습니다. 디버그 및 감사 로그.

디버그 로그: Apache 오류, 경고 및 오류 로그의 알림 메시지를 복제합니다.

감사 로그: Mod Security 규칙에 의해 표시된 트랜잭션 로그를 작성합니다. Mod Security는 감사, 디버그 또는 둘 다 로깅을 구성할 수 있는 유연성을 제공합니다.

기본적으로 구성은 두 로그를 모두 작성합니다. 그러나 요구 사항에 따라 변경할 수 있습니다. 로그는 SecDefaultAction 지시문에서 제어됩니다. setup.conf의 기본 로깅 구성을 살펴보겠습니다.

 SecDefaultAction “phase:1,deny,log”

디버그, 감사 로그 기록 - "log" 사용 감사 로그만 기록 - "nolog,auditlog" 디버그 로그만 기록 - "log,noauditlog" 사용 SecAuditLog에서 제어하는 ​​저장할 감사 로그 위치를 지정할 수 있습니다. 지령.

/opt/apache/logs/modsec_audit.log에 아래와 같이 추가하여 감사 로그를 작성해 봅시다.

  • setup.conf에 SecAuditLog 지시문을 추가하고 Apache Web Server를 다시 시작하십시오.
 SecAuditLog /opt/apache/logs/modsec_audit.log
  • 다시 시작하면 modsec_audit.log가 생성되는 것을 볼 수 있습니다.

규칙 엔진 활성화

기본적으로 엔진 규칙은 꺼짐입니다. 즉, 규칙 엔진을 활성화하지 않으면 Mod Security의 모든 이점을 활용하지 못하는 것입니다.

규칙 엔진 활성화 또는 비활성화는 SecRuleEngine 지시문에 의해 제어됩니다.

  • setup.conf에 SecRuleEngine 지시문을 추가하고 Apache Web Server를 다시 시작하십시오.
 SecRuleEngine On

SecRuleEngine에는 세 가지 값이 있습니다.

  • 켜기 – 규칙 엔진을 활성화하기 위해
  • 끄기 – 규칙 엔진 비활성화
  • DetectionOnly – 규칙 엔진을 활성화하지만 차단, 거부, 삭제, 허용, 프록시 또는 리디렉션과 같은 작업은 실행하지 않습니다.

규칙 엔진이 켜지면 Mod Security가 몇 가지 일반적인 공격 유형으로 보호할 준비가 됩니다.

일반 공격 유형 보호

이제 웹 서버는 Core Rule을 설치하고 Rule Engine을 켜서 XSS, SQL Injection, Protocol Violation 등과 같은 일반적인 공격 유형으로 보호할 준비가 되었습니다. 그 중 몇 가지를 테스트해 보겠습니다.

XSS 공격

  • Firefox를 열고 응용 프로그램에 액세스하고 끝에 또는 URL에 <script> 태그를 넣습니다.
  • apache/logs 폴더의 modsec_audit.log 모니터링

Mod Security는 XSS 공격의 루트인 <script> 태그를 포함하고 있으므로 요청을 차단한다는 것을 알 수 있습니다.

디렉토리 순회 공격:- 디렉토리 순회 공격은 이 취약점을 이용하고 시스템 관련 파일에 액세스하여 많은 피해를 줄 수 있습니다. 예 – /etc/passwd, .htaccess 등

  • Firefox를 열고 디렉토리 탐색으로 애플리케이션에 액세스
  • apache/logs 폴더의 modsec_audit.log 모니터링
 http://localhost/?../.../boot
  • Mod Security는 디렉토리 탐색을 포함하므로 요청을 차단한다는 것을 알 수 있습니다.

서버 배너 변경

이 가이드의 앞부분에서 Apache 및 OS 유형, ServerTokens 지시문 버전 도움말을 제거하는 방법을 배웠습니다.

한발 더 나아가서 서버 이름을 원하는 대로 유지하는 것은 어떻습니까? Mod Security의 SecServerSignature 지시문으로 가능합니다. 흥미롭군요.

참고: Mod Security를 ​​사용하여 헤더에서 서버 배너를 조작하려면 Apache 웹 서버의 httpd.conf에서 ServerTokesn을 Full로 설정해야 합니다.

  • setup.conf에서 원하는 서버 이름으로 SecServerSignature 지시문을 추가하고 Apache Web Server를 다시 시작하십시오.
 SecServerSignature YourServerName

전:

 [/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf SecServerSignature geekflare.com [/opt/apache/conf/crs] #

일반 구성

모범 사례로 몇 가지 일반적인 구성을 확인해 보겠습니다.

수신 구성

단일 서버에 여러 인터페이스와 IP가 있는 경우 절대 IP 및 포트 번호로 구성된 Listen 지시문을 사용하는 것이 좋습니다.

일부 포트 번호가 있는 모든 IP에서 수신 대기하도록 아파치 구성을 남겨두면 HTTP 요청을 다른 웹 서버로 전달하는 데 문제가 발생할 수 있습니다. 이것은 공유 환경에서 매우 일반적입니다.

  • 아래 표시된 예와 같이 절대 IP 및 포트를 사용하여 httpd.conf에 Listen 지시문을 구성합니다.
 Listen 10.10.10.1:80

액세스 로깅

웹 서버에서 액세스 로그를 올바르게 구성하는 것이 필수적입니다. 로그에서 캡처해야 할 중요한 매개변수 중 일부는 요청을 처리하는 데 걸리는 시간인 SESSION ID입니다.

기본적으로 Apache는 이러한 데이터를 캡처하도록 구성되어 있지 않습니다. 다음과 같이 수동으로 구성해야 합니다.

  • 액세스 로그에서 요청 및 SESSION ID를 제공하는 데 걸린 시간을 캡처하려면
  • LogFormat 지시문 아래 httpd.conf에 %T 및 %sessionID 추가
 LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

Apache Web Server의 LogFormat 지시문에서 지원되는 매개변수의 전체 목록은 http://httpd.apache.org/docs/2.2/mod/mod_log_config.html을 참조하십시오.

원하지 않는 모듈 로드 비활성화

모든 모듈과 함께 컴파일 및 설치한 경우 Apache에 로드된 많은 모듈이 있을 가능성이 높으며 이는 필요하지 않을 수 있습니다.

가장 좋은 방법은 웹 애플리케이션에서 필수 모듈로 Apache를 구성하는 것입니다. 다음 모듈에는 보안 문제가 있으며 Apache Web Server의 httpd.conf에서 비활성화하는 데 관심이 있을 수 있습니다.

WebDAV(웹 기반 분산 저작 및 버전 관리) 이 모듈을 사용하면 원격 클라이언트가 서버의 파일을 조작하고 다양한 서비스 거부 공격을 받을 수 있습니다. httpd.conf에서 다음 주석을 비활성화하려면

 #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so #Include conf/extra/httpd-dav.conf

정보 모듈 mod_info 모듈은 이 모듈이 로드되면 .htaccess를 사용하여 민감한 정보를 유출할 수 있습니다. httpd.conf에서 다음 주석을 비활성화하려면

 #LoadModule info_module modules/mod_info.so

참조: 다음 링크의 안내 없이는 불가능합니다.

  • http://httpd.apache.org/docs/2.4/
  • http://www.modsecurity.org/documentation/
  • https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

이것이 Apache 웹 서버를 보호하는 데 사용할 수 있는 모범 사례 중 일부였습니다.

Apache에서 사용자 정의 오류 페이지를 구현하려면 이 링크를 확인하십시오.

Apache HTTP가 처음이라면 Apache HTTP 관리 과정을 수강하는 것이 좋습니다.