SOC team are seeing parsing error in the Reporter Event log for the Cloud SWG logs.
From the Reporter event logs, we see a lot of message indicating invalid log lines exceeding the size.
The WSS logs are downloaded via the SyncAPI and then uploaded to an FTP server. The reporter server then consumes the logs from the FTP server.
The format of the log is the default format of the Cloud SWG log but still there is parse error.
A sample HTTP log entry showing corruption shown below (potential IDs are replaced with ### characters):
2023-06-28 01:16:39 "DP2-GBEBR1M4 81.252-UpdED oxyUpdED S252ware:12M9icr7.3.8necation/vnd.ms-c00Infrastructure;Cat-WHITEList_Tech;Cat_WHITEList_Common" - 403 TCP_DE1_ca2-003ap4lenied DENIED "We%222M9icr7.3.8|cation%20vnd.ms|timeout%2201a89ab83-wn218 01:16:04 3/static/trustedr/en/disallowedcertstl.cab ?8d5bf3026e3b729c cab Microsoft-CryptoAPI/#######-###-#######-####-######## PC - - -1164v3/staticicicicicicic3bc456c0891380a0ance" 1 -######" 1 - wss-######-#######:23ne373196 "United Stat1"EN3 - - - - none -###-i8-####-user1s1poUs%yNED - ICAP_NOT_SWeb Infrastruic/tr 4 --ess-agent 8989;4 - wss-agent architec "403om "C4%20name=Wia "Us%2010%/vnd.ms-cab-e -pr Gs IC52.91ctldl.wowedceupdED de - 8fe/msdownload/updED /v3/sIEDic/trusd Dr/en/pinrulesstl.cab ?d9ad9d521fcfc1bc cab M4 81.252-CryptoAPI/CAP_ 1_ca2-######-06-28 01:16:39 "DP1-GBEBR11_proxysg1" M4 81.252-UpdED oxyUpdED S252ware:12M9icr7.3.8necation/vnd.ms-c00Infrastructure;Ct-WHITEList_Tech;Cat_WHITEList_Common" - 403 TCP_DE1_ca2-003ap4lenied DENIED "We%222M9icr7.3.8|cation%20vnd.ms|timeout%2201a89ab83-wn218 01:16:04 3/static/trustedr/en/disallowedcertstl.cab ?8d5bf3026e3b729c cab Microsoft-CryptoAPI/######-####-####-####-####### PC - - -1164v3/staticicicicicicic3bc456c0891380a0ance" 1 -1a658abaance" 1 - wss-#######-#########:#######"United Stat1"E16 - - - - none -s1s1s1ithoutAuth8989 ######-####-###t.com "Chat (IM)/SMS;Office/Busineas.atlassia%ne - - - - none00a5ca2-002ap4e39e62721a-00000000649b89f7
Hosted Reporting Server.
Cloud SWG.
SyncAPI.
Customer has multiple Cloud SWG tenants that they download HTTP access log files from.
Broken internal, on premise, process uploading files to Reporting server.
Repair internal script to correct copy problems to upstream FTP servers.
After downloading and decompressing the Cloud SWG log files from multiple tenants, the internal process then send each tenant's log file to the right destination directory on the FTP server. The script that identified the log file's original tenant didn't have time to send the entire file to its destination directory before the same file was moved to the logs-archive directory by the custom download script.
Downloading the logs from the same timestamp as corrupted Portal logs showed only clean entries
SyncAPI download with API username/password showed clean downloads
Upstream process broken.