How to Optimize Security in Kerio 2.1.5 -Learning Thread 3

Hi:

1) I have 80 rules, with Stems split in ( I hope it is correct)
2) I also put in Rmus's rule on Port 53, it was really a matter of activating a BZ rule.
3) I will send today's October 3 rules to both of you and would really ask that 29.2 be set aside in favour of it for any editing

 

Rick/Stem:

What about this log packets to unopened ports setting?

 

That will cause incoming packets that are addressed to closed ports to be logged, "closed" as in not opened by a process or application on your system. Both hackers and malware scan PCs, looking for open ports to try to connect to. Since you're behind a router and hardware firewall, port scans won't reach your PC. Depending on how your router and firewall are set up, you could see some packets from them. With a hardware firewall blocking unwanted inbound traffic, the log will be more useful for specific monitoring of outbound traffic.
Rick

 

Okay, Rick, what about suspiciuos packets? Same logic? Only outbounds would be interesting?
Should I turn it on?


Oh, here is one you will like.

A day or so back, I thought I was restored a rule set. Something odd happened. i think I tried to restore from an empty set, not sure. But there should have been an alarm bell!

The rule set was empty! Nada, zip, void, Null what ever word you want!

I started getting pop ups, saying blah blah I want to connect.

What would happen If I left 0 rules in place and set it to deny all unless in the rules which don't exist?

My guess is if Kerio is working right, you will have no access to anything in or out. Same as stop all traffic?

 

I'm not sure just what Kerio considers suspicious packets. Turning it on won't cause any problems.

I'm not sure if it's the same when Kerio is installed on XP, but on my box, there's a .conf file in the Kerio folder named stat.conf. When I load it, I get one error message. Kerio seems to run fine, but there's no rules. I've run into quite a few times when an empty ruleset is handy.

With no rules and using the deny unknown setting, nothing should have internet access except Kerio itself.
Rick

 

October 5 bootup log observations:

These 2 10.x output UDP to 255.255.255.255 occured again today. They are the first entries occurring:

05/Oct/2007 07:24:06 Lan Subnet Bypass 10.x Outbound blocked; Out UDP; localhost:68->255.255.255.255:67; Owner: C:\WINDOWS\SYSTEM32\SVCHOST.EXE
05/Oct/2007 07:24:06 Lan Subnet Bypass 10.x Outbound blocked; Out UDP; localhost:68->255.255.255.255:67; Owner: C:\WINDOWS\SYSTEM32\SVCHOST.EXE

They show as if they are from an activated SVCHOST.EXE.

But which one?

____________________________________________________________________________________



Hi Stem:

Here is the bootup log from this morning. You dual split rule shows 2 outbound blocks!

Now I'm concerned I have a malware! It seems unlikely. Should I be?
These were blocked on outbound. for 10.x

All scans by Nod 32 show zip.
Ad Aware shows only tracking and MRU otherwise clean, Spybot S and D shows zip.

 

I'm using a friends XP unit that uses Kerio. Here's the result of a test using a similar rule. I inserted this rule at the top of the ruleset.

I then disabled the existing DHCP rules. Opened a command prompt and entered "Ipconfig /release", then entered ipconfig /renew. This was one of the alerts.

These entries appeared in Kerio's log.

The 10.x in this log is definitely the rule name, not the IP. Those alerts are standard DHCP broadcasts.
Rick

 

TY Herbalist:

When you have time tell me what I need to do to "fix", "correct" this alert? rule. What use is it to log standard boradcasts? What use is the deny rule this high up in the list? Did BZ error? More likely something I did in the rule set.

For now I'll leave my rules alone.

The only "new" things are the generic services keep regenerating attempts, I keep denying them and my list of denies of this group grows longer and longer.

 

Escalader, See PMs. I need info that doesn't need to be in an open post.
Rick

Once this is sorted out, we can address those generic services, figure out what each is for and block whatever isn't necessary. A few rules for services is normal but it shouldn't be a constantly growing list.

 

On the XP box I added that extra rule to, I went to the top of the ruleset to make sure that it was the first rule that was applied. I was working with an existing ruleset and didn't want to cause myself other problems. If I remember, you were using ruleset 29.2 when you first posted those logs? In that ruleset, the 10.x bypass rule was the first rule in the ruleset that covered TCP/UDP and wasn't specific about port numbers or applications. The rules above that were either for specific ports or single applications, not a general system rule.

BZs rulesets contain rules for several different types of setups. The user has to choose the ones that match what they use. On a network that uses DHCP throughout, DHCP broadcasts are normal. If the IPs on that same network are all static, those broadcasts are suspicious as DHCP shouldn't be in use. By logging the broadcasts, the log entries become a configuration tool that will contain the IPs for more specific rules that match your system.
Rick

 

Thanks, Rick:

I have the PM's, will work on them today and probably tomorrow as time permits.

I shouldn't have said constantly growing!

I meant I started out with certain services disabled and zero services rules.

Now I have about 6 attempted services access all of which had ip's and I have blocked them all and consolidated those blocked rules into 4 using ip ranges to do it. Here is their whois information.

1st set is:

OrgName: Akamai Technologies ( my ISP MAY use these for email servers)
OrgID: AKAMAI
Address: 8 Cambridge Center
City: Cambridge
StateProv: MA
PostalCode: 02142
Country: US

NetRange: 72.246.0.0 - 72.247.255.255
CIDR: 72.246.0.0/15
NetName: AKAMAI-ARIN-1

2nd set is:

OrgName: WV FIBER LLC ( this one looks suspicious)
OrgID: WFL-9
Address: 315 Wilhagan road
City: Nashville
StateProv: TN
PostalCode: 37217
Country: US

NetRange: 66.216.0.0 - 66.216.63.255

3rd set is:

OrgName: Microsoft Corp ( no need for them to talk to me today!
OrgID: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US

NetRange: 207.46.0.0 - 207.46.255.255
CIDR: 207.46.0.0/16
NetName: MICROSOFT-GLOBAL-NET
NetHandle: NET-207-46-0-0-1
Parent: NET-207-0-0-0-0
NetType: Direct Assignment
NameServer: NS1.MSFT.NET
NameServer: NS5.MSFT.NET
NameServer: NS2.MSFT.NET
NameServer: NS3.MSFT.NET
NameServer: NS4.MSFT.NET

 

Ah so! I have not made those BZ distinctions! That is an error on my part!

Needs fixing!

When you say

.


Do you mean my network from the dsl cable in or the ISP's huge network?

I think you mean my network but I've never been a network guy!

Here is my set up:

wall>Dsl cable>ISP modem> Alphashield H/W FW> Linksys Ethernet Cable/DSL Router>PC#1 and PC#2 both sharing the ISP service through the router.

 

I was referring to your network, which is everything from the modem inward. It's quite possible that you have several NAT devices there. Many DSL/cable modems are combination units that use NAT and DHCP. Looking at the Alphashield page, they mention a 1 minute setup for non-tech users, which makes me believe that it's using DHCP as well. Not sure on the Linksys router.

It's entirely possible that you could have up to 3 layers of NAT in that network, all using DHCP to assign addresses. Could you PM the model number of the router, the version of Alphashield you're using (home or professional edition), and the make/model of your modem? It'll be tonite at the earliest before I can go thru this. I've got a big job outside that will take all the daylight hours for a few days. Need to get it done while the weather still permits.
Rick

 

Will do. The Alphashield product specs say the device does NOT

1) assign ip addresses
2) does not translate addresses

But does:

3) support the following Protocols, TCP/IP,FTP,UDP,HTTP,TFTP,IMAP,DNS,DHCP
4) INSPECTS Packets using RPA

 

This rule should only block outbound to IP range 10.0.0.0<->10.0.0.255, and block any inbound from that same IP range. Nothing more.

