[번역글] 1. 인증서 투명성 (Certificate Transparency) 개요

인증서 투명성 개요

구글의 인증서 투명성 프로젝트는 모든 HTTPS 연결에 쓰이는 주요 암호화인 SSL 인증서 시스템의 결함을 수정합니다. 이 결함은 인터넷 연결의 암호화된 연결의 효용성과 신뢰도를 약화시키고 도메인 인증, 양 끝단 암호화, 그리고 인증서 인증을 통해 구성된 신뢰 체인을 포함한 TLS/SSL 구조의 심각한 손상을 가져올 수 있습니다. 이를 확인하지 않고 방치하면, 이 결함이 웹 사이트 스푸핑, 서버 위장, 중간자 공격과 같은 광범위한 보안 공격을 가능하게 만듭니다.

인증서 투명성은 SSL 인증서를 거의 실시간에 가깝게 모니터링하고 감사할 수 있는 오픈 프레임워크를 제공함으로써 이러한 결함을 제거하는데 도움을 줍니다. 특히, 인증서 투명성은 SSL 인증서가 인증서 인증을 잘못 받았거나, 다른 정당하지 않은 곳에서 인증서 인증을 오남용하여 받았는지를 확인할 수 있게 합니다. 인증서 인증이 악의적인 사용자에게 넘어가서 잘못된 인증을 받았는지도 알 수 있게 합니다.

오픈된 공개 프레임워크이므로, 누구든지 인증서 투명성을 구동하는 기본 구성요소를 빌드하거나 접근할 수 있습니다. 이는 특히 도메인 소유자, 인증서 인증자, 그리고 브라우저 제조사와 같이, SSL 인증 시스템의 무결성과 상태를 유지하는 인터넷을 구성하는 인터넷 보안 관계자에게 유용합니다.

인증서 투명성을 더 알아보려면, 도입 문서를 읽어보세요. 이미 인증서 투명성의 기본 개념에 친숙하고, 상세 구현을 알아보려면 상세한 디자인 문서를 확인해보세요. 인증서 투명성 프레임워크를 구동하는 핵심 구성 요소를 빌드하는 방법에 대한 오픈 소스 프로젝트도 있습니다.

인증서 투명성이란 무엇입니까?

현대 암호화 기술 덕택에, 브라우저는 평소에 위조되었거나 가짜 SSL 인증서가 제공되는 수상한 웹 사이트를 판별할 수 있습니다. 그러나, 현재 암호화 기술은 잘못 발급된 인증서나, 위험해졌거나 악의적인 집단에 넘어간 인증 기관(CA)의 인증서가 제공되는 수상한 웹 사이트를 판별할 만큼 뛰어나진 않습니다. 이러한 경우, 브라우저는 인증서에 이상이 없다고 표시하게 되는데, 이에 따라 인증 기관이 멀쩡해 보이고, 방문하고 있는 웹사이트가 인증되었고 연결이 안전하다는 인상을 줍니다.

여기서 문제는, 현재로선 쉽고 효과적으로 SSL 인증서를 실시간으로 감사하거나 감시할 수 없어서, 이러한 오작동이 일어나게 되는 것이고 (수상한 경우 등), 의심스러운 인증서는 보통 탐지되지 않고 인증 철회는 수 주나 몇 개월 후에나 이뤄진다는 것입니다. 게다가, 이러한 종류의 SSL 오작동의 빈도가 더욱 늘어나고 있습니다. 지난 몇 년간 잘못 발급된 수많은 인증서가 합법적인 사이트를 가장하는데 쓰이고, 일부의 경우에는 수상한 소프트웨어를 설치하거나 무고한 사용자에게 침투하는데도 쓰였습니다.

한 가지 사례로, 저명한 네덜란드 인증 기관(DigiNotar)이 공격받았고, 해커는 CA 시스템을 사용하여 가짜 SSL 인증서를 발급할 수 있었습니다. 인증서는 이란에서 Gmail과 Facebook과 같은 수많은 사이트를 가장하는데 활용되었고, 이는 가짜 사이트 소유자가 무고한 사용자에게 침투할 수 있게 했습니다. 다른 사례는 말레이시아 소속의 인증서 기관(DigiCert Sdn. Bhd.)이 실수로 22개의 취약한 SSL 인증서를 발급하여, 웹 사이트를 가장하고 수상한 소프트웨어를 서명하는데 쓰였습니다. 그 결과, 주요 브라우저는 DigiCert Sdn. Bhd.가 발급한 모든 인증서에 대한 신뢰를 철회하였습니다.1

최근에, 거대한 U.S. 소재 인증 기관 (TrustWave)이 고객의 인증서 하나에 대한 하위 루트 인증서를 발급하여 고객이 내부 네트워크 트래픽을 관찰할 수 있게 했습니다. 하위 루트 인증서는 인터넷의 거의 모든 도메인에 대한 SSL 인증서를 발급할 수 있게 합니다. 비록 Trustwave는 인증서를 철회했고 고객에게 하위 루트 인증서를 더이상 발급하지 않지만, 인증 기관의 잘못에 의해 얼마나 커다란 결과를 낳게 되는지를 보여주는 사례입니다.

많은 경우에 잘못 발급된 인증서는 해커에 의해 심각한 결과를 초래할 수 있는 악의적인 공격을 하는데 사용되었지만, 일이 터진 후 후폭풍도 거대하고 위험합니다.

결국, 네덜란드의 인증 기관 인증서는 인증 철회되고, 인증 기관은 폐쇄되었습니다. 인증 철회 및 폐쇄는 네덜란드 사람들이 인증 기관의 SSL 인증서를 발급받은 정부와 개인 사이트를 접속하지 못하게 되는 여파를 만들었습니다.

사태 해결을 위한 인증서 투명성

인증서 투명성은 SSL 인증서 발급 유무를 도메인 소유자, 인증 기관과 도메인 유저에 의해 정밀하게 조사할 수 있도록 개방할 수 있도록 하여 이들 인증서 기반 위협을 대처하는 걸 목표로 합니다. 특히, 인증서 투명성은 세 가지 주요 목표가 있습니다.

  • SSL 인증서를 도메인 소유자를 드러내지 않고서는 인증 기관이 도메인 SSL 인증서를 발급하지 못하게 하거나, 어렵게 만듭니다.
  • 아무 도메인 소유자나 인증 기관이 인증서가 실수 또는 악의적으로 발급되었는지 여부에 대한 공개 감사 및 감시 시스템을 제공합니다.
  • 사용자가 가능한한 실수 또는 악의적으로 발급된 인증서에 속지 않도록 만듭니다.

인증서 투명성은 TLS/SSL 인증 시스템 감시와 특정 TLS/SSL 인증서 감사를 위한 공개 프레임워크를 만듦으로써 이러한 목표를 만족시킵니다. 이 공개 프레임워크는 아래 세 가지 주요 구성 요소로 구성되어 있습니다.

인증서 로그

인증서 로그는 암호로 보호되며, 공개적으로 감사되며, 인증서에 대한 레코드 추가만 가능한, 단순한 네트워크 서비스입니다. 누구든지 로그에 인증서를 등록할 수 있지만, 인증 기관이 최우선 등록자가 될 것입니다. 비슷하게, 누구든지 로그된 특정 인증서가 잘 로그되고 있는지, 그리고 인증서를 검증하기 위해서 암호 증명에 대한 로그를 조회할 수 있습니다. 로그 서버 개수는 많을 필요가 없고 (이를테면, 전세계에 1000개보다 적습니다), 각각은 인증 기관, 인터넷 제공 업체 또는 어떤 다른 조직에서든지 독립적으로 운영될 수 있습니다.

감시자 (Monitors)

감시자는 주기적으로 모든 로그 서버와 접촉하면서 수상한 인증서에 대한 주시를 공개적으로 실행하는 서버입니다. 예를 들어, 감시자는 인증 기관을 잃었거나 인증되지 않은 인증서가 도메인에게 발급되었는지, 비정상적인 인증서 확장이나 인증 기관이 갖고 있는 인증 권한 같은 이상한 권한을 갖고 있는지 알려줄 수 있습니다.

감시자는 대출이나 신용 카드에 여러분 이름으로 누군가 사용할 때 알려주는 것과 같은 신용 경고 알림과 매우 유사한 방식으로 동작합니다. 일부 감시자는 Google 또는 은행, 정부와 같은 회사와 조직에 의해 운영됩니다. 그 외에도 도메인 소유자나 인증 기관이 구매할 수 있는 구독 서비스를 운영할 것입니다. 기술에 정통한 개인도 스스로 감시자를 운영할 수 있습니다.

감사자 (Auditors)

감사자들은 크게 보아 두 가지 기능을 수행하는 가벼운 소프트웨어 구성 요소입니다. 첫째는 로그가 올바르게 쓰이고 있고 암호화가 유지되고 있는지 검증할 수 있습니다. 로그가 제대로 작성되지 않으면, 로그 스스로 이에 대해 서술해야 하고 그렇지 않으면 종료될 수 있습니다. 둘째로 특정 인증서가 로그에 나타나는지를 검증할 수 있습니다. 이는 감사 기능에서 특히 중요한데, 인증서 투명성 프레임워크는 모든 SSL 인증서가 로그에 등록되어 있을 것을 필요로 하기 때문입니다. 인증서가 로그에 등록되어 있지 않다면, 인증서가 수상하다는 의미이며, TLS 클라이언트는 수상한 인증서에 대한 연결을 거절할 것입니다.

감사자는 브라우저의 TLS 클라이언트, 단독 서비스, 아니면 감시자의 보조 기능으로서 필수 구성 요소가 될 수 있습니다. 누구든지 감사자를 만들 수 있는데, 이는 인증 기관이 모든 인증 기관에 대한 운영 투명도를 높일 수 있는 효과적인 방법이므로 인증 기관이 수많은 감사자를 운영할 것입니다.

아울러서, 이들 구성 요소가 실시간으로 새로운 또는 기존에 존재하는 SSL 인증서를 누구든지 관찰하고 검증할 수 있게 하는 공개 프레임워크를 구성합니다.2

오작동의 감소, 안전한 브라우징

이것이 구현되면, 인증서 투명성은 잘못 발급된 인증서, 악의적으로 취득한 인증서, 공격받은 인증 기관과 같은 인증서 기반 공격의 몇 종류에 대한 대비를 하는데 도움을 줍니다. 이 공격은 도메인 소유자의 금전적 손실 증가, 인증 기관의 신뢰 하락 그리고 인터넷 사용자를 웹 사이트 스푸핑, 서버 위장, 중간자 공격과 같은 광범위 공격으로 노출할 수 있습니다.

