Comodo Firewall - Web Browser rule (hardened)

I just wanted to share my custom rule I created for Web Browsers in the "Predefined Policies" tab of the Network Security Policy in the FW . It may differ for v6, but I imagine is somewhat similar enough that you can follow. This rule is more hardened than the default one so I thought it could do some good to share it here.

Rule 1 - Loopback

Allow TCP Out, Source Add.- IPv4 Single Add.- 0.0.0.0, Dest. Add.- Network Zone (Loopback), Source Port- A Port Range- 1030-65535, Dest. Port- A Port Range- 1030-65535

Rule 2 - HTTP

Allow TCP Out, Source Add.- Network Zone (LAN), Dest. Add.- Any, Source Port- A Port Range- 1030-65535, Dest. Port- A Set of Ports- HTTP Ports

Rule 3 - DNS 1

Allow UDP Out, Source Add.- Network Zone (LAN), Dest. Add.- IPv4 Single Add.- *8.26.56.26, Source Port- A Port Range- 49152-65535, Dest. Port- A Single Port- 53

Rule 4 - DNS 2

Allow UDP Out, Source Add.- Network Zone (LAN), Dest. Add.- IPv4 Single Add.- *8.20.247.20, Source Port- A Port Range- 49152-65535, Dest. Port- A Single Port- 53

Rule 5 - Block Rule

Block IP, In/Out, Source Add.- Any, Dest. Add.- Any, IP Details- Any

* = Comodo Secure DNS... use your own.

 

Hey thanks for posting
I guess this solves DNS leaks

 

Just one of several measures to put in place to help achieve that end. Merely using an alternate DNS service than the ones your ISP provide you is a great 1'st step.

If you use a VPN then use that as the Source Add. instead of your LAN Network Zone for the rules. Hopefully you've created a VPN Network Zone too... recommended for easy implementation/transition of rules. Then if/when your VPN connection drops it will block your browser altogether, which IMO should be a desired effect for anyone using a VPN.

Substitute a VPN Zone for LAN in svchost rules too, with a block rule at the bottom there as well to block DNS leaks & sever your connection if the VPN drops.

Flush the DNS cache with either the DNS Leak Fix tool, or something like CCleaner, or manually from the command line after connecting your VPN also.

Add the DNS addresses to your router too, in addition to on your box.

All of that outta protect you from DNS leaks pretty well for both LAN & VPN connections.

btw these rules were created with IE & Firefox in mind. And my setup. I don't need the other rules that were in there default for Web Browser, and don't think most people should. I also don't use Java. And not exactly sure if Chrome may handle some things differently that make this rule set unfeasible with it.


* Edit * - It just occurred to me that the existence of plugin-container for Firefox could create a difference in the way it operates compared to say Chrome. p-c is it's own process to handle addons, with it's own set of rules (personally I just block internet access with it). Whereas with Chrome perhaps any addons run as part of the Chrome rules?... that could account for the discrepancy above, among others. So maybe this won't fly on Chrome. But then again maybe blocking any activity from anything pluged into that browser is a good thing too? If it's not necessary, it's not welcome on my box, pretty much.

 

So it's possible Chrome could still leak using this rule ?
I have ran both Cyberfox and Chrome with no "apparent" leaks

I all ready have a VPN only rule which will drop any non VPN adapter traffic on a per application basis but like the idea of having browser specific rules

 

No, I'm pretty confident that Chrome would not leak with this rule set. My concern is quite to the contrary... that the rule may be too restrictive for Chrome and block legitimate things.

Reason being any addons/plugins, or whatnot through Chrome may run as part of the browser itself, and therefore be subject to the browsers rules. Whereas with Firefox they run as a separate process (plugin-container), with it's own set of rules. So with Chrome, with these rules, you may see some traffic being blocked that you wouldn't see in Firefox, because in FF they're running under plugin-container instead... and so the activity would show up in logs under it (p-c) instead.

But personally I block internet access for plugin-container. And I have logging disabled globally, for both my FW & D+. I know by now what I want to allow & block, and just want it to happen silently. Logging uses up resources.

 

I am running Comodo Dragon as we speak with this rule and everything is working fine - extensions updated etc.
using WireShark everything is as expected - encrypted UDP
However I suspect I may stick with a VPN only rule - http://www.bolehvpn.net/forum/index.php?topic=5798.0 as I do not have a supporting rule set, I have one rule for all VPN-only app's.
The same security is achieved right ?

EDIT: I do think that people may benefit and use this rule over on Comodo's forum, they have been several similar threads recently.
Inc https://forums.comodo.com/firewall-help-cis/configuring-to-block-all-nonvpn-traffic-t91413.0.html

 

