ASA: ロギングの適切なSeverityレベル選択とチューニング

Taisuke Nakamura · ‎2016-12-06

ロギング出力先の設定と、高負荷時のトラブルケース
Severityレベルと、出力先別のチューニング
シスログメッセージのID別のチューニング
ロギングチューニング例
その他参考情報
シスログメッセージの出力理由と推奨対応の確認
Internal Bufferと ASDM Syslog Messageの使い分け
通信量の多い環境で、シスログメッセージの欠けが発生した場合
TCPベースのSysloggingの制限について
関連情報リンク

ロギング出力先の設定と、高負荷時のトラブルケース

ASAはセキュリティ装置ですので、様々なシスログメッセージの出力とそのチューニングが可能です。以下はシスログメッセージの出力先別のSeverity Levelの設定例です。

　　　
　　　
なお、ASAのシスログメッセージ出力量が増大すればするほど、(基本は軽微ですが)ASAの処理負荷増大や、また出力先によって以下のような問題が発生します。

1. Local bufferや ASDMのログ出力量が多いと、古いログメッセージがすぐ消えてしまう
2. Consoleや Monitorのログ出力量が多いと、ログに邪魔され、本来のコマンド操作性が著しく悪くなる
3. SyslogサーバやSNMPサーバ宛のログ出力量が多いと、ASAや通信経路、対向サーバの負荷増大

　　
Local bufferに細かなログ出力(Informationalや Debugなど)を有効にした場合、問題発生時にすぐshow logを確認できるのなら良いのですが、時間が立つと他のログの出力により、古いログは消失してしまう可能性があがります。結果、問題が発生してから数日後にshow logを取っても、過去のログが何も残っておらず原因究明ができない、というトラブルケースがつながる事が少なくありません。

外部Syslogサーバにログを保存する場合、ログ量が多ければ多いほど、その分 ASAのシスログメッセージ送信負荷増大や、通信経路の帯域圧迫、対向サーバの受信/処理負荷増大やストレージ圧迫につながります。また、(勿論、ASAで出力するログ量を増やせば取り漏れを防げるという長所はありますが) 雑多なログが多くなればなるほど、問題発生時のログの検索や確認に時間がかかり、運用性が低下する恐れがあります。

これらトラブル・悩みの解決には、シスログ出力状況の確認と、運用環境に合わせたシスログの出力量のチューニング、という対応が重要となってきます。

Severityレベルと、出力先別のチューニング

ASAがサポートするシスログメッセージのSeverityレベルは、Emegency、Alert、Critical、Error、Warning、Notification、Informational、Debuggingの８つです。 Emergencyはデフォルトで出力されません。 Alertに近くなるほどより重要なメッセージが出力され、Debuggingに近くなるほど細かな通信や動作ログが出力されるようになります。

例えば、Severity LevelにErrorを指定した場合、Errorとその上のCriticalやAlertレベルまでのシスログメッセージが出力されます。

　　
　　
Internal Bufferや ASDM Logging Bufferは容量が限られており、いっぱいになると古いログメッセージから消えてしまいます。仮に通信量が多い環境で InformationalやDebuggingの出力を指定すると、大量のログが出力され、古いログメッセージがすぐ失われやすくなります。トラブルシューティングのため、古いErrorやCritical、Alertログも show logコマンドで長い時間確認できるようにしたい場合は、Internal BufferのSeverityレベルを CriticalやErrorなど、より重大度の高いものに設定を検討します。

また、Internal Buffer (show logで確認)を多用する環境の場合、logging buffer-sizeコマンドで、バッファ容量の変更もお勧めします。デフォルト4096バイトから 40,000バイトなど大きな容量に変更(コマンド例=logging buffer-size 40000)しておき、格納量を事前に増やしておきます。 logging buffer-sizeコマンド利用時のメモリ影響は極めて軽微ですので、基本的に適度に大きいバイトの指定をお勧めします。

　　　　
外部Syslogサーバでログを保存している環境の場合、一般的にロギングメッセージの保存可能量がとても大きいため、ついSeverityレベルを、DebuggingやInformationalなど重大度の低いものに設定しがちです。ただ、ロギング出力量が増えるほど、処理負荷や、ストレージ圧迫が進みます。その為、負荷やストレージ圧迫が気になる環境の場合は、本当にそのSeverityレベルのログ出力・保存が必要か検討してください。また、シスログメッセージのID別のチューニング(例=ロギングレベル変更や出力停止)も可能です。

