Additional Info

The problem of viruses is temporary and will be solved in two years. (John McAfee)

There is no reason anyone would want a computer in their home. (Ken Olson, president, chairman and founder of DEC)

This post tagged:


Simple debugging with Kerio Control


This is just a simple debugging tip for Kerio Control admins. It takes advantage of Control's ability to do accounting on packets that match a specific rule and the perhaps not immediately obvious fact that a "useless" rule with accounting turned on isn't actually useless.

For example, let's say we have a machine that we suspect may be initiating Internet traffic. We don't know what kind of traffic that might be, but we'd like to quickly find out. We could set up a packet analyzer and capture everything that had that machine as its source, but that's a fair amount of effort. It also involves knowing a bit about tools like tcpdump or Wireshark. Why not use Kerio Control as our "packet sniffer"?

That's much easier. For example, here's a traffic rule that allows a specific IP address to do pretty much anything it likes. We call this rule "Peachtree" because it happens to be running that software, and we could locate it wherever we like in the rules as long as it is above Kerio's default "Local Traffic" rule. If we put it at the very top of the rules, no other rule can override it, or if we do have rules that generally block certain types of traffic, we could put it below those - it really depends on what we want to see.

A useless traffic rule

This rule basically is useless if we have no other blocking in place because the default local traffic rule would allow these packets anyway.

The generated default rules

So why bother? Because if we turn on accounting logging, we'll log only the packets we are interested in: the packets from that specific machine. If we were interested in particular ports instead, our rule might look like this:

Capturing a specific port

Basically, we can capture whatever we want. As to the actual logging, we have three choices. We can log connections, and those will show in the Connections log:

Logging to Connections

We can also just "log packets". Packets will then show up in the Filter Log:

Logging to Filter

By the way, those packets sent to are part of Name Resolution in Windows Vista and on up: see Link-local Multicast Name Resolution.

Finally, if we just want to know how much traffic this rule covers, we can click on "Internet Traffic Chart" and it will show up in Status->Traffic Charts:

Logging to Filter

Nor does the rule have to be useless. If, for example, we wanted to block a list of "bad guys", we could log or chart whenever that blocking happens.

Of course this sort of logging isn't sufficient for all network problems, but it is sometimes all that we need and it is very quick and simple to do.

I was reminded of this when I read Looking for evil in your firewall logs, which suggests a Perl script to scan logs for certain connections. As I'm sure you can see from this article, Kerio Control has better ways to do that!

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Simple debugging with Kerio Control

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us