Skip to main content

[翻訳] 1. 証明書の透明性(Certificate Transparency) 概要

証明書の透明性 概要

グーグルの証明書の透明性プロジェクトはすべてのHTTPSコネクションに使われるSSL証明書システムの欠陥を修正します。この欠陥はインターネットコネクションの暗号化コネクションの効用性と信頼性を脆弱にし、ドメイン認証、両側の暗号化、そして証明書を通じて生じられた信頼チェーンを含むTLS/SSL構図の深刻な損傷をもたらすこともあります。これを放置すると、この欠陥がウェブサイトなりすまし、サーバー偽装、中間者攻撃など広範囲なセキュリティー攻撃を容易にします。

証明書の透明性はSSL証明書をほぼリアルタイムに近くモニターし、監査できるオープンフレームワークを提供することで、このような欠陥を除くに役立ちます。特に、証明書透明性はSSL証明書が証明書認証が間違った場合、他のところでむやみに証明書の認証をもらったかを確認できるようにします。証明書の認証が悪意を持っているユーザーに乗っ取られて間違った認証を受けたかも確認できるようにします。

公開されいるオープンフレームワークなので、誰でも証明書の透明性を確かめる核心コンポーネントのビルドやアクセスができます。これは特に、ドメインの所有者、証明書の認証者、そしてブラウザの製造者など、SSL認証システムの無欠と好調を維持して、インターネットを構成するインターネットのセキュリティー関係者に特に役立つものです。

証明書の透明性を深く調べるには、導入ドキュメントをご覧ください。すでに証明書の透明性について、基本概念に馴染んでいる方は、詳細実装のための詳しいデザイン文書をご覧ください。証明書の透明性のフレームワークを起動する核心コンポーネントをビルドする方法についてオープンソースプロジェクトもあります。

証明書の透明性とは?

現代の暗号化技術のおかげで、ブラウザは常に偽装、偽物のSSL証明書が提供される怪しいウェブサイトの見分けができます。しかし、現在の暗号化技術は間違って発行された証明書と、危うくなったか、悪意を持っている集団に乗っ取られた証明機関(CA)の証明書が提供される怪しいウェブサイトを見分けるほど優れてはいません。この場合、ブラウザは証明書に問題がないと表示して、証明機関が信用できるし、訪問しているウェブサイトのコネクションが安全だという間違った印象を与えます。

ここで問題は、現在は簡単で効果的にSSL証明書をリアルタイムで監査、または監視する技術がなくて、このような(怪しい)誤作動が起きるのであって、疑いのある証明書は普通は検出されなく、証明書の取り消しは数週間後、あるいは数か月後になります。それに、このような種類のSSL誤作動の頻度がさらに増えつつあります。最近の数年間間違って発行になった証明書が適法なサイトとして仮装するに使われ、一部の場合、怪しいソフトをインストールしたり、ユーザーを浸透するにも使われました。

一例として、有名なオランダ証明機関(DigiNotar)が攻撃されて、ハッカーはCAシステムを利用して、偽物のSSL証明書を発行することができました。証明書はイランでGmailとFacebookなどの数多くのサイトを仮装することに活用されて、偽物のサイトの所有者がユーザーに浸透できるようにしました。

여기서 문제는, 현재로선 쉽고 효과적으로 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をインストールして、アップデートする方法

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バージョンであって、今後アップデートをなるべく避けたいし、最新機能を必要としていない方にお勧めします。多分、Ubuntuのデフォルトバージョンなので、このようにするひゆ

원하는 항목을 브라우저에서 링크만 복사하여 아래 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年設計されたストリーム暗号です。ストリーム暗号である分、速く適用できるし、今まで幅広く使われてきましたが、今は使用はお勧めきないそうです。いろいろ脆弱さが発見されたこと、暗号は十分に複雑ではないこと、したがって無線LANの暗号化形式の一つであるWEPを信用できなくなった原因でもあります。よって、新しいSSLプロトコルでは導入されたこともないし、そんな古いものをIISではまだサポートしていることでセキュリティーの点数に損をしてしまったわけです。

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ってなんでしょう