シスログメッセージのID別のチューニング

ASAの出力するシスログメッセージには、出力内容別に一意のシスログIDが設定されています。

不要な指定シスログIDは、no logging message [Message ID]コマンドで出力しないよう変更も可能です。例えば、UDPコネクション生成時のシスログIDは 302015ですが、no logging message 302015コマンドでその出力を停止できます。

指定のシスログIDのSeverityレベルの変更は、logging message [Message ID] level [Severity level]コマンドで可能です。

　　
これら設定変更は、ASDMからの場合、Configuration > Device Management > Logging > Syslog Setup から可能です。

ロギングチューニング例

以下は、ロギング設定のCLIでのチューニング例です。

その他参考情報

シスログメッセージの出力理由と推奨対応の確認

出力されたシスログメッセージの説明や推奨アクション例は、以下ガイドから確認可能です。

Cisco ASA Series Syslog Messageshttp://www.cisco.com/c/en/us/td/docs/security/asa/syslog-guide/syslogs.html

　　
例えば以下は UDPのコネクション生成時(SyslogID=302015)のログの説明例です。

　　
　　
ASDM利用時は、Monitoring > Logging > Log Buffer からも確認できます。

Internal Bufferと ASDM Syslog Messageの使い分け

Internal Bufferと、ASDM Syslog Messageは、異なるSeverityレベルを設定できます。

Internal Bufferは show logコマンドでログ出力確認をできます。 ASDMの出力ログは、ASDMでの確認、もしくは CLIでもshow logging asdmコマンドでもログ出力確認をできます。

当特性を利用し、例えば Internal Bufferには Error以上のログの格納を。 ASDM logging bufferには Informationalなど細かなログの出力を有効化し、使い分けることも可能です。

以下は実際の設定とコマンド実行例です。

Internet-FW-01# show run logging
logging enable
logging timestamp
logging buffer-size 40000
logging buffered errors
logging asdm informational
Internet-FW-01#
Internet-FW-01# show log
   --- 略 ---
Dec 05 2016 09:28:44: %ASA-3-710003: TCP access denied by ACL from 153.232.40.153/33216 to outside:153.232.42.139/23
Dec 05 2016 09:29:31: %ASA-3-710003: TCP access denied by ACL from 220.133.134.198/26522 to outside:153.232.42.139/23
Dec 05 2016 09:30:30: %ASA-3-710003: TCP access denied by ACL from 120.142.68.6/47515 to outside:153.232.42.139/23
Dec 05 2016 09:30:40: %ASA-3-710003: TCP access denied by ACL from 202.188.211.118/11310 to outside:153.232.42.139/23
Dec 05 2016 09:31:10: %ASA-3-710003: TCP access denied by ACL from 220.133.134.198/26522 to outside:153.232.42.139/23
Dec 05 2016 09:32:24: %ASA-3-710003: TCP access denied by ACL from 113.222.104.210/12833 to outside:153.232.42.139/23
Dec 05 2016 09:34:26: %ASA-3-710003: TCP access denied by ACL from 185.6.124.178/56173 to outside:153.232.42.139/23
Dec 05 2016 09:34:57: %ASA-3-710003: TCP access denied by ACL from 220.133.134.198/26522 to outside:153.232.42.139/23
Dec 05 2016 09:36:47: %ASA-3-710003: TCP access denied by ACL from 220.133.134.198/26522 to outside:153.232.42.139/23
Internet-FW-01#
Internet-FW-01# show log asdm
6|Dec 05 2016 15:03:00|302013: Built inbound TCP connection 13136 for inside:192.168.0.241/55876 (192.168.0.241/55876) to identity:192.168.0.254/443 (192.168.0.254/443)
6|Dec 05 2016 15:03:00|725001: Starting SSL handshake with client inside:192.168.0.241/55876 to 192.168.0.254/443 for TLS session
6|Dec 05 2016 15:03:00|725003: SSL client inside:192.168.0.241/55876 to 192.168.0.254/443 request to resume previous session
6|Dec 05 2016 15:03:00|725002: Device completed SSL handshake with client inside:192.168.0.241/55876 to 192.168.0.254/443 for TLSv1.2 session
6|Dec 05 2016 15:03:00|605005: Login permitted from 192.168.0.241/55876 to inside:192.168.0.254/https for user "enable_15"
6|Dec 05 2016 15:03:00|302013: Built inbound TCP connection 13137 for inside:192.168.0.241/55877 (192.168.0.241/55877) to identity:192.168.0.254/443 (192.168.0.254/443)
6|Dec 05 2016 15:03:00|725001: Starting SSL handshake with client inside:192.168.0.241/55877 to 192.168.0.254/443 for TLS session
6|Dec 05 2016 15:03:00|725003: SSL client inside:192.168.0.241/55877 to 192.168.0.254/443 request to resume previous session
6|Dec 05 2016 15:03:00|725002: Device completed SSL handshake with client inside:192.168.0.241/55877 to 192.168.0.254/443 for TLSv1.2 session
6|Dec 05 2016 15:03:00|605005: Login permitted from 192.168.0.241/55877 to inside:192.168.0.254/https for user "enable_15"
6|Dec 05 2016 15:03:00|725007: SSL session with client inside:192.168.0.241/55877 to 192.168.0.254/443 terminated

