2015年01月17日(土) - 21:04 | カテゴリ:
Network
以前からずーっと使っているD-LinkのL2SWに負荷をかけすぎたからか、
近頃不調になってしまった(´・ω・｀)
まぁ、サーバを収容していて高負荷がかかる事がわかっているのに、
魔改造したスイッチを使っていた自分もどうかと思うが…
という事で、そろそろスイッチング容量多めのL2SWに置き換えるべきか、
適当な物を買って分散化させるか等色々と考えつつ機材を選んでいる。
現在、L2SWの導入候補として上がっているのは以下の3つ
-
Cisco 2960S
-
Allied Telesis AT-9424T/SP
-
HP ProCurve 2824
2960Sだけ値段が違いすぎるけどNWを囓っている者としては、
「ギガCiscoは欲しいな～」と思い候補に。
2924Tは個人的に使い慣れたAlliedスイッチなので候補に入れてみた。
Allied製品はGS908MとかGSシリーズなら手元にあるのだが、
そろそろATも使ってみたく、L3SW領分の物を候補に。
ProCurveは安いわりに性能がそこそこ良いのでこちらも候補。
2824はそこかしこで使っている様で資料も多めなのが魅力的。
さて、ここからは予算とNWトラフィックを考えつつ、
導入する機材を選びますかね。
2014年12月29日(月) - 18:13 | カテゴリ:
PC
2014年は基幹レベルでヤバいインシデントが多かった多かった…(´・ω:;.:…
NTPやSNMPあたりの、UDPを使っているサービスはDDoS踏み台にされる事がある為、
インシデントの注意喚起がよく出ている昨今。
だが、今年はそんな日常的セキュリティインシデントを吹っ飛ばすレベルでヤバい脆弱性が多数上がってきた。
という事で、nowsky主観で今年の脆弱性を適当に挙げてみた
※切りが無いので、MicroSoft/Adobe/Javaあたりは除く。だって毎月でるし…
この中でも特に緊急性が高かったのは、OpenSSLのHeartBeat脆弱性(Heartbleed)と、
GNU BashのOSコマンドインジェクションの脆弱性(Shellshock)あたりだと思う。
Heartbleedは、暗号化されている為に安全と言われていたSSL/TLS通信を使っているにもかかわらず、
暗号化された内容を第三者が不正閲覧出来るかもしれないという物だった。
この脆弱性がここまで有名になったのは、攻撃難易度としては結構高いとは言え、
-
暗号化通信の基幹部分を崩す脆弱性
-
攻撃された側は攻撃を感知出来ない
-
応用すればサーバ情報を引き出す事も出来る
という、基幹を揺さぶって世界(のシステム管理者)を震撼させる物だった為。
普段、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%脆弱は潜んでいるわけで…
脆弱性情報が出ないで痛い目見るよりは、明るみに出る事で修正される方が良いのは当たり前。
来年こそは、基幹レベルでヤバい脆弱性に追われない事を祈るのみ。
« 続きを隠す
2014年12月23日(火) - 16:47 | カテゴリ:
Network
自宅にいる時はandroidからns-lab BBへ直接接続しているので問題が無いのだが、
外出先からVPN(IPSec)を張ってns-lab BBに接続する際に問題が起きたのでちょいとメモ。
事の発端は、内向けDNSのTTLを86400から10800に短縮した為。
TTL=86400の時はandroid端末内にDNSキャッシュが残っている為、
VPN経由で自鯖に接続をしても、キャッシュが優先されて内向きのAレコードが返ってきていた。
しかし、TTL=10800にすると流石にキャッシュが切れる事があり、
キャッシュ切れる → 内部の名前解決 → "ns-lab.org"ドメインのグローバル側Aレコードが返答される →
"ns-lab.org"サブドメインの問い合わせもグローバル側に投げられる → Aレコードが無いのでNoReplyになる
という、よくある障害コンボに突き当たった。
まぁ、この辺りは慣れた物でVPNプロファイルで優先DNSを設定したりしてなんとか回避。
したと思ったが、んな事無かった(´・ω:;.:…
文章だと非常にわかりずらいので、またもやトポロジ図の出番。
-
サーバがInternetとLANに見せているドメインは同じ
-
VPNクライアント側はSplitTunnelingを使って、InternetとVPN網の両方に接続可能
-
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は軽視されがちだけど、一度障害が起きると全滅するから特に気をつけておきたい所。
…たとえソフトウェア側に問題があったとしても(´；ω；｀)
« 続きを隠す
