I have a restrictive Setup in my Windows Firewall so that everything which I don’t allow explicitly is blocked and logged. Normally (no GlassWire installed/ GlassWire service not running) I get a log entry every now and then form various meaningless programs checking for updates etc. When GlassWire is installed my system spams Microsoft IPs with NetBIOS requests (as you can see below there are two requests nearly every second). This behaviour is 100% sure caused from the GlassWire Control Serivce.
While I don’t think it’s a big security issue or anything else I’d really like to know why GlassWire is doing this. I cannot image it has any use? Also GlassWire seems to work fine with all the requests blocked…
Thanks for an explanation.
PS: Sorry I can’t upload images as new users so HERE is a link to the imgur
Thanks for the investigation. It’s kinda rare to see so much effort from a support team these days
But when it’s not easy to reproduce this issue this will become tough - I have some experience with such things myself. I just thought maybe it is easy to reproduce or maybe some dev who knows GlassWire really well instantly has an idea what’s going on. But as I also don’t think this is a big problem I’d probably advice to not put too much resources in this issue from this point on…
Still, in case you are also interested in this, I will post some other findings on my side (and also update here, if I should find more in future).
The behaviour is absolutely persistent on my system. It survives restarts as well as reinstallation and is independent from the GlassWire GUI. It only stops as soon as I stop the GlassWire Control Service (and starts when I start the service again).
Still it is not totally constant. Sometimes it’s not there for minutes. However it will come back every time and than in the pattern you can see from the screenshot in the first post. Unfortunately I could not identify any third party program or anything else which could be responsible for the breaks or the behaviour.
This NetBIOS NS requests are two because I have two NICs; my hardware NIC and a virtual TAP device from OpenVPN. The requests also are sent “sand alone”. Hereby I mean when I lock in the network traffic generated from PID 4 (my System) it sends a lot “useful” NetBIOS NS requests to locally existent addresses or local broadcast addresses and these requests are always sent in “blocks”; so the sending happens nearly to the millisecond exact to the same time. The two “suspicious” requests we are talking about here are sent to different times and I cannot see a pattern/connection between the “useful” requests.
As it’s not easy to reproduce I guess it’s likely that this not only has to do with GlassWire and Windows (7 64 bit Pro btw) but also some third party software or my configuration - and finding the other involved culprit here will probably not be easy…
As said, I will update should I find the time to investigate further with any results. If I can be of any help please also let me know it. When my time allows it I’ll do what I can.
I got a new system (Windows 8.1) and just installed GlassWire on it (latest version as of today). I also configured the Windows Firewall similar with the help of BiniSoft’s Windows Firewall Control. And I have the exact same strange behavior. I have the system with firewall logging enabled already over a week and there was not one of these NetBIOS requests before I installed GlassWire so again it is guaranteed related to GlassWire. The only thing were I was too fast to judge in my first post was to only refer to Microsoft IPs. Now it looks like these NetBIOS requests get sent to any IP which GlassWire got to know / logged beforehand.
So after this I would guess this behavior really should be reproducible. And I still would really be interested in why GlassWire is doing this or why it makes the windows system (it is still PID 4 like it was in Windows 7) do this. Blocking these requests doesn’t seem to affect GlassWire in any way…
GlassWire checks for software updates and also updates its suspicious host list but if you don’t like those behaviors you can make GlassWire block itself. Our software doesn’t do anything that could cause more NetBIOS related connections that I know of unless it’s some type of bug.
Maybe email us some screenshots to our “bugs” email on our contact page so I can fully understand? I’m not sure I understand it.
Well I’ve posted very exactly meanwhile how this bug (as I also already said I too believe it is one) behaves. Blocking GassWire obviously wouldn’t help as these packages are real NetBIOS packages from the OS and not from GlassWire - BUT they are only sent from the OS when GlassWire is active (so GW has to be responsible for them in some way). This is absolutely reproducible - I just gave the latest version of GW on Windows 10 Preview a new shot and there is the exact same thing.
What good would it do if I would invest even more time in sending the whole story to you’re “bugs” email? You should very well be able to create an internal bug ticket with what is important yourself - last time I checked this is one of the main jobs of a CM and I think you are something like that…
These packages are also not just some phantoms I see in a log. They are actually on the wire everytime after I contact a “new” IP this session. This for example are the packages in question when I visit the Wall Street Journal (as hex byte stream with my private mac addresses zeroed out):
GlassWire checks for software updates and also updates its suspicious host list, but we give the user the ability to make GlassWire block itself with its own firewall. https://www.glasswire.com/privacy/
We don’t ever see any of your network data because it never leaves your computer.
Theoretically it’s possible that IP to DNS resolving could produce Netbios activity but we checked all our machines here and we were unable to reproduce this.
This looks related to the issue I raised about the NetBIOS Name Service:
At the time I remember doing some investigating and this is the most relevant part of what I found.
The short story: Get rid of legacy NetBIOS devices/configurations
Windows NetBIOS Name Service broadcasts because there is a legacy device or configuration setting for NetBIOS over TCP/IP but there is no longer a WINS (Windows Internet Naming Service) server running to resolve the names. In this situation NetBIOS broadcasts are a fallback mechanism for resolving names.
When you have a device with a NetBIOS name then that name needs to be resolved to an IP address. See Is WINS Still Needed? for more info - I added the bold emphasis :
Be aware however that decommissioning WINS doesn’t just mean pulling the plug on all your WINS servers. To properly decommission WINS in your environment, you will also need to remove any WINS settings in the TCP/IP configuration of clients and servers on your network. … If you have any legacy hardware like NAS devices that are hardcoded to use NetBIOS for registering themselves on the network, and you can’t or won’t replace these devices, then you will need to implement some workarounds so they can continue working properly once your WINS servers have been removed. Typically this will mean creating static DNS records for such devices to register them with your DNS servers.
That article has links to Microsoft articles on resolving the issue.
It is likely that GlassWire developers cannot replicate the issue because they have a modern network without legacy issues. That is not the case for my network.
More background on NetBIOS over TCP/IP
When you have a device with a NetBIOS name then that name needs to be resolved to an IP address.
Older versions of Windows, pre Win-NT, use a WINS (Windows Internet Naming Service) server to resolve it.
WINS primarily supports clients that run early versions of the Windows operating system and applications that require NetBIOS. Later versions of Windows including Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8 use Domain Name System (DNS) names in addition to NetBIOS names. Environments that include older computers that continue to use NetBIOS names on the same network as computers that use DNS names must use WINS servers in addition to the DNS servers.
If WINS is not running then NetBIOS name resolution proceeds as if there is no WINS entry for that NetBIOS name - see bold emphasis below. NetBIOS over TCP/IP Name Resolution and WINS:
Check to see if it is the local machine name.
Check its cache of remote names. Any name that is resolved is placed in a cache where it will remain for 10 minutes.
Try the WINS Server.
Try broadcasting.
Check the LMHOSTS file, if the system is configured to use the LMHOSTS file.
Try the HOSTS file and then a DNS, if so configured.
Nbtstat is designed to help troubleshoot NetBIOS name resolution problems. When a network is functioning normally, NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. It does this through several options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, LMHOSTS lookup, Hosts lookup, and DNS server query.
Here I use nbtstat to see broadcast stats:
C:\Users\Me>nbtstat -r
NetBIOS Names Resolution and Registration Statistics
----------------------------------------------------
Resolved By Broadcast = 47
Resolved By Name Server = 0
Registered By Broadcast = 118
Registered By Name Server = 0
Hey guys, reporting that I too am having the same problem / bug.
Open your task manager and click on the performance tab as
an alternate way to check your network connections.
Here is a short video that can assist you with work arounds:
I just created an account to bump this, THIS HAS TO BE FIXED!
I noticed this issue after “System” started spamming a ton of different gameservers with NetBIOS traffic that were automatically pinged in the server list for latency tests for a game, even long after I closed it.
The data usage might not be big but it adds up, GlassWire is literally spamming IPs with garbage traffic.
I just disabled NetBIOS and it stopped now.
By the way, I am not sure how exactly NetBIOS works but there is often talk of security issues with it, is this a concern with queries like this?
Our software does nslookups on hosts you connect to so inside GlassWire you can see when you connect to an IP, it resolves to Google.com for example. This is a popular feature of our software and it uses no noticeable resources.
However, if an nslookup on a host is upsetting to you for some reason you can disable nslookups so you can no longer resolve hosts you connect to.
stop the GlassWire service;
open C:\ProgramData\GlassWire\service\glasswire.conf as admin;
change the value to hostname_enable_nslookup to false;
save the changes and restart the GlassWire service.
I think you don’t understand what we are talking about here, especially since you renamed the thread from “NetBIOS” to “BIOS”, something unrelated.
When I disable NetBIOS in Windows, the “spam” from GlassWire stops, but the host names are still resolved. This can be confirmed by doing nslookups manually, these two things are completely unrelated.
NetBIOS is a different type of name resolution, due to a weird thing in Windows, it tries to do it before the normal DNS lookup if certain network conditions are present (legacy devices or bad router config, which is common in ISP routers). This also likes to get stuck and do other weird stuff.
While it technically “isn’t your job to fix” as it is partly a Windows issue, considering how common this is, you should look into providing a workaround, possibly in the form of a setting to prevent this from happening.
It is also a privacy issue as this NetBIOS spam occasionally continues for a while after the connection has stopped which may be an issue for VPN users.
Edit: Just to be clear: “System” (probably on behalf of GlassWIre) sends NetBIOS requests to hosts for multiple minutes after the initial connection, there is no way that is intended behavior.
GlassWire doesn’t do anything on the network besides check for updates (software and malicious host list) once per day, and do nslookups on hosts. Instructions on how to disable nslookups are above in this thread.
If you don’t want GlassWire to check for updates you can make it block itself under its own firewall.
GlassWire does not do anything with the NetBios.
Maybe you are just looking at traffic between our service and our UI on your own PC or something like that? If that’s the case, then this is local traffic between our service and UI and it does not use the network at all.