인증서 투명성 프레임워크는 공개 조사 제공 및 SSL 인증 시스템 개방을 통해 이들 인증서 기반 위협을 격리시키는 것을 목표로 합니다. 비록 공개 프레임워크가 공개적으로 감시자와 감사자에 의해 구통되지만, 인증성 투명성은 현행 SSL 인증 시스템에 빠져있는 몇몇 이점을 제공합니다.

잘못 발급된 인증서, 수상한 인증서, 공격 받은 인증 기관의 조기 탐지

대부분의 경우, 인증서 투명성 시스템은 수상한 인증서나 인증 기관을 수 일, 수 주, 수 개월을 수 시간으로 단축하여 탐지할 수 있습니다.

수상한 인증서나 인증 기관이 감지되었을 때 빠른 이탈

인증서 투명성이 위험한 인증서와 인증 기관을 다루는 기존의 해결 방식에 의존하긴 하지만(예를 들어 인증서 철회), 단축된 탐지 시간은 위험한 인증서나 인증 기관이 발견되었을 때 전체 해결 과정을 가속할 수 있습니다.

전체 TLS/SSL 시스템에 대한 더 나은 확인

인증서 투명성은 새로 발급되거나 존재하는 TLS/SSL 인증서에 대한 공개 감시 및 검증을 지원하는 공개 프레임워크로 설립되었습니다.  이에 (도메인 소유자, 인증 기관, 사용자 같은) 관심 있는 이들에게 TLS/SSL 시스템의 투명도와 상태를 관찰하고 검증할 수 있는 기회를 제공합니다.

집중 솔루션으로서, 인증서 투명성은 HTTPS 연결을 더욱 신뢰할 수 있고 정보 탈취 및 위장으로부터 안전하게 만듦으로써 인증 기관으로부터 개인 서버까지 확장된 신뢰 체인을 강화합니다. 그러나 그 이상으로, 일반적인 보안 관점에서, 인증서 투명성은 광범위한 인터넷 보안 공격을 방어하고, 모든 사용자가 안전하게 브라우징할 수 있도록 도와줍니다.

다음글: 2. 인증서 투명성 작동 방식

OpenSSL을 Ubuntu에서 설치하고 업데이트하는 방법

OpenSSL 을 Ubuntu 16.04에서 설치하고 업데이트하는 방법

OpenSSL은 SSL과 TLS 프로토콜의 오픈 소스 구현입니다. OpenSSL을 Ubuntu 장치에서 설치하고 업데이트하는 것은 무척 간단하며, 이 글은 그에 대한 내용을 다룰 것입니다.

OpenSSL을 설치하고 업데이트하기

OpenSSL의 설치를 시작하기 전에, 현재 버전의 OpenSSL을 다음 명령어로 가져옵니다.

$ openssl version
OpenSSL 1.1.0h  27 Mar 2018

그 후, OpenSSL의 최신 버전을 다음 명령어로 다운로드 받습니다. 좌측 링크를 눌러 다운로드 항목 중에 적절한 버전을 선택합니다. openssl-1.x 형식으로 된 것 중에 최신을 권장하지만, pre가 붙은 버전은 정식 출시 버전이 아니므로 문제가 생길 우려가 있습니다.

버전이 낮은데도 지속적으로 갱신되는 버전이 있는데, 이는 LTS 버전으로, 앞으로 업데이트를 자주하지 않고 최신 기능이 필요하지 않으면서 안정적으로 쓰고 싶은 사람에게 적절합니다.

원하는 항목을 브라우저에서 링크만 복사하여 아래 wget 명령 우측에 채워줍니다. 여기서는 openssl 1.1.1 pre7 버전을 설치하는 모습입니다.

$ cd /usr/src
$ wget https://www.openssl.org/source/openssl-1.1.1-pre7.tar.gz
--2018-06-19 08:49:17--  https://www.openssl.org/source/openssl-1.1.1-pre7.tar.gz
Resolving www.openssl.org (www.openssl.org)... 202.43.57.191, 2600:140b:5000:1af::c1e, 2600:140b:5000:1ab::c1e, ...
Connecting to www.openssl.org (www.openssl.org)|202.43.57.191|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8308876 (7.9M) [application/x-gzip]
Saving to: ‘openssl-1.1.1-pre7.tar.gz’

openssl-1.1.1-pre7.tar.gz   100%[=================================================>]   7.92M  4.00MB/s    in 2.0s

2018-06-19 08:49:26 (4.00 MB/s) - ‘openssl-1.1.1-pre7.tar.gz’ saved [8308876/8308876]

다운로드가 완료되면, 다운 받은 압축 파일을 다음과 같이 풀어줍니다.

$ tar -zxf openssl-1.1.1-pre7.tar.gz

수동으로 컴파일하기 위한 준비 작업이 필요합니다. 다음 명령으로 빌드 도구를 설치해주세요. 아래 명령에 파일을 찾을 수 없다는 오류가 발생하면, 우선 우분투 패키지 업데이트부터 실시합니다.1

$ sudo apt install build-essential

이어서 OpenSSL 컴파일 후 설치 및 업그레이드를 하기 위해서 다음 명령을 사용합니다. cd 명령어 뒤에 디렉토리명은 정확해도 되지만, 여기서는 편의를 위해 와일드카드로 간편하게 들어갔습니다. 둘 이상 존재한다면, 정확한 디렉토리명을 지정해주세요.

$ cd openssl*
$ ./config

참고로 위 ./config 대신 ./Configure --help를 참고하여 원하는 옵션을 더 넣을 수 있습니다. 특정 Cipher는 기본적으로 빠져있어서 이런 작업을 미리 해둬야 설치 후 사용 가능한 경우도 있습니다. 보통의 경우 위 명령으로 충분합니다.

이 작업이 끝나면, make 명령으로 OpenSSL의 설치를 준비합시다.

$ make

컴파일이 다 끝나면, make test 명령을 쳐줍니다.

$ make test

다양한 평가 항목이 완료되면, 루트 권한을 갖고 install을 시작합니다.

$ sudo make install

에러에 대한 언급이 없다면, 성공적으로 설치된 것입니다.

아래는 오류 발생시 따라합니다.

여기서부터 링크를 잘 걸어야 잘 실행할 수 있습니다. openssl 명령 실행시 error while loading shared libraries: libcrypto.so.1.1 등의 오류가 발생할 수 있습니다. libssl.so 또한 마찬가지입니다. 이 때 libcrypto.so와 libssl.so를 /usr/lib/usr/local/lib에 위치한 파일을 향하게 심볼릭 링크를 만들어야 합니다. 각 경로에 들어가서 파일이 (그것도 링크가 아닌 실행 가능한 파일로서) 실존하는지 확인합니다. 기존에 존재하던 예전 버전의 쓰레기가 있다면 제거합니다.

$ sudo rm /usr/lib/libcrypto.so*
$ sudo rm /usr/lib/libssl.so*
$ sudo ln -s /usr/local/lib/libcrypto.so.1.1 /usr/lib/libcrypto.so
$ sudo ln -s /usr/local/lib/libssl.so.1.1 /usr/lib/libssl.so
$ sudo ln -s /usr/local/lib/libcrypto.so.1.1 /usr/lib/libcrypto.so.1.1
$ sudo ln -s /usr/local/lib/libssl.so.1.1 /usr/lib/libssl.so.1.1

그리고 방금 설치한 openssl이 bin 폴더에 바로 저장될 수도 있지만, 다른 곳에 만들어졌을 수 있습니다. 위 make install에서 bin 파일이 어디 만들어졌는지 확인하고, 원래의 openssl을 치워버리고 링크해야 합니다.

$ sudo mv /usr/bin/openssl /root/
$ sudo ln -s /usr/local/bin/openssl /usr/bin/openssl

간단한 설치와 업데이트 방법이죠? OpenSSL은 기본적인 암호화 기능과 다양한 유틸리티 기능을 제공합니다. https 서비스 연결, ssh 터미널에도 쓰입니다. 또한, 명령줄을 통해 온라인 인증서에서 정보를 검증하고 추출하는데도 쓰일 수 있습니다.

사견으로, 빌드 난이도는 nginx보다도 낮은, 무척 쉬움에 속하며 아무래도 종속성이 낮은 원시 코드에 가까워서 그런 것 같습니다. 그러나 시스템 설치 단계에서 기존 버전과 충돌을 처리하는 방법에서 고민해야하는 부분이 많으므로, 시스템 백업을 사전에 한 후 도전하길 강력하게 권합니다.

IIS에서 cipher 보안 개선하여 SSLLabs 고득점 노리기

IIS 의 SSL은 안전하지 않다?

Windows 10 1607, 그것도 Server 2016 1607이라는 나름대로 최신1 버전을 사용중이면서 IIS 를 지난 게시물에서 세팅한 바 있습니다. 그러나 그런 과정을 거쳐서 Let’s encrypt를 설정했는데도 불구하고 뭐가 부족했는지 SSLLabs에서는 가차없는 점수를 주었네요. 무엇이 문제일까요?

RC4를 써서는 안 되는 이유

RC4 암호화는 1987년 설계된 스트림 암호입니다. 스트림 암호인 만큼 빠르게 적용할 수 있고, 그간 널리 쓰여온 바가 있지만 이제는 사용을 권하지 않는다고 합니다. 다양한 취약점이 발견되었으며, 암호의 복잡도가 충분히 높지 않아서 무력화되기 쉬우며, 이 취약점이 바로 무선랜 암호화인 WEP를 신용할 수 없게 하는 주요 원인이기도 합니다. 그래서 새로운 SSL 프로토콜에서는 도입되지도 않았으며, 그런 낡은 것을 IIS 는 여전히 지원한다는 점에서 HTTPS 보안에 대한 점수를 크게 감점하게 된 것입니다.

Cipher 선택에 따라 좌우되는 보안

SSL에 대한 그간의 글에서 언급하였던 보안 사이퍼(cipher)는 암호화 방법을 의미합니다. 서버가 암호화할 줄 알아야 하겠지만, 클라이언트도 복호화할 줄 알아야만 올바르게 정보를 전달할 수 있을 것입니다. Cipher는 암호화 알고리즘으로 정의되며, 그 종류는 무척 다양합니다. 개중에는 최신식 고급 보안을 가진 것도 있는가 하면, 옛날부터 쓰던 것이라 취약점이 알려질대로 알려진 낡은 것도 있습니다.

