Kerio PFW 2.14 - Safe?

Hi,

Of the personal firewalls I've looked at, Kerio 2.14 seems the best for
the following reasons:

1) No bloated 'glitzy' interface
2) I like the traffic monitor which lets me see where my bandwidth is
going
3) Seems to have everything ZA has as far as a firewall is concerned.
4) Seems like one of the lowest footprints.

However, my concern is that this software is now quite old. Does this
make it any more vulnerable than, say, the latest version of Zone Alarm,
or any of the other firewalls?

FWIW, I'm running XP SP2, don't especially like the new ICF, behind a
NAT ADSL router with the hardware firewall enabled. Oh, and yes, I'm
running AV software!

Thanks,

Pete

Re: Kerio PFW 2.14 - Safe?

"Peter Boulton" wrote in message
news:chmtou$ege$1$8300dec7@news.demon.co.uk...
> Hi,
>
> Of the personal firewalls I've looked at, Kerio 2.14 seems the best for
> the following reasons:
>
> 1) No bloated 'glitzy' interface
> 2) I like the traffic monitor which lets me see where my bandwidth is
> going
> 3) Seems to have everything ZA has as far as a firewall is concerned.
> 4) Seems like one of the lowest footprints.
>
> However, my concern is that this software is now quite old. Does this
> make it any more vulnerable than, say, the latest version of Zone Alarm,
> or any of the other firewalls?
>
> FWIW, I'm running XP SP2, don't especially like the new ICF, behind a
> NAT ADSL router with the hardware firewall enabled. Oh, and yes, I'm
> running AV software!
>
> Thanks,
>
> Pete

Why not try Kerio v4?

Clive

Re: Kerio PFW 2.14 - Safe?

Clive wrote on 08/09/2004 16:43:
> "Peter Boulton" wrote in message
> news:chmtou$ege$1$8300dec7@news.demon.co.uk...
>
>>Hi,
>>
>>Of the personal firewalls I've looked at, Kerio 2.14 seems the best for
>>the following reasons:
>>
>>1) No bloated 'glitzy' interface
>>2) I like the traffic monitor which lets me see where my bandwidth is
>> going
>>3) Seems to have everything ZA has as far as a firewall is concerned.
>>4) Seems like one of the lowest footprints.
>>
>>However, my concern is that this software is now quite old. Does this
>>make it any more vulnerable than, say, the latest version of Zone Alarm,
>>or any of the other firewalls?
>>
>>FWIW, I'm running XP SP2, don't especially like the new ICF, behind a
>>NAT ADSL router with the hardware firewall enabled. Oh, and yes, I'm
>>running AV software!
>>
>>Thanks,
>>
>>Pete
>
>
> Why not try Kerio v4?
>
> Clive
>
>

More bloated than 2.14 (or 2.15, which I tracked down after I posted my
question). So come one - is 2.15 compromised because it's old software?

Re: Kerio PFW 2.14 - Safe?

In article , news@Data*n0-
spam*Perceptions.co.uk says...
> Clive wrote on 08/09/2004 16:43:
> > "Peter Boulton" wrote in message
> > news:chmtou$ege$1$8300dec7@news.demon.co.uk...
> >
> >>Hi,
> >>
> >>Of the personal firewalls I've looked at, Kerio 2.14 seems the best for
> >>the following reasons:
> >>
> >>1) No bloated 'glitzy' interface
> >>2) I like the traffic monitor which lets me see where my bandwidth is
> >> going
> >>3) Seems to have everything ZA has as far as a firewall is concerned.
> >>4) Seems like one of the lowest footprints.
> >>
> >>However, my concern is that this software is now quite old. Does this
> >>make it any more vulnerable than, say, the latest version of Zone Alarm,
> >>or any of the other firewalls?
> >>
> >>FWIW, I'm running XP SP2, don't especially like the new ICF, behind a
> >>NAT ADSL router with the hardware firewall enabled. Oh, and yes, I'm
> >>running AV software!
> >>
> >>Thanks,
> >>
> >>Pete
> >
> >
> > Why not try Kerio v4?
> >
> > Clive
> >
> >
>
> More bloated than 2.14 (or 2.15, which I tracked down after I posted my
> question). So come one - is 2.15 compromised because it's old software?

I like Kerio 2.x but I like ZoneAlarm better because it has stateful
inspection and Kerio 2 does not. ZoneAlarm seems to be a good solid
firewall, although some have had problems with the 5.x series, so
beware.

Also, I have had some problems with Kerio 2.1.5 which I can't explain
and so don't fully trust it. Others have not had these problems
however, so it might be fine for you. I've been told that I may have
network driver conflicts with Kerio, but in my opinion Kerio has some
holes and flaws. Who knows for sure though..

If you're going to use Kerio 2.x then you'd be best to go with 2.1.5.
There was a flaw in 2.1.4 which was corrected in 2.1.5.

I've also tried the new Kerio 4.1 beta's and they're still amazingly
buggy after months and months of work. Stick with 2.1.5.

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

In article , kerodonospamkenny@hotmail.com says...
> In article , news@Data*n0-
> spam*Perceptions.co.uk says...
> > Clive wrote on 08/09/2004 16:43:
> > > "Peter Boulton" wrote in message
> > > news:chmtou$ege$1$8300dec7@news.demon.co.uk...
> > >
> > >>Hi,
> > >>
> > >>Of the personal firewalls I've looked at, Kerio 2.14 seems the best for
> > >>the following reasons:
> > >>
> > >>1) No bloated 'glitzy' interface
> > >>2) I like the traffic monitor which lets me see where my bandwidth is
> > >> going
> > >>3) Seems to have everything ZA has as far as a firewall is concerned.
> > >>4) Seems like one of the lowest footprints.
> > >>
> > >>However, my concern is that this software is now quite old. Does this
> > >>make it any more vulnerable than, say, the latest version of Zone Alarm,
> > >>or any of the other firewalls?
> > >>
> > >>FWIW, I'm running XP SP2, don't especially like the new ICF, behind a
> > >>NAT ADSL router with the hardware firewall enabled. Oh, and yes, I'm
> > >>running AV software!
> > >>
> > >>Thanks,
> > >>
> > >>Pete
> > >
> > >
> > > Why not try Kerio v4?
> > >
> > > Clive
> > >
> > >
> >
> > More bloated than 2.14 (or 2.15, which I tracked down after I posted my
> > question). So come one - is 2.15 compromised because it's old software?
>
> I like Kerio 2.x but I like ZoneAlarm better because it has stateful
> inspection and Kerio 2 does not. ZoneAlarm seems to be a good solid
> firewall, although some have had problems with the 5.x series, so
> beware.
>
> Also, I have had some problems with Kerio 2.1.5 which I can't explain
> and so don't fully trust it. Others have not had these problems
> however, so it might be fine for you. I've been told that I may have
> network driver conflicts with Kerio, but in my opinion Kerio has some
> holes and flaws. Who knows for sure though..
>
> If you're going to use Kerio 2.x then you'd be best to go with 2.1.5.
> There was a flaw in 2.1.4 which was corrected in 2.1.5.
>
> I've also tried the new Kerio 4.1 beta's and they're still amazingly
> buggy after months and months of work. Stick with 2.1.5.
>
>
>
Looks like Kerio v2.1 does have stateful packet inspection.
Quoted from the Kerio 2.1 User's Guide:
"The main principal behing a firewall such as KPF is stateful
inspection. This ensures that Personal Firewall only allows
communication initiated from within the local network"
Casey

