- - PR -
DNS BINDの設定について（及び ipchains の設定について）
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-04-15 11:19
なるほど、BASE さん のおっしゃる通りです。
実は内心そのようなご回答を期待しながらも、経験が浅いため、どうも確信が持てずに質問いたしました。 お二人にアドバイスをいただいたことにより、グループウェアのサーバーは他の公開サーバーと同じようにDMZに配置して単体でフィルタリングしようと思います。 また、現在 がるがる さん にIPスプーフィングの危険性などのセキュリティー面での検証を行って頂いてますので、ＢＡＳＥ さん からもその観点でご意見を頂戴できれば光栄です。是非よろしくお願いします。 | ||||||||||||
|
投稿日時: 2002-04-15 13:24
すいません、あれだけじゃなんも付加価値がないので
とりあえずこんなのを・・・ http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO-7.html IPChains使ってDMZ構築する方法のTipsみたいです。 NIC１枚増やせるようであれば、DMZ構築も視野に入れてみてはいかでしょう？ ＃IPChains使ってるってことでとで ＃LinuxでFireWall作ってると勝手に解釈しています。 ＃間違ってたらごめんなさい。 | ||||||||||||
|
投稿日時: 2002-04-15 16:15
ご指摘の通り、Linuxでファイヤーウォールを構築しております。
私はてっきり ----------------------------------------------------- [InterNet] ｜ ｜ [ルータ]211.x.x.1 ｜ ｜----------[DNSサーバー/BIND]211.x.x.2 ｜----------[公開WEBサーバー/Apache]211.x.x.4 ｜ ｜ 211.x.x.3 [ファイヤーウォール] ｜ 192.168.1.1 ｜ [ローカルサーバー/Apache]192.168.1.2 ----------------------------------------------------- の構成の中の211.x.x.x/28のセグメントがDMZになっているものと 思っておりましたが、セキュリティー上、やはりLANカードをもう1枚指して http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO-7.html のように 構成する必要があるのでしょうか。 [ メッセージ編集済み 編集者: okumura 編集日時 2002-04-15 16:17 ] [ メッセージ編集済み 編集者: okumura 編集日時 2002-04-15 16:18 ] | ||||||||||||
|
投稿日時: 2002-04-15 17:29
もし、DMZを構築するのであればNICは3枚に必要になるかと思います。
現在の状態であれば、DNSと公開サーバはルータのフィルタリングの他は 個別のホストでのセキュリティだけになります。 ただ、DMZが構築されていないから セキュリティ上どうのこうのという話には当てはまらないと思います。 Internet上にホストがさらされていたとしても、 ”ホスト個別のセキュリティ対策”や”パッチの適用”が”適切”に行われているのであれば DMZは構築しなくても良いと思います。 DMZの話を持ち出したのは、仮にもう１台もFireWallの外に置こうとする場合、 DMZを構築し公開サーバへのアクセスを一括でフィルタリングなどを管理することで 管理リソースが楽になるのではないかとも考えるわけです。 ＃ログなんかも一括で管理できるでしょうし もし、今度の私の発言で”DMZが構築されていないとセキュリティ上問題だ”と 勘違いさせてしまったらごめんなさい。 今回の部分でセキュリティ上まずいなと感じた部分は LAN内に対してFireWallを超えてアクセスできるパス（Port80）が ある部分だけです。 | ||||||||||||
|
投稿日時: 2002-04-15 18:01
的確なアドバイスをありがとうございます。
BASE 様 のアドバイスは分かりやすく、いつもありがたく 拝見させて頂いております。 さて、 「今回の部分でセキュリティ上まずいなと感じた部分は LAN内に対してFireWallを超えてアクセスできるパス（Port80）が ある部分だけです。」 に関してご質問させていただきます。 PORT80をオープンしておりますのは、複数のLANセグメントのクライアント達が 一般に外部のホームページを閲覧できるように穴を空けました。 PORT443をオープンしておりますのも同じ目的です。 クライアント達が安全に外部のWEBページを参照できる正しい設定をお教えいただけますでしょうか。。 プロキシサーバーなるものを構築するのでしょうか。 ご教授願います。 | ||||||||||||
|
投稿日時: 2002-04-15 21:55
ども。ちと遅くなりまして。
概ね見たのですが。ちと気になる点がいくつか。 ・inputのところでルールに乗っからなかった場合のDENYが見当たらない 実際のipchainsのコマンド発行を見ないとわからないのですが＆多分大丈夫だとは思うのですが、一応。 ・IPMA4とPOP3が両方とも穴が通っている。 いへ、別に問題はないのですが、実際にIMAP4を使ってるところを久しぶりに見たので（笑 ・202.x.x.xってなんだろ？ ルールの中に「202.」というIPがあるもので。或いはtypo（タイプミス）かもしれないので、確認されたほうがよいかも、です。 で、IPスプーフィングの原理がわからないとのお話をされていたのでついでに。 基本的には「外から入ってきたのに中からのパケットのフリをする」攻撃です。 例えば、ローカルサーバで「ローカルから入ってきたらいっぱい見せてあげる」ってな設定にしているとしましょう。まぁ、大雑把に書くと ipchains -s 192.168.0.0/24 -d 192.168.0.1 -j ACCEPT ってな感じでしょうか。192.168.0.1サーバで、192.168.0ネットワークからならOKよん、と。 これを、もし（今回のネットワークで言うところの）f/wより外側のパケットが「僕192.168.0から来たの」とか大嘘ついたら、セキュリティー的にえらい目に会います。 で、この場合、ルータ無いしf/wでこれを食い止めます。 ルールは、例えば ipchains -A chain_name -s 192.168.0.0/16 -d 0/0 -j DENY ってな感じです。つまり「外から来たのに、発信元IPが192.168.X.Xだった場合は却下する」ってな感じです。 同様に、明らかにローカルな10.X.X.Xとかその辺をこれでトラップすることで、IPスプーフィングを防ぐことが出来ます。 なんかわからないことがあったらまたここにでも書きこんでください :-) | ||||||||||||
|
投稿日時: 2002-04-16 09:06
いつもお世話になります。
この度は大変詳しく解説していただきましてありがとうございます。 さて、問題となる事項がたくさんございますので、番号付けをしてご質問させていただきます。 １．「inputのところでルールに乗っからなかった場合のDENYが見当たらない 実際のipchainsのコマンド発行を見ないとわからないのですが＆多分大丈夫だとは思うのですが、一応。」 ⇒Chain input (policy REJECT: ・・・)で満たせていると思っておりました。 やはり ipchains -A chain_name -s 192.168.0.0/16 -d 0/0 -j DENY などで食い止めないといけないのですね？ ２．「IMAP4とPOP3が両方とも穴が通っている。 いへ、別に問題はないのですが、実際にIMAP4を使ってるところを久しぶりに見たので（笑」 ⇒「公開WEBサーバー」と同じセグメントに「メールサーバー」211.x.x.5 があります。ここではPOPサーバーとIMAPサーバー両方を稼動させておりまして、移動の多いクライアントはIMAP、ローカルに取り込んでしまいたいクライアントはPOPを利用して頂いております。 ３．「202.x.x.xってなんだろ？ ルールの中に「202.」というIPがあるもので。或いはtypo（タイプミス）かもしれないので、確認されたほうがよいかも、です。」 ⇒すみません。まぎらわしかったでしょうか。211.x.x.2 は、プライマリDNSサーバーで 202.x.x.x はプロバイダ側で用意されているセカンダリDNSサーバーです。 ４．BASE 様 のご指摘にもありますように、「LAN内に対してFireWallを超えてアクセスできるパス（Port80）がある」のはまずいのでようか。こうしないとクライアントが外部のWEBページを参照できないのでは。。 [ メッセージ編集済み 編集者: okumura 編集日時 2002-04-16 09:09 ] | ||||||||||||
|
投稿日時: 2002-04-16 10:57
どもです。
っつか、早速（笑
一応、きちんと明示しておいたほうがよいと思います。 ただ、コマンド発行の順番間違えると大変なのですが（本当に「あらゆる」パケットをDENYにしてしまうので）。
なるほろ。であれば、あの設定でOKだと思います。
んと。今回の場合。 [外界(今回の場合DMZ?サーバが置いてある領域?)] | [eth1] [[ ファイアウォールマシン ]] [eth0] | [LAN環境] という状態であると予測しております。んで、ルールを見ると ACCEPT tcp ------ 0xFF 0x00 eth1 0.0.0.0/0 211.x.x.3 80 -> * となっております。つまり 「外部からF/Wに入り込むときに、発信Portが80番（HTTP)パケットならOKよん」であります。 なので、これは基本的に問題ないと思います。ただ、もしルールが ACCEPT tcp ------ 0xFF 0x00 eth1 0.0.0.0/0 211.x.x.3 * -> 80 の場合、状況によっては非常に危険であると言えます（まぁどーせNAPTかけてるので、内部到達するのはまず無理なんですが、普通）。 で、余談。もしこれが「NAPTではなくて、かつ"* -> 80"」だった場合。 例えばLAN内に「不用意にインストールされた」Winodws NTやWindows 2000がある場合(下手すっと、「誰も気づかないうちに」IISがインストール、自動起動しております)、いやぁなせきゅうりティーホールに悩まされることになります。こぉどれっどとか、わりと典型ですよね（そーいや、他の会議室で危険な発現もあったような（笑））。 で。フィルタリングを「ものすごく」アバウトに、かつ「ある意味」神経質に行うのであれば、 ・外部から内部に入ってくる ・到達Portが０から1023番（いわゆる特権ポート） は、一旦全部とめてしまうのも手です（ただし、FTPの問題があるのでそこだけ小さな穴をあけてください）。もうちょい神経質にいくなら、準特権ポート（何番までだかちと失念しております（苦笑）?求むフォロー＞ALL?）も塞いでおくとまぁ色々安心です。 この辺になってくるとまぁ「セキュリティーポリシー」を含む、根本的な設計にも絡んでくるとは思うんですが。先達に曰く「硬ければ使いにくく、柔らかければ壊される」。 ネットワーク設計で、常に難しさを感じる瞬間ですね。 またなにかありましたら。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。