물론 가장 최신의 알고리즘을 쓰면 더욱 안전한 건 당연하겠지만, 모든 브라우저를 만족시킬 수 없기 때문에, 옛날 OS에서는 에러 메시지만을 보게 될 것입니다. 그런 점을 고려하여 호환성과 안전 두 가지의 균형점을 갖춰보고자 합니다. 즉, 이 글은 조금 더 실용적으로 포장된 기존의 글 재탕으로 보셔도 될지 모릅니다.

IIS 에서 Cipher 선택하기

[시작]→[실행]을 들어가서 ‘gpedit.msc’를 실행하면 그룹 정책이 뜹니다. 그룹 정책에서 다음 경로로 들어갑니다.

컴퓨터 관리\관리 템플릿\네트워크\SSL 구성 설정

SSL Cipher Suite Order 항목을 눌러서 ‘사용’을 누르면 아래 입력칸이 한 줄로 있습니다. 한 번 기본값 전체를 살펴보겠습니다.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_RC4_128_MD5,
TLS_RSA_WITH_NULL_SHA256,
TLS_RSA_WITH_NULL_SHA,
TLS_PSK_WITH_AES_256_GCM_SHA384,
TLS_PSK_WITH_AES_128_GCM_SHA256,
TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_PSK_WITH_NULL_SHA384,
TLS_PSK_WITH_NULL_SHA256

RSA + PSK WITH NULL 있는 거 실화냐 / ECDSA랑 AES 붙을 때 자신감 있는 NULL

후순위이긴 하나 RC4는 물론 별다른 암호화가 없는 것으로 보이는 것도 보입니다. 이것이 보안의 허점을 노출하는 것으로 봐도 무방하겠습니다.

Windows에서 제안하는 변경점

Windows에서도 관련된 정보를 공개하고 있습니다. 여기 서술대로라면, 일단 크게 봐서 두 가지에 주의해야 합니다.

  • 일부 cipher는 HTTP/2 버전 연결을 미지원하므로 통신에 실패합니다. HTTP/1.1보다 HTTP/2가 지원하는 브라우저에선 서버 연결 속도에서도 압도적으로 낫기에 충분히 고려해봐야 합니다.2
  • SCH_USE_STRONG_CRYPTO시 Yes 되어 있는 것은 안전한 것으로 보고 있습니다. 그러나 여기서 Yes여도 SSLLabs의 깐깐한 판단으로는 WEAK에 속할 수 있습니다.

여기서 SCH_USE_STRONG_CRYPTO가 Yes인 것만 골라서 넣어보겠습니다.

TLS_PSK_WITH_AES_256_GCM_SHA384,
TLS_PSK_WITH_AES_128_GCM_SHA256,
TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

그리고 다시 SSLLabs 테스트를 받으니 여전히 WEAK 판정은 존재합니다. RC4를 없애니 랭크도 A로 올랐군요.

문제가 된 cipher를 추려내보겠습니다.

TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA

해당 cipher를 제거하고 넣으면 되겠군요. 추가적으로 최신 브라우저의 우선순위에 맞게 순서를 재배열하였습니다.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

HSTS 설정을 올바르게 하면 점수가 오를 것이다

이제 Cipher를 무결하게 만들고, 마지막 단계로 HSTS 설정을 하여 A+를 노려보겠습니다.

SSL이 강제될 사이트에서 HTTP Response Headers를 들어갑니다.

[Add…]를 눌러서 새로운 항목을 추가합니다.

다음과 같이 Strict-Transport-Security를 지정합니다. 이 값을 지정하고 헤더로 전송되면, 사용자 클라이언트 브라우저에선 향후 이 사이트에 대한 요청을 반드시 HTTPS로만 하게 되며 더욱 안전한 통신이 가능해집니다.

단, 추후 인증서를 해지하거나 만료되면 사이트에 아예 접속할 수 없을 수 있으니 이 설정에 유의하고 인증서가 없어지거나 만료되지 않도록 갱신 및 관리에 항상 신경써야 합니다.

Name: Strict-Transport-Security
Value: max-age=31536000

SSLLabs는 최소한 120일(10368000초) 이상 주어야 한다고 하며, 이상적인 값은 1년(31536000초)라고 합니다.

또한 평문 전송시 이러한 값을 전송해서는 안 되므로, redirect 전용 사이트 하나를 만들고 SSL 전용 사이트로 지정한 메인 사이트에서만 이러한 설정을 하는 것이 좋겠습니다.

저런, A+가 아직 나오지 않았어요

IIS의 한계랄까 안타까운 부분입니다. 이 부분에 대한 대응을 또 하나씩 해봅시다.

  • SHA1과 RC4 등 RC가 Cipher에 없음을 확인했습니다.
  • OCSP Stapling은 기본적으로 IIS가 챙기는 부분으로 별도의 설정은 불필요합니다. 다만, Must Staple 옵션을 적용할 방법이 보이지 않는군요.
  • Forward Secrecy는 ECDHE와 DHE를 지원한다면 저절로 robust support 될 것입니다.
  • TLS_FALLBACK_SCSV: 브라우저가 폴백(차선책) 시도를 할 수 있게 하여 구식 보안으로 다운그레이드하여 보안성을 약화시키는 것을 방지하는 기능입니다. 적절히 처리하지 못하면 POODLE 공격으로 이어질 수 있는데요. 안타깝게도 이 기능은 IIS에서 지원되지 않습니다.
    • 대신 TLS1.2 버전을 단독 지원함으로써 낮은 버전의 보안 연결을 원천적으로 봉쇄할 수 있습니다.
    • TLS1.2만 허용하게 되면서 버려지는 지원 기기의 예시는 다음과 같습니다.
      • Android 4.3 이전의 기기들
      • Baidu 2015년 1월 이전 버전
      • XP의 IE63~IE8
      • Vista의 IE7~IE8
      • Windows 7의 IE8~IE10 (Windows 7 현재 최신은 IE11)
      • Windows Phone 8.0의 IE8
      • Java 6, Java 7
      • OS X 10의 Safari 6.x

이 조치의 결과 A+를 획득하는데 성공했습니다. 그러나 버려지는 기기가 너무 많은 게 흠인 것 같습니다.

Windows Server IIS를 ASP 원격 배포 가능하도록 만들기

Java를 해보신 분이라면 Spring MVC로 Apache Tomcat에 한방에 올라가는 Eclipse의 연동된 환경이 꽤나 매력적으로 느껴지셨을 겁니다. 요즘은 파일 하나하나를 FTP로 업로드하기보단 패키지로 만들어서 설치하듯이 한 덩어리로 사이트를 구축하는 것이 관리하기도 편하고, 문제가 발생할 소지도 적어서 더 널리 쓰이는 게 아닌가 생각이 들 정도입니다.

이 글은 IIS에서 ASP 원격 배포가 가능하도록 설정하는 방법을 제시합니다.

준비물

  • Windows Server 2012 이상의 서버 OS
    • 당연히 IIS 역할이 추가되어 있어야 합니다.
    • Windows 8.0, 8.1 미지원으로 문서에 나와 있는데, Windows 10에서도 관련된 권한 옵션을 제공하는지 확인하지 못했습니다.
  • Web Deploy 설치 파일 (.msi)
  • 개발용 PC의 경우 Visual Studio 2017 Community 이상
    • 패키지를 만들어서 제공할 수 있는 다른 컴퓨터입니다.

순서

서버 역할 추가하기

서버 관리자에서 역할 및 기능 추가를 눌러줍니다.

IIS 관리 도구를 모두 선택해서 설치해줍니다. 이걸 먼저 해줘야 별탈이 없더군요.

Web Deploy 설치하기

Web Deploy 소프트웨어를 설치합니다. Web PI에서 3.5, 3.6 버전을 손쉽게 설치할 수 있습니다만, 이걸로 많은 문제가 발생합니다.

가장 흔한 게 접속 테스트에서 404, 550 같은 문제가 발생한다는 것입니다. 필요한 구성요소가 기본으로 선택되지 않은 채 설치가 진행되기 때문입니다.

그런 염려를 덜기 위해서는 직접 위 준비물 단락에 있는 링크에 들어가서 msi 파일을 다운받아 설치를 진행할 필요가 있습니다.

설치 마법사에서 모든 구성 요소 설치를 필히 선택해주세요. 설치가 완료되면 서버를 한 번 재부팅할 필요가 있습니다.

IIS 메뉴부터가 달라지거든요.

IIS 추가 설정

재부팅은 무사히 하고 오셨습니까? IIS에서 할 일이 좀 더 남았습니다.

모든 것이 순조롭게 설치되었다면, 관리 서비스 위임(Management Servicec Delegation) 항목이 설치되었을 겁니다.

지금은 이 항목에서 할 일은 없습니다.

내가 관리할 사이트를 (만들거나, 기존의 것을) 선택하여 마우스 우클릭으로 메뉴를 펼치고, [배포(Deploy)]→[웹 배포 게시 설정(Configure Web Publish Deploying…)]을 누릅니다.

여기서 게시 권한을 지정하고 설정하면 이 사이트에 대한 배포를 수용할 수 있게 됩니다.

사이트 설정이 완료되면 관리 서비스(Management Service)로 들어갑니다.

ID 자격 증명을 적합하게 설정하고 인증서도 https에서 쓸 수 있도록 올바른 것을 골라줍니다.

자신의 도메인 이름과 일치한 인증서를 사전에 발급받았다면 더욱 편리하게 설정할 수 있겠지요.

접속 테스트

올바르게 설정했으면 Visual Studio에서 접속을 확인해봅니다.

솔루션의 프로젝트 메뉴에서  [게시(Publish)…]로 진입합니다. 이미 게시한 적 있으면 저장된 프로필이 뜹니다.

타겟 방법은 IIS로 합니다.

Web Deploy를 선택하고 서버(IP / 호스트 이름), IIS 메뉴로 보이는 사이트 이름(기본 사이트), 유저명, 비밀번호, 목표 URL을 입력합니다.

목표 URL은 연결에 영향을 주지 않지만 미리보기 주소로 활용되는 듯 합니다.

[연결 테스트 (Vaildate Connection)] 버튼을 누르면, 상기 설정에 문제 없을 경우 통신 성공 여부가 뜹니다.

방화벽 설정

혹시 접속에 실패하는 경우 Windows 방화벽이 방해하고 있을 수 있습니다. 상기 항목이 제대로 옵션이 켜져 있는지 확인해봅시다.

테스트 프로젝트 배포

일반적인 문제 해결 방법

  • Web Deploy를 재설치하거나 업그레이드하는 경우, 관리 명령 프롬프트에서 다음과 같은 명령을 실행하여 핸들러와 에이전트를 다시 실행합시다.
    • net stop msdepsvc & net start msdepsvc
    • net stop wmsvc & net start wmsvc
  • 경로상에 있는 방화벽이 통신을 방해하지 않아야 합니다. Web Deployment Agent Service는 일반적으로 80포트를 쓰며, Web Management Service는 8172 포트를 씁니다.
  • MsDepSvc는 Administrator 또는 도메인의 Admin 그룹에서 실행되어야 합니다. 로컬 계정에서는 정상적으로 작동하지 않습니다.
  • .NET 4.0이 IIS에 등록되지 않았을 수 있습니다.
    • .NET 4.0이 설치되었으나 IIS 서비스 풀에 등록되지 않았을 수 있습니다. 그 원인은 .NET 4.0이 IIS 설치 전에 깔려 있지 않았기 때문입니다.
    • 다음 명령을 실행하여 해결합니다.
      • %systemdrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -iru

결론

Spring 부럽지 않은 일사천리 개발 환경이 갖추어졌습니다. SQL도 한방에 연결할 수 있는 것 같은데 관련된 정보를 더 많이 알아봐야 활용이 편리할 것 같습니다.

IIS 7에서 LetsEncrypt 설정하기

LetsEncrypt 는 무료 인증서 발급으로 https 확산에 혁혁한 공을 세운 단체입니다.1

특히 Certbot이라는 훌륭한 도구 덕분에 Linux 계열에서 Apache를 쓰든 Nginx를 쓰든 상관 없이 명령 몇 줄로 인증받는 시대가 열렸습니다.

그러나 윈도우에서는 공식적으로 LetsEncrypt 설치를 하는 방법이 제공되지 않습니다. 하지만 소스가 충분히 공개되어 있기에 누구든지 LetsEncrypt 인증 서버에 인증을 요청하고 인증서를 발급할 수 있습니다.

그러면 그냥 명령 쳐서 발급받으면 되잖아.

라고 하기엔 LetsEncrypt 인증서의 기간이 90일 이내로 짧기 때문에 자동 실행으로 갱신받아야만 하고, 그런 일을 대신해줄 프로그램은 필수입니다.

그런 역할을 해줄 프로그램을 소개해볼까 합니다.

Certify The Web

https://certifytheweb.com/

현재는 3.0.11 Stable 버전과 4.0의 Alpha 버전으로 나뉘어 있습니다. Alpha4가 문제가 있어서 Alpha3로 재공개했다는군요.

설치는 꽤 빠르게 이루어집니다.

메인 화면은 이렇게 생겼습니다.

바로 New Certificate를 눌러서 새로운 인증서를 발급해봅시다.
참고로 정식 버전이 아닌 경우에 상용으로 쓰지 말라고 경고가 여러 차례 뜹니다.

 

LetsEncrypt측에 전달할 나의 이메일을 적습니다.

만료 시기 도래 등 인증서에 특이사항이 있을 경우 향후 알려줄 수 있습니다.
이 기능은 리눅스 콘솔 버전 certbot과 완전히 동일하군요.

 

현재 IIS에서 작동중인 사이트를 선택합니다. 여러 곳에 쓰고 싶다면 여러 사이트를 모두 선택해도 되고, 사이트 선택 없이 발급만 할 수도 있습니다.
Request Certificate 버튼을 누르면 인증서 발급이 완료됩니다. Settings에 들어가서 갱신 일정도 올바른지 확인하세요.

이렇게 하면 IIS의 SSL 인증서에 LetsEncrypt가 올라가는 것을 확인할 수 있고, 향후에도 간단하게 변경할 수 있습니다.

단순히 HTTPS 통신에만 쓰는 것이 아니라, 원격 배포 기능과 FTP SSL 등 인증서가 필요한 분야가 많이 있으므로 폭넓게 활용할 수 있겠습니다.

한계

무료 버전은 5개의 사이트만을 관리할 수 있습니다. 프로 라이센스로 3개 사이트 더 추가하려면 약 50달러, 엔터프라이즈 라이센스로 100개 사이트 더 추가하려면 349달러네요. 여러 개 구매도 가능하다니 프로에 프로를 끼얹어도 되겠습니다.

문제 해결

  • 테스트 버튼을 눌러봤는데 실패할 수 있습니다. 외부 접속 체크시 DNS 확인이 올바르지 않을 수 있습니다. 인터넷 상황이 문제 없고 포트 바인딩이 되어 있으며 경로에 방화벽이 가로막지 않고 있다면, 과감히 Request Certificate를 눌러보세요.
  • 그 외에 Cloudflare 같은 DNS 서비스를 이용하고 있다면,  API Key를 발급받아서 넣고 이 앱에서 DNS-01 방식으로 체크를 요구할 수 있습니다. 이렇게 하면 서버의 파일 저장 공간에 임시 acme 테스트 없이 더 빠르고 문제 없이 도메인 소유 및 매치 여부를 확인할 수 있습니다. 와일드 카드 인증서(4 버전 이상) 발급시 DNS 인증이 필요할 것입니다.

Windows 2016 서버 구축

Windows Server 2016

은 제가 한 게 아닙니다. 그냥 저렴하게 샀어요. (클라우드의 시대! 관련 정보)

지금까지는 리눅스의 Ubuntu, CentOS 등에서 서버 구축을 LEMP 절차에 따라 진행해서 성공적으로 셋팅해왔죠. 허나 윈도우는 또 다른 도전입니다.

앞으로 무엇이 가능할지 더 찾아봐야겠습니다.

우선 IIS로 정통 셋팅하는 방법을 진행중입니다.

python

certbot 등 python에서 모듈 에러가 뜬다면 꼭 살펴볼 점

Letsencypt (certbot) 설정을 업데이트하면서, 이전에 한 Ubuntu의 대형 시스템 업데이트가 이것저것 망가뜨렸음을 알 수 있었다.

사실 리눅스의 상당 부분은 python 코드가 지탱하고 있다고 해도 과언이 아닌데(심지어 yum이나 apt-get도 포함한다), certbot 또한 예외가 아니다.

그냥 실행만 했을 뿐인데, 잘 되던 실행 파일이 이런 무참한 에러를 발생시키고 있었다.


