########################################################################################## PAS-22: TCP Transaction Log ########################################################################################## Issue Type: New Feature ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Done (2015-11-29 00:03:42) Project: PCAP Analysis Script (PAS) Reported By: btasker Assigned To: btasker Components: - Data Correlation and Extraction Affected Versions: - 0.1 Targeted for fix in version: - 0.1 Labels: TCP, Time Estimate: 65 minutes Time Logged: 25 minutes ----------------------------------------------------------------------------------------- Issue Description ================== I haven't thought of a specifically "evil" use for this yet, but it'd be handy to have a timestamped log of TCP flags observed. It'd add far too much noise to webtraffic.csv (especially as it'll include traffic not included in the file), but if structured carefully it should be fairly easy for the user to merge in if needed (although it'd mean making certain fields multipurpose to increase readability). We probably don't want to log every time a segment is sent, so much as specific connection events, so - SYN - SYN/ACK - FIN - FIN/ACK - RST There might be instances where we want to log either PSH or ACKs (the second could be used as an indicator of the first anyway) though. For example, for a HTTP Keep-alive connection, it'd show us the idle time between the last transmission and the connection being torn down (so we can deduce the client or server idle time depending which side sends the FIN). Once tuned, the same technique could potentially be used to deduce settings on HTTPS connections. The standard fields should obviously be used, and I think the final report should just contain a human readable version of the flags, so whilst we might extract as -- BEGIN SNIPPET -- $STANDARD_FIELDS Ack Push Reset Syn FIN $STANDARD_FIELDS 1 0 0 1 0 -- END SNIPPET -- We probably want the final report to be more like -- BEGIN SNIPPET -- $STANDARD_FIELDS Flags $STANDARD_FIELDS SYN/ACK -- END SNIPPET -- If the resulting report were combined with webtraffic.csv by doing something like -- BEGIN SNIPPET -- cat webtraffic.csv tcpreport.csv | sort > mergedreport.csv -- END SNIPPET -- The flags would show up in the FQDN column, which at least makes the CSV easy for a human to scan over, and the limited set of non-fqdn's should make it relatively easy for the file to be parsed by a custom script if needed. ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2015-11-28 17:25:47 btasker ----------------------------------------------------------------------------------------- I guess, though, if we're proceeding on the assumption that one use of the report might be to create a hybrid of the tcptransactions and webtraffic files, it might be worth looking at including ACK's and PSH's as well. They can soon be stripped out when combining if needed. Will implement something that logs them all, and then see what the savings are in terms of filesizes/processing time by disabling them. If nothing else, it could potentially become a config option. ----------------------------------------------------------------------------------------- 2015-11-28 20:53:00 btasker ----------------------------------------------------------------------------------------- Thinking about it, one thing this can definitely be used for is identifying port-knocking (and the sequence to be used) ----------------------------------------------------------------------------------------- 2015-11-28 21:19:42 git ----------------------------------------------------------------------------------------- -- BEGIN QUOTE -- Repo: PCAPAnalyseandReport Commit: 2fb7048350bde276a65049e6c72059ecbd05f5f0 Author: Ben Tasker