dslreports logo


2.5.1. Kerio and pre-v3.0 Tiny PFW

•Current Tiny build: (deprecated?)

•Current Kerio 2.x build: 2.1.5 (final)

•Current Kerio 4.x build: 4.3.268

•New releases anticipated: The status of Tiny PFW is unknown; it appears that CA intends either to rebrand or incorporate Tiny into its own security line. Status unknown; see "current build" link for information.

•Kerio now services the WinRoute line formerly handled by Tiny. WinRoute users are advised to go to http://www.kerio.com/ for information and support.

• The FAQs are under constant construction. Please visit regularly to look for product news, new additions, advanced topics, helpful resources and general tips and tricks.

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:13:13


The purpose of this FAQ is to provide a realistic launch pad for new users of Tiny and Kerio Personal Firewalls, as well as to serve as a reference for experienced users. This isn't documentation. It's basic firewalling with these firewalls. It covers getting started and having a sound basic set of firewall rules that can be developed as unique needs and new considerations evolve.

The default behavior is to deny anything not explicitly allowed or denied by a rule. Therefore, we will begin by discussing making the rules that are needed to allow normal traffic to be permitted.

The firewall processes the rules from the top down, and, when it encounters a rule that can be applied to a specific type of traffic, it applies the rule and stops processing rules. No rule below it will be considered. This cascading can be used to create conditionals by grouping rules but confuses many new users. Rules can be moved up and down in the processing sequence using the arrow buttons to the immediate right of the firewall rules table in the administrative interface.

021102-998

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:15:17

•Before you start -- You'll have an easier time if you can get the following information and write it down for reference: -DNS server address(es); -DHCP server address(es); and the subnet mask and range of any LAN you may have, along with the statically assigned address ranges of your active machines if you use static IP addresses locally.

•What the firewalls do and how -- They are simple packet and port filtering firewalls, employing stateful inspection techniques. Kerio is the successor to Tiny. Therefore, both share similar features. They accomplish their task by operating at a fairly low level (the TDI and NDIS translation layers, for those interested). As such, it filters ports and IPs and supports very basic application layer authentication by verifying that apps are what they say they are via an MD5 hash. As a fully rules-based firewall, there are no automation functions and minimal suggested or precoded rules; the ultimate measure of Tiny's effectiveness depends on sound, ordered rules.

•Windows networking -- The all important task of shielding NetBios ports from abuse is simplified with a special tab behind the firewall rules. Use it. It's a very effective built-in convenience feature. If you leave these ports open to the Internet, you are exposing your entire system, and may as well have no firewall at all from an intruder's point of view.

•Creating a basic ruleset - The emphasis is on "basic." Prompts will help you set up your Internet apps. It's a deny-by-default firewall. The first rules you need will be a deceptively simple trilogy, just a very basic set of rules to allow DNS, DHCP and ICMP. The apps will follow, in due time. If you use static IP adressing (behind a router, for example), the DHCP rule is unnecessary. You may also want to provide for open access for your LAN machines, if you have a network and consider it fully trusted, near the top.

•Rule priority and ordering - Very simple and critically important, it will be stressed throughout the FAQ. Top down, process until a match is found. When a match is found, apply the matching rule and STOP. Nothing below the match will be looked at at all. Using creativity, this opens up the potential for some very nice if-then conditionals. On the other side, there is no analog to "pass," where a rule is applied and processing continues. This would be a great feature for a future release. For now, though, your only options are allow and deny.

•Logs and alerts - Each rule must be individually set up for logging and alerts. In suggested rules in this FAQ, you will note that a suggestion is offered, log, nolog, alert, noalert, for convenience. Naturally, you can log and alert on anything you like, but following the suggestions should ensure that your logs will be useful without being unnecessarily large and unreadable. In addition, you can choose to log packets to unopened ports and, in most recent versions, to log suspicious activity. These can be useful, but may fill a log rapidly with false positives, noise traffic and so forth. Use your discretion.

•Advanced rulemaking - We'll cover advanced rules in the FAQ as needed. Suggestions and requests are always welcome.

022502-950

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-07-25 16:14:46

Yes. Because you can. A scripted attack aimed at stopping the firewall might be thwarted this way. With password authentication set, you will be prompted for your password before you can stop the firewall. A scripted exploit couldn't anticipate even a trivial password, so even with a stand alone one user install, a password protecting firewall is highly advantageous.

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:13:42

One of the first tabs under "advanced" that you should explore is the one titled "Microsoft Networking." This tab contains settings that can make protecting your NetBios ports (137-139) a lot easier. If you have no LAN, check only the top level checkbox, leaving the others unchecked. This will block all traffic over your netbios ports entirely, in both directions.

Typical LAN configuration -- click here to view full size.


If you do use a LAN, you will need to make decisions, and the selections are pretty self-explanatory. You can opt to isolate the machine from the network by setting up exactly as you would for no LAN, or you can allow traffic at various levels.

The trusted range on this page is only used by the settings on the same page. It is not the same as a "custom address group," which is set up on its own tab. Best form is to substitute the actual, active IPs of your LAN machines as a range or a list. The default is to allow the entire subnet mask.

When it first runs, Tiny will generally prompt you to set up the default configuration for the LAN. There are two very important considerations when that prompt appears. First, if you have more than one NIC on the machine, make sure that you select the correct interface, the one that connects to your LAN's switch or hub. Second, decide what you want to do with NetBios traffic. Err towards being overly restrictive if in doubt. You can always adjust that part later in the Microsoft Networking tab settings behind the rule set.

021102-900

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:19:23

Tiny does not require many deny rules when properly configured. In fact, most denies you use will be for logging and alerting, not for blocking. We'll discuss that later on. Tiny's default behavior is to prompt you for action when it sees traffic and no rule is in place that covers it. After it's fully configured, you can turn off the alerts and just have Tiny drop the traffic quietly. You only need to deny traffic that would be allowed by a lower positioned rule; you want to create an exception and "deny" for that. Tiny doesn't let a packet through by default. If you aren't around to respond, it just holds the traffic. Eventually, it times out, unaccepted and unreplied to, and dies.

There are two other "default settings." They're adjusted with the slider in the main screen. The first is "cut me off" and is self explanatory. It's the same as the "cut me off" setting in Zone Alarm and other firewalls. It simply shuts off your computer from the network. The other implements a different trust model than we want to encourage. To understand this, every time you make a firewall decision of any kind, you create a "trust model," even though you don't think of it by that name. "I trust this, but don't want to trust that..." When you install, your first decision is the overall trust model that controls every other decision you will make thereafter. There are essentially two models, "deny unless explicitly allowed" and "allow unless specifically denied." Out of the box, Tiny applies the first, most desirable model. The bottom slider setting implements the second, riskier model. The bottom setting is definitely not recommended

021102-890

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:36:54

Tiny parses rules in the order in which they're listed. It processes each rule, from the top down, until it reaches one that matches. When it can make a match, it stops processing immediately, applies that rule and moves on. No rules below the matching rule are even examined. Game over. Therefore, it's vitally important to understand that an exception to a general rule MUST precede the general rule, or it just won't work. If no rule matches and it reaches the end of the rule set, it will "slop over" to whatever default behavior you've selected if no match is found.

021102-799

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:15:54

Critical. The right rule in the wrong order is useless. It may never even be looked at. For example, if you "deny all traffic to or from remote port 53" in a rule, and put a rule below that to "allow all to or from remote port 53 on 192.168.1.1 only," the traffic will be denied. Tiny sees the generic deny BEFORE the specific allow, so it never processes the later rule. It finds a match. It applies the rule that matches and stops. Game over.

021102-798

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:16:53

Look to the right of the rule set in the advanced screen. You will see an up arrow and a down arrow. Highlight the rule you want to move, and use the arrow buttons to place it in the proper order. Also, note that there is a button labeled "insert" next to "add." If you highlight a rule and select "insert," it will open a new blank rule and place it above the highlighted selection. "Add," on the other hand, will always put the new rule at the bottom of your set, and you will have to position it manually.

021102-797

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:17:53

Tiny allows users to designate one custom address list, which is just what the name implies-- a list of IPs that can be referred to as a group in your rules. You can use this for any purpose you choose, but you're limited to only one list. This is unfortunate, since these lists can be very useful for grouping addresses and eliminating redundancy in rule sets.

Custom ranges

!- Do not confuse the custom address range with the trusted range under the Microsoft Networking tab. The latter is only for NetBios control functions, which are all contained on the Microsoft Networking tab; the MS networking "trusted" range is meaningless elsewhere. The "custom" range, in contrast, allows you to group non-contiguous IP addresses and use the group as a remote endpoint in any rule.

