Kerio Rules

Had it installed a few days, seems fine, but just wanted to see if I should tweak any of these rules. Still a few applications that I let online that I haven't ran yet, but I don't think they will be the problem, it's just all this stuff at the top I don't really understand.

Had it installed a few days, seems fine, but just wanted to see if I should tweak any of these rules. Still a few applications that I let online that I haven't ran yet, but I don't think they will be the problem, it's just all this stuff at the top I don't really understand.

Click to expand...

Hi,

I should not use a general loopback rule but only for the needed applications, like IE and OE for instance.
DNS rules only for your ISP DNS servers.

quoting: jaxson link=board=23;threadid=7446;start=0#49125 date=1045845471]. . . . Sounds lazy but do I really need to go through all that lot?
It'll take ages

I don't like ZA, too bulky, so maybe Outpost or Sygate are better for me
if you need to really setup all this stuff?

Click to expand...

The basic problem is pretty much the same with all of the rules-based firewalls. And, in saying that, I specifically include Tiny/Kerio/Sygate/Outpost/LnS/NIS/NPF. (And the rules are pretty much translatable from any of the above to any other. Indeed, the people that write recommended rulesets for one often collaborate with people writing rulesets for another.)

However, there's no need to freak out about all this. Most of them start off with a set of default rules that are at least as rigorous as what you would find with the free version of Zone Alarm. Take your time, do it at your leisure (and you'll learn a lot more about firewalls in the process).

What we're talking about here is tightening the rules up as much as possible to reflect your specific needs and requirements, based on your particular system configuration -- that's all.

There's admittedly a bit of esoterica in all this, but if you just take it one step at a time, you'll do just fine.

Although the terminology varies from product to product, the concept or intent of the rules remain the same. (ie. Remote Address Kerio refers to as Remote Endpoint)

As a starting point for your application rules, you may want to look at restricting them to the remote services/ports you will need. Right now your application rules permit outbound to any remote service/port.

Default rules with the Kerio install that you can probably remove:
Local Security Authority System
Microsoft DS
Services and Controller App
Generic Host Process

The Reply from DHCP should already be covered by the default DHCP near the top of your rule set.

The loopback rule concern can be dealt with a number of different ways. If you choose to go on a per application basis that is fine. I have attached an image of a rule set as an example only and to provide you with some ideas and it uses per application loopback rules. Note if you use a final block for outbound, make sure you enable logging as this will usually disable the rule assistant/wizard in most products and you will not be prompted for new applications wanting to access the network. They will just be blocked and logged. As has already been suggested, there is no one rule set for everyone. You will have to determine what best suits your needs.

For some of your specific applications, you may need to enable logging for short periods while using the application to determine just what local and remote services/ports and addresses are used to help determine how you customize the rules for those applications.

For the very first rule, I'd block Kerio itself from TCP & UDP. This might sound weird but it provides a little protection should the firewall itself be compromised.

Then put a rule right beneath the DNS rule blocking all traffic to and from Port 53 (remote). Since you have DNS already as restricted as it can be there is no point in allowing Port 53 traffic to continue further down the list. Ditto for DHCP.

I would also enable that last rule blocking everything.

You should consider adding some spyware IP filters if you plan on using IE and IRC, since a lot of the spyware out there likes to hijack IE, and if you use auto DCC on IRC you can get something loaded on your system quite easily.

Isn't the first rule actually too narrow to block all NetBIOS? Set up the way it is, see image, isn't it only saying to block any connections to/from local ports 137-139 from/to remote ports 137-139? Wouldn't an incoming bugbear/opaserv connection to local UDP port 137 get by this rule since these generally come from a remote port of 1024 and above?