:~$ sudo certbot
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in 
    load_entry_point('certbot==0.21.1', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 561, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2631, in load_entry_point
    return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2291, in load
    return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2297, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 10, in 
    import josepy as jose
  File "/usr/lib/python3/dist-packages/josepy/__init__.py", line 41, in 
    from josepy.interfaces import JSONDeSerializable
  File "/usr/lib/python3/dist-packages/josepy/interfaces.py", line 8, in 
    from josepy import errors, util
  File "/usr/lib/python3/dist-packages/josepy/util.py", line 4, in 
    import OpenSSL
  File "/usr/lib/python3/dist-packages/OpenSSL/__init__.py", line 8, in 
    from OpenSSL import crypto, SSL
  File "/usr/lib/python3/dist-packages/OpenSSL/crypto.py", line 16, in 
    from OpenSSL._util import (
  File "/usr/lib/python3/dist-packages/OpenSSL/_util.py", line 6, in 
    from cryptography.hazmat.bindings.openssl.binding import Binding
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/openssl/binding.py", line 156, in 
    Binding.init_static_locks()
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/openssl/binding.py", line 137, in init_static_locks
    cls._ensure_ffi_initialized()
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/openssl/binding.py", line 124, in _ensure_ffi_initialized
    cls.lib = build_conditional_library(lib, CONDITIONAL_NAMES)
  File "/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/openssl/binding.py", line 84, in build_conditional_library
    if not getattr(lib, condition):
AttributeError: cffi library '_openssl' has no function, constant or global variable named 'Cryptography_HAS_MEM_FUNCTIONS'

cffi library ‘_openssl’ has no function, constant or global variable named ‘Cryptography_HAS_MEM_FUNCTIONS’

보통 함수가 오류가 나고, 라이브러리를 제대로 된 것을 내놓으라는 위와 같은 오류가 발생하면,
파이썬 모듈을 다시 설치하면 해결되기 마련이다.

$ pip install cryptography

그러나 이 경우, 아무리 pip에서, 구글링했던 대로 cryptography를 다시 설치하더라도 문제가 해결될 기미가 보이지 않았다.

-U 옵션을 붙여서 강제 업그레이드를 하든말든 변화는 없었다.

그러다가 python 2.7이라는 표기와 python3라는 표기에 주목하게 되었다. 이미 2.7과 3에 3.5로 맨날 갈아엎으면서 기존 호환성이 무너지다보니 요즘 리눅스에선 다 설치하는게 추세가 됐다는 예의 그 문제다.

pip 실행 파일은 python 2.7에 대해서만 수정하고 있었으나, certbot은 python3를 필요로 하고 있으며 정상적으로 python3에서 실행될 수 있도록 다음과 같은 스크립트를 갖고 있다.

#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'certbot==0.21.1','console_scripts','certbot'
__requires__ = 'certbot==0.21.1'
import re
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(
        load_entry_point('certbot==0.21.1', 'console_scripts', 'certbot')()
    )

이제 해답은 명확해졌다. pip가 2.7에 모듈을 무의미하게 지웠다깔았다 하는 사이, python3는 문제가 전혀 해결되지 않았던 것이다.

$ sudo apt-get install python3-setuptools
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  python-setuptools-doc
The following NEW packages will be installed:
  python3-setuptools
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 215 kB of archives.
After this operation, 944 kB of additional disk space will be used.
Get:1 http://ppa.launchpad.net/certbot/certbot/ubuntu xenial/main amd64 python3-setuptools all 33.1.1-1+certbot~xenial+1 [215 kB]
Fetched 215 kB in 1s (109 kB/s)
Selecting previously unselected package python3-setuptools.
(Reading database ... 109834 files and directories currently installed.)
Preparing to unpack .../python3-setuptools_33.1.1-1+certbot~xenial+1_all.deb ...
Unpacking python3-setuptools (33.1.1-1+certbot~xenial+1) ...
Setting up python3-setuptools (33.1.1-1+certbot~xenial+1) ...

easy_install python3 버전을 깔기 위해 ubuntu에선 이 명령을 입력하면 된다. 설치된 easy_install3를 활용하여 pip도 같이 설치한다.

$ sudo easy_install3 pip
Searching for pip
Reading https://pypi.python.org/simple/pip/
Downloading https://pypi.python.org/packages/11/b6/abcb525026a4be042b486df43905d6893fb04f05aac21c32c638e939e447/pip-9.0.1.tar.gz#md5=35f01da33009719497f01a4ba69d63c9
Best match: pip 9.0.1
Processing pip-9.0.1.tar.gz
Writing /tmp/easy_install-wmqoi3hf/pip-9.0.1/setup.cfg
Running pip-9.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-wmqoi3hf/pip-9.0.1/egg-dist-tmp-b7xxe23x
warning: no previously-included files found matching '.coveragerc'
warning: no previously-included files found matching '.mailmap'
warning: no previously-included files found matching '.travis.yml'
warning: no previously-included files found matching '.landscape.yml'
warning: no previously-included files found matching 'pip/_vendor/Makefile'
warning: no previously-included files found matching 'tox.ini'
warning: no previously-included files found matching 'dev-requirements.txt'
warning: no previously-included files found matching 'appveyor.yml'
no previously-included directories found matching '.github'
no previously-included directories found matching '.travis'
no previously-included directories found matching 'docs/_build'
no previously-included directories found matching 'contrib'
no previously-included directories found matching 'tasks'
no previously-included directories found matching 'tests'
creating /usr/local/lib/python3.5/dist-packages/pip-9.0.1-py3.5.egg
Extracting pip-9.0.1-py3.5.egg to /usr/local/lib/python3.5/dist-packages
Adding pip 9.0.1 to easy-install.pth file
Installing pip script to /usr/local/bin
Installing pip3 script to /usr/local/bin
Installing pip3.5 script to /usr/local/bin

Installed /usr/local/lib/python3.5/dist-packages/pip-9.0.1-py3.5.egg
Processing dependencies for pip
Finished processing dependencies for pip

설치가 잘 된 듯 하니, 셸에서 실행 가능한지 확인해보자.

$ which pip3
/usr/local/bin/pip3

이처럼 절대 경로를 잘 표시해주고 있다. pip3 명령을 통해 cryptography 모듈을 깔아보자. 버전으로 난리치지 않게 U 옵션을 잊지 말고 넣어서, 강제로 업그레이드를 하도록 하자.

$ sudo pip3 install -U cryptography
The directory '/home/yeon/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/home/yeon/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting cryptography
  Downloading cryptography-2.1.4-cp35-cp35m-manylinux1_x86_64.whl (2.2MB)
    100% |████████████████████████████████| 2.2MB 451kB/s
Collecting idna>=2.1 (from cryptography)
  Downloading idna-2.6-py2.py3-none-any.whl (56kB)
    100% |████████████████████████████████| 61kB 3.7MB/s
Collecting asn1crypto>=0.21.0 (from cryptography)
  Downloading asn1crypto-0.24.0-py2.py3-none-any.whl (101kB)
    100% |████████████████████████████████| 102kB 3.1MB/s
Collecting cffi>=1.7; platform_python_implementation != "PyPy" (from cryptography)
  Downloading cffi-1.11.4-cp35-cp35m-manylinux1_x86_64.whl (419kB)
    100% |████████████████████████████████| 419kB 833kB/s
Requirement already up-to-date: six>=1.4.1 in /usr/lib/python3/dist-packages (from cryptography)
Collecting pycparser (from cffi>=1.7; platform_python_implementation != "PyPy"->cryptography)
  Downloading pycparser-2.18.tar.gz (245kB)
    100% |████████████████████████████████| 256kB 1.8MB/s
Installing collected packages: idna, asn1crypto, pycparser, cffi, cryptography
  Found existing installation: idna 2.5
    Uninstalling idna-2.5:
      Successfully uninstalled idna-2.5
  Found existing installation: asn1crypto 0.22.0
    Uninstalling asn1crypto-0.22.0:
      Successfully uninstalled asn1crypto-0.22.0
  Running setup.py install for pycparser ... done
  Found existing installation: cryptography 1.9
    Uninstalling cryptography-1.9:
      Successfully uninstalled cryptography-1.9
Successfully installed asn1crypto-0.24.0 cffi-1.11.4 cryptography-2.1.4 idna-2.6 pycparser-2.18

무언가 잘 진행되는 것 같이, 진행률 표시도 된다.

$ sudo certbot
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------

이후, 거짓말처럼 모든 것이 잘 작동하고 있다.

Servers

VPS를 고려하게 되는 이유, 저렴한 VPS 업체 비교

2020-12-12 추가: 이 글은 업데이트되지 않았으므로 최신 정보가 아닐 수 있습니다. 현재 서버는 Amazon Lightsail을 사용하고 있습니다.

웹 호스팅이 만능이 아닌 이유

웹 호스팅은 꽤 단순합니다. 그냥 사이트를 만들겠다고 마음 먹고 호스팅 업체에 신청하면 저렴한 옵션으로 만들어주죠.

이를테면, Cafe24의 경우엔 신청료가 별도로 있긴 하지만 한달 500원짜리까지도 있습니다. FTP로 접속해서 파일만 올리면 그야말로 홈페이지 셋팅 완료입니다.

이 과정도 생략하기 위해 WordPress나 제로보드 XE, 그누보드도 설치 지원해주는 업체가 많습니다. 이런 곳은 키보드도 별로 두들기지 않고 뚝딱 서버 완성입니다.

하지만 그렇게 해서 뿌듯하게 자신의 사이트를 만든 K씨(갑자기 사례자 등장?)
그는 디스크 사용량만을 고려하여 최저 플랜으로 웹 호스팅을 신청한 다음, 자신의 포트폴리오 사이트를 올려놓고, 면접 이력서를 여러 군데 넣고 본격적인 구직에 뛰어들었습니다.

어느 날, 취직 커뮤니티(Naver CAFE)를 방문한 K씨.

자신의 포트폴리오가 우수 사례로 공유되고 있다는 걸 알게 되자, 내심 뿌듯해했는데요.
그리고 얼마 가지 않아 고작 4번째 댓글에서 생각지도 못한 내용을 발견하게 되었습니다.

안 들어가지는데요.

어라? 하고 자신의 포트폴리오 사이트를 들어가보니, 반갑게 맞아준 건 이런 페이지였습니다.

카페24 트래픽 초과 페이지
카페24 트래픽 초과 페이지

부랴부랴 플랜을 업그레이드하려고 보니, 가격이 월 몇 만원까지 뛰어오르는군요. 트래픽 리셋을 매일매일 유료로 눌러주는 것도 대안이 되지 못합니다.

넉넉한 트래픽과 여유로운 공간, 이 두 가지를 노리려면 역시 가정집에 개인 서버라도 돌려야 하는 걸까요?
슬며시 전기료 걱정도 떠오르는데요.

VPS는 조금만 부지런하면 가장 유리한 옵션

그런 K씨의 지인은 VPS1를 소개해주었습니다. VPS란 것도 처음 듣는데, 들어보니 원격지에 서버 하나가 생기는 거라 하더군요.

호스팅 서버랑 뭐가 다르지 했는데, 이건 온전히 컴퓨터 한 단위를 다룰 수 있다고 합니다.

월 몇 십만 원에서 백만 원인 서버 호스팅은 많이 비싼데요. 이건 서버를 쪼개서 서버로 만든다고 합니다(!)

서버를 한 컴퓨터 안에서 여럿으로 나눌 수 있는 건 가상화 기술이 진보했기 때문입니다.
컴퓨터 속 컴퓨터로 명령어를 별도로 처리해야 했던 과거와 달리 CPU와 주요 장비들이 처음부터 가상화를 대비하고 만들어져서 성능의 저하를 최소화2한다고 합니다.

서버를 빌리는 것이니 가격도 상당하겠지만, 서버는 자유로운 용도로 활용할 수 있으므로 경우에 따라 더 유리할 수 있습니다. 특히 기본 트래픽이나 용량 제공이 그리 적지 않다는 점이 큰 매력입니다.

밑에서 서술하겠지만, 최소 트래픽 용량만 해도 웬만한 웹 호스팅 업체의 최고 플랜 수준입니다.3

하지만 VPS가 모두에게 올바른 답은 아니라는 것

분명 가성비가 좋은 것은 알겠지만, 그렇다고 별다른 지식 없는 사람이 덜컥 VPS를 신청하게 되면 접속부터 헤매게 됩니다.

겨우겨우 접속해도 갓 설치된 Ubuntu4의 검은 콘솔이 너무나 당혹스럽습니다.

최소한 윈도우 설치는 여러 번 해보고, 컴퓨터와 소프트웨어 개념이 어느 정도 있는 사람이면 명령어5와 관련 프로그램을 익히는 것으로 꽤 능숙해질 수 있습니다. (자꾸 까먹어서 문제지만요)

그러니까 검은 화면에서 LAMP(Linux+Apache+MySQL/MariaDB+PHP) 또는 LEMP(Linux+nginX+MySQL/MariaDB+PHP) 구성은 할 줄 알아야 한다는 것이죠. 물론 이에 관한 강좌는 아주아주 많으니 따라하는 것만으로 꽤 손쉽게 완료할 수 있습니다.

다만 문제 해결에서 크게 갈리게 됩니다. 분명 퍼미션(권한) 문제가 여러분을 괴롭힐 것이고요.
그 외 문제 원인을 파악하는데 항상 어려움을 겪는다면, 서버를 운영하려고 했다가 배울 거리만 늘었다고 푸념하게 되실지도 모릅니다.

주요 업체 비교

사실 VPS 업체는 더 세상에 많고, 아래 업체들보다 더 견실한 곳도 더 많을 겁니다.

그러나 어디까지나 제 주관적인 경험을 적고자, 직접 개설해본 적이 있는 곳만 나열해봤습니다.

ConoHa

VPS Conoha
VPS라면 코노하!
모에한 미유키
모에한 미쿠모 코노하

conoha.jp
모에버전6

코노하는 일본의 GMO 인터넷 주식회사에서 운영하는 가상 서버 호스팅 서비스입니다. 모기업도 탄탄하다고 하고, 이곳은 뭐니뭐니해도 무제한 트래픽7이 특징입니다.

글로벌 영업도 활발해서, 한국어는 당연하다는 듯이 홈페이지와 관리 콘솔에서 지원하고 있습니다.

하지만 용도외 사용이거나, DDoS 공격의 표적이 되기라도 하면, 일방적으로 서비스가 해지되며, 이를 해결하기가 무척 까다롭습니다.

또한, 메일로 영문 문의가 가능한데, 전화로 급한 문제를 해결하려고 한다면, 일본어는 필수입니다.

100Mbps 회선만을 지원하여 다소 아쉬운 속도입니다. 그러나 핑, 서버 연산은 또 회선과 별개의 문제죠.

이상하게 다소 느립니다. 도쿄를 골라도요. 그리고 이게 널뛰기를 하는 걸 보니, 오버부킹8이 의심스러운 점도 있습니다.

이용 금액은 크레딧으로 충전하거나, 신용카드를 연결할 수 있습니다. (해외 결제)

서버를 꺼도 크레딧이 소모됩니다.

ConoHa 컨트롤 패널
ConoHa 컨트롤 패널
ConoHa Japan Plan
ConoHa Japan Plan

장점

  • CPU 혜자
  • 트래픽 혜자
  • 덕후를 위한 덕후 디자인 제공(별도 메뉴). 덕후 취향 아닌 분들을 위한 담담한 버전(기본값).

단점

  • 이상하게 느린 속도. 널뛰는 접속 속도. 높은 핑.
  • 상담, 문제해결이 어려움. 친절하지만 사무적인 상담원
  • 기능이 많은 것 같지만 기능이 적은 관리 콘솔. API를 이용하라지만 관련 안내는 전무함.
  • 리모트 뷰(원격 서버 그래픽 표시) 도구가 없음. SSH 죽으면 막막함.

솔직히 말해 덕후 취향 노리든 말든 느린 건 용서가 안 됨

Vultr

Vultr
Vultr

vultr.com

Vultr는 다른 VPS 업체에 비해 신생인 편에 속하나, 높은 업타임으로 높은 신뢰도를 기록하고 있는 업체입니다.

문제가 발생하면 군말없이 크레딧을 얹어주며 보상해주고, 평소에도 추천인 링크로, 많으면 페이백까지도 시켜주는 혜자 정책을 취하고 있습니다.

링크를 타고 가입하면 깎아주는 시절도 있었는데 지금 이 글을 올리는 시점에는 딱히 이벤트가 없는 것 같습니다. 사이트를 직접 확인해보세요.

관리 콘솔이 단순하면서 관리하기 편하고, 필수적인 요소를 모두 갖고 있습니다.

스냅샷 저장에 과금하지 않으며 별도로 제약 사항도 없습니다. 서버 인스턴스를 복제하는데 써먹을 수도 있고, 문제 생겼을 때 롤백하는 가장 편리한 방법입니다. 스냅샷 생성과 적용(복원)도 10분 내외로 끝날 정도로 빠릅니다.

10Gbps의 빠른 회선을 갖고 있으며, 전세계 여러곳에 서버를 갖고 있어 원하는 곳을 골라 만들면 유용합니다.

뉴저지에 만들면 무료로 블록 스토리지를 제공합니다. 블록 스토리지를 연결하면 추가 하드디스크를 연결한 것처럼 용량을 확장할 수 있고, 데이터를 안전하게 보관할 수 있습니다.

도쿄에 만들면 ConoHa 부럽지 않은데, 여기는 회선은 멀쩡한데 오버부킹이 또 심하게 의심됩니다. 회선의 상태는 좋다는 것을 테스트 사이트에서 직접 확인할 수 있죠.9

이용 금액은 크레딧으로 결제하거나, 해외 결제 카드를 연결 가능합니다.

서버를 꺼도 크레딧이 소모됩니다.

장점

  • 편리한 관리자 콘솔
  • 혜자스러운 크레딧 제공, 다운 시간 피해 보상
  • 웹상에서 서버 그래픽 콘솔 제공
  • 스냅샷 생성 가능

단점

  • 참을 수 있을 정도의 느린 속도
  • 도쿄 지역의 높은 사용률, 낮은 서버 준비율(오버부킹을 예상할 수 있는 Availability Low 표시가 있음)
    • 가까운 도쿄가 이러니 국내에서 활용하기엔 점점 부적합해지는 경향이 있습니다.
    • 태평양 건너 뉴저지랑 비슷할 때도 있으니 절레절레

Somagu

Somagu
Somagu

somagu.com

소마구는 미꾸라지를 운영하는 미꾸라지네트웍스에서 커스텀 VPS 상품을 2017년 하반기에 출시하면서 시작했습니다.

절제된 디자인과 절제된 기능인데 비해, NoVNC 등 여러 방법으로 서버를 제어할 수 있는 수단을 제공하고, 고성능으로 옵션을 올려도 높은 비용을 요구하지 않습니다. 부업의 자신감?

한국에서 서비스하려면 한국에 있다는 지리적 강점으로, 속도가 상당히 빠릅니다.

서버의 소재지를 공개하셨는데, 경남 함안군 칠서면 구포리 62-34(…)로 공장 내부 서버랙에서 돌아가고 있다고 합니다.

직접 관리하는 게 아니라 가족에게 위탁하고 상태를 원격으로 점검하시는 것으로 보이는데, 이 탓에 문제 대응이 느리며, 포럼에 문의를 남기면 답변에 약 3일 이상은 각오해야 합니다.

하지만 이에도 장점이 있는데, 관리 UI에 없는 기능이라도 부탁하면 관리자께서 편의를 봐주신다는 점이죠. 오히려 세심한 하부 부분에선 관리를 맡긴다는 면에서 급하지 않은 서비스에 더 적합할 수 있겠습니다. (OS 위의 일은 사용자가 알아서 해야겠지만요)

장점

  • 성능 대비 무척 저렴한 가격
  • 국내 서비스의 쾌적함 (KT망)
  • Toss로 크레딧 지불 가능

단점

  • 느린 문제/문의 대응
  • 불안한 업타임, 전력 문제
    • 부정기적인 일대 전력 점검으로 서버가 꺼지는 경우가 있음
    • 서버 일부에 문제가 있다고 하셨으며, 교체 작업으로 인해 2017년 12월 기준 일시적으로 고사양 신청이 중단된 것으로 보임
  • 관리 도구의 기능 부재
    • 스냅샷 생성 기능이 별도로 없음
    • 관리 콘솔에선 컴퓨터 켜고 끄기, 원격 접속 정보 제공이 거의 대부분의 기능
  • 스위치 기반의 연결인데 포트 점유가 있는 듯
    • 같은 외부 포트를 여러 사용자가 같이 쓸 수 없는 것으로 보임
    • 20개로 제공된 포트 내에서 웹 UI를 통해 관리해야 함
    • 80 / 443 포트와 같은 HTTP에 대해서는 가상 호스트 방식으로 매핑해줌 (웹서버 동작에 이상은 없음)
    • 모든 원격 연결이 10.0.0.1 같은 내부 스위치 IP로 넘어옴. 방문자 IP 구분 불가. (X-Forwarded라도 ㅠㅠ)

스마일서브 (IwinV)

IwinV
IwinV

iwinv.kr

2002년부터 설립되어 오랫동안 발전시켜온 노하우를 갖고 있는 회사인데, 2014년 적자 업체 아이비호스트도 인수하는 등 적극적인 사업 확장 중입니다. VPS 분야는 iwinv에서 별도로 관리중입니다.

이 업체의 강점은 다양한 옵션, 저렴한 가격입니다.

장점

  • 가상코어, 리얼코어, 단독서버로 3단계로 나눈 상세 스펙 선택 가능
    • 가상코어란 CPU Core를 가상으로 다시 쪼갠 것으로, 다수 사용자에게 제공하기 위한 방법입니다. 타 사용자의 Core 사용량에 따라 크게 널뛰게 됩니다.
    • 리얼코어 사용시 CPU가 가상화로 인한 감쇠(10% 이내라고 주장)만 있고, 타 사용자의 간섭을 크게 줄일 수 있습니다.10
    • 단독서버가 당연히 제일 비싸지만, 그래도 타사보다 많이 저렴한 편
  • 포트 개방, 리소스 현황 파악 및 설정 상태 도달시 문자, 텔레그램, 이메일 통보 가능
    • 단, 문자는 문자 발송비에 대해 선충전후발송이므로, 텔레그램을 사용하는 편이 좋음. 자세한 설명이 실려 있음.
  • 기본 웹 방화벽 제공. OS도 방화벽 제공.
  • 웹상에서 서버 그래픽 콘솔 제공.
  • 스냅샷 생성 가능. 무료 생성 한도는 신청 인스턴스(서버) 용량의 2배까지만.
  • 신용/체크카드 후불형 결제
  • 블로터 등 유명 사이트들과 같은 IDC 센터 사용 (문제 발생 요인이 적음)

단점

  • 추가로 싸게 만들 프로모션은 딱히 눈에 띄지 않음
  • 부족한 결제 옵션

결론

VPS라는 것이 저렴해지고 가시화된지 오래되지 않아서 정보를 모으기 쉽지 않습니다.

그러나 리눅스에 보다 익숙해지고, 대형 서버에 의존하지 않는 자신만의 보안 대책을 강구하기 위해서라도 피할 수 없는 흐름인 것 같습니다.

하지만 어디까지나 본인에게 맞는지 따져보고서 결정할 일이겠죠. 여럿이 모여서 하나의 VPS를 신청해보는 것도, 사양이 허락한다면 꽤 유연한 사용 방법이지 않을까 생각합니다.

yeon.me TLS

[번역글] SSL과 TLS 배포 모범 사례

SSL / TLS는 놀라울만큼 간단한 기술입니다. 배포하기 쉬우며, 안 될 때를 제외하면 그냥 쉽게 작동합니다. 가장 큰 문제는 암호화가 보통 올바르게 배포되기 쉽지 않다는 점입니다. TLS가 적절한 보안을 보장하려면, 시스템 관리자와 개발자는 반드시 올바른 서버 설정과 앱 배포에 노력을 기울여야만 합니다.

2009년, TLS가 어떻게 쓰이는지, TLS 도구와 문서를 어떻게 개선할지를 알기 위해서 우리는 SSL Labs에서 일하기 시작했습니다. 그 결과 몇 가지 목표에 달성했는데, TLS 사용에 대한 전세계적인 통계와 온라인 평가 도구를 만들었으나, 문서 부족은 여전히 눈에 띕니다. 이 문서는 그 문제의 해법을 위한 첫 걸음입니다.

우리 목표는 안전한 사이트와 웹 애플리케이션을 배포하는데, 관리자와 프로그래머가 가능한 최소의 시간을 들이도록 명확하고 간결한 설명서를 제공하는 것입니다. 명확함을 추구하고자, 우리는 완성도를 희생하고, 특정 추가 주제도 건너뜁니다. 실질적이고 따라하기 쉬운데 요점을 두었습니다. 더 자세한 정보를 원하시는 분께는, 6장에서 유용한 정보를 제공합니다.

yeon.me TLS

“[번역글] SSL과 TLS 배포 모범 사례” 더보기

Ubuntu 16.04 + NginX에 Tomcat을 끼얹어보자

Tomcat은 기본적으로 Apache랑 한 세트라는 느낌인데, 그래서 Nginx를 설치할 때는 전혀 어울리지 않는다고 생각해서 얼씬도 하지 않았다.

그러나 SCIT마스터에서도 계속 배우고 있는 진도 과정이기도 하고, 결국 Java를 어딘가에 올려서 프로젝트할 필요는 있기에, Nginx에 JSP 기능을 다는 것은 어느 정도 피할 수 없는 선택이었다.

Cafe24에서도 한때 철수했다가 지금은 다시 서비스 하는 모양인데, JSP 호스팅과 PHP가 공존하는 서비스도 있고 (cafe24 메뉴에서 64비트 JSP 호스팅 서비스가 그렇다) PHP가 빠진 대신 tomcat이 7에서 8 버전으로 올라갔다. 이 무슨 생색이냐

역시 PHP 구 버전 보는 것 같이 하나 같이 구닥다리 냄새가 나지만, 이쪽도 레거시 때문인지 좀처럼 버전을 올리지 못하고 여러 가지를 동시에 유지하고 있는 것 같다. Tomcat 9이 있는데 그리 관심 받지 못하는 것이 그걸 증명한다.

이미 Nginx가 셋팅되어 있는 환경에 요점만 적으면서 정리해둔다.

        1. 톰캣을 깐다.
          1. # apt-get update
            # apt-get install tomcat8
        2. 더 이상 깔 것은 없어 보인다.
        3. 편하게 home 디렉토리에서 웹 루트로 들어갈 수 있도록 심볼릭 링크를 생성한다.
          1. # ln -s /var/lib/tomcat8/webapps/ ~/webapps
        4. 톰캣이 정상적으로 구동중인지 확인하고, 구동중이지 않으면 실행한다.
          1. # service tomcat8 status
            # service tomcat8 start
        5. nginx.conf (보통 /etc/nginx에 위치) 열고 파일을 수정한다. include가 있는 형식이면 server 절을 include에서 찾아야 할 수 있으니 유의.
          1. 파일 내용에서 http절에 다음줄을 추가한다. /etc/tomcat8/server.xml의 내용을 참고하여 올바른 포트(기본값 8080)를 지정한다.
            1. # for tomcat jsp
                  upstream tomcat {
                      ip_hash;
                      server 127.0.0.1:8080;
                  }
          2. server절을 다음 내용으로 고친다. name이 겹치면 기존의 server 절을 없앨 필요가 있다.
            1. server { # MY DOMAIN
                      listen       80;
                      server_name  mydomain.net;
              
                      location / {
                          proxy_set_header    HOST $http_host;
                          proxy_set_header    X-Real-IP $remote_addr;
                          proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
                          proxy_set_header    X-Forwarded-Proto $scheme;
                          proxy_set_header    X-NginX-Proxy true;
              
                          proxy_pass http://tomcat;
                          proxy_redirect  off;
                          charset utf-8;
                      }
              }
        6. nginx -t 를 실행하여 ok 사인을 확인한 다음 service nginx reload로 적용한다.
        7. 위 server_name과 같은 도메인을 입력하여 잘 작동하는지 확인한다.

apt-get install tomcat8-examples 해서 예제를 깔아주면 JSP와 서블릿이 부드럽게 돌아가는 것을 확인할 수 있다.

8080을 굳이 칠 필요가 없고, 기존의 php 서버와도 충분히 공존할 수 있음을 확인했다. 이제 SSL이 적용되어도 잘 되는지, 신규 도메인 적용 후 확인해볼 필요가 있겠다.

덧… 당연히 SSL / TLS 적용도 무사히 성공했다. 이제 서비스도 같이 할 수 있을 것이다.

CentOS 7에서 Nginx/PageSpeed Module + PHP-FPM7.1 + MariaDB 설치, 보안 로그인 (6)

Ajenti 설치

시스템 현황을 보여주는 ajenti 콘솔은 강력하고, 유용하게 쓰일 수 있다. 콘솔에서 처리해야할 상당 부분을 건너뛸 수 있고, 현재 서비스가 잘 돌고 있는지 위젯을 만들어서 직접 관리할 수 있다.

공식 사이트는 이곳이며, 설치 매뉴얼이 있긴 하나, 정말로 부실하므로 큰 도움이 되지 않는다.

$ curl https://raw.githubusercontent.com/ajenti/ajenti/master/scripts/install.sh | sudo bash -s -

이걸로 충분하다고 한다.

python 의존성 관련된 오류가 발생하는 경향이 있다. 다행히 별 문제가 없었지만, 케이스가 발견되는대로 여기 내용을 추가해나가야겠다.

설치가 완료되면, sudo 권한을 얻지 못하는 문제를 해결해야할 필요가 있다. 다음 명령으로 conf 파일을 편집할 수 있다.

$ sudo nano /etc/ajenti/config.yml

바인드 포트를 잘 확인하고 지정한다. 기본 포트는 port: 8000이라고 되어 있듯이, 8000번 포트를 사용한다. restricted_user: 계정 이름 이렇게 입력해주고 저장해야만 나중에 1 incorrect password attempt 오류를 피할 수 있다.

$ sudo firewall-cmd --permanent --zone=public --add-port=8000/tcp
$ sudo firewall-cmd --reload

이 명령으로 포트도 확실하게 열어둔다.

 

다 되었으면 실행해본다.

$ sudo systemctl start ajenti

웹에서 구동은 다음 주소에서 가능하다.

http://서버주소:8000

서버 OS 계정으로 로그인할 수 있다. ssh 계정과 동일하다고 보면 된다.

CentOS 7에서 Nginx/PageSpeed Module + PHP-FPM7.1 + MariaDB 설치, 보안 로그인 (5)

PHP 7.1 설치

홈디렉토리에 역시 저장소 파일을 받아서 등록하자. 기본 php 저장소 역시 너무 구버전이라 remi-release-7으로 갈아치울 필요가 있다.

$ cd ~
$ wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm
$ rpm -Uvh remi-release-7.rpm
$ yum-config-manager --enable remi-php71
$ sudo yum install php php-devel php-fpm php-gd php-mbstring php-pdo php-pecl-swoole php-cli php-intl php-soap php-tidy php-xml php-xmlrpc

쓸만한 php 모듈을 모두 등록한 경우이며, 필요에 따라 가감할 수 있다.

다음으로 php-fpm 연동이다.

$ sudo nano /etc/php.ini

cgi.fix_pathinfo를 찾아서 =0으로 바꿔준다. 이는 필수적인 PHP 보안 설정이라고 한다.

이어서 php-fpm.d 설정을 한다.

$ sudo nano /etc/php-fpm.d/www.conf
listen = /var/run/php-fpm/php-fpm.sock
user = nobody
group = nobody

각각 내부에 listen = / user = / group = 항목이 다 들어 있으므로 복붙하지 말고, 찾아서 해당 부분을 각각 수정해야 한다.

다 되었으면 실행해본다.

$ sudo systemctl start php-fpm

CentOS 7에서 Nginx/PageSpeed Module + PHP-FPM7.1 + MariaDB 설치, 보안 로그인 (4)

maria db 설치

$ cd /etc/yum.repos.d/
$ sudo nano MariaDB.repo

이렇게 입력하면 yum 패키지 원본으로 MariaDB 저장소를 새로 지정할 수 있다. 이렇게 하지 않으면, 기본으로 있는 패키지는 너무 구버전이다.

# MariaDB 10.2 CentOS repository list - created 2017-11-06 14:03 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.2/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

저장하고 다음 명령을 실행한다.

$ sudo yum update

이제 설치한다.

$ sudo yum install MariaDB-server MariaDB-client

이렇게 하면 자동으로 패스워드 설정 페이지가 나온다. 접속에 필요한 정보니 신중하게 설정하면 된다.

$ sudo systemctl start mariadb

mariadb가 시작된다.

다음 글에서 이어집니다.

CentOS 7에서 Nginx/PageSpeed Module + PHP-FPM7.1 + MariaDB 설치, 보안 로그인 (3)

기본 시스템 설정

root인 김에 막바지 작업을 끝마치자. 도메인을 갖고 있다면 시스템을 도메인과 일치시키는 편이 관리하기에 수월할 것이다.

# hostname mydomain.net

이어서 hosts 파일도 수정한다.

# nano /etc/hosts

127.0.0.1 / ::1인 첫 항목을 바꿔버린다.

# nano /etc/sysconfig/network

여기서도 HOSTNAME= 오른쪽의 이름을 나의 도메인으로 맞춘다.

해외든 국내든 서버가 어디에 있어도 대한민국 대상으로 서비스한다면 서버 시계도 맞춰주면 좋을 것이다. 다음 방법으로 금세 시간대를 맞출 수 있다.

# timedatectl set-timezone Asia/Seoul

참고로, 가능한 시간대를 모두 출력하려면 다음 명령을 통해 볼 수 있다.

# timedatectl list-timezones

대륙을 알고 있다면 뒤에 | grep Asia 이런식으로 적어주면 더 간략하게 필요한 정보만 추려낼 수 있을 것이다. 이제 root 로그인은 종료해도 괜찮다.

Nginx 빌드

이 절부터는 처음에 만든 신규 계정으로 로그인하고 진행한다.

yum install nginx로 순식간에 설치되는 것이 nginx의 장점이거늘, 여기서는 직접 빌드에 도전해본다. 원래 빌드는 관련 의존성 패키지를 다 깔아주고, 경로도 맞춰줘야 하는 등 무척 까다로운 과정을 거쳐야 한다. 그러나 Nginx는 비교적 쉬운 작업으로 빌드가 가능하다는 점, 또 빌드를 통해서만 원하는 추가 모듈을 깔아줄 수 있다는 점에서 언젠가 꼭 거쳐야 할 과정이라고 생각한다.

gzip이나 기타 유용한 모듈을 쓰려면 빌드 방법은 꼭 알아둘 필요가 있다.

$ sudo yum install gcc-c++ pcre-devel zlib-devel make unzip libxml2-devel libxslt-devel gd-devel GeoIP GeoIP-devel perl

시행착오 끝에 빌드시 괴롭히는 것들을 다 깔 수 있었다.

$ wget https://zlib.net/zlib-1.2.11.tar.gz
$ wget https://www.openssl.org/source/openssl-1.1.0g.tar.gz
$ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.41.tar.gz
$ tar -xzvf ./zlib-1.2.11.tar.gz
$ tar -xzvf ./openssl-1.1.0g.tar.gz
$ tar -xzvf ./pcre-8.41.tar.gz

의존성 있는 라이브러리들도 같이 준비해준다. 공식 홈페이지에서 최신 버전으로 맞추는 편이 좋다. 다만, perl 같은 경우엔 메이저 버전이 높은 것으로 하면 문제가 생길 수 있다.

$ ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --user=nginx --group=nginx --build=CentOS --builddir=nginx-1.13.6 --with-select_module --with-poll_module --with-threads --with-file-aio --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_auth_request_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_geoip_module=dynamic --with-stream_ssl_preread_module --with-compat --with-pcre=../pcre-8.41 --with-pcre-jit --with-zlib=../zlib-1.2.11 --with-openssl=../openssl-1.1.0g --with-openssl-opt=no-nextprotoneg --add-module=../ngx_pagespeed-1.12.34.3

make 하기 전 설정 과정을 거친다. 여기서 의존성 체크를 당하고, 에러가 나면 구글링하면서 또 해결을 해야 한다. 무사히 끝나면 make가 남는다.

$ sudo make
$ sudo make install

에러가 나지 않기를 기원한다. 참고로 512MB에서 make시 fatal error가 발생했다. 램이 부족하면 죽어버리는 모양이다. vps라서 업그레이드는 간단했다만, 다운그레이드가 안 돼서 좀 그렇다.

$ sudo groupadd nobody
$ sudo useradd -g nobody nobody

Nginx 서버에서 사용할 계정을 만들어야 한다. 방문자가 파일을 확인하게 되는 기본 사용자인 만큼, 보안을 최대한 고려하여 필요한 권한만 제공되어야 한다.

손수 빌드할 경우 서비스로 등록되지 않는다. 서비스 등록을 위한 과정을 거치면, 부팅시 자동으로 웹 서버가 기동된다.

$ sudo nano /lib/systemd/system/nginx.service

여기에 다음 내용을 붙여넣자.

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target
			
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

이렇게 하면 실행된다.

다음 글에서 이어집니다.

CentOS 7에서 Nginx/PageSpeed Module + PHP-FPM7.1 + MariaDB 설치, 보안 로그인 (2)

root 수정

처음 VPS 서버가 생성되면, root 계정과 비밀번호를 관리 패널에서 알 수 있다. 그러나 root를 로그인할 수 있게 두고, ssh를 기본 포트로 쓰면 IP는 쉽게 알 수 있으므로 전세계에서 공격이 들어오게 된다.

따라서 안전하게 서버를 운영하고, 공격자를 막기 위해서는 본인만의 설정을 만들고 관리자 계정을 비활성화하여 서버 권한 탈취를 막아야 한다.
왼쪽에 $인지 #인지 여부로 쉽게 루트 권한인지를 알 수 있다.

putty로 연결하는 법까지는 알고 있다고 하고, putty 접속을 마친 다음 작업을 시작한다. 주로 쓸 계정을 새로 만들 것이다. 여기서는 myadmin이라고 하자.

# useradd myadmin
# passwd myadmin

비밀번호를 새로 셋팅하는 화면이 뜬다.

# nano /etc/sudoers

이걸 실행하면 sudo 명령을 쓸 수 있는 계정을 선언할 수 있다. 다음 부분을 추가하자.

myadmin       ALL=(ALL)       ALL
myadmin    ALL=NOPASSWD: /usr/libexec/openssh/sftp-server

첫째 줄 따로 모여 있는데 내려가면서 비슷한 명령끼리 모아서 새로 한 줄씩 추가하면 된다.
NOPASSWD라고 쓰여 있는 두 번째 줄은 WinSCP 설치시 유용한 기능인데, 이를 통해 WinSCP에서 myadmin으로 접속해도 sudo를 친 것과 동일한 효과를 얻을 수 있다.

nano 에디터를 저장하는 방법은 Ctrl+O를 누르는 것이다.

ssh 포트 변경

우선 패키지를 처음으로 설치하기 전에 패키지 목록을 업데이트하자.

# yum update

가까운 미러 사이트를 저절로 검색하면서 이것저것 다운로드 받을 것이다. 그걸로 할 일은 충분하다.

이어서 CentOS 7에서 netstat을 설치하는 법은 간단하다. netstat을 통해 열린 포트르 확인할 수 있다.

# yum install net-tools

Install y/n에서 당연히 y를 쳐야 하는 것은 기본이다.

# netstat -anp | grep LISTEN | grep sshd

이렇게 치면 LISTEN이라고 표기된 sshd 포트만을 찾아볼 수 있다.

tcp        0      0 0.0.0.0:22            0.0.0.0:*               LISTEN      825/sshd

숫자는 다를 수 있지만 :22 라고 쓰인 부분에서 22번 포트가 열린 것을 확인할 수 있다.

# cat /etc/ssh/sshd_config | egrep ^\#?Port

여기서 Port 22 라는 글자가 보인다면 이 파일은 타겟이 확실하다.

# nano /etc/ssh/sshd_config

nano 편집기가 뜨면 Ctrl+W 키를 눌러서 port를 찾아서 해당 문구를 주석처리(# 붙이기)하고 밑줄에 같은 형식으로 추가한다. 원하는 포트를 1234로 가정하면 다음과 같다.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
Port 1234
#AddressFamily any

Ctrl+W를 또 눌러서 permit이라고 쳐본다. PermitRootLogin 항목이 뜰 것이다.

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

해당 부분의 주석(#) 표기를 해제하고, no라고 바꿔서 저장한다.

# service sshd start

이 명령을 써서 sshd 서비스를 재시작한다. 현재 sshd로 로그인되어 있는 세션이 풀리지는 않는다. 다음 번 로그인 때 설정이 적용되어 기존 셋팅으로 로그인이 안 될 것이다.

방화벽 설정

잠깐, 아직 연결을 종료해서는 안 된다. 기본적으로 켜져 있는 방화벽 관련 설정을 맞춰야만 한다. 그렇지 않으면 시스템이 모르는 포트로 접속시 바로 차단된다.

# firewall-cmd --permanent --zone=public --add-port=2123/tcp

firewall-cmd 명령에 포트 번호와 프로토콜, 항구적 설정임을 명시하여 config에 추가하는 것이다.

앞으로도 포트를 쓰는 모든 서비스는 이렇게 포트를 열어줘야만 정상 접속이 가능해진다. 예를 들어, 우리는 HTTP/HTTPS 서버를 운영할 것이므로, 다음과 같은 명령도 미리 실행해줘야 웹 서버로서 기능을 할 것이다.

# firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https

이렇게 미리 정의된 서비스를 허용할 수도 있다.

# firewall-cmd --reload

모든 과정이 끝나면 –reload를 해야만 변경 사항이 적용된다.

다음 글에서 이어집니다.

CentOS 7에서 Nginx/PageSpeed Module + PHP-FPM7.1 + MariaDB 설치, 보안 로그인 (1)

Ubuntu 이외의 첫 리눅스 도전

서버를 구축하면서 처음에는 익숙한 Ubuntu로 막연하게 되겠거니 생각했는데,
사실 말처럼 우분투는 그렇게 가볍지 않았다.

물론 무언가 검색했을 때 바로바로 해결책이 나오고 apt-get으로 나오는 검색 결과가 많은 점은 확실히 메리트이긴 하나, 몇 가지 마음에 안 드는 점이 있었는데…

  • 너무 잦은 업데이트
    • 아무리 서버 콘솔 운영체제를 깔아도 우분투의 패키지 업데이트는 무척 많고 방대하고 잦다.
    • 아무 생각 없이 업데이트 했다가 기존에 잘 돌아가던게 안 될 우려가 크므로 신중해야 하는데, 로그인시마다 업데이트 몇 개가 있다고 압박을 한다.
  • 너무 많은 변수
    • 소프트웨어도 다양하고 좋은 점은 있지만, Ubuntu에서 셋팅법은 타 OS보다 더 다양하고, 그만큼 문제의 요인도 많아보인다.
    • 물론 대부분의 단점은 본인의 미숙함에서 오는지라, 그냥 이런저런 문제로 Ubuntu 말고 CentOS가 서버에 적합하다는 의견을 많이 보게 되면서 골랐다고 보면 된다.
  • apt와 apt-get보다 yum이 단순하고 편하다.
    • 이건 철저히 취향 문제인지라… 좀 더 써보면서 결론을 내볼까 한다. 일단 명령이 짧은 건 명백한 장점이다.

Apache보단 Nginx가 답인가

Apache가 일반적인 서버 셋팅의 정석인 듯 한데, Apache는 무겁고, 셋팅이 결코 단순하지 않다. Nginx가 가볍다고 잘라 말하기엔 다양한 상황이 있고, 멀티미디어 성능에서는 상호간에 큰 차이가 없는 것으로 나타나있다. 편한 걸 쓰기 나름이지만, config의 스타일이 직관적인 점과 FastCGI가 기본인 Nginx가 더 끌렸다.

그럼 이제부터 서버 셋팅을 시작해보자. 따끈따끈하게 VPS에서 CentOS 7 서버를 만들어낸 상황으로 가정하자.

참고로 본 서버는 Vultr에서 구동되고 있다. 서버 셋팅에 관해서 후일 더 자세하게 적어볼 생각이다. 링크를 누르고 신규 서버를 셋팅하고 금액을 지불하면, 신규 가입자와 글쓴 본인 모두에게 소정의 적립금이 적립된다고 한다.

다음 글에서 이어집니다.