IIS Insider

各質問を見ていく前に、このログ ファイルでどの「フィールド」がログ インされているかを理解することが重要です。この場合、フィールドは次の通りです。

time c-ip cs-username s-port cs-method cs-uri-stem sc-status

次の表は各フィールドによりどの情報がキャプチャされるかを示しています。

それでは、個々の質問を見ていきましょう。

質問 (a):上記の最初のログ エントリで、[135] および 331 は何を意味していますか? この状態コードに関する詳細情報はどこで見つけることができますか?
回答 (a): cs-method フィールドの [135] は、IIS FTP の「接続 ID」を表しています。この場合、ip1 からの最初の接続は、サービスが開始されてから 135 番目の接続となります。331 は返信された状態コードで、RFC959 specification (英語) により、「ユーザー名 OK、パスワードが必要」という意味です。次のログ エントリは状態コード 530 を含んでおり、これはユーザーがログ オンに失敗したことを示しています。無効なユーザー名/パスワードのため、またはユーザー アカウントがログオンに必要とされるアクセス許可またはユーザー権限を持たないため、認証が失敗した可能性があります。完全な状態コードおよびその説明については、マイクロソフト サポート技術情報IIS Status Codes (英語) をご覧ください。

質問 (b): Windows 2000 Server を実行している私のコンピュータには anonymous@ftp.msft.comがありません。また、匿名アクセスは許可していませんでした。このユーザーはユーザー名を推測することによりログオンしようとしているのですか?
回答 (b): はい。匿名アクセスを無効にしているため、標準の電子メール フォーマットのユーザー名は機能しません。 "administrator" またはユーザー データベースに存在している任意のユーザー名のようなログオンが確認される場合、攻撃者は既知のユーザー名を悪用してログオンしようとしている可能性が高いと思われます。

質問(c):2 行目で、PASS – 530 とはユーザーがログオンしなかったことを意味しているのですか?
回答 (c):はい。上記の最初の質問に対する回答をご覧ください。また、マイクロソフト サポート技術情報 Err Msg: 530 User <Username> Cannot Log In. Login Failed (英語)」もあわせてご覧ください。

質問 (d): 6 行目で、電子メール アドレスはなぜ PASS と 530 の間にあるのですか?
回答 (d): これはよい質問です。3 行目と 6 行目のログ エントリは両方ともユーザーが匿名でログインしようとしていることを示しています。「匿名」として cs-username が見られます。匿名アカウントでも、ユーザーは依然としてパスワードを提供する必要があります。パスワードはどのような形式の何でも可能です。しかし、IIS FTP は次のように応答します。"331 Anonymous access allowed, send identity (e-mail name) as password." (「331 匿名アクセスが許可されました。ID (電子メール名) をパスワードとして送信してください。」) このため、ほとんどのユーザーが電子メール アドレスをパスワードとして入力するでしょう。この匿名のパスワードは ＦＴＰ ログ ファイルでキャプチャされます。

質問 (e): 8 行目の最後で、IEUser@ がなぜ PASS フィールドにあるのですか?
回答 (e): これは明らかにユーザーが Internet Explorer (IE) を使用していることを示しています。既定で、IE は FTP サイトをブラウジングする時、自動的に匿名としてログオンします。このため、ユーザー名「匿名」が見られ、IEUser@ は単に IE により使用されるパスワードです。

質問 (f): 最後の 2 つのログ エントリは FTP にログオンしたユーザーを示しているのですか?
回答 (f): はい。これは PASS の状態コードが 230 (これは正常なログオンを示しています) であるためです。しかし、IIS はログ ファイルにログオン ユーザーのパスワードを保存しないことに注意してください。

これは IIS SMTP についての一般的な質問です。まず、次のサポート技術情報に記載されているステップにしたがうことにより、トラブルシューティングを始めることを推奨します。Pickup フォルダにファイルを置くことによって送信メールの流れをテストする方法 (英語) 　これは単に SMTP の基本的な機能をテストするものです。このサポート技術情報では、指定された形式でプレーン テキスト ファイルを作成します。SMTP が機能している場合、メールは配信されます。
メールがサーバーでスタックしている場合、それは通常 DNS の問題が原因となっています。たとえば、SMTP コンポーネントは受信者の電子メール ドメイン MX 記録を解決できない可能性があります。IIS 5.1 およびそれ以前のバージョンでは、SMTP は TCP DNS クエリをサポートするのみです。クエリが失敗すると、メールは配信されません。(Microsoft Windows Server 2003 および IIS 6.0 は TCP および UDP の両方をサポートします。) このため、サーバーでスタックしているメールが DNS の問題であるかどうかをテストするためには、次のサポート技術情報に記載されているステップにしたがってください。Windows 2000 と Exchange 2000 の SMTP のDNS 問い合わせ (英語)
このようなトラブルシューティングが必要となることを避けるために、SMTPDiag (英語) という診断ツールをダウンロードすることができます。このツールは Microsoft Exchange Server チームから提供されています。これは DNS MX 解決を含む SMTP 関連の問題のトラブルシューティングを行なう手助けとなり、リモート ホストへの接続のテストなどを行います。また、これは Exchange Server を必要としません。これが必要とするものは SMTP コンポーネントのみです。またこのツールは非常に小さいもので、わずか 96 KB です。ここにこの診断ツールのプロセスの出力のサンプルを挙げます。

D:\Tools\SmtpDiag>SmtpDiag.exe "sender@sender.com" "foobar@foobar.com" /v
Searching for Exchange external DNS settings.
Computer name is XXXXX.
Failed to connect to the domain controller. Error: 8007054b ?<-- You can ignore this if you are 
not in Active Directory domain.

Checking SOA for foobar.com.
Checking external DNS servers.
Checking internal DNS servers.

Checking TCP/UDP SOA serial number using DNS server [xxx.xxx.xxx.xxx].
TCP test succeeded.
UDP test failed. ?<-- Windows 2000 Server behavior
Serial number: 2004092100

Checking TCP/UDP SOA serial number using DNS server [xxx.xxx.xxx.xxx].
TCP test succeeded.
UDP test failed.
Serial number: 2004092100
SOA serial number match: Passed.

Checking local domain records.
Starting TCP and UDP DNS queries for the local domain. This test will try to validate that DNS is set up correctly 
for inbound mail. This test can fail for 3 reasons.
    1) Local domain is not set up in DNS. Inbound mail cannot be routed to local mailboxes.
    2) Firewall blocks TCP/UDP DNS queries. This will not affect inbound mail, but will affect outbound mail.
    3) Internal DNS is unaware of external DNS settings. This is a valid configuration for certain topologies.
Checking MX records using TCP: sender.com.
  A:     sender.com [xxx.xxx.xxx.xxx]
Checking MX records using UDP: sender.com.
  A:     sender.com [xxx.xxx.xxx.xxx]   
Both TCP and UDP queries succeeded. Local DNS test passed.

Checking remote domain records.
Starting TCP and UDP DNS queries for the remote domain. This test will try to validate that DNS is set up correctly 
for outbound mail. This test can fail for 3 reasons.
    1) Firewall blocks TCP/UDP queries which will block outbound mail. Windows 2000/NT Server requires TCP DNS queries. 
   Windows Server 2003 will use UDP queries first, then fall back to TCP queries.
    2) Internal DNS does not know how to query external domains. You must either use an external DNS server or 
   configure DNS server to query external domains.
    3) Remote domain does not exist. Failure is expected.
Checking MX records using TCP: foobar.com.
  MX:    gsmtp171.foo.com (10)
  MX:    gsmtp57.foo.com (20)
  A:     gsmtp171.foo.com [64.233.171.27]
  A:     gsmtp57.foo.com [216.239.57.27]
Checking MX records using UDP: foobar.com.
  MX:    gsmtp171.foo.com (10)
  MX:    gsmtp57.foo.com (20)
Both TCP and UDP queries succeeded. Remote DNS test passed.

Checking MX servers listed for foobar@foobar.com.
Connecting to gsmtp171.foo.com [64.233.171.27] on port 25.
Received: 
220 mx.foobar.com ESMTP 73si601551rna
Sent: 
ehlo sender.com