高順位ではありますが、RC4はもちろん、別途の暗号化アルゴリズムを持っていないものも見えます。これが保安の弱点になりうるところです。

Windowsのドキュメントでの提案

Windows公式ドキュメントからも関わっている情報を公開しています。この通りなら、大きく2つに注意しましょう。

  • 一部cipherはHTTP/2バージョンのコネクトをサポートしていないので、通信に失敗します。バージョンが2になると同時リクエストができるので、速度に必要です。
  • SCH_USE_STRONG_CRYPTOの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設定をすることでA+を目指そう

Cipherも無欠になったところなので、最後にもう一押しでA+を撮る裏ワザを紹介いたします。

SSLが強制されるサイトでHTTP Response Headersを設定します。

[追加(Add)…]を押して新しいアイテムを追加しましょう。

ご覧になってるように、Strict-Transport-Securityを設定します。このバリューを設定したうえで、ヘッダーに転送されたら、ユーザークライアントブラウザでは今後このサイトに対するリクエストをすべてHTTPSのみに制限し、一時的にHTTPになる可能性を防げるので、より安全な通信ができます。

ただし、これからは証明書の抹消、期限切れの問題があった場合、サイトにまったく接続できなくなるかもしれません。証明書の管理に特に気を付けなければなりません。

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

SSLLabsは少なくとも120日(10368000秒)以上を要求し、理想的な値は1年(31536000秒)だそうです。

また、平文伝送の場合、このようなヘッダーは望ましくないので、リダイレクトの専用サービス一つを作り、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でのIE62~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エラーのようなことが起こるということです。必要なコンポーネントがまったく一緒にインストールされないようです。

そういう恐れを逃れるため、自分でリンクをクリックしてインストールしてみましょう。ファイルは上記の持ち物にあります。

インストールウィザードですべてのコンポーネントインストールを必ず選んでください。インストール完了したら、サーバーも一回再起動します。できるならシステム再起動してですね。

IISメニューを読み直しする必要があるからです。

IISのエキストラ設定

再起動はいかがでしたか。IISでの仕事がまだ残っています。

もし、すべてが順調ならば、Management Servicec Delegation項目も見えるはずです。

今は何もすることはありませんが。

私がこれからリモートで管理するサイトを(作るか、既存のものを)選択して、デプロイ(Deploy)のウェブデプロイ設定(Configure Web Publish Deploying…)を押します。

ここでデプロイ権限を設定したら、このサイトにアップロードをもらえるようになります。

サイトの設定が終わったら、マネジメントサービス(Management Service)に入りましょう。

ID資格証明を適当に設定し、証明書も使えるようにhttpsの証明書を選んでおきます。

自分のドメインネームを合う証明書を事前にもらって置いたらさらに便利でしょう。

接続テスト

間違いなく設定したら、Visual Studioで接続を確かめられます。

ソリューションのプロジェクトのメニューで [公開(Publish)…]に入ります。すでにしたことがあるなら、保存されたプロフィールが先に出ると思います。

ターゲットメソッドはIISにしましょう。

Web Deployを選び、サーバー(IP / ホストネーム)、IISメニューで見えるサイトの名前(Default Web Siteなど)、ユーザー名、暗証番号、ターゲット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よりも強力なVisual Studioとサイトが繋がりました。SQLも一気にできそうですが、活用も知識次第だと思います。

IIS 7でLetsEncryptの設定

LetsEncryptは無料証明書の発行でhttpsの拡散に貢献した団体であります。1

特に、Certbotという強力なツールにより、Linux系ではApacheを使おうが、Nginxを使おうが、関係なくコマンド数行で証明書がもらえる時代になりました。