通信量の多い環境で、シスログメッセージの欠けが発生した場合

SyslogサーバやSNMPサーバで ASAからのシスログメッセージを受信・確認してる環境で、シスログメッセージ欠けが発生するケースがあります。

多くの場合、以下が原因です。

ASAのLogger、もしくは関連プロセスの過負荷
ASAシステム全体で過負荷
通信経路で輻輳とドロップが発生
SyslogサーバやSNMPサーバ側での過負荷、処理漏れ

特にASAのロギングプロセス単体ないしは ASAシステム全体の過負荷は、シスログメッセージ生成処理にも悪影響を及ぼし、シスログメッセージの生成欠けや送付処理失敗の原因になります。これら問題が発生してるかの調査方法は以下URLなどを参考にしてください。また、仮に以下で過負荷の確認ができる場合は、当ドキュメントの内容を確認し、ASAロギング設定の見直しやチューニング、およびそれでも改善しない場合は ASAを通過する通信量を手前機器のACLやルーティングで調整したり、よりCPU処理能力の高い上位モデルへのマイグレーションなども検討してください。

ASA トラブルシューティングガイド： Syslog 宛先のログがない
https ://www.cisco.com/c/ja_jp/support/docs/security/asa-5500-x-series-next-generation-firewalls/113603-asa-missing-logs-00.html

ASA: show processes cpu-usage を用いた CPU負荷の調査
https://supportforums.cisco.com/t5/-/-/ta-p/3157321

TCPベースのSysloggingの制限について

ASAのSysloggingはデフォルトUDPベースですが、TCPベースのSysloggingの設定も可能です。しかし、TCPベースのSyslogging、以下の用途のために特殊に設計された、非常にセキュアな特殊な環境向けの機能となります。

何等か理由でSyslogサーバーから応答がなくなった場合に、通信ログが残せなくなることを防ぐため、自動でASAを経由する通信を遮断したい場合に利用
Syslogサーバーとの疎通確認に、コネクション型の TCP Syslog を利用

そのため、上記のセキュリティ要件が特にない場合は、TCPベースのSysloggingの利用は原則避け、UDPベース(デフォルト)のSysloggingの利用を強くお勧めします。TCPベースのSysloggingは高機能な分、Sysloggingのパフォーマンスが低く、通信量が多い環境の場合通信ログ欠けの原因になります。また、Syslogサーバーやその経路のトラブル時の予期せぬ通信断の原因になります。TCPベースのSysloggingについてより詳しくは、ASA: TCP Syslog 利用時の注意点についてを参照してください。