Don't make this mistake in your firewall rules


2013/05/17

A customer called this morning with a problem.  He'd upgraded his Kerio Connect mail server so that they could use Instant Messaging and said he'd run into a problem.  When I asked what that problem was, he said that it actually had to do with their Kerio Control Firewall.  

"OK", I asked, "what happened?"

"Nothing", he said, "and that's the problem."

He continued:

"I expected that I'd be blocked from downloading the Pidgin EXE file, but I wasn't.  I then checked other things that should be blocked, and they are not - I can go to anything, anywhere!"

Oops.  That's not good.  I quickly logged in and took a look at his Filter log.  Sure enough, the last time anything had been blocked was two weeks ago.   So, the next question is "What happened two weeks ago?".  I looked in the operations log and had my answer: he had added a new HTTP Policy rule.

Here's what it looked like when I went to look at the rules:

A rule that kills all following rules

It's the top rule he added, the one labeled "dafont.com".  Apparently they have users who regularly need to download fonts, so he added this rule to allow that.

Unfortunately, he didn't really add a rule.  This is how it should have been done.

The rule he should have added

His rule basically said "Allow anything" (because it referenced no URL at all), which effectively disables all rules below it. The traffic - all traffic - is allowed to pass. Basically, he mistook the name of a rule as being the rule itself.

I explained that to him and also pointed out that he'd be better off to put that site and any other sites he needs to whitelist into an "Allowed" URL group.

"Oh,", he said, "So if I call it 'Allowed' it will let it through?"

No.  I've seen this misconception before.  

URL Groups do NOTHING.

You can define any URL groups you like, but until you reference them in a rule, they mean nothing. Even in a rule, they can mean anything: you could make a group named "Allow" and put it in a "Deny" rule. I told him to look at the "Search Engines" rule as a good example. By default, it is set to allow that group of popular search engines, but we could change the "Action" to "Deny" and all of them would be blocked immediately.

So, lesson learned (I hope) and the system is back to its normal state.



Got something to add? Send me email.





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

Printer Friendly Version

-> -> Don't make this mistake in your firewall rules


2 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Mon May 20 21:06:37 2013: 12076   anonymous

gravatar


Interesting. I don't have any familiarity with Kerio firewall, but I have been keeping an eye on it as a potential future replacement of our Sonicwall system.

I would think Control would not allow duplicate rules like that, since the access rule appears to just be a duplicate of the final rule in the sequence.

I know that doesn't address the misconfiguration issue on the client's side, but it just seems like it could open up more opportunities for misconfiguration.



Mon May 20 21:11:54 2013: 12077   TonyLawrence

gravatar


Well, I agree that a rule with no conditions at the top should generate at least a warning.

Allowing duplicate rules can have a purpose, though - temporary debugging, for example. Just the same, a warning would help.





------------------------
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





Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds ... However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. (Tim Berners-Lee)

Better to fight for something than live for nothing. (George S. Patton)







This post tagged: