Sponsored Link

過去ログ



 戻る      101〜110  111〜120  121〜130  131〜140  141〜150  151〜160  161〜170  171〜180  181〜190  191〜200

ひとつ未来へ              ひとつ過去へ


120.RE[4]: iptablesのDNS

投稿者: Pyzar - 2003年06月15日 0時36分40秒
ホームページ: http://www.geocities.co.jp/SiliconValley-SantaClara/1792/redhat/iptables.html

> モデムがDNSキャッシュサーバーとして動いているならルータはモデムから貰うようにすればいいんだと思うけど
> (ただしモデムでDHCPのDNS配信機能を有効にしないとモデムからは取得できなかったりするかも?という気もしないではないけど)

あっ、ルーターのDHCPは切りました
だからかな??

とりあえず、iptablsesの設定、再度更新しました
コメント>>

118.そうそう

投稿者: ぴゅあ - 2003年06月14日 23時26分58秒

 2段NATのときはある程度NAT頼りではなくプロクシに任せた方が軽くなるよなぁ?と思ってプロクシの復帰も検討してたけど
 2段NATをやめてうまく行ってから復帰の可能性はかなり減ったかも
 ので使ってないけど
 キャッシュプロクシという意味では(DNSがそうだし(キャッシュ)NTPがそうだけど(これは単なる中継か))squidとか復活させるかも知れないししないかも知れないし(キャッシュすることによる使い難さも出なくはないし・・・というかそれはIEとかクライアントの問題なのかもしれないけど)
 少なくとも今のとこプロクシを入れることによるマイナス効果(パケットの遅延/トラフィック)の方が大きそうで

 そういやiptablesのNAT機能を使って透過プロクシに挑戦してみるのもいいかもよ
 iptables+squidでの透過プロクシとかの例もあると思うので(対Delegateもあると思うけど)参考にするとうまく行くでしょう

 FTPのAuth/IDENT問題はまぁ我慢すればいいだけのことだけどアクティブモードでまだちと不安定なのがなんとかしたいとこだけど
コメント>>

117.RE[3]: iptablesのDNS

投稿者: ぴゅあ - 2003年06月14日 23時18分00秒

 エアコンの掃除した
 空気が綺麗になったかどうかは・・・
 不明(照)

 両方開けないといけないのかなぁ?
 モデムがDNSキャッシュサーバーとして動いているならルータはモデムから貰うようにすればいいんだと思うけど
 (ただしモデムでDHCPのDNS配信機能を有効にしないとモデムからは取得できなかったりするかも?という気もしないではないけど)
 ルータ,クライアントの設定に問題はないのか?というのもあるかも
 クライアント・・・ルータのアドレス
 ルータ・・・モデムのアドレス
 モデム・・・プロバイダのアドレス
 今の構成ではこうなるのかと
 うちは2段NATをやめて・・・というのには関係なくだけどこうしてたかなぁ?
※単純にクライアントでプロバイダのアドレスを設定できる(全てがルータの存在を意識しないでいい設定ができる)環境になったけどキャッシュの意味でそうしている

 因みにINPUTは必ずESTABLISHEDになる筈なんだからそれを明示するのがいい気も

 ホントにその設定がうまく生きているのかというのもちと疑問に思えなくもないので気になるならそれぞれのログを採って何処を流れているのかを確認してみるといいでしょう

> クライアントPCでブラウジングしていると・・・
 ホントにブラウジング(という言葉は何度も使おうと思ってホントに適しているか?と思って使わないようにしてたりするが@ホントは使いたいと思っている)中でしょうか

 実際それがどうなのかは確認していないけど(ブロックしているからログに出ているので気にしてないが)
 明らかにDDoSなり(に当たるのかそれらしい記事は目にしてはいるけどそんなちゃんと読んでないので(照)DNSに対してもそう書いてあったような気がするというだけ)のアタック(無差別?)だろうと思われるのが(暫く目立たなくて気付かなかっただけなのか)最近また増えてるみたいではあります
 こちらのDNSアクセスによるものではないだろうと思うんだけど

 パターンは8つのアドレス(固定ではあるが対象の発信元はまちまち(ルーマニアのだったりモロモロ))が一気にで10秒ごとにICMPx2とDNSx2のパターンが3時間ごとくらいだったりするのかな(3時間というのは順番がくるまでマチマチだろうが)
 てなパターン化されているので特に問題ないんだろうなと
 ログが流れてしまうのがぢゃまだけど

 前にも書いたけど
 最近見ないのに如何にも「踏み台プロクシ探してますよ」なのもあったのでプロクシ使っているならいちお頭に入れておいても損ないかもが
