그리고 WP Rocket에서 제공하는 비교표를 보면 WP Rocket이 가장 많은 기능을 제공하고 있습니다.
3.1. WP Rocket 속도 측정 결과 – 아이비호스팅에서
당시 WP Rocket을 구매 설치한 때는 아이비호스팅을 이용하던 시기인데 WP Rocket을 설치 후 속도를 비교하면 캐시 플러그인 미설치시와 WP Rocket 설치시와 비교해 보면 양 2초이상 개선 효과가 있었습니다.
이전에 설치했던 W3 Total Cache보다는 1초정도 개선이 있었습니다.
일반 웹호스팅과 같이 서버에서 충분한 캐시나 메모리등이 확보되지 않은 상태에서 이러한 캐시 플러그인은 확실한 속도개선을 보여줍니다.
속도 측면에서 WP Rocket은 확실히 만족감을 주었습니다. 그러나 절대 속도는 전혀 만족스럽지는 않습니다.
▽ WP-Rocket 적용 전 측정 결과
▽ WP-Rocket 적용 후 측정 결과
3.2. WP Rocket 속도 측정 결과 – vultr 가상서버호스팅
그러면 이번에는 아이비호스팅에서 vultr 가상서버호스팅으로 이전 후 WP Rcoket 설치 전 후를 비교해 봤습니다.
그 결과 WP Rocket 설치 전이나 설치 후나 속도상에 큰 변화가 없었습니다.
이는 WP Rocket없이도 서버단에서 Google mod PageSpeed , Opcache 등등이 제대로 작동하면 WP rocket과 같은 캐시 플러그인이 없어도 좋은(?) 속도를 보여주는 예가 아닐까 싶습니다.
아무는 저는 이 테스트 결과를 WP Rocket에 제시하면 효과가 크지 않다고 refund를 요구해 반화받았습니다.
가상서버호스팅 상태에서는 WP Rocket이 훨씬 좋은 성과를 내는게 아니라면 굳이 사용할 필요가 없기 때문이죠.
4. WP Rocket 사용시 좋았던 점
WP Rockrt을 사용하면서 좋았던 점을 간략 나열하면 아래와 같습니다.
첫째는 상대적으로 빨라진 속도, 워낙 호스팅이 느려서(?) 만족할만한 속도가 나오지는 않았지만 기존 보다는 확실히 빨라졌음을 체감할 수 있었으며,
둘째는 이미지와 비디오를 모두 지원하는 lazy load기능이 신선했고 별도 플러그인을 설치하지 않아도 그 효과를 느낄 수 있어 좋았고,
Tools에서 DB등 워드프레스를 최적화하는 기능들이 있었는데 이도 별도 플러그인을 설치할 필요없다는 점
5. WP Rocket의 문제점
WP Rocket은 속도 개선을 위해 어쩌면 무리한 시도를 맣이하다보니 다른 프로그램들과 충돌이 있었습니다. 대표적으로 크게 느낀 문제는 아래 두가지 였습니다.
5.1. 동영상이 레이아웃을 넘어가는 현상
WP Rocket에서 vedeo lazy load를 선택하면 유튜브 레이아웃이 개집니다.
즉 유튜브소스를 구글에서 제공하는 소스 크대로 적용 시(예를 들어 width="853" height="480"를 그대로 적용 시) 아래 캡춰 이미지처럼 레이아웃을 넘어가 재생이 됩니다.
이를 WP rocket에 문의를 했는데 거기서도 뚜렸한 대답을 주지 못하더군요.
결국 궁여지책으로 모든 유튜브 소스의 폭을 width=100%로 변경해 해결했습니다.
5.2. WP Rocket 세팅에서 js 압축 선택 시 Disqus 플러그인과 충돌
WP Rocket 세팅 옵션에서 js압축을 선택하면 disqus가 작동을 하지 않습니다.
이는 여러 조건에서 테스트를 해보았지만 모든 일관되게 재현되는 문제라서 결국 이 옵션 선택을 포기하고 말았습니다.
그리고 Disqus 댓글 입력 시 많은 오류를 냅니다. 많은 경우 There was internal server error while processing your request라는 메세지를 뿜어내네요. 여러번 시도를 해야 올라가는 경우가 종종 발생했습니다.
6. 마치는 글
제 경험을 기준으로 (일부 기능 충돌은 있지만, 이는 옵션 선택에서 조정할 수 있으므로 조금은 부차적인 문제로 보아 아주 몰쓸 제품은 아니라는 관점에서) 일반 웹호스팅을 사용하는 경우 어느정도 속도 개선 효과가 있다고 보여집니다.
서버를 직접 제어하는 가상서버호스팅이상에서는 속도를 개선할 많은 방안들이 있어 WP rocket에 비해서 뒤떨어지 않는 속도를 확보할 수 있다는 생각입니다.
과연 39$어치의 가치가 있느냐는 질문에 대해서는 속도를 어느 정도 중시하느냐에 따라 달라진다고 생각합니다. 즉 이 캐시 플로그인을 통해서 개선 가능한 1~2초정도가 충분히 의미있는 성과라고 본다면 돈 가치는 한다는 생각이고, 반대로 1~2초 개선이 큰 의미가 없다고는 입장이라면 값어치에 대해서 생각할 필요조차 없습니다.
그렇지만 위에서 지적한정도의 문제점을 노출한다는 것은 유료 상품으로서는 문제가 있으며 39$이라는 비싼 가격에 판매한다면 보다 완벽하게 만들어야한다는 생각입니다.
저는 Memcached를 최대한 활용할 수 있는 cachify라는 플러그인을 사용하고 있습니다.
일반 웹호스팅을 사용하면 호스팅사에서 일정 정도 정기 백업을 해줍니다. 어떤 곳은 1주일정도를 보관하는 경우도 있었습니다. 그래서 사이트 문제가 있을 경우 롤백을 하기도 하지요.
그런데 웹호스팅에서도 점차 백업의 책임을 사이트 운영자에게 넘기고 자료 보관의 문제인지는 몰라도 백업본을 매일 보관하지는 않는 것 같습니다.
최근에 이용했던 아이비호스팅은 운영자가 백업을 요청하고 이를 백업본을 사이트에 올려주는 시스템이고 자동 백업은 주당 한번정도 해서 보관하고 있었습니다. 사이트에 문제가 생겨 자동 백업한걸로 롤백해 달라고하니 (일주일에 한번 백업한다고하면서) 가장 최근 백업된거라고하며서 3일전 자료로 롤백해주더군요.
일반적으로 사이트에 문제가 생기면 바로 이전치 백업자료가 필요하므로 가능하면 매일 매일 백업된 자료가 있는게 좋습니다.
더우기 가상서버호스팅을 하는 경우 아무도 백업을 도와 주지 않으므로 정기적으로 백업할 수 있는 시스템을 갖춰놓는것은 너무도 당연한 일입니다.
가상서버호스팅에서 워드프레스를 운영한다는 기준에서 정기 백업 방법은 백업 플러그인을 사용하는 방법과 서버에서 자동화 스크립트를 이용하는 방법의 2가지가 있습니다.
여기에서는 가능하면 플러그인을 사용하자말자는 주의에 따라 서버에서 자동화 스크립트를 이용하는 방법에 대해서 살펴보겠습니다.
사이트가 털리고나서 다시 복구하는 과정에 배운 내용을 기반으로 가상서버호스팅 서버 보안 설정 방법을 좀그 ㅁ더 자세하게 알아보자.
사이트가 털린 것 같다는 연락을 받고 바로 새로운 서버를 계약하고, 새로 OS 설치, Nginx, PHP7.0-FPM, MARIADB 등 기본 프로그램을 설치하고 pageSpeed, SSL 등을 설치한 다음 최종 Wordpress를 설치 후 데이타베이스 및 이미지 파일등을 복원하였다.
이러한 과정에서 해킹에 취약한 나의 사이트 보안 강화 방안에 대해서 고민하였고 아래는 그 그 과정을 간략히 정리해 보았다.
보안 관련해 이런 점을 고려했구나하는 정도로 이해해 주면 좋겠다.
1. 서버 재설치
사실 해커가 어디로 침투했는지도 모르고 (로그를 살펴보면 알 수 있다고하는데 이럴 여유조차 없어서, 바로 신규 세팅 작업에 들어갔다 ) 어디에 무슨 악성코드가 심어져있는지도 모르므로 기존 것을 전부 지우고 새로 설치하기로 했다.
vultr에서는 Servers – Setting – change hostname 을 선택해 hostname을 선택하고 reinstall을 누르면 새롭게 설치가 시작된다. 이는 기존 사이트는 그대로 둔 상태에서 서버만 준비할 수 있다는 점에서 가상서버의 장점 덕을 본 셈이다.
여기서 별도로 OS 등을 선택하는 메뉴는 없이 기존에 선택한 OS를 그대로 다시 설치해 준다.
설치 후 확인해 보니 Ubuntu 16.04 x64가 설치되어 있는 걸보니 위에서 이야기한 내용이 맞는 것 같다.
2. 보안 관련 조치들
서버 운영체제가 설치된 후 필요한 조치들을 해 준다. 인터넷 검색을 통해서 아래 사항들을 설정했다.
해커도 인터넷 정보를 토대로 해킹 방법을 찾는다고 한다.
그렇다면 이런 기본적인 조치들은 궁극적으로는 무용지물이겠고, 뚫리는데 걸리는 시간만을 지연해 줄 수는 있겠지만 그것만으로도 역활을 한다고 생각한다.
어느 정도 실력있는 해커가 덤빌정도로 가치있는 정보가 없는 사이트이기 때문에 너무 고난이도의 방어까지는 필요하지 않는다는 생각을 해봤다. 가치있는 정보가 있다면 그만큼 비용을 등여서 보안을 강화할 필요가 있을 것 같다.
테스트 삼아 접근하는 해커들을 방어할 정도의 순준이 필요할것으로 보여 준다.
2.1. Ubuntu 방화벽 – ufw 설정
서버를 세팅하기전에 맨먼저 해야하는게 방화벽 설정이라 할 수 있다. 사실 이 어려운 단어를 직접하게 될줄은 진정 몰랐다. 그러니 세상일이란 모르는 것이다.
우분투에서 방화벽은 iptables로 세팅하는데 이게 어렵기때문에 좀 더 쉽게 사용할 수 있도록 한 방화벽이 ufw라고 한다.
우분투를 설치하면 방화벽은 기본적으로 꺼져있다. 어떻게 세팅할지 모르기 때문에 세팅 후 이에 맞추어 방화벽을 가동하라는 의미라고..
그러므로 세팅이 끝나면 반드시 방화벽을 가동시켜야 한다.
나는 단순한것이 좋다고 ufw를 ssh 포트, 80포트, 443포트만 열어 놓았다. 이런 정보를 오픈한는 것도 보안에는 별 도움은 안되는 데 어쩔 수 없지 뭐..
ufw enable # 방화벽을 활성화한다.
ufw allow 80/tcp # 일반 웹 정보 관련 입출력 통로
ufw allow 443/tcp # SSL 설치 시 웹정보 관련 입출력 통로
ufw allow ****/tcp # ssh를 위한 포트, 뒤에서 설명하겠지만 22번 포트는 너무 알려져 있어 여기로 공격하는 경우가 많아 포트를 바꾼다.Code language:PHP(php)
2.2. ping 금지
해외 가성서버호스팅(VPS)를 사용하면서 ping 속도에 민감해 ping 정보를 자주 조회해 보곤 한다. 현재 속도가 얼마나 나오는지 궁금하므로..
일반적으로 서버를 구성한 경우 핑(ping)을 허용하고 있는 경우가 많다. 우분투 방화벽인 UFW의 기본 설정도 ping 요청을 허용하고 있다.
그런데 해킹 목적으로 네트워크 침입을 시도 시 핑(Ping)을 통해 특정 서버가 살아있는지 확인하는 경우가 많고, 고전적이긴 하지만 DDOS 공격 시 무한 핑(ping) 요청으로 서버를 무력화를 시도하는 경우도 있기때문에 핑(ping)을 허용하지 않는 게 좋다.
이를 위해서는 방화벽 정책을 변경해 준다. 변경해야하는 설정 파일은 아래 경로에 있는 /before.rules을 수정한다.
nano /etc/ufw/before.rulesCode language:PHP(php)
아래 명령에서 ACCEPT를 DROP으로 변경하거나 삭제해 준다.
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT → DROP으로 변경
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT → DROP으로 변경
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT → DROP으로 변경
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT → DROP으로 변경
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT → DROP으로 변경
Code language:PHP(php)
2.3. ssh 포트 변경
일반적으로 ssh포트를 22번을 사용하는데 이는 너무 알려진 포트이므로 이를 이용해 공격해오는 경우가 있다고 한다. 따라서 자기만아는 포트 번호로 변경 사용하는 게 필요하다.
이를 위해서는 먼저 sshd_config에서 22번대신 사용할 포트 번호로 바꾸어 준다. 즉 /etc/ssh/sshd_config에서 Port 22 를 찾아서 자기가 사용할 포트 숫자를 기억하기 쉽고 10000자리이상에서 임의의 숫자를선택한다. 예를 들어 58722, 65322 등등
#Port 22
Port 58782#AddressFamily any#ListenAddress 0.0.0.0#ListenAddress ::Code language:PHP(php)
이렇게 포트를 변경한 후 ssh 서비스를 재시작한다. 그리고 기존 ssh port로 사용했던 22번 포트는 접속할 수 없도록 막아준다.
service ssh restart
Code language:PHP(php)
그 다음 방화벽 ufw에서 정의해주고 FTP나 Terminal에서 접속 시 새로 설정한 포트 번호를 이용하면 된다.
ufw enable # 방화벽을 활성화한다.
ufw allow 80/tcp # 일반 웹 정보 관련 입출력 통로
ufw allow 443/tcp # SSL 설치 시 웹정보 관련 입출력 통로
ufw allow ****/tcp # ssh를 위한 포트, 22번 포트는 너무 알려져 있어 여기로 공격하는 경우가 많아 포트를 바꾼다.
ufw deny 22/tcp # ssh용으로 22포트를 사용할 수 없게 한다.Code language:PHP(php)
2.4. Nginx 버전 숨기기
보안에 철저하려면 가능하는한 정보를 숨기는게 좋을 것 같다. 서버 시스템이 무엇이구 어떻게 구성되어 있는지 등등 물론 뚫리면 이런 정보야 쉽게 알 수 있겠지만 최소한 시간을 벌어 줄 수 있겠지.
그런 이미에서 Nginx 버젼을 숨기는 것도 필요하다. Nginx 버젼을 알면 그 버젼의 취약점을 토대로 보다 용이하게 해킹을 할 수 있다고 한다.
아무튼 Nginx 버젼을 숨기는 방법은 Nginx 환경 설정 파일에 아래 문구를 추가하는 것이다.
일반적으로 사용자가 잘못된 경로로 접근 시 에러메시지와 함께 nginx는 하단에 nginx의 버전을 표기해 준다, 앞에서 이야기한 대로 Nginx 버전 약점을 토대로 해킹을 시도하는 나쁜 해커가 있을 수 있으므로 이 문구는 에러메세지나 서버 정보 표현 시 Nginx 버전을 표기하지 않토록 하는 명령이다.
일반적인 Nginx 환경 설정 파일은 아래 경로에 있다. /etc/nginx/nginx.conf
server_tokens off; # Nginx 버전 숨기기 활성화Code language:PHP(php)
2.5. PHP 버젼 정보 숨기기
Nginx 버젼 숨기는 것과 마찬가지로 PHP버젼을 알아서 도움이 되는게 없겠죠.
마찬가지로 이 버젼 정보를 숨기는 옵션을 선택한다. 이는 php.ini에서 expose_php = Off로 설정하면 끝.
참고 최근의 php7에서는 expose_php=off로 기본 설정되어 있다. php7을 쓴다면 별도 작업하지 않아도 된다.
; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header). It is no security
; threat in any way, but it makes it possible to determine whether you usePHP
; on your server or not.
; http://php.net/expose-php
expose_php = Off
Code language:PHP(php)
2.6. PHP-info.php 파일 지우기
이는 대단한 팁은 아닌데 일반적으로 서버 세팅을 하는 과정에서 PHP 관련 설치가 제대로 되었는지확인하기 위해 루트에 php-info.php 등의 이름이 붙은 php 파일을 올려놓아 사이트명 + php-info.php를 치면 php 관련 정보를 일목 요연하게 볼 수 있는 경우가 있다.
설치 과정이 끝나면 필요가 없는데 그냥 남겨 놓은 경우가 많은 것 같다.
나도 참고하려는 사이트에서 php-info.php, phpinfo.php 등등 몇가지 이름을 바꾸어 입력해보면 많은 사이트가 이 파일을 그대로 유지하고 있어서 php 정보를 쉽게 볼 수 있었던 많은 경험을 가지고 있다.
나처럼 초보도 이런 원시적인 방법으로 php 정보를 알아내는데 전문 해커야 두말할 필요가 없는 듯.. 그런데 이러것 말고도 인터넷에는 php 버젼등을 확인하는 방법이 널려 있는 듯..
결론 ; 설치가 끝나면 document root에 있는 php 정보를 볼 수 있는 php 파일을 삭제하자.
2.7. ipv6 차단하기
ipv6을 사용하겠다고 신청하긴 했지만 아직 그럴 단계가 아니라고 한다면 이를 사용하지 않토록 한다.
더우기 IPv4와 IPv6를 동시 사용 시 시스템 성능이 낮아 질 수 있으므로 굳이 사용하지 않는다면 IPv6를 사용하지 않토록 하는게 성능을 위해서도 좋다.
#!/bin/sh
# 백업 위치는 /backup, 백업 시간은 년-월-일 형식으로 지정
DATE=`date +"%Y%m%d%H%M%S"`
# 사용자 계정과 비밀번호
USERNAME="MySQL계정"
PASSWORD="비밀번호"
# 백업할 데이타베이스
DATABASE="wp"
# 백업 작업
mysqldump -u$USERNAME -p$PASSWORD $DATABASE > /backup/wp_bak_${DATE}.sql
자동 백업 Shell 프로그램의 권한 부여
자동 백업 Shell 프로그램이 제대로 작동하도록 700권한을 부여합니다.
chmod +x /backup/wpbackup2.sh
크론탭에서 자동 실행 명령
일정 시간에 자동 백업되도록 크론(cron)을 만듭니다.
매일 5시 30분에 자동실행되도록 crontab을 수정합니다.
cd /etc/crontab
vi /etc/crontab
30 5 * * * root /backup/wpbackup2.sh # 매일 5시 30분 실행 명령어 입력
/etc/init.d/cron restart # 크론 데몬을 재 실행토록 합니다.
시스템 재시작 시 스크립트가 실행되도록 설정
시스템이 재시작은 중요한 액션이 시작되는 것이므로 백업을 실행하도록 합니다.
vi /etc/rc.local
/backup/wpbackup2.sh
5. 마치며
서버를 운영하다보면 생각보다도 많이 DB를 백업받아야 할 일들이 발생합니다. 그냥 방치하면 모르겠지만 끊임없이 새로운 것을 시도해보고 개선을 시도해 본다면 DB 백업 및 복원은 일상적으로 일어나는 일들이 될 것입니다.
그리고 서버 운영에서 가장 중요한 일중의 하나가 만일의 사태에 대비한 백업과 복원이라고 할 수 있죠. 솔직히 어떤일이 일어날지 모르잖아요. 군대에 빗대어 서버 복원에 실패한 서버 전문가는 용서할 수 있어도 백업에 실패한(백업하지 않은) 서버 전문가는 용서할 수 없다는 이야기도 있더군요.
이렇게 중요한 서버 백업 및 복원에 대해서 전문가도 아니면서도 서버를 어쩔 수 없이사용해야하는 저와 같은 초보에게 도움이 될길 바라면서 이해하는 범위내에서 공유했습니다. 아무쪼록 도움이 될길 바라고 차후에는 좀더 업그레이든 내용을 공유해 보도록 하겟습니다.
참고로 자동백업 스크립트등은 우성군의 NAS에서 제안한 내용을 많이 반영했습니다. 이 자리를 빌어 감사드립니다.
VPS로 사이트를 옮기로나서 여러가지 시행착오을 격었는데 여기서 정리하는 썸네일이미지를 생성하지 못하는 경우도 그것이다.
VULTR로 옮기고나서 해킹도 당해보고 여러번 서버 설치도 해보면서 정말 이 동네 일이라는게 어렵다는 생각을 절로 하게된다. 그렇다고 중간에 중단할 수도 없어서 초보로선 어쩔 수 없이 많은 시간을 투여할 수 밖에 없었다.
조금 지나면 여유롭게 운영할 수 있는 시기가 올리라는 희망을 가지고서…
1. 문제 제기 – 서버 세팅 후 워드프레스에서 썸네일이 생성되지 않는다.
제목을 거창하게 문제제기라 썼지만 문제점 발견이라고해야 겠다.
지난주에 내 사이트가 해킹이 되었다는 Matthew님의 연락을 받고 사이트를 우서 며칠전에 백업한 상태로 되돌리고 이번 주말과 연휴에 사이트를 다시 세팅하였다.
OS를 새로 설치히고 (이는 VULTR dashboard에서 간단히 할 수 있는 일이다.) Nginx, PHP7.0-FPM, MARIADB 등 기본 프로그램을 설치하고 pageSpeed, SSL 등을 설치하고 최종 Wordpress를 설치 복원하였다..
그리고 이번 기회에 워드프레스테마를 무겁고 VC 빌더를 사용해 다소 무겁다는 newspaper 7에서 EXTRA로 변경해 보았다,
그런데 이 EXTRA를 설치하고 최적화하는 과정에서 도대체 썸네일이 매칭이 않되는 것이었다.
도대체 뭐가 문제일까?
2. 문제 해결 과정과 문제 해결 방법
이 문제를 해결하기 위해서 아래와 같은 몇가지 단계를 거쳤다. 어쩌면 이 문제를 해결하기 위한 삽질 순서라고 해야할 듯…
2.1. 테마간 썸네일이 중복되어 생성이 않되는 것일까?
혹시 테마별로 필요한 썸네일 사이즈가 있으므로 혹 테마간 충돌로 제대로 썸네일이 생성되지 않을 수도 있겠다 싶어서 EXTRA만 제외하고 모든 테마를 지우고 테스트를 해보있다.
여전히 제대로 working하지 않는다. 썸네일 자체가 전혀 생성되지 않는다. 미디어라이브러리에 이미지는 올라가는 것 같다. 처음 서버를 설치 시 이미지 자체가 보이지않고 올라가지 않아서 고생했던 기억이 있었는데 이는 아니어서 다행…
2.2. 썸네일 생성 플러그인이 문제가 아닐까?
예전부터 썸네일 관련해서는 Thumbnail Cleaner라는 플러그인과 Regenerate Thumbnails라는 플러그인을 사용했는데 제대로 작동하지 않았다. 기존 썸네일지우는 동안에 많은 에러를 내고 생성한다고 메세지는 나오는데 섬네일은 생성되지 않았다. 이는 플러그인이 오래되어서 그러나보다며 플러그인을 의심했다.
이 플러그인을 다 지우고 인터넷을 검색해보니 Force Regenerate Thumbnails을 추천하는 포스팅이 많아서 또 설치… 이 플러그인도 마찬가지 – 멋있게 작업 진행 상황을 보여주긴 하는데 섬네일이 생성된다는 메세지는 없다. — 삭제
그러면 강제로 Thumbnails size를 지정해 만들어보면 어떻할까는 생각이 들었다. 이런 작업을 해줄 수 있는 플러그인은 무엇일까? 검색에 검색을 거듭해서 AJAX Thumbnail Rebuild라는 플러그인을 발견해 설치했다.
AJAX Thumbnail Rebuild는 원하는대로 사이즈를 지정할 수 는없지만 테마에서 필요로하는 모든 사이즈 리스트를 보여주고 여기서 선택을 할 수 있게 해준다. 작업 시 이미지들을 보여주면셔 작업을 진행하는데 이번에는 뭐가 제대로되는 느낌..
작업이 완료된 후 FTP로 점검해보니 왠걸 AJAX Thumbnail Rebuild도 마찬가지로 아무런 썸네일도 생성되지 않았다..
도대체 뭐가 문제야?
2.3. 파일 권한의 문제가 아닐까?
구글링! 구글링! 이번에는 wordpress cannot create thumbnails라는 영어로 질문을 던졌다. 그랬더니 이와 관련된 질문이 여러가지가 보인다.
어떤 사람이 이는 당연히 파일 권한 문제라고 한다. 그러면서 아래와 같이 퍼미션을 주라고 한다.
전체 wp-content 폴더는 777로 세팅한다.
나머지 폴더(wp-admin, wp-includes)는 755로 설정하고 파일들은 644로 세팅한다.
이렇게 세팅하고 예전 기억이 있어서 사용자를 www-data로 지정도 했다.
이 방법도 실패!!
2.4. 기본 프로그램 설치의 문제 – PHP7.0-GD 미설치 시 나타나는 문제
구글링을 계속하니 PHP5-GD 설치하지 않아서 발생했다는 글이 있었다.
그러면 혹시 PHP7.0-GD도 있는 것 아닌가? 이를 실마리로 PHP7.0-GD와 thumbnails로 검색하니 PHP7으로 업그레이드하고나서 Post Thumbnail Editor가 작동하지 않는다는 질문이 꽤 있다.
Since I migrate my webserver to PHP7, Post Thumbnail Editor is not working… It doesn’t show up the image in the crop window and don’t generate automatically those thumbnails.
Any one facing this too?
I had to revert to PHP 5.6 and now it’s working again.
이에 대한 해결책은 PHP7.0-GD를 설치하는 것. 워드프세스는 GD라고 불리우는 PHP 확장 기능을 사용해 이미지를 조작하므로 워드프레스에서 이미지관련 작업을 하려면 서버에서 PHP 버젼에 따라 PHP5-GD나 PHP7.0-GD가 설치되어 있어야 한다고 한다.
Ubuntu 16.04 등 최근 OS에서는 별도의 인증서 저장없이 바로 설치 할 수 있다.
apt-get update
sudo apt-get install php7.0-gd
PHP7.0-GD 설치
Nginx 재시작(service nginx restart)
PHP 재시작(service php7.0-fpm restart)
PHP7.0-GD를 설치, nginx 및 PHP를 재가동시키고 나니 언제 그랬나는듯 아무 문제없이 썸네일이 생성된다.
무식하면 손발이 엄청 고생한다는 게 이번 교훈!!
3. 마치며
원인을 알고나면 참으로 간단한 해결 방안이고 허망할 정도로 단순 문제인데 원인을 모르면 이런 저런 갑질을 하게 된다.
이런 원인들을 잘 모르니 서버 운영자들이 PHP 업그레등 기능 업그레이드를 망서리게 되는 원인이 되지 않을까 싶다.
위에서 인용한 사람도 PHP7로 업그레이드 했지만 썸네일 문제를 해결하지 못해서 다시 PHP5.6으로 다운그레이드한 경우처럼..
관련 분야에 폭넓은 지식을 가지고 있다면 해결책을 빨리 발견할 수 있겠지만 그렇지않으면 엄청난 삽질을 해야하므로 비지니스 측면에서 그런 삽질를 감당할 수없으니 소비자들에게잔소리말고 낡은 프로그램을 쓰라고 윽박지르는 것이 아닐까??
오늘 마지막으로 Memcached를 설치해보고 워드프레스 속도 최적화 프로젝트(?)는 종료하면서 초보가 보기에 의미가 있는 cache 이야기해 보려고 합니다.
이 포스팅은 공유 목적도 있지만 제 자신의 기록과 나중에 참고할 자료 성격이 더 강합니다. 아무래도 이 포스팅을 위해서 고민을 많이하다보니 자료가 어디있지라는 생각에 제일 먼저 떠오르는 곳이 이 곳이기 때문에 저는 여기에 올린 포스팅을 종종 참조하곤 합니다. 그리고 저라도 활용을 해야 할 듯 싶기도 합니다.
다만 이 포스팅의 한계는 분명합니다. 미래를 앞서가는 개발자에게 어떤 인사이트를 제공하고 개발자분들에게 명확한 가이드가 되는 포스팅은 아닙니다. 먼저 고민을 하고 구글링한 결과를 한글로 정리한 것에 불과할 수도 있습니다. 이런 고민을 하는 초심자들에게는 조금 도움은 될 수 있지 않을까 합니다.
오늘 서버 성능을 개선해보고자 cache 부분을 어떻게 개선할까 고민했습니다.
2. 고민의 계기 – newspaper 7 테마에서 APC 를 추천하다.
그 고민의 시작은 newspaper 7 테마 제작사에서 테마의 속도를 올리는 방법으로 APC full page cache를 사용하라고 조언을 하더군요. 그래서 이게 대단한 것 같아서 자료를 찾아보고 설치를 해보았습니다.
아래는 newspaper 7 테마 제작사에서 권유하는 내용입니다.
we recommend that you use WP Super cache with default settings.
you can also use the APC full page cache if you have a lot of ram on your server
구글링으로 알아본 cache에 대해서 간략히 정리해 봅니다.
APC는 매우 낡은 기술로 더 이상 잘 사용하지 않는 기술이라고 합니다. 이렇게 낡은 기술을 newspaper 7과 같은 최신 테마에서 사용하라고 가이드 한다는 점에서 굉장히 실망하게 되었습니다.
그러면서 이 테마는 최근에 최신 기술을 기반으로 만들어진 테마라기보다는 오래전에 나온 테마를 계속 업데이트 해온 것이 아닐까 하는 생각이 들었습니다.
알고보니 이 테마가 처음 등장한 것은 2014년 경으로 이 당시는 APC가 그 낡은 기술은 아니었던 것으로 보입니다.
아마 예전에 만들었던 마케팅 커뮤니케이션 자료들이 최신 기술등으로 업데이트되고 있지 않다는 게 최종 결론입니다.
3. Cache 프로그램에 대해서
Cache에 대해서 구글링을 하다보면 만나는 단어들이 있습니다. APC, XCache , Opcache, Memcache, Memcached 그리고 Tarantool (HASH), Tarantool (TREE), Redis, Azure Redis Cache, CouchBase Redis등등이 그것입니다.
굉장히 많은 종류의 Cache가 있지만 워드프레스를 운영하는 초보 입장에서는 APC, Opcache, Memcache, Memcached가 많은 접하는 수준의 단어들인 것 같습니다. 그런데 이 cache관련 내용은 들어도 잘 모르는 알송달송한 내용이 대부분인듯… 역시 전문 분야는 다른 것 같다는 생각입니다.
Nginx서버에서의 Cache 관련 구글링을 통해서 얻은 내용을 아래와 같이 간략히 정리해 봅니다.
Cache에는 Full page cache, PHP Script 결과를 모아 두는 cache, 데이타베이스 Query 결과를 모아두는 cache로 나눌 수 있다.
Full page cache는 PHP를 통해서 HTML 형태로 page를 구성한 결과를 보관했다가 요청이 오면 바로 보여주어 속도를 높이는 기법으로 Nginx에서는 FastCGI가 가장 좋은 성과를 보여 준다,
PHP Script Cache는 말 그대로 PHP Script를 컴파일한 결과를 공유 메모리에 저장하고 있다가 필요 시 사용하는 cache로 요즘 OPcache가 가장 성능이 좋다고 알려 있다.
APC는 PHP Script 결과를 모아 두는 cache + 데이타베이스 Query 결과를 모아두는 cache 모두 커버하는 기술이었다.(아래 개발군님의 댓글 참조)
xcache, wincache, eAccelerator 등등은 구닥다리 기술로 쳐다볼 필요조차 없다
APC의 PHP 관련 기능은를 대신해서 PHP 5.5이상에서는 자체 OPcache로 대체되었고, PHP 5.5이하에서 Opcache를 사용하려면 별도 프로그램을 깔아야 한다.
PHP 5.5이상에서 APC의 기능 중 데이타베이스 쿼리(query) Cache 부분은 APCu라는 php 확장 모듈을 사용 할 수 있다.
데이타베이스 쿼리(query) Cache에는 APCu나 Memcached가 있다. 이중에서 단독 머신에서 사용하기에는 APCu가 빠르며, 머신 3개이상을 운영한다면 Mencached가 낫다는 평가가 있다.
OPcache와 Memcached의 차이는 OPcache는 위에서 설명한 대로 PHP Script 결과를 모아 두는 cache이고, Memcached는 주로 데이타베이스 쿼리(query) 결과를 보관하는 cache라는 차이가 있다.
Opcache나 APCu가 Redis 또는 Memcached 보다 속도면에서 유리한 이유는 Redis나 Memcached는 별도 서버와 통신을 통해서 작동하는 방식이라 규모가 작은 시스템에서는 상대적으로 느맇 수 있다. 반면 OPcache나 APCu는 연결할 필요없이 바로 서버 공유메모리에 바로 Caching하기 때문에 빠르고 메모리도 절약된다, Memcached와 Redis의 작동 방식은 같다.
Opcache와 Memcached를 같이 쓰는 것에 대해서 OPcache는 PHP Script Cache이고 Memcached는 데이타베이스 Query Cache이므로 같이써도 무방하다. 이를 같이 쓰는 경우를 많이 발견할 수 있다. 특히 사용자가 많은 경우 시스템을 효율적으로 공유할 수 있는 유용성때문에 같이 사용한다.
아래에서는 비교적 최신 기술이고 PHP 5.5이상에서 내장되어 사용되는 OPcache에 대해서 살펴보도록 하겟습니다.
4. OPcache 의미와 설정법
OPcache는 byte코드로 컴파일된 명령문(PHP Script)으로 공유된 메모리에서 PHP 문서 해석 시간을 줄여 성능을 개선시킵니다. Opcache는 낮은 CPU 자원을 사용하면서 빠른 해석으로 개벌적 접속자가 상대적으로 빠른 속도감을 느낄 수 있습니다.
아래는 PHP Script를 처리하는 과정에 대한 플로우 차트인데 Cache와 PHP Script 컴파일이 잔행되는 프로세스를 살펴볼 수 있습니다. 이 플로우 차트는 Basics of PHP opcode cache 에서 가져왔습니다.
Opcache는 PHP 5.5부터 내장되어 설치되며 5.4이하에서는 PECL 방식으로 사용이 가능합니다.
Opcache는 PHP.ini 파일에서 환경 설정을 효율적 세팅함으로써 효울을 더 높힐 수 있습니다.
4.1. OPcache 적용 여부 확인
우선 OPcache가 작동하고 있는지 확인하는 방법은
첫째, php.ini 설정을 살펴보면 됩니다. ubuntu 계열에서 php.ini 파일은 /etc/php/7.2/fpm/ 폴더에 있습니다. (PHP Version만 달라짐)
vi /etc/php/7.2/fpm/php.ini
여기에서 OPcache 관련 항목이 있으면 설치되어 작동하고 있는 것입니다.
또한 일반적으로 많이 사용하는 php-info.php를 활용해서 확인 할 수 있습니다.
먼저 아래와 같은 내용의 php-info.php 파일을 만들어 계정의 루트에 올립니다.
그 다음 인터넷 브라우저에서 (yourdomain)/php-info.php를 치면 php의 관련 내용이 나오는데요.. 여기서 opcache 관련 내용을 확인하면 됩니다.
<?php
phpinfo();
?>
4.2. php.ini에서 OPcache 설정
php.ini 파일을 열어보면 OPcache 관련해 앞에 주석 처리된 명령문들이 많이 있습니다. 이 명령문 중에서 상호 관련이 있는 변수는 opcache.memory_consumption, pcache.max_accelerated_files, opcache.max_wasted_percentage의 3가지로 서로 충돌이 나지 않토록 설정하는 게 관건으로 보입니다.
opcache.memory_consumption은 기본값이 64MB로 되어 있는데요. 메모리의 여유가 있다면 늘려주는 게 좋을 것 같습니다. 원래 256MB를 설정했는데, OPcache 모니터링 프로그램으로 며칠 살펴보니 70MB이하로 사용되고 있어서 96MB로 최종 설정했습니다.
opcache.max_accelerated_files은 한번에 처리하는 캐시 파일 수 인데요. 이는 200에서 1,000,000사이의 값을 넣게 되어 있고 기본값은 2000입니다. 램에 여우가 있다면 기본보다 높이는게 좋겠죠. 저는 100,000으로 설정했습니다만 실제로 1,300개 정도 사용되고 있는 것으로 보아 개인 사이트라면 10,000정도면 충분할 것 같습니다.
opcache.max_wasted_percentage는 Opcache가 재시작을 해야할 시 버려야하는 비율을 정하는 것입니다. 기본값은 5%로 되어 있습니다. 일반적으로 기본보다 더 높여주는 것 같습니다.
opcache.revalidate_freq는 php소스 변경 확인 간격을 말하는데요. 개발자라면 이를 0으로 놓아 바로 바로 확인토록 하고, 일반인이라면 60 또는 180으로 설정합니다.
그외 일반적으로 꼭 하는 설정들은 아래에 적어 보았습니다.
opcache.enable=1 ; Opcache 사용여부 설정, 1일때 활성화 됨
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=100,000 ; 최대 파일갯수 설정
opcache.revalidate_freq=180 ; php 소스 변경확인시간 60sec
opcache.validate_timestamps=2 ;php 소스 수정 확인
opcache.fast_shutdown=1
opcache.enable_cli=0 ; 명령행 버전의 PHP에서도 opcache적용할지 여부
opcache.use_cwd=1 ;같은 이름을 가진 파일들사이에서 가능한 충돌 제거
4.3. OPcache 모니터링
이렇게 OPcache를 설정했으면 이 OPcache가 어떻게 작동하고 있는지 모니터링하고 혹시 수정할게 있는지 확인하는 게 좋을 것 같습니다.
즉 SSD와 PHP 7을 적용해도 서버 사양이나 서버 세팅에 따라 성능 및 속도가 달라질 수 있다는 사실을 HDD와 PHP 5.5를 적용한 루아틱이 오히려 더 나은 속도 및 퍼포먼스를 보여줌으로써 증명되었습니다.
그리고 아이비호스팅을 이용하면서 한국업체이므로 서비스가좋고 편하다는 느낌을 받을 수 없었고 모든 문제를 내가 알아서 해결해야하므로 한국 업체의 서비스가 무의미했습니다. 대부분 문제를 구글링을 통해 해결해야하는 실정이라면 그냥 해외업체를 쓰는게 속편하겠다는 생각을 했습니다.
그래서 서버 사양이나 세팅을 어느정도 자유롭게 할 수 있는 VPS 가상서버호스팅을 고민하기 시작했습니다.
그렇지만 VPS 가상서버호스팅이 자유롭게 서버등을 최적화 할 수 는 있지만 (국내업체는 너무 비싸므로) 가격 경쟁력을 갖춘 해외업체를 사용해야 하므로 해외 가상서버호스팅이 과연 만족할만한 속도를 내줄 것인지가 의문이었습니다.
최소한 현재 shared hosting인 아이비호스팅보다는 빨라야 옮길 수 있는 명분이 있는게 아닐까 싶었습니다.
그래서 VPS 가상서버호스팅과 아이비호스팅을 비교해 보기로 했습니다. 이의 결과에 따라 VPS 서버호스팅이 대안이 될 수 있을지를 결정하기로 했습니다.
1. VPS(가상서버호스팅 ) 선정
인터넷 검색 결과 속도 및 가격을 고려해 VULTR.com을 선정했습니다.
VULTR을 선정한 이유는
하지만 Let’s Encrypt 사용을 아래 그래프에서 보듯 매우 빠르게 증가 (개인적인 생각으로는 무료이기 때문에 테스트로 중복 인증도 많다고 생각)
Let’s Encrypt SSL 인증서 사용 증가 추이, Graph by Let’s Encrypt
Let’s Encrypt의 정책은 독특합니다. 앞에서 HTTPS의 확산을 위한 비영리단체로 소개했듯이 Let’s Encrypt은 서버운영자들이 인증 관리를 철저히 하지 못한다는 점을 염려(?)해 인증서 설치부터 재발행(갱신)까지 다 책임진다는 자세로 인증관련 업무를 진행하고 있습니다.
인증기간이 90일로 상대적으로 짧은 것은 보안 상황이 계속 변동되므로 이를 반영해 갱신할 수 있도록 짧게 잡았으며 대신 자동으로 인증서가 연장(재발행)되는 기능을 사용하도록 권장하고 있습니다.
자동으로 연장(재발행)된다면 오히려 안심하고 사용할 수 있는 것이 아닌가 싶습니다.
HTTPS Everywhere 를 추구하는 비영리 프로젝트
스폰서 : Mozilla, Akamai, Cisco, eff, Identrust
IdenTrust cross-sign됨
SSL 인증서 100% 무료화
인증기간 연장 및인증서 재발급 무료
사용편리성 : 콘솔상에서 인증서 발급/갱신/설치/세팅 자동화.
멀티도메인 지원, SAN 기능(여러 도메인을 한 인증서로 묶어주는 기능) 지원
2. Let’s Encrypt SSL 인증서 발급 방법 4가지
Let’s Encrypt SSL 인증서 발급 방법은 webroot와 Standalone, DNS의 3가지 방식이 있습니다. 인증서 발급은 사이트에서 인증기관인 Let’s Encrypt에 접속해 이 사이트의 유효성을 검증하는 과정을 거치며 이 과정을 아래 3가지 방법 중 하나를 선택해 진행할 수 있습니다.
webroot : 사이트 디렉토리 내에 인증서 유효성을 확인할 수 있는 파일을 업로드하여 인증서를 발급하는 방법 . 실제 작동하고 있는 웹서버의 특정 데렉토리의 특정 파일 쓰기 작업을 통해서 인증 . 이 방식의 장점은 nginx를 중단시킬 필요가 없음. . 이 방법의 단점은 인증 명령에 하나의 도메인 인증서만 발급 가능
웹서버 . Nginx나 아파치와 같은 웹서버에서 직접 SSL 인증을 실시하고 웹서버에 맞는 SSL세팅값을 부여 . 발급이나 갱신을 위해 웹서버를 중단시킬 필요가 없음 . 인증서 갱신 시 상황에 맞게 세팅을 자동으로 업데이트 . 사용자가 세팅을 변경할 수 있지만 자동 업데이트 시 반영되지는 않음
Standalone : 사이트 작동을 멈추고 이 사이트의 네크워킹을 이용해 사이트 유효성을 확인해 Let’s Encrypt SSL 인증서를 발급하는 방식 . 80포트로 가상 staandalone 웹서버를 띄워 인증서를 발급 . 이 방식은 동시에 여러 도메인을 발급 받을 수 있음 . 그렇지만 인증서 발급 전에 Nginx를 중단하고 발급 완료 후 다시 Nginx를 시작해야 함
DNS : 도메인을 쿼리해 확인되는 TXT 레코드로 사이트 유효성을 확인하는 방법 . 와일드 카드 방식으로 인증서를 발급 가능 . 이 방법은 당연하게도 서버 관리자가 도메인 DNS를 관리/수정할 수 있어야 하며 . 인증서 갱신 시마다 DNS에서 TXT값을 변경해야 하므로 외부에서 TXT 레코드를 입력할 수 있도록 DNS가 API를 제공하는 경우만 갱신 과정을 자동으로 처리(클라우두플레어 API가 대표적인 사례)
여기에서는 가장 안정적인 방식인 standalone 방식으로 SSL 인증서를 발급하는 방법에 대해서 알아보도록 하겠습니다. 보다 자세한 내용을 아래 글을 참조하시면 좋을 것 같습니다.
그러면 아래와 질문들이 나오면서 인증이 진행됩니다. 첫번째로은 이메일 주소를 입력하라고 나옵니다. 이메일을 입력해야 다음 단계로 넘어갈 수 있으니 연락을 받을 수 있는 이메일을 입력합니다.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel)
:Code language:PHP(php)
그 다음 단계는 서비스 약관에 동의하느냐고 묻습니다. 모든 서비스가 그러하듯이 Y를 누르지 않으면 서비스를 이용할 수 없기 때문에 A를 누릅니다.
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory
(A)gree/(C)ancel: ACode language:PHP(php)
마지막 질문은 재단에 이메일 주소를 공유할 것인지를 질문 합니다 간혹 귀찮게 하는 경우도 있어 N를 선택하라는 조언도 많은데 저는 이 비영리기관에 도움이 될 수 있다면 이라는 긍정적인 생각으로 Y를 눌렀습니다.
Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom.
(Y)es/(N)o: YCode language:PHP(php)
그러면 다음과 같이 진행되고 인증을 축하다는 메세지가 나옵니다.
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your cert will expire on 2021-03-25. To obtain a newor tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew <em>all</em> of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donateDonating to EFF: https://eff.org/donate-le Code language:PHP(php)
인증이 완료되면 웹서버를 다시 가동시킵니다.
service nginx restartCode language:PHP(php)
2.3. 여러개 도메인을 한번에 인증받기
이 standalone 옵션은 또한 한꺼번에 여러 개의 사이트를 인증 받을 수 있는데요. 아래와 같은 명령을 사용할 수 있습니다. 이는 연속해서 사이트명을 나열해주면 가능합니다.
단 이렇게 여러개 사이트를 인증 받을 시 인증서 존재 위치가 맨앞 사이트명으로 통일되게 됩니다. 나중에 사이트를 없앨 때 난감할 수도 있습니다.
2.4. DH Param 생성, 적용하기
여기가지 진행하면 SSL 인증서 설치는 끝나지만 보다 보안을 강화하기 위해서 DH Param 생성을 합니다.
DH Param은 일부 암호화 알고리듬에 사용되는 커다란 난수 하나를 미리 생성해 두어서 암호화 성능을 향상시키고 보안을 높이는 방법입니다.
실제로 DH Param을 비적용시와 적용 시 보안 점수를 측정해보니 한등급 차이가 날 정도로 Gap이 컷습니다. DH Param를 적용시는 A+ 보안등급이 나오고 DH Param를 비적용시는 A-가 나오네요.
mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
openssl dhparam -out dhparams.pem 4096# 2048비트로 하려면 4096대신 2048로 대체 한다.
openssl rand 48
session_ticket.key # 세션 티켓키도 생성 이는 시간이 거의 걸리지 않는다.Code language:PHP(php)
3. 암호화 알고리즘 설정하기
XE 분야에서 탁월한 식견을 자랑하는 가지곰님이 Xpress Engine 공홈에 올린 SSL의 정석 (아파치 & nginx) 라는 글에 의하면 실제로 보안을 제공하는 것은 인증서가 아니라 암호화 알고리즘이라고 이야기 하고 있습니다.
인증서를 획득하는게 중요한게 아니고 얼마나 철저한 암호화 설정을 하느냐가 중요하다는 것입니다.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Processing /etc/letsencrypt/renewal/example.com.conf
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
IMPORTANT NOTES:
Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates andprivate keys obtained by Certbot so
making regular backups of this folder is ideal.
Code language:PHP(php)
5. SSL 사용을 위한 워드프레스 설정하기
워드프레스에서는 별로 할것은 없습니다. 워드프레스 어드민의 설정 – 일반으로 가서 워드프레스 주소와 사이트주소에 S를 붙여줍니다.
일반적으로 인터넷은 HTTP(Hypertext Transfer Protocol의 약자)로 데이타를 전송해왔습니다. 이는 암호화되지 않은 방식으로 데이타를 전송하므로 메세지를 감청하는것이 매우 쉬워 보안에는 취약합니다. 로그인을 위해 비밀번호를 전송시 쉽게 비밀번호를 가로챌 수 있다는 의미이죠.
그래서 보다 보안을 강화한 방식이 HTTPS입니다. 마지막의 S는 Over Secure Socket Layer의 약자로 보안이 강화된 HTTP라고 이해하면 될 것 같습니다.
1.2. SSL이란
SSL protocol은 Secure Socket Layer protocol의 약자로 (지금은 사라진 브라우져회사인)Netscape사에서 처음으로 웹서버와 브라우저 사이의 보안을 위해 만들었다고 합니다. .
[웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)
[웹서버] Public Key를 인증서와 함께 전송한다.
[웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. (역주:Internet Explorer나 Netscape와 같은 웹브라우저에는 이미 Verisign, Thawte와 같은 널리 알려진 root CA의 인증서가 설치되어 있다) 또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인한다.
[웹브라우저] Public Key를 사용해서 랜덤 대칭 암호화키(Random symmetric encryption key)를 비릇한 URL, http 데이터들을 암호화해서 전송한다.
[웹서버] Private Key를 이용해서 랜덤 대칭 암호화키와 URL, http 데이터를 복호화한다.
[웹서버] 요청받은 URL에 대한 응답을 웹브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저로 전송한다.
[웹브라우저] 대칭 키를 이용해서 http 데이터와 html문서를 복호화하고, 화면에 정보를 뿌려준다.
위 SSL작동방식에서 설명한 것처럼 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달하며 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 자료 전송 등등의 작업을 진행합니다.
이 SSL 인증서을 사용하면 서버와 클라인언트간 통신 내용이 공격자에게 노출되는 것을 막을 수 있고, 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단할 수 있으며 공격자에 의해서 서버와 크라인언트간 통신 내용의 악의적인 변경을 방지할 수 있다고 합니다.
2. 웹보안의 강제적 적용과 구글의 정책
위에서 설명한것처럼 웹에서 보안을 위해서는 HTTPS 적용이 기본적으로 필요합니다.
이런 저런 이유로 우리나라는 2012년 8월 18일부터 시행된 정보통신망 이용촉진 및 정보보호 등에 관한 법률에 따라 개인정보호를 위해서 보안서버(SSL)를 구축해야합니다. 개인사이트, 커뮤니티를 포함해 회원가입을 받는 국내 모든 웹사이트가 해당된다는 해석입니다. (이에 대해서 불필요한 규제라는 많은 불만이 있는 것은 사실입니다.)
제28조(개인정보의 보호조치) ① 정보통신서비스 제공자등이 개인정보를 취급할 때에는 개인정보의 분실·도난·누출·변조 또는 훼손을 방지하기 위하여 대통령령으로 정하는 기준에 따라 다음 각 호의 기술적·관리적 조치를 하여야 한다.
개인정보를 안전하게 취급하기 위한 내부관리계획의 수립·시행
개인정보에 대한 불법적인 접근을 차단하기 위한 침입차단시스템 등 접근 통제장치의 설치·운영
접속기록의 위조·변조 방지를 위한 조치
개인정보를 안전하게 저장·전송할 수 있는 암호화기술 등을 이용한 보안조치
백신 소프트웨어의 설치·운영 등 컴퓨터바이러스에 의한 침해 방지조치
그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치
② 정보통신서비스 제공자등은 이용자의 개인정보를 취급하는 자를 최소한으로 제한하여야 한다.
또한 구글에서도 2014년부터 HTTPS를 지원 여부를 사이트의 신뢰할 수 있다는 척도로 판단하고 검색 순위에서 올리겠다고 발표했습니다.
Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default. That means that people using Search, Gmail and Google Drive, for example, automatically have a secure connection to Google. ~ 중략~ For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We've seen positive results, so we're starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content — while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.
3. 무료 SSL인증서에 대해서
그러면 이처럼 보안을 강화하기위해 보안서버(SSL)를 구축하려면 SSL인증이 필요합니다.
그동안 SSL인증에는 일정정도 비용을 수반했기때문에 HTTPS 프로토콜을 적용하는 사이트가 적었지만 HTTPS 확산을 위해서 무료로 발급해주는 곳이 증가하고 잇습니다.
이러한 무료 인증서가 유료 인증서보다 보안에 약하지않을까하는 염려가 있을 수 있는데이는 전혀 걱정할 필요가 없다고 합니다.
무료인증서나 유료인증서나 인증에는 별 차이가 없습니다만 유료인증서에는 사고가나면 배상받을 수 있는 조검이 걸려있습니다. 쉽게 말해서 일종의 보험이 포함되어 비싼진 게 유료인증서라고 보면 될 것 같습니다.
이처럼 무료로 SSL인증서를 발급해주는 곳으로는 Let’s Encrypt, Wosign, StartSSL이 널리 알려져 있습니다. 아래에서 각 업체별 특징을 간략히 알아보겟습니다.
Let’s Encrypt은 HTTPS의 확산이 늦어지는 것은 SSL인증서에 있다고 보고 무료 인증서 보급을 통해 HTTPS의 확산을 늘리겠다는 취지로 시작된 비영리 프로젝트입니다.
Mozilla, Akamai, Cisco, eff, Identrust등이 스폰서로 참여해서 HTTPS Everywhere를 모토로 100% 무료 SSL 인증서를 발급 해주고 있습니다.
Let’s Encrypt의 정책은 독특합니다. 앞에서 HTTPS의 확산을 위한 비영리단체로 소개했듯이 Let’s Encrypt은 서버운영자들이 인증 관리를 철저히 하지 못한다는 점을 염려(?)해 인증서 설치부터 재발행(갱신)까지 다 책임진다는 자세로 인증고나련 업무를 진행하고 있습니다.
인증기간이 90일로 상대적으로 짧은 것은 보안 상황이 계속 변동되므로 이를 반영해 갱신할 수 있도록 짧게 잡았으며 대신 자동으로 인증서가 연장(재발행)되는 기능을 사용하도록 권장하고 있습니다.
Wosign은 중국의 인증업체 상당히 공격적인 조건으로 사용자를 확보하고 있는 인증업체입니다. 여기서 발급하는 인증서의 브라우저 호환성은 StartSSL과 같은 수준이라고 합니다. (StartSSL cross-sign)
이곳의 장점은
최초 발급이 무료이고 더우기 Revoke/Reissue가 무료 임 (StarSSL은 상당 비용($25)을 받음, Let’s Encrypt는 무료임)
멀티도메인 지원 및 발급 도메인수가 많다. ( Wosig에서는 한 인증서당 SAN 100개까지 지원할정도로(도메인 + 서브도메인 포함해 100개) 많은 도메인을 등록할 수 있었으나 스팸성 도메인들의 증가로 도메인을 5개까지 무료 지원 + 그 이상은 도메인당 1.99달러 가격으로 이용 가능)
인증기간을 3년까지 선택할 수 있음
Wosign의 단점을 꼽자면
중국 인증업체로 신뢰성이 떨어진다는 점
서비스에의 의구심(뚜렸한 사유없이 인증이 취소되었다는 케이스 등등 사례가 있음)
3.3 StarSSL
StarSSL은 이스라엘 보안업체가 운영하는 인증서 발급업체로 비교적 신뢰도가 높은곳으로 알려지고 있습니다.
다만 위 Wosign이나 Let’s Encrypt에서 당연시되는 사항들이 여기에서는 무료로 지원되지 않고 있습니다.
계정당 인증서 1개만 가능
인증서 연장은 무료지만 유효기간이 지나 재발급받을 시 상당한 비용을 받습니다. (25$ of Revoke fee)
3. 어떤 무료인증서를 이용해야 할까?
위에서 무료 SSL 발급업체인 Let’s Encrypt, Wosign, StartSSL의 간략한 특징을 살펴보았는데요.
그러면 이중 어디를 써야할까요?
아마 관리가 귀찮은 분들은 인증기가닝 가장 긴 Wosign의 3년짜리를 쓴 것이 답이 아닐까도 싶구요. 보다 믿을 수 있는 곳을 서야겠어하시는 분은 그래고 권위(?)있는 StarSSL을 쓰시는게 마음 편할 듯 합니다.
저는 여러 조건을 고려해 볼 시 자동으로 연장되는 기능을 사용하는 조건으로 Let’s Encrypt가 가장 경쟁력있다고 판단되었습니다.
원래는 SrarSSL을 사용하려고 인증서까지 받고 서버에 설치하는 중이었는데요. Let’s Encrypt로 바꿔보기로 했습니다.
다음 포스팅에는 Let’s Encrypt 인증서를 적용하고 자동 연장토록 구성하는 방법에 대해서 알아보도록 하겠습니다.
![[워드프레스 Tips] 최고라 추천된 WP Rocket 캐시 플러그인 사용기](https://happist.com/wp-content/uploads/2016/10/WP-Rocket-site-main-1-768x320.jpg "[워드프레스 Tips] 최고라 추천된 WP Rocket 캐시 플러그인 사용기")
![[워드프레스 Tips] 백업 플러그인없이 자동으로 정기 백업하는 방법 – 가상서버호스팅(VPS)의 경우](https://happist.com/wp-content/uploads/2016/08/Featured_photo-1443694910004-3567042689f5-12-1-768x311.jpg "[워드프레스 Tips] 백업 플러그인없이 자동으로 정기 백업하는 방법 – 가상서버호스팅(VPS)의 경우")
![[워드프레스 Tips] phpMyAdmin 사용하지 않고 워드프레스 데이타베이스 백업하기](https://happist.com/wp-content/uploads/2016/08/Featured_student-849825_960_720-22-1-768x381.jpg "[워드프레스 Tips] phpMyAdmin 사용하지 않고 워드프레스 데이타베이스 백업하기")
![[워드프레스 Tips] 워드프레스에서 썸네일 이미지 생성 불가시 해결 방법](https://happist.com/wp-content/uploads/2016/10/이미지-썸네일-1-768x441.jpg "[워드프레스 Tips] 워드프레스에서 썸네일 이미지 생성 불가시 해결 방법")
![[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안](https://happist.com/wp-content/uploads/2016/10/페라리-무료이미지-1-768x361.jpg "[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안")
![[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안 1](https://www.vultr.com/media/banner_3.png "[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안 27")
![[워드프레스 Tips] Nginx서버에서 phpMyAdmin DB 업로드 용량 확대 방법](https://happist.com/wp-content/uploads/2016/08/Featured_photo-1439194850785-37cfb3d7efc2-09-1-768x307.jpg "[워드프레스 Tips] Nginx서버에서 phpMyAdmin DB 업로드 용량 확대 방법")
![[워드프레스 Tips]웹서버 보안을 위한 무료 SSL 인증서 비교](https://happist.com/wp-content/uploads/2016/09/nginx-letsencrypt-https-featured-3-1-768x329.jpg "[워드프레스 Tips]웹서버 보안을 위한 무료 SSL 인증서 비교")
