- - PR -
iptablesのルールについて。。
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-03-06 01:47
今eth0(例66.66.66.66)がそのままネットにつながっているのでredhat９でiptablesでfirewallでポート2005を閉じようとしています。
ルールをすべて削除し、全てのアクセスを拒否しました。 sshでの接続を許可しました。port22 ssh のポートフォワード機能でトンネルさせて、そこからserverのport2005にアクセスを試みています。 iptablesにどのようなルールを追加すればよいのかわかりません。 POP over SSHでセキュアにメール受信のような事をしたいのです。 よろしくお願い致します。 | ||||||||||||||||||||
|
投稿日時: 2005-03-06 05:04
ネットワークの構成が分からないので何とも言えませんが…。ssh にて 利用するポートは 22 番のみで、ポートフォワード機能を利用しても 22 番以外のポートは利用しません。なので、iptables にて開くポートは 22 のみでかまいませんね。 ちなみに、どこへフォワードするかはクライアント側の設定だったはずです。 | ||||||||||||||||||||
|
投稿日時: 2005-03-06 06:21
そうなのですか？
sshのクライアントにはTeratermを使っています。 例えば、sshのポートを開き、sshは接続できます。 Foward local port "110" to remote machine "plain" port "110"とします。 でもメールはクライアントにservername: "localhost" port"110”と設定してもpopできません。 iptablesにはsshだけを開けるようにすればよいのでしょうか？ ネットワークの構成は直でglobal IPをeth0につなげているだけです。 | ||||||||||||||||||||
|
投稿日時: 2005-03-06 10:55
ちょっと一般論的な話になりますが、iptablesを利用する際にどんなルールを書けばよいか
分からない場合にやることとしては、 ・実際にどんな通信が行われているかを把握する iptablesを設定しているマシンや、送信元/送信先となるマシンにおいて、 tcpdumpやEtherealなどのスニファを利用して、実際にどのアドレスのどのポートから どのアドレスのどのポートに、どんなプロトコルのどんな内容の通信が行われて いるのかを調べる。上記3点すべてで行えるのが望ましいですが、 できるマシンだけでもかまわないし、スニファが使えない場合はnetstatの出力結果が 分かるだけでも十分なことはあります ・即ターゲットに送らず、LOGターゲットを活用する これは上記のiptables設定マシンでの調査とほぼ同等のことをするために、です。 即ACCEPTやDROPしたんじゃ、どんな通信を処理したんだか分かりません。 たとえば iptables -A INPUT <条件> -j accept とするところを、あらかじめ iptables -N log-accept iptables -A log-accept -j log <logターゲット関連のオプション> iptables -A log-accept -j accept などという「ログ取得してからaccept」という処理を行うユーザ定義チェインを作成しておいて iptables -A INPUT <条件> -j log-accept という感じで処理してやれば、syslogにどんな通信が処理されたのかログが残ります。 ・-L -vオプションを活用 上記いずれも実施困難な場合(手っ取り早くどうにかしたい場合も含む)、 iptables -L -v というオプションを活用しましょう。どのルールにどれだけのパケットがマッチしたのか っていうカウンタが表示されるのが -Lオプション単体のときと異なります。 むしろ、-Lオプションって、必要とされる情報が中途半端にしか出力されないので、 単体で使っても大した意味ないと思ってたりしてます。 ・むしろ一旦iptablesを無効に iptablesのfilterテーブルにおける処理が原因で問題が起きてるのか否か、を、 一番手っ取り早く切り分けるための手段です。 別途ファイアウォールで保護されており、iptablesを一時的に無効にしても セキュリティリスクがほとんどない環境なら、これが一番手っ取り早い というあたりを考慮した上で、実際にどんなルールを追加すればいいのか考えましょう。 | ||||||||||||||||||||
|
投稿日時: 2005-03-06 13:03
いま、少しテストしてみましたが、22番ポートのみで問題なく利用できます。私としてはどの段階で失敗しているのか少し整理した方がよいのではないかと思います。 たとえば、sshd の設定はあっていますか？(AllowTcpForwarding yes) ログインする sshd のサーバからリモートのサーバへ ping は出来ますか？ ログインする sshd のサーバからリモートのサーバへ telnet + ポート指定で接続は出来ますか？ | ||||||||||||||||||||
|
投稿日時: 2005-03-06 16:45
こんにちわ．
iptables 云々の前に， まず ssh がちゃんと使えてるんでしょうか？ 水無月様ご指摘のように，iptables の基本的な話の前にまず， sshd がちゃんと動いていて， 更に port forwarding を受け付ける状態であることからはじめるべきかと． 「接続ができる」のが「login できた」だけなのか， 「操作も出来るし，localhost の service に接続できる」のでは 話が違うでしょう． まず teraterm を利用して ssh で login して， その状態で pop3 が使えるのか？を確認されては？ 個人的には， localhost 向けの通信まで「削除」してしまって良いのか？と思ってますが．．． 一般論を云々する話なのか？とも思いますが．．． | ||||||||||||||||||||
|
投稿日時: 2005-03-06 17:12
見れば分かるように、切り分け手順を書いてるわけですから、 役に立たない返信をしているつもりはありません。 それとも、その場その場の解決を目指す返信のみがここではOKで、 今後にも役立つようにと思った内容を返信することに何か問題ありますか？ 的外れだったり間違ってる点があるなら、具体的に示して批判してください。 それとも斜字にしたりコメント化すりゃ何でも言ってもいいとでも思ってますか？ | ||||||||||||||||||||
|
投稿日時: 2005-03-06 21:25
PM でいただいていないのですから，ここで続けてよろしいのですね？
以前も同様のお話をしたと思いますが．
そのようにお考えになるのも， 自分のように考えるのも自由ではありませんか？ 自分は「iptables の基本の何たるか？」を説く必要はないと思いました． あなたの知識や経験が深く広いのは十分わかっています． が，別スレでも書かせていただいたように ※おそらくそこ繋がりの返信なのだと邪推してますが 「書き方考えられないか？」という話もあるんです． そう考える事自体，自分の個人的趣向に影響されてるんでしょうけど， 単なる「智者の傲慢」になっていると看て取れるんですよ．
斜めに書いたのは，それでも「直截的に書かないほうが良い」との配慮です． 正面切って「一般論唱えても答え見つからないでしょ？」とか 「そんなに知識を披瀝したければ別スレ立てて教示したら如何か？」 とでも書いたほうが良かったですか？ 改めて書くことになりますが， ※既にお忘れかもしれませんが あなたの書き方で不愉快を感じる人間もいるのです． ご自分が「不愉快」と感じて憤激するのと同じように． さらに，あなたの能力を惜しみます． 最後のが最も自分の気持ちの強い部分です． どう受け取ろうとあなたの自由ですが， こちらがどう書くのも感じるのも， あなたに拘束されたり従属したりする義理は感じません． 悪しからず． ＊＊＊＊＊＊＊閑話休題＊＊＊＊＊＊＊ 失礼しました -> kage様 ちょっと気がついたことを． ssh がちゃんと機能しているか？を確認することを指摘させていただいていますが， それと同時に server 側が 2005/tcp をちゃんと listen していることは 確認済みですか？ pop3 client -> ssh client -（ssh で tunnel）-> sshd -> pop3 daemon の流れのなかで，どの辺で「繋がらないのか？」で， 話の論点が変わってくると思います． 少なくとも ssh で port forwarding するなら， 性質として ssh 以外の通信を許可しなければならないのは理屈に合いません． ところで，
と，最初の書き込みの
は話の辻褄は合っていますか？ | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。