User-ID Agent Windows Firewall Settings

[djr]

Hi,

I just found a bit of a weird problem with the User-ID on a 2008 server due to the windows firewall.

I am using AD service polling and SYSLOG feeds for the User-ID but I couldn't get the syslog messages to be recognised.  I could see them hitting the server via wireshark and when I turned of f the Windows Firewall they started working so it was clear where the problem was.

When I configured the Windows Firewall I selected the user ID service and allowed all ports and protocols to it (inbound rule).  This meant that the firewalls could connect to it and I confirmed that was working OK.

The only way I could get the syslog messages through was to create another rule allowing UDP 514 through to any program/service.

Looking up with netstat though, port UDP514 was owned by the UAService.exe process which was the same as port TCP 5007 so that seemed as if it ought to work with the initial rule.

Can anyone shed any light on why that first rule didn't work and what the recommended windows firewall rules are? (I did a search and couldn't see any articles on this)

Thanks

[mivaldi]

UDP 514 is for the Syslog messages

Does Syslog Use Random or Fixed Port?

TCP 5007 is for the communication from the Firewall to the User-ID Agent

What is the Communication Direction for User-ID?

I am not clear what "first rule" you're referring to.

The recommended Windows Firewall configuration is to only open the ports you need to make the set of features you need, work for your setup. Make sure to understand the ports you need. It wouldn't be wise to open more ports than you needed and these vary from setup to setup.

[pulukas]

The windows firewall rules created using the by program method are usually successful for this type of operation.  But as you have seen if there are some communications involved that are well-known standards ports then they may still be seen as separate from your program allowed setting in windows.

The other thing to be aware of is that these program rules are not necessarily permanent in their operational port selection.  They are mostly the same but they are deployed based on how windows programmatically sees the application working.  I generally use them to identify the unknown ports of communication on a server then write specific inbound and outbound port based rules for all the traffic so identified and remove the program rule.

Of course the best solution is that vendors provide a kb article on their application traffic and direction needs so we can create those rules in the first place when the application is installed and activated.  So we don't have to find them in packet captures and reverse engineer the rules.

[djr]

Hi,

The "first rule" was the rule based on the service process rather than the port based rules for SYSLOG and the User ID agent port

Your last line is precisely why I went for the service-based option.  I prefer to think of processes as trusted, so allowing the service is better in my mind than allowing all the ports it may need (and having to reverse engineer which ports it needs as Steven said).  It also means if I add another User ID mechanism I don't have to go round my agents fiddling with firewall rules.

I do think a KB article or preferably something in the documentation on the windows firewall config would be reasonable, if the software installation doesn't do that for you.

[pulukas]

Right now the closest thing we have to the firewall recommendation is the document 2831 linked by mivaldi above. 

What is the Communication Direction for User-ID?

I added a comment there asking for it to be expanded with more specific information on windows server firewall recommendations.  The documentation and kb teams are pretty good about responding to reasonable requests like this.  so hopefully, you will see it updated.