・httpサーバーのポートである80
・CodeRedとかNimdaとかに大袈裟に騒ぎ捲くっている人たちが回避と称して変更したとか言ってるポート(*1)
・squidが使うポート
・Delegate等一般的にhttpプロクシで使われているようなポート
が探られてたりはしました

*1:
 大騒ぎしている割には(しているから?)対処が安直で(問題ないと言われても心配になる気持ちは判るけど)ポートの変更をして安心してしまっている
 尤もターゲットとなりうるIISとかは存在しない環境なのが殆どなのだろうからいいだろうとしても
 もしIISが存在して止めてあるつもりだと知らない間に動いていたとしても気付けないことにもあるのではあるけど

 うちは誤って漏れ出さないためとエラーが出てないかとかの通常のログが見難くなるのを回避するためにhttpサーバーの機能を使って簡単に余計なログを分離してたりする
 (お邪魔虫を拒否するんでなくて誘い込むことで回避@一種のDMZ的手法でもあめのかな?)

 あぁ 洗濯は明日にしよ
 少しずつは解説書いてるけどなぁ
 なんか寝てる気もするからあんまし進んでないし
 狐もちっと叩くの減ってるゎ(謎汗)
コメント>>

116.RE2: iptablesのDNS

投稿者: Pyzar - 2003年06月14日 20時51分15秒

現状、53番ポートはプロバイダのDNSサーバーとルーターのDNSサーバーについてのみ開けてあります。

# IP map
F_DNS=***.***.***.**1
S_DNS=***.***.***.**2
ROUTER=192.168.0.1
WAN=192.168.0.2
WAN_NET=192.168.0.0/24

# router dns
$iptables -A INPUT -p udp --sport 53 -s $ROUTER --dport 1024: -d $WAN -i eth0 -j ACCEPT
$iptables -A OUTPUT -p udp --sport 1024: -s $WAN --dport 53 -d $ROUTER -o eth0 -j ACCEPT
中略
# provider dns
$iptables -A OUTPUT -p udp --sport 1024: -s $WAN --dport 53 -d $F_DNS -o eth0 -j ACCEPT
$iptables -A INPUT -p udp --sport 53 -s $F_DNS --dport 1024: -d $WAN -i eth0 -j ACCEPT
$iptables -A OUTPUT -p udp --sport 1024: -s $WAN --dport 53 -d $S_DNS -o eth0 -j ACCEPT
$iptables -A INPUT -p udp --sport 53 -s $S_DNS --dport 1024: -d $WAN -i eth0 -j ACCEPT

ルーターもDNSサーバーも開けておかないとクライアントPCでブラウジングが出来なくなります

本題なのですが…
で、クライアントPCでブラウジングしていると、
たまに、ルーターでもないプロバイダのDNSサーバーでもない
IPアドレスの53番ポートと話をしたがるんですけれど…
ブロックしたよとログが出て…
別にブラウジングにも支障はないのですが…
これが気になっていたのですが…

ひょっとして、クライアントPCがブラウザで閲覧しているサイトから最初の指示が出ている??
コメント>>

115.全く 同感です!!

投稿者: Pyzar - 2003年06月14日 19時45分34秒

>  なんで信頼されていないのは拒否されるかってのも各自がサーバーを立てようとしたとき(とまで行かなくても単にインタネに繋げたいと思っただけ
> でも)まず攻撃対策とか言って(間違った解釈だとしても)躍起になっているくらいなのに
> ぢぶんが信頼されないのは何故?と考え込み悩み方が変ぢゃないのか?と思ったりするけど
> どうかな?

> 直接実験したわけでもないので正確なところが掴めてるわけでもないけど(といい加減な人たちは試してないなら言うなと反撃してくるもんだが)
> 少なくともそのプロバイダに接続した上でそのプロバイダへSMTPサーバーを向けるのなら可能性はあるけど
> 基本的にはメールクライアントから接続されることを前提として設定されている筈
> (それでもPOP before SMTP等のセキュリティ対策を「色々と苦労して考え」て運営している)
> だからSMTPサーバーを使っての接続は拒否されてもおかしくはないとも言えるんではないかと思ったりする

ただ、ふと…回避策ないかな…と思ったりして、云々したりしてる…
コメント>>

114.RE: iptablesのDNS

投稿者: ぴゅあ - 2003年06月14日 18時22分13秒

 それでいいのかな?

> INPUT -p udp --sport 53 -s ???? --dport 1024: -d $WAN_IP -i eth0 -j ACCEPT

 eth0は外側ルータ側だったよね?
 と-sはプロバイダのDNSサーバーアドレスだろうから????となっているのでその意だろうとしてOKとして
 -dは$WAN_IPかな?
 外側ルータにはNATが入っていると思うのでプライベートアドレスになっていると思うんだけど?(でもって宛先はeth0のアドレスになっていると思う)

> INPUT -p udp --sport 53 --dport 1024: -d $WAN_IP -i eth0 -j ACCEPT
 とすると・・・というよりまず内部ルータから要求を出すのが最初なので前にも言ってるESTABLISHEDだけでカタが付くとも思うんだけど
 --sport 53は先にOUTPUT --dport 53でプロバイダ側に問い合わせたことに対する応答のときに来るもので合っているし
 --dport 1024:はOUTPUT --sport 1024:に相当するものの自DNSサーバーが適当に付けた1024:のポートがそのまま返されてくる(自DNSサーバーが発したどのパケットにマッチするかを判断するため)ので合っているし
 でもってDNSに対するアタックは--dport 53としてくるのでこれは弾かれるけど
 絶対に安全とは言えない・・・ということより相手DNSサーバーが判っているのだから&特定のサーバーにしかアクセスしないので-sを省略しないのが「他のセキュリティホールが見つかったとき」のことを考えても神経質にならないで済む安心なんだろうと思うけど


 さて
 昨日雑貨屋?でエアコンのお掃除スプレー見つけて買ってみたし
 エアコン掃除してみるかな
 効率上がるし電気代節約になることは間違いないし
 ってこれから夏に向けて電力不足の心配・・・とかってのはなんか(毎度やっぱりのような?またちと騒ぎたかっただけなのか?)静かになってるみたいだけど・・・ってわけではないけど
 テレショップでよく出てくる熱湯(てか霧ってのか)クリーナがダイエーで売ってるの見掛けてホントに効果あるんかな?(あるとやっぱ嬉しいもんだが)と思ってたのを思い出したりしたけど

 おなかすいた
コメント>>

113.RE: postfixのスレッドから…

投稿者: ぴゅあ - 2003年06月14日 17時56分49秒

 617で終わっているでしょ

 でも・・・
 最初の着眼点から間違った思い込みをしてしまっているという気がするんだけど・・・

>  552 sorry, your domain isn't in my list of allowed senderhosts (#5.7.1)

> 弊社ドメイン名( pobox.ne.jp など )がFrom行に存在しない場合は、
> メールを送信できないように設定しております。

・DNSの設定は問題ないのに
 確かにSMTPサーバーで…という点では絡みがあるのかも?知れないけど(不明)
・固定IPが1つしかないから特殊
 というのも大きな勘違いではないんでしょうか(と思うんだけど)
 ドメイン名・IPアドレスというのは住所であって各サーバーというのは部屋みたいなもの(アパートとかではなく一戸建ての)ってのは前に書いたですよね

 とかなので違った方向で嵌っているんではないのか?とか思ったりするけど
 とここで言ったところで仕方はないが