I don't understand why you are using an IP address of 0.0.0.0 in this rule. That address is not a valid TCP/IP address and only is used in a pre-TCP/IP initialized state.

Loopback rules many times are not necessary and if required are usually coded for outbound loopback using your example as:

Allow TCP Out, Source Add.- Network Zone (LAN), Dest. Add.- Network Zone (Loopback), Source Port- A Port Range- 1030-65535, Dest. Port- A Port Range- 1030-65535.

To harden further, you could define a network that excludes your router IP address and use than name in the Source Add.- Network Zone (xxx) rule.

Note that any firewall rule that allows access to the loopback zone does expose you to DNS rebind attacks if your router gets hacked. Hence the need to exclude the router IP address from the source IP list.

 

I'd guess that that's exactly why FF uses it. If you set no rules at all, FF will use 0.0.0.0 as the source add. for Loopback. So I'm merely reflecting what is already the case with that rule. I use that address in my Internet Options for IE as well as a sort of fake proxy to prevent other things that use IE connection settings from connecting out... more than just IE uses it. SBIE & Comodo for instance use those connection settings as well. So I have it in place as a safeguard. I'd imagine FF uses it similarly... possibly for such a scenario you mentioned. Since it doesn't exist, something trying to connect in to your loopback would be trying to connect to a nonexistent souce. Only you could access your own loopback this way.

Also I don't understand why I'd have to exclude my router... considering that block rule I have in place at the bottom. That effectively makes everything above it a whitelist. So as long as you don't have an allow rule up there for your router, you shouldn't need to exclude it.

And Firefox does indeed "seem" to work fine without a loopback rule. I have one in there because I remember a long time ago reading about the merits of using loopback vs. not using it, and for some reason decided to use it. I no longer remember WHY I chose to, or any of the specifics. I remember everything regarding it was very vague, either way. I think I pretty much just did because I noticed Firefox used it in it's default state, and just figured maybe it had it's reasons. But then again I live by the mantra "if it's not necessary, it's not wanted", on my box. But then sometimes a thing may not appear needed, but it's hurting you in a way you're oblivious to. So I don't apply that logic universally.

Perhaps it's time for a refresher on the merits of using loopback?... perhaps another thread.

 

And if I'm misunderstanding the merits of having my router excluded, or mistaken that my block rule at the bottom would block such a thing from being a problem... please elaborate on the "exact" rule(s).

Like do you mean to check the box to exclude it while I'm creating it in the Network Zones? Or do I create it in Network Zone normally... then click the box to exclude when I'm creating the FW rule for Source Add.? And also does this apply only to the loopback rule? And/or should it have it's own rule?

An exact rule(s) would be nice... as well as an explanation as to why my block rule wouldn't just take care of it already.

Thanks for your help : ) If I ultimately decide you're right here, and/or a loopback rule isn't needed at all, I'm edit the OP.

 

This would only apply if you were using the LAN as the source network zone in the loopback rule.

Interesting how FF handles loopback. I'm an IE person myself. FF must create some type of internal proxy for loopback.

 

Yeah, and if your LAN range included your routers IP address. Mine doesn't personally. Say your routers IP address is 192.168.1.1... my LAN range would be 192.168.1.2 - 192.168.1.254 / 255.255.255.0 (in my router), to avoid a scenario such as you mentioned. And in the LAN rule in my Network Zone I'd list just 192.168.1.2. I keep my router separated from everything on this side of it. And I think that's good policy. In fact... every router I've seen, I think, forces you to handle it this way (and for good reason).

But if somebody managed to "hack" my router like you said... I doubt any measure I took could stop them from owning me. Cuz if you can circumvent WPA2 encryption with a 63 digit ASCII key... I admittedly got nothin for ya, lol. I'd ask them for their autograph.

I did open a new thread about Loopback though. You could be absolutely right that it's just not necessary at all. I'm looking for some feedback from the masses here. And if I believe it to be the case I'll amend my rule above.

 

@lucid & itman,

for my firewall local address handling I have the following:

- Trusted address: 127.0.0.1 (loopback ip)

- Local addresses: 127.0.0.1 (loopback ip) & 192.168.1.xx (local adapter address).

My fw rules basically allow incoming packets from one to the other as:

- incoming from trusted: source address = 127.0.0.1 ; local address = 127.0.0.1 & 192.168.1.xx

- outgoing to trusted: source address = 127.0.0.1 & 192.168.1.xx ; trusted address = 127.0.0.1

I guess this handles loopback comms while excluding the router's LAN-side ip address (192.168.1.254)?

 

I always remove the Loopback rule, never had issues.

 

