Unisphere for PowerMax 9.2リモート セキュアSyslog
Résumé: Unisphere for PowerMax Secure Syslog:使用方法とタイミング。設計と業界標準
Symptômes
Syslog 履歴
Syslog は 1980 年代に Eric Paul Allman (1955 年 9 月 2 日生まれ) によって開発されました
エリックは、1970年代後半から1980年代初頭にかけてカリフォルニア大学バークレー校でSendmailとその前身であるDelivermailを開発したアメリカのコンピュータープログラマーです。1998年、AllmanとGreg OlsonはSendmail, Inc.を共同設立しました。Syslogと呼ばれるmtaメッセージ転送エージェントによって使用されるログ形式。Syslog は当初 Sendmail によってのみ使用されていましたが、最終的には他の無関係なプログラムがログ記録に使用する非公式の標準形式になりました。その後、この形式は 2001 年に RFC 3164 によって公式になりました。ただし、元の形式は、最新のリビジョンである RFC 5424 によって廃止されました。
インターネット技術特別調査委員会
Internet Engineering Task Force (IETF) は、自主的なインターネット標準、特にインターネット プロトコル スイート (TCP/IP) で構成される標準を開発および促進するオープン スタンダード組織です。
正式な会員名簿や会員要件はありません。すべての参加者とマネージャーはボランティアですが、彼らの仕事は雇用主またはスポンサーによって資金提供されています
Internet Architecture Board (IAB) は、IETF の外部関係と RFC エディタとの関係を監督します。IABは、インターネット開発のための長期的な技術的方向性を提供します。IABは、IETFにロジスティックなどのサポートを提供するIETF管理支援活動(IASA)を監督するIETF管理監視委員会(IAOC)の共同責任も負っています。
IABは、IETFがいくつかのグループ横断的な関係を持っているInternet Research Task Force(IRTF)も管理しています。
運営グループ
Internet Engineering Steering Group (IESG) は、Internet Engineering Task Force (IETF) の議長とエリア ディレクターで構成される機関です。これは、インターネット標準の最終的な技術レビューを提供し、IETF の日常的な管理を担当します。IESGは、作業部会の決定に対する異議申し立てを受け、IESGは、標準トラックで文書を進めることを決定します。
Syslogプロトコル
Syslog utilizes three layers o "syslog content" is the management information contained in a syslog message. o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages. o The "syslog transport" layer puts messages on the wire and takes them off the wire. o An "originator" generates syslog content to be carried in a message. o A "collector" gathers syslog content for further analysis. o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays. o A "transport sender" passes syslog messages to a specific transport protocol. o A "transport receiver" takes syslog messages from a specific transport protocol. Diagram 1 shows the different entities separated by layer. +-------------------------+ +----------------------+ | content | | content | |------------------------| |----------------------| | syslog application | | syslog application | | | | | (originator, | | | | (collector, relay) |------------------------| |----------------------| | syslog transport | | syslog transport | (transport sender, | | | | (transport receiver) +------------------------+ +----------------------+ ^ ^ | | -----------------------------
Syslogはどのように転送されますか?
syslogメッセージを送信する一般的な方法は2つあります。RFC 5424では、すべてのSyslog実装がTCP経由の暗号化されたTLSネットワーク トランスポートをサポートする必要があると規定されていますが、ほとんどのSyslogメッセージは依然として古いUDP方式を使用して配信されています。UDPバージョンでは、メッセージはUDPパケットのデータ部分に配置され、UDPポート514を介してサーバーに送信されます。通常、各メッセージは 1 つのパケットに収まります。UDPはステートレスであり、セッションレスであるため、確認応答はありません。パケットはネットワークに送信されます。これには明らかな問題があり、ネットワークの問題によってパケットの配信が妨げられる可能性があり、その場合、ネットワークがダウンしていることを通知できないため、ネットワークがダウンしていることに気付かない可能性があります。また、重要なパケットが輸送中に紛失または損傷する可能性があることも意味します。
基本方針
syslog 通信には、次の原則が適用されます。
o syslog プロトコルは、メッセージ配信の確認応答を提供しません。一部のトランスポートはステータス情報を提供する場合がありますが、概念的には、syslogは純粋なシンプレックス通信プロトコルです
o 発信元とリレーは、複数のコレクターとリレーに同じメッセージを送信するように構成できます
o 発信元、リレー、およびコレクターの機能は、同じシステム上に配置できます。
最低限必要なトランスポート マッピング
この仕様のすべての実装は、[RFC5425] に記述されているように、TLS ベースのトランスポートをサポートしなければならない[MUST]。
この仕様のすべての実装は、[RFC5426]に記述されているように、UDPベースのトランスポートもサポートすべきである[SHOULD]。この仕様の導入では、TLSベースのトランスポートを使用することが推奨されます
syslogメッセージの自由形式は、syslogの最大の強みですが、Syslogの最大の問題でもあります。異なるベンダーの何十もの異なるシステムからのイベントを含むログを解析し、それらを同時に理解することは非常に困難です。どのメッセージがどの機能を表していますか? また、重要なイベントと単なる情報メッセージのどちらを表していますか
これらの質問に対処するために、syslog プロトコル (RFC 5424 で定義) は、これらの自由形式のメッセージに "facility" と "severity" と呼ばれる特別なフィールドを提供します
(RFC 5424 は syslog の標準ですが、すべての syslog 実装が RFC 5424 に準拠しているわけではないことに注意してください。syslogプロトコルは非常に長い間存在しており、いくつかの先行標準実装がまだ使用されています。
Syslogのセキュリティ要件
Syslogメッセージは、目的のコレクターに到達するまでに複数のホップを通過する場合があります。一部の中間ネットワークは、ネットワークが発信元、リレー、またはコレクターとは異なるセキュリティー・ドメインにあるか、またはセキュリティー・レベルが異なるため、発信元、リレー、または受信側によって信頼されない場合があります。もう1つのセキュリティ上の懸念は、発信元、リレー、または受信側自体が安全でないネットワーク内にあることです
Syslogセキュリティには、対処すべき脅威がいくつかあります。
主な脅威は次のとおりです
o 仮面舞踏会。権限のないトランスポート送信者が正当なトランスポート受信者にメッセージを送信したり、権限のないトランスポート受信者が正当なトランスポート送信者をだまして syslog メッセージを送信させようとしたりする場合があります。
o 変更。トランスポート送信者とトランスポート受信者の間の攻撃者は、転送中の syslog メッセージを変更し、そのメッセージをトランスポート受信者に転送する可能性があります。このような変更により、トランスポート受信者がメッセージを誤解したり、望ましくない動作をしたりする可能性があります。
o 開示。権限のないエンティティがSyslogメッセージの内容を調べ、その情報に不正にアクセスする可能性があります。Syslogメッセージ内のデータの中には、許可された管理者やユーザーのパスワードなど、機密性の高いものがあり、攻撃者にとって有用である可能性があります。
第 2 の脅威は
o メッセージ・ストリームの変更。攻撃者は、一連のメッセージから 1 つ以上の syslog メッセージを削除したり、メッセージを再生したり、配信シーケンスを変更したりする可能性があります。Syslogプロトコル自体は、メッセージの順序に基づいていません。ただし、syslogメッセージ内のイベントは、他のメッセージ内のイベントと意味的に関連している場合があるため、イベントのシーケンスを理解するには、メッセージの順序付けが重要になる場合があります
次の脅威は、syslog にとって重要度が低いと見なされ、このドキュメントでは扱いません。
o サービス拒否
o トラフィック分析
TLSを使用したSyslogの保護
TLSは、上記のsyslogに対するすべての主要な脅威に対抗するための安全なトランスポートとして使用できます
o メッセージ内容の開示に対抗するための守秘義務。
o ホップバイホップベースでメッセージへの変更に対抗する整合性チェック。
o マスカレードに対抗するためのサーバーまたは相互認証。
注：このセキュアなトランスポート(つまり、TLS)は、Syslogトランスポートをホップバイホップ方式でのみ保護し、Syslogメッセージの内容には関係しません。特に、トランスポート送信者の認証されたアイデンティティ(例えば、証明書中のサブジェクト名)は、必ずしもsyslogメッセージのHOSTNAMEフィールドに関連しているとは限りません。syslogメッセージ発信元の認証が必要な場合は、[SYS-SIGN]を使用できます。
Cause
上の図は、Secure Syslogを構成するためのUnisphere for PowerMaxの画面を示しています。