satakesatakeの日記

2016-03-11

Apacheで行う、特定のURLのみを除き、リバースプロキシさせる設定のレシピ

| 14:06

https://example.com/admin

だけはリバースプロキシさせずに、

https://example.com/

とか、それ以外のものはリバースプロキシさせるようなレシピ

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^/admin - [L]
  RewriteRule ^/(.*) http://example.com:5001/$1 [P,L,QSA]
  ProxyPassReverse /  http://example.com:5001/
</IfModule>

mod_rewriteのPオプションはProxyPassディレクティブと同じ機能を持つ。

…のだが、ProxyPassReverseを直後に書いてやらないとダメらしい。

参考→http://blog.livedoor.jp/techblog/archives/65151527.html

応用

それの応用で、特定のIPアドレス以外はメンテナンス画面を見せるレシピ。RewriteRule の L オプションの活用だ。

#1~3がそれぞれ、if文のブロックのような感覚。

RewriteRule は L オプションを付けると、ルールに合致した際にそこで処理を停める。それ以外は次の行に処理を移す。If文で書ければいいのになあ。

    ErrorDocument 503 /html/maintenance.html

    <IfModule mod_rewrite.c>
      RewriteEngine On

      # 1
      RewriteRule ^/admin - [L]

      # 2
      RewriteCond %{REQUEST_URI} !=/html/maintenance.html
      RewriteCond %{REMOTE_ADDR} !=192.168.0.1
      RewriteRule ^.*$ - [R=503,L]

      # 3
      RewriteRule ^/(.*) http://example.com:5001/$1 [P,L,QSA]
      ProxyPassReverse /  http://example.com:5001/
    </IfModule>

2016-03-10

SSLを取得して、中間CA証明書が2つあって混乱した話

| 14:14

はい。いつも利用しているSSL販売店から、別のところへ変えたら、なんかしらねーが前のところでは1個だった中間CA証明書が2つになってて、

ちょww意味フメーなんすけどwwww

となりました。

どうやら前までは3階層のサーバIDだったのが、4階層になったらしい。中間CA証明書の前にクロスルート証明書というのが入る形になる。

参考→https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?vproductcat=V_C_S&vdomain=VERISIGN.JP&page=content&actp=CROSSLINK&id=SO22877&locale=ja_JP&redirected=true


ルート証明書
 ┗RSAAddTrustCA.crt(*1 クロスルート証明書)
   ┗RSADomainValidationSecureServerCA.crt(*2 中間CA証明書)
     ┗サーバID(*3)

んで、買ったとこから、(*1)と(*2)のファイルと、サーバID(*3)が何の説明もなくZIPで送られてきて設定しろとかいうんですわ。いつもは中間CA証明書、一個だけだからそれをApacheの設定に↓みたいな感じで突っ込んでた。

SSLCACertificateFile /var/www/vhosts/webapp/pem/frontage/current/inca.pem

でも今度は二個だ。どうしよう。

連結する。catして一つのファイルにしちゃえばOKらしい。といっても、並びが重要で、

  1. RSAAddTrustCA.crt(*1)
  2. RSADomainValidationSecureServerCA.crt(*2)

この順番じゃないとダメだそうだ。

(*1)がクロスルート証明書発行者によっては、これを所定の場所からダウンロードせよ、という場合もあるらしい。

幸い、自分の使った発行者ZIPに全部固めてくれていた。

2016-01-05

トンネリングを使った公開鍵認証の設定方法

| 10:39

弊社が管理するサーバはどれも、hosts.allowやらiptablesなどで接続元を限定している。

そのため、ssh port forwarding(トンネリング)が必須だ。

今回、新しいサーバを設置したため、公開鍵認証のおさらいをしたい。

サーバ構成

手順

以下の手順で公開鍵認証+トンネリングを実現する。

  1. 接続元(クライアント)にキーペア(公開/秘密鍵)を作る
  2. 公開鍵をポートフォワーディング用の接続先(example.net)にコピーする
    • ここは、ssh-copy-idを使用すると楽
    • 接続先のauthorized_keysに作成した公開鍵が追加される
    • 通常の設定であれば、ここまでをクリアすれば、公開鍵認証が実現できるんじゃないかと思う
  3. 下記のコマンドでクライアントの8022ポートにポートフォワーディングするための接続を開始
    • ローカルの8022ポート経由でexample.com:22への道が開かれる
  4. 公開鍵を目標の接続先(example.com)にコピーする

ちなみに公開鍵認証の設定はそれほど難しくなく、以下の二点を抑えておけばほぼ問題ない。

  • 接続元にキーペアを作成し
  • 接続先の.ssh/authorized_keysに公開鍵をコピーする

※もちろん接続先には公開鍵認証を有効にする適切な設定が必要だ

なお、パスフレーズが必要な場合もあるが、このパスフレーズは、秘密鍵を使う際に必要なもので、ネットワークには流れない。

参考→http://guinan.ten-forward.ws/wiki/doku.php?id=handout:ssh%E3%81%AE%E5%85%AC%E9%96%8B%E9%8D%B5%E8%AA%8D%E8%A8%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E8%80%83%E3%81%88%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86

コマンド例

ここまで行うと、以下のコマンドで接続できる。

1行目は3番のポートフォワーディング用の接続だ。こいつはlocalhostの8022を開いてずーっと待っている。

2行目はexample.comへの接続。localhostの8022に接続するとexample.com通信が転送される。なお、some_account@localhostは、some_accountというアカウントで目標に接続しようとしている(ポートフォワーディングを行っているため、some_account@example.comとして読みかえるとわかりやすい)。

$ ssh -fNL 8022:example.com:22 -i ~admin/.ssh/id_rsa admin@example.net
$ ssh -p 8022 some_account@localhost

なお、ポートフォワーディング用ポートは放っておくといつまでもリッスン状態なので、手動で閉じてやる必要がある。以下でプロセスを終了させる。(この一文を覚えておくといい)

$ ps aux | awk '/[s]sh -fNL/ {print $2}' | xargs kill

どうでもいい話

キーペアは英語では、private keyとpublic key、日本語では秘密鍵と公開鍵。対義語としては問題ないと思うが、privateを秘密って訳すのもどうかなとか思ったりして。かといって私用鍵とか個人鍵ってのも変?だし。組み合わせとしては、秘密/公開よりも、private/publicのペアが好き。

"https://ja.wikipedia.org/wiki/%E9%8D%B5_(%E6%9A%97%E5%8F%B7)"

私有鍵とも言われるらしい。でもぜんぜんメジャーじゃない言い方だよな。

2015-11-16

送信時に"dh key too small"エラー

| 19:34

Thunderbird 38.3.0にて、メール送信エラーが発生した。なお、宛先にはメールは到着していない。

maillogにはこんな記録が残っていた。TLSのハンドシェイク時のdh keyがtoo smallだというエラーだ。なお、この宛先のサーバは、自分が管理しているのだが、過去1年間、業務で使われなかったため、半分放置されていた。

Nov 16 18:06:53 ns-1 sendmail[11116]: STARTTLS=client, error: connect failed=-1, SSL_error=1, errno=0, retry=-1
Nov 16 18:06:53 ns-1 sendmail[11116]: STARTTLS=client: 11116:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:2429:
Nov 16 18:06:53 ns-1 sendmail[11116]: ruleset=tls_server, arg1=SOFTWARE, relay=example.com, reject=403 4.7.0 TLS handshake failed.
Nov 16 18:06:53 ns-1 sendmail[11116]: tAG96rbm011114: to=<to@example.com>, ctladdr=<from@example.net> (625/625), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=120777, relay=example.com. [XXX.XXX.XXX.XXX], dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed.

これは先に発生した、メール受信時のエラーと同様の現象である。*1参照→http://nextstageone.g.hatena.ne.jp/satakesatake/20150724/1437725683

SMTP(-AUTH) + STARTTLSを使用して(今度は)送信した際に、送信先サーバdh key(DH PARAMETER、DHパラメータ)のビット数が低いことが原因などとは思いもよらなかった。

送信先サーバにも上記URLと同様の対策を施してやれば解決するはず。各所でこれは問題にならないのだろうか? それともうちだけ?

サーバ管理者の仕事(セキュリティ対策)と言えば、そうなので、あまり表に現れない問題なのかもしれない。

ただ、Tunderbirdの問題だとすると、宛先サーバDHパラメータ低ビット問題で、送信できない宛先がまだこの世に存在する可能性も否定できない。ちょっと嫌な感じだ。

右記も参照のこと。ただし、これは消極的な対応策である。→https://support.mozilla.org/ja/kb/thunderbird-and-logjam

アドオンの使用は長期的な解決策にはならず、サーバの問題を修正する代替にもなりません。これを使用することは、中間者攻撃の危険性がありますが、メールの利用を優先して、サーバ管理者がより安全な鍵ペア生成してサーバインストールするまでの息継ぎにはなるでしょう。

*1:エラー発生時、Thunderbird以外のメーラーでは検証していないので、他メーラーで同様のエラーが出るかどうかは不明

2015-11-05

selinuxとうまく付き合いたい

| 18:34

最近、SELinuxを停めるのは負けたような気がしているので、きちんとSELinuxを停めない運用をするように心がけている。

で、サーバyum updateして、selinuxバージョンアップされたせいなのか、kernelアップデートされたせいなのか、皆目見当がつかないが、突然、samba共有がアクセス拒否しやがるんですよ。

# setenforce 0

とかして、一時的にSELinuxをPermissiveして試すと、アクセスできる。これはなんだか、ディレクトリのコンテンツタイプというのがアップデートで更新されてしまったのかもしれない。

確認してみると、こんな感じだ。ちなみにこのディレクトリは仮名だが、httpdのドキュメントルートでもある。そのため、httpd_sys_rw_content_tが設定されている。

# ls -Z /var/share
drwxr-xr-x. share share system_u:object_r:httpd_sys_rw_content_t:s0 share

そして、SELinuxをEnfocingに戻す。

# setenforce 1

対象のディレクトリのタイプを変更する。※これは一時的な設定らしい

# chcon -t -R -t public_content_rw_t /var/share

今度は、アクセス拒否されなかった。だが、ブラウザからhttpdを通してphpの動くURLにアクセスしてみると、パーミッションエラーでログが書き込めないとか言いやがる。

おそらく、httpd_sys_rw_content_tが外されたからだ。複数のタイプを与えられればすごくうれしいんだが、やり方がわからないので、ちょっと調べてみる。