カテゴリーアーカイブ インフラ

takahashi 著者:takahashi

Postfixでメールサーバー間暗号化を有効化する方法

メールソフトの送信サーバー設定で、SSLやSTARTTLSなどでメールソフトとサーバー間の通信を暗号化できることはご存知の方も多いかと思います。

実は、メールソフト⇔サーバー間だけでなく、サーバー同士の暗号化も行えることはご存知でしょうか。

これをやっておかないと、折角メールソフトからサーバーまでの間が暗号化できていても、自分側のメールサーバーから送付先のメールサーバーまでの間が平文になってしまい、だれでも覗ける状態になってしまいます…

今回はPostfixでのサーバー間暗号化通信を有効化する方法をご紹介します。

postfixの設定ファイル

sudo vi /etc/postfix/main.cf

に次の一行を追記します。

smtp_tls_security_level = may 

これだけでOKです。
あとはメールサーバーを再起動すれば適用されます。

この指定を行っておくことで、相手のメールサーバーがTLS通信に対応しているときに自動で暗号化接続を行ってくれます。

ちなみに

smtp_tls_security_level = encrypt

という指定もありますが、このようにしてしまうとTLSに対応していないメールサーバーとは通信できなくなってしまうので注意してください。

設定自体は超簡単なので、自分でSMTPサーバーを持っている方は是非設定してみてください。

Postfixのメールサーバ間通信でTLSを有効にする – Qiita

  • この記事いいね! (0)
takahashi 著者:takahashi

Apacheでは1つのpemファイルに中間証明書をまとめてあっても別で中間証明書を指定する必要がある件

最近新しいサーバーをセットアップし、その上でApacheをセットアップし、新しいサイトを構築しました。

そのサイトへはPCやスマホのWebブラウザからは問題なく閲覧できていたのですが、何故かアプリのWebviewからアクセスできないという問題が発生していることが判明。

具体的には、Webview側でサイトへアクセスしようとするとステータスが”Cancelled”になる、というもの。

いろいろ調べたところ、どうやら平文では問題なく閲覧できてはいるものの、SSL(https)経由になると何故か正常に見ることができないことがわかりました。

そこで、SSL通信のチェックサービスを使って、SSLの状態を調べてみました。

SSLチェック【証明書・プロトコル・暗号スイート確認】 – cman

結果、証明書の認証チェーンに問題があることがわかりました。

ApacheではSSLの証明書の指定を行う際、下記のように書きます。

SSLCertificateFile /etc/letsencrypt/live/example.jp/fullchain.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.jp/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.jp/privkey.pem

今回構築したサーバーではSSL証明書にLet’s Encryptを使用しており、Apacheに入れる設定としては上記のようになります。

fullchain.pemについては1ファイルに証明書本体と中間証明書も含まれているのですが、Apacheではそのようには認識してくれず、中間証明書は別で指定する必要があります。

その中間証明書の指定が2行目の SSLCertificateChainFile の記述になります。

今回の場合、2行目のSSLCertificateChainFile が抜けていたことで証明書のチェーンが壊れてしまっていたのが原因だったのですが、PCやスマホのブラウザで見るとOSがチェーンを補完して問題なく見れてしまうため、アプリでつなげようとしてようやくエラーに気付いた形でした。

SSLを使うサイトを立ち上げた際は、ブラウザでのチェックだけでなく、ご紹介したSSLチェックツールなどでもテストしておいた方が確実かもしれません。

  • この記事いいね! (0)
takahashi 著者:takahashi

確かにSIMフリーのAndroid端末でも防災速報が受信できた話

先日の大雨は久々に不安を感じるレベルでした。

側溝から水が噴水のようにあふれていたり、道路に水が冠水してしまっていたり、極めつけは普段名前の聞かないような川の周辺まで警報が出て、ちょっと恐怖を感じました。

冠水こそありましたが、川の氾濫という最悪の自体がギリギリ回避できて、ほっとしました。

ところで、先日SIMフリーのAndroid端末でも、Android8.1から標準で緊急速報が受信できるようになったという話をご紹介しました。

こちらの記事ではIIJ社が行った実験による緊急速報の受信の様子をご紹介しましたが、実際に今回の増水による避難勧告発令時に、自分が所有するPixel 3a(Android 9)でも実際に緊急速報を受信することができました。

実際にはこのような画面になりました。

前回ご紹介したIIJ社の実験の通り、最初に内容のない緊急速報を受信し、そのすぐ後に詳細な内容を受信しました。

以前使っていたXperia Z5(Softbank版 Android 6)では警報を受信しても専用の通知音がなるだけでしたが、Pixel 3aの場合は通知音が流れた後、内蔵の読み上げエンジンで全文が音声で読み上げられるようになっていました。

これはロック画面を解除していない状態でも行われ、スマホを開くことなく警報内容を確認することができるので、安心できます。

この機能はAndroid 8.1以降のAndroidには標準で含まれているため、SIMフリーであってもモバイル回線に接続されていればメーカーやキャリア側で意図的に無効化されない限りは8.1以降のすべてのAndroidで受信できそうです。

いままで、こういった重要な機能が搭載されていないといった理由でSIMフリー版のスマホを購入がちょっと心配になるパターンもあったのですが、今後はそういった縛りを受けることなく機種を選ぶことができそうなのはとてもありがたいですね。

  • この記事いいね! (0)
takahashi 著者:takahashi

突然MyDNS+Let’s Encryptでの証明書取得が不能に。原因はIPv6経由のアクセス。

たまたま自宅のサーバーのSSL証明を確認したら、Let’sEncryptで取得しているSSL証明書の有効期限が1か月を切っていました。

1か月に1回強制更新するように設定してあったのでおかしいなぁと思いつつ調べたところ、どういうわけか自宅サーバーからDNSサーバーへの接続がうまく行かなくなっていました。

自宅のサーバーではLet’s Encryptからワイルドカード証明書を取得しており、その際ドメインを管理しているDDNSのMyDNSと連動させることで自動で取得できるようにしています。
(詳細はこちらの記事をご覧ください。)

サーバーが接続しているインターネット回線はIPv6に対応しているため、SSL証明書を取得する際の接続先としてスクリプトで指定している”www.mydns.jp”への接続もIPv6で接続されるのですが、何故かMyDNSのIPv6アドレスに通信が到達できない状態になっていたのが原因でした。

他にもMyDNSに限らずサーバーからあらゆるドメインへのIPv6アドレス経由での接続ができなくなっているようだったので、どうやら自宅側のIPv6ネットワークがおかしくなってしまっているようでした。

とりあえず、接続先の指定をipv4.mydns.jpに変更してIPv4に固定したところ、問題なく通信できるようになったので、当分はこれでしのげそうです。

何故突然IPv6での接続ができなくなってしまったのかはまだ分かっていないのですが、まだまだ不安定なところがあるのかもしれませんね…

  • この記事いいね! (0)
takahashi 著者:takahashi

[備忘録]dockerインストール手順(CentOS7)

参考:CentOS7にDockerをインストールする – Qiita
Docker Composeのインストール方法(CentOS7.3) – Qiita
CentOS7 に pip と awscli をインストール -set setting reset

#docker-ce
sudo yum remove docker docker-common docker-selinux docker-engine
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum makecache fast
yum list docker-ce.x86_64 --showduplicates | sort -r
sudo yum install docker-ce-17.06.0.ce-1.el7.centos
sudo yum install docker-ce
sudo systemctl start docker
sudo systemctl enable docker
sudo docker run hello-world #動作テスト

#docker-compose
sudo yum install epel-release
sudo yum install python-pip
pip install docker-compose

殆ど上記のコマンドをそのまま実行するだけで最低限のセットアップはできました。

すんなり入ってくれたのでうれしいですね。

#Core OSも試してみたのですが仮想マシン上でのブートでコてたので、こっちの方が簡単かもですね…

  • この記事いいね! (0)
著者:ym

やっぱり VMware 。VMware と Hyper-V 切り替え

昔ながらの BIOS マシンを使用しているので、以下のコマンドで切り替えられます。

VMware を使いたい場合

bcdedit /set hypervisorlaunchtype off
その後 OS 再起動


