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 2.4.18.184. 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.