A typical boot DHCP broacast, which will be made to the Internet broadcast address.

An Internet outbound broacast should not be blocked by that "10.*" rule. It is why I asked for the rule to be split, in case the logging was incorrect, and possibly blocking inbound broadcasts from the 10.0.0.0<->10.0.0.255 range.

Internet broadcasts from the PC should not be blocked with such a rule. (the only outbound broadcast that should be blocked, would be to 10.0.0.255)

 

It would not work like that. External DHCP broadcasts will not pass in through a router to the internal private network.

 

Stem/Rick:

I sent under separate cover, my LAN set up. Apart from my AlphaShield, there are millions of setup identical to mine over here.

Stem, you have a different view than Rick, I did the split and the log shows a whole host of OUTBOUND attempts see attached jpg. ( whoops it was too large to upload) I cleared it and will have to wait a bit for it. I will post this without the log. Reboot return to thread and post the log.

What now?

I ran all real time AV's and on demand ASW scanners in safe mode nada, ThreatFire finds zip in real time>

Would there be any value in popping in a different FW for a bit to see if the same issue/symptom occurs?

 

It is looking more like a bug/problem with Kerio.

 

I have downloaded a last old version of Kerio 4.2, it seems to have a HIPS in it?

What do you think?

Should we fight this bug that will never be fixed, or move on with rules in hand?

I just looked at the log status it remains empty! This log entry shows at boot up time!

 

and

Agreed, it shouldn't have blocked it. When I added that rule to my friends ruleset, that 10.x rule did block outbound DHCP broadcasts. I cleared the log before starting and double checked the other rules to make sure I hadn't missed anything. Their cable modem translates IPs to the 192.168.x range, so nothing there has an IP beginning with "10". When I get back over there, I'm going to load Escaladers ruleset(s) into my friends XP box and try a few more ideas. To start with, I want to disable all of the 10.x rules, then release/renew again and see what turns up in the logs. If this a bug in how Kerio handles broadcasts, I'd expect to see the same type of log entry, except they would be for the "LAN Subnet Bypass 192.168.x" rule, with the rest of the log data staying the same. The one other thing I want to rule out is that 10.xx.xx isn't an IP being used by any of Escalader's other hardware. At the moment, I'm inclined to believe that there is a bug in how Kerio handles broadcast traffic.
Rick

 

Stem,
Is this a bug that's been undocumented until now? As popular as this firewall has been, that would be amazing. As soon as I can, I'll try to check this thoroughly on my friends XP box. They trust me to experiment on their PC. I'll also set up a test configuration here with Smoothwall and set it to use DHCP

Escalader,
Hold off changing to the new version. If this is a bug, it doesn't necessarily mean that you're vulnerable. At the moment, it appears that Kerio is applying a rule when it shouldn't be. In this instance, it's blocking traffic with a rule that shouldn't apply. If this were an "allow" rule, the situation might be different. This will take some time to work thru and determine the extent of the problem, if it really is a bug. At the moment, I'd move your DHCP rules above all the LAN subnet and range rules, since they're the ones that should be handling this traffic anyway.
Rick

 

I cannot see this in "Escaladers" setup:- PC->router->Alpha shield->Modem. The only IP range that should be seen from the PC is that from the router private LAN (192.168.1.1/24)

I will have another look on VM,... but do think this myself.

 

I will hold, as I see zero threat at the moment just possible bug. I will shift my DHCP rules up as you suggest. I want to optimize my rules delete any that are BZ's that aren't relevant so I will have MY rules. Those have value to me no matter what FW we test !


I just powered off and on and have attached a thin log now for you guys to enjoy! It occurs during boot time, as if I clear the log, and run all day no entries occur! I removed the log as it had my ip in error, I need to slow down.

This thread shows much more it seems that my usual slow learning!

If this is a bug do we all get an award!

 

After you shift those rules, reboot and see if that stops more log entries from appearing.
Rick

 

Okay, rules shifted, rebooting now.