ですが、Windowsでは公式的にLetsEncryptの証明書をインストールする方法が提供されません。なのに、ソース公開も十分できているので、誰でもLetsEncryptの認証サーバーに接続して、証明書がもらえます。

だったら、自分で通信すればいいのでは?

というわけには恐れ入りますが、LetsEncryptの証明書の期限が90日以内で大変短いので、自動実行で更新されなかったら問題になりがちです。ツールの使用は避けられませんね。

そういうツールには何があるんでしょうか。

Certify The Web

https://certifytheweb.com/

現在は3.0.11 Stableバージョンと4.0 Alphaバージョンに分けられています。Alpha4の問題により、Alpha3を再公開したらしいです。

インストールは素早く進められます。

メインはこうなっています。

すぐにNew Certificateのボタンを押して、新しい証明書をもらってみましょう。
ちなみに、正式バージョンではない場合、常用はやめてほしいという警告が何回か出ます。

 

LetsEncrypt側に伝えたい自分のメールアドレスを書きます。

期限切れの到来など証明書の特異事項のお知らせが届きます。
この機能はLinuxのcertbotとまったく同じですね。

 

現在IISでサービスしているサイトを選びます。複数のサイトに使いたければ、複数選択も可能であり、サイトを選ばずに、発行のみも可能です。
Request Certificateボタンを押すと、証明書の発行は完了です。Settingsに入って、更新日程も正しいか確認する必要があります。

こうすると、IISのSSL証明書にLetsEncryptが入れられたことが分かり、今後もすぐに変更ができます。

HTTPS通信だけではなく、リモート配布機能とFTP SSLなど証明書が必要な個所に幅広く活用もできます。

限界

無料バージョンは5個のサイトまで管理ができます。プロライセンスでは3個の追加が50ドル、エンタープライズライセンスでは100個の追加が349ドルです。複数購買もできるので、多数のサイトには購入が必須です。

トラブルシューティング

  • テストボタンを押したとき、失敗する可能性もあります。外部接続確認の時、DNS確認が正しくない場合があります。インターネットのコネクションに問題がなく、サイトのバインドも設定されて2、ファイアウォールも遮ることなかったら、Request Certificateを押してみても問題はないはずです。
  • その他CloudflareなどのDNSサービスを使用中なら、API Keyを入れておいて、このアプリでDNS-01方式でチェックするようにできます。こうすれば、サーバーのファイルにテンポラリファイルの生成なしに、早く問題の余地なくドメインの持ち主の確認ができます。ワイルドカード証明書(4バージョン以降)にはDNSが必要な場合があります。

Windows 2016サーバーの構築

Windows Server 2016

とは言いましたが、ただ安く買っただけです。Windows Serverもかなりサービス値段を下げることができますね。(韓国の場合です)

今まではLinuxのUbuntu, CentOSなどでサーバー構築をLEMPの手順により、成功的に進んできましたが、Windows Serverはワクワクします。

これから何ができるのか、期待が高まりますね。

本物のIISはXP時代以降初めてです。

ASPなど古い遺産もありますが、Visual Studioと連携して、Springのように一貫したサイト管理がどう行われるかを重点的に見てみたいです。

python

certbotなどでpythonからのモジュールエラーが出たときのチェックリスト

Letsencypt (certbot) 設定をアップデートしてから、この前にしたUbuntuの大規模システムアップデートがあれこれ壊したことに気づいた。

実はLinuxのほとんどの部分は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はpython 3で起動するため、次のようなスクリプトになっている。

#!/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のpythonにモジュールを無意味にインストールしたり、アンインストールしたりを繰り返していたのだ。

これでは、python 3の問題は全然解決にならない。

$ 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は?

このブログでは韓国の場合を想定しています。例示や説明が日本と合わない部分にご注意ください。

Webホスティングが万能ではないこと

Webホスティングはなかなか単純なサービスです。ただ、サイトが欲しいと思ってホスティングサービスに申し込めば、安い価格でセッティングしてくれます。

例えば、韓国のホスティングサービスであるCafe24の場合には申し込み代がありますが、月に約50円くらいです。FTPで接続して、ファイルさえアップロードしたら、ホームページの出来上がりです。

この過程も省略するため、WordpressやゼロボードXE、他の掲示板ソフトもサポートしてくれるサービスが少なくありません。こういう場合、キーボードをあまり叩かなくても早速サイトの完成ですね。

ところが、そうして自慢の自己紹介サイトを作り上げたKさん…(いきなり実例の登場?)
彼はディスクの容量だけを考えて、最低プランでWebホスティングを申し込んだ後、自分のポートフォリオサイトでアップロードして、面接の履歴書をあちこちに叩き込んで、就職活動に突入しました。

ある日、就職コミュを訪れたKさん。

ある企業の担当者の共有で自分のサイトが優秀事例として書かれておりましたので、誰にも知られずに喜んでいました。
そして、それから数時間後、たった四つ目のコメントで思ってもみなかった内容を目にすることになりました。

入れませんが。

あれ?として、自分のポートフォリオのサイトを入ってみたら、迎えてくれたのはこのページでした。

Cafe24のトラフィック超過のお知らせ
Cafe24のトラフィック超過のお知らせ

あたふたプランのアップグレードのために比較してみると、なんと、価格は月に数千円ぐらいに急上昇します。トラフィックのリセットもあまり安い方法ではありません。

十分なトラフィックと余裕のあるスペース、この二つを狙うには、やはり家の中の個人サーバーでしょうか。
そしたら、電気代はどうなるんでしょうか。

VPSは少しスマートであればメリットあり

そういうKさんは知り合いからVPS1のことを聞きました。VPSというのも初めてなのに、聞いてみれば、リモートに自分のサーバーが一つできるらしいですね。

Hostingサーバーとは何が違うかとしたら、これは完全にパソコン1個ができるそうです。

月に数万円から十万円もするサーバーホスティングとは違って、これはサーバーを分けてまたサーバーにする仕組みです。

サーバーを一つのコンピューターのの中で分けられるのは、仮想化技術の進歩に秘密があります。
パソコンの中のパソコンでコマンドを別途に処理しなければならなかった過去とは違って、CPUと主な装置が最初から仮想化に備えて作られているので、性能の損失を最少2にするそうです。

サーバーを借りるのだから、価格も半端ではないと思いますが、サーバーは自分の好きなままに使えるので、場合によっては有利なところがあります。特に、基本トラフィック提供量が少なくないことが魅力です。

繰り返して説明することになりますが、最初のトラフィック容量だけでも、ほとんどのWeb Hostingサービスの最高プランに匹敵します。3

しかしVPSが全員の答えではないこと

たしかに、コストパフォーマンスがいいというのは分かるものの、だとして特に知識を持ってない人がVPSから持つことになったら、接続から戸惑うことになります。

やっと接続しても、インストール直後のUbuntu4の黒い画面は困惑そのものです。

せめて、Windowsのインストールは何度かしていて、コンピューターとソフトに関した概念がある程度ある人なら、コマンド5と関連ソフトに慣れることで熟達できるようです。(いつも忘れてしまうことがみんなの問題ですね)

 

だから、黒い画面でLAMP(Linux+Apache+MySQL/MariaDB+PHP)あるいはLEMP(Linux+nginX+MySQL/MariaDB+PHP)の構成はできなくちゃですね。もちろん、これについての講座はいろいろありますので、従うことでなかなか手軽にできます。

ただし、問題解決でまた挑戦になると思います。きっとPermisson(権限)問題がみんなを苦しめることになります。
それ以外にも、問題の原因を把握するのに苦労するとしたら、サーバーを運用しようとしてから、習うことばかりになったと苦情が増えるかもしれません。

主なサービス会社の比較

