Public IP’s Assigned to Endpoints, Scanning, and App Identity: An explanation as to why you might see inbound internet traffic from alerting anti-virus network filters

• My company or my personal anti-virus is alerting on scanning attempts on my computer

Historically firewalls worked off Source/Dest IP’s, Ports, and later, Security Zones. When traffic destined for a device would enter a firewall’s filtering engine, it would check top-down for a match, and allow/deny based on the rules. For instance, if you had a rule to allow tcp/22 (ssh) to 1.2.3.4, and someone sent traffic to that host on that port, it would be allowed. But what if you had SSH listening on 1.2.3.4 on tcp/5555 instead? Although odd, this can be done, however in this case, this traffic would be dropped as it does not match tcp/22, even though it’s the same service, ssh.

AppID was created by a variety of firewall vendors to solve this problem. Instead of relying solely on source/dest ports to identity services, it uses a series of Layer 4 to Layer 7 analysis to determine the service, regardless of what port it is on.

Today DSU employs many AppID rules, including on ingressing traffic from the internet to more Trusted networks such as Student Wi-Fi. We primarily use these rules to allow certain traffic in some scenarios such as IPSec tunnel creation. In this case, the firewalls are constantly running application identification on incoming traffic to see if it does or doesn’t match these rules.

Let’s look at an example. We have a Windows PC on Staff Wi-Fi with the IP 138.247.242.233 and an SSH server listening on tcp/22. A host on the internet, 184.83.222.164, is attempting to connect to it via SSH on tcp/22. Below is a packet capture from the Staff PC. Notice how the incoming traffic is allowed, a TCP 3-way handshake occurs, but suddenly the Staff PC does several re-transmits and then forcibly tears down the connection without hearing back.

The answer to this, is that the firewall allowed several packets through (3 to be exact), allowing the flow to continue to a point until it determines the traffic is a match or non-match of any rules. In this case, there is no rule to allow tcp/22 to this host from the internet, but the traffic must be allowed through to employ App-ID. Once the applications identified, the rules are matched against this flow, the traffic is now dropped.

You can see below from the firewall logs how we hit a deny rule for this flow:

And as you can see, the detection was via AppID, allowing 3 packets ingress, 2 packets egress, before denying the connection.

Therefore if you or your company is employing a variety of AV tools on your device and is using some type of network filtering on device, you may see internet ingress traffic onto your device due to the firewalls checking the application in use as it watches the TCP session build up, but be aware these few packets that enter have almost no likelihood of being maliciously exploitable due to only allowing the TCP handshake initially.

DSU currently has a StudentWifiPrivate network configurable for your specific device if needed, however a ticket must be submitted and you must provide a MAC address (that must not rotate) and we can add it as an device to be sorted into the Private IP wireless, which acts the same as a GoTrojans wireless. Note, the device must support 802.1x authentication for this possibility.