Classification of traffic using NTP fails

Most likely the app classification is not accurate. But mine is? Maybe your traffic is different to mine. NTP is not NTP in most cases. There are different types of NTP. So based on the port, plenty attackers try to use the port 123 to communicate with there apps (C2 Communication). 

If your NTP is not correctly pickup, you could do a wireshark dump and check the wireshark dump, if you find anything odd looking. 

There were some issues with ThunderVPN etc. based on Port123. But not picking up NTP at all is rather new to me. 

Check the logviewer on Port123 if there is a app classification. 

Most likely the app classification is not accurate. But mine is? Maybe your traffic is different to mine. NTP is not NTP in most cases. There are different types of NTP. So based on the port, plenty attackers try to use the port 123 to communicate with there apps (C2 Communication). 

If your NTP is not correctly pickup, you could do a wireshark dump and check the wireshark dump, if you find anything odd looking. 

There were some issues with ThunderVPN etc. based on Port123. But not picking up NTP at all is rather new to me. 

Check the logviewer on Port123 if there is a app classification. 

I checked the logviewer and found only one device uses Network Time Protocol and that is a power controller. All other devices are not recognised as using NTP but port 123 and this includes the two Sophos APX120s, the NTP server running a specific NTP server function.

Thunder VPN has not surfaced for a couple of releases.

I did find a couple of errors in the firewall rueles which have been cleaned up. The APX that is managed by CM continually does NTP checks where as the locally managed APX does not.

Ian

That is expected. NTP is used for time correction. As Central is using a lot of certificates, you need to fetch the time first, otherwise you could run in one of the oldest TLS issues (time of certificate is not valid). 

Do a tcpdump of this traffic and in another shell do a conntrack. Then we could take this to Labs to analyse the pattern. 

I have been trying to capture the traffic using PCAP, but all attempts fail with no records found, so in summary I must be doing something wrong, but not obvious to me.

I will try tcpdump later today.

Ian

I have captured some PCAP traffic and contract but not of the same connections.

Looking at the PCAP results would suggest that the XG has an issue because of the data included or omitted from the capture.

Ian

I have sent you a PM with the conntrack file.

Ian

We need a pcap file. Not a screenshot of some packet capture. 

support.sophos.com/.../KB-000037007

I have added a tcpdump file in a PM to you.

I think I can maybe see the cause, the traffic is decoded as NTPv4, not NTP, so maybe a there is a need to add a couple of new classifications of NTPv4 

Ian

More analysis, shows the device that records the traffic as Network Time Protocol in logviewer is using NTPv3.

I have sent you a tcpdump of the IP4 traffic in a PM.

I have attached a screenshot of the tcpdump capturing NTP using IPv6.

Ian

Having identified the issue as being XG classifies NTPv3 but does not recognise NTPv4 what needs to be done to effect the addition of NTPv4 to the classification list?

Ian

Is your Tcpdump / pcap file with NTPv4 Traffic?