実はVPSのサービスは世の中に多くあり、下のサービスよりよくて、メジャーな会社もあるでしょう。

しかし、どこまでも自分の意見を披露するため、直接解説してみた(お金がかかった)所だけを並べました。

ConoHa

VPS Conoha
VPSならコノハ!
모에한 미유키
萌え萌え美雲このは

conoha.jp
萌えページ6

コノハは日本のGMOインターネット株式会社で運営している仮想サーバーホスティングサービスです。親企業も丈夫だとのことで、ここはなによりも無制限トラフィック7が特徴です。

グロバル営業も活発になっていて、韓国語も当然のようにホームページと管理コンソールでサポートしております。

しかし、用途以外の使用か、DDoS攻撃の的になったら、一方的にサービスが解除されるし、これを解決するにはすごく難しいと言われます。

それに、メールで日本語と英語の問い合わせもできますが、韓国人には高い壁となるのは電話での日本語ですね。

100Mbpsの回線のみ使用されていますので、少々残念なところです。でも、Pingとサーバー演算はまた回線とは別の問題です。

変にドンくさいところがあります。東京を選んでもそうです。それに、これが時間により変わってくるのが、オーバーブッキング8が疑われる部分があります。

利用金額はクレジットでチャージするか、クレジットカードをリンクできます。

サーバーをオフにしても、維持費用が同じくかかります。

ConoHa 컨트롤 패널
ConoHa コントロールパンネル
ConoHa Japan Plan
ConoHa Japan Plan

メリット

  • CPU 快適
  • 贅沢なトラフィック
  • オタク向けのデザインあり(別のメニュー)。 オタクではない人は普通のメニューが基本。

デメリット

  • 不思議な遅さ。不定の接続スピード、高いPing
  • 問い合わせ、問題の解決が難しい。親切なのに事務的な職員
  • 機能が多いようで、実は少ないウェブコンソール。APIを利用したらできることは多い方だが、入門者には向いていない
  • リモートビュー(リモート サーバー グラフィック 表示)なし。SSH不具合でもあったら接続不能。

ぶっちゃけ、オタク向けかどうかよりはスピードが大事でしょう?

Vultr

Vultr
Vultr

vultr.com

Vultrは他のVPSサービスより歴史は短い方ですが、長いアップタイムで高い信頼度を誇っています。

問題があったら、すぐに保障のクレジットをくれるし、普段から勧誘者リンクで、Paybackも可能なお得な政策を持っています。

リンクを通じて申し込むと両方割引してくれたごろもありましたが、今は特にイベントがないようです。サイトを直接見てください。

管理コンソールは簡単で、必須要素全部含んでいます。

Snapshotセーブに課金がありませんし、リミットも特に決まっておりません。サーバーのインスタンスを複製するにも使えるし、問題があったとき、Rollbackする一番容易い方法です。Snapshotの生成と適用(復元)も5分ぐらいで終わるくらいです。

10Gbpsの速い回線でサービスしているので、全世界に広まっているサーバーどこでも選んで作ればいいです。

New Jerseyでは無料でブロック ストレージを提供しています。ブロック ストレージをリンクすると追加ハードディスクを繋げたように、拡張できて、データも安全に保管できます。

東京のサーバーもありますので、ConoHaと同じく使用できます。しかし、ここも回線は速いのに、サーバーのオーバーブッキングが疑われます。回線の状態はテストサイトで直接確認できます。

利用金額はクレジットをチャージするか、クレジットカードを使えます。

サーバーをオフにしても、課金されます。

メリット

  • 楽な管理者コンソール
  • 贅沢なクレジットカード提供。ダウン時間の保障
  • Web上でサーバーグラフィックコンソールの提供
  • スナップショットの生成可能。リミット無し

デメリット

  • 我慢できるほど遅い
  • 東京地域の高い使用率、低いサーバー準備率(オーバーブッキングの予測できるAvailability Low表示)
    • 太平洋渡って、アメリカ東部のNew Jerseyと変わらない時もあるくらい

