How to Optimize Security in Kerio 2.1.5 -Learning Thread 3

[Escalader]

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

Originally Posted by herbalist

I have a total of 80 rules. I'm not aware of a limit on the number of rules Kerio can handle. If there is a limit and if you're approaching it, you could combine a lot of the rules you have. When I get a chance, I'll edit the last ruleset you sent over and send it back with a text file explaining what I changed. One quick way to cut out a few rules would be with your ICMP rules. You have 5 blocking rules and no allow rules for ICMP. One blocking rule could do the same thing. Your 2 Peer Guardian rules are identical except that one allows and one blocks. The blocking rule serves no purpose when the first rule allows all IP addresses. Several of your SVCHOST rules are for single IPs with no port/protocol limitation. Some of them could be combined by using an IP range. Eventually you can remove the network rules that are for LAN IP ranges that don't apply to your system.

I'm pretty sure that he had no rules permitting any DHCP active at the time, only a single blocking rule "Unrestricted DHCP" with no IP restrictions, local port 68, remote port 67, both directions. This rule was located 5 rules below the 10.x rule.
I think we're just reading the log differently. You appear to be reading 10.x as the local IP while I'm reading 10.x as the rule name and "localhost" as the local IP. If you look at the other entries in Kerio's log, they all use the same syntax:

[Date and time] rule '(name of rule)' action: direction protocol, (source IP:port#)->(destination IP:port#), Owner:  

The other outbound log entries show "localhost:port number" as the source IP. I read the 10.x entries as "localhost:port 68"->"broadcast:port 67".

It wouldn't take much to find out. If using IPCONFIG to release and renew results in more of those log entries, the question is answered. If it does, I'd be interested to see the resulting firewall alert for this with that 10.x rule disabled.

If I understand this correctly, a DHCP broadcast is sent to all LAN IPs, which would include 10.x IPs. Looking at the ruleset Escalader sent, the "LAN Subnet Bypass 10.x" blocking rule is the first rule in the ruleset for outbound TCP/UDP that is not application or port specific. Did Escalader send you a copy of this ruleset? I believe he was using the one he named 29.2 when these log entries were made. I'm beginning to suspect that Kerio has a bit of a problem with how it applies rules to outbound broadcasts.
Rick

[Escalader]

Originally Posted by herbalist

The IP ranges used for private IPs are not assigned to or used by sites on the net. Private IPs are used on local networks. They belong to whoever owns that network. Private IPs are not directly accessible from the net. Your modem/router translates your public IP (provided by your ISP) into your private IP, chosen by you and determined by the settings you use in your router. Unlike internet IPs, private IPs aren't exclusive. Many networks use the same private IPs but have different public IPs. All the IPs on your local network are owned by you. Yes, you can block local IPs, just like you can block any other internet IP. Blocking local or private IPs prevents different parts of your own network from communicating with each other.
Rick

Rick/Stem:

What about this log packets to unopened ports setting?

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

[Escalader]

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.

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

[Escalader]

Originally Posted by Stem

Hi Escalader,
I am still curious about this block from 10.* (broadcast). I can understand "Rick" putting forward this as possibly unresolved DHCP, but I have never seen such a broadcast from an unresolved (I would expect to see such a broadcast from a private IP range only for DHCP renew). I have been trying to recreate such an event. But up to now, I only see what I have seen before (such as unresolved DHCP NIC defaulting to IP`s such as 169.*. The IP being the same each time no successful DHCP boot is made).
You have mentioned another PC on LAN, is this using a VM (example: Virtualbox will use private network 10.* when setup for NAT,.. broadcasts (255.255.255.255) from this will go through the host if allowed). Just really thinking out load at the moment, as the (log) event we see for this could actually be a blocked inbound.

What you could do, when you have time, is to split the block 10.* rule, so that one rule blocks outbound, and one blocks inbound. We would know for sure the direction of this broadcast (if attempted again)

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

[Escalader]

Originally Posted by herbalist

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.
Attachment 194043
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.
Attachment 194045
These entries appeared in Kerio's log.
Attachment 194044
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

[Escalader]

Originally Posted by herbalist

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.

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

[Escalader]

Originally Posted by herbalist

.....

BZs rulesets contain rules for several different types of setups. The user has to choose the ones that match what they 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

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

Needs fixing!

When you say

Originally Posted by herbalist

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

.


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

[Escalader]

Originally Posted by herbalist

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

[Stem]

Originally Posted by herbalist

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.
Attachment 194043

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.

Originally Posted by herbalist

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.
Attachment 194045

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

Originally Posted by herbalist

These entries appeared in Kerio's log.
Attachment 194044

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.

Originally Posted by herbalist

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

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)

[Stem]

Originally Posted by herbalist

It's entirely possible that you could have up to 3 layers of NAT in that network, all using DHCP to assign addresses.

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

[Escalader]

Originally Posted by Stem

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?

[Stem]

Originally Posted by Escalader

I did the split and the log shows a whole host of OUTBOUND attempts

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

[Escalader]

Originally Posted by Stem

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!

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.

and

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)

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

[Stem]

Originally Posted by herbalist

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.

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)

Originally Posted by herbalist

At the moment, I'm inclined to believe that there is a bug in how Kerio handles broadcast traffic.

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

[Escalader]

Originally Posted by herbalist

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

[Escalader]

Originally Posted by herbalist

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

Okay, rules shifted, rebooting now.