021102-557

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:39:08

DHCP is only required if you are connected directly to a modem from your NIC. If you have a router or a proxy server that you connect through, you will only need DHCP if you use it to assign a local IP address to your machine on your LAN.

If your router, for example, is a DHCP server for your network, you need to have your router's LAN IP address handy. Since most routers are installed with the default of 192.168.1.1, we'll use that address for this example. If you have a direct connection, you will substitute your ISP's DHCP server IP address for "192.168.1.1" in your own rules. The rules will be the same for a directly connected user; the IP address in the first rule will be the only variation.

ALLOW
both directions
UDP
application ANY
single local port 68
single remote port 67
single remote address 192.168.1.1*
nolog - noalert
Notes: *For a router in many default configurations, substitute the IP address of your ISP's DHCP server as appropriate.

ALLOW
OUT
UDP
application ANY
single local port 68
single remote port 67
single remote address 255.255.255.255
nolog - noalert

Rule position: high

021102-513

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:43:37

DNS is essential to connectivity. However, the rule Tiny supplies is less secure than we want it to be. As it is written, it could allow a hostile app to find a back door in your firewall. Allowing DNS connectivity is mandatory for all Internet users.

To tighten it up, you first need to know the IP address of the DNS servers your ISP assigns to you. This is usually found in your TCP-IP setup under "Network" in the control panel. If the addresses are directly next to each other, you will be able to just change the default rule from "any remote host, remote port 53" to "IP range [the two addresses you found in DNS setup]." Now, one of the limitations of Tiny is that it can't process lists of IPs, only ranges and netmasks. A range or netmask may be desirable or acceptable in some special situations. If your IPs aren't a range, you can just duplicate the rule for the backup DNS server.

For reference, the standard rule for DNS is:

ALLOW
both directions
UDP*
application ANY
local port ANY
single remote port 53
single remote address [my.isp.dns.ip]**
nolog - noalert

Notes: *To allow a "dig" application to use a nameserver requires that TCP as well as UDP be enabled. **It may be necessary to use two or more rules if your ISP uses non-contiguous nameserver addresses. In general, it's not unusual for an ISP to change DNS servers in some circumstances; this can be provided for by placing a rule like this below all of the DNS allows:

DENY
both TCP/UDP
application ANY
local port ANY
single remote port 53
any remote address
log - alert

Finally, some software apps will poll a foreign DNS server as part of their operation. If you see a recurring deny alert every time a certain app runs, you can verify this in your documentation. Verify that the IP the app is contacting is a valid nameserver -- remember, hostile apps and trojans can "spoof" common remote ports to confuse you! Having verified, allow the app name resolution with a rule like this:

ALLOW
UDP*
application [the name of specialty app you're running]
local port ANY
single remote port 53
single remote address [the correct nameserver for that app]
nolog - noalert

position: high

021102-512

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-06-29 15:24:20

ICMP type 3 is necessary for path MTU discovery to work correctly. It should be enabled inbound to get top efficiency from your tweaked broadband connection. Normally, you will also allow your machine to ping another machine, but not to accept or reply to pings from other machines. To be able to ping out but not be pinged, we allow type 8, echo request, to go outbound. We allow type 0, echo reply, inbound. Type 11 allows us to receive "time exceeded" messages to support traceroutes, etc.

The other types are normally not absolutely necessary to get a working connection. If you choose to enable other types, remember, for the most part you don't mind sending (outbound) "requests," or receiving (inbound) "replies," but you don't want to be replying outbound yourself unless absolutely necessary. An exception would be if you wanted to be pingable, in which case you would enable types 0 and 8 on both your ICMP inbound and your ICMP outbound rules.

Finally, the typical install requires precisely two (2) rules to handle ICMP properly: an allow in and an allow out. Anything that matches the types you've picked in neither allow rule will be dropped down for further processing and will be blocked and prompted or dropped if it reaches the end of the rules unmatched. The usual position for this pair would be directly below loopback and any LAN rules.

Generally, the following will permit enough ICMP for an average installation, allowing outbound ping and path MTU discovery/connection-related traffic:

ICMP allowed in
allow
IN
ICMP
types 0, 3, 11
nolog - noalert

ICMP allowed out
allow
OUT
ICMP
types 3,8
nolog - noalert

[optional rule to drop all non allowed ICMP; prevents unnecessary pop-ups asking for action on packets that can almost always be safely dropped]

Deny any ICMP
deny
BOTH DIRECTIONS
ICMP
types: "select all"
[normally]nolog-noalert, for blocking; may log if desired.

030202-511


Feedback received on this FAQ entry:
  • I only heard of ICMPv4 and ICMPv6 I have no knowledge of type 0,3 or 11

    2014-08-17 03:57:25

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-06-29 15:28:32

Essentially, none. With these three basic connectivity functions covered, a secure Microsoft Networking configuration and your logging, authentication and other configuration preferences set up, you should be able to access the Internet in safety, as well as use the prompts supplied by the firewall to create rules for your applications to access the Internet. You can now move on to study some intermediate and advanced issues, if you like, or just sit back and relax for a while. You now have a functional firewall.

Kerio users will note that the default loopback rule is missing. Normally, this won't cause you problems, but if you use apps (VNC is one, for example) that keep asking for loopback, you can safely add the rule to your set. It's not necessary, or even very desirable, to make it your topmost rule, though. Put it below your system rules. Kerio also includes a prebuilt IGMP deny rule, which Tiny users may want to replicate as part of their basic rulesets and a set of ICMP rules that is very complete, except for ICMP, which may cause some problems because the suggested rules don't allow for inbound type 3. While type 3, strictly speaking, has some fairly obscure exploits associated with it, the benefit of allowing it inbound outweigh the risks in many cases. Path MTU detection, which you probably have turned on as part of your tweaking, won't work without it, and it can slow down the connection significantly at times.

Finally, if you like a neat ruleset, it's perfectly all right to group the ICMP rules, for example, into one "in" rule and one "out" rule. If you want to log certain things but not others, you can reverse the procedure and create more individually specific rules.

510

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-31 16:56:36

If you have a LAN, it's often good form, IF you want unrestricted LAN access for local services without a lot of rules, to START the ruleset with an allow any rule for an IP range of the LAN addresses you use, and another rule allowing the subnet broadcast address. While it's up to you to decide, firewalls are much easier to configure, and much easier to do log analysis with, if you do not use DHCP, but a static block of private IP's, if you're behind a router... that rule, if desired, could be placed here.




DNS is fundamental:
A sample DNS rule.


... and can be followed with a neat deny and set this for alert:

A sample foreign DNS block rule. Set this rule to alert.


If you use DHCP to retrieve a dynamically assigned IP address from your ISP or router, you can tighten up on the generic rule provided with a pair of rules, like this:

A sample DHCP rule pair.


and protocol specific rules, for example:
A sample Protocol type 2 (IGMP) deny.


Next, among the basics you'll want to have for getting started out, you can use the following as a guide to some sample ICMP rules; this can be a good place to put a generic loopback, if you want to use one:
 A few sample ICMP rules.


/under construction! :)/

Yes. This intimidating looking list, below, is actually overkill for any beginner, and it's soon to be replaced. The series of denies, marked "ignore," are anti-spoofing rules. The rest are identified by their function. To understand these rules, you need to understand the machine they're on, and that the list is meant to contemplate almost every basic firewall situation we might encounter, without being overly complex for a beginning or an intermediate user.

The machine has two NIC's, only the 10 range is trusted. The LAN operates over the 10 range. The 172 range is a TCP only net. It carries internet traffic, as well as some local intranet traffic. It is behind a router ("NAP," network access point), and the DHCP rules are disabled in this configuration, because the router provides DHCP client services for the network.

The rules labelled "proxy access rules" are designed to "bunker" the browser and other apps required to pass through the proxy, and force them to use the local proxy server as their only means of accessing the internet (in this case, proxomitron on port 8080; these rules can be adapted to any filter or proxy server running on the local machine). They also bunker the proxy server, by denying access to any app not explicitly permitted to use the proxy to reach the internet. This is very important! If you use a proxy server, you have a natural firewall tunnel on your computer! The firewall cannot filter any request that passes to the proxy. It only sees the proxy asking for access. To prevent this, we make a rule denying access and alerting us if anything not permitted by rule tries to reach the proxy on localhost. This is an excellent example of ordering a series of rules to create a conditional with rule processing logic... examine the logic of how it works... IF the app is listed THEN allow it to access localhost 8080 ELSE IF app requesting access is IE AND access is requested to an address other than localhost THEN deny access ELSE IF any unlisted app THEN deny access to localhost port 8080 and prompt the user.