Somagu

Somagu
Somagu

somagu.com

SomaguはMudfishを運営しているミクラジネットワークスという会社を建ててから、カスタムVPSサービスを2017年始めました。

淡々なデザインと機能に比べて、NoVNCなどいろいろな方法でサーバーをコントロールできるようにしています。高性能にオプションを上げても、高い費用を要求しません。趣味でしょうかね

信頼できる韓国のISPであるKTの回線で、スピードは快適な方です。

サーバーの場所が田舎だと言われていて、運営者とも距離があるそうです。フォーラムでの問い合わせの回答は三日以上かかるのが自然です。

これにもメリットがありますが、管理UIにない機能でも、納得できるくらいなら、直接見てくれるところです。潜在なカスタマイズが必要ならば、こちらも是非使ってみることです。対応言語は韓国語と英語です。

メリット

  • コストパフォーマンスの優れているところ
  • 韓国では最適なスピード (KT網)
  • Tossでクレジットが買える

デメリット

  • 遅い問い合わせの対応
  • 不安なアップタイム、電気問題
    • 地域が田舎なため、余儀なく点検したり、あまり無誠意な電気会社の製作。
    • 一部のサーバーに問題が続いていて交換中なので、一時的にハイクラスのプランがなくなっている
  • 管理機能の不便
    • スナップショット生成無し
    • 管理コンソールではパソコンのオンオフ、リモートアクセス情報提供くらいがすべて
  • スイッチを通るのに、独立した気がしない
    • 同じ外部ポートを複数のユーザーが使えない
    • 20個に限られたポート数
    • 80 / 443はHTTP仮想ホスト方式でマップ (Webサーバーとして問題なし)
    • すべてのコネクションは10.0.0.1だと表示。訪問者の見分け不能。(X-Forwardedもない)

IwinV

IwinV
IwinV

iwinv.kr

2002年から始めて、長年発展し続けていたノーハウを持っている会社で、2014年赤字のアイビホストも引き受けるなど、積極的にビジネスの領域を広めています。VPSはiwinvというところで管理しています。

このサービスの利点は幅広いオプション、安い価格です。

メリット

  • 仮想コアー、リアルコアー、独占コアー三つの分類になっている詳細スペック
    • 仮想コアーとは、CPU Coreを仮想でまた分けたのであって、多数のユーザーに提供するための方法です。他の使用者のコアー使用率により、パフォーマンスは違います。
    • リアルコアーの使用はCPUが仮想化による性能の損失(10%以内だと言う)のみに限られ、他ユーザーに関係なく利用できます。9
    • 独占サーバーが当然もっとも高いが、他者より安い方
  • ポートの開放、リソース現状の把握などをして異常状態のお知らせができる
    • ただし、テキストは発想費用があるので、Telegramが進められます。

デメリット

  • あまりプロモーションがないこと

結論

VPSというのが安くなり、可視化されたばかりなので、なかなか情報を得ることは難しいと思います。

しかし、Linuxに前より馴染んで、大型サーバーに依存しない自分だけのセキュリティー対策を工夫するには、もう避けられない流れだと思います。

なのに、それはどこまでも自分に合うかどうかを確かめてから決めることでしょう。数人がそろって、一つのVPSに挑んでみることも柔軟な使用方だと思います。

現時点ではこのサイトはIwinVを使用しております。

yeon.me TLS

[翻訳] SSLとTLSの配布のベストプラクティス

SSL / TLS驚くほど簡単な技術です。配布しやすいし、ダメな時以外はただスムースに動作します。ただ、問題は暗号化は普通性格に配布しにくいところです。TLSが適切な保安を保証するためには、システム管理者は必ず正しいサーバー設定とアプリの配布に気を引き締めなくてはなりません。

2009年、TLSがどう使われているか、TLSツールとドキュメントをどうやって改善するかを知るために、私たちはSSL Labsで働き始めました。その結果、いくつかの目標を達成しました。TLS使用に対する世界的な統計とオンライン評価ツールを作りましたが、ドキュメントの不足はまだまだ見えています。この文書はこの問題の解決のための第一歩です。

私たちのゴールは安全なサイトとウェブアプリケーションを配布するために、管理者とプログラマーができる限り最少の時間をかけるように、明確で簡潔なマニュアルを提供することです。明確さのために、私たちは完成度を削って、そして特定のトピックも飛ばしておきます。実用的で習いやすくするのにポイントを置きました。もっと詳しい説明が必要な方には、第6章から役に立つ情報を提供します。

yeon.me TLS

続きを読む

Ubuntu 16.04 + NginXにTomcatを載せてみよう

Tomcatはその生まれながらApacheとのお揃いという気分なので、Nginxのインストールのとき、まったく考えたことがなかった。

しかし、SCITマスターでも習い続けているので、いずれにせよ講義室のパソコンをサーバーに出せないので、Nginxが起動されているこのサーバーにJSPの機能を追加することが一番自然な流れだと思う。

Cafe24という韓国のホスティングサービスでも一時はサービス中断になるほど、古い技術だが、PHPと共存することもあるらしい。

やはり、PHPのバージョン4あるいは5みたい古くなり、伝統さえ感じてしまいそうだが、こちらもレガシーとかなんとかで、バージョンを全部同時に配布している。

すでにNginxが設定済みであると仮定する。

  1. Tomcatをインストールする。
    1. # apt-get update
      # apt-get install tomcat8
  2. はいっ、ここでインストールはおしまい。
  3. 手早くhomeディレクトリから、ウェブルートに入るために、シンボリックリンクを作る。
    1. # ln -s /var/lib/tomcat8/webapps/ ~/webapps
  4. Tomcatが起動中か確かめて、起動してない場合、実行する。
    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とServletがスムースに動くのが見えたら成功だ。

CentOS 7でのNginx/PageSpeed Module + PHP-FPM7.1 + MariaDBのインストール

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のインストール

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のインストール

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のインストール

기본 시스템 설정

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のインストール

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 以外の初のLinuxに挑戦

サーバーを構築するとき、初めは手に慣れていたUbuntuでできるだろうと漠然と思っていたが、あれが思うままには素早く行かなかった。사실 말처럼 우분투는 그렇게 가볍지 않았다.

もちろん、何の問題も検索すれば出るほどのユーザー層はすごく役に立ったし、apt-getを使ったマニュアルが多くあるのも、Ubuntuのおかげであることは否めないところだが、いくつか気に入らないところがないことはなかった。

  • あまりにも多かったアップデート
    • サーバーは構築してから、継続するのが目標に等しい問題だが、サーバーのOSなのに、アップデートを圧迫する傾向がある。
  • 少なくない変数
    • ソフトウェアの多様さもいいところではあるが、Ubuntuでのセッチングは案外、手間がかかるところがあるし、問題の要因につながれるほど、方法はばらばらである。
    • たぶん、ほとんどの原因は自分の未熟さからくると思うので、あれこれ言いながらも、ただ気に入らなかったという感情的な問題ではないとは限れない。
  • aptとapt-getよりyumの方が単純で、便利
    • 一応、コマンドが短いし、分かりやすい。aptとapt-getごとく、ばらばらになってもない。

ApacheよりはNginxは回答なのか

Apacheが普通のサーバー構築に基本になっている傾向だが、Apacheは重たいし、セッチングもあまり簡単ではない。だとして、Nginxの方が軽いとは必ずしもそうとは言えないところもあるし、マルチメディアの性能では大きい違いはないそうだ。慣れているものを使うものだが、configファイルのスタイルが直感的なこともあり、FastCGIが基本として使われるNginxの方が自分にあっていると思った。

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

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

다음 글에서 이어집니다.