Hi SAP enthusiasts,
the Security Audit Log [SAL] contains information about important system events and should, therefore, better not get lost unintentionally!
Let’s see, how the Audit Log can be erased and what we can do to prevent this and maximize its protection.
The Audit Log is stored in log-files that are located in the file system (see parameter DIR_AUDIT) and is either rotated daily or when the current file is full (see parameter rsau/max_diskspace/per_file).
Access to these files is possible via kernel functionality (from within the SAP system) or on operating system level (e.g. via an external OS command). We’ll focus on access via the SAP application server and won’t take a deeper look at manipulations directly from OS level (i.e. from the command line).
Ways to delete the Security Audit Log
From inside the SAP system, three variants of deleting the SAL files exist.
Below we’ll check them and see, which measures exist to protect the logs.
Variant 1: SM18 (or function module RSAU_CLEAR_AUDIT_LOG or system function C_REMOVE)
SM18 is the SAP standard way of removing old SAL files.
The transaction is protected by an authorization check for S_ADMI_FCD with value AUDA (= AUDit log Administration). The minimum age of files to be erased is 3 days − a nice feature because an attacker cannot remove fresh logs and hide what he/she did moments ago.
SM18 is not really problematic… S_ADMI_FCD with value AUDA is a critical authorization, which nobody should be assigned to on production.
Diving a bit deeper…
A clever developer might try to copy the code that is responsible for the deletion to a customer report − fortunately, this does not work… see below:
REPORT. WRITE 'SM18 (C_REMOVE):'. DATA: errno TYPE rsautypes-errno , errmsg TYPE rsautypes-errmsg. CALL 'C_REMOVE' ID 'DIR' FIELD '/usr/sap/[SID]/DVEBMGS00/log' ID 'FILE' FIELD 'audit_20160425' ID 'GROUP' FIELD 'AUDIT' ID 'ERRNO' FIELD errno ID 'ERRMSG' FIELD errmsg. IF sy-subrc = 0. WRITE: 'successful'. ELSE. WRITE: 'failed;', errmsg. " caller not registered ENDIF.
⇒ This report always runs into an error, because the SAP kernel checks the program name that calls the C_REMOVE function against an internal whitelist; we’ll always get a “failed; caller not registered” message…
Variant 2: DELETE DATASET
A more sophisticated way of getting rid of audit log files is to simply delete them via the DELETE DATASET statement from within an ABAP report.
A simple example:
REPORT. WRITE 'DELETE DATASET:'. TRY. DELETE DATASET '/usr/sap/[SID]/DVEBMGS00/log/audit_20160425'. IF sy-subrc = 0. WRITE 'successful'. ELSE. WRITE 'failed / not found'. ENDIF. CATCH cx_sy_file_authority. WRITE 'missing authorization'. ENDTRY.
The kernel checks for S_DATASET authorizations each time a DELETE DATASET statement is executed (this cannot be prevented since the check takes place in the kernel).
The field ACTVT is checked for value 06 (delete) and the FILENAME field for the path of the file to be deleted.
A check for authorization object S_PATH can be activated to implement additional protection for file system accesses. It is then evaluated after a successful S_DATASET check.
Alternatively, we can also prevent unauthorized log file deletion completely… even if a user has S_DATASET with all field values set to “*“!
For the additional check, the logic is as follows (see SAP Note 177702):
- first, the system checks whether the SPTH table contains a PATH, which matches the start of the pathname of the log file that we want to delete
- if an authorization group is set in the FS_BRGRU field, the system then performs an authorization check on S_PATH with ACTVT = 02 (write or delete)
Additionally, the table SPTH has two flags, which can further limit file access and overwrite the authorization checks on S_PATH and S_DATASET:
- if FS_NOREAD has the value “X”, neither read nor write access is possible
- and FS_NOWRITE = “X” prevents write access
To effectively prevent Security Audit Log deletion, you can add the following entry to SPTH:
PATH = /usr/sap/[SID]/DVEBMGS00/log/audit_
FS_NOREAD = X
FS_NOWRITE = X
Afterward, no user will be able to read or modify the SAL log files – disregarding their authorizations!
Anyway, SM20 will continue to work, as the access therein is performed by the kernel.
Variant 3: External operating system command
The third variant does not use the SAP kernel to delete the file, but rather an OS command (in the following example we’ll use the Unix/Linux rm command).
The following report creates a new external command, executes it to delete the same audit log file as above and finally deletes the command.
The creation and deletion of the command is logged via table logging for table SXPGCOSTAB… but at least at a first glance, we can hide what we did by deleting the command after execution…
REPORT. WRITE 'External command (SM69):'. DATA command TYPE sxpgcolist. command-NAME = 'Z_DEL_AUDITLOG'. command-opsystem = sy-opsys. command-opcommand = 'rm'. command-addpar = 'X'. CALL FUNCTION 'SXPG_COMMAND_INSERT' " --- Create command EXPORTING command = command EXCEPTIONS OTHERS = 1. IF sy-subrc = 0. WRITE 'creation successful;'. ELSE. WRITE 'creation failed.'. LEAVE PROGRAM. ENDIF. DATA exitcode TYPE extcmdexex-exitcode. CALL FUNCTION 'SXPG_COMMAND_EXECUTE' " --- Execute command EXPORTING commandname = command-NAME additional_parameters = '/usr/sap/[SID]/DVEBMGS00/log/audit_20160425' IMPORTING exitcode = exitcode EXCEPTIONS OTHERS = 1. IF sy-subrc = 0 AND exitcode = 0. WRITE 'execution successful;'. ELSE. WRITE 'execution failed;'. ENDIF. DATA: BEGIN OF command_del. INCLUDE STRUCTURE sxpgcostab. DATA: sapcommand TYPE sxpgcolist-sapcommand , TYPE(8) TYPE c , END OF command_del , rc TYPE i. command_del-NAME = command-NAME. command_del-opsystem = command-opsystem. PERFORM command_delete(saplsxpt) " --- Delete command USING SPACE CHANGING command_del rc. IF sy-subrc = 0 AND rc = 0. WRITE 'deletion successful.'. ELSE. WRITE 'deletion failed.'. ENDIF.
Of course, you could also create, execute and delete the command via transaction SM69.
The above method works fine if you have S_RZL_ADM (ACTVT = 01) for the creation of the command and S_LOG_COM authorizations for execution.
Unfortunately, the SPTH-protection from variant 2 does not work here.
If table logging is enabled (profile parameter rec/client), changes are recorded in table DBTABLOG and can be evaluated via transaction SCU3 (for table SXPGCOSTAB).
All three variants can be protected quite well via authorizations, so log deletion can be prevented by strictly controlling these authorizations.
Anyway high-privileged users – e.g. emergency users – still have access, so I suggest also implementing the SPTH-protection described in variant 2. 💡 It provides a good additional line of defense around the log files.
Please keep in mind that you should also take care of protecting table SPTH itself… 💡
Apart from the “access”-perspective, organizational measures should be implemented to make sure that malicious code – like to one above is – checked (and rejected) before a transport to production takes place!
There is a new option for deleting the SAL that comes up with the possibility to store the SAL data in the database. Deleting table RSAU_BUF_DATA, programmatically, via SE14 or via transport request!
Thanks, Thomas – that’s very helpful information!
(didn’t expect anything else from Onapsis 🙂 )
we have benefited from your articles a lot of times. Always very detailed and transparent explanations.
The risks that are associated with transport requests are always underestimated…
Until 7.31, SAP customers running SAP on MSSQL were at risk of deleting the production database with just one object entry in a transport. And even in higher versions, it is possible – not anymore immediately during the import of the transport request but delayed and executed by a clueless admin.
thank you for this insights on log protection and possible ways to delete.
In the first option, you mentioned the minimum age of files to be erased is 3 days. Where can i check this? In my case when I see in SM18, the period is set as 30.
However i see a weird behavior that audit file less than 3 days are no available to view.
Same is the case with system log.
Now, I am trying to check, where can I check the settings for the security audit log files deletion.
When I check in AL11, I see only three files for the last three days.
Any suggestion/feedback will be very helpful.
transaction SM18 calls report RSAUPURG and in that report, the function module RSAU_CLEAR_AUDIT_LOG is called to perform the actual file deletion.
The 3-day limit is a hard-coded in the program code of the FM:
I came across your blog on recherche about the topic. And thanks to you, I got aware about the 3rd variant. I’m thinking and currently testing a more in depth defense. Imho SM18 is a design weekness in general. A OS cron job can provide the functionality of archiving and deleting at least as good as or even better. I’m testing to write the SAL to an NFS share where I can use NFSv4 ACL’s to prohibit only deletion by admins. This is still not perfect because files can be altered by admins, but deletion is not possible anymore and the protection can be achieved without special licenses or hardware. Of course SM18 can’t be used either, which as a downside might be critizised by audit, because deletion is not logged in SAP.
What’s your opinion about it? Is the additional protection worth the effort?
good point – here are my two cents:
As long as the SAL files are in the reach of the SAP application (i.e. accessible by the SIDadm), it’s hard to come close to a perfect protection level.
First, there are always several ways to get things done in SAP and all of them need to be taken care of (as outlined in the article). Secondly, you simply cannot get rid of (few) users with very extensive authorizations (e.g. DDIC)… you can try to limit their auths or lock them until they’re needed, but in the end there will be a residual risk. You can mitigate that risk (logging, someone watching the admin physically …), but there will be no doubtless, 100%-security.
To be clear: for almost all circumstances that’s fine.
After having cleaned up the authorizations and mitigated the residual risks, you should ask yourself: do I really need 100% at the cost of additional complexity and (most probably) additional security headaches?
If your answer is yes, then what you described sounds fine.
The important aspects are imho: adjust file access rights, so that the SIDadm and all other SAP-related users are prohibited from doing anything but “read” on the SAL files. It is not really necessary to copy the files to another location, as long as the file permissions are set correctly. If the other location is on another server (with other security settings, users …), you might even run into new problems…
Concerning the deletion and the missing log: you could make the script write comprehensive log entries to the syslog and make sure that the syslog is stored in a safe place (protected log-directory or – preferably – a central log server).
If in doubt, I’d suggest you prepare a solution and ask an IT auditor for his opinion; usually those people are eager to help! Just don’t ask audit, what to do – the role of audit does not include making design decisions…
Hope that helps,
Maybe set the
suid-flag on files?
Can you give more details or an example?
This is by far the most clear, insightful discussion of this topic I’ve ever read. Excellent work, Daniel!