- - PR -
管理者泣かせのソフトウェア
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-01-06 12:26
上記スレッドを見てみましたが、このスレッドで議論し尽くされている内容ですね。
ちと、softetherのパケットを研究してみたいですよ。 ## 意欲も環境もある。ないのは時間だけ 
| ||||||||||||
|
投稿日時: 2004-01-06 13:15
がるです。
…絶望的雑感を軽く。 あちこちでSoftEtherの発言を読んでいるのですが。 概ね ・利点のみを追いかけて問題点をほとんど見ていない ・そもそも問題点がわからない ・利点を利用(悪用)したいので問題点をあえて踏んでいる という方向性が現在の主流なのかなぁ、と。 ここで議論している(恐らくはネットワーク管理者の)多くの 人たちが予想している「最悪の事態」が、認識できないか、 或いは「自分は関係ない」か、どちらかなのでしょう。 # そしてその責任は管理者に擦り付けられる、と。 ちっと、怖い考察を。 ずっと暖めておいたのですが、途中経過ってことで軽く公表 してみます。 内容は"SoftEtherをより「便利に」する方法" ・ルート偽装 「常に(公開)HUBへTCP通信する」状況を偽装する。 具体的には、SoftEther(改)をつかっている別クライアントへ 通信してクッションをかけることで、TCPのあて先をランダムに 変化させる。 一定パケットごとにクッション先を変更していくことが望ましい。 ブラックリストが作成されたときにその回避方法となる。 ・コネクション偽装 一定時間ごとにTCPコネクションを切断する。あるいは一定 通信量ごとに、通信を一時的に止め、自動再開させる。 これにより、接続時間、通信量によるフィルタを回避する。 ・パケットかく乱 現在パケットの先頭にある固定文字をランダムにする。 これにより、パケット解析によるフィルタを回避する。 ・プログラム名かく乱 自身のプログラム名を定期的に、或いはユーザの任意で変更 できるようにする。 これにより、クライアントプログラムのプロセス名による フィルタリングを回避する。 ・インストールチェックかく乱 インストールにレジストリを用いず、単純にファイルの解凍のみとする。 これにより、クライアントプログラムのインストールブロックを回避する(Administratorでなくても簡単にインストールできる)。 ---------- などなど。 この手のモノを黒く考えればきりがないですな。 っていうか、この辺までの変質を予想した上で「だから嫌なものが でたなぁ」という雑感が生まれるわけなのですが。 上記までを視野に入れてセキュリティ対策を考えているわけなの ですが…これがなかなか難しい。 突っ込みその他、入れていただけるとありがたいです ＞ みなさま | ||||||||||||
|
投稿日時: 2004-01-07 11:37
SoftEtherって要は仮想NICを構築するソフトだということで
複数のIPを持ってる端末をログインスクリプトではじくとか レジストリを定期的にスクリーニングして複数のNICを持ってるクライアントを検出するとか この程度ならスクリプト組む程度で対応できるのであんまり問題ないのでは？ この対策が出来ない組織ってadmin権限がユーザーにしかなくワークグループで管理してる組織ということになりますが、さすがにこんな運用ではやりたい放題になって当たり前かと。 まぁ、レジストリを使わないようになると厄介でしょうが、その場合、仮想NICは作れないので、ネットワーク的な脅威にはならないかと というより、そこまで社員を疑うなら、もうリムーバブルメディア一切禁止、PC持ち出し厳禁、分離ネットワークってことにするとか、そういう手段が必要だと思います 結局、この手の対策はコストと被害と可能性と利益の問題なんで、完璧ってのは無理では？大抵、自分でこうやれば崩せるだろうな、でも、それを防ぐコストは掛けれないって案件がほとんどの様な気がします。 どこで妥協するかって事になるかと・・・・・・・ | ||||||||||||
|
投稿日時: 2004-01-07 13:42
ども。がるです。
投稿数１の人がよくこのスレッドでこういった主旨の書き込みをしている ように感じるのは気のせいかなぁ、とかかるくぼやきつつ。
んと。まず「複数IPを持っているからNG」という対応は非常に 難しいと思われます。 普通に必要で複数IPを持っているケースも多いですし。 かつ、ここにいたるまでに 「有効なスクリプトを組んで」「それを各クライアントに配布し」 「そのスクリプトがきちんと動いていることを確認し」という 複数の手間が存在しますので。 一部の方には耳たこで恐縮ですが。コスト、という単語をもう少し 真摯に考察することをお勧めいたします。
ですね。 つまり、今まで「ある程度モノをわかっていないとF/Wがすり抜け られない」環境であれば、お目こぼしもありだったのですが(いやまぁ 私がお目こぼししてただけなのですが :-P)。 一般社員が気軽にF/W抜けをできる、なんてこの状況になりますと、 不本意ながらそこまで硬くせざるを得ない、という選択肢の可能性が あると思ってます。 そーゆー面倒をしたくはないんですがね。
図らずしもMERCYさん自身が述べているように。 今回のSoftEtherのせいで「可能性」が極端に跳ね上がってしまっている のが、最大の問題です。 そして「コストをかけずに確実に」って考えると、わりと短絡的に 向かうのが「じゃぁThe Internetを使えなくすればいいじゃないか」 という話になります。 線一本引っこ抜けばよいだけなので、簡単ですし :-P # 前にも書きましたが。一部の経営者は「The Internetが使えないこと # による弊害とその弊害のために発生するコスト」には目が向かない # モンです。困ったことに。 そーゆー状態になって困るのは果たして誰なのでしょう？ # いやまぁ無辜の一般社員という話があるのが非常に憂鬱なのですが。 この辺の議論ってもう@ITでは語りつくしたような気がするのですが。 一応書き込みをしておきます。 | ||||||||||||
|
投稿日時: 2004-01-07 14:38
クライアントに配布というのは、Windowsをドメインで管理していれば、ドメインのログオン時に配布することが可能ですし、どの程度の判定を行うかにもよりますが、ただのデータ収集であればipconfig /allのコマンドを発行してネットワークドライブに書き込む程度で問題ないでしょう。 ドメインを使用してない場合は配布がちょっと面倒ですが、その場合adminのパスワードがわかるのであれば、ゆっくり動くプロセスをサーバで立ち上げて、アドレスの存在確認をしつつ、レジストリのデータを保存していけばユーザーにはほとんど迷惑がかからないですし その後にちょっとしたスクリプトを書いて、判定し警告するという作業にそれほど膨大な手間（コスト）はかからないのではないでしょうか？ それに、複数のNICをつけたマシンが一般的に存在する状況というのもかなり妙な構成ですし、普通２つあるということであれば、３つのマシンを判定すればすむでしょう 最低１つは自社で使用してるIPがある訳ですから、そのIPとの組み合わせを判定しても良いですし この程度の作業であまり詳しくない一般的な人の使用に関してはほぼ把握できるかと思います。 一回書いちゃえばその後結構長く使える物ですし、まぁ、かなり長めに見てもスクリプト作成に一日、その後は週に１時間も有れば怪しいクライアントの判定を行えるのではないでしょうか？ ま、チェック間隔は一月位でも良いでしょうし、そうすればもっと楽に出来るでしょう。 | ||||||||||||
|
投稿日時: 2004-01-07 15:16
ども。がるです。
んと、MERCYさんの手法がわからないわけではないのですが、 気がかりな点がいくつか。 1.Windows系OS各種の違い この辺は私も無知なので純粋に不明な部分もいくつかある のですが。 ipconfigの出力結果とかレジストリの「どこに何が入っているか」 など、全て共通なんでしょうか？ なんかむか〜〜しに、その辺の不一致で結構苦労した記憶が かすかに残っているのですが。 そのあたり、もしご存知な情報があれば書き込んでいただけると。 で。 その辺の整合性とりで時間がかかるとすると、やはりコスト が結構膨大になりそうで怖いです。 # いっそ各OSごとのスクリプトを公開してみるとか ;-) # 結構重宝がられるかも、とか思いますがどんなもんでしょ？ 2.結局事後対処になる 悪い、というわけではないのですが。やはり「可能なら瀬戸際で ブロックしたい」という本音がまぁ存在するわけでして。 無論事後にせよ把握できることは非常に重要なのですが、実施から 把握までのタイムラグで何かが起こると…ってのも結構怖い予想が 色々とたちます。 ちなみに、その見解から
に関しては、少なくとも当分の間は一日一回以上のスパンでの 実施が必要かと思います。 まぁどっちにしてもAdminのパスワードとかその辺の洗い出しは、その 手前での急務ですが。 # 某お役所の「Administratorのパスワードが"設定されて"しまったので # 何も出来なくなった」などという怖い単語は二度と聞きたくなかったり。 ----------- そうそう。手法が不明なのでまだ半信半疑ですが。 http://www.netagent.co.jp/onepoint/ で、SoftEtherが防げるとか。 PacketBlackHoleを作ってる会社さんみたいなので、少しだけ期待しつつ。 ただ、保守サービスが初年度から必要でかつ値段が「お問い合わせください」 ってあたりが限りなく微妙ですが ^^; | ||||||||||||
|
投稿日時: 2004-01-08 10:52
おはようございます。
るぱんです。 ネットワークは詳しくないので未熟と思いますが、 お付き合いの程宜しくお願いします。 まず、自分の意見のスタンスから。 １．今回の問題は３つ議論のフェーズがある。 ２．悪影響の大きいと思われるツールは公開するべきではない。 ３．ましてや補助金を交付するべきではない。 ４．価値観の違いは有っても良い。 ５．技術的な側面からだけのアプローチでは片手落ちである。 ６．危険性を認識しない楽観論は論外である。 以上の観点ににたちます。 次に、３つの議論のフェーズから。 １−１．技術的に公開して良いものかどうかと言う議論 １−２．基礎技術として悪用される懸念にたいする議論 １−３．現場管理者としての対策の方法に対する議論 に分けられると思います。 １−１．に対する意見 →問題なく今回のケースでは公開するべきではなかったと認識 １−２．に対する意見 →ネットワークはそれほど詳しいわけではないので今後の議論に期待 １−３．現場管理者としての対策の方法に対する議論 →この点に関して重点的に述べさせて頂きます。 経営TOPの方の切り口からすると 危険＝すぐ手当て 手当てできるツールがある →購入すれば良い 手当てできるツールが無い →まず探してみろ 探した結果金額の多寡について意見が出るのは更に次のフェーズで良い。 という見方があると思います。 勝手に先回りしようとされる事の方を嫌がる上司って多くないですか？ 技術者サイドからすると、 得体の知れない物＝使いたくない と言う潜在意識に近い見方があると思います。 打開策として １．不安を経営陣に伝える ２．業者を呼んで話を聞いてみる が妥当な線ですよね。 危険性を認知しても経営陣にアナウンスしないと言うのはそれはそれで問題ですし、 ただ、聞いたからどうなる物でもないんですが、 耳に入れておけば責任は取らされる心配は無いのではないかと。 「今こんなの使われたら対応できません。 ついてはこういうのがあるので、検討してみますが良いですかね？」 って軽いアナウンスが有れば良いかと。（重たいと逃げられてしまいますから） セキュリティのいたちごっこの部分じゃないですか？ 予防対応に苦慮してる事だけ伝えて 後は定期的に進捗報告してれば良いんじゃないでしょうか。 技術者の傾向として 「全て自分で抱え込んでしまう」という事もあると思います。 非技術者の傾向として 「わからなければとりあえずやってみる」と言う事があるとも思います。 更に技術者サイドから 「一度導入した物についてはあまりいじりたくない」 と言う意識があり、 導入→結果不調→取り外し という考えが欠落する事があるのでは無いでしょうか。 評価版→結果によって導入、非導入の是非を探る と言う解決策も有りですよね？ 企業として「できます」と宣言してるわけですから、 話は聞く価値はあるのではないかと思います。 ただ、その際に、 １．SoftEatherについて技術的な下調べをする。 ２．話を聞いた際に手法と整合性を確認する。 とすれば良いかと。 ただし、上記の１の作業はかなりしんどいですよね。 コミュニティ作るか他の有志企業に当たって見て、 共同作業にしても良いのかな？と。 個人レベルでも良いと思いますし。 ただ、ネットワークの知識は結構必要なのかな？ 重要なのは「わからない事を素直にわからないと言う」事なのではないでしょうか？
| ||||||||||||
|
投稿日時: 2004-01-08 15:22
ども。がるです。
息抜きの合間に仕事をしている今日この頃(笑 るぱんさんへのレスになりますが、同意部分を書いていると長く なるので、コメントしたいところだけ記述します。 > ２．悪影響の大きいと思われるツールは公開するべきではない。 微妙ですね。いや本音では「やめて欲しい」と心の底から思う のですが。現実にこの辺を突き詰めると結構面倒な話で煙に まかれる事が多々あるので。 この辺は「ブレーキを用意する」という話の持っていきかたを するほうが、個人的には好みかなぁ、と。 # 過激な意見もいっぱいあるのですがとりあえずおいておきます :-P > １−１．技術的に公開して良いものかどうかと言う議論 に対する意見 > →問題なく今回のケースでは公開するべきではなかったと認識 実は「技術公開」は、私はしてもよいと思ってます。っていうか 今回の新機軸は「Etherの仮想化」の部分で、その辺については 興味がある人も多いと思うので。 もう少し掘り下げると。 技術公開で使える程度のスキルの人間を相手にするのは、まだ もう少し「本音で会話」ができるので楽なので(笑 > １−２．基礎技術として悪用される懸念にたいする議論 に対する意見 > →ネットワークはそれほど詳しいわけではないので今後の議論に期待 この辺の「悪用の仕方」は、ほかのホールも含めて、本来は活発に議論 されるべき内容だとおもいますねぇ。 確かに一歩間違えると非常に危険な議論でありログになるのはわかって いますが。 > 探した結果金額の多寡について意見が出るのは更に次のフェーズで良い。 > という見方があると思います。 基本的には、手段を見つけてから稟議書を通す時点で金額の話 になることが多いみたいですね。 私は発注を受ける側なので、稟議書は敵なのですが(笑 > 打開策として > １．不安を経営陣に伝える > ２．業者を呼んで話を聞いてみる > が妥当な線ですよね。 社内管理者としては妥当な線だと思うのですが…どんなもんでしょ？ ＞ 各位 私は基本的に呼び出される側なのでなんとも、ですが(笑 > 危険性を認知しても経営陣にアナウンスしないと言うのはそれはそれで問題ですし、 > ただ、聞いたからどうなる物でもないんですが、 > 耳に入れておけば責任は取らされる心配は無いのではないかと。 わりと大切ですね :-P メールであらかじめ送っておいて証拠を残すのも重要な手口です B-P > 更に技術者サイドから > 「一度導入した物についてはあまりいじりたくない」 > と言う意識があり、 > 導入→結果不調→取り外し > という考えが欠落する事があるのでは無いでしょうか。 微妙ですねぇ。現実にそこら辺にかかるコストが膨大になることも 多いので、ってのが片方に。 もう片方に「変更がある程度容易にできる程度に柔軟に」設計 できていない技術者のスキルの低さってのがもう片方に。 理想はテスト環境の構築だと個人的には思うのですが。 結構予算の関係で蹴られるんですよねぇ。 私は「自社でテスト環境」で外に売り込むので、そういう意味でも 重宝はされてますが。 > 企業として「できます」と宣言してるわけですから、 > 話は聞く価値はあるのではないかと思います。 企業によりけりですね。危ない業者も結構あるので :-P ただ、もしこの話がone pointの話であるとするのなら、あれは 一考の価値はあると思っています。 # いやまぁ本音を言えば誰か他に人柱がいれば…とは思ってますが :-P 資金に余裕があれば、テスト環境一式構築して購入まで全部やっちゃいたい のですが、なかなかそこまでは…ってのが現状でしょう。 とりあえず今は「使った結果の報告」がどこかのサイトに上がって こないかなぁ、と。 # ついでに、一応稟議書などあげてみたりはしてますが…通るかが微妙。 > 重要なのは「わからない事を素直にわからないと言う」事なのではないでしょうか？ 大事ですね。これは何によらず。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。