Need some CoreForce configuration tips

Hello,

I am currently testing the 0.95 version, which seems to be stable.

But there are numerous things I don't understand using this FW.

First of all, the "ping issue".

Let say I have a brand new CF installation.
My conf is empty : no programs, and just one system rule : block all and log.
That's great !

Then I want my machine to be reachable by ping.
I try to ping it, have time out answer - OK.
I have a log entry, perfect.
Then I authorize the ping request, and only this (by doing a new rule, or right click to the log entry, and say allow it, great feature).

Then I'd like to have time out, and a new log entry for icmp reply outbound block (remember, I block all but inbound icmp requets).
But the ping is now OK ! no time out, and nothing in the log.

Last but not the least : I remove the icmp request inbound rule, but the ping is still allowed.

What is wrong with my tests ? Or a bug ?

 

Hello gagman,

By adding a rule via log, this will auto apply the change

The reply will be made via SPI, if you want the rule to only allow the inbound, and not reply, then change the ICMP rule settings "Advanced ~ Stateful" to "NO"

Ensure when you manually remove a rule that you "Apply changes" (top left of console (looks like a bolt of lightning))

 

There is stateful insecption on ICMP packets ? I'm sorry, I didn't notice it.
I will try.

And for the idea that I didn't apply my changes when removing my icmp inbound rule... I will check.

 

Yes, there is stateful on ICMP

I have installed CF, and removed the ICMP rule (following your test) and the rule remained active untill I applied the changes. After I applied the changes, the packets where dropped.

 

I've done some more investigation :
when playing with my ping test and rules without stateful on, it's OK.
when I add a rule to allow ping - stateful on), then the ping is allowed (great). IKf I remove the rule (and applying the change correctly), the ping is still allowed.

It seems that the connection table used for stateful inspection packet (I presume there is one) is not cleared. So my current connection remains, and ping is still allowed.

Any idea ?


EDIT : just seen your last comment, Stem. Tanks for the test, but the behavior is not the same for me !
Which version of CF on your side ? 0.95 for me.

 

0.95.167, (I have just downloaded as my last version was 0.9)

What O.S. are you using, I am currently on W2K

What other rules are currently active?

 

Same CF version here, but on Win2K server.
Only one rule : block all, and ping is still running.

And 2 NIC on the test machine, same behavior on both.

 

I dont have W2K server, so not able to set up on this to rest.
I can only go off my currnet findings,... that once I removed the rule and applied, that the inbound was blocked.
On the allow ICMP rule, did you set to logging,.... then if the rule is still active after you remove the rule, then these packets will still be logged (just a thought)

 

For sure the logging was on, but nothing in the log !

 

I am now seeing this behaviour, CF must, as you mentioned, be keeping the state table open for the rule, I am seeing a time out (for the rule being allowed, after deleting the ICMP rule) even if the ICMP rule is changed to block in/out

 

So you are experiencing the same issue.
I'm trying to have answer for that on CF forums.

 

BTW, Stem, sorry to say that, but according to CF guy, you're wrong on that point :


snip from CF guy post : Firewall rules and permissions added from the Activity Monitor's log or network viewers will also enable the thunderbolt button (Apply changes) and be retained until you click on the icon, switch to another category or close the configuration window.

 

Well, how did CF react when you added a rule via activity monitor?.......... on my setup, when I added the rule via activity monitor, the rule was added, the "thunderbolt" was not lit up, and the rule was applied.
I can only go of how I viewed CF behave, not how it should behave.
Did you get a reply about the ICMP?

 

We can read this on CF website :
Another advantage of keeping state is that corresponding ICMP traffic will be passed through the firewall. For example, if Stateful is specified for a TCP connection and an ICMP message referring to this TCP connection arrives, it will be matched to the appropriate state and passed through the firewall.

Though UDP is a conectionless transport protocol, CORE FORCE defines a state for an UDP pseudo-connection, keeping track of packets for the same source and destination addresses and ports. These pseudo-connections are removed when no traffic has been handled after a while. Packets of ICMP protocol use a similar feature, based on matching appropiate ICMP options.

They have UDP and ICMP stateful mechanisms. OK, sounds good. A lot of firewalls are doing the same.
But what about the idea of matching the ICMP packet to a state related to a TCP connection ?? Sounds weird to me.
Do they mean if there is a TCP connection up, then icmp is allowed

I won't be surprised if the behavior of my "ping issue" is somewhere related to that.

 

I will do the test, in fact this point is of no matter, just click on apply when you can and you need to !

About the ping, I don't have any answer yet, will keep you posted.

(thanks for all your tests, it seems you have all the personal firewalls ready to use very close to you, Stem !!)

 

I can understand allowing ICMP back through an outbound connection made,.. as this will allow error messages. But as the tests made with the ICMP where made from a remote PC (no outbound connection made to that remote PC) I see no reason for this explantion from CF.
When a rule is removed, it should be removed, not a timeout before the removed rule is inactive.

 

I totally agree with you Stem, when I block, I want to block.

When I wrote :
I won't be surprised if the behavior of my "ping issue" is somewhere related to that.

I was not very "understandable".
I just want to say that they have maybe a kind of control/behavior for ICMP which is different from what we know from other FWs.

But again, but I block icmp, I want to block icmp, even if a tcp connection is up.

Still waiting answer from CF guy...

 

Well from the CF statement:

This is what I mentioned to you in my earlier post,.. as at first this did work. But after playing around with creating/deleting rules, the ICMP rule did remain active,..... it appeared to be active for around 60 seconds, after deletion (and applying)

 

When I added a rule via activity monitor, the thunderbolt was lit up here.
But the changes are applied if I click on it, or if I change window (for example switching from activity monitor to permissions.

 

So for you, the rule is active for around 60s.
For me, it's active all the time, no delay.

Sounds weird... I will do more tests.

 

I am going to setup on XP,... I am starting to see a few (minor) problems with a number of software updates and W2k.

 

I haved switched to the other view mode (rightmost button of the toolbar, the icon looks like a table).
So it's easier to write rules in this post (just copy what CF wrote in the permissions view).


So I have only one rule :
block log from any to any

The ping is not allowed, OK (btw, I have only one log entry when doing a ping -t. I need to stop it, and to wait for some seconds before doing the ping again, then I can have a new log entry).
Then I add a new rule (the default one) :
pass log from any to any keep state

The ping is allowed (but nothing in the log).

I keep the ping -t runnig.

If I remove the last rule, to have ony the block all one, the ping is still allowed (at least for some minutes).
Then I stop the ping -t, and wait for some seconds, then launch the ping -t again.
Then the ping is not allowed.

But the most interesting part is :
if my pass from any to any is without the keep state option, then the behavior is OK.

I block all, ping is not allowed.
I add pass log from any to any, ping is allowed
I remove the pass rule, ping is not allowed anymore (ping -t is still running)

So the issue is really regarding state table.

BTW, doing all thoses tests, I never have a pass entry log...

 

We did both say it was the keep state (or stateful). There does need to be a complete stop in the pinging, otherwise it will still allow, the state will be kept (I should of mentioned that). On XP the timeout appears to be 30sec.

From the point of the adding a rule from the activity log,... the rule is active as I switch over from the log, to the permissions to check the rule as been added.(the apply is already greyed out)

Do you mean the allowed pings? (have you set the allow rule to log?)

 

You wrote :
There does need to be a complete stop in the pinging, otherwise it will still allow, the state will be kept

Yes, we already said that before, but playing with the stateful option in the allow rule shows it very clearly.
And I don't think it is a very good point for CF ! It's a pity, because CoreForce appears to be a very good firewall.

Regarding logs :
Yes, I set the allow rule to log, but no log.