All posts by Enteroa

mod_pagespeed with apache 2.4.x

구글이 공개한 mod_pagespeed를 컴파일된  apache 2.4 에 설치하는 방법을 설명 한다.
구글의 경우 nginx 의 경우 컴파일 버전을 apache 버전은 rpm 버전으로 제공 하고 있으며
일반적으로 yum 설치되어 /etc/http 안에 위치한경우 rpm 설치만으로 활성화가 가능 하다.

 

다만 컴파일을 해서 prefix 가 다른곳에 있을경우 rpm을 설치한다면 dependency 때문에 yum 으로 httpd 가 설치되어 시스템이 꼬이게 되므로 설치할 수 없는게 일반적인 상식 ‘ㅅ’..

하지만 yum 으로 설치가능한 httpd 의 경우 버전이 매우 낮아 새로운 기술을 전혀 활용하지 못한다… SNI 라던가 HTTP/2 라던가..
때문에 구글이 배포한 rpm을 분해하여 서버에 맞게 편집한뒤에 적용을 한다 ‘ㅅ’b
1. mod_pagespeed 배포 는 https://developers.google.com/speed/pagespeed/module 에서 다운받아서 rpm2cpio 명령어를 이용해 rpm을 분해 한다.

 

2. 압축해제된 파일을 경로에 맞게 수정 이동 시킨다 ‘ㅅ’a  ( 예제 에서 컴파일된 위치는 /usr/local/apache 이다. )

 

3. httpd.conf 에서 pagespeed.conf 파일을 불러오도록 설정 한다.

 

4. 아래는 개인적으로 편집한 pagespeed.conf 파일이다 ‘ㅅ’a

memcache 를 쓴다면 중간에 주석처리된 ModPagespeedMemcached 관련 옵션을 활성화 한다. ‘ㅅ’a

 

외부에서 js 를 가져오는 부분의 속도가 빨라지기 때문에 js를 많이 쓰는 복잡하고 느린 사이트일수록 사이트 가속된것을 체감할수 있는것으로 확인됨 ‘ㅅ’b
그리고 또 js minify 기능이 있기 때문에 별도로 개발자가 신경을 쓰지 않아도 되기 때문에 매우 편한 mod 인듯…

설치를 추천합니다 ‘ㅅ’ b

간혹 캐시 적용으로 사이트가 특정 경로상에 문제가 발생하는 경우 아래와 같이 특정 경로에서 기능을 끄거나
사이트 전제 pagespeed 적용을 해제 할 수 있다.

 

OWASP CRS 룰셋 v3.0.0

기존 v 2.2.9  엄청나게 많은 부분이 바뀌었다. ( 초급자에게 오히려 다루기가 쉬워졌다. )
기존 CRS 를 쓰던 사람은 v3.0.0 으로 업그레이드 하지 말고 새롭게 설치해야 한다.
– 설치 방법은 apache 기준이다. Nginx, IIS 의 경우 포함된 INSTALL 문서를 참조하여 설치해야 한다.
물론 기존에도 spamhouse 연동이나 spam bot의 에이젼트 구분을 하던부분이 있었지만.
projecthoneypot.org 연동으로 기존 룰셋에 비해 스팸 방지 기능이 매우 탁월해 졌다.
– Blocking Based on IP Reputation 부분을 정독하고 SecHttpBlKey 를 연동해야한다.

 

  • git을 이용하여 룰셋 다운로드를 하고 기초 메뉴얼에 따라 파일 명 변경등을 한다.

 

  • httpd.conf 에서 아래와 같이 각 룰셋 등을 불러오도록 설정한다.

 

  • 이후 crs-setup.conf 수정을 한다. ( 사랑해요 구글 번역♥ )

conf 파일중 “Project Honey Pot HTTP Blacklist” 부분은 제공되는 URL을 참조하여 SecHttpBlKey 키를 받아 사용한다.
https://www.projecthoneypot.org 을 접속 한 뒤에 회원 가입 및 메일 인증을 한뒤에 간단히 키를 받을 수 있다.