Re: Kerio PFW 2.14 - Safe?

>More bloated than 2.14 (or 2.15, which I tracked down after I posted my
>question). So come one - is 2.15 compromised because it's old software?

No, I don't think so. In fact, the older it is the more time there has been for
vulnerabilities to surface. Newer firewalls just have more stuff, not
necessarily better security. A bigger worry with a firewall that is no longer
supported is that it may not be compatible with some later operating system
update.
--
Dave "Crash" Dummy - A weapon of mass destruction
crash@gpick.com?subject=Techtalk (Do not alter!)
http://lists.gpick.com

Re: Kerio PFW 2.14 - Safe?

Peter Boulton wrote:
>> Why not try Kerio v4?
>>
>> Clive
>>
>>
>
> More bloated than 2.14 (or 2.15, which I tracked down after I posted my
> question). So come one - is 2.15 compromised because it's old software?

I use 2.15 and I'm very happy with it. I'm not aware of any vulnerability or
problems with it - it's lean, mean and clean.

I saw another poster claiming that it is not statefull - untrue: Kerio fully
supports that, and even gives you very nice and fine-grained control.

The only question is how much longer will it work. Given that they stopped
development on that branch it may not be compatible with future OS systems,
such as Longhorn (if and when it comes).

Finally I fully agree with the estimate on the 4.x branch. I find it bloated
and quite unstable.
--
Mailman


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Re: Kerio PFW 2.14 - Safe?

In article ,
Casey@nosuch.net says...
> Looks like Kerio v2.1 does have stateful packet inspection.
> Quoted from the Kerio 2.1 User's Guide:
> "The main principal behing a firewall such as KPF is stateful
> inspection. This ensures that Personal Firewall only allows
> communication initiated from within the local network"
> Casey

I could have sworn that it doesn't, but there you go...
--
Kerodo

Re: Kerio PFW 2.14 - Safe?

In article ,
Casey@nosuch.net says...
> Looks like Kerio v2.1 does have stateful packet inspection.
> Quoted from the Kerio 2.1 User's Guide:
> "The main principal behing a firewall such as KPF is stateful
> inspection. This ensures that Personal Firewall only allows
> communication initiated from within the local network"
> Casey

Casey... on second thought, I'm fairly sure that despite what the user's
guide says, it does not have SPI. I've seen several references to this
in various forums and other groups..

And I've seen things to dispute this here as well. If Kerio had SPI
then I would not see outbound ICMP type 3 packets to my DNS servers at
times. Kerio would only accept responses to DNS initiated by my system.
This is however not the case.

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

"Mailman" wrote in message
news:413f6f23_5@corp.newsgroups.com...
> Peter Boulton wrote:
>>> Why not try Kerio v4?
>>>
>>> Clive
>>>
>>>
>>
>> More bloated than 2.14 (or 2.15, which I tracked down after I posted my
>> question). So come one - is 2.15 compromised because it's old software?
>
> I use 2.15 and I'm very happy with it. I'm not aware of any vulnerability
> or
> problems with it - it's lean, mean and clean.
>
> I saw another poster claiming that it is not statefull - untrue: Kerio
> fully
> supports that, and even gives you very nice and fine-grained control.
>
> The only question is how much longer will it work. Given that they stopped
> development on that branch it may not be compatible with future OS
> systems,
> such as Longhorn (if and when it comes).
>
> Finally I fully agree with the estimate on the 4.x branch. I find it
> bloated
> and quite unstable.
> --
> Mailman
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Running Kerio 4 on a W2K machine, never had any problems with it?

Does 2.15 work on W2K and XP SP2?

Clive

Re: Kerio PFW 2.14 - Safe?

Kerodo wrote...

> And I've seen things to dispute this here as well. If Kerio had SPI
> then I would not see outbound ICMP type 3 packets to my DNS servers at
> times. Kerio would only accept responses to DNS initiated by my system.
> This is however not the case.

I don't know the specific answer to the does/doesn't question, but
stateful packet inspection doesn't necessarily mean there will be no
replies to requests that are externally initiated. Stateful inspection
means a firewall will keep track of the "state" of a connection by
observing things like origins, destinations, and packet sequences so it
can better determine what sort of traffic it's dealing with, but it in
no way guarantees any specific traffic will be accepted or rejected.
That is entirely up to the firewall rule set.

The traffic you describe is "normal" activity, and probably would be be
passed by any firewall that didn't explicitly deny it. Stateful
inspection may aid the firewall in controlling who it replies to or
under what conditions, or even detect some sort of odd "fragmented
packet" activity from an alleged name server or nefarious local source,
but the yes/no question is generally answered elsewhere.

--

At the present time, the alternative is not between change or no
change, but between change for the better and change for the worse.

-- C. H. Douglas

Re: Kerio PFW 2.14 - Safe?

Peter Boulton wrote:
> Clive wrote on 08/09/2004 16:43:
>

>
> More bloated than 2.14 (or 2.15, which I tracked down after I posted my
> question). So come one - is 2.15 compromised because it's old software?

Why would you expect it to be? It's a rules based firewall that
essentially filters packets based on the rules *you* create. So, if you
know how to properly secure your system, based on your adherence to safe
computing, it ought to provide the degree of safety which you instruct
it to.

Re: Kerio PFW 2.14 - Safe?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9B3277EAB2C02E50DA2AD583
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Clive wrote:
[snip]
>
> Running Kerio 4 on a W2K machine, never had any problems with it?
>
> Does 2.15 work on W2K and XP SP2?
>
> Clive
>
>

I can not say about XP SP2, since I don't have it and will never have, but
Kerio 2.1.5 works fine on W2k and at least XP SP1(a?).

Felix

--------------enig9B3277EAB2C02E50DA2AD583
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBQFJyDH+mFzdSOa0RAnYkAJ0SU8f2j8KhiJ3g73av1f/vIYjatwCc CSUB
lCEHRFmuTB9cyaoXp2XBosM=
=5Jog
-----END PGP SIGNATURE-----

--------------enig9B3277EAB2C02E50DA2AD583--

Re: Kerio PFW 2.14 - Safe?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig807715EF9C50545E28E337CB
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kerodo wrote:
> In article ,
> Casey@nosuch.net says...
>
>>Looks like Kerio v2.1 does have stateful packet inspection.
>>Quoted from the Kerio 2.1 User's Guide:
>>"The main principal behing a firewall such as KPF is stateful
>>inspection. This ensures that Personal Firewall only allows
>>communication initiated from within the local network"
>>Casey
>
>
> Casey... on second thought, I'm fairly sure that despite what the user's
> guide says, it does not have SPI. I've seen several references to this
> in various forums and other groups..
>
> And I've seen things to dispute this here as well. If Kerio had SPI
> then I would not see outbound ICMP type 3 packets to my DNS servers at
> times. Kerio would only accept responses to DNS initiated by my system.
> This is however not the case.
>

ICMP type 3 means "destination-unreachable". This is exactly the answer I
would expect if the system in question blocks all incoming traffic except
for traffic on initiated connections.

If Kerio hadn't SPI it couldn't determine whether incoming packets are
related to one of your initiated connections or not. So you couldn't see
anything on the internet, since Kerio would block *all* incoming packets.
It may be true that it's not possible to use Kerio's SPI for finer filter
rules, but Kerio *must* have it.

Greetings,
Felix

--------------enig807715EF9C50545E28E337CB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBQFVmDH+mFzdSOa0RAi6fAJ9pvTPR5LrZtYLLWym6ftRdW6uDcACe MO7j
aKo2CUzwxWy0fLgTZ2pn/5g=
=bNLn
-----END PGP SIGNATURE-----

--------------enig807715EF9C50545E28E337CB--

Re: Kerio PFW 2.14 - Safe?

Felix Tiede wrote on 09/09/2004 13:54:
> Clive wrote:
> [snip]
>
>>
>> Running Kerio 4 on a W2K machine, never had any problems with it?
>>
>> Does 2.15 work on W2K and XP SP2?
>>
>> Clive
>>
>
> I can not say about XP SP2, since I don't have it and will never have,
> but Kerio 2.1.5 works fine on W2k and at least XP SP1(a?).
>
> Felix

OP here! Yes, 2.15 seems to work fine with Win XP SP2. 2.14 was picked
up by the SP2 Security Centre and so I didn't get a 'nag' that I had no
firewall. When I uninstalled 2.14 and installed 2.15 (and rebooted)
curiously Service Centre DID nag me, even though 2.15 had been
successfully installed and was running. Still, this is but a small
difficulty (the nag can be permanently turned off) - other than that it
runs just fine.

Pete

Re: Kerio PFW 2.14 - Safe?

optikl wrote on 09/09/2004 13:32:

> Peter Boulton wrote:
>
>> Clive wrote on 08/09/2004 16:43:
>>
>
>>
>> More bloated than 2.14 (or 2.15, which I tracked down after I posted
>> my question). So come one - is 2.15 compromised because it's old
>> software?
>
>
> Why would you expect it to be? It's a rules based firewall that
> essentially filters packets based on the rules *you* create. So, if you
> know how to properly secure your system, based on your adherence to safe
> computing, it ought to provide the degree of safety which you instruct
> it to.

I understand what you're saying, but what if you have a trojan running?
I have no idea whether any trojans do this, but it is surely
technically possible for a trojan to turn off the firewall / change the
rule set? My original question was posted with this sort of thinking in
mind - i.e. would more modern software offer better defenses to trojans
trying to switch them off / change rulesets etc.?

If that danger is theoretical rather than real then I'm happy with Kerio
2.15 for the reasons in my earlier posts. If the danger is real and not
theoretical AND more recent offerings better protect from trojans then
maybe I need to think again.

Pete

Re: Kerio PFW 2.14 - Safe?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB90C27E3E1AA6855385AD5AF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Boulton wrote:
> optikl wrote on 09/09/2004 13:32:
>
>> Peter Boulton wrote:
>>
>>> Clive wrote on 08/09/2004 16:43:
>>>
>>
>>>
>>> More bloated than 2.14 (or 2.15, which I tracked down after I posted
>>> my question). So come one - is 2.15 compromised because it's old
>>> software?
>>
>>
>>
>> Why would you expect it to be? It's a rules based firewall that
>> essentially filters packets based on the rules *you* create. So, if
>> you know how to properly secure your system, based on your adherence
>> to safe computing, it ought to provide the degree of safety which you
>> instruct it to.
>
>
> I understand what you're saying, but what if you have a trojan running?
> I have no idea whether any trojans do this, but it is surely
> technically possible for a trojan to turn off the firewall / change the
> rule set? My original question was posted with this sort of thinking in
> mind - i.e. would more modern software offer better defenses to trojans
> trying to switch them off / change rulesets etc.?
>
> If that danger is theoretical rather than real then I'm happy with Kerio
> 2.15 for the reasons in my earlier posts. If the danger is real and not
> theoretical AND more recent offerings better protect from trojans then
> maybe I need to think again.
>
> Pete

There's only one method to keep trojans from shutting down a firewall: Never
run it as Administrator. But if the trojan can get administrator privileges
even from an user account, even most up-to-date firewalls can not help you.
And yes, trojans do this.

The problem with Kerio is its interaction with the user account: As long as
a user can change the ruleset, a trojan can also. I don't know where in
Kerio the password authentication for rulechanging is needed. If it's needed
only in the client and the server process doesn't ask for it, you should
better use another software or, even better, a hardware firewall.
If this password is asked by the server process, neither an user nor a
trojan can alter rules without having the password.
Since Kerio is a two component system with the server-service filtering
packets and a client acting as an interface for serverconfiguration I
think/hope the developers were wise enough to implement the password
authentication in the server process, not in the client.
If that's the case, you have a password for Kerio set and you're only
working as administrator if absolutely necessary, it's quite unlikely that a
trojan can shutdown Kerio or alter its rules.

Greetings,
Felix

--------------enigB90C27E3E1AA6855385AD5AF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBQGidDH+mFzdSOa0RAtptAJ9OuQ22RK4uMmFdhBDDrph1jY6qtgCY mJIN
9v2VfqYXvvdoSGn25OJt9g==
=+rSp
-----END PGP SIGNATURE-----

--------------enigB90C27E3E1AA6855385AD5AF--

Re: Kerio PFW 2.14 - Safe?

Taking a moment's reflection, Clive mused:
|
| Does 2.15 work on W2K and XP SP2?

Yes.

Re: Kerio PFW 2.14 - Safe?

Taking a moment's reflection, Peter Boulton mused:
|
| I understand what you're saying, but what if you have a trojan running?
| I have no idea whether any trojans do this, but it is surely
| technically possible for a trojan to turn off the firewall / change the
| rule set?

That is a danger as some trojans are now exhibiting that capability.
However, the trojan has to specifically interact with the firewall in order
for this to happen ... this takes specific coding by the trojan author.
Likely, they will not waste time on all firewalls ... just the popular ones
(ZoneAlarm, McAfee, and Norton). So, the older Kerio has an element of
security through obscurity. I have not heard of any trojan that can
specifically disable Kerio 2.1.x ...

Re: Kerio PFW 2.14 - Safe?

On 2004-09-09 16:28, Felix Tiede wrote:
> Peter Boulton wrote:
>
>> optikl wrote on 09/09/2004 13:32:
>>
>>> Peter Boulton wrote:
>>>
>>>> Clive wrote on 08/09/2004 16:43:
>>>>
>>>
>>>>
>>>> More bloated than 2.14 (or 2.15, which I tracked down after I posted
>>>> my question). So come one - is 2.15 compromised because it's old
>>>> software?
>>>
>>>
>>>
>>>
>>> Why would you expect it to be? It's a rules based firewall that
>>> essentially filters packets based on the rules *you* create. So, if
>>> you know how to properly secure your system, based on your adherence
>>> to safe computing, it ought to provide the degree of safety which you
>>> instruct it to.
>>
>>
>>
>> I understand what you're saying, but what if you have a trojan
>> running? I have no idea whether any trojans do this, but it is surely
>> technically possible for a trojan to turn off the firewall / change
>> the rule set? My original question was posted with this sort of
>> thinking in mind - i.e. would more modern software offer better
>> defenses to trojans trying to switch them off / change rulesets etc.?
>>
>> If that danger is theoretical rather than real then I'm happy with
>> Kerio 2.15 for the reasons in my earlier posts. If the danger is real
>> and not theoretical AND more recent offerings better protect from
>> trojans then maybe I need to think again.
>>
>> Pete
>
>
> There's only one method to keep trojans from shutting down a firewall:
> Never run it as Administrator. But if the trojan can get administrator
> privileges even from an user account, even most up-to-date firewalls can
> not help you.
> And yes, trojans do this.
>
> The problem with Kerio is its interaction with the user account: As long
> as a user can change the ruleset, a trojan can also. I don't know where
> in Kerio the password authentication for rulechanging is needed. If it's
> needed only in the client and the server process doesn't ask for it, you
> should better use another software or, even better, a hardware firewall.
> If this password is asked by the server process, neither an user nor a
> trojan can alter rules without having the password.
> Since Kerio is a two component system with the server-service filtering
> packets and a client acting as an interface for serverconfiguration I
> think/hope the developers were wise enough to implement the password
> authentication in the server process, not in the client.
> If that's the case, you have a password for Kerio set and you're only
> working as administrator if absolutely necessary, it's quite unlikely
> that a trojan can shutdown Kerio or alter its rules.
>
> Greetings,
> Felix

Well, I think it _does_ separate the user/admin privilegies ok, as I've
run it as admin, then switched to a user account and tried to run a
program (with no rules) which tried to access the internet; all the
dialog from Kerio only showed up on the admin screen, and to the user it
looked like his program had stopped responding. (XP home & Kerio 2.1.5)

/Rolf

Re: Kerio PFW 2.14 - Safe?

In article <8q2cbnf1fc5j@x02x67invalid.net>,
synesthesia@ix02x67invalid.net says...
> Kerodo wrote...
>
> > And I've seen things to dispute this here as well. If Kerio had SPI
> > then I would not see outbound ICMP type 3 packets to my DNS servers at
> > times. Kerio would only accept responses to DNS initiated by my system.
> > This is however not the case.
>
> I don't know the specific answer to the does/doesn't question, but
> stateful packet inspection doesn't necessarily mean there will be no
> replies to requests that are externally initiated. Stateful inspection
> means a firewall will keep track of the "state" of a connection by
> observing things like origins, destinations, and packet sequences so it
> can better determine what sort of traffic it's dealing with, but it in
> no way guarantees any specific traffic will be accepted or rejected.
> That is entirely up to the firewall rule set.
>
> The traffic you describe is "normal" activity, and probably would be be
> passed by any firewall that didn't explicitly deny it. Stateful
> inspection may aid the firewall in controlling who it replies to or
> under what conditions, or even detect some sort of odd "fragmented
> packet" activity from an alleged name server or nefarious local source,
> but the yes/no question is generally answered elsewhere.

Thanks for the explanation... that's very interesting..

With Kerio here, I see miscellaneous packets coming in from my DNS
servers at times, addressed to various ports, and then my system
resonding with an outbound ICMP type 3 to these packets, which I assume
is just my system saying "port closed" or some such thing. I've never
worried about it since it's from a "trusted" source.

However, with ZoneAlarm, which definitely has stateful inspection, I
don't see any of this outbound ICMP 3 activity. So I assumed that the
stateful inspection stopped it and kept the firewall from accepting the
random inbound UDP packets, hence no system reply. Perhaps I'm wrong
here though. I don't know..

I did manage to stop this activity in Kerio 2.1.5 by simply adding
"services.exe" as the application to my DNS rules. That's for Win2k.
In XP I guess it would be "svchost.exe". Not sure. Anyway, this
effectively keeps Kerio from accepting any stray inbound DNS packets
that are not the result of DNS queries initiated by my system. Seems to
work anyway. I now see no outbound ICMP type 3 anymore.

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

In article <41405562.6080308@pc-tiede.de>, tiede@pc-tiede.de says...
> Kerodo wrote:
> > In article ,
> > Casey@nosuch.net says...
> >
> >>Looks like Kerio v2.1 does have stateful packet inspection.
> >>Quoted from the Kerio 2.1 User's Guide:
> >>"The main principal behing a firewall such as KPF is stateful
> >>inspection. This ensures that Personal Firewall only allows
> >>communication initiated from within the local network"
> >>Casey
> >
> >
> > Casey... on second thought, I'm fairly sure that despite what the user's
> > guide says, it does not have SPI. I've seen several references to this
> > in various forums and other groups..
> >
> > And I've seen things to dispute this here as well. If Kerio had SPI
> > then I would not see outbound ICMP type 3 packets to my DNS servers at
> > times. Kerio would only accept responses to DNS initiated by my system.
> > This is however not the case.
> >
>
> ICMP type 3 means "destination-unreachable". This is exactly the answer I
> would expect if the system in question blocks all incoming traffic except
> for traffic on initiated connections.
>
> If Kerio hadn't SPI it couldn't determine whether incoming packets are
> related to one of your initiated connections or not. So you couldn't see
> anything on the internet, since Kerio would block *all* incoming packets.
> It may be true that it's not possible to use Kerio's SPI for finer filter
> rules, but Kerio *must* have it.

I think not Felix. But I could be wrong.

I have conducted tests here with Kerio 4.1 beta, which DOES have
stateful inspection now, and I don't see any of this outbound ICMP 3
traffic to DNS servers at all. In Kerio 2.1.5 I do see it. This
further supports my thoughts that SPI should block this incoming DNS
traffic if working properly, and it doesn't in Kerio 2.

However, I'm certainly no expert, so I may be totally wrong...

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

In article ,
Casey@nosuch.net says...
> Looks like Kerio v2.1 does have stateful packet inspection.
> Quoted from the Kerio 2.1 User's Guide:
> "The main principal behing a firewall such as KPF is stateful
> inspection. This ensures that Personal Firewall only allows
> communication initiated from within the local network"
> Casey

You might ask about this in the Kerio 2 forum...http://forums.kerio.com/

I'm sure you'll get an answer and consensus on it..

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

Kerodo wrote...

>> The traffic you describe is "normal" activity, and probably would be be
>> passed by any firewall that didn't explicitly deny it. Stateful
>> inspection may aid the firewall in controlling who it replies to or
>> under what conditions, or even detect some sort of odd "fragmented
>> packet" activity from an alleged name server or nefarious local source,
>> but the yes/no question is generally answered elsewhere.
>
> Thanks for the explanation... that's very interesting..
>
> With Kerio here, I see miscellaneous packets coming in from my DNS
> servers at times, addressed to various ports, and then my system
> resonding with an outbound ICMP type 3 to these packets, which I assume
> is just my system saying "port closed" or some such thing. I've never
> worried about it since it's from a "trusted" source.

That's basically what's happening. The ICMP type 3 packet is a
"Destination Unreachable" packet. In general terms it's a standard reply
sent out by what's basically your operating system, to any request that
can't be fulfilled because there's simply nothing listening. The packet
itself has flags that detail the specific reason a "destination" can not
be reached, like "host unreachable" or "port unreachable", and some
other information like a piece of the original request packet. If you're
really curious and have some time to waste you could capture a few of
the packets with something like Ethereal and pick at them.

> However, with ZoneAlarm, which definitely has stateful inspection, I
> don't see any of this outbound ICMP 3 activity. So I assumed that the
> stateful inspection stopped it and kept the firewall from accepting the
> random inbound UDP packets, hence no system reply. Perhaps I'm wrong
> here though. I don't know..

I don't know the details of how ZA or Kerio handle this, but my first
question would be how you know there's no Destination Unreachable packet
geing sent out. ;) Kerio may report them and ZA not. Or... it could be
that they really aren't being sent out because ZA uses "stealth
technology". A fancy name for just dropping packets rather than issuing
the standard reply.

Stealth is a little "snake oily" in my opinion. It really doesn't prove
to the outside world that your machine doesn't exist like it claims to
do, and as far as I'm concerned there's nothing wrong with being polite
and just saying "not listening". It's not a huge security breach or
anything, and if someone really want's to own you, so called "stealth"
is meaningless if there's simply no service listening on a port anyway.
About the only real advantage it gives you is some immunity to being
spotted by cursory, random scans.

> I did manage to stop this activity in Kerio 2.1.5 by simply adding
> "services.exe" as the application to my DNS rules. That's for Win2k.
> In XP I guess it would be "svchost.exe". Not sure. Anyway, this
> effectively keeps Kerio from accepting any stray inbound DNS packets
> that are not the result of DNS queries initiated by my system. Seems to
> work anyway. I now see no outbound ICMP type 3 anymore.

It looks like you pretty much seem to have a grip on it. If Kerio just
drops the incoming packet you've achieved "stealthdom", and made it
every bit the firewall ZA is in context. Although in this case I'd say
you've probably built an electrified fence and hired killer Dobermans to
keep a lamb out of a sheep's house, but what the hell... you probably
didn't break anything in the process and that's a plus.

--
Those who beat their swords into plowshares will plow for those
who do not.

-- Unknown

Re: Kerio PFW 2.14 - Safe?

In article ,
synesthesia@ix02x67invalid.net says...
> > However, with ZoneAlarm, which definitely has stateful inspection, I
> > don't see any of this outbound ICMP 3 activity. So I assumed that the
> > stateful inspection stopped it and kept the firewall from accepting the
> > random inbound UDP packets, hence no system reply. Perhaps I'm wrong
> > here though. I don't know..
>
> I don't know the details of how ZA or Kerio handle this, but my first
> question would be how you know there's no Destination Unreachable packet
> geing sent out. ;) Kerio may report them and ZA not. Or... it could be
> that they really aren't being sent out because ZA uses "stealth
> technology". A fancy name for just dropping packets rather than issuing
> the standard reply.

Well, with ZA, I am assuming that it would show any outbound ICMP 3 in
the logs. Maybe not though, but I can only assume it's not there if I
don't see it.

I've tried this with several firewalls. ZA, I see no outbound type 3.
Sygate, I DO see outbound type 3, because, I'm thinking, Sygate has
stateful inspection ONLY on TCP and not UPD, which is what DNS uses.

Kerio 4 I see no outbound type 3 due to stateful inspection of UDP (or
so I assume). Kerio 2, I DO see it, due to no stateful inspection (so
I'm assuming from various discussions and my own above experience).

> > I did manage to stop this activity in Kerio 2.1.5 by simply adding
> > "services.exe" as the application to my DNS rules. That's for Win2k.
> > In XP I guess it would be "svchost.exe". Not sure. Anyway, this
> > effectively keeps Kerio from accepting any stray inbound DNS packets
> > that are not the result of DNS queries initiated by my system. Seems to
> > work anyway. I now see no outbound ICMP type 3 anymore.
>
> It looks like you pretty much seem to have a grip on it. If Kerio just
> drops the incoming packet you've achieved "stealthdom", and made it
> every bit the firewall ZA is in context. Although in this case I'd say
> you've probably built an electrified fence and hired killer Dobermans to
> keep a lamb out of a sheep's house, but what the hell... you probably
> didn't break anything in the process and that's a plus.

Yep, I'm happy now.. Works for me, even if it is a little overkill. :)

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC9CC6D7334C2AB8F985AFF5C
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kerodo wrote:
> In article <41405562.6080308@pc-tiede.de>, tiede@pc-tiede.de says...
>
>>Kerodo wrote:
>>
>>>In article ,
>>>Casey@nosuch.net says...
>>>
>>>
>>>>Looks like Kerio v2.1 does have stateful packet inspection.
>>>>Quoted from the Kerio 2.1 User's Guide:
>>>>"The main principal behing a firewall such as KPF is stateful
>>>>inspection. This ensures that Personal Firewall only allows
>>>>communication initiated from within the local network"
>>>>Casey
>>>
>>>
>>>Casey... on second thought, I'm fairly sure that despite what the user's
>>>guide says, it does not have SPI. I've seen several references to this
>>>in various forums and other groups..
>>>
>>>And I've seen things to dispute this here as well. If Kerio had SPI
>>>then I would not see outbound ICMP type 3 packets to my DNS servers at
>>>times. Kerio would only accept responses to DNS initiated by my system.
>>>This is however not the case.
>>>
>>
>>ICMP type 3 means "destination-unreachable". This is exactly the answer I
>>would expect if the system in question blocks all incoming traffic except
>>for traffic on initiated connections.
>>
>>If Kerio hadn't SPI it couldn't determine whether incoming packets are
>>related to one of your initiated connections or not. So you couldn't see
>>anything on the internet, since Kerio would block *all* incoming packets.
>>It may be true that it's not possible to use Kerio's SPI for finer filter
>>rules, but Kerio *must* have it.
>
>
> I think not Felix. But I could be wrong.
>
> I have conducted tests here with Kerio 4.1 beta, which DOES have
> stateful inspection now, and I don't see any of this outbound ICMP 3
> traffic to DNS servers at all. In Kerio 2.1.5 I do see it. This
> further supports my thoughts that SPI should block this incoming DNS
> traffic if working properly, and it doesn't in Kerio 2.
>
> However, I'm certainly no expert, so I may be totally wrong...
>
A good firewall should signal to the sender, that the port is either closed
or communication is prohibited. Otherwise the sender can be sure, that there
is something and it's trying its best to conceal itself. If a system should
be hidden from the net, the last router before this system should send a
"destination host unreachable".
The difference between Kerio 2.1.5 and 4.x may be, that the latter uses TCP
RST packets to signal a closed port (which is almost equal to ICMP 3). If
there are *no* packets sent back to the DNS, the firewall doesn't obey the
RFCs regarding these cases, which is development in the wrong direction.

Greetings,
Felix

--------------enigC9CC6D7334C2AB8F985AFF5C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBQNSyDH+mFzdSOa0RAlgdAJ9wQmKGVeADeXMy39iewJADMGeDDwCc DdsN
ChjEfBkeVB7C3mektzWNFOs=
=zoEO
-----END PGP SIGNATURE-----

--------------enigC9CC6D7334C2AB8F985AFF5C--

Re: Kerio PFW 2.14 - Safe?

In article <2qc2ljFu56ufU1@uni-berlin.de>, tiede@pc-tiede.de says...
> A good firewall should signal to the sender, that the port is either closed
> or communication is prohibited. Otherwise the sender can be sure, that there
> is something and it's trying its best to conceal itself. If a system should
> be hidden from the net, the last router before this system should send a
> "destination host unreachable".
> The difference between Kerio 2.1.5 and 4.x may be, that the latter uses TCP
> RST packets to signal a closed port (which is almost equal to ICMP 3). If
> there are *no* packets sent back to the DNS, the firewall doesn't obey the
> RFCs regarding these cases, which is development in the wrong direction.

Interesting.. thanks for the info.. I've read elsewhere that generally
speaking, you do *not* want your system or firewall responding to
external traffic. But this looks like one of those situations where a
full blown debate is about to erupt... I think I'll sit this one out..
:)


--
Kerodo

Re: Kerio PFW 2.14 - Safe?

