2014年02月23日

HP製サーバーのユーザは今すぐファームウェアのダウンロードを

HPがこれまでのサポート方針を変更し、今後のファームウェアアップデートは保証期間内あるいは長期サポートの契約者にのみにアクセスが制限されることになった。 HP社のFAQ

2014年1月以前に公開されたファームウェアは今のところ一般に公開されているようだが、いつまで配信が続くかは不透明だ。 PC world

Proliant ML110、ML115シリーズや、MicroServerなど、HP製の安価なサーバー製品は個人で利用している人も多いと思われるが、そのほとんど全ては延長サポートなど受けていないだろう。

セキュリティ上必要なアップデートは今後も提供されるということだが、今後公式ウェブサイトでのアップデータ一般公開が停止された場合、混乱に便乗してアップデータに偽装したウイルス・マルウェアをダウンロードさせようとするウェブサイトが現れるのは避けられない。 今のうちに公式ウェブサイトから安全なファイルをダウンロードして、手元にバックアップしておくことを強くおすすめする。

もし管理下にHP製のサーバーがあるなら、不用心な末端ユーザーが変なサイトからダウンロードしてきたアップデータもどきを実行することがないように、あらかじめ注意しておいたほうがいいかもしれない。

タグ:MicroServer
posted by ko-zu at 23:18| Comment(0) | TrackBack(0) | サーバー | このブログの読者になる | 更新情報をチェックする

2014年02月12日

SSD VPSのDigitalOceanがシンガポールリージョンを追加

VPSプロバイダのDigitalOceanがシンガポールリージョンをリリースした。

DigitalOceanは標準でSSD、snapshotに対応、時間課金なのでAnsibleのテスト環境として利用している。ストレージがSSDだとテスト時間が大部分ネットワークレイテンシなので確認してみた。

レイテンシ

国内からのtracerouteは良い時に85msくらい。 AS133165

NTT経由のときはいいけれど、telia.netに行ってしまうと西海岸経由で悲惨なことになる。経路依存なので、必要な場所から ping speedtest-sgp1.digitalocean.com してチェックしたほうが良さそう。

 7  xe-7-4.a16.tokyjp01.jp.ra.gin.ntt.net (61.213.145.93)  12.994 ms  13.205 ms  13.757 ms
 8  ae-6.r24.tokyjp05.jp.bb.gin.ntt.net (61.213.169.177)  14.429 ms  13.953 ms  13.817 ms
 9  as-0.r20.sngpsi02.sg.bb.gin.ntt.net (129.250.4.91)  76.973 ms  87.418 ms  87.652 ms
10  ae-1.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.4.143)  76.893 ms  87.259 ms  76.356 ms
11  116.51.27.150 (116.51.27.150)  101.476 ms  101.557 ms  97.790 ms
12  103.253.144.242 (103.253.144.242)  85.614 ms  94.697 ms  94.266 ms
13  *** (***)  100.764 ms  89.258 ms  88.088 ms
 5  ae-12.r24.tokyjp05.jp.bb.gin.ntt.net (129.250.5.92)  1.547 ms  1.414 ms  1.474 ms
 6  as-0.r20.sngpsi02.sg.bb.gin.ntt.net (129.250.4.91)  79.530 ms  75.088 ms  75.270 ms
 7  ae-1.r00.sngpsi02.sg.bb.gin.ntt.net (129.250.4.143)  75.647 ms  75.388 ms  75.380 ms
 8  116.51.27.150 (116.51.27.150)  229.987 ms  229.558 ms  230.153 ms
 9  103.253.144.242 (103.253.144.242)  201.196 ms  201.171 ms  201.127 ms
13  *** (***)  249.515 ms  238.729 ms  238.970 ms

逆向きを見るとteliaの西海岸経由している

 3  103.253.144.250 (103.253.144.250)  10.348 ms  10.335 ms  10.336 ms
 4  10ge-v107-mad-prov-ixn.airenetworks.es (62.115.40.169)  6.781 ms  6.716 ms  6.683 ms
 5  hnk-b2-link.telia.net (213.155.136.118)  39.762 ms hnk-b2-link.telia.net (80.91.245.149)  39.921 ms  38.904 ms
 6  las-bb1-link.telia.net (213.155.132.215)  205.099 ms  200.264 ms las-bb1-link.telia.net (213.155.136.44)  211.212 ms

帯域

今のところシンガポール国外宛が詰まっているようで、シンガポール内のサーバー相手だと十分出ている。

またサービスイン直後なせいか直近の各種リポジトリからのパッケージダウンロードが重くなっている模様。