My Loopback Zone is 127.0.0.1 / 255.0.0.0 , and I think that's pretty much universal. I can't really tell by looking at those rules whether you're protected or not. It confuses me, lol. Seems to me like it includes, not excludes it. Or kind of binds them together when they should be separate zones (IMO). Different FW's word things differently though.

I do agree with BlackKnight, it never seems necessary. I wish I could remember what I read about Loopback when I researched it long ago. I think it was kinda like a ping, just to test for proper connectivity before the "real" connection. As long as you keep it on the LAN side, no harm done. But no real benefit either I guess.

 

http://en.wikipedia.org/wiki/Loopback I never needed this.

 

One of the uses of loopback connection is inter-process communication. Sometimes it is used to communicate between parts/threads of the same process. As there is no harm done in letting a single process use loopback to communicate with itself, you can safely allow the rule you were talking about.

 

The way I see it, the addition of the rule poses no threat, but more than likely you don't need it either. Because of the former, I'm just going to include it. I believe Firefox could have it's reasons for wanting to communicate with itself, although I don't know exactly what that is.

 

Actually the more I look into it the more I'm convinced I had it right the first time, and knew I had my reasons for allowing it. In another thread I saw someone mention it provides a link between FF and things like proxies, web filters on AV's and things of the sort.

So I do a search to see if I can find things that corroborate that, and sure enough see it mentioned that FF loopback helps it communicate with PSM (Personal Security Manager), to implement SSL.

So it sounds like Loopback helps to facilitate FF in properly handling SSL/HTTPS. Personally I think a loopback rule should be used. And I know from looking at logs, with FF at least, it uses 0.0.0.0 as the source add. when it connects to the loopback zone. I only created that rule to reflect what I saw it doing.

This is a perfect example of how just because things "seem" like they're fine doesn't mean there can't be an issue you're oblivious to, like I mentioned above.


* So the Loopback rule stays... and I recommend people use it. *

 

I'm not saying that the Loopback rule is absolutely vital for proper implementation of SSL/proxies, web scanning and whatever... and that you've been naked all this time if you haven't been using it. That is almost certainly not the case. Just that there "could", conceivably, at some point be a situation where not having it in place could break something while leaving you oblivious to the fact. So since the rule (as it's written) poses no possible threat, I think it's prudent to have it in place.

Was going to add that as an edit to the above post but wanted to bump this so that people that may have thought the case was closed when I removed it see this updated status.

And Chiron, if you happen to view this... you may want to add it to your (excellent) guide, if you haven't already.

 

Yes, I think you and BlackKnight are right, the universal loopback rule may not be necessary in most cases. I've disabled mine recently and no problems yet. However, I do need the Application rule for the browsers, Firefox and IE, to send and receive UDP and TCP/IP to/from 127.0.0.1. Jetico places the default universal loopback rule under the IP category, the rules of which are processed before the Application rules.

 

There is no universal rule for it in Comodo. It's just listed in the Network Zones by default... there to be applied and integrated into rules easily as you see fit. Also I don't think a universal/global rule for it is a good idea since different apps utilize it in different ways, as I mentioned in the other thread about loopback.

And the only place it's integrated into a rule by default is for Web Browsers, I believe... the one I just tweaked here.

After learning what I learned about it, personally, if an app is trying to utilize loopback I'm allowing it whether it's absolutely necessary or not. It causes no harm and could potentially provide benefit that I'm oblivious to.

The only global rule I'd recommend in Comodo is to Block IP In... Any, Any, Any. I also block ICMP In/Out, but don't recommend it to others, as I know some people feel some types of ICMP are useful for proper networking. I'm not one of those people, but still... out of respect for their opinions it's not something I go around recommending to other people.

 

With Jetico, the universal one, which I could be stating incorrectly, won't allow applications to utilize it. It seems it's only for IP traffic, since it's only for incoming and outgoing packets, as the rule shows.

As it states in the help contents regarding IP traffic:

...so I guess this is why it only deals with browsers and such one module below in the "Application" module.

 

Hello, luciddream. Thanks for your great sharing, inspired me a lot. May i ask you a question, if i want to restrict a browser can only open one website but which is no static IP. Is it possible to do that ? Because i want one of my browser to visit only the online banking website.

Thank you.

Regards
Southcat

 

If it's a dynamic IP I can't think of how you could accomplish that with a firewall... sorry. Unless it always uses a specific range of IP's, like say for instance always between xx.xxx.xx.1 and xx.xxx.xx.255.

Then you could create an allow rule from your LAN to that range, then place a block rule like I listed underneath it to block all other connections. That's the closest you could conceivably get.

 

Thanks for your advise. I will continue looking for solution perhaps different approach to achieve.

Regards
Southcat