DigiLoog

続きを読む »

Heartbleedは、暗号化されている為に安全と言われていたSSL/TLS通信を使っているにもかかわらず、
暗号化された内容を第三者が不正閲覧出来るかもしれないという物だった。
この脆弱性がここまで有名になったのは、攻撃難易度としては結構高いとは言え、

1. 暗号化通信の基幹部分を崩す脆弱性
2. 攻撃された側は攻撃を感知出来ない
3. 応用すればサーバ情報を引き出す事も出来る

という、基幹を揺さぶって世界(のシステム管理者)を震撼させる物だった為。
普段、PCの事は取り扱わないNHKがニュースとして取り上げたレベルなのでお察し下さい

最終的にはVPN系のアプライアンス製品にも飛び火して、対応を迫られたエンジニアも多かった筈。
自分の場合、自鯖のオレオレ証明書絡みと、インターネット側のサーバとSSLセッションを張るシステムの
全部に対応する必要があって大変だった(´・ω・｀)

………

Shellshockは特にヤバかった。"ns-lab BB"にShellshockを悪用したHTTP GETが来るレベルで。
"ns-lab BB"にShellshockをやられた時には、FWとBash自体で対策済みだった為、問題無かった。

こっちは、誰でも簡単にOSコマンドインジェクションが可能という点で、サーバ管理者を震え上がらせた。
攻撃難易度は、標的を決めてtelnetコマンドを3行程打ち込んだだけで再現が出来てしまうという超お手軽性。
その為apache上でPHP・CGI・perl辺りを動かしている環境下では特に危険だった。
ちなみに、先のHeartbleedと組み合わせる事で、OSを丸裸に出来る点もヒヤヒヤ要因の一つ。