Hosted by World's Fastest Indian (Tokyo) [5320.20 km]: 21.617 ms
Testing download speed........................................
Download: 19.77 Mbit/s
Testing upload speed..................................................
Upload: 9.12 Mbit/s
Hosted by Viewqwest Pte Ltd (Singapore) [7.42 km]: 26.385 ms
Testing download speed........................................
Download: 151.81 Mbit/s
Testing upload speed..................................................
Upload: 27.08 Mbit/s

cpuinfo

メモリ512MBのドロップレット

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 2
model name      : QEMU Virtual CPU version 1.5.0
stepping        : 3
cpu MHz         : 1999.999
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 4
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good unfair_spinlock pni vmx cx16 popcnt hypervisor lahf_lm
bogomips        : 3999.99
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:
タグ:VPS
posted by ko-zu at 23:07| Comment(0) | TrackBack(0) | サーバー | このブログの読者になる | 更新情報をチェックする

2013年11月26日

OpenVZゲストでNative IPv6とIPv6トンネルのデュアルルートを作る

DTIのserversman VPSをx86_64化してIPv6がいくらか動くようになったのでOpenVPNサーバーにしてみた。

前提

  • OpenVZのVPSゲスト、CentOS6.x + OpenVPN 2.3.x
  • dev venet0:0 にNative IPv6が1つ(/128)だけ割り当て済み。可能ならこのルートを使う。
  • He.netのIPv6トンネルから/64の割り当てを受けてOpenVPNのクライアントへ割り当てる。
  • dev tun0 をOpenVPN tun-ipv6 で作成
  • dev tb をユーザースペーストンネル tb_tun で作成。

トンネルとルートの作成

まずOpenVZ上ではカーネルもジュールを導入できないので、sitトンネルを使えない。 トンネルパケットをユーザースペースで処理するtb_tunがあるのでサービスとして起動する。 http://code.google.com/p/tb-tun/

setsid tb_userspace tb {{tunnel_server}} any sit > /var/log/tunnel.log 2>&1 &

tbにIPv6アドレスを割り当て。

ifconfig tb up
ifconfig tb inet6 add {{tunnel_client_ipv6}}

venetをデフォルトにするためmetricを増やして追加しておく。

ip -f inet6 route add default metric 10 dev tb

他のOpenVZマネージャ(SolusVM)ではIPv6割り当てが無いのにデフォルトルートが設定されている。その場合削除しておく。

ip -f inet6 route del default metric 1 dev venet0

iptablesで-p 41のINPUT/OUTPUTを通しておく事を忘れずに。

iptables -A INPUT -p 41 -s {{tunnel_server}} -j ACCEPT

ここまででトンネルIPv6は到達可能になった。

トンネル-VPN間のルーティング

IPv6ルーティングを有効化

net.ipv6.conf.all.forwarding = 1

He.netを経由させるRoutedなソース範囲に対してルール付きのテーブルを作成、デフォルトルートに指定

ip -f inet6 rule add src {{tunnel_routed}} table 10
ip -f inet6 route add default metric 1 dev tb table 10

ip6tablesのFORWARDを許可

ip6tables -A FORWARD -i tun0 -s {{tunnel_routed}} -j ACCEPT
ip6tables -A FORWARD -i tb   -d {{tunnel_routed}} -j ACCEPT

ServersMan@VPSはopenvzカーネルが古すぎてip6tablesのconntrackが機能していない。 常用するならもっとまともなフィルタルールが必要。

OpenVPN側

routedなIPv6を割り当てる。クライアントにはデフォルトルートとしてpushする。

server-ipv6 {{tunnel_routed}}
push "route-ipv6 ::/0"

残念ながら、openvpn 2.3.6ではまだIPv6 DNSサーバーアドレスをpushすることができない。 そのためAAAA filteringされていないHe.net提供のIPv4 DNSサーバーを指定するか、クライアント側で上書きしてもらう必要がある。

ひとまずこれでnativeのIPv6を生かしたままIPv6 over OpenVPNが出来た。

タグ:VPN IPv6 VPS OpenVZ
posted by ko-zu at 20:02| Comment(0) | TrackBack(0) | サーバー | このブログの読者になる | 更新情報をチェックする

2013年11月20日

Ansibleのtemplateにカスタムフィルタを追加する方法

Ansibleのtemplateモジュールではjinja2が使われているため、カスタムフィルタを登録して好きな処理を書ける。

templateはplaybookのパース時にも使われるので、Ansibleロード時点でグローバルなプラグインとして導入する必要がある。今のところロードするフィルタの切り替えはansible.cfgで切り替えるしか無いようだ。 (ドキュメントには ./libraryに置くことでロードできるらしいのだがcfgで上書きされているっぽい)

フィルタの登録はFilterModule().filters()が返す辞書。

import socket
class FilterModule(object):
    def filters(self):
        return {"A": socket.gethostbyname}

このファイルを適当な名前でfilter_pluginsフォルダに置くとansibleロード中に読み込まれる。

