8

McAfee is reporting incoming network connections blocked from IPs like 198.252.206.149 (StackExchange Inc.), 54.179.231.116 (Amazon Technologies Inc.), 74.125.68.106 (Google Inc.), etc.

screenshot of McAfee showing aforementioned logs

The ports blocked vary: e.g. 54452, 54551, 52931, 53353, 52912, 52902, 52914, 54146, 54156, 53986, 52931, 52914, 53204, 52927, 52912, etc.

These ports shouldn't be the ones used for web browsing, because I seemingly can browse "perfectly" as per usual with no anomalies.

Why am I getting these messages?

What does it mean when someone tried to connect to TCP port on my PC "without permission"?

Improve this question
2
  • These ports shouldn't be the ones used for web browsing They sound like ephemeral ports for connections which are initiated by your browser to a web server.
    – Brandon
    Commented Mar 29, 2015 at 2:33
  • @Brandon, But the diagram shows that the connections have been blocked, yet I'm browsing with no problems. Hence, these ports shouldn't be the ones used for web browsing
    – Pacerier
    Commented Mar 29, 2015 at 4:25

2 Answers 2

Reset to default
14

Those messages get a D- for technical content and accuracy. The most likely explanation is that these packets arrived late and failed the ESTABLISHED,RELATED check because the connection was already closed.

Somewhat less likely is that they actually had the CONNECT flag set in the TCP header, and your firewall is either dropping all incoming connections or the target port was closed.

Random incoming connections can occur due to malicious port scans, but also due to dynamic IP allocation giving you an address which was formerly allocated to a user of peer-to-peer/mesh transfer software, such that the address has been advertised in the mesh. However since these are coming from sites that you do use, more likely is that the packet arrived after you already moved on to another webpage, and the browser was no longer listening for the data in question.

Unfortunately, describing the firewall action as a "block" is lacking in information as well. There are two possible actions when an unwanted packet arrives -- DROP it, or respond with REJECT. Rejection can take the form of an RST flag in a TCP return packet, or an ICMP "port unreachable" message. Either way, explicit rejection leaks information about your network configuration. At the same time, DROP can be caused by network congestion, so the remote end may retry. So for your "friends" (legitimate communication partners), it is preferred to REJECT, while for random port scans it is definitely preferred to DROP. And your firewall is not telling you which it is doing.

Improve this answer
5
  • Regarding "peers will receive these random incoming connections due to DHCP", what if I'm connected to a site using TLS / HTTPS ? If my peers monitor their firewall logs, will they see incoming connections from the sites which I visit? (assuming I use TLS/HTTPS only)
    – Pacerier
    Commented Mar 28, 2015 at 17:41
  • @Pacerier: This is something that can happen when DHCP changes the address that is issued to you. What I said about "giving you an address which was formerly allocated" and "the address has been advertised in the mesh" are rather important. Most communications (e.g. HTTPS) will only retry for a few minutes, so information on who you are communicating with could be leaked to your neighbors only if DHCP issues you a new address and immediately gives out your old one, quite unlikely. But p2p networks can keep member lists for many hours, causing connection attempts throughout that time.
    – Ben Voigt
    Commented Mar 28, 2015 at 17:48
  • So do you mean that if DHCP is malconfigured, not only HTTP, but even TLS/HTTPS would leak the IP addresses of sites I connected to to malicious peers? If so, is there a way to avoid this, or is this fundamentally a flaw in the TCP protocol?
    – Pacerier
    Commented Mar 28, 2015 at 17:58
  • 1
    @Pacerier: No, I mean what I wrote in my answer. Nothing is being leaked to peers. (A peer is a computer you exchange traffic with) If your address is taken from you and given to a different neighboring node (A neighbor is another computer in the same subnet) then that neighbor may discover what computers were sending data to that address at the time the address swap occurred (how do they know who had the address previously?). If your DHCP server is broken, then you have bigger problems than leaking packets in transit. HTTPS is not designed to hide IP addresses of endpoints.
    – Ben Voigt
    Commented Mar 28, 2015 at 18:23
  • Ic, bad usage ("peer" = colleague/friend) of terms on my part. So to clarify, is it right to say that as long as a server's timeout is longer than DHCP's timeout (which means as long as either one of them gets misconfigured), all it takes is one frenemy on our lan to run a program that logs arp -a and the SNI hostnames of kidnapped HTTPS requests and he can build a database of a subset (significant over time/months) of where everyone has been visiting?
    – Pacerier
    Commented Nov 9, 2015 at 21:53
0

These seem like exaggerated claims in the form of "We just protected you from 145 threats, killed 5 aliens, 3 ninjas and one dragon!" The best options are, either:

  • (next time it happens) use a network scanner/sniffer (like WireShark or similar) to see what actually happened
  • ignore it (or use a better HIDS that gives better descriptions)
  • uninstall McAfee ;)
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .