以下のコマンドを入れて、なにもでなければ、そのポートは利用可能です。
> netstat -an | grep ポート番号
また以下の自作のコマンドもあります。
ozzy-1 07/29 8:32am] portstat -h
Usage: portstat [-tuh] MIN_PORT MAX_PORT (1 ~ 65535)
-t : TCP/IP (default)
-u : UDP
-h : help Ex) portstat 1500 1550
ozzy-2 07/29 9:13am] portstat 1530 1535
Port Services tcp Status : Reason Services=/etc/services
------ ---------- --------------------------------------
1530 Not available : Address already in use
1531 Not available : Address already in use
1532 Available
1533 Available
1534 Available
1535 Available
 |
|
unix 上での TCP/IP はカーネルモジュールとして実装されています。 その中には、システムでオープンされているソケットを管理するテーブルがあります。
ソケット管理表の構造には、PID、送信元 IP とポート番号、 受信先 IP とポート番号があります。 また送られてきたパケットのヘッダには送信元 IP とポート番号、 受信先 IP とポート番号があります。 従って、TCP/IP カーネルモジュールは、これらの情報からパケットの受け取り先の PID を決定できます。
相手側がソケットをクローズ（シャットダウン）し、
自分側がソケットをクローズするのを待っている状態です。
通常このような状態を長時間保持することはありませんが、
以下の３つの場合が考えられます。
- CPU の負荷が大きく該当プロセスに CPU が割り当てられない場合
なお、この状態から脱出するチューニング・パラメータ等はないため、 特に Web を使う場合, どんどんこのような状態のプロセスがたまって、 ついにはファイル記述子を食いつぶし、ハング状態になる事例が増えています。
対処法：サーバ側をリスタートする。 - 自分側がソケットをクローズするのを忘れている場合
対処法：ソケットをクローズする。 - サーバ側がソケットをクローズする前に異常終了した場合
対処法：システムをリブートする。
|
|
|
両サイドがソケットをクローズし、 相手側からの遠隔シャットダウン再送信を待っている状態です。 この場合、該当プロセスはすでに終了していますので問題はありません。
TIME_WAIT 状態のものが多数残る場合は、
tcp_time_wait_interval の値を小さくすることをお奨めします。
以下のチューニング・パラメータの項を参照してください。
|
|
|
TCP のコネクション確立の手順を悪用するものの代表例が SYN flood 攻撃です。 一斉に多数の TCP コネクションを要求し、 それぞれのコネクションを中途半端なままで放置する （ハーフ・コネクション）ものです。
TCP のコネクションを確立する場合、クライアント側からの要求（SYN）、 サーバからの確認応答（SYN-ACK）、 クライアントからの確認応答という３回のやり取りが必要です。 この TCP コネクションの確立を、 SYN と SYN-ACK の２回のやり取りだけで止めてしまうことを多数行うのが SYN flood (SYN の洪水)です。
サーバ側は、クライアントからの確認応答を受け取るまでコネクションを確立しません。 この確認応答を待つ間、 バッファ・メモリ上にクライアントの要求情報を格納します。 クライアントからの確認応答を受け取るまでは、メモリを解放できず、 同様のハーフ・コネクションが同時に多数発生すると、 バッファがいっぱいになって、 他のクライアントからのコネクション要求を受け取れなくなります。
■攻撃を発見するには？
初期の段階で発見するのは困難ですが、使用不可の症状が徐々に確認できます。 SYN flood 攻撃は最初の TCP の 三相ハンドシェークの SYN を送った後、 決して ACK を返さないので、攻撃されているホストで netstat を実行し、 SYN_RECV で止まっているものが多く、 さらに増えているようであればその攻撃下にある可能性が高いです。
もちろん、攻撃されているホストが netstat を実行できなくなる状態にまで陥っていれば確認はできません。 この場合は少々難しいですが LAN アナライザ等でパケットを補足して ACK を返さない異常な状態を見つけて下さい。
■攻撃されやすい環境とはどんな環境？
Web サーバや E-mail サーバ等インターネット上の TCP/IP reachable なホストは IP-Spoofing する必要はありません。 これらは簡単に攻撃の対象になってしまいます。 攻撃の目的が使用不能にすることなので、 狙われやすいサービスを行なっているサイト（組織）等はあるでしょう。例えば ISP (Internet Service Provider) 等が考えられるでしょう。
■防御方法
TCP/IP の本質的問題なので、防御は難しい。 ファイアウォール製品の中には、SYN flood を自動検知して、 一定時間以上確立されないままのハーフ・コネクションを強制 的にリセットしてしまう機能を持つものもあります。
- CONFIG_SYNCOOKIES
Linux の場合、カーネルが CONFIG_SYNCOOKIES オプション付きでコンパイルされている場合にのみ使用できます。 ソケットの SYN 蓄積キューが溢れた場合 に syncookie を送信します。 これは一般的な「syn flood 攻撃」を防ぎ ます。
tcp_syncookies=1 - ACK 待ち時間
クライアントからの ACK 待ち時間を短くする。
ただし、遠隔地からの正常な接続要求が拒絶される恐れがある。 - コネクション上限数の調整
ハーフオープンのコネクションの上限数を増やす。
ただし、資源の無駄が増える恐れがある。
Solaris では、tcp_conn_req_max_q0で、 1024 から 10240 までです。 - 三相ハンドシェイク
三相ハンドシェイクが成立したコネクションだけサーバに接続する。
ただし、専用のファイアウォールが必要。
|
|
|
Solaris 2.x では、tcp/ip がアボートされる間隔が短すぎます。 デフォルト値は２分です。 結果として 2 分以内に ACK が受信されなかった場合、 接続はクローズされます。 これは sendmail でしばしば起こるようで、以下のログが発生します。
以下のコマンドを実行することで、 タイムアウトを 8 分に増加させるよう修正できます（単位はミリ秒です）。 この値は 2.4 及びパッチを適用した 2.3 のデフォルト値です。
|
|
|
Solaris 2.x はパケットが MTU パス・ディスカバリーの一部として送るすべてのパケットに "don't fragment bit" を立てます。 Solaris 2.x のインプリメンテーションは RFC に準拠していますが、 パスの中でこわれたルータがあると、 MTU パス・ディスカバリー・プロトコルは失敗します。 典型的な現象として、 Solaris 2.x のホストからは接続できないが他のホストからの接続は問題がない、 TCP/IP 接続は開始できるが大量データの移動ができない、 といったことがあります。
上記設定でも接続できない場合は、 パッケットを適切に処理できないリンクを見ることがしばしばあります。 それらはフラグメントをせず、代わりにパケットをだまって切り落としてしまいます。
上記の修正がうまくいかない場合には、 ネットワークの性能に良くない影響を与えますが、 以下のような劇的な手段に訴えることができます。
536 という値は、 ほとんどのシステムがローカルネットの外と通信できることが事実上保証されている、 標準のパケットサイズです。 もし接続がうまくいき始めたら、今度はうまく行く最大値を見つける番です。
また、接続を完全に機能させるには、 "ip_path_mtu_discovery" を接続の両端に適用する必要があり、 一方だけにしか適用していないと、 外に出ていく大きなパッケトにしか効果が及ばないということを 述べておくのも有意義でしょう （すなわち、サイトからのダウンロードは成功しますが、 回避策を適用していない他の Solaris 2.x マシンからのアップロードには依然として失敗するかもしれません）。 "tcp_mss_max" は片方だけを調節する必要があります。
いくつかサイトのために "tcp_mss_max" の回避策が必要な場合には、 それらのサイトとあなたのホストの間のリンクに問題があります。 そちらを修正して下さい。 traceroute はどこに問題があるかの教えてくれます。 「traceroute ホスト サイズ」をサイズを色々変えてやってみてください。 サイズ・パラメーターを与えないと動作するのに、 サイズとして 1460 を与えるとあるホップで失敗する場合には、 そのホップと次のホップの接続が壊れています。
|
|
|