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
$STANDARD_FIELDS Ack Push Reset Syn FIN
$STANDARD_FIELDS 1 0 0 1 0
We probably want the final report to be more like
$STANDARD_FIELDS Flags
$STANDARD_FIELDS SYN/ACK
If the resulting report were combined with webtraffic.csv by doing something like
cat webtraffic.csv tcpreport.csv | sort > mergedreport.csv
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
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
2015-11-28 21:19:42
Webhook User-Agent
View Commit
2015-11-28 21:21:57
Logging straight PSH and ACKs adds very little overhead once the reports have been generated, though for a busy long-live connection it can extend the processing a bit.
A bigger saving, though, can probably be achieved by adjusting the known IP/Ports run (https://github.com/bentasker/PCAPAnalyseandReport/blob/2fb7048350bde276a65049e6c72059ecbd05f5f0/PCAP_Analysis.sh#L380) so that it instead uses the data the new run has collected. At the moment we're doing two sweeps of the PCAP un-necessarily when it'll almost certainly be faster to grep the TCP transaction log for "SYN" and parse out the fields we need.
2015-11-28 21:22:18
2015-11-28 21:57:15
Assuming the server had the following KnockD config
[openSSH] sequence = 7000,8000,9000 seq_timeout = 10 tcpflags = syn command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPTWe might observe something like the following in tcptraffic.csv
It's probably worth coming up with a good way to script identifying that sort of pattern, especially as there might well be other traffic mixed in at the same time (a browser tab reloading somewhere, or multiple users behind NAT). Also worth bearing in mind that KnockD allows you to configure the flag to watch for, so it doesn't have to be a SYN. It also doesn't have to be TCP, but we're not going to pick up on UDP knocks in tcptraffic.csv anyway
As a general set of rules though
- Source/Dest IP will be the same for the Knock and the eventual connection
- Knock traffic will be the same before every connection to that service (e.g. Port 22 for SSH)
- There will (probably) be a close knock using a different set of ports
With observation of multiple connections over time, it should be possible to draw a pattern out, at least where one time knocks aren't in use
2015-11-28 22:49:41
Webhook User-Agent
View Commit
2015-11-28 22:54:30
2015-11-29 00:03:43
2015-11-29 00:03:44
2015-11-29 00:03:44
2015-11-29 00:03:54