実際のパス指定はansible.cfgの

filter_plugins     = /usr/share/ansible_plugins/filter_plugins

参照: https://github.com/ansible/ansible-examples/blob/master/language_features/filter_plugins/custom_plugins.py

タグ:Ansible
posted by ko-zu at 20:26| Comment(0) | TrackBack(0) | サーバー | このブログの読者になる | 更新情報をチェックする

2013年10月19日

CentOS6.4+NginxでECDHEを有効にしてForward Secrecy取得までのメモ

昨日は鍵共有を甘く見て爆死したためCentOS+NginxのサーバーをWindows環境に対応させてみる。

RPMに慣れていた都合上、主なサーバーにCentOS6を使っている。 CentOS/RHEL6.4では2013年10月時点で、標準のOpenSSLは1.0.0、Nginxは1.0系が導入される。Nginxには公式リポジトリもあるが、openssl-1.0.0を前提にビルドされている。

これらはコミュニティサポートのあるRPMで提供されているものの、NginxでHTTPSサーバーを建てようとすると、TLSはv1.0 まで、対応cipherはDHE-RSA-AES-SHAまでになり、QualsysのSSLテストでは色々と指摘される。

問題点

既存のパッケージで対策不能なのは、TLS1.2対応(兼BEAST対策)とRSA鍵共有。

BEASTは未対策のブラウザがTLSv1.0以前のCBCモードで通信する場合に発生しうる。一時的な対策としてストリーム暗号のRC4が使われているが、TLSv1.2ではCBCモードの問題が解消されているためTLSv1.2で導入された暗号モードを使えば問題は無い。しかし、TLSv1.2はopenssl-1.0.0には入っていない。

将来解読される可能性がある(RSA)鍵共有を使わない、というForward Secrecyは各所で既に行われている。RSA鍵共有に替わるものとして、多くのブラウザはDH鍵共有・ECDH鍵共有が実装されている。 CentOSのopensslでも有効なDH鍵共有を利用できればいいのだが、クライアント側、例えばWindows+IE環境ではDHE-RSAが無いためにRSA鍵共有が優先され、Forward Secrecyを保証できないことをご指摘頂いた。(Win7+IEでブラウザのCipherテストみるとDHE-DSSは実装されているのにDHE-RSAが無い)

Windows+IEに対応するためには、ECDH鍵共有を有効にする必要がある。Googleなど多くのサービスは既にECDHE-RSAを有効にしている。

ビルド手順

TLSv1.2と、多くのブラウザでRSA鍵共有以外を使おうとすると、OpenSSLとNginxをリビルドする必要があった。

システムのopensslをいじるのでVMなどのビルド用サンドボックス環境で要検証。

まず、1.0.1のopenssl-develをビルド環境にインストールする。 CentOS6でのopenssl-1.0.1e のビルド手順は http://www.ptudor.net/linux/openssl/ がとても詳しいのでそのまま。 生成されたRPMをインストールしてopenssl version が1.0.1eになり、openssl cipher -v 'HIGH' でKx=ECDHが含まれるかチェックしておく。

Nginxはmainline 1.5.6のSRPMをリビルド。自動インストールするのであれば、nginx.specファイルでRequires: openssl >= 1.0.1e のバージョンを指定しておく。 出来たバイナリはopenssl-1.0.1eのcipherに対応しているはず。 例えば

  ssl_protocol TLSv1.2;
  ssl_ecdh_curve secp384r1;
  ssl_ciphers EECDH+aRSA+AESGCM;

が通るか確認。

実際のciphers指定

次のように明示しておく。

    ssl on;
    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    # RC4無し
    ssl_ciphers EECDH+HIGH:EDH+HIGH:HIGH:+3DES:!RC4:!MD5:!aNULL:!eNULL:!LOW:!EXP:!PSK:!SRP:!DSS:!KRB5;
    # RC4有り
    # ssl_ciphers EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH+RC4:EECDH+HIGH:EDH+AESGCM:EDH+SHA384:EDH+SHA256:EDH+RC4:EDH+HIGH:AESGCM:SHA384:SHA256:RC4:HIGH:+3DES:!MD5:!aNULL:!eNULL:!LOW:!EXP:!PSK:!SRP:!DSS:!KRB5;
    ssl_ecdh_curve prime256v1;
    ssl_dhparam /path/to/dhparam2048.pem;
    ssl_certificate /path/to/server.crt
    ssl_certificate_key /path/to/private.key
  • ECDHE>DHE>RSAを明示する。OpenSSLのデフォルトのソートは、ソート順がEnc→KxなのでKxが交互に並んでしまう。
  • 将来証明書がRSAからECDSAに切り替わった時のために、grep Au=RSA、grep Au=ECDSAで順序が変わらように並べる。
  • GCM>SHA-2>RC4>SHA-1なのは、SHA-2未対応のクライアントはTLSv1.0である可能性があり、BEAST対策なされていないかもしれないから。
  • MD5はSSL3.0ならSHA-1必須なので抜く。
  • RC4をそのまま抜くとWinXP+IEで接続できなくなるので、cipherの最後に+3DESを追加する。
  • EC関数のsecp384r1は互換性から減点される模様
  • ECDHは256bit以上、DHは2048bit以上が推奨されている。Nginxのデフォルトは1.5.6でもDH1024bitのままだった。
  • !aNULL以降は表示されるcipher削減のため。利用するクライアントは存在しないかそれ自体脆弱と考えていい
  • 性能上の問題は無視している。