Hyper-V を使いたい場合

bcdedit /set hypervisorlaunchtype auto
その後 OS 再起動

HDD マシンだから再起動したら 30 分以上かかる。どうにかならんのか、これ。

  • この記事いいね! (0)
takahashi 著者:takahashi

PHPでMS SQL ServerをCygwinで使うべきではない理由

何故なら、公式のMSSQLドライバがCygwin用に提供されていないからです。

GitHubのMicrosoftの公式リポジトリでも、Cygwinはサポートしないとはっきりと明言されています。

Driver in cygwin enviroment #258 – GitHub

Transact SQL クライアントのオープンソースの実装であるFreeTDSについてはCygwinにもドライバがあるので、これを使えば”とりあえずは”Cygwin上のPHPからSQL Serverへ接続することはできます。

しかしFreeTDSではSQL文実行後一定時間経過しても結果が返ってこない場合、接続を切ってしまううえ、この仕様を修正するにはFreeTDSのソースを修正するしかない、という状況になっているようです。(調べて見つけた記事にそのようなことが書かれていたのですが、その記事のURLを見失ってしまいました…また見つけたら追記します。)

代替えとして、Windowsネイティブでありながら、基本的なLAMP環境を簡単に動作させることができるXAMPPというパッケージがあります

XAMPP

こちらなら、SQL Serverの公式PHPドライバが利用可能ですので、 個人的にはこちらを利用するのがおすすめです。

本当はUNIXライクなOSで動作させるのが一番なのですが、もしWindowsでどうしても…という方は一度検討してみてください。

  • この記事いいね! (0)
takahashi 著者:takahashi

MySQL 5.7で厳格になったパスワードポリシーを解除する方法

MySQLは5.7からrootパスワードがデフォルトで設定されていたりと、なにかと面倒な仕様変更が多いのですが、その流れで今回困ったことがあったのでご紹介したいと思います。

とりあえず、開発用のテスト環境としてセットアップをしたサーバーにMySQL5.7をセットアップし、エディタからSQLサーバーへアクセスできるようにするために、いつも通り外部からのアクセスが可能なユーザーを作成しようとしたのですが…

-- 実際にはもっと予想されにくい認証情報を指定しています。
GRANT ALL PRIVILEGES ON DBNAME.* TO user@'%' IDENTIFIED BY 'PASSWD123' WITH GRANT OPTION;
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

