------------------------------------------------------------------------------ PACKAGE : syslog-ng Premium Edition VERSION : 4 F1 SUMMARY : Critical error in syslog-ng PE version 4 F1 DATE : Sep 5, 2011 ------------------------------------------------------------------------------ A critical error has been found in syslog-ng Premium Edition (PE) version 4 F1 that in certain situations causes the month information for September to be interpreted as December in legacy-syslog formatted log messages. This announcement contains important information about an error that may affect your system logging infrastructure, and describes how to assess and remedy the situation. Read the entire announcement thoroughly. WARNING You will have to upgrade to the new, corrected version of syslog-ng 4 F1 no later than September 30 to avoid losing information. Performing the upgrade is recommended as soon as possible. AFFECTED VERSIONS syslog-ng Premium Edition 4.1.x (4 F1) BACKGROUND The syslog-ng Premium Edition application associates two timestamps with every incoming log message: the timestamp that is included in the header of the log message, and the time when syslog-ng actually receives the log message. The information from the timestamp included in the log message is available using the "S_"-prefixed macros of syslog-ng (for example, "$S_DATE"), while the timestamp added when syslog-ng PE received the log message is available using the "R_"-prefixed macros. Macros without prefix (for example, "$DATE") are equivalent with the "S_"-prefixed macros. ISSUE Because of an error, the month information from September to December will be interpreted as December in the timestamp of messages received by syslog-ng Premium Edition 4 F1. This causes the month information in the log messages and date-related macros to be incorrect. Since the macro values are affected as well, filenames, pathnames, and the names of database tables that have date-related macros in their names will be misnamed as well. For example, if a destination uses the "$YEAR/$MONTH/$DAY/$HOST.log" filename template for log files, then the logs of the recent days (that is, September 1-5) are incorrectly stored under the "2011/12/$DAY/$HOST.log" directory instead of "2011/09/$DAY/$HOST.log", and the timestamp of the stored log messages contains December instead of September. HOW TO FIND OUT IF YOUR CONFIGURATION IS AFFECTED Your configuration is affected if the following is true: - You are using syslog-ng PE 4 F1, and: - At least one log source is define that uses the legacy-syslog (also called RFC3164, or BSD-syslog) message format. Such sources include, but are not limited to network sources (for example, the tcp() or udp() driver), sockets (for example, unix-stream()), and file or pipe sources. A source is not affected if the "flags(syslog-protocol)" option is set for the source. - At least one date-related macro that is not prefixed with "R_" is used in a filename, database table name, or other template. Your configuration is NOT affected, if the following is true: - the "keep_timestamp(no)" global option is set, or - the "keep_timestamp(no)" option is set individually for every source, or - you use custom templates for every destination that explicitly use the "R_"-version of the date-related macros. SOLUTION BalaBit will provide new, corrected syslog-ng PE 4 F1 packages by Tuesday, September 6. If you are using syslog-ng Premium Edition 4 F1 in a production environment and your configuration is affected, please contact the BalaBit Support Team at http://www.balabit.com/boss/ to help assess and remedy the situation. The complete solution involves upgrading to the new, corrected version of syslog-ng PE 4 F1, and correcting the problems resulting from the error (for example, renaming misnamed files). WARNING You will have to upgrade to the new, corrected version of syslog-ng 4 F1 no later than September 30 to avoid losing information. Starting with October 1, uncorrected versions of 4 F1 will log the new log messages as messages from December, possibly mixing or overwriting the log files or database tables of September. WORKAROUND To have syslog-ng process the timestamps correctly until you upgrade to the corrected packages, use the timestamp when the messages are received. Note that in this case the information about when the log message was sent is irrevocably lost. To accomplish this, set the "keep_timestamp()" option to "no", either globally, or locally for the affected sources. Alternatively, replace the date-related macros (for example, $DATE, $ISODATE, $S_MONTH, and so on) used in your configuration with their "R_"-prefixed versions to use the received date of the log message. POSSIBLE SIDE-EFFECTS OF THE ERROR Depending on your environment, certain further steps might be needed to resolve the results of the issue. For example: - Backups and archives of the log files must be reviewed if log files of the affected period (September 1-5) have already been archived or backed up. - If you forward the log messages from syslog-ng Premium Edition to a SIEM or log analyzing application or device, the incorrect dates might appear in the SIEM reports as well, and might also affect the monthly statistics of the log messages. - Misnamed database tables, and the contents of database columns containing date-related information might have to be corrected. Kind Regards and Sincere Apologies, BalaBit IT Security