MITM Attack (Man In The Middle attack)

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

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

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

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

A. HSTS (HTTP Strict Transport Security)

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

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

1	Header always set Strict-Transport-Security "max-age=15552000; preload"

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

B. HPKP (HTTP Public Key Pinning)

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

1	Header set Public-Key-Pins 'pin-sha256="DE7ntbANTouhht7vxZIhpHI9UVzGcSmWNDZumjS1yvU=";pin-sha256="CtK5iaXbFhoHDsmHvpVYENisllUsXOSfXLwrFXvNcq4=";max-age=2592000;includeSubDomains'

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

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

1	~]# openssl x509 -noout -in 인증서파일.pem -pubkey\|openssl pkey -pubin -outform der\|openssl dgst -sha256 -binary\|openssl enc -base64

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

~]# openssl genrsa -out 임시KEY파일.key 4096

~]# openssl req -new -key 임시KEY파일.key -sha256 -out 임시CSR파일.csr

...CSR 생성을 위한 입력값을 넣는다...

~]# openssl req -noout -in 임시CSR파일.csr -pubkey|openssl pkey -pubin -outform der|openssl dgst -sha256 -binary|openssl enc -base64

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

#!/bin/bash

if [[ -z `echo $LANG|grep -iE "euckr|utf-8"` ]];then

if [[ -e /etc/sysconfig/i18n ]];then

source /etc/sysconfig/i18n

elif [[ -e /etc/locale.conf ]];then

source /etc/locale.conf

fcher=`file -i $0|awk '{if(/utf-8/||/UTF-8/)print"utf-8";else print"euckr"}'`

tcher=`echo $LANG|awk '{if(/utf-8/||/UTF-8/)print"utf-8";else print"euckr"}'`

ch="iconv -f $fcher -t $tcher"

echo "가나다라마바사아자차카타파하"|$ch >> /opt/cron_logs

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	~]# yum install jwhois

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

1	~]# whois [도메인명]

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

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

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

~]# cd /etc

~]# mv jwhois.conf jwhois.conf_old

~]# wget --no-check-certificate https://raw.githubusercontent.com/robert-scheck/jwhois/master/example/jwhois.conf

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

~]# which whois

/usr/bin/whois

~]# ll /usr/bin/whois

lrwxrwxrwx 1 root root 6 2016-11-21 2016 /usr/bin/whois -> jwhois

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

~]# rm -f /usr/bin/whois

~]# touch /usr/bin/whois

~]# chmod 755 /usr/bin/whois

~]# vi /usr/bin/whois

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

#!/bin/bash

if [[ -n $1 ]];then

domain=`echo $1|sed 's=^http://==g;s=^https://==g;s=^www\.==g'|awk -F"/" '{print $1}'`

if [[ -z `echo $1|sed 's/[a-zA-Z0-9.]//g'` ]];then

domain=$domain

else

domain=`echo $domain|idn 2> /dev/null`;

i18n_char=`echo $LANG|cut -d"." -f2|tr [a-z] [A-Z]`

if [[ $i18n_char == "EUCKR" ]]&&[[ -n `echo $domain|grep -E ".xn--3e0b707e$|.kr$"` ]];then

whois_target_fix="-h oldwhois.kisa.or.kr"

else

whois_target_fix=""

/usr/bin/jwhois $domain $whois_target_fix

else

/usr/bin/jwhois

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

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

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

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

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

1 2	~]# mysqldump -u아이디 -p 데이터베이스명 --add-drop-database -d > 테이블.sql ~]# mysqldump -u아이디 -p 데이터베이스명 --skip-extended-insert --no-create-info -c > 데이터.sql

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

~]# sed -i 's/DEFAULT CHARSET=euckr/DEFAULT CHARSET=utf8/g;1 i\SET NAMES UTF8;' 테이블.sql

~]# iconv -fEUCKR -tUTF8 -c 테이블.sql > 새테이블.sql

~]# iconv -fEUCKR -tUTF8 -c 데이터.sql > 새데이터.sql

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

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

1	~]# mysql -u[아이디] -p [데이터베이스명] < 새테이블.sql

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

#!/bin/bash

sqlfile="새데이터.sql"

IFS=$'\n'

for a in $(grep ^INSERT $sqlfile)

mysql -u[아이디] -p[데이터베이스패스워드] [데이터베이스명] -s -N -e "$a"

if [[ $? -eq 1 ]];then

echo $c >> error_query.sql

done

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자까지 인식하도록 하게 한다.

컬럼A varchar(255)

컬럼B varchar(255)

KEY `키명` (`컬럼A`(95),`컬럼B`(95)),

mariaDB yum을 이용한 설치 ( CentOS 7 )

https://downloads.mariadb.org/mariadb/repositories

위 주소에서 먼저 맞는 OS 버전 및 설치할 mariaDB 선택한다 ‘ㅅ’a

그후 나오는 내용을 레포지트리에 추가를한다.

~]# echo "# MariaDB 10.1 CentOS repository list - created 2016-11-14 06:56 UTC

# http://downloads.mariadb.org/mariadb/repositories/

[mariadb]

name = MariaDB

baseurl = http://yum.mariadb.org/10.1/centos7-amd64

gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB

gpgcheck=1" >> /etc/yum.repos.d/MariaDB.repo

그담 yum 으로 설치 고고싱.

1	~]# yum install MariaDB-server MariaDB-client

초기 mysql 데이터폴더는 /var/lib/mysql 에 있다.
그래서 data 폴더를 이동하게 되는 경우에는 저 폴더를 다른 위치 및 이름으로 변경을 한다.
물론 /etc/my.cnf 에서 아래 부분을 찾아 고치는것도 병행해야 한다.
운영하려는 캐릭터셋에 맞게 설정을 추가하는것도 잊지 말자 (latin1 으로 깔리기 때문에….)

[client]

default-character-set = utf8

socket = /tmp/mysql.sock

[mysql]

default-character-set = utf8

[mysqld]

character-set-server = utf8

collation-server = utf8_general_ci

datadir = /var/lib/mysql

socket = /tmp/mysql.sock

[mysqldump]

default-character-set = utf8

datadir에 selinux 설정을 한다

~]# semanage permissive -a mysqld_t

~]# semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"

~]# restorecon -Rv /var/lib/mysql

~]# semanage permissive -a mysqld_t

이후에 데몬 자동시작 등록 및 시작을 한다.

~]# mysql_install_db --datadir=/var/lib/mysql

~]# systemctl start mysqld

~]# systemctl enable mysqld

mysql 명령어로 mysql 에 로그인을 한뒤에 root 패스워드를 지정하고
보안을 고려하여 user 등이 비어있는 로그인정보 및 test 데이터베이스를 삭제해야 한다.

~]# mysql

MariaDB [mysql]> SET PASSWORD FOR root@localhost = PASSWORD('mysqladminpassword');

MariaDB [mysql]> FLUSH PRIVILEGES;

MariaDB [mysql]> USE mysql

MariaDB [mysql]> DELETE FROM user WHERE User='';

MariaDB [mysql]> DELETE FROM user WHERE Password='';

MariaDB [mysql]> DELETE FROM db WHERE User='';

MariaDB [mysql]> DROP DATABASE test;