Again, this is 100% a NetBIOS related issue, disabling NetBIOS over TCP/IP removes this traffic. Someone in this thread also said that this occurs due to the lookup order in Windows.
Frankly, I suspect that unless you write your own nslookup this will remain an issue.
Wouldn’t just using the DNS cache make nslookups unnecessary?
Thanks for your feedback.
GlassWire itself is just a network monitor and it doesn’t really use any significant network resources, besides doing some simple nslookups and software update checks. And as I posted previously you can make GlassWire block itself with its own firewall, and instructions on how to disable nslookups are above.
Also, please note our Android app has no ability to access the network at all.
I will submit this thread to our team and see if they have any comments.
Our team asked if you tried the nslookup disable option as suggested above, and if that made the NetBios traffic you are seeing go away or not? Thanks.
I just tested it and it made the traffic successfully go away (I made sure to turn NetBIOS back on during the test).
It’s still something that should be addressed, considering it seems to be an issue with nslookup looking up NetBIOS instead of directly jumping to DNS/hostfile it shouldn’t be necessary to completely disable that functionality (If you can’t just disable NetBIOS).
Just adding that when checking the network traffic in my PC (Win10 Pro) I saw NetBIOS traffic as well (didn’t check if it was GlassWire related) but I’ve turned off the NetBIOS for my network adapter so it would stop
If you have our nslookup feature on, but your PC is in “Block All” mode and you don’t see any network activity in GlassWire, do you see NetBios activity?
I’m asking because if it’s the nslookups somehow, then if GlassWire is NOT doing any nslookups (due to no network activity) then perhaps there should be no NetBIOS activity?
Also if GlassWire’s service is killed do you see NetBios activity? Thanks.
The NetBIOS traffic stops when Block all is on. (And it resumes when it’s off, I just tested it)
I am not set up to check if it stops when the service stops (GlassWire obviously doesn’t record activity when it’s stopped) but considering the nslookup feature is clearly the culprit here as disabling it fixed the issue it has to be an issue with GlassWire.
The way to know if the nslookups are the issue would be to stop our service, then watch the NetBios traffic. We’re unable to recreate this on our end.
Please let us know if you’re able to check and what you find. Thanks.
If you guys go to Control Panel -> Network and Internet -> Network Connections (adapters) -> Right Click the adapter you use -> Properties -> IPv4 (click Properties when selected) -> Advanced… -> WINS -> Enable NetBIOS over TCP/IP (it should force it on without router config) and then turn on nslookup in GlassWire config and go to websites (websites with CDN like youtube or twitch are the best) do you see NetBIOS traffic from “System”?
Doing this should to my knowledge replicate what is happening for me and the other users. If this doesn’t work for you please let me know because I can try something but it might be a bit difficult and I don’t want to waste time figuring it out if this replicates it for you guys.
I deleted my previous post because my edits got out of hand.
I tried reproducing your issue, @Thinking, but I wasn’t able to do it on Windows 10 - NetBIOS over TCP/IP are enabled and GlassWire nslookups are enabled in hte config file.
NetBIOS traffic is as I would expect, each broadcast arising from a specific application but attributed to the SYSTEM application. The one issue I found is that the NetBIOS Name Service appears to include DNS name resolution.
So @Ken_GlassWire, does what GlassWire shows as NetBIOS Name Service actually include DNS name resolution?
Here’s some reasons why I think it does:
URLs that are resolved through my web browser also appear under NetBIOS Name Service.
Only the NetBIOS Name Service has external traffic.
I have Windows Firewall running and it should limit NetBIOS broadcasts to the subnet, but there is external traffic showing. Whereas the NetBIOS Datagram Service and the NetBIOS Session Service don’t get out of the subnet, as expected.
Using the NetBIOS utility NBTSTAT with only an IP address generates a URL in GlassWire
nbtstat -A 40.100.146.194
Although there was no matching NetBIOS name in the cache, GlassWire Usage | Traffic showed the correct URL under NetBIOS Name Service i.e. 40.100.146.194 resolves to outlook.ms-acdc.office.com. But the name resolution doesn’t appear to be done by DNS as it doesn’t appear in the DNS cache:
ipconfig /displaydns
I haven’t used other tools to check what is actually happening but it wouldn’t be difficult, just too time consuming for me right now.
That’s literally what I was talking about, SYSTEM is sending NetBIOS requests on behalf of GlassWire?
NetBIOS traffic does not include DNS, if I enable NSlookup in GW and disable NetBIOS in Windows, I don’t get that traffic anymore.
It is an issue with the order how stuff is being looked up, when Windows thinks NetBIOS is used on the network it will do it before DNS.
So far I can only confirm those generated by WIndows NetBIOS. I’d have to either monitor the processes or monitor network traffic (before and after GlassWire is installed) and I don’t have time for that.
Anyway, the best solution for me and 99.9% of users is to disable NetBIOS over TCP/IP which we should be doing anyway because of the security vulnerabilities it creates (see the link below). @Ken_GlassWire, It might even be a worthwhile security measure for to GlassWire help users to turn it off if it is on.
The only reason to keep using NetBIOS is if you run an old application that requires it. Typically, we’re talking about applications from about twenty years ago.
I’m still interested to know why there is NetBIOS external traffic because it was limited to the subnet at one time. I remember when Microsoft limited NetBIOS by default and there was a big outcry from those with systems that didn’t use FQDN for SMB/CIFS. Maybe Microsoft reversed that change.
Thank you for your feedback on this issue.
We have now researched this issue in detail.
If you don’t like GlassWire to do nslookups you can change the config file as recommended above. We’re considering adding a simple on/off switch for this feature in the future.
The way our nslookups work is that we use a standard Windows API to do an nslookup. In fact, if you do an nslookup in the Windows command prompt it works in an identical way. The reason we know this is because we checked this and confirmed it works the same way.
So, in summary, GlassWire does nslookups using a Windows API and it’s the same way the Windows command prompt does an nslookup. If you are unhappy with this you can disable nslookups with GlassWire using our config file.
Or, you can disable NetBIOS traffic with the Windows OS.
Right click the start menu > Network Connections > Right click your connection > properties > Click Internet Protocol Version 4 (TPC/IPv4) > Properties > Advanced… > WINS tab > Disable NetBIOS over TCP/IP
I think Remah also mentioned this option along with some other helpful commentary.
Further support for disabling NetBIOS over TCP/IP is that Internet Service Providers (ISPs) are stepping in to block NetBIOS. The largest ISP in my country (44% market share) has just announced that they will block the ports for both NetBIOS and SMB:
Just a quick heads up on a change we’re making to our Broadband network to increase customer security. As per industry best practice we’re going to start blocking the ports used for SMB and NetBIOS on our Broadband connections. Those protocols are fairly well documented to be insecure and should never be used outside your own LAN - i.e. never on the internet.
The specifics of the ports being blocked are:
Incoming TCP ports 135->139
Incoming TCP port 445
This was implemented for Wireless Broadband Static IP nationwide from day 1. It is now being progressively rolled out across ADSL/VDSL and [Fibre]…
What the above articles doesn’t say is that newer versions of SMB reduce the risks dramatically. It is the older SMB formats that carry the greater security risks when exposed on the Internet.
SMB 1.0 is used for Windows XP which has been out of support since 2014. Nobody should be using it on the Internet.
SMB 2.0 is used for Windows Vista and 7 and has better security turned on by default in Windows but this is not the case for third-party products.
SMB 3.0, which was introduced with Windows 8 and Windows Server 2012, provides end-to-end encryption that removes much of the risk.I just remembered this thread and would like to ask a couple questions that you guys might know answers to regarding the nslookup behavior which could be very important:
Are NetBIOS lookups actually a security issue?
From what I’ve gathered it is only intended for local networks, so there isn’t an issue with the netbios service UPNP forwarding itself (e.g. opening a port). Can the lookups still be exploited?
While it was active, I received one or two seemingly* inbound connections (e.g. 0 bytes sent) from Shodan Census (Crawler) and some Chinese botnet server assigned to the System entry (only around 200bytes and no other activity, I checked using autoruns, procexp, etc.). During this time I didn’t have any application opening an Upnp port, is is possible that this was a sideeffect of the NetBIOS request? It never happened again after disabling it.
*This might be a bug with GlassWire, seemingly incoming requests to the System entry also happened with Battlefield and GMod game servers while NetBIOS was active (only around a couple bytes).