RFC 7768 - Port Management to Reduce Logging in Large-Scale NATs 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7768
タイトル : RFC 7768 - 大規模NATでのロギングを削減するポート管理
翻訳編集 : 自動生成

[要約] RFC 7768は、大規模なNATでのログ記録を減らすためのポート管理に関するガイドラインです。その目的は、NATデバイスのパフォーマンスを向上させ、ログの負荷を軽減することです。

Independent Submission                                           T. Tsou
Request for Comments: 7768                              Philips Lighting
Category: Informational                                            W. Li
ISSN: 2070-1721                                            China Telecom
                                                               T. Taylor
                                                                J. Huang
                                                     Huawei Technologies
                                                            January 2016

Port Management to Reduce Logging in Large-Scale NATs

大規模NATでのロギングを削減するポート管理

Abstract

概要

Various IPv6 transition strategies require the introduction of large-scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low.

さまざまなIPv6移行戦略では、移行が完了するまでネットワークで利用可能なIPv4アドレスの限られた供給を共有するために、大規模なNAT（AFTRやNAT64など）の導入が必要です。最近、同じIPv4アドレスを共有する異なるサブスクライバー間でのポートの共有を管理する方法についての議論があります。説明の1つの要素は、サブスクライバーへのトランスポートアドレスの割り当てをログに記録するための運用要件です。サブスクライバー間で個々のポートを動的に割り当てるには、大量のログを生成する必要があると主張されてきました。このドキュメントでは、ログのボリュームを低く抑えながら動的なポート共有を実現する方法を提案しています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7768.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7768で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  A Suggested Solution  . . . . . . . . . . . . . . . . . . . .   3
   3.  Issues Of Traceability  . . . . . . . . . . . . . . . . . . .   4
   4.  Other Considerations  . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Configure Server Software to Log Source Port . . . .   9
     A.1.  Apache  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     A.2.  Postfix . . . . . . . . . . . . . . . . . . . . . . . . .   9
     A.3.  Sendmail  . . . . . . . . . . . . . . . . . . . . . . . .   9
     A.4.  sshd  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.5.  Cyrus IMAP and UW IMAP  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

During the IPv6 transition period, some large-scale NAT devices may be introduced, e.g., Dual-Stack Lite (DS-Lite), Address Family Transition Router (AFTR), and NAT64. When a NAT device needs to set up a new connection for a given internal address behind the NAT, it needs to create a new mapping entry for the new connection, which will contain source IP address, source port or ICMP identifier, converted source IP address, converted source port, protocol (TCP/ UDP), etc.

IPv6移行期間中に、デュアルスタックライト（DS-Lite）、アドレスファミリートランジションルーター（AFTR）、NAT64などの大規模なNATデバイスが導入される場合があります。 NATデバイスは、NATの背後にある特定の内部アドレスに新しい接続を設定する必要がある場合、送信元IPアドレス、送信元ポート、またはICMP識別子、変換された送信元IPアドレスを含む、新しい接続の新しいマッピングエントリを作成する必要があります、変換された送信元ポート、プロトコル（TCP / UDP）など

Due to legislation and law enforcement requirement, sometimes it is necessary to log these mappings for a period of time, such as 6 months. The mapping information is highly privacy sensitive; if possible, the information should be deleted as soon as possible. Some high-performance NAT devices may need to create a large amount of new sessions per second. If logs are generated for each mapping entry, the log traffic could reach tens of megabytes per second or more, which would be a problem for log generation, transmission and storage. According to a test discussed in "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses" [ALLOC-METHODS], in a network with 20,000 subscribers, over a 60-day period, the raw log size can reach 42.5 TB if it is based on per-session log, while the log size will be 40.6 GB if it is based on port blocks. Although compression technologies can be used before log storage, the log size is still big.

法律と法執行の要件により、これらのマッピングを一定期間（6か月など）記録する必要がある場合があります。マッピング情報はプライバシーに非常に敏感です。可能であれば、情報をできるだけ早く削除する必要があります。一部の高性能NATデバイスは、毎秒大量の新しいセッションを作成する必要がある場合があります。マッピングエントリごとにログが生成される場合、ログトラフィックは数十メガバイト/秒以上に達する可能性があり、これはログの生成、送信、および保存に問題となります。「共有IPv4アドレスのNAT64ポート割り当て方法の分析」[ALLOC-METHODS]で説明されているテストによると、60日間でサブスクライバーが20,000のネットワークでは、生のログサイズは42.5 TBに達する可能性があります。セッションごとのログでは、ポートブロックに基づく場合、ログサイズは40.6 GBになります。ログを保存する前に圧縮技術を使用できますが、ログのサイズは依然として大きくなります。

[RFC6888], REQ-13 suggests "maximize port utilization" and REQ-14 suggests "minimize log volume". However, it is difficult to achieve both; there will be a trade-off between the efficiency with which ports are used and the rate of generation of log records.

[RFC6888]、REQ-13は「ポート使用率を最大にする」ことを提案し、REQ-14は「ログボリュームを最小化する」ことを提案します。ただし、両方を達成することは困難です。ポートの使用効率とログレコードの生成率の間にはトレードオフがあります。

2. A Suggested Solution

2. 推奨されるソリューション

This document proposes a solution that allows dynamic sharing of port ranges between users while minimizing the number of logs that have to be generated. Briefly, ports are allocated to the user in blocks. Logs are generated only when blocks are allocated or deallocated. This provides the necessary traceability while reducing log generation by a factor equal to the block size, as compared with fully dynamic port allocation.

このドキュメントでは、生成する必要があるログの数を最小限に抑えながら、ユーザー間でポート範囲を動的に共有できるソリューションを提案します。簡単に言うと、ポートはブロック単位でユーザーに割り当てられます。ログが生成されるのは、ブロックが割り当てまたは割り当て解除された場合のみです。これにより、必要なトレーサビリティが提供されると同時に、完全に動的なポート割り当てと比較して、ブロックサイズに等しい係数でログ生成が削減されます。

This is how the proposal works in greater detail. When the user sends out the first packet, a port resource pool is allocated for the user, e.g., assigning ports 2001~2300 of a public IP address to the user's resource pool. Only one log should be generated for this port block. When the NAT needs to set up a new mapping entry for the user, it can use a port in the user's resource pool and the corresponding public IP address. If the user needs more port resources, the NAT can allocate another port block, e.g., ports 3501~3800, to the user's resource pool. Again, just one log needs to be generated for this port block.

これは、提案がより詳細に機能する方法です。ユーザーが最初のパケットを送信すると、ポートリソースプールがユーザーに割り当てられます。たとえば、パブリックIPアドレスのポート2001〜2300がユーザーのリソースプールに割り当てられます。このポートブロックに対して生成されるログは1つだけです。 NATがユーザーの新しいマッピングエントリを設定する必要がある場合、ユーザーのリソースプールのポートと対応するパブリックIPアドレスを使用できます。ユーザーがより多くのポートリソースを必要とする場合、NATはユーザーのリソースプールに別のポートブロック（ポート3501〜3800など）を割り当てることができます。この場合も、このポートブロックに対して生成する必要があるログは1つだけです。

[RFC6431] takes this idea further by allocating non-contiguous sets of ports using a pseudorandom function. Scattering the allocated ports in this way provides a modest barrier to port guessing attacks. The use of randomization is discussed further in Section 5.

[RFC6431]は、疑似ランダム関数を使用して隣接しないポートのセットを割り当てることにより、この考えをさらに取り入れています。このように割り当てられたポートを分散させると、ポート推測攻撃に対する適度な障壁が提供されます。ランダム化の使用については、セクション5でさらに説明します。

Suppose now that a given internal address has been assigned more than one block of ports. The individual sessions using ports within a port block will start and end at different times. If no ports in some port block are used for some configurable time, the NAT can remove the port block from the resource pool allocated to a given internal address and make it available for other users. In theory, it is unnecessary to log deallocations of blocks of ports, because the ports in deallocated blocks will not be used again until the blocks are reallocated. However, the deallocation may be logged when it occurs adding robustness to troubleshooting or other procedures.

ここで、特定の内部アドレスに複数のポートブロックが割り当てられているとします。ポートブロック内のポートを使用する個々のセッションは、異なる時間に開始および終了します。一部のポートブロックのポートが構成可能な時間使用されない場合、NATは特定の内部アドレスに割り当てられたリソースプールからポートブロックを削除し、他のユーザーが使用できるようにすることができます。理論的には、ブロックが再割り当てされるまで、割り当て解除されたブロック内のポートは再び使用されないため、ポートのブロックの割り当て解除をログに記録する必要はありません。ただし、割り当て解除は、発生時にログに記録され、トラブルシューティングやその他の手順に堅牢性が追加されます。

The deallocation procedure presents a number of difficulties in practice. The first problem is the choice of timeout value for the block. If idle timers are applied for the individual mappings (sessions) within the block, and these conform to the recommendations for NAT behavior for the protocol concerned, then the additional time that might be configured as a guard for the block as a whole need not be more than a few minutes. The block timer in this case serves only as a slightly more conservative extension of the individual session idle timers. If, instead, a single idle timer is used for the whole block, it must itself conform to the recommendations for the protocol with which that block of ports is associated. For example, REQ-5 of [RFC5382] requires an idle timer expiry duration of at least 2 hours and 4 minutes for TCP.

割り当て解除手順には、実際には多くの困難があります。最初の問題は、ブロックのタイムアウト値の選択です。アイドルタイマーがブロック内の個々のマッピング（セッション）に適用され、これらが関係するプロトコルのNAT動作の推奨事項に準拠している場合、ブロック全体のガードとして構成されている可能性のある追加の時間は必要ありません数分以上。この場合のブロックタイマーは、個々のセッションアイドルタイマーのやや保守的な拡張としてのみ機能します。代わりに、ブロック全体で単一のアイドルタイマーが使用される場合、それ自体が、そのポートのブロックが関連付けられているプロトコルの推奨事項に準拠する必要があります。たとえば、[RFC5382]のREQ-5では、TCPに対して少なくとも2時間4分のアイドルタイマーの有効期限が必要です。

The next issue with port block deallocation is the conflict between the desire to randomize port allocation and the desire to make unused resources available to other internal addresses. As mentioned above, ideally port selection will take place over the entire set of blocks allocated to the internal address. However, taken to its fullest extent, such a policy will minimize the probability that all ports in any given block are idle long enough for it to be released.

ポートブロックの割り当て解除に関する次の問題は、ポートの割り当てをランダム化したいという欲求と、未使用のリソースを他の内部アドレスが利用できるようにしたいという欲求との対立です。上記のように、ポート選択は、内部アドレスに割り当てられたブロックのセット全体で行われるのが理想的です。ただし、このようなポリシーを最大限に活用すると、特定のブロック内のすべてのポートが解放されるまでアイドル状態になる可能性が最小限に抑えられます。

As an alternative, it is suggested that when choosing which block to select a port from, the NAT should omit from its range of choice the block that has been idle the longest, unless no ports are available in any of the other blocks. The expression "block that has been idle the longest" designates the block in which the time since the last packet was observed in any of its sessions, in either direction, is earlier than the corresponding time in any of the other blocks assigned to that internal address.

別の方法として、ポートを選択するブロックを選択するときに、他のブロックで使用できるポートがない場合を除いて、NATはその選択範囲から最も長くアイドル状態であったブロックを除外することをお勧めします。「最も長い間アイドル状態だったブロック」という表現は、最後のパケットがいずれかのセッションでいずれかの方向に観測されてからの時間が、その内部に割り当てられた他のブロックの対応する時間よりも早いブロックを示します。住所。

3. Issues Of Traceability

3. トレーサビリティの問題

Section 12 of [RFC6269] provides a good discussion of the traceability issue. Complete traceability given the NAT-logging practices proposed in this document requires that the remote destination record the source port of a request along with the source address (and presumably protocol, if not implicit). In addition, the logs at each end must be timestamped, and the clocks must be synchronized within a certain degree of accuracy. Here is one reason for the guard timing on block release, to increase the tolerable level of clock skew between the two ends.

[RFC6269]のセクション12では、トレーサビリティの問題について適切に説明しています。このドキュメントで提案されているNATロギングプラクティスを踏まえた完全なトレーサビリティでは、リモート宛先が要求の送信元ポートと送信元アドレス（およびおそらく暗黙的でない場合はプロトコル）を記録する必要があります。さらに、両端のログにタイムスタンプを付け、クロックをある程度の精度で同期させる必要があります。これは、2つの端の間のクロックスキューの許容レベルを上げるための、ブロック解放時のガードタイミングの1つの理由です。

The ability to configure various server applications to record source ports has been investigated, with the following results:

さまざまなサーバーアプリケーションを構成して送信元ポートを記録する機能が調査され、次の結果が得られました。

o Source-port recording can be configured in Apache, Postfix, sendmail, and sshd. Please refer to the Appendix for the configuration guide.

o ソースポートの記録は、Apache、Postfix、sendmail、およびsshdで構成できます。構成ガイドについては、付録を参照してください。

o Source-port recording is not supported by IIS, Cyrus IMAP, and UW IMAP. But it should not be too difficult to get Cyrus IMAP and UW IMAP to support it by modifying the source code.

o ソースポートの記録は、IIS、Cyrus IMAP、およびUW IMAPではサポートされていません。しかし、Cyrus IMAPとUW IMAPがソースコードを変更してそれをサポートするようにするのはそれほど難しくないはずです。

Where source-port logging can be enabled, this memo strongly urges the operators to do so. Similarly, intrusion detection systems should capture source port as well as source address of suspect packets.

送信元ポートのロギングを有効にできる場合、このメモはそうすることをオペレーターに強く促します。同様に、侵入検知システムは、疑わしいパケットの送信元ポートと送信元アドレスをキャプチャする必要があります。

In some cases [RFC6269], a server may not record the source port of a connection. To allow traceability, the NAT device needs to record the destination IP address of a connection. As [RFC6269] points out, this will provide an incomplete solution to the issue of traceability because multiple users of the same shared public IP address may access the service at the same time. From the point of view of this document, in such situations the game is lost, so to speak, and port allocation at the NAT might as well be completely dynamic.

場合によっては[RFC6269]、サーバーが接続の送信元ポートを記録しないことがあります。トレーサビリティを可能にするために、NATデバイスは接続の宛先IPアドレスを記録する必要があります。 [RFC6269]が指摘しているように、同じ共有パブリックIPアドレスの複数のユーザーが同時にサービスにアクセスする可能性があるため、これはトレーサビリティの問題に対する不完全なソリューションを提供します。このドキュメントの観点からは、そのような状況では、いわばゲームが失われ、NATでのポート割り当ても完全に動的になる可能性があります。

The final possibility to consider is where the NAT does not do per-session logging even given the possibility that the remote end is failing to capture source ports. In that case, the port allocation policy proposed in this document can be used. The impact on traceability is that analysis of the logs would yield only the list of all internal addresses mapped to a given public address during the period of time concerned. This has an impact on privacy as well as traceability, depending on the follow-up actions taken.

考慮すべき最後の可能性は、リモートエンドが送信元ポートのキャプチャに失敗している可能性があっても、NATがセッションごとのロギングを行わない場合です。その場合、このドキュメントで提案されているポート割り当てポリシーを使用できます。トレーサビリティへの影響は、ログの分析により、関係する期間中に特定のパブリックアドレスにマップされたすべての内部アドレスのリストのみが生成されることです。これは、行われたフォローアップアクションに応じて、プライバシーとトレーサビリティに影響を与えます。

4. Other Considerations

4. その他の考慮事項

[RFC6269] notes several issues introduced by the use of dynamic, as opposed to static, port assignment. For example, Section 13.2 of that document notes the effect on authentication procedures. These issues must be resolved, but are not specific to the port allocation policy described in this document.

[RFC6269]は、静的なポート割り当てではなく、動的なポート割り当ての使用によって導入されたいくつかの問題に言及しています。たとえば、そのドキュメントのセクション13.2は、認証手順への影響を示しています。これらの問題は解決する必要がありますが、このドキュメントで説明されているポート割り当てポリシーに固有のものではありません。

5. Security Considerations

5. セキュリティに関する考慮事項

The discussion that follows addresses an issue that is particularly relevant to the proposal made in this document. The security considerations applicable to NAT operation for various protocols as documented in, for example, [RFC4787] and [RFC5382] also apply to this proposal.

以下の議論は、この文書で行われた提案に特に関連する問題に対処します。たとえば、[RFC4787]や[RFC5382]で文書化されているように、さまざまなプロトコルのNAT操作に適用できるセキュリティの考慮事項は、この提案にも適用されます。

[RFC6056] summarizes the TCP port-guessing attack, by means of which an attacker can hijack one end of a TCP connection. One mitigating measure is to make the source port number used for a TCP connection less predictable. [RFC6056] provides various algorithms for this purpose.

[RFC6056]は、攻撃者がTCP接続の一方の端を乗っ取ることができるTCPポート推測攻撃を要約しています。緩和策の1つは、TCP接続に使用される送信元ポート番号を予測不可能にすることです。 [RFC6056]は、この目的のためのさまざまなアルゴリズムを提供します。

As Section 3.1 of that RFC notes: "...provided adequate algorithms are in use, the larger the range from which ephemeral ports are selected, the smaller the chances of an attacker are to guess the selected port number." Conversely, the reduced range sizes proposed by the present document increase the attacker's chances of guessing correctly. This result cannot be totally avoided. However, mitigating measures to improve this situation can be taken both at port-block assignment time and when selecting individual ports from the blocks that have been allocated to a given user.

そのRFCのセクション3.1が注記しているように、「...適切なアルゴリズムが使用されている場合、一時ポートが選択される範囲が大きいほど、攻撃者が選択されたポート番号を推測する可能性が小さくなります。」逆に、現在のドキュメントで提案されている範囲サイズを小さくすると、攻撃者が正確に推測できる可能性が高くなります。この結果を完全に回避することはできません。ただし、この状況を改善するための緩和策は、ポートブロックの割り当て時と、特定のユーザーに割り当てられているブロックから個々のポートを選択するときの両方で実行できます。

At assignment time, one possibility is to assign ports as non-contiguous sets of values as proposed in [RFC6431]. However, this approach creates a lot of complexity for operations, and the pseudorandomization can create uncertainty when the accuracy of logs is important to protect someone's life or liberty.

割り当て時に、1つの可能性は、[RFC6431]で提案されているように、ポートを隣接しない値のセットとして割り当てることです。ただし、このアプローチは操作に多くの複雑さをもたらし、疑似ランダム化は、ログの正確さが誰かの生命または自由を保護するために重要である場合に不確実性を生み出す可能性があります。

Alternatively, the NAT can assign blocks of contiguous ports. However, at assignment time, the NAT could attempt to randomize its choice of which of the available idle blocks it would assign to a given user. This strategy has to be traded-off against the desirability of minimizing the chance of conflict between what [RFC6056] calls "transport protocol instances" by assigning the most-idle block, as suggested in Section 2. A compromise policy might be to assign blocks only if they have been idle for a certain amount of time, and select pseudorandomly between the blocks available according to this criterion. In this case, it is suggested that the time value used be greater than the guard timing mentioned in Section 2, and that no block should ever be reassigned until it has been idle at least for the duration given by the guard timer.

あるいは、NATは隣接するポートのブロックを割り当てることができます。ただし、割り当て時に、NATは、使用可能なアイドルブロックのうち、特定のユーザーに割り当てるものをランダムに選択しようとする可能性があります。この戦略は、セクション2で提案されているように、最もアイドル状態のブロックを割り当てることにより、[RFC6056]が「トランスポートプロトコルインスタンス」と呼ぶものの間の競合の可能性を最小限に抑えるという望ましさとの間でトレードオフする必要があります。それらが一定時間アイドル状態である場合にのみ、この基準に従って使用可能なブロック間で擬似ランダムに選択します。この場合、使用される時間値はセクション2で述べたガードタイミングよりも大きく、少なくともガードタイマーで指定された期間アイドル状態になるまでブロックを再割り当てしないことをお勧めします。

While the block assignment strategy can provide some mitigation of the port-guessing attack, the largest contribution will come from pseudorandomization at port-selection time. [RFC6056] provides a number of algorithms for achieving this pseudorandomization. When the available ports are contained in blocks, which are not in general consecutive, the algorithms clearly need some adaptation. The task is complicated by the fact that the number of blocks allocated to the user may vary over time. Adaptation is left as an exercise for the implementor.

ブロック割り当て戦略はポート推測攻撃をある程度軽減することができますが、最大の貢献はポート選択時の疑似ランダム化によるものです。 [RFC6056]は、この擬似ランダム化を実現するためのいくつかのアルゴリズムを提供します。利用可能なポートが一般に連続していないブロックに含まれている場合、アルゴリズムは明らかにいくつかの適応を必要とします。ユーザーに割り当てられたブロックの数が時間とともに変化する可能性があるという事実により、タスクは複雑になります。適応は実装者のための練習問題として残されています。

6. Informative References

6. 参考引用

[ALLOC-METHODS] Chen, G., Li, W., Tsou, T., Huang, J., Taylor, T., and J. Tremblay, "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Work in Progress, draft-ietf-sunset4-nat64-port-allocation-02, January 2016.

[ALLOC-METHODS] Chen、G.、Li、W.、Tsou、T.、Huang、J.、Taylor、T.、J。Tremblay、「Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses」、Work in進捗状況、draft-ietf-sunset4-nat64-port-allocation-02、2016年1月。

[APACHE_LOG_CONFIG] The Apache Software Foundation, "Apache Module mod_log_config", <http://httpd.apache.org/docs/2.4/mod/ mod_log_config.html>.

[APACHE_LOG_CONFIG] Apache Software Foundation、「Apache Module mod_log_config」、<http://httpd.apache.org/docs/2.4/mod/ mod_log_config.html>。

[POSTFIX_LOG_CONFIG] "Postfix Configuration Parameters", <http://www.postfix.org/postconf.5.html>.

[POSTFIX_LOG_CONFIG]「Postfix構成パラメーター」、<http://www.postfix.org/postconf.5.html>。

[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.

[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<http://www.rfc-editor.org/info/rfc4787> 。

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.

[RFC5382] Guha、S。、編、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT動作要件」、BCP 142、RFC 5382、DOI 10.17487 / RFC5382、 2008年10月、<http://www.rfc-editor.org/info/rfc5382>。

[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.

[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<http://www.rfc-editor.org/info / rfc6056>。

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.

[RFC6269]フォード、M。、エド、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <http://www.rfc-editor.org/info/rfc6269>。

[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. Tsou, "Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)", RFC 6431, DOI 10.17487/RFC6431, November 2011, <http://www.rfc-editor.org/info/rfc6431>.

[RFC6431] Boucadair、M.、Levis、P.、Bajko、G.、Savolainen、T。、およびT. Tsou、「Huawei Port Range Configuration Options for PPP IP Control Protocol（IPCP）」、RFC 6431、DOI 10.17487 / RFC6431、2011年11月、<http://www.rfc-editor.org/info/rfc6431>。

[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.

[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 DOI 10.17487 / RFC6888、2013年4月、<http://www.rfc-editor.org/info/rfc6888>。

[SENDMAIL_LOG_CONFIG] O'Reilly, "Sendmail, 3rd Edition, Page 798", December 2002.

[SENDMAIL_LOG_CONFIG] O'Reilly、「Sendmail、第3版、ページ798」、2002年12月。

[SSHD_LOG_CONFIG] "sshd_config OpenSSH SSH daemon configuration file", <http://www.openbsd.org/cgi-bin/ man.cgi?query=sshd_config&sektion=5>.

[SSHD_LOG_CONFIG] "sshd_config OpenSSH SSHデーモン構成ファイル"、<http://www.openbsd.org/cgi-bin/ man.cgi？query = sshd_config＆sektion = 5>。

Appendix A. Configure Server Software to Log Source Port

付録A.サーバーソフトウェアを構成してソースポートをログに記録する

A.1. Apache

The user can use the LogFormat command to define a customized log format and use the CustomLog command to apply that log format. "%a" and "%{remote}p" can be used in the format string to require logging the client's IP address and source port, respectively. This feature has been available since Apache version 2.1.

ユーザーは、LogFormatコマンドを使用してカスタマイズされたログ形式を定義し、CustomLogコマンドを使用してそのログ形式を適用できます。 "％a"と "％{remote} p"をフォーマット文字列で使用して、クライアントのIPアドレスとソースポートをそれぞれログに記録する必要があります。この機能は、Apacheバージョン2.1以降で使用できます。

A detailed configuration guide can be found at [APACHE_LOG_CONFIG].

詳細な構成ガイドは、[APACHE_LOG_CONFIG]にあります。

A.2. Postfix

In order to log the client source port, macro smtpd_client_port_logging should be set to "yes" in the configuration file [POSTFIX_LOG_CONFIG].

クライアントのソースポートをログに記録するには、構成ファイル[POSTFIX_LOG_CONFIG]でマクロsmtpd_client_port_loggingを「yes」に設定する必要があります。

This feature has been available since Postfix version 2.5.

この機能はPostfixバージョン2.5以降で利用可能です。

A.3. Sendmail

Sendmail has a macro ${client_port} storing the client port. To log the source port, the user can define some check rules. Here is an example that should be in the .mc configuration macro [SENDMAIL_LOG_CONFIG]:

Sendmailには、クライアントポートを格納するマクロ$ {client_port}があります。送信元ポートを記録するために、ユーザーはいくつかのチェックルールを定義できます。 .mc構成マクロ[SENDMAIL_LOG_CONFIG]に含める必要のある例を次に示します。

LOCAL_CONFIG Klog syslog

LOCAL_CONFIG賢いsyslog

   LOCAL_RULESETS
   SLocal_check_mail
   R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $)

This feature has been available since version 8.10.

この機能は、バージョン8.10以降で使用できます。

A.4. sshd

SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives the verbosity level that is used when logging messages from sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended. SyslogFacility Gives the facility code that is used when logging messages from sshd(8). The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, and LOCAL7. The default is AUTH.

SSHD_CONFIG（5）OpenBSDプログラマーズマニュアルSSHD_CONFIG（5）名前sshd_config-OpenSSH SSHデーモン構成ファイルLogLevel sshd（8）からのメッセージをログに記録するときに使用される詳細レベルを指定します。可能な値は、QUIET、FATAL、ERROR、INFO、VERBOSE、DEBUG、DEBUG1、DEBUG2、およびDEBUG3です。デフォルトはINFOです。 DEBUGとDEBUG1は同等です。 DEBUG2とDEBUG3はそれぞれ、より高いレベルのデバッグ出力を指定します。 DEBUGレベルでのロギングは、ユーザーのプライバシーを侵害するため、お勧めできません。 SyslogFacility sshd（8）からのメッセージをログに記録するときに使用される機能コードを提供します。可能な値は、DAEMON、USER、AUTH、LOCAL0、LOCAL1、LOCAL2、LOCAL3、LOCAL4、LOCAL5、LOCAL6、およびLOCAL7です。デフォルトはAUTHです。

sshd supports logging the client IP address and client port when a client starts connection since version 1.2.2; here is the source code in sshd.c:

sshdは、バージョン1.2.2以降、クライアントが接続を開始したときのクライアントIPアドレスとクライアントポートのロギングをサポートしています。ここにsshd.cのソースコードがあります：

... verbose("Connection from %.500s port %d", remote_ip, remote_port); ...

... verbose（ "％。500sポート％dからの接続"、remote_ip、remote_port）; ...

sshd supports logging the client IP address when a client disconnects in version 1.2.2 to version 5.0. Since version 5.1, sshd supports logging the client IP address and source port. Here is the source code in sshd.c:

sshdは、クライアントがバージョン1.2.2からバージョン5.0に切断したときのクライアントIPアドレスのロギングをサポートしています。バージョン5.1以降、sshdはクライアントIPアドレスと送信元ポートのロギングをサポートしています。 sshd.cのソースコードは次のとおりです。

   ...
   /* from version 1.2.2 to 5.0*/
   verbose("Closing connection to %.100s", remote_ip);
   ...

   /* since version 5.1*/
   verbose("Closing connection to %.500s port %d",
   remote_ip, remote_port);

In order to log the source port, the LogLevel should be set to VERBOSE [SSHD_LOG_CONFIG] in the configuration file:

ソースポートをログに記録するには、構成ファイルでLogLevelをVERBOSE [SSHD_LOG_CONFIG]に設定する必要があります。

LogLevel VERBOSE

A.5. Cyrus IMAP and UW IMAP

A.5. Cyrus IMAPとYOUR IMAP

Cyrus IMAP and UW IMAP do not support logging the source port for the time being. Both software use syslog to create logs; it should not be too difficult to get it supported by adding some new code.

Cyrus IMAPおよびUW IMAPは、当面の間、送信元ポートのロギングをサポートしていません。どちらのソフトウェアも、syslogを使用してログを作成します。新しいコードを追加してサポートすることはそれほど難しくありません。

Acknowledgements

謝辞

Mohamed Boucadair reviewed the initial document and provided useful comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing provided comments on the subsequent draft version that resulted in major revisions. Serafim Petsis provided encouragement to publish the document after a hiatus of two years.

Mohamed Boucadairは最初のドキュメントをレビューし、それを改善するために役立つコメントを提供しました。 Reinaldo Penno、Joel Jaeggli、Dan Wingは、大幅な改訂につながった後続のドラフトバージョンについてコメントを提供しました。 Serafim Petsisは、2年間の休止の後にドキュメントを公開するように勧めました。

The authors are grateful to Dan Wing for his help in moving this document forward, and in particular for his helpful comments on its content.

著者は、この文書を前進させるのを助けてくれたDan Wingに、特にその内容に関する彼の有益なコメントに感謝しています。

Authors' Addresses

著者のアドレス

Tina Tsou Philips Lighting 3 Burlington Woods Dr #4t Burlington, MA 01803 United States

Tina Tsou Philips Lighting 3 Burlington Woods Dr＃4t Burlington、MA 01803アメリカ

   Email: tina.tsou@philips.com

Weibo Li China Telecom 109, Zhongshan Ave. West, Tianhe District Guangzhou 510630 P.R. China

weibo l i Chinaテレコム109、Z爆撃身廊、西、TIは広州510630地区と一致

   Email: mweiboli@gmail.com

Tom Taylor Huawei Technologies Ottawa Canada

Tom Taylor Huawei Technologiesオタワカナダ

   Email: tom.taylor.stds@gmail.com

James Huang Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China

James Huang hu Aはテクノロジー禁止の日であり、長いギャング地区は非常に現実的です518129 P.R.中国

   Email: James.huang@huawei.com