Felix Tiede wrote:
> A good firewall should signal to the sender, that the port is either
> closed or communication is prohibited. Otherwise the sender can be sure,
> that there is something and it's trying its best to conceal itself. If a
> system should be hidden from the net, the last router before this system
> should send a "destination host unreachable".
> The difference between Kerio 2.1.5 and 4.x may be, that the latter uses
> TCP RST packets to signal a closed port (which is almost equal to ICMP 3).
> If there are *no* packets sent back to the DNS, the firewall doesn't obey
> the RFCs regarding these cases, which is development in the wrong
> direction.

In principle your analysis is almost correct, with one small error: there is
little chance of answering with a TCP RST to a UDP packet (he was talking
about DNS, which is - mostly - UDP).

Some firewalls make a virtue out of sending no reply, and they even invented
a new term for it: "stealth". This may be great for a marketing brochure,
but is quite useless in the real world, especially if you have any service
at all open on your machine, with any protocol. Even worse, this breaks
some RFC's - not that that ever stopped the marketroids.
--
Mailman


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Re: Kerio PFW 2.14 - Safe?

In article <4140dbf6_5@corp.newsgroups.com>, mailman@anonymous.org
says...
> In principle your analysis is almost correct, with one small error: there is
> little chance of answering with a TCP RST to a UDP packet (he was talking
> about DNS, which is - mostly - UDP).
>
>
Good point.. Somehow, that went right by me. Thanks...

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

Felix Tiede wrote...

> The difference between Kerio 2.1.5 and 4.x may be, that the latter uses TCP
> RST packets to signal a closed port (which is almost equal to ICMP 3). If
> there are *no* packets sent back to the DNS, the firewall doesn't obey the
> RFCs regarding these cases, which is development in the wrong direction.

No, that's "stealth technology". It sounds really cool, so it *must* be
a good thing.

What's an RFC?



--
Don't worry about it. It's nothing.

-- U.S. Navy Lt. Tyler, Dec. 7, 1941, upon being informed that
radar had just picked a large formation of planes heading for
Pearl Harbor, Hawaii.

Re: Kerio PFW 2.14 - Safe?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5F379E53956053839C7BE4B5
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mailman wrote:
> Felix Tiede wrote:
>
>>A good firewall should signal to the sender, that the port is either
>>closed or communication is prohibited. Otherwise the sender can be sure,
>>that there is something and it's trying its best to conceal itself. If a
>>system should be hidden from the net, the last router before this system
>>should send a "destination host unreachable".
>>The difference between Kerio 2.1.5 and 4.x may be, that the latter uses
>>TCP RST packets to signal a closed port (which is almost equal to ICMP 3).
>>If there are *no* packets sent back to the DNS, the firewall doesn't obey
>>the RFCs regarding these cases, which is development in the wrong
>>direction.
>
>
> In principle your analysis is almost correct, with one small error: there is
> little chance of answering with a TCP RST to a UDP packet (he was talking
> about DNS, which is - mostly - UDP).
>
> Some firewalls make a virtue out of sending no reply, and they even invented
> a new term for it: "stealth". This may be great for a marketing brochure,
> but is quite useless in the real world, especially if you have any service
> at all open on your machine, with any protocol. Even worse, this breaks
> some RFC's - not that that ever stopped the marketroids.

Yes, you're right, I've missed that point. So Kerio has also made the step
to use this famous but almost completely useless "stealth" feature. One more
point to the list of reasons why I'm happy to stick with Kerio 2.1.5...

Greetings,
Felix

--------------enig5F379E53956053839C7BE4B5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBQV4EDH+mFzdSOa0RAnNOAJ0cY0wf2oUJaNO4wkLROXu9u/uXsgCd GjCp
eM8An+NtUCDOJitF/BGzDIc=
=kluG
-----END PGP SIGNATURE-----

--------------enig5F379E53956053839C7BE4B5--

Re: Kerio PFW 2.14 - Safe?

Kerodo wrote...

>> I don't know the details of how ZA or Kerio handle this, but my first
>> question would be how you know there's no Destination Unreachable packet
>> geing sent out. ;) Kerio may report them and ZA not. Or... it could be
>> that they really aren't being sent out because ZA uses "stealth
>> technology". A fancy name for just dropping packets rather than issuing
>> the standard reply.
>
> Well, with ZA, I am assuming that it would show any outbound ICMP 3 in
> the logs. Maybe not though, but I can only assume it's not there if I
> don't see it.

I learned a long time ago to not assume too much. ;) But if I were the
assuming type I'd have to say that my gut feeling about the "design
philosophy" of modern versions of ZA lean towards a pretty, but dumbed
down user interface. If I had to assume, I'd conclude ZA simply doesn't
tell you about everything as a matter of "not alarming the unwashed
masses" or whatever. Again, that's just my opinion/assumption/whatever.

> I've tried this with several firewalls. ZA, I see no outbound type 3.
> Sygate, I DO see outbound type 3, because, I'm thinking, Sygate has
> stateful inspection ONLY on TCP and not UPD, which is what DNS uses.
>
> Kerio 4 I see no outbound type 3 due to stateful inspection of UDP (or
> so I assume). Kerio 2, I DO see it, due to no stateful inspection (so
> I'm assuming from various discussions and my own above experience).

Don't take this the wrong way, but I'd say my above assumption would
have a little more basis in fact than an assumption that contradicted a
software's literal statements. If Kerio 'X' says it's stateful it most
likely is, and any observed behavior that appears to contradict this
would likely be a product of rules, or reporting philosophy. The only
way to know for sure would be to stand between the firewall and the
outside world and observe the actual traffic itself. There's simply too
many "what if's" for anything else to be more than speculation.

--
Christianity neither is, nor ever was a part of the common law.

-- Thomas Jefferson

Re: Kerio PFW 2.14 - Safe?

Peter Boulton wrote on 08/09/2004 13:26:
> Hi,
>
> Of the personal firewalls I've looked at, Kerio 2.14 seems the best for
> the following reasons:
>
> 1) No bloated 'glitzy' interface
> 2) I like the traffic monitor which lets me see where my bandwidth is
> going
> 3) Seems to have everything ZA has as far as a firewall is concerned.
> 4) Seems like one of the lowest footprints.
>
> However, my concern is that this software is now quite old. Does this
> make it any more vulnerable than, say, the latest version of Zone Alarm,
> or any of the other firewalls?
>
> FWIW, I'm running XP SP2, don't especially like the new ICF, behind a
> NAT ADSL router with the hardware firewall enabled. Oh, and yes, I'm
> running AV software!
>
> Thanks,
>
> Pete

Hello, OP here! This has been a really interesting thread and I'd like
to thank everyone who's taken the trouble to respond (if that doesn't
sound too pompous! :->> )

Anyone care to attempt a summary? Here's my one for everyone to contradict:

1) Unclear on whether Kerio 2.14/5 offers stateful packet inspection,
but the docs claim it does.

2) Assuming your Kerio 2.14/5 rules are appropriate, the vulnerability
of your system is not noticeably worse than with more modern software
firewalls.

3) If you are running a router/NAT + up to date av with Kerio 2.14/5
then any additional risks from Kerio 2.14/5 are largely theoretical.

Is this right, or am I just stirring it again? Hope the former, as I'm
still happily running Kerio 2.14/5!

Cheers!

Pete

Re: Kerio PFW 2.14 - Safe?

Taking a moment's reflection, Peter Boulton mused:
|
| Is this right, or am I just stirring it again? Hope the former, as I'm
| still happily running Kerio 2.14/5!

As long as we are speaking in generalities ... yes, that's right.

Re: Kerio PFW 2.14 - Safe?

Peter Boulton wrote...

> Anyone care to attempt a summary? Here's my one for everyone to contradict:

Hey... you asked for it. ;)

> 1) Unclear on whether Kerio 2.14/5 offers stateful packet inspection,
> but the docs claim it does.

If Kerio 2.14/5 states it's stateful, it's pretty clear it is. Stateful
inspection is a type of inspection... a general descriptive term with a
few "should do this" rules, not a hard wired design parameter governed
by a set of "must examine bit x of third byte in field y" blueprints.
Each firewall peddler is free to develop their own specific methods of
watching the state of a connection, a general philosophy about how much
weight that flavor of inspection is given compared to "dumb" packet
filtering, and what to do with the information stateful inspection
uncovers.

Stateful inspection is also completely useless without, and greatly
influenced by, the rules set the firewall applies. Seeing packets of
type 'X' leave your machine tells you absolutely nothing at all about
what caused those packets to exist. It's every bit as possible that a
stateful inspection method detected an incoming request a non-stateful
inspector would have completely missed, as it is is that a "dumb" packet
filter just replied to something *it* saw. Inspection methods have
nothing at all to do with security policies outside the fact that they
provide more information for that policy to consider, and the buzz words
"stateful" and "stealth" have no relationship at all. Don't be mislead
into confusing them.

> 2) Assuming your Kerio 2.14/5 rules are appropriate, the vulnerability
> of your system is not noticeably worse than with more modern software
> firewalls.

It could be theoretically better. Any attack against a firewall itself
is likely to be version specific, and would almost have to be at least
brand specific. If you assume the attacks you'll encounter today will be
against more common and modern firewalls, in theory you could be safer
with an older or off color firewall. Assuming all else is equal of
course. Not much has changed about the "core" functionality of TCP/IP
over the years. There's very little a newer firewall van do that an
older one can not, other than be more prepared to deal with known
specific threats that didn't previously exist. This is largely a
policy/rules thing that can be configured if the firewall itself isn't
utterly useless to begin with.

> 3) If you are running a router/NAT + up to date av with Kerio 2.14/5
> then any additional risks from Kerio 2.14/5 are largely theoretical.

If you're running NAT with everything properly configured and
maintained, Kerio 2.14/5 is basically irrelevant. So is the most recent
version of Zone Alarm, the time tested ipchains, or any software
firewall running on a workstation behind NAT. The "can't get here from
there" philosophy applies. With the notable exception that you suspect
an attack from within your own network of course. ;)

> Is this right, or am I just stirring it again? Hope the former, as I'm
> still happily running Kerio 2.14/5!

For all intents and purposes you should be. You're likely every bit as
safe from intrusion as the guy who has the shiny new copy of
"HckerKnocker 3000" sitting there handing him a fluffy GUI with nice
dithered edges, or the geek with the 386DX266 and a terminal only
installation *nix/ipchains. Again, assuming everything is set up and
configured properly of course...

And yes, you're stirring.

--
The surest way to corrupt a youth is to instruct him to hold in
higher regard those who think alike than those who think
differently."

-- Nietzsche

Re: Kerio PFW 2.14 - Safe?

Copelandia Cyanescens wrote on 10/09/2004 19:28:
> Peter Boulton wrote...
>
>
>>Anyone care to attempt a summary? Here's my one for everyone to contradict:
>
>
> Hey... you asked for it. ;)
>
>
>>1) Unclear on whether Kerio 2.14/5 offers stateful packet inspection,
>>but the docs claim it does.
>
>
> If Kerio 2.14/5 states it's stateful, it's pretty clear it is. Stateful
> inspection is a type of inspection... a general descriptive term with a
> few "should do this" rules, not a hard wired design parameter governed
> by a set of "must examine bit x of third byte in field y" blueprints.
> Each firewall peddler is free to develop their own specific methods of
> watching the state of a connection, a general philosophy about how much
> weight that flavor of inspection is given compared to "dumb" packet
> filtering, and what to do with the information stateful inspection
> uncovers.
>
> Stateful inspection is also completely useless without, and greatly
> influenced by, the rules set the firewall applies. Seeing packets of
> type 'X' leave your machine tells you absolutely nothing at all about
> what caused those packets to exist. It's every bit as possible that a
> stateful inspection method detected an incoming request a non-stateful
> inspector would have completely missed, as it is is that a "dumb" packet
> filter just replied to something *it* saw. Inspection methods have
> nothing at all to do with security policies outside the fact that they
> provide more information for that policy to consider, and the buzz words
> "stateful" and "stealth" have no relationship at all. Don't be mislead
> into confusing them.
>
>
>>2) Assuming your Kerio 2.14/5 rules are appropriate, the vulnerability
>>of your system is not noticeably worse than with more modern software
>>firewalls.
>
>
> It could be theoretically better. Any attack against a firewall itself
> is likely to be version specific, and would almost have to be at least
> brand specific. If you assume the attacks you'll encounter today will be
> against more common and modern firewalls, in theory you could be safer
> with an older or off color firewall. Assuming all else is equal of
> course. Not much has changed about the "core" functionality of TCP/IP
> over the years. There's very little a newer firewall van do that an
> older one can not, other than be more prepared to deal with known
> specific threats that didn't previously exist. This is largely a
> policy/rules thing that can be configured if the firewall itself isn't
> utterly useless to begin with.
>
>
>>3) If you are running a router/NAT + up to date av with Kerio 2.14/5
>>then any additional risks from Kerio 2.14/5 are largely theoretical.
>
>
> If you're running NAT with everything properly configured and
> maintained, Kerio 2.14/5 is basically irrelevant. So is the most recent
> version of Zone Alarm, the time tested ipchains, or any software
> firewall running on a workstation behind NAT. The "can't get here from
> there" philosophy applies. With the notable exception that you suspect
> an attack from within your own network of course. ;)
>
>
>>Is this right, or am I just stirring it again? Hope the former, as I'm
>>still happily running Kerio 2.14/5!
>
>
> For all intents and purposes you should be. You're likely every bit as
> safe from intrusion as the guy who has the shiny new copy of
> "HckerKnocker 3000" sitting there handing him a fluffy GUI with nice
> dithered edges, or the geek with the 386DX266 and a terminal only
> installation *nix/ipchains. Again, assuming everything is set up and
> configured properly of course...
>
> And yes, you're stirring.
>
Thanks for the response. Very helpful!

Cheers,

Pete the Stirrer

Re: Kerio PFW 2.14 - Safe?

In article <1e47gkdzju13x$@x02x67invalid.net>,
synesthesia@ix02x67invalid.net says...

>
> I learned a long time ago to not assume too much. ;) But if I were the
> assuming type I'd have to say that my gut feeling about the "design
> philosophy" of modern versions of ZA lean towards a pretty, but dumbed
> down user interface. If I had to assume, I'd conclude ZA simply doesn't
> tell you about everything as a matter of "not alarming the unwashed
> masses" or whatever. Again, that's just my opinion/assumption/whatever.

Yes, you're probably right. That's pretty scary though, to think that
ZA isn't really showing you everything in the logs. Of course there is
some stuff I probably don't care to see, but something like outbound
type 3 ought to be shown. But knowing ZA, I think perhaps you are
right.

