nDPI
nDPI copied to clipboard
ntop
Classifying RDP in http packets
Describe the bug
When I run ndpiReader with a pcap, it shows that an RDP session is created, but I see that there is http traffic from port 80 in the packets inside the pcap. Could there be an error here?
nDPI Environment (please complete the following information):
- OS name: [e.g. Ubuntu].
- OS version: [e.g. 18.04]
- Architecture: [e.g. arm64]
- nDPI version or commit hash: Using nDPI (4.9.0-4439-99d48383)
ndpiReader -i ../http_traffic.pcap
nDPI Memory statistics:
nDPI Memory (once): 37.30 KB
Flow Memory (per flow): 976 B
Actual Memory: 5.02 MB
Peak Memory: 5.02 MB
Setup Time: 9 msec
Packet Processing Time: 0 msec
Traffic statistics:
Ethernet bytes: 2000 (includes ethernet CRC/IFC/trailer)
Discarded bytes: 0
IP packets: 20 of 20 packets total
IP bytes: 1520 (avg pkt size 76 bytes)
Unique flows: 2
TCP Packets: 20
UDP Packets: 0
VLAN Packets: 20
MPLS Packets: 0
PPPoE Packets: 0
Fragmented Packets: 0
Max Packet size: 67
Packet Len < 64: 18
Packet Len 64-128: 2
Packet Len 128-256: 0
Packet Len 256-1024: 0
Packet Len 1024-1500: 0
Packet Len > 1500: 0
nDPI throughput: 54.20 K pps / 41.35 Mb/sec
Analysis begin: 22/Dec/2023 15:09:00
Analysis end: 22/Dec/2023 15:09:00
Traffic throughput: 538.62 pps / 420.80 Kb/sec
Traffic duration: 0.037 sec
DPI Packets (TCP): 8 (4.00 pkts/flow)
Confidence: DPI 2 (flows)
Detected protocols:
RDP packets: 20 bytes: 1520 flows: 2
Protocol statistics:
Acceptable 1520 bytes
Risk stats [found 2 (100.0 %) flows with risks]:
Known Proto on Non Std Port 2 [50.0 %]
Desktop/File Sharing 2 [50.0 %]
NOTE: as one flow can have multiple risks set, the sum of the
last column can exceed the number of flows with risks.
Hi, can you share pcap example? The RDP dissector was recently fixed to avoid false positives, so it's unlikely to be the cause.
http_traffic.zip @0xA50C1A1
It may be a false positives, or it may not. I thought this check would be enough to accurately detect RDP traffic:
tpkt_verify_hdr(packet) &&
/* COTP */
packet->payload[4] == packet->payload_packet_len - 5) {
if(current_pkt_from_client_to_server(ndpi_struct, flow)) {
if(packet->payload[5] == 0xE0 && /* COTP CR */
((packet->payload[11] == 0x01 && /* RDP Negotiation Request */
packet->payload[13] == 0x08 /* RDP Length */)
Well, let's take a look at why this happens. I've marked with colored boxes the bytes that match conditions of this check:
Bytes marked in magenta are similar to TPKT header, byte marked in yellow are similar to COTP Connection Request flag, bytes marked in red and blue are similar to RDP Negotiation Request and RDP Length flags. Also I forgot to mark byte 0E, it matches packet->payload[4] == packet->payload_packet_len - 5 check conditions (19 - 5 is 14 or 0xE).
So it's really like a RDP Negotiation Request, sent on TCP port 80. And the server responses with HTTP code 400 (Bad Request):
Well, I'll try to figure it out after the holidays, I guess I've got an idea how to fix it. Thank you very much for the bug report and pcap.
