Best practices: Log management
When the FortiGate unit records FortiGate activity, valuable information is collected that provides insight into how to better protect network traffic against attacks, including misuse and abuse. There is a lot to consider before enabling logging on a FortiGate unit, such as what FortiGate activities to enable and which log device is best suited for your network’s logging needs. A plan can help you in deciding the FortiGate activities to log, a log device, as well as a backup solution in the event the log device fails. This plan should provide you with an outline, similar to the following:
l what FortiGate activities you want and/or need logged (for example, security features) l the logging device best suited for your network structure l if you want or require archiving of log files l ensuring logs are not lost in the event a failure occurs.
After the plan is implemented, you need to manage the logs and be prepared to expand on your log setup when the current logging requirements are outgrown. Good log management practices help you with these tasks.
Log management practices help you to improve and manage logging requirements. Logging is an ever-expanding tool that can seem to be a daunting task to manage. The following management practices will help you when issues arise, or your logging setup needs to be expanded.
- Revisit your plan on a yearly basis to verify that your logging needs are being met by your current log setup. For example, your company or organization may require archival logging, but not at the beginning of your network’s lifespan. Archival logs are stored on a FortiGate unit’s local hard drive, a FortiAnalyzer unit, or a FortiCloud server, in increasing order of size.
- Configure an alert message that will notify you of activities that are important to be aware about. For example: if a branch office does not have a FortiGate administrator, you will need to know at all times that the IPsec VPN tunnel is still up and running. An alert email notification message can be configured to send only if IPsec tunnel errors occur.
- If your organization or company uses peer-to-peer programs such as Skype or other instant messaging software, use the Applications FortiView dashboard, or the Executive Summary’s report widget (Top 10 Application Bandwidth Usage Per Hour Summary) to help you monitor the usage of these types of instant messaging software. These widgets can help you in determining how these applications are being used, including if there is any misuse and abuse. Their information is taken from application log messages; however, application log messages should be viewed as well since they contain the most detailed information.
- Ensure that your backup solution is up-to-date. If you have recently expanded your log setup, you should also review your backup solution. The backup solution provides a way to ensure that all logs are not lost in the event that the log device fails or issues arise with the log device itself.
Just a comment on #2 above, I found enabling ipsec event emails to quickly annoy my customer, as fortinet stupidly sends an alert for every time some random host sends an ike message, which occurs constantly from the likes of Shodan.io and all the script kiddies probing for exploitable ipsec terminations. Asking fortinet support for a good way to block this by policy, or tuning the alerts to ignore the random connections was fruitless, my only option was to disable it.
That sucks as I’d really like an alert for a tunnel going down, but not all the noise that comes with it.
Yeah, it is incredibly chatty. If you are logging to a FortiAnalyzer and using the event management process of the FAZ you can get a lot more flexibility on your alerting etc.