これでほぼ全てのブラウザで対応できたはず。

Forward Secrecy     Yes (with most browsers)   ROBUST (more info)

レポジトリ?

他人のビルドしたopensslを試す無謀な方は

http://yumrepo.usb0.net/GPG-KEY
pub   4096R/848C083D 2013-11-17
      指紋 = D11E 88FF 3FC0 4339 EE1D  BBA4 4F1E A7EE 848C 083D
uid                  causeless (myrepo sign key) <causeless@gmail.com>
[myrepo]
gpgcheck = 1
enabled = 0
name = My Repo - $basearch
baseurl = http://yumrepo.usb0.net/RPMS/$basearch/
[myrepo-noarch]
gpgcheck = 1
enabled = 0
name = My Repo - noarch
baseurl = http://yumrepo.usb0.net/RPMS/noarch/
[myrepo-source]
gpgcheck = 1
enabled = 0
name = My Repo - noarch
baseurl = http://yumrepo.usb0.net/RPMS/source/
タグ:CentOS nginx ssl
posted by ko-zu at 19:11| Comment(0) | TrackBack(0) | サーバー | このブログの読者になる | 更新情報をチェックする

2013年09月17日

NginxのSSL設定メモ(obsolute)

このssl_ciphersだとWindows+IEでRSA鍵共有が優先されてしまう問題が有ったのでobsolute

 

理由が記載されていない設定例しか見当たらなかったのでメモしておく。2013/9時点の理解。 Apacheでも名前の読替えで全て同じ設定が可能。

    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers AESGCM:SHA384:SHA256:@STRENGTH:RC4:HIGH:!EXP:!LOW:!MD5:!aNULL:!eNULL:!KRB5:!PSK:!SRP;
    ssl_prefer_server_ciphers on;
    ssl_stapling on;
    add_header Strict-Transport-Security max-age=31536000;
ssl_ciphers
  • RC4 > CBC (BEASTの方が重大と考える)なら、上記の通り。
  • CBC > RC4 (RC4の危殆化が重大と考える)なら
      ssl_ciphers HIGH:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PSK:!SRP;
  • クライアントの構成から、SSLv3とRC4を無効にできるなら、
      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PSK:!SRP;

ciphersの記述を細分すると、

AESGCM:SHA384:SHA256:@STRENGTH

TLSv1.2以降で導入された方式をMACでリストアップして、暗号強度順に並べている。これらに対応しているクライアントはTLSv1.2で接続しているはず。デフォルト有効ではないものの、メジャーブラウザは実装済み。 なお、

TLSv1.2:!eNULL

でも同じ結果になるはずだが、1.0.1eより前ではTLSv1.2という一括指定は使えないようだ。

RC4:HIGH:!EXP:!LOW

BEAST未対策かつTLSv1.2非対応の古いブラウザ向けにRC4-128bitを優先する。米国輸出規制対応の弱いRC4は!EXPで排除される。(64bitのRC4が実装された時のために!LOWをいれておく) RC4が無効化されていればそれ以外に128bit以上の暗号を使う。

!MD5

今のところ弱衝突はでていないが、MD5が必須なのはSSLv2以下のブラウザだけなので無効にして構わない。SHA1に非対応のブラウザは流石に無いと考えていい。

!aNULL:!eNULL:!KRB5:!PSK:!SRP

署名なし、暗号化なしは無効。また古い形式と事前共有など。使われることは無いだろうが ssl_prefer_server_ciphers on なので念のため無効にしておく

これらのルールは

    openssl ciphers -v 'ciphersuites'

で利用される順序が確認できる。

ssl_session_cache

トラフィックが少ないのでワーカー毎キャッシュを無効にして、全て共有。

ssl_stapling

OCSP応答をサーバー側にキャッシュする。最初のセッション確立までの遅延を減らせる。nginxの場合、resolverを明示的に設定が必要

Strict-Transport-Security

同じくトラフィックが少ないのでブラウザにSSLの利用を強制する。

タグ:Beast ssl nginx
posted by ko-zu at 19:45| Comment(0) | TrackBack(0) | サーバー | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。