Received: 
250-mx.foobar.com at your service
250-SIZE 20971520
250 8BITMIME
Sent: 
mail from: <sender@sender.com>
Received: 
250 OK
Sent: 
rcpt to: <foobar@foobar.com>
Received: 
250 OK
Sent: 
quit

Received: 
221 mx.foobar.com closing connection
Successfully connected to gsmtp171.foo.com.
Connecting to gsmtp57.foo.com [216.239.57.27] on port 25.

Received: 
220 mx.foobar.com ESMTP v71si245850cwb
Sent: 
ehlo sender.com
Received: 
250-mx.foobar.com at your service
250-SIZE 20971520
250 8BITMIME
Sent: 
mail from: <sender@sender.com>
Received: 
250 OK
Sent: 
rcpt to: <qbernard@foobar.com>
Received: 
250 OK
Sent: 
quit
Received: 
221 mx.foobar.com closing connection

Successfully connected to gsmtp57.foo.com.

このため、行なう必要のあることは、ベースとして出力を使用し、次に各問題のエリアに焦点を当てることです。たとえば、 SMTPDiag が MX レコードを解決できないことを示す場合、SMTP ホストは TCP/UDP ポート 53 を介し MX レコードをクエリできることをチェックしてください。

それはとてもよい質問です。そのご苦労はよくわかります。私自身も時々混乱します。それではどのように考えてみましょうか。まず、ブラウザの制限から見てみましょう。HTTP GET リクエストについて、Internet Explorer はそのリクエストを、サポート技術情報「 [IE] URL に使用可能な文字数は最大 2,083 文字 (英語)」 の通り、2,083 文字に制限します。 これは、サポート技術情報に説明されているように HTTP POST には当てはまりません。 HTTP GET および POST に関する詳細情報は、RFC 2616 (英語) の HTTP/1.1 メソッドの定義をご覧ください。
それではサーバー側の制限について、我々は次を知っています。

* URLScan をインストールしている場合、URLScan.ini. に追加のリクエスト制限の設定を設定することができます。URLScan に関する詳細情報は、「 IIS の URLScan を使用する (英語)」 をご覧ください。 さらに IIS 6.0 には HTTP.sys 設定があります。詳細情報は、「IIS 用の Http.sys レジストリ設定 (英語)」をご覧ください。
各構成設定間の関係の定義に移る前に、各設定をここで手短に説明します。

次は URLScan リクエストの制限の設定です。

上記の表で、これらは URLScan 2.5 の既定の構成の設定であることに注意してください。URLScan.ini ファイルで変更が行なわれます。また、特定のリクエスト ヘッダーに自分特有のリクエストの制限を課すこともできます。詳細情報は、「IIS の URLScan を使用する(英語)」をご覧ください。
次は HTTP.sys リクエストの制限の設定です。

これらの設定は IIS 6.0 に URLScan により提供される機能または構成の一部に間接的に変換されることに注意してください。IIS 6.0 で URLScan を適用するかどうかを決定するためには、「IIS 6.0 で URLScan 2.5 を使用するかどうかを決定する」 の欄をご覧ください。変更は次のレジストリ キーで行うことができます。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.

これまでで、すべての異なるリクエストの制限の設定をよくご理解いただけたと思います。それでは、設定間の関係を見てみましょう。たとえば、最初にどの制限が課されるべきでしょうか?

手短に言えば、MaxClientRequestBuffer の制限は MaxRequestEntityAllowed と同等です。IIS 6.0 で、マイクロソフトは、HTTP.sys のリクエストの制限の制御ばかりでなく、AspMaxRequestEntityAllowed などのリクエストの制限の制御に対しさらに粒度を提供します。

それでは、次にどのような順序で制限が適用されるかについて見てみましょう。図 3.1 は IIS の適用されたリクエスト制限の順番を示しています。IIS 6.0 を実行していない場合、HTTP.sys セクションは適用されません。

図 3.1 IIS のリクエスト制限

OK! これですべてです。IIS での異なるリクエストの制限の設定をよりよくご理解いただけたことを願います。それでは次回まで、ごきげんよう!