サーバーからのラブレター＠人騒がせ
Posted on 2013年12月11日 by Qsaku
サーバーからは１日１回ラブレターが送られてきます♪
って、ログがメールで来るだけなんですけど。ｗ
ラブレターによると・・・
rootkit検知ツールが改ざんを検知したと騒いでます。
実際にはcron.dialyで毎日決まった時間に自動実行させますが、
手動でやる場合は以下のコマンドです。
# chkrootkit
何もなければ【not infected】や【not found】という結果が出力されます
Checking `du’… not infected
・
・
省略
・
・
Searching for Adore Worm… nothing found
・
・
・
以下省略
ところが以下のように
Checking `du’… INFECTED
rootkitが問題を検知すると、大文字で【INFECTED】と出力されます。
そこで通常は
# chkrootkit | grep INFECTED
のごとく多項目にわたる結果から【INFECTED】とされた項目のみ抜き出して
出力されるようにします。
つまり、何事もなければ何も表示されません。
ラブレター（しつこいって？）によると
for Suckit rootkit… Warning: /sbin/init INFECTED
ギョギョ！/sbin/initがSuckitにより改ざんされた！？
早速事実かどうか該当するパッケージとデータベースに
格納されているパッケージ情報と比較してみます。
# rpm -V `rpm -qf /sbin/init`
実際に改ざんされていれば、なにがしかのメッセージが
表示されますが、何も表示されませんので、検知ツールの
誤検知ということになります。
なぜ誤検知されるかをググってみると、詳細は省きますが
upstartパッケージの更新でinit が置き換わることにより
リブートするまでは誤検知するのだとか。
誤検知をさせないために
/usr/lib64/chkrootkit-0.49/chkrootkit
の中に
rpm -V `rpm -qf /sbin/init`
を実行してなにも出力されなければ未検出という条件を
加える方法も見つけましたので、修正しておきました。
人騒がせなやつめ！
ところでシステム全体の整合性チェック・ツールとしては
tripwireがありますが、この１台が未導入でしたので
インストールしておきます。
パッケージはサードパーティのEPELに置いてありますが、
先日のrpmforgeとの絡みで、enabled=0にしてましたので
# yum –enablerepo=epel install tripwire
ポリシーファイル最適化などは後ほどゆっくり・・・
ちなみにenablerepo=epelの前は【-】が２個連続なのですが、
wordpressの標準エディタの仕様なのか、うまく表示されません。。。
Evernoteでも半角のマイナスを２個並べたとき、前後がスペースや
半角文字だと、勝手に全角マイナス１個に変換されてしまいます。
横線引きたいときには便利なのでしょうけどね。
オープンリゾルバー
Posted on 2014年3月31日 by Qsaku
－貧乏暇なし状態継続中－
接続会社からメールで拙宅のDNSサーバーが、不特定な
IPアドレスによる外部からの再帰的な問い合わせを
許可しているというご指摘のメールがありました。
早速オープンリゾルバー確認サイト ⇒ こちら
で診断を受けたところ、オープンリゾルバーの可能性があるという結果が・・・
いくら忙しくてもこいつだけはやっつけておきました。
■ オープンリゾルバーについて少し語ります
DNSサーバーにはいくつかあって
１ 権限サーバー
・自分で情報を持っている
拙宅サーバーにはoba-q.comなどを含め、50ほどのドメインを管理。
２ キャッシュサーバー
・自分で情報は持っていないが、一度他の権限サーバーに問い合わせた
結果をキャッシュして、設定した期間は同じドメインの問い合わせに
キャッシュ情報から返答する。
３ 権限およびキャッシュサーバーの併用
なぜキャッシュサーバーが存在するのかというと、権限サーバーしかなければ
自分で情報を抱いていないドメインには、毎回権限サーバーに問い合わせを
するることになるので、サーバーや回線に負荷がかかるのを軽減するためです。
キャッシュされたものに情報があれば直接返答するので早いということもあります。
★ キャッシュサーバーの功罪＠余談
プロバイダのユーザーは、明示的にDNSサーバーを指定しない
（自動取得の）場合、プロバイダー管理のDNSサーバーで名前解決
（ホスト・ドメイン名⇔IPアドレス）を行います。
特に大手プロバイダーは問い合わせが多くなるため、複数のDNSサーバーで
対応していますが、キャッシュをリフレッシュする時間が長いサーバーが
見受けられます。
拙宅サーバーでは1日でリフレッシュする設定ですが、大手プロバの
サーバーでは、1月近く古い情報を抱いているものも見受けられます。
通常は３日から4日もあれば反映されることになっているのですが、
負荷軽減を意識するあまりリフレッシュ時間が長くしすぎすぎると、
WebやMailサーバーを変更した場合など、古い情報で返答されてしまい、
古い情報でサーバーを辿ればそんなサーバーはねえぞ！なんて
怒られる場合が多々あります。
それが証拠に同じプロバイダの複数のネームサーバーにIPアドレスが
更新されたドメイン（サーバーを引っ越した）の問い合わせをした場合、
違った回答（新だったり旧だったり）が返ってくることがあるのです。
対策として拙生はWebやMailサーバー切替の時は、1ヶ月くらいは
古いサーバーを活かしておき、Webサイトも新旧サーバーで見られたり、
メールも両サーバーから受信できるようにしておき、リフレッシュさ
れるのをじっと待つことにしています。＠余談終了
★ オープンリゾルバーとは＠ここから本題
キャッシュした情報から再帰的に返答する場合、今回の脆弱性が
発覚してからは指定したネットワークのみアクセスを許可します。
拙宅サーバーでは通常はLAN内のみ指定します。
（もちろん権限サーバーは誰にでもアクセスを許可）
プロバなどでは自分の降り出したIPアドレスを指定します。
しかし世の中には外部からの不特定なIPアドレスに対しても
返答するキャッシュサーバーがありこれをオープンリゾルバーと言います。
拙宅サーバーの1台がこいつであったというのが今回の事件です。。。
自分が参照しているDNSサーバーがオープンリゾルバーであるか
否かは、最初に記載したサイトにアクセスして確認できます。
■ 拙宅DNSサーバーがオープンリゾルバーだった理由
はい、単なる設定忘れです。
オープンリゾルバーの脆弱性が発覚した時には、すぐに
他のサーバーはキャッシュ情報の再帰的問い合わせはLAN内から
のみに絞っておきましたが、該当サーバーは【したつもりだったが
実は未設定だった】というお粗末なお話です。スミマセヌ。。。
勿論すぐに外部からの問い合わせはクローズしておきました。
■ DDos攻撃の踏み台となりうるオープンリゾルバー
別にけち臭いこと言わないで、誰にでも教えればばいいじゃん！？
って声が聞こえてきそうですが、DDos攻撃の踏み台と成り得るために
そうはいかないのです。
仕組みはこうです。
あるサーバーなどのIPアドレスになりすまし（IPアドレスを詐称し）多くの
オープンリゾルバーであるDNSサーバーに一斉に問い合わせをすると、
詐称されたＩＰアドレスを持つ攻撃対象サーバーに、一斉にあちこちの
オープンリゾルバーDNSサーバーから回答が返ってくることになります。
一つのリクエストによる回答のパケットは小さくても、イナゴの大群のごとく
数による攻撃が行えるんですね。
つまり踏み台として大規模な DDoS 攻撃の一端を担ってしまうことに
成り得えるというわけです。
オープンリゾルバーは全世界に多数存在するので、どこかのパソコンを
乗っ取ってシコシコ攻撃を掛けるよりずっと効率的なやり口です。
どぉして次から次へ悪知恵が働くのでしょう。
そんな頭が良いなら違うことに使えば良いのにと思ってしまいます。
■ オープンにしないBIND(9.*)named.confの設定
LAN内のネットワークが【192.168.1.*】だとします。
LANネットワークに適当な名前（ここではoba-q）を付けます。
acl oba-q {
192.168.1.0/24;
localhost;
};
//サーバーを運用されている方に192.168.1.0/24;などの意味が
//分からない方はいないと思いますので説明は省きます。
//オプション内に追記
options {
//以下の4行をオプション内に記載。
//recursionはすでにyesかも。
};
//権限およびキャッシュサーバー併用なので
//キャッシュサーバーを活かします。
recursion yes;
//権限サーバーはすべてのクエリを受付ます。
allow-query { any; };
// リゾルバーとしての応答を上記で設定した【oba-q】
// からのみ許可します。
allow-recursion { oba-q; };
// キャッシュの内容を【oba-q】のみに返答します。
allow-query-cache { oba-q; };
// はコメント行なので一緒にコピペしても大丈夫です。
以上簡単な設定です。
見えているところでの書式に間違いはありませんが、
スペースや改行などの関係で、このままコピペしても
大丈夫かどうかは検証しておりません。
違ったらＤＮＳサーバー再起動時に何行目がエラーと
表示されるので分かります。
このくらいなので生書きしたほうが無難かも。。。です。
最近のコメント