つぶやき
技術系や雑感等は再編集して本文の記事にする事を前提としているので、こっちにLinkを張らないでください。
Facebookに書いた駄文(20150520)
少しだけ、思ったことを書いてみる。Security関連。 例によって、グダグダで、まとまりは無い。
数年前は、XSSだのCSRFだののようなWebアプリケーション系のセキュリティが花盛りだった。もう少し言うと、Middlewareから上のレイヤーのセキュリティ。 この状況が数年続き、そのエリアのセキュリティがビジネスに繋がってきたことから、Security技術者も、このエリアの人が増えた。知見もBad know-howも溜まった。 これはこれで素晴らしいことだとは思う。
翻ってみると、その間Infra関連技術者はApplication技術者と違ってあんまり増えていない。また、Applicaton側と比べて技術的変化が少なかった。
いまはやりのSDNだって、あれはInfra技術者側の技術ではなくApplication側の技術者向けの技術に近いと思う。
さて、この状況の中で、ShellShockや、Heartbleed、今回のracoon問題をみると、これがなかなか悩ましい。これらの問題は、少なくともApplicaton側の守備範囲からは少し離れている。むしろInfra側の守備範囲。
ところが、これらの実装は、インフラ側で対処することが困難。だって、多くのインフラ技術者って、この領域に関して言えば「提供されたupdate」を適用するしかできないから。
OSのpatch、Server applicationのpatch、FirmwareのPatch、全部根は同じ。
冪等だの青緑だの言うけど、これらは「インフラはちゃんと動く」という担保があって初めて意味を持つことであって、「インフラを動かすための技術ではない
(使えないと言っているわけではない。構成管理や冗長を考えたらこの考え方はInfraにも有用)。
Securityの観点でここしばらくのようなこと(shellshock,heartbleed,…)が起こって困る事は、そもそも、インフラ側が提供している機能の根幹であるこの種のソフトウェアは、実はApplication側に比べて、余りにもぬるま湯に浸かってたという事。そして、多様性が足りなく、置き換え困難な事。さらに、一度何かが見つかると、その影響がとんでもない範囲まで広がっていて、かつ、その修正がとんでもないコストになる事。 しかも、インフラは「動いて当たり前」と思われ、かつ、過剰な価格下落を要求されている事。
(ちと脱線) 運用者から見たら、「こんな報われない、旧態依然とした、辛い刺激しかない、激務」なんてやりたくない、と思う方が普通で、だから新しい人だって入ってこないしすぐに抜けてしまう事になると思う。 (元に戻して)
まぁ、まとまりもとりとめもないんだけど、今の状況はかなりまずいところまで来ている気がしている。善意に寄りかかった寄生虫がモンスターになっていろいろ崩壊するまえに、もう一度「Infraの総点検」と、「問題点の洗い出し」を徹底する必要があり、それを一つずつ潰していく必要があると思う。
少なくとも、Applicationエリアの近くまでInfraを引き上げないと、「共倒れ」になると思う。
メモ(20150520)
- etckeeper with ansible https://github.com/silpion/ansible-etckeeper
- pure-vi http://ex-vi.sourceforge.net
気になった記事(20150512)
ああ、気になった記事がたまっている。 FaceBookと連動できたら便利なのに… いや、FBでなくてもいつも使っているToolから直接URL送れるでもいい…
- これに気づいてない日本人は永遠に英語を話せるようにはならない。 英語を話せるようになるかどうかよりも、根本的に失礼なことをしていたということの方がはるかに悲しい
- GCEのライブマイグレーションのすごさをまとめてみた 単体レベルで考えれば、技術的には、それほどのことをしているわけではない。しかし、あの規模で確実に動くことはものすごいことだ
- 伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？ 確かに、そういう傾向かもしれないと思った
- Gitと連動するWebベースのコードレビューツール「Gerrit 2.11」リリース へぇ。今度試してみないと
- 大規模データ時代に求められる自然言語処理 -言語情報から世界を捉える- これはあとでじっくり読まないと
- Metasploit――大いなる力と責任を体感する (1/2) うむぅ。これはやりながらじゃないとわからない
- 息が止まる超絶演奏。あるピアニストの『ラ・カンパネッラ』がスゴすぎる 確かにこれはすごかった
- CC0 日本語版の公開 参照版ではなく正式版というところが素晴らしい
そろそろいろいろ片付けないと
やらなきゃならないことが山のように溜まっているので、そろそろメモにしておく。
- DNSサーバーとSMTPサーバーの移設
- KnotDNSはいいとして、Postfix+CyrusSASLで行くかPostfix+dovecotで行くか…
- IMAPサーバーの移設
- SMTPサーバーから切り離す。
- XenServerのβ版テストと、XenOrchestraのテスト
- Dom0がCentOS7になるので、その分の確認とか
- OPNsenseの試験
- イケてたら移行も考えないとなぁ
- NGiNXとmod_securityを利用したWAF構築
- NGiNX Proxy/LoadBalancer配下でWAF処理させる一連のシステムの構築
- SignatureはOWASPの奴かな
- Snort+pf+pfSyncを利用したIPSの構築
- そろそろ新しいSnort使いたいんだよな。全然追えてないけど
- NGiNXのSPDY/SNI対応と、FreeBSD/NGiNX上でAES/NIを利用したSSL Accelerator環境の構築
- SPDYは、NGiNXがHTTP2.0対応するまでのつなぎ
こうしてみるとてんこ盛りだ。全部それなりに時間がかかる。
CentOS上のNFS
原因は不明だが、とりあえず対処療法で逃げたのでメモ。
原因を追究する根性がない。
- 以下のマシンはすべてKVMのGuest VMとして作成。
- KVMはCentOS-7で構築している
- NFS Server: CentOS 6.6/lsyncd/xintd/rsync
- NFS Client: CentOS 6.6
- NFS Protocol: v4 (nfsinfo -mで確認)
この環境で、以下の設定を実施
nfs server: /exports /mnt 172.25.255.0/24(rw,root_squash,sync,no_subtree_check) chkconfig --list nfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off rpcgssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off rpcsvcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
nfs client: /etc/fstab nfs-server:/mnt /mnt nfs rw,sync,suid,exec,nouser,auto,hard,intr,noatime,actimeo=10 0 0 chkconfig --list netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off rpcgssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off rpcsvcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
この状況で、client側で dd if=/dev/zero bs=512 count=102400 of=/mnt/test を実行すると、以下のような症状が出る
- コマンドは正常に終了する
- しかし、/mnt/testのファイルサイズが32768であったり65536であったりする。
本来、ファイルサイズが102400にならなければならないのに、32768や65536バイトにしかならないのは明らかに異常。
原因を小一時間ググったが、参考になる情報がないので、仕方がないからfstabのOprtionをいろいろ変更したところ、syncを外したら問題が解決した。
この問題は、複数のCentOS VMで観測されたので、個々のVM Instanceの問題ではないと考えられる。
しかし、こんなことが起こる理由がよく分からない。