- - PR -
DNSサーバーへのアタックの跡?
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2003-02-03 11:39
お世話になります。実験DNSサーバー(BIND9)へのアタックの跡らしきものを見つけました。おそらく不正なゾーン転送の跡だと思います。大量のログが残っておりましたので一部だけ掲載します。
################## LogWatch 2.6 Begin ##################### --------------------- Named Begin ------------------------ **Unmatched Entries** client 192.168.0.3#1064: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 192.168.0.3#1067: update 'mydomain.jp/IN' denied: 1 Time(s) client 210.159.xxx.xxx#1221: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 210.159.xxx.xxx#1224: update 'mydomain.jp/IN' denied: 1 Time(s) client 210.170.xxx.xxx#1124: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 210.170.xxx.xxx#1127: update 'mydomain.jp/IN' denied: 1 Time(s) client 210.170.xxx.xxx#1031: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 210.170.xxx.xxx#1034: update 'mydomain.jp/IN' denied: 1 Time(s) client 210.170.xxx.xxx#1563: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 210.170.xxx.xxx#1566: update 'mydomain.jp/IN' denied: 1 Time(s) client 218.44.xxx.xxx#60016: update 'mydomain.jp/IN' denied: 1 Time(s) client 218.44.xxx.xxx#60098: update 'mydomain.jp/IN' denied: 1 Time(s) client 218.44.xxx.xxx#60111: update 'mydomain.jp/IN' denied: 1 Time(s) client 218.44.xxx.xxx#60122: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 218.44.xxx.xxx#60148: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 218.44.xxx.xxx#60241: updating zone 'mydomain.jp/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET): 1 Time(s) client 218.44.xxx.xxx#60247: update 'mydomain.jp/IN' denied: 1 Time(s) ・・・ ・・・ ・・・ ------------------------------------------------------------ BIND自体の設定で、指定セカンダリDNSサーバーにのみ転送を許可しておりましたので、DENYされていましたが、要求の量が半端ではありませんでした。今回の実験DNSサーバーはRedhat7.3のインストール時にデフォルデ設定できるipchainsの定義で許可するサービスにDNSとSSHにチェックしてインストールしたもので、定義内容は以下の通りです。 ---------------------------------------------------------------------- #ipchains -nvL Chain input (policy ACCEPT: 4826 packets, 336971 bytes): pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports 436 34866 ACCEPT all ------ 0xFF 0x00 lo 0.0.0.0/0 0.0.0.0/0 n/a 66245 5105K ACCEPT udp ------ 0xFF 0x00 eth0 0.0.0.0/0 219.x.x.x * -> 53 7945 550K ACCEPT tcp ------ 0xFF 0x00 eth0 0.0.0.0/0 219.x.x.x * -> 53 242 13252 ACCEPT tcp ------ 0xFF 0x00 eth0 0.0.0.0/0 219.x.x.x * -> 22 611 32132 REJECT tcp -y---- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> * 74762 19M REJECT udp ------ 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 * -> * Chain forward (policy ACCEPT: 0 packets, 0 bytes): Chain output (policy ACCEPT: 135622 packets, 19489600 bytes): ---------------------------------------------------------------------- このような不正要求事態を受け付けないようにするにはどうすれば良いでしようか、是非ご教授のほどよろしくお願いします。 [ メッセージ編集済み 編集者: okumura 編集日時 2003-02-03 11:41 ] | ||||
|
投稿日時: 2003-02-03 11:46
初めまして。maji25です。
okumuraさんの書き込み (2003-02-03 11:39) より: > このような不正要求事態を受け付けないようにするにはどうすれば良いでしようか、是非ご >教授のほどよろしくお願いします。 Bind9なら、named.confに下記の記述を加えればいいのかな? blackhole { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 10.0.0.0/8; }; これだとIPがわからないといけませんが、、、IPがわかればこれではじいてくれるものと思います。直接的な解決にはならないと思いますが。とりいそぎ。 では | ||||
|
投稿日時: 2003-02-03 11:54
ありがとうございます。フィルタで弾くことはできませんでしようか。。
| ||||
|
投稿日時: 2003-02-03 15:52
お世話になります。udpの53への要求を指定の正規のセカンダリからのみiptablesで許可するようにすれば止まりました。やはりRedhatデフォルトの定義では甘いようです。
| ||||
|
投稿日時: 2003-02-04 09:51
これをやってしまうと、外からDNSが引けなくなるような気がするのですが 大丈夫でしょうか? | ||||
|
投稿日時: 2003-02-04 09:55
おっと。本当ですか?ちょっとやってみます。
| ||||
|
投稿日時: 2003-02-05 10:59
53/udpまで拒否すると、セカンダリに名前解決のリクエストが行く場合は、
問題無いでしょうが、自身に来た名前解決リクエストは拒否してしまうので、 #この場合はNotFound? 一部のユーザには問題ですねぇ・・・ ZONE転送をiptablesで拒否するならば、 53/tcpの通信をセカンダリのみ許可にするのでよろしいのでは? | ||||
|
投稿日時: 2003-02-05 11:18
BASE様、いつも本当にお世話になっております。皆様もご返答ありがとうございます。
さて、ここでもう一度確認させていただきたいのですが、プライマリのdnsサーバに対して他から来るdnsの要求は、要求元が、tcpの1024〜65535の任意のポート、要求先が自分(プライマリdnsサーバー)のtcpの53番ポート。セカンダリからのゾーン転送要求は、セカンダリのudpの1024〜65535の任意のポートから自分のudpの53番ポートで行われると、O□Nのサポートセンター聞きましたが、どうも違うようですか? |