…はいでました、ポリシー違反(汗
MySQL5.6あたりまでは平気で設定できていたパスワードも、ものによっては5.7以降になると単純すぎるとはじかれます。

本番環境であれば十分に複雑で、かつ大文字や記号が入っているパスワードがベストなのはわかっていますが、開発中は手動で何度も接続しないといけない場合があるため、複雑なパスワードにしてしまうとちょっと困ります。(もちろんオフィス以外から接続できないようにするなどの別の対策はとってます。)

なんとか緩いパスワードを設定したいと探したところ、SQL上でパスワードポリシーを変更する方法を見つけました。

mysql5.7でパスワードを変更する – Qiita

MySQLのシェルに入った状態で、次のSQL文を入力します。

-- パスワードの最低文字数を4文字に変更
SET GLOBAL validate_password_length=4;
-- 要求するポリシーレベルを"LOW"に変更
SET GLOBAL validate_password_policy=LOW;

これで再度

GRANT ALL PRIVILEGES ON DBNAME.* TO user@'%' IDENTIFIED BY 'PASSWD123' WITH GRANT OPTION;

を実行してみると…

Query OK, 0 rows affected (0.00 sec)

無事成功しました。

MySQL 5.7から結構あちこち変更されているので、今までのノリで触っていると戸惑ってしまうような変更が結構ありますが、その仕様変更に当たっても、焦らずに一つ一つ解決していきたいですね。

  • この記事いいね! (0)
著者:ym

ロボットと人

Web サイトに対して突然大量のリクエストを投げつけてくるボット。検索エンジンのクローラ系もありますが、全く関係の無いボットもあります。

プロセスで CGI 特定したり、netstat -anl 結果から攻撃元を特定、 さらにはアクセスログと格闘していましたが、今更ですが今回は Apache の server-status 表示を”プログラム”で取得し、集計して判断をするようにしました。 これであれば、リクエスト URI や、常にポートを専有しているかの判断ができそう。

この Status モジュールによりサーバ管理者はサーバがどのくらい の性能で動作しているかを知ることができるようになります。 現時点でのサーバの統計情報を読みやすい形式で表した HTML ページが 表示されます。必要であれば、このページは自動的にリフレッシュさせる こともできます (互換性のあるブラウザを使用している場合)。 別に、現時点でのサーバの状態を単純な機械読み取り可能なリストで 表すページもあります。

https://httpd.apache.org/docs/2.4/ja/mod/mod_status.html

  • この記事いいね! (0)
takahashi 著者:takahashi

LaravelをNginxで動作させる際の設定

LaravelではどのURLを指定されても、(自分の担当するパス配下へのリクエストであれば)Laravel自身を起動させるために必ずpublic/index.phpを経由させる必要があります。

この設定はPHPだけでは限界があるため、Webサーバー側の設定で対応する必要があります。

Laravelのパッケージにはこの”index.phpを必ず経由させる”という設定が書かれた設定ファイルがデフォルトで含まれています。
具体的には

public/.htaccess

上記のファイルがこの設定ファイルにあたります。
ところが、この.htaccessファイルは基本的にApacheなどのごく一部のWebサーバーでしか認識しないので、たとえは先日の記事のようにnginxにPHPをインストールした環境で動作させようとしても、そのままではうまく動いてくれません。

この場合、.htaccessに書かれている設定と同様の働きになる設定をWebサーバーの設定ファイルに指定する必要が出てきます。
ただし、その記述の仕方もApacheとは異なってきますので、各Webサーバー用の書き方に書き換えないといけません。

nginxの場合、.htaccessの中身をnginx用の設定に書き換えてくれるWebサービスがあり、まず最初にこのサービスを使って変換した設定ファイルを使って設定を行ってみました。

元の.htaccess

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

上記サイトで変換後のnginxコンフィグ

# nginx configuration

location / {
  if (!-e $request_filename){
    rewrite ^(.*)$ /%1 redirect;
  }
  if (!-e $request_filename){
    rewrite ^(.*)$ /index.php break;
  }
}

実際に入れ込むと以下のようになります。

server {

  listen        80;
  listen        443 ssl;

  server_name  example.com;

  ssl_certificate       /path/to/ssl/fullchain.pem;
  ssl_certificate_key   /path/to/ssl/privkey.pem;

  root /path/to/docroot;
  client_max_body_size 1g;
  location / {
        if (!-e $request_filename){
                rewrite ^(.*)$ /%1 redirect;
        }
        if (!-e $request_filename){
                rewrite ^(.*)$ /index.php break;
        }      
        index index.php index.htm index.html;
  }
  location ~ \.php$ {
    if (!-e $request_filename){
        rewrite ^(.*)$ /%1 redirect;
    }
    if (!-e $request_filename){
        rewrite ^(.*)$ /index.php break;
    }
    fastcgi_pass   unix:/var/run/php-fpm.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;
    allow all;
  }
}

ところが、上記のような設定を行ったところ、リダイレクトループに陥ってしまいます。

いろいろ調べたところ、Nginx向けのLaravel用の設定が公開されていました。

nginxをLaravel5.4用に設定する – Qiita

上記の記事を基に今回の場合の設定ファイルを書き換えてみます。

server{
   listen        80;
   listen        443 ssl;

   server_name  example.com;

   ssl_certificate       /path/to/ssl/fullchain.pem;
   ssl_certificate_key   /path/to/ssl/privkey.pem;

   root /path/to/docroot;

   location / {     
        index  index.php index.html index.htm;
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass   unix:/var/run/php-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

全然違うじゃん…

やはり、ただ設定を変換しただけではうまく行かないみたいですね。

参考元の記事ではLaravel5.4となっていましたが、5.6の環境でも同様の設定で問題なく動作しました。

Laravel + Nginxの構築でお困りの方の参考になれば幸いです。

  • この記事いいね! (0)