そして、GNU BashはMAC-OSから始まり、家庭用ルータ・業務用アプライアンス、さらにはメインフレームにも
デフォルトインストールされている点も被害を広げた。
Linuxをインストールした時のデフォルトシェルがbashになっている事が多いのも(ry

ちなみに、"ns-lab BB"のシェルはOSディストリ毎に変更している為、
bash/ksh/tcsh/zshとチャンポン状態だが、自作シェルスクリプト互換性の為にbashだけは全部に入れていた。
脆弱性情報出たら即アップデートかけたが、仮想サーバ含めると台数が多いので大変だった(´・ω:;.:…

………

いろんな脆弱性が出て毎月「(>'A`)>ｳﾜｧｧ!!」と頭を抱えていた2014年。
本来なら脆弱性の無い事が最高なのだが、人が作るプログラムなので100%脆弱は潜んでいるわけで…
脆弱性情報が出ないで痛い目見るよりは、明るみに出る事で修正される方が良いのは当たり前。

来年こそは、基幹レベルでヤバい脆弱性に追われない事を祈るのみ。

« 続きを隠す

続きを読む »

文章だと非常にわかりずらいので、またもやトポロジ図の出番。

1. サーバがInternetとLANに見せているドメインは同じ
2. VPNクライアント側はSplitTunnelingを使って、InternetとVPN網の両方に接続可能
3. androidからserverへ名前解決を行って"www.hoge.org"プライベートIPのAレコードが取れれば理想

この状態でandroidからserverに問い合わせを行うと、
グローバルIP(202.212.xxx.aaa)が返答されてしまい、
"www.hoge.org"のAレコードを引っ張る事が出来なかった。まぁ、当たり前って言えば当たり前なのだが

………

この辺りの対処方法は色々とやり方があるのだが、今回は優先DNSを設定する方法で対処。
しかし、PCではLANの名前解決が出来るのにandroidのWebブラウザから
"www.hoge.org"にアクセスしようとすると何故か202.212.xxx.aaaが返答され、
LAN内のAレコードが引けない状態となった。
しかし、androidから直接nslookupやったりdigったりすると、ちゃんとLAN内のAレコードが引ける状態…

この辺りで「Webブラウザ(Firefox)が臭うな…」と思ってchromeに変更してアクセスしてみると、
"www.hoge.org"がちゃんと表示出来た。

………

という事で、Webブラウザが見るDNSリゾルバがなんかおかしいという事がわかったので、
適当なWebブラウザの挙動を調べてみた。間違っていたらゴメンナサイ

• chrome → 優先DNSあればそっちも見る。
• Firefox → androidのネットワーク項目に設定したDNSサーバだけを見る。
• dolphin → 優先DNSがあればそっちも見る。

なんとも微妙な結果だが、今回の結末はWebブラウザの挙動で変化するという内容だった。

今回の事から
「DNSのTTLを長くしておくと、それに起因しての隠れた障害も起こりうるんだなぁ～」
と実感した昨晩。

DNSは軽視されがちだけど、一度障害が起きると全滅するから特に気をつけておきたい所。
…たとえソフトウェア側に問題があったとしても(´；ω；｀)

« 続きを隠す

続きを読む »

構築方法メモ

• Corosync
• Pacemaker
• ResourceAgents
• Cluster Glue
• crmsh
• HAProxy
• Squid

今回はメールシステムを組んだ時以来の難航作業だった(´・ω:;.:…
というのも、何処を探してもPacemaker+HeartBeatの構成は見つかるのだが、
具体的なPacemaker+Corosyncの構成が見つからなかった。

なんでCorosyncに拘ったのかと言うと、今回の構築ディストリがCentOS7であり、
yumで突っ込めるのがPacemaker+Corosyncだった為。
「yumでバイナリが用意されている = ソースから入れる事も可能」という安直な発想から突撃をしてみた。
その結果、1からドキュメントを読み直し、ソースをビルドし、ミドルウェアを連携させ、
コンフィグとinit(systemd)も自作するという果てしない道のりを歩んでしまった。

一番大変だったのは、Corosyncのビルド。はい。初っぱなから躓きました…
自分はソースビルドを行う時はprefix指定を行い、その中に全部突っ込むやり方をよくやるのだが、
Corosync+Pacemakerの場合は一部インストールディレクトリを変更してやる必要があった。
また、今回使うミドルウェア群はローレベルで読み込ませる必要もある為、
バイナリも"/usr/sbin"から拾える状態にする必要があったりと、
今までに自分の経験した事の無い構築手法をやる必要が出てきてしまった。

結果としては、prefix指定を行いながらも"/usr/sbin"からシンボリックリンクを張る方向で
なんとか落ち着かせる事ができ、バージョン管理(切り戻しなど)も行える構成に持って行けた。

………

冗長構成を組む際、本来ならインターリンクを使って本気で作ってやる必要があるのだが、
今回はNICが物理的に足りなかったり、単純な負荷分散装置としてProxy以外でも使いたかった為、
敢えて1物理鯖1NIC構成で構築を行った。結果として、これがまた面倒な事になった……(´・ω・｀)

Pacemakerでインターリンクを使わない場合、クラスタノードを探しだす処理にマルチキャストを使うのだが、
"ns-lab BB"の鯖では諸事情でマルチキャストを全遮断しているので、上記の構成が使えなかった。
その為、今回はユニキャストによる決め打ちでノードを探し出す設定に変更。
ユニキャストの設定方法は色々と見つかり、例を元にアレンジも加えつつコンフィグ作成を行ったのだが、
いざPacemakerとCorosyncを起動してもcrmshでノードが拾えないという始末。

駄目だった原因はcrmshより上位層である、
そもそものPacemaker+Corosync連携でミスっていたという悲劇。
この原因を突き止める為に3週間くらいかかってしまった。

………

そんなこんなでcrmshとpcsのどっちを使うか問題とか、
Pacemakerで割り当てたEIPにping送っても戻りが無くて、(´・ω・｀)としていたりとか、
色々と回り道をしつつも、なんとか冗長負荷分散Proxyを常用可能なレベルまで持っていく事が出来た。

冗長構成+負荷分散を一度でも構築した経験があれば、
NAT環境下でのサーバ冗長化も工夫次第で作れるし、色々と良い経験になった。

"ns-lab BB"配下は、シングル構成なシステムも何個かあるので、
これを気にシングル構成脱却を行っていきたい所。

« 続きを隠す