Networking issues with PrivateFirewall (split to own thread)

The more I get into PF firewall rules, the stranger it gets.

First, I an running WIN 7.

For starters, observe where the DHCP rules are located in PF. Since XP, DHCP is controlled by svchost.exe but in PF the DHCP rules are located under System Services? If you try to set up the DHCP rules under svchost.exe where they should be, you will get bombarded with outbound udp port 1900 to remote IP 239.255.255.250 messages in your PF firewall log. Appears to me PF has issues with muticast traffic. It also appears to ignore the outbound udp port 1900 default rule PF generates for svchost.exe.

Then there are the strange DNS tcp port 53 outbound rules in lsass.exe and services.exe. Lsass.exe is only applicable to domain i.e. office profile and services.exe has not been used since WIN 2000?

Finally there are rules missing that are required for WIN 7 Homegroup to function:

svchost.exe

1. In/out tcp port 3587
2. In/out udp port 3540

system

1. In tcp port 2869 -WIN mediaplayer networking
2. In/out tcp port 5357-5358

Might explain why people trying to network with PF are having issues.

 

Since I am "letting things hang out" in this thread, I will add I don't like the default LAN network rules PF generates for WIN 7.

Using the svchost.exe LLMNR default rule for an example, you will note that the rule is set up as inbound/outbound UDP from 1024-65355(user) local port to 5355 remote port. This implies in/out traffic to/from port 5355?

This is not how it works. The outbound UDP traffic to remote port 5355 is OK but not super secure. This is a local-link muticast broadcast to the IPv4 address of 224.0.0.252 and IPv6 address of ff02::1:3. In other words, your local subnet. It's the inbound rule that I have a real issue with. In my opinion, a separate inbound rule is needed to allow and restrict inbound traffic from your LAN to local port 5355. The inbound rule for LLMNR should be UDP local port 5355 and remote port 1024-65355(user).

 

I have playing with the PF 7 firewalls for a while so i thought I would revisit this thread.

First, I will say that you are best to leave the system and svchost.exe rules alone with minor secruity tweaks; things like restricting DNS to your DNS servers or gateway, DHCP to your gateway if it contains a DHCP server as most do, etc. I have found out PF has a mind if its own in determining what is your local subnet.

I also have no clue why DNS TCP is enabled for the services.exe rule? It definitely is not used by WIN 7. I have disabled it without one firewall log block entry to date.

PF's firewall ICMP/ICMPv6 rules are an entirely different matter. Appears to me these rules are leftovers from the days when PF was a paid commerial firewall? The rules are of the nature you would find on a corporate client box.

One definite no-no is that redirect is enabled for both ICMP and ICMPv6. Redirect is only needed for networks that contain multiple routers which is not the case for most home networks. Minimally, that rule should be disabled for both ICMP and ICMPv6.

For ICMP, my allow rules are inbound; destination unreachable, echo reply, and time exceeded and outbound; destination unreachable IP only to my DNS servers addresses, I use NortonDNS servers, and echo request.

Note: what I don't like about these rules is I have no way of knowing what code of destination unreachable this rule applies to. There are mutiple ones. The one it should apply to is code 4 - MTU Path Discovery.

For ICMPv6, the error message rules are OK. For information messages, I allow all except; redirect, router renumbering, ICMP node rules, Home Agent rules, Mobile Prefix rules*, the experimental rule, and the FMIPv6 messages rule.

* Mobile rules might be needed if connecting to mobile devices, etc.

 

This will be my last posting in this thread for a while. I was able to secure a copy of Kapersky IS 2012 for free after rebate. So why fool around driving a Ford when you can ride in a Cadilac?

I also have found PF's firewall a bit to restrictive for my needs. I also believe this firewall is a "rebagged" version of the old Sygate firewall. Great for it's day but totally obsolete for today's needs. PF's HIPS on the other hand is great. Would love to see the HIPS offered as a separate product. Coupled with the WIN 7 firewall would be a great combo if you don't care about monitoring outbound connections.

There is one major vunlerability in PF in my opinion I will mention. Sometime ago, I asked the developer if PF monitors localhost connections. The answer was no. As such, I believe PF is vulernable to today's DNS rebind attacks. Without getting into the nitty gritty of that, I will say firewall rules need to be added to PF svchost.exe application rule to deny oubound connections from any local port for TCP and UDP to remote port 53 for only remote address 127.0.0.0/255.255.255.0. These new rules need to be moved above the existing DNS rule.

Edit - one other point I should mention. Some AVs use localhost. Norton is one of them. FYI - Norton also uses this capabilty to dial home to the Symantec mothership regardless of option settings to disallow this. Technically if you are using one of these AVs, your localhost connections should be protected. Your call. I personally would still add the above localhost deny DNS rules to PF.

For those wondering how DNS rebinds occur, they happen when your router is hacked. Recent research has shown there are thousands and possibly millions of hacked routers currently connected to the Internet.

How to Hack Millions of Routers

This talk will demonstrate how many consumer routers can be exploited via DNS rebinding to gain interactive access to the router's internal-facing administrative interface. Unlike other DNS rebinding techniques, this attack does not require prior knowledge of the target router or the router's configuration settings such as make, model, internal IP address, host name, etc, and does not rely on any anti-DNS pinning techniques, thus circumventing existing DNS rebinding protections.

A tool release will accompany the presentation that completely automates the described attack and allows an external attacker to browse the Web-based interface of a victim's router in real time, just as if the attacker were sitting on the victim's LAN. This can be used to exploit vulnerabilities in the router, or to simply log in with the router's default credentials. A live demonstration will show how to pop a remote root shell on Verizon FIOS routers (ActionTec MI424-WR).

Confirmed affected routers include models manufactured by Linksys, Belkin, ActionTec, Thompson, Asus and Dell, as well as those running third-party firmware such as OpenWRT, DD-WRT and PFSense.

Craig Heffner