none
Firewall "Query User" filters not querying user RRS feed

  • Question

  • skip to >>><<< if you're not interested in the background

    (I'm reporting this on Windows 10, 'cuz that's what my desktop is running, but we're seeing this on Windows 7 & 10 & Server 2012R2.  This (getting lots of 5152s) happens on some hosts and not others (seemingly at random), but is persistent on the hosts where it's happening and rare or nonexistent on hosts where it's not)

    It started with seeing 5152s in the security event log for a bunch of commonly used ports.  This first came to my attention in August when I couldn't connect via WinRM to a server I usually had WinRM (port 5985) access to.  I saw piles of 5152s in the Security event log (some for 5985), thought "hey, that ain't normal", double-checked my desktop and saw them there, too.

    With the help of internet search, I discovered how to track the filter ID back to the filter description (netsh wfp show state).  (And also discovered that the filter IDs seem to be dynamically assigned and are only good since the latest reboot).

    The problem has come and gone (more than once) with various network reconfigurations.  Finally it bugged me enough to post something about it.  The tipping point came when 1) the 5985 blockage came back today and 2) I couldn't get a guest VM to talk to SQL Server on the host (my desktop), even though various other ports were working, things seemed to be set up correctly in the config manager (SqlServerManager11.msc) and I could see SQL Server and SQL Browser listening on the appropriate ports with netstat and procexp,

    Any road up, some of the most common filters that show up in connection with these 5152s have the name Query User and the description Prompt the User for a decision corresponding this Inbound Traffic.  I have Security and Maintenance notifications turned on under Notifications & Action in setting.  But I never get asked (searching the internet turns up indirect evidence that some people do get asked when they hit these rules).  The rules in question don't appear in the UI for Windows Defender Firewall with Advanced Security.  I suppose they could be stealth mode filters, come from Sophos (the AV and endpoint safety software we use), GPOs or be dynamically injected from some other source through the API.

    >>>Has anybody else bumped into this?  Anybody have any diagnostic hints?<<<

    I've thrown together some bits of PowerShell (based, again, on stuff I found from searching the internet) to help me gather some information on the phenomenon.

    $os     = gwmi win32_operatingsystem
    $bt     = $os.ConvertToDateTime($os.LastBootUpTime)
    $minutesUp = (get-date).Subtract($bt).TotalMinutes
    
    $fiftyOne52sSinceBoot = Get-WinEvent -FilterHashtable @{ProviderName='Microsoft-Windows-Security-Auditing' 
      StartTime=$bt; Id=5152}
    
    $fiftyOne52sSinceBoot `
    | %{
      $evt = $_
      $propLines = $evt.FormatDescription()  -split "`r?`n" -match '\S\s*:\s*\S'
      $propLines | %{
        $name, $val = $_.split(':', 2)|%{$_.Trim()}
        $evt | Add-Member -membertype noteproperty -name $name -value $val
      }
    }
    
    $fiftyOne52sSinceBoot | group 'Filter Run-Time ID', Direction, 'Source Address' <#, 'Source Port'#>,
      'Destination Address', 'Destination Port', 'Application Name' | ?{$_.Count -ge $minutesUp / 10 }| sort count -desc `
    | ft count, name, @{n='Earliest';e={($_.group | measure TimeCreated -Minimum).Minimum}}, 
                      @{n='Latest';  e={($_.group | measure TimeCreated -Maximum).Maximum}} -AutoSize
    
    Add-Type -AssemblyName System.Xml.Linq
    $xdt = [System.Xml.Linq.XDocument]
    cd $env:temp
    netsh wfp show state
    $ws = [xml](gc .\wfpstate.xml -raw)
    $ws.SelectNodes('//*[filterId=67614 or filterId=68186 or filterId=68214 or filterId=66808 or filterId=67642 or filterId = 67238]') `
    | %{$xdt::Parse($_.OuterXml).ToString()}


    Monday, November 6, 2017 11:49 PM

All replies

  • Hi,

    Based on your description, it seems that there might be something wrong with the firewall, please try troubleshooting tools and see if it helps.

    Automatically diagnose and fix problems with Windows Firewall

    https://support.microsoft.com/en-us/help/17613/automatically-diagnose-and-fix-problems-with-windows-firewall

    If the problem still persists, please try the following article.

    Restore or reset Windows Firewall settings to defaults

    http://www.thewindowsclub.com/reset-windows-firewall-settings

    Please Note: Since the websites are not hosted by Microsoft, the links may change without notice. Microsoft does not guarantee the accuracy of this information.

    Best Regards,

    Tao


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 8, 2017 2:25 AM
    Moderator
  • Thanks for showing an interest.  Troubleshooter (WindowsFirewall.diagcab): "issue not present" for all issues.  Restore defaults/netsh advfirewall reset - no change in the 5152s, SQL Browser still blocked.

    I like suggestions that are easy to try, though:-) 

    Some critical text in the firewall control panel: For your security, some settings are managed by your system administrator (since I'm an admin on my own system, I suspect the issue here may be something that a domain admin has done.  Yes, the domain admins are aware that a number of machines have their security event logs filled with 5152s, at the rate of dozens per minute.  Haven't heard a thing from them yet.  I was kind of hoping to connect with someone either more knowledgeable or less swamped.)

    OABTW - the 5152s on port 5985 went away a day after my base post (and haven't come back (yet)).  A potentially interesting aspect of the 5152s on 5985 - WinRM was being blocked on the VM host at the same time that it was accessible on VM guests.  I have yet to bump into 5152s on 5985 for the VM guests, but they've come and gone several times on the VM host.  This may be relevant or it may just be noise.  Hard to know at this point.
    • Edited by un6o6 Wednesday, November 8, 2017 2:30 PM ongoing developments
    Wednesday, November 8, 2017 1:37 PM
  • Hi,

    We haven’t heard from you for a couple of days, have you solved the problem? 

    Best Regards,

    Tao


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 17, 2017 8:32 AM
    Moderator
  • No.  At our site, it's been happening for months and is still happening.

    If you search for security event 5152, you'll see that

    • it's been happening to Windows systems at least as far back as 2009
    • it affects both server and workstation versions of Windows
    • for many people the problem appears to be unresolved
    • for some of the people who have "resolved" the problem, they've merely suppressed the message with auditpol

    If the problem were merely extraneous messages, I'd go with the auditpol solution (although I'd still consider it a bug that we're seeing regular DHCP and LLMNR traffic in the security event log).  But we have ports blocked, seemingly at random, for reasons I've so far been unable to decipher.

    [later edit and afterthought: we do have a lot of retransmits on our network, which the firewall may see as attackish - but that really seems like a long shot.  And you may ask: why don't you fix your network?  Personally I don't have physical access to or control over that part of the network.  There are people who do.  And last time they tried to clean up the network, it fixed the retransmission problem but broke something else.  And retransmissions were the lesser evil]

    [even later edit] I now suspect some kind of poor interaction between the Sophos firewall and the native Windows firewall.  I recently received a new VM, noticed the 5152s and quickly grabbed the security event log contents before they wrapped.  I found the first occurrence of a 5152 and examined the application, system and security event logs for events that happened just before this first 5152.  The thing that happened just before the 5152s started flooding the security event log is that Sophos Endpoint Firewall was installed and started.  As to why this happens on some systems and not others (Sophos firewall is on pretty much all our systems, I think), I have no idea (yet).

    I've revised the tail end of the PowerShell snippet to make it a bit more automated:

    $grouped5152s = $fiftyOne52sSinceBoot | group 'Filter Run-Time ID', Direction, 'Source Address' <#, 'Source Port'#>,
      'Destination Address', 'Destination Port', 'Application Name' | ?{$_.Count -ge $minutesUp / 10 }
      
    $grouped5152s | sort count -desc `
    | ft count, name, @{n='Earliest';e={($_.group | measure TimeCreated -Minimum).Minimum}}, 
                      @{n='Latest';  e={($_.group | measure TimeCreated -Maximum).Maximum}} -AutoSize
    
    $filterIds = $grouped5152s | %{$_.Group[0].'Filter Run-Time ID'} | sort | Get-Unique
    
    Add-Type -AssemblyName System.Xml.Linq
    $xdt = [System.Xml.Linq.XDocument]
    pushd $env:temp
    netsh wfp show state
    $ws = [xml](gc .\wfpstate.xml -raw)
    popd
    $ws.SelectNodes("//*[$(($filterIds | %{"filterId=$_"}) -join ' or ')]") `
    | %{$xdt::Parse($_.OuterXml).ToString()}




    • Edited by un6o6 Tuesday, April 17, 2018 3:03 PM
    Friday, November 17, 2017 6:41 PM
  • I'm not sure how much what I see is related to what you see, but I do see EvenID=5152 too.
    I'm posting this hoping that by describing various situations where this event happens, one would ultimately be able to understand the root cause.

    The setup is simple:

    • The PC (Windows 10 version 1903) with eth1: 192.168.165.71 is hosting an OpenVPN server (dev tun, 192.168.137.1).
    • The eth1 got Internet Connection Sharing (ICS) enabled (shared for the OpenVPN).
    • There's one client, "Client1" (192.168.137.2).
    • The 192.168.165.71 is marked as a private network
    • The 192.168.137.1 is marked as a public network (just because it's a common issue of OpenVPN TAP adapters).
    • The Client1 can ping 192.168.165.1, 192.168.137.1, 8.8.8.8. It's able to access web sites (via the OpenVPN).
    • The Client1 cannot ping 192.168.165.71.
    • On PC, I've added a Windows Defender Firewall rule to accept any connections (Protocol=Any, LocalPort=Any,...) from 192.168.137.2 . No other Firewalls are installed on PC.
    • I've checked that no "Block" rules that might interfere are visible.
    • The Client1 is able to connect to 192.168.137.1 via SMB_v1.

    The weird thing I tried to fix is that Client1 is only able to connect to 192.168.137.1 via SMB_v2 (port 445) if Windows Defender Firewall is completely turned off for "Public networks".

    I've tried this, but it doesn't fix the issue.

    To debug this, I've followed this article  to enable logging dropped packets.
    And this is the "blocked" event (EventID=5152) I caught:

    The Windows Filtering Platform has blocked a packet.
    
    Application Information:
    	Process ID:		4
    	Application Name:	System
    
    Network Information:
    	Direction:		Inbound
    	Source Address:		192.168.165.71
    	Source Port:		62552
    	Destination Address:	192.168.165.71
    	Destination Port:		445
    	Protocol:		6
    
    Filter Information:
    	Filter Run-Time ID:	306834
    	Layer Name:		Receive/Accept
    	Layer Run-Time ID:	44

    In "wfpstate.xml" the 306834 is:

    <item>
    	<filterKey>{abc}</filterKey>
    	<displayData>
    		<name>Query User</name>
    		<description>Prompt the User for a decision corresponding this Inbound Traffic</description>
    	</displayData>
    	<flags/>
    	<providerKey>{abc}</providerKey>
    	<providerData>
    		<data>653a000000000000</data>
    		<asString>e:......</asString>
    	</providerData>
    	<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
    	<subLayerKey>{abc}</subLayerKey>
    	<weight>
    		<type>FWP_UINT8</type>
    		<uint8>8</uint8>
    	</weight>
    	<filterCondition numItems="1">
    		<item>
    			<fieldKey>FWPM_CONDITION_ORIGINAL_PROFILE_ID</fieldKey>
    			<matchType>FWP_MATCH_EQUAL</matchType>
    			<conditionValue>
    				<type>FWP_UINT32</type>
    				<uint32>1</uint32>
    			</conditionValue>
    		</item>
    	</filterCondition>
    	<action>
    		<type>FWP_ACTION_BLOCK</type>
    		<filterType/>
    	</action>
    	<rawContext>0</rawContext>
    	<reserved/>
    	<filterId>306834</filterId>
    	<effectiveWeight>
    		<type>FWP_UINT64</type>
    		<uint64>9223372036854791168</uint64>
    	</effectiveWeight>
    </item>

    So, the PC is trying to contact itself (I'm not sure why). 
    And runs into this weird "Query User" rule which does not actually query me.


    BTW, I do have notifications enabled:


    • Edited by i3v Monday, February 24, 2020 8:23 PM fixed link
    Monday, February 24, 2020 8:19 PM
  • Interesting - yours is the first report of the problem I've seen where some explicitly mentions they have no other firewall products installed (not they I've tried to look at all the reports in detail - they're pretty numerous).  I had kind of assumed that the problem wasn't being solved because it fell into some middle ground between Microsoft and 3rd party firewall vendors and neither wanted to touch it.  It's interesting to know that the Microsoft firewall is capable of doing this to itself:-)
    Monday, February 24, 2020 8:30 PM
  • We have almost the same issue with our Windows Server 2016 + OpenVPN server. The only solution we've managed to find is changing network profile for TAP adapter from public to private. Only after that server's local interface became accessible from VPN client, despite we have a rule that allows incoming connections to specific ports for Any profiles.
    Friday, March 13, 2020 9:41 PM
  • I'm glad you found a solution.  We haven't and it's my impression that most people have not (other than suppressing the message with auditpol, which seems to me like throwing the baby out with the bath water).

    Your post prompted me to look back over this thread.  This thread in answers.microsoft.com is the earliest report I can quickly find.  That was June 15, 2009.  So the issue had its tenth anniversary last year.  I wonder if it will make it to 15.  20?

    Friday, March 13, 2020 11:50 PM