카테고리 Archives: linux

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

데이터베이스 마이그레이션

EUC-KR 에서 UTF-8 로 DB마이그레이션을 진행할때 캐릭터셋 전환에 따라 일부 문자가 유실 되거나 깨지게 되어 dump된 파일의 복구가 곤란한 경우가 발생하였다.

sql은 복원중 에러가 발생을 할경우 하위 내용을 복구를 하지 않기 때문에..
이러한 경우 보통 sql 파일을 하나하나 수정해가면서 다시 부어넣는 짓을 해야한다 =_=a

DB용량이 작다면 하나하나 수정해줄수 있지만 100M단위를 넘어가는 파일을 변경하긴 어렵다.
때문에 테이블 생성정보와 데이터를 따로 따로 백업을 하고 먼저 테이블을 생성한뒤에 복구하는 방법을 쓰기로 하고 스크립트를 작성하였다.

 

위와 같이 원본서버에서 백업을 할때 데이터를 분리 한뒤에 iconv를 이용해서 캐릭터셋 치환을 하고 캐릭터셋 선언을 바꾸어 준다.

이중 -c 옵션은 에러가 나는 문자열을 제외하고 치환하는 옵션이다.
가급적 에러가 나지 않는게 좋겠지만 ‘ㅅ’…

 

새로운 데이터 베이스에 먼저 테이블 복원을 한다.

아래와 같은 스크립트작성을 한 뒤에 실행한다.

IFS 를 통해 구분자를 엔터(\n) 으로 지정한뒤 for 문을 돌려 한줄한줄 복원을 시도 하고
에러가나는 구분은 error_query.sql 파일로 별도 저장을 한다.

추후 error_query.sql 파일을 분석하여 쿼리문을 완성 시켜 재 복원을 하거나… 버리거나.. 할수 있겠다.

 

테이블 복원중 VARCHAR(255) UTF8 is too long for key, but max length is 1000 bytes 가 나오는 경우가 발생할수 있다.

key로 사용되는 컬럼의 길이가 1000byte를 넘어가면 안된다는 메세지 이다.
(Mysql에서 UTF8의 경우 문자당 3byte 를 사용한다 – utf8mb4 = 4Byte 를 쓴다..)

이경우 key로 사용되는 컬럼의 varchar 값을 최대치인 333이하를 쓰도록 한다.
일반적으로 2개 이상의 컬럼은 하나의 키로 사용하는 부분에서 에러가 난다. 그때는 사용된 컬럼의 합이 333 이하여야 하겠다.

utf8mb4의 경우에는 200 이하로 해야겠고.. 그래서 대략 아래와 같이… 큰 varchar 컬럼을 앞95자까지 인식하도록 하게 한다.