CFP and Portslock

I’ve been doing an in-house review of security guidelines. All the usual good stuff and applications to make surfing the net a whole lot safer. A question came up about ‘per user’ firewall rules. A google search turned up very little, except for a product called “Portslock” ( It’s not a firewall in the sense that Comodo Firewall is a firewall, but a first impression testing shows it seems to work as described.

It’s asking for a headache to run two firewall (or firewall-like) products together, but there seems to be enough functional difference that Comodo and Portslock could work together. Before I go spending what available time there is to test things, I’m going to ask the question here for any similar experiences and gotcha’s (rule mismatches are the first thing on the crash list. Keeping in sync is the headache. Got that one. What else is there to watch out for?)

Doing a fast eyeball of the CFP v3 wishlist shows that ‘per user’ rules gets mentioned a few times. Having seen an implementation, let me say it is very much worthwhile. Maybe not in v3, but how about v4??

I haven’t been able to find any other reference to Portslock here in these forums, so I don’t have anything to point you to there.

The developers can probably better answer questions about conflicts. While it would not seem, on the surface, that there would be a lot of trouble between the two, my concern would be how Portslock actually controls these things; my guess is that it embeds pretty deep in the system. There could end up being core/driver-level conflicts, rather than application-level conflicts.


PS: V3 does allow the creation of different configuration or profiles. This would seem to be the place for multiple users to store their rulesets. However, it would be user-managed (afaik) rather than admin-managed. I could be wrong on how that will all come out in the final, though.

PPS: I note that here, the developers say it does not conflict with soft or hardware firewalls. Guess there’s only one way to find out!

As a followup to my earlier posting…

I’ve downloaded the trial version of PortsLock 2.0, and run it in on a test machine that is also running Comodo Firewall Pro This is on a Windows XP Pro SP2, patches to date, laptop with 1 gig memory. LAN connection is via 100BaseT Ethernet (wired, not wireless).

I’m running also in what some would describe as a company LAN environment, with the laptop on a workgroup subnet sitting behind a FreeBSD box running as a packet filter router and Samba server. Not your normal home user kind of stuff.

As both PortsLock and CFP are firewall products, there were some test environment assumptions to keep packets from falling over each other. The really simplifying assumption is that PortsLock is functioning as a front-end wrapper to the TCP stack, and is just checking user-and-group permissions and parameters. Consequently, in this testing, PortsLock is defining only “outbound” rules that let packets get fed into the TCP stack. CFP and the stack takes it from there, all the way out to the wire, and back.

Given that kind of setup, PortsLock and CFP seem to get along just fine. And it immediately makes the case for per-user rules on a Windows machine.

One of the in-house guidelines here is that admin users don’t do email, IM, IRC, and anything else but patches and updates. Per-user rules allow that guideline to be made a real policy-in-effect rule. The Storm spam that is filling inboxes presently needs admin privileges to install the malware. If admins don’t do email, Storm malware doesn’t install as there is no admin privilege to allow the install, no matter how good the social engineering.

Along those same lines, there are some products (the Intuit Quicken products for example) that have to run with admin privileges. Creating a Windows login account to run that product, with admin privileges, and then blocking all Internet and LAN access with the per-user rules does a very effect job of containing anything trying to get in, or trying to phone home.

Scheduled Tasks, and RunAs commands, also come under those rules running under a blocked user. From logs I’ve seen, a lot of malware will set up Scheduled Tasks. Per-user rules would apply equally to those tasks.

One surprise in the testing though, is that a fully blocked user account could still do DNS queries. A little research shows why. WinXP runs a “DNS Client Service” with NetworkService privilege level. The application does a DNS lookup by asking the DNS Client service, the service does the query (assuming the NetworkService user-group has unlimited access), hands the answer back to application, and the application then goes splat up against that user’s blocking rule.

One side note on that DNS lookup, is that even a fully blocked user running some manner of malware, could “tunnel out” using DNS to an evil DNS server, and acquire additional malware by encoded DNS TXT records. I haven’t seen anything that says such tunneling is being done, but the capability obviously exists. So even full network blocking for a given Windows user login does not close off the possibility of any malware, but it does make it a whole lot harder for that malware to even get in and do anything.

I haven’t done any testing of PortsLock by itself. PortsLock does not bill itself as being a “complete” firewall, and it would take some considerable doing to even consider replacing CFP. But, anyone looking for per-user rules, PortsLock looks to be a workable, and useful, add-on.

Tnx for the info!

On the DNS situation, I’d say that’s where CFP comes in, given that it’s coming into play (for the outbound) after the stack. Each application can be blocked from doing outbound on any ports except those specified (or allowed outbound on any port except those specified; either way).

You could also create a Network Monitor rule so that DNS queries could ONLY be directed to the specified server IP/host.


Agreed about when CFP comes into play. The difficulty occurs when the same application is running between two users with different PortsLock rules. This was an expected “fall thru the cracks” item that comes from not-quite-overlapping capabilities. General utility programs, like ping or telnet (which got a workout in testing), can’t really have the restrictions applied that a more specialized application would have (e.g. Quicken). PortsLock is running per-user rules, and CFP is running machine-level and application rules. Not a perfect alignment, but workable.

About the DNS queries, those rules already exist and do their job very well. It’s the bucket-brigade nature of DNS that forms the tunnel. A WinXP client passes a query to a DNS caching server (typically the ISP, or whatever provided by the boot DHCP settings), then that caching server does all the recursive Internet query heavy lifting, eventually getting an answer, then passing that answer back to the waiting WinXP client. Once the query gets off the WinXP client, CFP rules don’t apply. The caching server should have its own, if it’s running something like BIND v9 on a BSD or *ix box. Which is the case here on-site.

Indeed, you do not have the “typical” home LAN sort of setup… :wink: