UNIXやLinux: 2013年12月アーカイブ

以前、「再帰問い合わせ有効のままの DNS サーバがあった件」というエントリーで書いたように、当社で管理しているコンテンツサーバの中に、キャッシュサーバの機能が有効になったままのものがあったので、再帰的クエリーの実行は一切許さない

allow-recursion { none; };

という設定をおこなった。

しかし、今回、お客さんがテストでこのサーバを一時的にキャッシュサーバとして使いたいということだったので、特定のホストからの問い合わせ要求だけ受けるように設定を変更した。

内容的には、named.conf の中の、上記の allow-recursion { none; }; 記述をコメントにして、以下のように設定。

acl my-network {

        124.XXX.XXX.XXX/32;
        202.XXX.XXX.XXX/32;
        180.XXX.XXX.XXX/32;

};

options {

        directory       "/var/namedb";
        pid-file        "/var/namedb/run/named.pid";
        allow-transfer {
                180.XXX.XXX.XXX;
        };
        allow-query {
                localhost;
                my-network;
        };
        allow-query-cache {
                localhost;
                my-network;
        };

//        allow-recursion { none; };

};

まず acl で、my-network という IP アドレスグループを設定。
今回は 3台とも個別のサーバなので 32ビットマスクをかけて。

次に options で、allow-query と allow-query-cache に自分自身(localhost)と先ほど作成したグループを設定。
allow-query、allow-query-cache の設定で、これらのホストからの DNS クエリーは許すということで、つまりキャッシュサーバとして使わせるということ。

この設定を行うまでは、このサーバをキャッシュサーバとして使おうとしても、

% nslookup
> www.yahoo.co.jp
Server:         named.exsample.com
Address:        124.XXX.XXX.XXX#53

Non-authoritative answer:
*** Can't find www.yahoo.co.jp: No answer

となっちゃうが、上記設定を行った後は、

% nslookup
> www.yahoo.co.jp
Server:         named.exsample.com
Address:        124.XXX.XXX.XXX#53

Non-authoritative answer:
www.yahoo.co.jp canonical name = www.g.yahoo.co.jp.
Name:   www.g.yahoo.co.jp
Address: 203.216.231.189

という具合に、正しく名前が引けるようになる。

DNS サーバが、キャッシュサーバとして稼働しているということだ。

ちなみに、上記設定をして 10秒後には、

Dec 11 16:40:32 localhost named[1101]: client 49.XXX.XXX.XXX#44640: query 'host1.exsample.com/A/IN' denied

というようなログが数秒おきに山のように出力されるようになった。
他人の DNS を DDoS 攻撃の踏み台にしようとひたすらインターネット上のキャッシュサーバを探し続けている気持ち悪いやつが世の中には一杯いるんだな。

死ぬような痛みを感じながらも死ねないまま七転八倒したあげく、自分の糞を喉に詰まらせて死ぬとか、そういう末路をたどればいいのにな、こういう犯罪者どもは。
PostgreSQL の VACUUM 処理を書いたスクリプトを cron で自動実行したいのだが、このサーバは現在、UNIX ドメインからの DB への接続でもパスワード認証が必要な設定にしている。深い意味はなくて、うちでサーバ運用を引き継いだ時そういう設定になってたからそのままにしているだけだ。

そうすると、sh スクリプトの中で vacuumdb とか実行すると、対話式にパスワード入力を求めてくるんだよね。cron で自動実行するスクリプトでこれはまずいやろう。

そこで、.pgpass を用意したり、PASSWORD や PGPASSWD といった環境変数にパスワードを予めセットしてみたりしたんだが、全然効かんやん。

そもそも、このサーバ、地元大手の某プロバイダのホスティングサービスを利用してるんだけど、環境が「やたらセキュアな仮想サーバ」なんだよね。
PostgreSQL も「vinstall というコマンドで、仮想OSが用意しているバイナリをインストールしてください。yum とかで入れるのやめてください。ソースから make?絶対だめです」って感じ(^^;。仕方無いから言われるとおり、その vinstall ってコマンドで入れたヤツなんだよね。

で、そうして入れた psql や vacuumdb コマンドには、-w(--no-password)オプションも無い。
多分、「.pgpass や環境変数へパスワードをセットするのは危険」という思想なんだろうなあ(^^;
「外は危ないから、一生家から出るな」っていうセキュリティ思想だよね。馬鹿だよね(笑)

で、仕方ないので、pg_hba.conf を触って UNIX ドメインの認証方式を trust に設定。
これで、問題なく cron でスクリプトを実行出来るようになった。

何か、本末転倒なセキュリティ対策やなあ。
いや、ホント、この仮想 OS 嫌いだわ。どう考えても愚者のための OS なんだもん(^^;

このアーカイブについて

このページには、2013年12月以降に書かれたブログ記事のうちUNIXやLinuxカテゴリに属しているものが含まれています。

前のアーカイブはUNIXやLinux: 2013年10月です。

次のアーカイブはUNIXやLinux: 2014年2月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。


月別 アーカイブ

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら