ハッカーが検出を避ける手段

ハッカーの聡明さは彼らがサーバーに侵入する方法を知っているだけではなく、彼らが自分の攻撃を偽装する方法を知っているからです。悪意の攻撃者は様々な逃避手段を使って自分が検出されないようにしますので、システム管理者としても、これらの手段を理解して、可能な攻撃に対処してください。この文章の主な目的はハッカーの新しい攻撃手法を掲示するのではなく、ハッカーが使用する逃避検査の手法と彼らが残している可能性のある証拠を説明することです。これらの手段の詐欺性が大きいので、それらを検出するのももっと難しいです。  ネットワークサーバ  私たちの実験環境は、最も一般的な2つのネットワークサーバー、Apacheとマイクロソフトのインターネットを使用しています。 Information Server（IIS）。私たちはRedにいます Hat LinuxでAppleを実行します 1.3.9,Windowsでは NT 4.0でIISを運転する 4.0です。両方とも通常とSSLのバージョンを使用していますので、暗号化と暗号化されていないサーバの攻撃をテストすることができます。16進符号化は、攻撃を偽装する最も簡単な手段として、URL要求を修正することである。管理者としては、ログファイルで文字列や普通のテキストの文字セットを検索します。例えば、要求において既知の脆弱性と一致する文字列を検索する。例えば、私達はIISサーバで次のような文字列を発見しました。IISで遠隔利用できるMDAACホールがあるかどうかを調べています。  06:45:25 10.0.29. GET /msadc/ 302は、攻撃者がこのようなマッチング検出をどのように回避するかを知るために、以下の悪意ある攻撃者ポリシーの一部としての要求を参照してください。msadcディレクトリが存在するかどうかを判定するには、攻撃者は以下の内容を入力することができます。root@localhost /root nc -n 10.0.25 80  GET /msadc HTTP/1.0これは私たちが見たログファイルを作成します。攻撃者は要求を16進数のASCII文字でエンコードすることができます。以上の例では、文字列msadcは16進数符号化後に6 Dになります。 73。 61 64 63です。Windowsが使えます。 Charrmapプログラムは文字のASCIIから16進数への変換を迅速に行います。以上のHTTP要求は、文字列msadcを16進数で符号化すると、次のようになります。  [root@localhost」シシシ nc -n 10.0.25 80  GET /%6 D%73%61%64%63 HTTP/1.0  IISのログファイル表示：07:10:39 10.0.21 GET /msadc/ 302  なお、16進符号化の手段を採用しているが、生成されたログは、16進符号化を使用していないURLと同じである。この例では、エンコーディングは攻撃者の検出からの脱出を助けるものではない。しかし、もし私たちがAppacheのログを見たら、もう一つの状況です。次の攻撃者が使用しているCGIスクリプトを検索するコマンドで、後に続くのは16進数コードを使用した後の同じコマンドです。  [root@localhost」シシシ nc -n 10.0.0.2 80  HEAD /cgi-bin/test-cgi HTTP/1.0  [root@localhost」シシシ nc -n 10.0.0.2 80  HEAD /%63%67%69-bin/test-63%67%69 HTTP/1.0  今からaccess_を確認します。ロゴファイル:  10.10.10 - - [18/Oct/2000:08:22:47 -0700; "HEAD /cgi-bin/test-cgi HTTP/1.0" 200 0  10.10.10 - - [18/Oct/2000:08:23:47 -0700; "HEAD /%63%67%69-bin/test-63%67%69 HTTP/1.0" 200 0  まず、この2つの例では、200コードの説明コマンドが成功しました。しかし、第二の場合、ログには、明文ではなく16進数の値が表示されます。もし我々が形式に依存してこのような攻撃を検出したら、我々は発生した攻撃を検出することができない。多くの侵入検知システムが使用するフォーマットマッチング技術は知能化が高くなく、十六進のURLを変換してからマッチングすることができない製品があります。しかし、使用された侵入検知ソフトが16進数のコードを変換できるかどうかを問わず、すべてのネットワーク管理者はこのようなテクニックを理解しなければならない。  プロキシサーバ  攻撃者にとって攻撃行為を完全に隠すことは難しいので、攻撃の真実を隠すことが重要な課題になります。ハッカーが彼のソースIPアドレスを隠すことができれば、彼は捕まる心配がない状態で攻撃することができます。ハッカーは彼らのソースIPアドレスを隠すための手段の一つとして、プロキシサーバーを使用します。  プロキシサーバは、単一のアクセスポイントから複数のプロトコルを転送するために合法的に使用される。一般的には、内部ユーザはプロキシを通じてインターネットにアクセスする必要がありますので、管理者はプロキシサーバで外部アクセス及び内部アクセスの制限策を指定できます。ユーザはまずプロキシと接続を確立し、プロキシサーバは接続要求を本当の宛先アドレスに転送する。宛先アドレスは、最初に要求されたシステムのIPアドレスではなく、プロキシのIPアドレスを記録する。残念なことに、プロキシがインターネット上に置いてあるのは勝手です。Proxys-4-llを確認して、これらの誤配置マシンのリストを取得することができます。） これらのサーバーにはしばしば構成エラーがあり、インターネットユーザーがこれらのプロキシサーバーに接続できるようにしています。あるインターネットユーザーがプロキシを介してあるサーバーに接続すると、プロキシサーバのIPアドレスを要求の発信元としてログに記録します。攻撃されたサーバのログで攻撃者に対して記録されたIPアドレスは攻撃行為のない「罪のない」ホストに属しています。攻撃者の本当のアドレスではありません。以下の例を見てみます。  次の例はハッカーの攻撃と攻撃に関する情報をログに表示します。  攻撃者  [[email protected] /]# nc -v 10.8.8 80  HEAD / HTTP/1.0  ログファイル  10.1.1.1 - - [18/Oct/2000:03:31:58 -0700; "HEAD / HTTP/1.0" 200 0  次のような状況の中で、攻撃者が同じ目的を達成したのを見ましたが、今回はプロキシを使いました。  攻撃者  [[email protected] /]# nc -v 216.34.161.83 80  HEAD http://10.8.8.8/ HTTP/1.0  ログファイル  216.34.161.83 - - [18/Oct/2000:03:39:29 -0700; "HEAD / HTTP/1.1" 200 0  この例では、ログファイルに表示されるアドレスは、攻撃者の実際のアドレスではなく、プロキシサーバ（216.34.161.83、proxy.proxyspace.com）である。このケースでは攻撃者は攻撃のソースアドレスを隠すことに成功しました。しかし、ネットワーク管理者がプロキシサービスのサポートを受けることができれば、攻撃の本当のソースを追跡することができます。ほとんどのプロキシはかなり詳細なログを保存していますので、攻撃のソースを見つけられます。しかし、道高一尺の魔高一戦は、ハッカーも相応の方法で追跡します。彼らはマルチエージェントを使ってもいいし、代理チェーンと言って攻撃してもいいです。管理者と法律執行部門はすべての中間代理サーバを順次検査して攻撃の出所を獲得しなければなりません。ハッカーの団体ではこのような「代理チェーン」の使用が非常に一般的で、Socks Charinのようなものがあります。 for Windowsのようなツールは使えます。  SSL  これまで多くの人が議論してきましたが、SSLのサーバーがネットワーク侵入検知システムによって検出されないようにすることを改めて提案する価値があります。一つのハッカーを80ポート（HTTP）と443ポート（HTTPS）の間で選択させると、攻撃者は毎回443ポートを選択します。これは実際には手段ではなく、暗号化された通信の使用による副作用です。443ポートの要求を監視するために、ネットワークサーバログファイルを使用することができます。結論  私たちはあなたにいくつかのネット上のハッカーがよく使う騙し術を実証しました。言うまでもなく、これらの手段はハッカーたちの想像力と創造力の増加によって絶えず拡張されています。例えば、十六進符号化という技術は、詐欺的なログファイルの入り口のようなところだけではない。同様に、ネットワークサーバのURL解析機構をも騙し、ソースコードの露出などの脆弱性の出現を引き起こす可能性がある。攻撃者は、複数のプロキシサーバーを使ってスキャンや攻撃を行う場合もあります。もちろん、SSLはいつか「安全ハッカー行為」のために道を開けました。