>
> Don't take this the wrong way, but I'd say my above assumption would
> have a little more basis in fact than an assumption that contradicted a
> software's literal statements. If Kerio 'X' says it's stateful it most
> likely is, and any observed behavior that appears to contradict this
> would likely be a product of rules, or reporting philosophy. The only
> way to know for sure would be to stand between the firewall and the
> outside world and observe the actual traffic itself. There's simply too
> many "what if's" for anything else to be more than speculation.

It does seem convincing if Kerio actually says it's stateful.

I myself am currently running Kerio 2.1.5, stateful or not, simply
because I like it best and feel most comfortable with the interface and
the rules. It's my favorite firewall.

The fact that it's an aging firewall that is no longer being updated
doesn't bother me at all. It works well as is. And I'd much rather see
it stay as is than add a bunch of useless extra stuff like ZA and others
do all the time with their updates.

If it gets the job done and you feel comfortable with it, then that's
all you need.

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

In article ,
Casey@nosuch.net says...
> Looks like Kerio v2.1 does have stateful packet inspection.
> Quoted from the Kerio 2.1 User's Guide:
> "The main principal behing a firewall such as KPF is stateful
> inspection. This ensures that Personal Firewall only allows
> communication initiated from within the local network"
> Casey

Casey, can you point me to a link so I can download that Kerio Users
Guide? I downloaded another one for Kerio 2.1 which looks like the Tiny
PF User Guide and I find no mention of stateful inspection in it.

Thanks..

--
Kerodo

Re: Kerio PFW 2.14 - Safe?

>Casey, can you point me to a link so I can download that Kerio Users
>Guide? I downloaded another one for Kerio 2.1 which looks like the Tiny
>PF User Guide and I find no mention of stateful inspection in it.

http://lists.Gpick.com/crashsite/downloads/kpf21-en-v1.zip

Look under "Kerio Personal Firewall 2.1\Security Settings\How does Kerio
Personal Firewall work?" in the contents.
--
Dave "Crash" Dummy - A weapon of mass destruction
crash@gpick.com?subject=Techtalk (Do not alter!)
http://lists.gpick.com

Re: Kerio PFW 2.14 - Safe?

In article <10k4qm3e4daeb20@corp.supernews.com>, dvader@deathstar.mil
says...
> >Casey, can you point me to a link so I can download that Kerio Users
> >Guide? I downloaded another one for Kerio 2.1 which looks like the Tiny
> >PF User Guide and I find no mention of stateful inspection in it.
>
> http://lists.Gpick.com/crashsite/downloads/kpf21-en-v1.zip
>
> Look under "Kerio Personal Firewall 2.1\Security Settings\How does Kerio
> Personal Firewall work?" in the contents.
>

Ok, thanks, I just looked in the help file that comes with 2.1.5 and
found what he was talking about...

"The main principle behind a firewall such as KPF is stateful
inspection. This means that a record is made on every packet going from
your computer and only a packet corresponding with this record is let
pass back through. All other packets are dropped. This ensures that
Personal Firewall only allows communication initiated from within the
local network."

I'll be damned... :)


--
Kerodo

Re: Kerio PFW 2.14 - Safe?

Kerodo wrote...

Sorry for the lag. :(

>> I learned a long time ago to not assume too much. ;) But if I were the
>> assuming type I'd have to say that my gut feeling about the "design
>> philosophy" of modern versions of ZA lean towards a pretty, but dumbed
>> down user interface. If I had to assume, I'd conclude ZA simply doesn't
>> tell you about everything as a matter of "not alarming the unwashed
>> masses" or whatever. Again, that's just my opinion/assumption/whatever.
>
> Yes, you're probably right. That's pretty scary though, to think that
> ZA isn't really showing you everything in the logs.

Naaa... it's not scary at all. If you want your adrenaline level raised,
stand in the network stream with a packet sniffing tool and get a feel
for what none of them tell you. Then consider the fact that most packet
sniffing tools don't tell you everything either.

Please *don't* take this personally, but for a lot of people a typical
horror story script begins with the line "A user opened his log file and
saw...". ;) This thread is an example of that plot. The bottom line is
that the outgoing packets you describe should be sent "by law". The
general guidelines that govern such things dictate that the appropriate
response be sent to any request, and anything contrary to that can
potentially break something. In this light, Zone Alarm's assumed
behavior of not replying is the real problem, not Kerio's. Kerio is
doing everything right except failing to obscure normal and expected
network activity from the average user's field of vision. It's only
common sense to reply when the name server you've been using asks
something, and if all is as it appears I'd have to say that ZA's alleged
dropping of those packets is broken behavior.

> Of course there is
> some stuff I probably don't care to see, but something like outbound
> type 3 ought to be shown. [...]

I totally disagree. Logging normal activity at normal levels is about as
useful and informative as measuring the tread life of your car's tires
with a dashboard light that blinks every time they complete a rotation.
Common sense dictates only abnormal or cumulative activity is
relevant... an odometer reading that surpasses Firestone's estimation of
tread life, or a firewall that gives "someone tapped port whatever a
bazillion times in the last 10 minutes" alerts.

>> Don't take this the wrong way, but I'd say my above assumption would
>> have a little more basis in fact than an assumption that contradicted a
>> software's literal statements. If Kerio 'X' says it's stateful it most
>> likely is, and any observed behavior that appears to contradict this
>> would likely be a product of rules, or reporting philosophy. The only
>> way to know for sure would be to stand between the firewall and the
>> outside world and observe the actual traffic itself. There's simply too
>> many "what if's" for anything else to be more than speculation.
>
> It does seem convincing if Kerio actually says it's stateful.

I don't even know that much for sure. I'm really speaking in general
terms here, from the perspective of someone who has probably tried every
software firewall under the sun, but doesn't currently use any of them
and is too lazy to research the specifics of the questioned version. ;)
It could be Kerio's claims are total BS, but I rather doubt it.

> I myself am currently running Kerio 2.1.5, stateful or not, simply
> because I like it best and feel most comfortable with the interface and
> the rules. It's my favorite firewall.

A tool you know and use well is better than the tool you don't
understand or misuse... even if the latter is a better tool. :)

I'm a big Outpost fan myself. Even though it reeks of "stealth" snake
oil, I like it's thorough logs. Which I suppose makes me a hypocrite.



--
What the world needs is not dogma but an attitude of scientific
inquiry combined with a belief that the torture of millions is
not desirable, whether inflicted by Stalin or by a Deity imagined
in the likeness of the believer.

-- Bertrand Russell

Re: Kerio PFW 2.14 - Safe?

On Thu, 09 Sep 2004 10:47:33 GMT, "Clive" wrote:


>
>Does 2.15 work on W2K and XP SP2?
>
>Clive
>


I've got kerio 2.15 running on w2k sp4 no problems.

Got eudora lite v3.06 too ;)

Re: Kerio PFW 2.14 - Safe?

In news:comp.security.firewalls, Felix Tiede posted on
Thu, 09 Sep 2004 16:28:41 +0200:

> If that's the case, you have a password for Kerio set and you're only
> working as administrator if absolutely necessary, it's quite unlikely that a
> trojan can shutdown Kerio or alter its rules.

If you have to be in an admin account to change rulesets in Kerio, then
doesn't that mean that anytime you receive a "what do I do" window with a
request for instructions, you'd have to log out of the user account, log in
to the admin account, try to recreate the event that caused the permission
window, allow or disallow, then log back in to your user account? That
seems like a major fajita PITA. Seems simpler to just password-protect the
ruleset, but then malicious keystroke logging programs could simply monitor
and steal your password that way. :-\

Damaeus