2014年06月07日(土) - 18:46 | カテゴリ:
Linux
最近OpenSSLの重大バグ発見率上がっているなぁ~(´・ω・`)
………
OpenSSLのバグと言えば、Heartbleed発見で世界中が震撼したのが新しい記憶。
HBが見つかってから期間があまり経っていないのに、またもやデカイバグが発見されたとの事。
どうやら、SSL/TLS通信経路上での脆弱性らしい。
で、攻撃(改ざん等)を防ぐ為には"クライアント or サーバのどちらかで、脆弱性修正されたOpenSSLへ更新する"事が必須と。
脆弱性修正の施されたOpenSSLは、
-
OpenSSL1.0.1系統 → OpenSSL1.0.1h
-
OpenSSL1.0.0系統 → OpenSSL1.0.0m
-
OpenSSL0.9.8系統 → OpenSSL0.9.8za
なので、対応したバージョン(最新版)へ更新する必要がある。
てか、0.9.8系統のバージョン末尾がアルファベットの"z"を超えちゃったよw
HBの時程、世間では騒がれていないけど
世のサーバ管理者は着実に対応していく必要ある問題だわね(´・ω・`)
……という事で、自分の休日その1はOpenSSLのバージョンアップで無くなったのでした(´;ω;`)
2014年04月18日(金) - 23:02 | カテゴリ:
Linux
朝っぱらのニュースとかで報道されていたので知っている人もいるだろうが、
この脆弱性発覚によって、今週は地獄を見たインフラ屋が多かった事だろう(´・ω:;.:…
今回の脆弱性をPCに疎い人にでもわかるように書くなら、
『キャッシュカードと暗証番号のヒント(『1+1=2が暗号になっちょるよ!』レベル)を
自宅のポストの中に入れておいた』
というような感じかと。
つまり、『やろうと思えばキャッシュカードを利用出来る状態』になっていたのが今回の脆弱性。
PCに詳しい人向けの解説なら、DeNAが公開している記事がわかりやすくて、
概要も把握出来るのでオススメ。
DeNA : 巷を賑わすHeartbleedの脆弱性とは?!
…自分の場合、公になる前に今回の脆弱性を知る事が出来たので早くから対応に動けたのだが、
今回のは対策打つのも凄~~~く大変だった(´・ω・`)
まず、影響範囲が大きすぎた。
OpenSSLを利用しているのは、サーバサイドだと証明書,https,VPN,etc…と色々あるのだが、
今回のは一部クライアントソフトにも影響が出たのが一つの理由。
クライアントの大御所だと、OpenVPNとかWinSCP(FTPS)が対象に。
また、一部の商用ソフトウェアでも影響が判明してきた模様。
注:今は修正版がアップされている
NW分野だと、Cisco(IOS XE)の大御所からBIG-IP等のUNIXベースまで幅広く脆弱性対象に。
それら全てに対処していくのは骨が折れた。
そんな今回の脆弱性だが、殆どの場合でBugFixが出ているので今だったら、
ソフトのアップロードをして対応すれば良いかと。
RedHat系統なら『yum update』した後に対象サービスをリスタート。
OpenSUSEなら『zypper update』、Debianなら『apt-get update』とか、
それぞれのディストリビューションに合致した方法でアップロードを。
が、問題なのが"make等で独自ビルドしたミドルウェア"の存在。
自分の環境にも数台あるのだが、OpenSSLに紐付いているのが多すぎるので、
結局殆どをリビルドする様な自体に…
OpenSSLだけアップデートすれば良いようなアナウンスもあるのだが、
事が事なのでちゃんと対処をしないと後々ブーメランしそうなので。
で、ここからが脇に逸れた話になるのだが『今回の脆弱性って本当にヤバいの?』という声がチラホラ。
という事で、自実験環境でレッツトライしてみた所、
自分みたいなアホでもhttpsのセッションIDを取る事は可能だった。
…やり方の紹介はアレなので勘弁してね。わかる人なら、↑のブログ記事を見ればなんとなく把握出来るかと。
TCP/IPの事を囓ってないと出来ないレベルではあるが、その程度のレベルで出来てしまうのがアカン。
というのも、ここまで簡単だとスクリプトキディが横行しそうなのが。
ガチの自宅鯖運営者とかなら多重FW+IDS位は構築していそうだけど、
今回のOpenSSL脆弱性はそれすらも通過する可能性があるわけで…
『一つの暗号処理(ライブラリ)に依存するとこうなるのか~』と身に染みた一週間でした(´;ω;`)
« 続きを隠す
2013年08月18日(日) - 19:49 | カテゴリ:
Linux
今までは、自鯖にディスプレイを接続していたので、コンソールとかも直打ち出来たのだが、
PCの配置を変更した際にディスプレイとキーボードを取っ払ってしまったので、
GUI環境で確認したり入力したりが出来ない状態だった。
…まぁ、SSHさえ使えればGUIは余程の事が無けりゃいらないっちゃいらないのだが(´・ω・`)
が、この度GUI環境を使う必要が出てきてしまった為、
リモートで操作出来る様にVNC環境を整備してみた。
※写真だと2つのモニタが映っているが、接続先は別々のPCになっています。
肝心の構築メモはns-lab memoの方で、続きは動作写真でも。
今までの持論は『リモート環境? 実機触れば良いじゃん』という考えの人だったので、
VNCは初めての構築・運用だった。
現状だと、設定を詰められていない箇所もあるのだが、思ったのは『ちょっとレスポンス悪いな…』という。
しかし、常用するわけではないし動画やら負荷率高い物を見るとかでも無いのでこんなもんで良いかなと。
あと、VNCで問題になるセキュリティ関連については、
今回は自宅内でしか使わないのでSSH-Forwarding(トンネリング)だけしておけば良いと判断。
今回、一番苦労したのはxinetdからx11vncを叩く際の引数設定だった。
ポート番号を指定しているのに、実際には違うポート番号で待ち受けていたり、
一度に複数端末でログインするとセッションが全部切れたりと四苦八苦した。
結果として、いくつかのオプションが被ったりで競合しているのが原因っぽかった┐(´∀`)┌
2台のPCでほぼ同時に接続した際のSS
・PC1
・PC2
※自鯖の裏で色々と動かしているので、CPUやらメモリの使用率が高め(´・ω・`)
時間がある時に設定を詰めたいが、常用でも無いのでこんなもんで良いか( ´_ゝ`)
« 続きを隠す