- - PR -
ASP.NETでの閲覧者情報
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-07-26 11:14
小僧 氏へ
※最寄の駅までの徒歩でびしょ濡れでスーツがしわに…
自分で補完しました。 なぜ、こういう風に補完したかというと ・ASP.NET ・<a href="ファイル名">○○○</a> ・ダウンロードするだけの単純なシステム というキーワードを元に補完致しました。 また ・どれをダウンロードするかはユーザの目でないと確認できない との事からURLの一覧だけではユーザ全員が必要の無いファイルまで 全部ダウンロードすることにはならないか？との考えから URLリストだけのテキストファイルでは無いと考えました。
確かにログイン機能などをつければ…などの意見など一蹴していたと思いますが、 これも、実際にはユーザ次第なのでは無いでしょうか？ 時間とお金の問題も含めて開発者が勝手に決められないのでは無いでしょうか？ 特に、時間とお金に関しては、開発者が勝手に時間とお金を掛けても、 ユーザの了承無しにはお金は払ってもらえないですよね？ （勝手に時間とお金を掛けてユーザから代金貰う方法があったら知りたいです）
こういった話自体は私も興味ありますし、その通りだと思うのですが、 そもそもの議題はこういったセキュリティ関連がメインでは無いと思います。 ここまでの話の流れを見て、また自分で補完しますが、 例えば、『ダウンロード数の制限』は言い換えれば 『IIS+ASP.NETでApacheのmod_limitipconnと同様の機能を持たせるには？』 という風な技術的な情報交換をメインで話し合いたかったのでは無いでしょうか？ これについては、現在ISAPIを作るという案とTCT/IPのパケットモニタのような機能で できるのでは？という案が出ていますが、まだ結果は出てないようですね。 ※私自身、趣味でレンタルサーバをつかってPHPを使っており、 mod_limitipconnも標準でインストールされている為、 こういった機能はWebサーバで標準で実装済みだと、先日まで勘違いしていました。 | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 11:43
どもです。がるです。ご指名いただいたのと(笑)その他諸々で。
んっと。まず初めに、PMで思ったよりも多く(数名)から頂いた 「技術的奇妙さ」の部分についてです。 以前にDAI氏が書かれた
また、迦陵頻伽さんが書かれている
なのですが。 もちろん、上記で ・TCPをモニタリングして情報を取得 ・その情報を元にASP.NETでダウンロード制限をかける が「技術的に可能か不可能か」といえば、可能です。 恐らくお二人はこの「技術的に可能であろう」という部分を基点に 「出来るのではなかろうか」と推測されているように思われるのですが。 ヒント。私は「技術的に無理」とは言ってないです。「奇妙だ」と 言ってます。 答え。 TCPのモニタリングや、ましてやパケットの解析には、相応の マシンパワーがかかります。 # 念のため。パケットの解析においては、一端「全パケット」を # 見る必要があります。理由はわかりますね？ しかも、当初の要求において
という要求があることからも、比較的面倒な解析(どのファイルかを 認識し、そのファイルのサイズを把握し、パケットで「ファイルデータ が何バイト流れたか」をカウントし続ける)が予測されます。 この処理がどれくらいの重さになるか、ご存知ですか？ で。DAI氏は以前に
とあります。 つまり「サーバ負荷軽減」のために「めちゃくちゃ重たい処理を」 想定している、という話になります。 この辺が「奇妙である」と感じる端的な理由です。 あと。
という話しも気になっていて。 ちとWindows関連のプログラムに関しては無知に等しいのですが。 少なくとも、例えばUNIX-Cなどにおいて、上述のような「パケット モニタリング」をするためのレアソケットの扱いって、そんなに 楽じゃないです。相応の時間もかかりますし(ライブラリとか持ってれば 別ですが)、結構なスキルが必要です。 WIN32APIにも.NETクラスライブラリにも、レアソケットが「楽に」 扱えるようなものを見た記憶がないのですが。 過去にけられた「認証機構」よりも「レアソケットによるパケット モニタリング」のほうが「楽」なんでしょうか？？？ この辺も不思議だなぁと感じる所以です。 ーー で、はじめましてでちょっときついことを申し上げて恐縮なのですが。 迦陵頻伽さんへ。
疑問を持つことそのものは非常によいことだと思うです。 ただ、私が知っている限り「釣り」という単語はいきなり使うには ちょっと好ましくない単語のように思われるです。 で、詳細な内容の検討なのですが。
これについては是とも否とも。現行のシステムへの発言はまったく ないので。 つまり「多分こうなのではないか」という「楽観的予測」は、平たく言って SEとしては危険な発想になります。 特にセキュリティを扱う場合に顕著なのですが、こういったケースにおいて 必要な考え方は「ではこの場合にどのようなホールがありえるのだろうか？」 だと思うです。 ちなみに上記のパターンで平たくホールになるのは ・LANソケットがそこらへんに散らかっていて適当に社外の人間の出入りがある 場合です。 セキュリティは「常に」「包括的な」ものです。「ソフトウェアに問題が ないからセキュリティはOK」とかいう発想でいくと、ものすごく簡単に クラックされるシステムにしかならないので。 私はよく、悪い意味で「官僚縦割り的セキュリティ」とか呼びますが :-P # そーいえば最近「電磁シールド」の話を聞かなくなったような… したがって、
これは大きな間違いになります。それが「どこであれ」、セキュリティに ついてはちゃんと意識をしていかなければなりません。 あと、
についてですが。少なくともある程度こなれたSEであれば、ごく 自然に、実装について ・技術的に可能か？ ・セキュリティは？ ・今後の仕様変更への耐久性能は？ ・可能であれば、より「安価な」実装方法は？ 程度のことは「同時に並行的に」想定するものだと思います。 ちなみに、私の優先順位は上述の通りです。 ですので、「技術的に無理」であるか「セキュリティ的に危なすぎる」 のであれば、とりあえずその辺から突込みが入るのは当然かと。 なので、私は特に「議題からそれている」とは感じていないです。
上記を見て、まだ「釣り」だと思われますか？
数点ほど。 もし「対面して」の話であれば、それは非常に正しいです。 ただ、「伝える」のは最短で一方的に伝達が可能であるのに対して、 「聞き出す」ためには非常に多くのやり取りの往復が必要になります。 会話だと、会話がまさに「キャッチボール」のように何度も往復 しますよね？ 同じことが掲示板で出来るでしょうか？ 掲示板で、という限定された世界観では、基本的には「伝える側」の 能力のほうがより重要視されます。 まぁチャットならまた別なのですが :-P したがって、聞き出す側よりも伝える側のほうに比重が傾く傾向が あるように思われます。 そうそう。
これですが。この部分「だけ」を読み、ほかの部分が不明であるという 現在の私の目からみての「危険の可能性」を何点か。 ・管理画面の脆弱性 管理画面へのクラックに成功すれば「悪意あるリンク」への誘導が可能 推測できるパスワードのほかに「セッションハイジャック」などが可能性として ・DBMSの脆弱性 DBMSへのクラックに成功すれば「悪意あるリンク」への誘導が可能 DBMS自体のセキュリティホールなどが可能性として あとは、上述システムが「Webとつながる」のであれば、当然外部からの クラックの可能性が。 「Webへの接続」と「上述システムへの接続」の双方が出来るマシンが 存在するのであれば、そのマシンをトロイなどでのっとった上で同様の 危険性が。 あとは「社内に悪意がある人間のいる」可能性と「社内LANに無断で接続 する悪意ある外部の人間」の可能性が。 このあたりが、ざっくりと「よくあるパターン」として思い浮かぶです。 以上、つらつらと。 追伸： 打ち合わせの仕方ですが、ちぃとスレッドの趣旨からずれそうなので 別スレッドにて。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=23113&forum=25&0 に書きました ^^ | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 12:30
※お昼を食べながら^^
自分の力量不足を感じつつ… TCP/IPのマシンパワーですが、そんなに負荷が掛かるものなのでしょうか？ 以前、北海道なんたらという会社がフリーで公開していた パケットモニタ？（C言語）で遊んだ覚えがあるのですが、 動作自体は比較的軽量だったと思います。（私のPCはP3の800MHz、メモリ1GBです） また海外のサイトでソースコードなどが公開されている所があったのですが、 そこでC#で書かれたパケットモニタ？スニファ？も使って見ましたが、 これも比較的に軽量であったと思います。（ちょっと記憶が曖昧です）
どれぐらい重くなるのでしょうか？ パケットのデータまで保持しておく必要は無いのだから、 流れたパケットの量だけ数値型の変数にカウントアップしていく。 でもって、その変数の配列なりがダウンロードしているユーザ分だけある。 ユーザが1000人なら数値型の変数（負は考えないからunsignedで良いのかな？）が 1000×変数のバイト数 必要だから重くなるのでしょうか？ また、ここまでやれば、ダウンロード数も正確にカウントできるような 気もするのですが、この機能を捨てて、ダウンロード数の制限だけにすれば モニタ側のプログラムはダウンロードの開始と終了情報のフラグだけを拾えば いいから負荷は少なくなる？
レアソケットというのは生ソケット(RawSocket)と同じですか？（すいません無知で） RawSocketでのサンプルですと、Win32API、C#で掛かれたものなら、 見たことがあります。（上記で書いた通りです） ソースコードも数十行から多くても100行程度だったと思います。
申し訳ないです。 別の人が『釣り』と書かれていたので、使ってしまいました。 ※色々と勉強になります。 | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 13:04
＃見るだけなら、軽いだろうね〜。 今回の場合ダウンロード数を正確にカウントしたい、誰がダウンロード中か正確に把握したいという要望があるので、その解析処理を考えなくてはなりません。
そんな単純な処理では済まないはずです。HTTPには終了フラグなんてありませんので、ヘッダにあるファイルサイズを元に、実際に流れたデータ量を計数する必要があるでしょう。 ましてTCPの再送要求とか、中断やら、HTTPのレジュームを考慮しながら解析する処理を記述するのは、お世辞にも簡単じゃないだろうなぁとは思います。まして今回の場合は性能が問題になるほどのトラフィックを解析するんだよね・・・。 ＃現在の帯域幅がどの程度なのか知らないけど・・・ 処理が重いからといってHTTPサーバー以外の別サーバーでキャプチャーを行うわけにも行きません。他の端末でトラフィックを計測した場合、パケットをロストする恐れがありますので。もしパケットロストが発生すれば、「正確にカウントしたい」という要件を満たせなくなってしまいます。 | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 13:09
昨夜は間抜けな事を書いてしまった…。 で、また思いつきを。 単に、有効期限が数分後に指定された cookie を使って、有効期間内であればダウンロード不可にするってのは（当然、ストレートにファイルを参照するアンカを並べるわけにはいきませんけど）どうですか？ あと、ダウンロードツールについては例えばエージェント文字列とかで判別できないものなんでしょうか？ まあ、ウラをかく事は可能ですし、ダウンロードが失敗した場合のフォローとかも考慮してませんけど、それほど厳密である必要はないとの事ですので「数分後に再度チャレンジしてね」で良いんじゃないでしょうか？ 要求された内容を全て実現するには金も時間も掛かりますよ、という事で。 あとは、何方かの投稿にあったように、注意事項をガツンと明記しておけば OK ではないかと。 | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 13:22
※殆ど素人なのにこんなに書き込んで良いのだろうか…
※勉強だと思って頑張ります。 ※聞くは一時の恥、聞かぬは一生の恥とも言いますし。
間違っていたら指摘して下さいね。 終了したかどうかというのはパケットのヘッダのFINでは判別付かないのでしょうか？ また、性能が問題になるほどのトラフィックというのは、 卵が先かニワトリが先かという事ではないのでしょうか？ 仮に、パケットを見ることでダウンロード数などが制限された場合、 トラフィックが減る事になるので、 パケットの情報を見るのは、このトラフィックが減った状態って事ですよね？ | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 13:47
どもでふ。がるです。
んっと。厳密には「流れるパケットの量による」としかならないのですが。 「HTTPで処理がぎりぎり」ってほどのところにパケット解析まで含める 事を考えると、かなりの高負荷になります。
うい。パケットの量がさほどでもなければ、かなり軽快なはずです。 っていうか「軽快に」作らないと、大量のパケットが捌けないので :-P
んっと。大まかに処理を。 まずパケットのヘッダ部分(IPとポート番号)から 該当するパケットを取得します。 これがスタートであると仮定して。 まず、中のデータの解析をして「どのファイルなのか」を 把握します(これによって転送サイズが確定します)。 次に流れ続けるパケットから「同一のIP/portのもの」を 拾い続けて、「パケットの中を解析してbody部分のサイズを」 カウントし続けることで ・ある特定人物がある特定ファイルを何バイトダウンロードしたか を把握します。 厳密にはここで「再送信要求パケット」を広い、必要に応じて 減算もしなくてはなりません。 そうして最終的に「転送サイズ」分だけパケットが通過し、 ファイルの転送が終了した時点で初めて「終了フラグ」がたて られます。 これだけの処理を、いらんパケットを捨てたりしながら並列 で行う必要があるです。 言い方を変えると「さまざまに入り乱れるパケットから、逐次 "自分に必要な"ものをより分けながら処理をする」必要があるです。 特にTCP/IPの場合、混雑するとコリジョンなどが発生するので 余計に面倒です。
そうです。 で、ソースコードの量というよりも「それによって扱われるパケット量」 によるです。
うん。つかないです。 あくまでも、TCP上のパケットのFINは「TCPの世界における」 FINであって、それが「HTTP上で配信されているコンテンツのFIN と等しい」保障がどこにもないからです。
んっと。 「全体の性能を考えて最終的に計算された上で」ならまだしも なのですが。 現状のDAI氏の書き込みを見ている限りだとそのあたりが不明なので。 # ってかぶっちゃけ「認証機能」である程度片付く機能なので、 # わざわざパケットウォッチングするほどの苦労は多分だれも # したがらないです(苦笑 こんな感じで回答になってますでしょうか？ | ||||||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-07-26 13:49
迦陵頻伽さんにご紹介いただいたFreePeek、良さそうですね。GPLですし。
ありがとうございます。 自分だったらパケットの解析をこういったツールに任せておいて （できれば別マシンに処理させて）ログファイルを読んで処理しますね。 | ||||||||||||||||||||||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。