アカウント名:
パスワード:
確かこの欠陥が見つかった時も, SQLサーバを外部にさらすような使い方をすることはほとんど無いはずだから, 欠陥としては深刻だけど影響は少ないはずという論調があって, 私自身もその意見に同意していました.
でも結果は... 教訓!!バカはなめちゃいけない.
デフォルトでサービスをふさぐ方が安全なんでしょうが、ふさぐと今度は××が動かんぞー、と騒ぐ奴が山のようにでるんだろうな。逆に踏台にされているユーザは知らないだけに文句は言わない。なんか安全側にスイッチを倒してくれる望みは薄い気がするなぁ。
UDPでも単純なportフィルタリングなら可能です. UDPがTCPと比べてフィルタリングが難しいのは, 最初に接続の確立が行われないためであり, そのため内部からの接続要求か外部からの接続要求かの判断が難しいためです.
この程度の簡単な物なら, 例えばBINDであれば named.conf の query-source オプションを使えばいいんですが. サーバについても開けている口が分かっているので大丈夫.
一般的なUDPでの問題はクライアントですね. これについては完全ではありませんが, natや動的ファイアウォール設定を使うとか, 企業などではいっそのことUDPは完全に遮断というのも手かと思います. 業務では(ストリーミング等を使わなければ)UDPで必要になるのはdomain, ntpとsnmp程度ですし, これらはファイアウォール上のアプリケーションproxy経由で接続できますから, クライアントに対してUDP接続の制限を行ってもそれほどの不興をかわないのではないかと思います.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
IISをターゲットとした、CodeRedとかならともかくなんでこんなにはやるんでしょう?
とりあず、外部に公開する必要のないサービスはふさいで起きましょうよ。ほかの人にも迷惑かけちゃうんだから・・。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:2, 参考になる)
確かこの欠陥が見つかった時も, SQLサーバを外部にさらすような使い方をすることはほとんど無いはずだから, 欠陥としては深刻だけど影響は少ないはずという論調があって, 私自身もその意見に同意していました.
でも結果は... 教訓!!バカはなめちゃいけない.
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
マーフィーの法則だったっけ?
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
デフォルトでサービスをふさぐ方が安全なんでしょうが、ふさぐと今度は××が動かんぞー、と騒ぐ奴が山のようにでるんだろうな。逆に踏台にされているユーザは知らないだけに文句は言わない。なんか安全側にスイッチを倒してくれる望みは薄い気がするなぁ。
の
無料でくばったり (スコア:2, 興味深い)
向上の一環として製品の無料配布をやめるとかになったりして。
わらしはMSの競合会社につとめてるものですが、W2kとかSQL鯖とか
突然、自宅に送ってこられたりしたことがあります。ありがたく
つかわせてもらってますが(制限の範囲内でって意味ですよ)。
life is too short to hate each other.
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
だけど実際こうなっているってことは信じるしかないんだろうなぁ。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
なんてのがありそうですな。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1, 参考になる)
もちろん感染サーバのほとんどがMSDEを使用しているかなんてことは判りませんが、#243430 にある通りMSDEはパッチ適用条件であるSP2をCDからでのみしかインストールできないものがあるんですよ…。
#同条件サーバに覚えがあるのでAC
#でもイントラサーバだから慌ててないけど
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
やっぱり CD からのみのインストールなんですね。
セキュリティ強化するって、片手落ちじゃないですか > MS
これで対応が遅れる(できない)サイトが、
ずーと攻撃し続けるのか。
迷惑だから Windows サーバを公開しないでほしい。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
セキュリティ意識と購買権限は関係ないと思われ。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
> 今度は××が動かんぞー、と騒ぐ奴が山のようにでるんだろうな。
います。先日セキュリティに配慮せよとの命を受けて
「じゃあFirewallで空けてよいポート選んでください」といったら
デフォルトの/etc/services のようなリストが届きました。
聞くと今まで動いてた
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
DTS(Data Transformation Service) [microsoft.com] でインターネット越しにデータを授受する、ってのはどうでしょう?
・本社-営業所間のデータ同期
・自社-取引会社間でのデータ同期
・ウェアハウスへのデータロード(普通はLAN内で行うものでしょうが…)
等、結構便利です。前提条件として、データ送信元/先の両者が直接接続できる必要があったと思います。
DTSを利用するにしても、VPN越しに行うのが普通だと思いますが。
他では、インターネット越しに取引会社のOracle等をマウントして(ゲフンゲフン)、というのもアリかもしれません。
最近 SQL*Server では遊んでないので間違いがあるかもしれません。鵜呑みにしないでくださいね。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
は限ってますが、相手が感染しない保証なぞマッタクないわけで。
今ごろ大騒ぎになってないことを祈るっす。合掌。
みんつ
1つあるのは (スコア:1)
コストと時間を考えて、そうするところもあるんじゃないんでしょうかね。1台のマシンにWebとDBが入っていれば、マシンもOSも1台分で済みますし、アクセス少ないうちはパフォーマンス的にも有利ですし。2台に分けちゃうと、OSとマシンが2つ必要になりますし、Firewallも入れなきゃとか、色々とお金も時間も掛かりますから・・・
金の問題ならLinux使えって話しもありますけど。
そんな手抜きだとしても、ルータでPORT閉じていればいいんですけど、閉じない理由は、無知だからってのが一番大きな理由かと・・・
あと、SQLサーバのネットワークの設定として、デフォルトで名前付きパイプとTCP/IPが動いちゃうはずです。せめてTCp/IPをはずしてくれるといいんですけどね。SP3では閉じてくれるのだろうか・・・例のセキュリティ重視にMSが変わってからのSPですから・・・どうなんでしょ・・・
Re:1つあるのは (スコア:0)
無理です。
新機能よりセキュリティですが
機能がなければ価値そのものがなくなってしまいます
削る事マイクロソフトの死を表します。
Re:1つあるのは (スコア:0)
Web サーバ、DB サーバ間の通信用ポートは lo でしか開かないようにすればいいだけの話なんじゃ?これなら追加コストは0
Re:1つあるのは (スコア:1)
ドメインソケットみたいな通信方法はないのだろうか?
Re:1つあるのは (スコア:0)
>ドメインソケットみたいな通信方法はないのだろうか?
そういうものを使えば使ったで「独自技術はけしからん、すべてTCP/IPにしろ」と叩かれる罠。
Re:1つあるのは (スコア:0)
と上に書いてあるが
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
なぜ全開にしているか興味あります。
理由がしりたいですはい。
突っ込むつもりではないのですが (スコア:1)
honey pot ではないかと
---- sinbo
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
便利を選択すれば攻撃され、安全を取ると使う意味すらない。
時代は終わったのかもなぁ(遠い目)
#もうなかった事に...
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
単純なフィルタリングの話なら、「全部閉じて必要なポートを開ける」はTCPでは可能ですが、UDPでは障害が発生します。その理由はUDPの特性及び(通常の)スタックの実装にあります。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
UDPでも単純なportフィルタリングなら可能です. UDPがTCPと比べてフィルタリングが難しいのは, 最初に接続の確立が行われないためであり, そのため内部からの接続要求か外部からの接続要求かの判断が難しいためです.
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
うーん、ちょっと違う。
> UDPがTCPと比べてフィルタリングが難しいのは,
...
> 接続要求かの判断が難しいためです.
こちらは結構です。
bind()をしないUDPの送信は、使用されていない適当なポートが使われる事を思い出してください。例えば、DNS(UDP53,domain)が動いているとして、
local:domain、remote:any
local:any、remote:domain
あるいは、
local:domain、remote:non-priv
local:non-priv、remote:domain
のUDPの通過を指示してやる必要がありますが、リモート側がdomainでUDPを送って来た場合、ローカル側の全ポートor非特権ポート全て宛のUDPパケットを通過させてしまいます。それがイヤなら、上の通過ルールを削るしかありませんね。ならばDNS使用不可という障害が発生です。
まあ、ポート1434がバインドされていて、外部からのポート1434宛のUDPを遮断する、は出来ます。そういうルールを前の方に入れてやれば。しかし、中にはローカル側が不定のサービスもあって(範囲は決められている場合もある)、更に常にバインドされているとは限らないもんもある訳です。となると、フィルタリングなんか出来ませんし、無理にやれば真っ当なサービスに通信障害が発生します。
これが単純なフィルタリングの限界なのです。
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
プロトコルであるはずですから、sourceポートがたまたま1434に
なった場合は全てfailということでいかがでしょうか。
destinationが1434になるという状況は、MS SQLからのアタック
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:0)
query-source-port が たまたま 1434 に
なっちゃっていたりしたら...
destination 1434/udp 無条件破棄すると
かなしい結果になりそうですが(苦笑
Re:・・・・不必要なポートをふさがないのはなぜ? (スコア:1)
この程度の簡単な物なら, 例えばBINDであれば named.conf の query-source オプションを使えばいいんですが. サーバについても開けている口が分かっているので大丈夫.
一般的なUDPでの問題はクライアントですね. これについては完全ではありませんが, natや動的ファイアウォール設定を使うとか, 企業などではいっそのことUDPは完全に遮断というのも手かと思います. 業務では(ストリーミング等を使わなければ)UDPで必要になるのはdomain, ntpとsnmp程度ですし, これらはファイアウォール上のアプリケーションproxy経由で接続できますから, クライアントに対してUDP接続の制限を行ってもそれほどの不興をかわないのではないかと思います.