> ネームサーバーの再設定でこの人は解決できたのだろうか??
 それは・・・
 掲示板でも当然の如くある「悩んでいる間は必死だから一生懸命書くが解決したら終わり」
 ってのはMLでもやはり同じだったり
 だから掲示板然りML然り折角の場が死んでしまってるんですよね
 のでそういう場作りをやめてしまったりフォローに嫌気がさしてしまったり
 (嫌気がさす方が悪いと言う人に限ってそういう質問の仕方してたり ってのも)

 何度も各所で言ってたりしてたことでもあるけど
 某NIFTY掲示板ではぢぶん以外のレスする人には敵対感丸出しであったりして
 一切フォローしないことにしたってことも何度もあるけど
 (て その後絶対正しいとは限らないから反論や嫌がらせメールは一切不可とか言いつつ続けてたりするし@そう言った人たち)
 今はみんなはこういったことで悩んでいるのかといった情報収集だけに利用させてもらってるけど
 それくらいしか使い道ないし 今は(相変わらず?)

 メッセージで出ているdomainというのが送信者のメールアドレスのことをいっているのか(Puzarさんの挙げてくれた解説文ではそういうことになっているでしょ)
 送信元SMTPサーバーが相手SMTPサーバーに未登録のサーバーだからと言っているのか
 その辺が定かではないけど

 前者だとしてMLでも特定のプロバイダのサーバーに対して拒否されていると言っているだけで送信者のメールアドレスが何を使っているかは書かれていない
 ここに他のプロバイダのメールアドレスを書いていると拒否されたりするでしょう
※DoCoMoの携帯メール宛にcomドメインのメールアドレスで送信すると拒否されるらしいとか
 受信者側で許可設定しないと受信できないらしい
 ってのもある

 後者だとするとドメインは取得してるんだろうから
 ってかhttpとかアクセスできるっていうんだからインタネ上ではそのドメインは生きているということ
 つまりDNS云々は問題ないんだろう(と思う)(終始それが話題になっているが)
 しかし前にもちらっと出てきているけど(Pyzarさんから)SMTPサーバーに限らずどのサーバーと信頼関係を持つかという設定はあるのだから取得したドメインが「そのプロバイダの(或いは個人でもそのサーバー内の)サーバーで受け入れを許可」してなければ拒否されてもおかしくないだろう
 ってのもある
 DNS云々ていうのは「その相手とする特定のサーバー」に限ってのものではなくインタネ全体が対象であるから「DNSに問題なさそうなのに」というのはちと外れてるんぢゃないのかな?ってところ
 尤もSMTPサーバーのための設定というのも含んでいるだろうから(ハッキリとしていないだけでそんな風なのを見たことあるのであるだろうという話)全く無関係とは言い切ってしまわないことにするけど

 なんで信頼されていないのは拒否されるかってのも各自がサーバーを立てようとしたとき(とまで行かなくても単にインタネに繋げたいと思っただけでも)まず攻撃対策とか言って(間違った解釈だとしても)躍起になっているくらいなのにぢぶんが信頼されないのは何故?と考え込み悩み方が変ぢゃないのか?と思ったりするけど
 どうかな?

 直接実験したわけでもないので正確なところが掴めてるわけでもないけど(といい加減な人たちは試してないなら言うなと反撃してくるもんだが)少なくともそのプロバイダに接続した上でそのプロバイダへSMTPサーバーを向けるのなら可能性はあるけど基本的にはメールクライアントから接続されることを前提として設定されている筈(それでもPOP before SMTP等のセキュリティ対策を「色々と苦労して考え」て運営している)だからSMTPサーバーを使っての接続は拒否されてもおかしくはないとも言えるんではないかと思ったりする

 因みに先の怪しい知り合いはうまく動かしているらしい(当然メールプロバイダは他社だろう)


 前に消えてしまって・・・というのは思い出したけどまた今度気が向いたらにしよう
コメント>>

112.iptablesのDNS

投稿者: Pyzar - 2003年06月14日 17時45分57秒

$iptables -A INPUT -p udp --sport 53 -s ???? --dport 1024: -d $WAN_IP -i eth0 -j ACCEPT

現状、ルーターとプロバイダのDNSサーバーにだけ開けているけれど…
$iptables -A INPUT -p udp --sport 53 --dport 1024: -d $WAN_IP -i eth0 -j ACCEPT
としちゃっても問題ないのだろうか…
コメント>>

111.postfixのスレッドから…

投稿者: Pyzar - 2003年06月14日 16時31分50秒

http://www.kobitosan.net/postfix/ML/archives/msg00575.html
ネームサーバーだのMXだの…難しい…
で、結局…
http://www.kobitosan.net/postfix/ML/archives/msg00616.html
でこのスレッドは終了…
ネームサーバーの再設定でこの人は解決できたのだろうか??

まっ とりあえずiptablesかな
コメント>>


トップへ     101〜110  111〜120  121〜130  131〜140  141〜150  151〜160  161〜170  171〜180  181〜190  191〜200


ひとつ未来へ              ひとつ過去へ