기초적인 crs-setup 이다 좀더 고급적인 설정을 하려면 하나하나 읽어보고 세팅해야한다 ‘ㅅ’a
Paranoia Level Initialization 선언을 1 이나 2 정도로 하는것이 좋을것으로 생각되며
현재 올려둔 기본 세팅 설정은 level = 1 이다.

 

  • 룰셋 예외 처리

사전 룰셋 예외처리는 rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf 에서 선언된다.

주의할점은 여러줄을 선언할 경우 id:1000 그다음을 id:1001 이런식으로 틀리게 줘야 한다.

사후 룰셋 예외 처리는  rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf 에서 선언이 된다.

Project Honey Pot HTTP Blacklist 에서 구글 봇의 접속조차 막기 때문에 추가 해서 운영하자 ‘ㅅ’a

기존 과 같이 가상호스트 내에서 특정 룰셋만 끄는것 역시 유효 하다.

 

 

PS.1 여기까지 읽기전에 httpd.conf 에서 OWASP csr 룰셋을 불러오는 설정이 httpd-vhost.conf  혹은
         httpd-ssl.conf 보다 먼저 불러와야 한다는걸 눈치챘다면……..    참 잘했어요 🙂

PS.2 apache 2.4.11 보다 낮은 버전의 경우 SecRule 선언을 제대로 인식하지 않을 수 있다.
         이때는 아래 명령어로 여러줄로 되어 있는 Rule 선언을 한줄로 만들어 줘야 한다.

PS.3 아래 명령어로 현재 modscurity 로직에 걸린 error_log 를 확인할 수 있다. IP  ruleID  URL/URI  가 출력된다.
         룰셋 910000 910160 910170 의 경우 악의적인 / 의심되는 / 스패머 IP로 분류되는 것으로 제외하고 본다.


MITM Attack (Man In The Middle attack)

SSL을 운용을 하면 서버 및 클라이언트 간의 통신을 암호화 한다.

다만 암호화 전송을 하는 값을 가로 채서 암호환 된 값을 해석없이 그대로 재 전송 하여 이용할수 있는 해킹 기법을 막기 위해
홈페이지에 HTTP Strict Transport Security / HTTP Public Key Pinning 을 선언해야 한다.
https://ko.wikipedia.org/wiki/중간자_공격 에 대략적인 공격 방식에 대한 설명이 있다.

예시를 들어서 설명을 한다면..

  1. 공격자가 A은행 에서 B은행으로 돈을 보낸다.
  2. 이때 공격자는 A은행에서 B은행으로 전송하는 데이터를 스니핑한다.
  3. 공격자는 암호화된 데이터를 해석하지 않은채로 http 를 이용하여 B은행으로 재 전송을 한다.
  4. HSTS, HPKP 선언이없을경우  B은행의 서버는 정상전송값과 공격자 신호를 구분 없이 계좌에 돈이 쌓인다.
  5. 공격자는 돈을 인출하여 유유히 사라진다.

 

A. HSTS (HTTP Strict Transport Security)

HSTS 선언을 하는 경우 사이트는 HTTPS 로 강제 고정이 되기 때문에 외부 HTTP 를 연동하여 서비스 되는 부분이 있을경우
해당 연결이 끊어질 수 있다. 기본적으로 forced HTTPS 가 적용된 사이트에서는 HTTP 컨텐츠를 불러올 수 없다.
아울러 인증서가 만료되는경우 이 HSTS설정 때문에 접속이 아예 불가능할 수 있다.

HSTS 는 몇번 언급을 한적이 있는데 Header SET 을 통해 선언 하며 forced HTTPS 가 적용된 사이트는 속도상 이점이 생긴다. – 선언된 Header 에 의해서 접속한 도메인은 HTTPS 통신만 사용한다는 선언이다.

.htaccess 혹은 웹서버의 가상호스트 에 선언하면 된다.

 

B. HPKP (HTTP Public Key Pinning)

HPKP는 인증서의 pin을 공개함으로서 통신에 사용된 인증서가 pin과 비교함으로서 위조된 인증서를 구분할 수 있다.
즉 선언을 할때 pin 코드는 인증서에서 추출해야 함으로 인증서가 교체되는 경우 pin 역시 교체를 해야한다.

첫번째 pin-sha256 의 경우 HTTPS 통신에 사용된 인증서의 pin 코드 이다.
두번째 pin-sha256는 서버에서 생성한 csr을 가지고 생성하는 코드 이며 백업 pin 코드 이다.

인증서(crt파일) 에서 pin 을 확인하는 방법이다.

CSR파일에서 pin 을 확인 하는 방법이다. (백업키 생성을 위해 쓴다.)

 

Let’s encrypt 를 이용했을때 약 2개월 단위로 인증서가 교체가 된다…. 즉 HPKP pin 역시 2개월 단위로 변경…을 해야 한다.
물론 백업키는 변경할 필요가 없겠지만…

이건 아무래도 귀찬기 때문에 스크립트 만들어야 겠다 ‘ㅅ’a

crontab 에 등록된 스크립트의 한글 처리.

주기적인 작업을 crontab 에 등록하여 운영을 할때 캐릭터셋이 중요한 경우가 발생한다.
일반적으로 CentOS 리눅스 서버에는 i18n 설정이 되어 캐릭터셋이 운영 된다.

물론 CentOS7의 경우는 변경 되었다. ( /etc/locale.conf )

 

anyway.. cron 에 등록해서 적용하는경우 이러한 설정이 반영되지 않고 en_US가 기본 캐릭터셋으로 돌아간다 ‘ㅅ’a
때문에 캐릭터셋이 중요한 스크립트에서는 export LANG=ko_KR.eucKR 과 같이 선언을 하거나 source /etc/sysconfig/i18n내용을 호출하여 $LANG 가 정상 동작 하도록 한다 ‘ㅅ’a

echo $LANG 의 값이 euckr 혹은 utf8이 아닐 경우 i18n 혹은 locale.conf 을 불러오거나 현재 문서의 인코딩 셋을 LANG 으로 지정하도록 만든 로직 이다 ‘ㅅ’a (centos5 이하의 file 명령어 버전 차이때메동작 제대로 안됨..)

 

일반적으로 utf8서버에서 생성된 파일은 utf-8인코딩 셋일 꺼고 euc-kr 에서 생성된 파일은 euckr 문서일꺼기 때문에 =_=a
일반적인 상황에서는 export LANG=utf8 과 같은 선언으로도 충분하다.

다만 서버 관리 특성상 shell script의 버전관리를 통해 자동 배포를 하고(svn 혹은 git 처럼..)
받아서 쓰는 서버의 캐릭터셋이 예측할수 없을때 유용할 수 있음.

CentOS에서 whois 명령어를 이용한 도메인 정보 조회

CentOS 즉 레드햇 계열의 리눅스에는 jwhois 를 이용하여 linux 콘솔에서 도메인 정보조회를 할 수 있다.
설치는 yum 으로 진행을 할 수 있다.

사용법 다음과 같이 매우 간단하다.

 

다만 쓰다 보니 이것저것 불편한것이 많았다.

  1. new TLDs 가 전혀 조회가 되지 않는다.
  2. 브라우져에서 복사해서 바로 조회 할경우 http 혹은 https 까지 복제 되어 실패한다.

 

new TLDs 를 조회하기 위해서 /etc/jwhois.conf 파일을 새로운 conf 파일로 대체 한다.

 

whois 명령어를 조회해보니 아래와 같이 whois 명령어가 jwhois 명령어로 링크되어 있다.

때문에 먼저 whois 명령어를 삭제하고 새롭게 명령어를 만든다.

그리고 동작이 좀 더 되도록 입력값을 수정해서 작동되게 한다.

~]# whois https://www.enteroa.com 이 된다.
아~ 편하다 ‘ㅅ’a