A very important thing to remember is that IE needs UDP access to 127.0.0.1 to maintain its caches. It will slow browsing to a crawl, if this is denied. You will note the first rule in the specialized proxy section allows IE full UDP access to localhost to accomodate this.

The "proxomitron" entry is the first normal internet application. As a rule, you will allow authorized applications "outbound TCP" or "outbound TCP/UDP" access only. Inbound is tantamount to allowing the application to act as a server, and should always be used with care.

The rest of the ruleset is a list of the internet apps on the machine.

It should be noted that you don't have to, and aren't even advised to, copy this ruleset verbatim... it's meant to show a subset of some of the various tricks this firewall is capable of. The most important rules for a beginner are identified as "DNS" "DHCP" and "ICMP". The rest are optional or special purpose rules.

Note too that the "block foreign DNS" is out of order. This is an error. It should e directly under the DNS entries. It lets the user know if something wants to access a foreign nameserver, which may be legitimate, so it alerts to a denied DNS request, in case the ISP changes the server, or an app uses a non-standard nameserver (and you'll usually know if you need that).

A sample Kerio PFW ruleset - click to view full size in a new window; maximize the window for best readability!.


This ruleset is by no means comprehensive or suggested. They're provided as a guide and an example. Also, as the crude annotations no doubt imply, there will be a more permanent solution as soon as possible.

by gwion See Profile
last modified: 2002-06-20 02:31:34

Kerio has a useful feature. It allows you to decide what should be logged, what should be alerted and what should be silently processed and forgotten. This makes it easier to read logs, and it allows you to use alerting in a meaningful way, instead of trivializing the popups, as some firewalls do, by alerting on everything. Set this by editing the individual rule you want to log or be alerted on. There will be two checkboxes, one for log and one for alert, and you can tick or untick either or both, depending on your preferences. By default, Kerio won't log or alert, but it still does its job quietly in the background.

021102-450

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:19:46

Here's a temporary rule to find out exactly what ports and remote IPs any app on your system is connecting with:

ALLOW (or deny, if the behavior is naughty)
both directions
BOTH
application [the suspect application]
local port ANY
remote port ANY
remote address ANY
log - alert

Note: This rule should be deleted or unchecked and replaced with an appropriate permanent rule as soon as it captures the information you need. It is a diagnostic rule only.

Position: Above all other rules.

021102-006

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-06-11 16:57:12

You can generally get your DHCP server's IP by running winipcfg in Windows 9x. However, you may want or need to have Tiny find it for you. Here's a trick that can be adapted to find anything if you know which port to expect it on. Make a rule to "allow any UDP in or out" on local port 68, from any remote host, remote port 67. Now, have it log and alert. When your DHCP "lease" comes up for renewal, it will alert you and log the remote address. This is the address you will need for your first DHCP rule; you can now go to the rule you made and change "remote host" to the IP you obtained in the log of the rule match. If you're in a hurry, it's usually possible to "force" a DHCP connection by logging off on a PPPoE connection and logging back on a short while later, or you can try power cycling your modem and resynchronizing your connection.

021102-005

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:21:51

In the registry, navigate to HKLM\SYSTEM\CurrentControlSet\Services\fwdrv, and change the value MaxBufferSize to 16000

If the message persists, an even larger setting may be necessary.

Our thanks to S. Kolar for this information.

As always, exercise extreme care whenever editing the registry.

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-05-08 12:22:23


1/ The Tiny Software Corporate Website

2/ The Kerio Corporate Website

3/ Yahoo Kerio Users' Group

4/ Follow Java App - a handy log viewer that works well with Tiny's log file and many others. Requires the Sun Java Runtime Environment to function.

5/ Kiwi Syslog Daemon - an excellent syslog daemon for centralized log collection of all Tiny clients on your LAN; also supports SNMP for logging LinkSys and other routers.

6/ Tiny Log Viewer - a third-party utility for viewing and processing log information from Tiny and Kerio firewalls.

032102-001

by gwion See Profile edited by JMGullett See Profile
last modified: 2007-06-11 16:59:23