Udostępnij za pośrednictwem

Detecting port availability and blockage: Part 2, The Trace

  • Artykuł

Note: For Part 1 of this blog, "The players", Click Here

So, back to our scenatio and detecting port blocking. A little copy and paste from Part 1:

Nature of blocked ports
Port blocking is a somewhat secret event to tracing, but there are some very easy methods to determine if this is happening. Let's take these scenarios:

  • Scenario 1 - Port 3389: RDP enabled but blocked through the Windows Firewall
  • Scenario 2 - Port 3390 - nonexistent port
  • Scenario 3 - Port 3389: RDP enabled and allowed through the Windows Firewall

Now, to the trace itself. Let's talk each scenario.

First, to take the trace, it's always recommended to have a trace taken by both sides of the conversation.

To do this, I use netsh (doesn't require any installations), with this command: netsh trace start capture=yes tracefile=(name of file).etl
Note this should have an ETL extension and if you want the trace to survive a reboot, add persistent=yes. When you're finished, netsh trace stop

Scenario 1: RDP enabled and blocked
So, network traces can be very secretive here. But, let's walk the process. First, you want to search for well known port 3389 (our destination port). This will reveal the source port. So, using Network Monitor, use this filter:
tcp.port==3389
You are looking for this text in the description (bolded for context):
SrcPort=57475, DstPort=MS WBT Server(3389)

Now, to narrow it down a bit, look for port 57475. You can limit this to SrcPort, but you'll only get half a conversation. I wouldn't recommend this.
tcp.port==57475

You now have the conversation. What do we get?
TCP: [Bad CheckSum]Flags=......S., SrcPort=57475, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1912198306, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
TCP:[SynReTransmit #299] [Bad CheckSum]Flags=......S., SrcPort=57475, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1912198306, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
TCP:[SynReTransmit #299] [Bad CheckSum]Flags=......S., SrcPort=57475, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1912198306, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240

So, let's analyze, what are we looking for?

  • First, one red herring, the [Bad CheckSum] messages. They can be safely ignored, and are not relevant to port blocking. It is likely a byproduct of Checksum Offloading which can be disabled.
  • Next, note the Ack stays 0 throughout the conversation, meaning no acknowledgment was given.
  • Also, note the packet sequence stays at 1912198306, meaning that it is retrying the same packet, as you are seeing from SynReTransmit.

A trace taken at the same time on the Receiving system running RDP shows the same story with subtle differences:
TCP:Flags=......S., SrcPort=57475, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1912198306, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
TCP:[SynReTransmit #177]Flags=......S., SrcPort=57475, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1912198306, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
TCP:[SynReTransmit #177]Flags=......S., SrcPort=57475, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=1912198306, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240

At this point, the relevant data of the trace dies. What do we know from this? We know that a call went out over port 3389, it wasn't acknowledged that there was a listener (dropped at the server), 2 more tries were made, and that was all (and likely the code throws an error at the user).

Scenario 2 - Port 3390 - nonexistent port
Next, I use telnet client to connect to a system on port 3390, where nothing is listening. The trace is almost identical to the first, here's the sender trace:

TCP: [Bad CheckSum]Flags=......S., SrcPort=57808, DstPort=3390, PayloadLen=0, Seq=1039920141, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
TCP:[SynReTransmit #694] [Bad CheckSum]Flags=......S., SrcPort=57808, DstPort=3390, PayloadLen=0, Seq=1039920141, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
TCP:[SynReTransmit #694] [Bad CheckSum]Flags=......S., SrcPort=57808, DstPort=3390, PayloadLen=0, Seq=1039920141, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240

Notice the same pattern as when we were blocking with Windows Firewall, it is esentially not acknowleding a listener (there isn't one this time) and communication stopped after 2 retries.

Scenario 3 - Port 3389: RDP enabled and allowed through the Windows Firewall
In this trace, let's look at what success looks like. So, perhaps you want to make sure that everything you sent was acknowledged. You can use this filter:
tcp.flags.syn==1
...and you will see 5 packets: 1 for RDP 3389 and 4 others for Ketberos port 88 going in both directions (I won't leave all the packets):

Sender: TCP: [Bad CheckSum]Flags=......S., SrcPort=57502, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=3320970900, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
Receiver: TCP:Flags=...A..S., SrcPort=MS WBT Server(3389), DstPort=57502, PayloadLen=0, Seq=1717801724, Ack=3320970901, Win=64000 ( Negotiated scale factor 0x0 ) = 64000

Sender: TCP: [Bad CheckSum]Flags=......S., SrcPort=57503, DstPort=Kerberos(88), PayloadLen=0, Seq=2107900703, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
Receiver: TCP:Flags=...A..S., SrcPort=Kerberos(88), DstPort=57503, PayloadLen=0, Seq=3959601786, Ack=2107900704, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152

Note that the Ack field is populated. You will then see traffic and packets throughout this trace. This means that not only RDP connected, but also authenticated.

I hope this has been a good educational overview on basic network tracing and detecting port blockage, but also what a successful connection looks like.

— Easy link to my blog: https://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.