ShowTable of Contents
Audit logs are security-relevant record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, or event.
Websphere provides the Auditing Service which allows to log a set of events into a separate audit log file. The security auditing primary responsibility is to prevent unauthorized access and usage of resources.
The security auditing subsystem has the ability to capture the following types of auditable events:
- Principal/Credential Mapping
- Audit policy management
PS : All sample files were created when user "hacker" tries to login but fails.
Settings to get logs from WebSphere Application Server
We can generate Audit logs in WAS in two different methonds. Each one suites for different requirement and usage
Administrative auditing :
Link to steps : https://www.ibm.com/support/knowledgecenter/SSHRKX_8.0.0/admin/srvcfgref_audit.dita
•All configuration change like WebModule,Application role etc that are created, modified, or deleted.
•User/group created, modified or deleted
By default the audit logging service is disabled. This means that the service is loaded, but does not register any event listeners for audit logging. The auditing service configuration is controlled by the Auditing Service. The auditing service allows us to have the transaction ID written to the audit log file. The project ID can also be written to the audit log file. As these IDs can be very long and might not be required in every environment, you can disable the inclusion of the IDs.
Problem with this method : No details of the user who tried to login/logout information is collected. Infact, in this method no login/logout details are collected. Its mainly used for administration like whats happening with resources and which group is deleted or created etc.
Sample file : PortalAudit_WebSphere_Portal.png
Security auditing :
Link to Steps : http://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tsec_sa_secauditing.html?cp=SSAW57_8.5.5%2F1-8-2-33-5&lang=en
It gathers the information specific to Authentication,Authorization, Principal/Credential Mapping, Audit policy management,Delegation
This method logs all login/logout event with complete information writing each event as a sequence. The events will have lot of useful information like which remote machine has tried accessing the URL and also, the IP of the same including the remote port number.
Global security must be enabled for the security audit subsystem to function, as no security auditing occurs if global security is not also enabled. We can configure event type filters to only record a specific subset of auditable event types in your audit logs. Filtering the event types that are recorded makes for easier analysis of audit records by ensuring only those records important to your environment are archived.
Sample file : BinaryAudit_85-cf10-templateCell_porta_WebSphere_Portal_test.png
Settings to get logs from WebSphere Portal Server
Trace strings : 1st option
This is suggested in "Collecting Data: Login for WebSphere Portal" link
Steps to configure - http://www-01.ibm.com/support/docview.wss?uid=swg21592791.
Choose to enable either static or dynamic tracing and proceed with the steps accordingly. Enabling Static trace will set the trace level permanently but it will require the server to be restarted. Where as Dynamic trace ennoblement will set the trace at run-time i.e. no need of restarting the server but in case of server restart , trace settings will be cleared.
Trace level :
- If troubleshooting an impersonation issue, append the following string to the above trace:
- If using rule based user groups, append the following string to the above trace:
Sample file : trace_1.png
Trace strings : 2nd option
Steps to configure : Follow the link given in above set to set the trace strings for WebSPhere portal. Use below trace string in this case.
Trace level :
Sample file : trace_2.png
Each one provides different kind of information in the log when some security threat happens. One can decide to stick with only one type or combination of WAS audit log with setting Portal trace also to more information at that instance of time.