1

Does anyone have an at-a-glance list of common, required Firewall rules?

Because we’ll be doing internal pen tests to satisfy PCI regs, obviously now the internal defences need to come up, which ofc means our internal rule lists are tabula rasa.

Microsoft don’t make it easy with their dynamic ranges and multiple conflicting documents on TechNet/MSDN and there’s common services that we all just take for granted without thinking about whether they work or not.

Anyone out there have a de-facto list and or importable policy they repeatedly use, ideally split into Inbound & Outbound and Desktop vs. Server?

3 Spice ups
2

If this is for PCI, don’t they have a list of requirements for firewalls that you can self audit against?

3

They have a short-list of the obvious unsecured ports that they require to be fudged into their secure alternatives, but I’m after a more functional list of common software…

I.e. What I mean is to make/compile a list of what would be required to make AD, SQL Server, Sharepoint, Spiceworks, RDP, Ninite, Dameware etc. work.

I’ve seen your name crop up in several posts relating to AD ports, which is a good start - care to contribute?

I’ll knock together a crowd-sourced Google Doc, if that will help.

4

Personally, I wouldn’t firewall AD but that’s just me.

So you want a list of ports, ok:

Spiceworks - 80 (or 443 if you make it secure)

RDP - 3389 - unless it has been changed

Ninite - Remote Connection Information | Ninite Help

SQL Server - 1433 unless it’s running instances and then it can use random ports, these ports can be hard coded

Dameware - I’d be surprised if this is allowed in a PCI environment as it’s often a tool of choice for hackers.

Shareport - 80 and 443 (if you use SSL)

and the best is last. AD - Active Directory and Active Directory Domain Services Port Requirements

1 Spice up
5

I wouldn’t either, but if you’re writing the profiles from a security point of view, the common methodology is to deny all then poke the required holes as needed, yes?

Also, Spiceworks requires inbound TCP 139 & 445 and UDP 137 & 138 for the scans, according to the documentation.

Here’s the Google Doc, if you/anyone else want to contribute: Firewall Rule Cheat Sheet - Google Sheets

6

No.

There is a difference between securing something for practical reasons versus security potentially causing more problems.

Because of the way AD works, I wouldn’t block any of it’s ports. If there are genuine security concerns then there are better ways to lock down your AD servers.

7

Correct as well as TCP 22 and more but that’s outbound, not inbound.

8

Then maybe I’m being stupid, but how do you work around the Windows Firewall concept of ‘Inbound connections that do not match a rule are blocked’ if you are not defining the rules?

I see now that a number of Core Networking rules are already defined in the local WFwAS Rules. I wasn’t intending to override them, just making sure all the boxes are ticked and ensuring I can turn the Windows Firewall Domain Profile from ‘Allow All’ to ‘Block (Default)’ in GP and not have the entire company come crashing down.

9

I don’t use the windows firewall on anything other than laptops. On the servers, I’m using vlans so that, if required, other tools such as IDS systems can examine the traffic as it passes between networks.

1 Spice up
10

Good point. Maybe I’m approaching this problem the wrong way around - IDS via Snort on pfSense is on the todo list. I guess I just wanted to stop Windows Action Centre from moaning about the Firewall status without simply just ‘disabling the message’…