![[Pocketstudio.jp Linux Wiki]](image/icon.gif "[Pocketstudio.jp Linux Wiki]"){kind=icon}
PortSentry/README 日本語訳
http://pocketstudio.jp/linux/?PortSentry%2FREADME%20%C6%FC%CB%DC%B8%EC%CC%F5
PortSentry README.install 日本語訳 †当ドキュメントは配布アーカイブに付属している README.install を日本語訳したものです。 ドキュメントの翻訳について †日本語版のドキュメント公開については念のため作者さんに問い合わせ中です。先方の回答やライセンスによってはドキュメントは非公開になる場合もあります。 ドキュメントの内容は出来るだけオリジナル英語に忠実に翻訳するように努めますが、日本語として不適切な部分は日本語として読みやすいように置き換えている場合もあります。なお、免責事項として、日本語版を利用者が利用するにあたり、いかなる場合も訳者はその責をを追いません（、と書くのが一般的ですので、私も書かせてください。。）。 PortSentry - ポートスキャン検知とアクティブな防衛 †これは"長〜い"インストール版です。プログラムのロジック（構造）について全ての手法を熱狂的に理解したいのであれば、この文章を読むべきでしょう。細かい事を気にしないのであれば、ページの下の方のインストールに関する場所まで読み飛ばしてください。 詳しい情報は http://sourceforge.net/projects/sentrytools から得られます。 PortSentry は以下に挙げる方法のように様々な種類のポートスキャンを検出します。
これらの情報から、管理者にどのような事態が発生しているかを伝えるのが目的です。すでに類似するプログラムはいくつか作成されています（Klaxon など）。このプログラムではアイディア（自動ブロック）にステルス・スキャンの検出に対応できるよう"ひねり"を加えています。 PortSentry は４種類の"ステルス"スキャン・モードを検出します。１つめの動作は予め指定されたポート一覧の推移を監視します。ポートに対する何らかのアクセスによりプログラムが作動します。２つめの動作は"逆"ポート・バインディング(inverse port binding) と呼ばれるもので、Portsentry の起動時や手動で実行する時に、ネットワーク・デーモンの監視*対象外*となっているポートに対しても監視を行います。ポート調査を行う手法はとても緻密ですが、誤検出する傾向もあります。 Install - インストール †ステップ１: †エディタで portsentry_config.h ファイルを読み込んで以下の項目が希望通りかどうか確認します。 CONFIG_FILE - PortSentry 設定ファイルのパス（設置場所） WRAPPER_HOSTS_DENY - TCP ラッパーの使う hosts.deny ファイルのパス SYSLOG_FACILITY - PortSentry が使う syslog のファイシリティ（ログの種別の事です） SYSLOG_LEVEL - syslog へメッセージを送るときのレベル これらの項目がどのような事を意味しているのか理解できない場合は、これらのオプションを変更しない事をお勧めします。 メモ：上級者であれば syslog のファシリティを LOG_DAEMON から LOG_LOCAL0 へ変更（あるいは他の種類のローカル用ファシリティへ変更）して構いません。 メモ：設定ファイルから "#" の記号を絶対に消さないでください。これらはコメント文ではなく、C 言語のコンパイラがヘッダを読み込むために必要なものです。もし "#" を消してしまえばコンパイル時にエラーメッセージが表示されてしまいます。 ステップ２： †エディタで portsentry.conf ファイルを読み込んで以下のオプションの確認・変更を行います。 TCP_PORTS - PortSentry に監視させたい TCP ポート番号を "," 区切りで記述します。文字列の中に空白を入れてはいけません。希望するソケット（ポート番号）を好きなだけ指定することが出来ます。PortSentry は標準の上限である 64 ポートまでを確保しようとします。 ステルス・スキャン検出モードを使う場合、ポート自体を拘束することはありませんが、ソケット・レベルでの接続は監視します。 高度なステルス・スキャン検出モード（後述します）を参照してください。*無視*されても構いません。 UDP_PORTS - 上記と同じようなことを UDP ポートに対して行います。UDP モードでは攻撃者が広範囲にわたるスキャンをしてしまう事により、多数のホストに接続できなくさせてしまう事もありますので、十分に注意を払ってください。このオプションを使うときはインターネットで名の通ったシステムでも、あるいはそうでなくても、注意して使用してください。 高度なステルス・スキャン検出モード（後述します）を参照してください。*無視*されても構いません。 ADVANCED_PORTS_TCP - より高く明示されているポート番号を監視します。指定されているポート*以下*のあらゆるポートを監視します。標準では 1024 (予約ポート範囲)ですが、最大で 65535(システムの上限)まで引き上げることができます。ですが、1024 以上の設定はお勧めしません。 ADVANCED_PORTS_UDP - 上記と同様な事を UDP ポートに対して行います。 ADVANCED_EXCLUDE_TCP - TCP ポート番号を "," で区切って記述します。アドバンス・モードでは監視対象から外されます。これらは一般的に用いられるポートであり、攻撃と誤検出される可能性のあるポートを記述します（例：ident、SSL など）。 ADVANCED_EXCLUDE_UDP - 上記と同様な事を UDP ポートに対して行います。 IGNORE_FILE - 常に無視したいホストの IP アドレス一覧を記述したファイルへのパスを記述します。詳細は後述します。 BLOCKED_FILE - 常に遮断したいホストの IP アドレス一覧を記述したファイルへのパスを記述します。 RESOLVE_HOST - DNS の名前解決を行わないホストを記述します。反応の遅い DNS サーバを使っている場合、ここで指定することによって DNS の応答速度が良くなるかもしれません。 BLOCK_UDP - このオプションを使うことで自動的に全ての UDP ポート監査を行いません。UDP パケットは容易に偽装することができるため、対象となるホストに対して攻撃者が DoS 攻撃を行うと、通常利用されるべき UDP ポートも遮断されてしまう可能性があるためです。オプション値を "0" にしておくことで、全ての監視を無効にしますがログの記録は行います。オプションは主にインターネットに晒されているホストに対して有用でしょう。ファイアウォールやルータ配下の内部ホストであれば無効にしておくべきです。もしネットワーク内部で偽装されたパケットが排出されているのであれば、Dos 攻撃よりも更に大きな問題を抱えている事でしょう。 BLOCK_TCP - TCP ポートに対して上記に挙げたような動作を行います。パケットの偽装はさほど大きな問題ではありません。PortSentry は完全な接続があるまで待機しますので、基本モードでも偽装し辛くなっています。インターネットに接続されているホストであれば、この機能は有効でしょう。ステルス・スキャン検出モードでは以下のような UDP に対する警告が表示されます：
KILL_ROUTE - もし攻撃が検出されると攻撃者からの経路を遮断するコマンドを実行します。ここには必要なパラメータと共にコマンドを実行するために必要なコマンドを*フルパス*で記述します。$TARGET$ マクロのオプションには攻撃ホストの IP アドレスを必要とします。手元のローカルのサブネットに *dead host* ゲートウェイを追加したほうが良いでしょう。大抵のシステムではローカルホスト用アドレス(127.0.0.1)を用いる事ができます。攻撃ホストからの全パケットは 127.0.0.1 にゴチャゴチャと送られるでしょう。最近の route 小窓には "-blackhole" や "-reject" といったフラグを用いることができます。man(1) ページで route コマンドがこれらの機能を利用できるかどうか調べてみてください（パケットフィルタを行う場合は別の方法を推奨します。詳しくは以下をご覧下さい）。 この動作により"非同期の経路"、基本的にはパケットをある経路から別の経路（行き止まり）に送り出す事にも注意を払ってください。この動作は全 TCP 接続のリスクエストに対して機能しますが、UDP のステルス・スキャン検出モードでは PortSentry がパケットを検出しても"すでに遮断済み"と警告を出す場合もあります。UDP のスキャンに対しては攻撃者に対して全ポートが開いているかのように ICMP メッセージを応答します。ですが、攻撃者が UDP に対する攻撃を行っている場合には UDP のパケットを遮断することはできません。非同期の経路を使うことでパケットがシステムまで到達することができますが、攻撃者がシステムがどのような応答をするか周知している場合、攻撃者による*出口のない* UDP 攻撃を受ける場合もあります。 一番最も良い方法はローカルのパケットフィルタを用いることです（Linux では ipfwadm/ipchains や BSD では ipfw）。こちらのほうは綺麗な解決方法で、詳細については設定ファイルで記述しています。$PORT$ マクロは攻撃者によって接続されたポートの代わりとなるものですが、必ずしも必要なオプションではありません。$MODE$ マクロはどのようなモードを遮断したか（tcp、udp、stcp、sudp、atcp、audp）を報告しますが、こちらもまた必要なオプションではありません。 KILL_HOSTS_DENY - TCP ラッパーが使う hosts.deny ファイルに挿入する文字列の書式を定義します。$TARGET$ マクロで攻撃者の IP アドレスを追放するために再び必要とされます。ここではどのようなエスケープコード(%h や twist など)でも TCP ラッパーに引き渡すことができます。$PORT$ マクロは攻撃者によって接続されたポートの代わりとなるものですが、必ずしも必要なオプションではありません。$MODE$ マクロはどのようなモードを遮断したか（tcp、udp、stcp、sudp、atcp、audp）を報告しますが、こちらもまた必要なオプションではありません。 KILL_RUN_CMD - ここでは攻撃者からの通信を遮断する*前に*実行したいコマンドを記述します。攻撃が検出された時、希望するあらゆるプログラム・スクリプトを実行させることができます。とはいえ、私たちは攻撃者に対して何らかの報復を行うことは決して勧めません。殆どの場合、ポートスキャンを行ったホスト自身がスキャンを受けたことがあるはずです。つまり、報復しようとしている対象が、実のところ罪のない場合もあり得ます。セキュリティ上の目的は、攻撃者を立ち去らせる事です。報復によって、相手から恨みを受けてしまうような事も望まないはずです。さらに１３歳の子供でさえ適当な DOS 攻撃プログラムを走らせて、あなたの生活を憂鬱にすることも出来るのです。以上の事から、$TARGET$、$PORT$、そして $MODE$ マクロは利用可能ではありますが、オプションとしては必要なものではありません。 KILL_RUN_CMD_FIRST - このオプションを "0" に設定しておけば上記のコマンドを経路を遮断する前に実行します。"1" に設定すると遮断後にコマンドを実行します。 SCAN_TRIGGER - PortSentry は接続したホストを記憶しておく機能を備えています。設定する値は PortSentry に何回ポートへのアクセスがあったら動作させるかを指定するものです。連続するポートやランダムなポートへのアクセスを検出します。標準では即時に対応するよう 0 が設定されています。1 か 2 を設定しておけば誤警報を減らすことができるでしょう。ヒット回数が 3 以上であれば、多くの場合、かなり怪しい行動が行われていると考えていいでしょう。通常、特に理由がなければ 0 を指定しておいていいでしょう。例外として高度なステルス・スキャン検出モードでは苛立たせられる事もあるでしょうから注意してください。あなた自身の判断でご利用下さい。 PORT_BANNER - PortSentry が稼働した時、ホストのディスプレイ上に表示したい文字列を記述します。とくにメッセージを表示したくない場合は、この行をコメントしておいてください。機能を使う場合は、あまり人を怒らせるようなことは書かないでください。私たちは出来れば専門家のようにポイントを突いたメッセージにすることをお勧めします。なお、ステルス・スキャン検出モードが有効であっても、検出時、画面には表示されません。 ステップ３： †エディタで portsentry.ignore ファイルを開いて、検査対象のポートへのアクセスがあっても無視するホストを記述してください。少なくとも localhost (127.0.0.1) やローカル・インターフェースの IP アドレスは記述すべきです。自分のネットワーク上にある全マシンの IP アドレスの記述はお勧めできません。ネットマスクを使って指定できるからです。書式は以下の通りです： <IP アドレス>/<ネットマスク> 192.168.2.0/24 192.168.0.0/16 など あまり多くを無視するような設定は勧めません。たとえ"友好的な"マシンであったとしても、誰が自分のマシンに接続しようとしているか調べることは重要な場合もあります。これは、内部ホストからの危険性をより速く検出する事にも用いられるでしょう。このジレンマの答えは、危険性はあり得るという事です。私たちはあまりにも多くのホストを信頼することにより、結果として対象となるマシンから攻撃を受けてしまったという管理者の事例を多く知っています。 ステップ４： †コンパイルします。make と入力して、自分のシステムにあったものをビルド・インストールします。標準のインストール先ディレクトリは /usr/local/psionic/portsentry です。ディレクトリ名が気に入らなければ Makefile を編集して portsentry.conf と portsentry_config.h ファイルにも新しいパスを反映させることを確認してください。 ビルドが終わった後はシステムにインストールするため make install と入力してください。 ステップ５： †PortSentry を起動します。PortSentry には６つの動作モードがあります。ですが、１つのプロトコルに対しては１つのモードしか動作できません。利用可能なコマンドは以下の通りです： portsentry -tcp (基本的な TCP ポートの監視モード) portsentry -udp (基本的な UDP ポートの監視モード) portsentry -stcp (TCP ステルス・スキャン検出モード) portsentry -atcp (高度な TCP ステルス・スキャン検出モード) portsentry -sudp (UDP ステルス・スキャン検出モード) portsentry -audp (高度な UDP ステルス・スキャン検出モード)
PortSentry は設定ファイルを確認し、バックグラウンドで指定された TCP ポートを監視します。プログラムの初期化状態を確認したい場合はローカルにある syslog ファイルをしらべて、どのようなメッセージが表示するか見ることができます。
PortSentry は設定ファイルを確認し、バックグラウンドで指定された UDP ポートを監視します。プログラムの初期化状態を確認したい場合はローカルにある syslog ファイルをしらべて、どのようなメッセージが表示するか見ることができます。UDP ステルス・スキャン検出については README.stealth の注意を参照してください。
PortSentry は全受信パケットの生情報を監視します。受信パケットに監視対象のポートへのアクセスがあれば、対象ホストからの通信を遮断します。connect() スキャン、SYN/half-open スキャン、FINS スキャン検出時に動作します。UDP ステルス・スキャン検出については README.stealth の注意を参照してください。
PortSentry は ADVANCED_PORTS_TCP オプションを選択時に指定対象となるポートを監視しますが、基本的なポートを除外したリストを作成します。除外された*どのポート範囲に対して*接続があっても、それらは*監視対象にはならず*遮断対象外となります（たとえば SMTP や HTTP といったリスニングのみでないネットワーク・デーモンが対象です）。これは注意すべき重要な意味合いを持っています。 1) この動作モードは全ての保護オプションの中で最も敏感かつ効果的なものです。対象となるポートへの攻撃が見受けられれば電光石火の如くポート調査に対応します。 2) あまりにも突然に反応するため、正常なトラフィックも遮断する恐れがあります。たとえば FTP サイトは IDENT 認証のリクエストを送ってくるかもしれません。もし、ident ポート(TCP 113 番)を監視対象にしていると、接続しようとしていた FTP サイトへの接続が遮断されてしまいます。つまり、結果としてこのような状態に陥らないように対象ポートを指定しなくてはいけません。 ＊＊ 高度な論理モード ＊＊ PortSentry はポートをどのように監視するか高い知性を備えています。FTP のような複数のプロトコルでは、クライアントは規定範囲のポート(1024〜65535)を開き、相手サーバ側からの接続を*受け入れ*ます。通常動作としてポート監視が開始されます。PortSentry は受信する接続を調べ*一時的な*ポート接続かどうかを判断します。一時的なものと認識されれば、一定期間その接続を無視します。もしバラバラの接続が続くようであれば直ちにポートを閉じて保護モードに復帰します。これが基本的な処理状況を把握する識別機構です。UDP ステルス・スキャン検出については README.stealth の注意を参照してください。
上記の TCP ステルス・スキャン検出モードと同様の動作を行います。監視対象となる UDP ポートをリストします。ここではどのようなソケットも監視しませんが、本当に"ステルス"スキャンを検出（通常 UDP ポート対しては見受けられませんが）すると TCP 同様に遮断を行います。UDP ステルス・スキャン検出については README.stealth の注意を参照してください。
こちらは上記の TCP ポートに対して記述した同様の動作を UDP ポートに対して行います。これは非常に高度なオプションで誤検出を引き起こす場合もあります。PortSentry はブロードキャストとダイレクトなトラフィックの区別を行わないためです。もしローカルネットワーク上のルータが RIP ブロードキャストを消しているようであれば、誤検出をなくしてくれる可能性はあります。十分な注意を払ってこのオプションを使ってください。UDP ステルス・スキャン検出について記述してある README.stealth にある ADVANCED_EXCLUDE_UDP の除外条項（例 520 [RIP]）に必ず目を通すようにしてください。 インストールのテスト †ローカルのログファイルの末尾に PortSentry 初期化メッセージが数行表示されます。 起動成功時には次のようなメッセージが表示されます： Oct 9 09:11:35 nemesis portsentry[1644]: adminalert: portsentry is starting. Oct 9 09:11:36 nemesis portsentry[1644]: adminalert: Going into listen mode on TCP port: 143 . . . Oct 9 09:11:37 nemesis portsentry[1644]: adminalert: PortSentry is now active and listening. 最終行が PortSentry が正常に初期化された事を意味します。もし表示されない場合は何か起動に失敗しています。 まず監視対象としたポート番号の情報がログに表示されているかどうか確認すべきです。もし対象ポートが使用中であれば、PortSentry がポートを確保できなかったという警告を表示し、その他のポートも全て確保できるまで確保作業を継続します。もしポートを１つも確保することが出来なければエラーを出力して終了します。 高度なステルス・スキャン検出モードのために、ポートを確保できなくとも検査対象とします。これが逆バインディング(inverse binding)です。 この状態で別のホストから仕掛けをしたポートにたいして telnet をかけてみてください。ただし、機能が正常動作すると自分自身の正常なアクセスも遮断されてしまいますので、もしアクセス許可が１カ所のみしか許可がされてないホストでは、決して実行しないでください。telnet を試みると以下のようなメッセージが表示されます： Oct 9 09:12:44 nemesis portsentry[1644]: attackalert: Connect from host: 123.345.56.78 to TCP port: 143 Oct 9 09:12:46 nemesis portsentry[1644]: attackalert: Host server.haxor.org/123.345.56.78 has been blocked via dropped route. Oct 9 09:12:46 nemesis portsentry[1644]: attackalert: Host server.haxor.org/123.345.56.78 has been blocked via wrappers. 高度なモードでの動作確認をするには、警告を出すようにしていないポートに対しても telnet のアクセスを試みてください。 一旦接続した telnet を切断後、もう一度接続を試みようとしても対象となるホストへの経路が到達不能となっている事が確認できます。 お祝いをいわせてください、これで利用可能な状態になりました。 もし Logcheck を動作させているのであれば対象となった経路情報が怒濤のように表示されることでしょう。 netstat -nr コマンドを実行すると攻撃者のホストからの経路情報を失わせていることが確認できるでしょう（もし私たちが推奨しているパケット・フィルタ機能を使用していない場合）。 最後に PortSentry のコマンドを起動ファイル(rc.local など)に記述して仕事は終わりです。 さて、PortSentry はどのように役立つでしょうか？ ここにいくつかのアイディアがあります： - TFTP スキャンを検出するため UDP サービスのポート 69 番を監視する - SNMP スキャンを検出するため UDP サービスのポート 161 と 162 番を監視する - RPC スキャンを検出するため UDP ポートの 32000 〜 33000 番の範囲を監視する - IMAP スキャンを検出するため TCP サービスのポート 143 番を監視する - netstat/systat スキャンを検出するため TCP サービスのポート 11 番と 15 番を監視する - など 実際の所、PortSentry は攻撃者から該当ポートに対するポートスキャンを受けても１秒後には十分に反応して遮断することができます。高度なステルス・スキャン検出モードではより速く対応します。 どのような種類の UDP スキャンがあっても、あたかも全ポートが開いているかのように攻撃者には見えますし、TCP ポートであれば全く応答しません。スキャンしようとしてる攻撃者をイライラさせる事ができるでしょう。 Safety - 安全性 †もし私たちのプログラムで安全性に関する問題があれば、BugTrack? に投稿する前に、是非私たちに情報をお聞かせ下さい(^_^) Messages - メッセージ †一番良いと思える方法、つまり全ての状態・エラー・成功・失敗・状況不明といった情報を syslog を経由して書き込まれるようになっています。 以下のタグはそれぞれ次のような意味を持っています： adminalert：PortSentry の稼働状態を表す何らかのメッセージ securityalert：セキュリティに関係のある事態が発生したというメッセージ attackalert：ホストからのスキャンを検出し何らかの行動を起こしました Files - ファイル †起動時から遮断した情報は portsentry.histry ファイルと同様に posrtsentry.blocked.* ファイルの中にホスト情報が書き込まれていきます。これらブロックファイルは PortSentry が再起動する毎に削除されます。portsenty.history ファイルは純粋にこれまで遮断したホスト情報を記録し続けるために使用します。portsentry.blocked.* はファイルの拡張子によって、どのような種類の遮断を行ったかが記録されてます。 portsentry.blocked.tcp portsentry.blocked.udp portsentry.blocked.stcp portsentry.blocked.sudp portsentry.blocked.atcp portsentry.blocked.audp 起動時のモードによって各ファイルは作成されますが、PortSentry 再起動時には削除されます。 route による経路の遮断は攻撃ホストにパケットを*差し戻す*のであり、*受信*経路を捨てているのではありません。攻撃者がホストに対して UDP スキャンをすると、それらのパケットによりセンサーは稼働しますが、該当ホストに情報を返しません。もし遮断ホストを記述するファイルがなければ、hosts.deny ファイルに何百、あるいは何千といったホスト情報を記述することになってしまうでしょう。これは良くありません。よりよい解決法としてはローカルのパケットフィルタ（Linux の ipfwadm/ipchains/iptables のように、利用中のシステムにある類似する機能）と連動することです。 一定の期間を経過した後も、攻撃者からローカルな接続をする経路情報を遮断したままにして、hosts.deny ファイルへ記述することを希望するかもしれません。どう対処するかはあなたの選択次第です。攻撃者が戻ってきたとき、再び進入の阻止を行いたいのであれば、PortSentry を再起動するか遮断ファイル内の該当項目を削除してください。 経路を遮断したホスト情報を復帰させる必要があれば、route コマンドを使って単純に以下のようなコマンドを入力してください： Linux: route del <IPアドレス> reject そのほか: route delete <IPアドレス> <dead_route> あるいは、単にパケットフィルタの情報をリセットしてください。 説明は以上です。私たちは Logcheck ツールを使うことにより、PortSentry がどのような出力をしているか知るために、ログファイルから目を離さなくていいようにするために、その他の問題を検出するために活用される事を強く推奨いたします。Logcheck の情報は以下の URL より取得可能です。 |
