I launched Windows Word for the first time and Glasswire’s firewall ASK TO CONNECT popup said winword.exe wanted to connect to the internet. I denied it access to the internet. I didn’t study the popup closely at the time.
How can I now go back and see what Host/IP address winword.exe was trying to connect to?
Since I denied access I don’t see it in the Alerts or Graph.
All information (date/time, destination host/ip) about the app trying to connect seems to be lost when I deny an app access to the internet.
When an app is denied access to the internet, is there anywhere in Glasswire where I can later see the same type of information that is reported in the ALERTS log?
When I click on the Winword.exe app in the Firewall list it does not have any historical activity info (like the Alerts), such as first/last time the app was denied access and what host/IP it was trying to connect to.
Before you allow or deny the connection, it shows the connection in our “Ask to connect” window.
I made Outlook try to connect to show an example similar to the one you mentioned. You can then mouse over the host, and it will have a three dot menu where you can see more host info. Or you can go to https://www.glasswire.com/host/188.8.131.52 and see what the host is the app is trying to connect to.
Once you deny the connection though we don’t save the host since the connection failed, but perhaps we should look at doing that for the future. Thanks for your feedback.
Saving the host is irrelevant, unless I misunderstand your exact meaning.
I noted on this a ways back… May, 2017.
Given if deny is chosen it’s because the user determined (read: panicked) as such and then there is no way to find out what was involved.
The info should be available after the fact and gleaned from an entry in Alerts as “First network activity - Network access denied,” not in “Ask to connect” when a possibly malicious process is fully active albeit waiting on a connection.
As well a “Network access allowed” should be posted. Because this and denied are similarly not posted in alerts until an actual allowed actual, but NOT denied, connection is made. That is, there is a only “connection initiated” alert, but not a “connection blocked.”
The lack of complete and differentiated “access” and “connection” alert posts for allow and deny has been IMHO a One Big Fail in the otherwise superb features in GlassWire.