I recently read a piece by an infosec analyst who observed ebay.com doing a local port scan.

I could not believe my eyes, but it was quickly reproduced by me (see below for my observation).

I surfed around to several sites, and found one more that does this (the citibank site, see below for my observation)

I further see, at least across ebay.com and citibank.com the same ports, in the same sequence getting scanned. That implies there may be a library in use across both sites that is doing this. (I have not debugged into the matter so far.)

The questions:

  1. Is this port scanning "a thing" built into some standard fingerprinting or security library? (if so, which?)
  2. Is there a plugin for firefox that can block such behavior? (or can such blocking be added to an existing plugin)?


ebay.com as seen by me: ebay.com port scanning

citibank as seen by me: citibank port scanning

Other sites I checked that did NOT seem to be doing this:

  • paypal.com: no
  • ups.com: no
  • fedex.com: no
  • https://www.bankofamerica.com/: no
  • twitter.com: no
  • facebook.com: no
  • duckduckgo: no
  • authorize.net: no
  • wellsfargo.com: no
  • 2
    I figured that it's a crude attempt to checking if you're using a remote computer. Criminals frequently use hacked RDP/VNC/etc to make fraudulent purchases. Commented May 27, 2020 at 1:44
  • @SomeLinuxNerd It appears to be that, but it could easily also be fingerprinting and/or nefarious.... Commented May 27, 2020 at 15:29
  • 1
    @JonesomeReinstateMonica if that's the case, then it would be interesting to see if the results of the connection attempts to localhost are sent back to the origin (e.g. ebay.com or citibank.com). If so, this is a sneaky way to get around same-origin policy.
    – mti2935
    Commented May 28, 2020 at 21:35
  • 1
    For what it's worth, there is a proposed web standard now that aims to block this sort of thing by default: wicg.github.io/private-network-access
    – Ajedi32
    Commented Mar 31, 2022 at 16:36

4 Answers 4


Blocking WS requests

While looking for a way to disable websockets, I found two native Firefox solutions that do not work any more, then stumbled upon https://github.com/jawz101/TrackersVsFirefox, which mentions that one can block websockets with the uBlock Origin rule:


You can restrict this further to localhost only, but you have to come up with a pattern that matches all possible localhost references (for example, all IP addresses between and refer to localhost as well). I won't try to come up with such a pattern as I am afraid that there may be some exotic aliases that I am not aware of.

Testing the result

In any case, once you have the filter set up, you can try it by visiting https://www.websocket.org/echo.html and clicking the Connect button. To test blocking localhost connections specifically, you can run a dummy server that listens for incoming connections and try to connect it.

For example, on linux you can run netcat -l 4444 to listen on port 4444 and connect to it by specifying wss://localhost:4444 as the location on the WS echo page.

  • Without the uBlock Origin rule, you will see some gibberish showing up in the netcat output and the WS echo page won't show any output (because netcat is not replying to it, just displaying the request).

  • With the rule enabled, you won't see any output in netcat but the WS echo page will display the error "DISCONNECTED, ERROR: undefined".

  • Zoltan, that is the best tip going, but I think it isn't that useful in practice. I think what is really needed is for the browser to treat websocket connections to local DIFFERENTLY than WS to public. Just as my browser asks permission to use my web cam (a local resource), it should ask permission to connect to local WS (who knows what I have running locally? perhaps not even me!). Commented Jun 1, 2020 at 3:51
  • I agree and hope that browser developers will notice this problem (after all, it got a very wide news coverage) and introduce protective measures. On the other hand, this issue is very tricky to properly address, because not only localhost but local network request can be sensitive too. For example, your home computer can probably access the management interface of your home router, which can not be accessed from the public internet. But browsers can't just block the whole private IP range as that would include web servers on the local network, like a company intranet.
    – Zoltan
    Commented Jun 1, 2020 at 18:46
  • Please also note that although I provided a more generic rule, you can be more specific and block localhost only. This, however, can be error-prone and I did not provide a more specific rule because I did not feel confident enough that I could come up with a rule that matched all localhost aliases.
    – Zoltan
    Commented Jun 1, 2020 at 18:55
  • Does not work. See DNS Rebinding.
    – Joshua
    Commented Mar 29, 2022 at 21:50

It is possible this scan is coming from ThreatMetrix (just a rumor, not confirmed that I know of).

There is now a documented proof of concept that this vulnerability can be used against developers.

This thing is real.

But mitigations are, currently, unknown.


In answer to browser plug-ins that may be able to block this traffic, I would recommend trying uMatrix. There are other plug-ins with similar capabilities (e.g., NoScript), but I find uMatrix more intuitive. It is possible that uBlock Origin (or its derivative Nano Adblocker) can block the traffic, but this will depend from where the scripts load.

uMatrix can block third-party (as well as first-party) scripts (and other elements). If the scripts are loaded from a separate website, then uMatrix may work perfectly. If the scripts are loaded from the origin website, it would be necessary to block first-party scripts which will seriously break website functionality usually. These extensions may leak initial connections. Once blocking rules are created, the browser extensions do appear to work reliably. This behavior of leaking initial connections may be due to the default configuration which permit some elements to load from third-parties (e.g., images and CSS).

Another option, though not one you requested, is an OS-level software firewall, such as Little Snitch for macOS. I have found Little Snitch far more effective than the browser extensions at blocking the kind of behavior you are describing (and have witnessed).


To block this, you can use uBlock dynamic filtering (enable advanced user settings to use it and do read documentation):

* [::1] * block
* 10 * block
* 127 * block
* 172.16 * block
* 192.168 * block
* localhost * block

[::1] [::1] * allow
10 10 * allow
127 127 * allow
172.16 172.16 * allow
192.168 192.168 * allow
localhost localhost * allow

This will block connections from anywhere to your computer and local network, but allow such connections from your computer and local network.

As an alternative, you can use uMatrix or firewall.

  • 1
    This does not work if the attacker uses DNS rebinding. uBlock has no concept of IP addresses. Everything is a hostname. Commented Jan 15, 2021 at 20:51

You must log in to answer this question.

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