I'm not very knowledgable about networking -- I'll say that up front. However, I recently downgraded from Kerio Personal Firewall 4.x to 2.1.5 to speed up my computer. And it worked. (I'm on a college network, I'll mention.) Kerio 2.1.5 has a problem with fragmented packets. My question, then, is how to handle these. There seems to be no consensus about how dangerous this vulnerability is, so I'm not sure just how dangerous the hole is. Still, I'd like to plug it if I can.
One method that's come to my attention is a simple Registry fix: [HKEY_LOCAL_MACHINE\\SYSTEM\\CURRENTCONTROLSET\\IPFILTERDRIVER\\PARAMETERS] "ENABLEFRAGMENTCHECKING"=DWORD:00000001
formatting link
Is this effective? If not, what freeware (preferably) or shareware can I use to help plug the hole that Kerio 2.1.5 has? Something with a light footprint is necessary.
That registry tweak will not really solve the problem. That will keep the OS from processing fragments perhaps, but will not stop Kerio from letting in packet pairs, the first packet being a non-first fragment and then a second right behind it Kerio will let thru. This is what I used to see here some time ago when I used to use Kerio 2.1.5.
The best solution I have seen, if you're determined to keep using Kerio
2, is to run CHX behind it. CHX uses about 3mb ram, is extremely fast and light, runs as a kernel service, rules based packet filter with good SPI and so on. It's free also. Just register at the site and they'll send you a free serial via email within minutes.
Here is the link:
formatting link
Download CHX, also the sample filters, read thru the online docs (important!) and that should get you started. Make sure you turn on SPI for all protocols in the Interface Properties tab, also logging. Modify the sample rule set for any Force Allow rules you might need. If you are familliar with Kerio 2 and rules, then CHX will come naturally to you. It's a little different but also very similar.
When you run CHX with Kerio, you will see crap in the CHX logs that Kerio let's thru, most of it will be due to CHX's stricter SPI, however, you may see an occasional fragmented packet. Kerio will catch most of the traffic first, and CHX gets anything Kerio misses.
I have run CHX with many software firewalls and never once had any issues running them together. Some people will tell you it's not wise to run 2 firewalls, and they are right usually, however, CHX co-exists with them quite well. I have never had any problems when I ran the two together. Many other people have also done so without problems.
If an incoming connection is fragmented Kerio will accept it. Then it will allow all traffic in both directions on that connection. Kerio is supposed to be a packet filter and it can't filter fragmented packets.
Sometimes this registry fix works, sometimes not. To test it create a new rule to block all ICMP and make sure it is the first rule in your list. Then type ping -l 3000 IPaddy This creates an oversized packet that will be fragmented before it's sent through the firewall.
If you use a router this problem should be restricted to your LAN.
With the ability to sync MTU size, there should never be a need for Fragmented Packets. Unconditionally dump them all :) you can even set maxmtu=576 and the issue just goes away.
Ahh, instant understanding. :-) Kerio logs the first packet as _blocked_, then statefully allows the connection. A lot of people still use Kerio because they think a few fragmented packets will do no harm, when only one is needed.
No. Kerio versions up to 2.1.5 are vulnerable, v4.x are not. Tiny is also vulnerable up to 2.1.5 but I didn't test against later versions.
It's very quick to setup using fragrouter. If you already have a nix box or two, the most complicated part is installing Kerio and configuring it for the test.
Does this solve the problem, can someone confirm? I do it anyway... yay :o)
You can use DrTCPIP
1064 is a good size for MTU (1024 for MSS, MSS+40=MTU) Recieve window 8196 (1024x8) Window scaling: No Time stamp: No SACKs: Yes Path MTU Discovery: No BHD: No MD Acks: 3 TTL 128
Many people recommend MSS 1460 (or 1452 for PPPOE) (a VPN needs it to be a bit less) you would need to test your ISP as well with ping and do not fragment.
1024 results in a 3% performance loss, but in my experiance this is more than made up for by a more stable connection (less packet loss etc). It also scales well with the applications which tend to use multiples of 1024 (usually 4096 or 8192) when sending data over the winsock. Someone may be able to improve on my imperfect understanding but this is it... one 8192 packet would go into the winsock and leave the socket as (1024 1024 1024 1024 1024 1024 1024 1024) + 40x8 of headers as opposed to (1452 1452 1452 1452 1452 932) + 40x6 maybe its (1452 1452 1452 1452 1452 (1452, 520 of this last one not used)) + 40x6 (anyone know?)
Some firewalls solved the frag problem by just dropping fragmented packets (a certain internet securities - thay may have improved it :o) Borderware firewall has a bug/feature caused by its OS (BSD, which refuses to accept fragmented packets with the "do not fragment" packet set (which is what Linux does sometimes)) BSD also did not zero the packet info from in stack, so from BSD that 520 could contain anything (not sure if it is fixed). The borderware bug probably exists on many firewalls and setting a 1064 MTU on clients remidies it.
Sorry I meant to say "do not fragment" 'bit' not 'packet', and excuse the spelling :o) I am tired.
To answer my own question it does not work, b/c even if the MTU is set then the fragmented packet is still legal. It is actually more likely to happen.
kerio 2.1.5
small ping (not blocked) Starting ping - Dec 22, 2005 06:46:03 Pinging fileant.com [67.19.96.18].... IP Address RTT(ms) TTL Bytes Received Returned Data: 01234567890123456789
67.19.96.18 291 46 20 Returned Data: 01234567890123456789
67.19.96.18 282 46 20 Returned Data: 01234567890123456789
67.19.96.18 283 46 20 Returned Data: 01234567890123456789
67.19.96.18 283 46 20 Returned Data: 01234567890123456789
67.19.96.18 283 46 20 Ping Successful
5 packets received out of 5 packets transmitted : 0% PACKET LOSS Round Trip Time (in milliseconds) Max/Min/Av: 291/282/284
small ping... (blocked and logged by kerio) Starting ping - Dec 22, 2005 06:46:37 Pinging fileant.com [67.19.96.18].... IP Address RTT(ms) TTL Bytes Received TIMED OUT TIMED OUT TIMED OUT TIMED OUT TIMED OUT Ping Unsuccessful
0 packets received out of 5 packets transmitted : 100% PACKET LOSS
big fraged ping.. (set to block but not logged by kerio) Starting ping - Dec 22, 2005 06:47:52 Pinging fileant.com [67.19.96.18].... IP Address RTT(ms) TTL Bytes Received ERROR - UNKNOWN REASON ERROR - UNKNOWN REASON ERROR - UNKNOWN REASON ERROR - UNKNOWN REASON ERROR - UNKNOWN REASON Ping Unsuccessful
0 packets received out of 5 packets transmitted : 100% PACKET LOSS
The not logged by kerio seemed to wait for a while each time but the server did not respond back, I would say it went through kerio though.
They have still allowed it's download all this time, and refused to inform users of the problem. Considering the severity of the problem, they should have informed their users years ago.
KPF 2.x and 4.x have just been bought by another company
formatting link
who still plan to distribute 2.1.5. I don't know if they are aware of the problems.
To control an application, you need concepts like BSDs jail(), like virtualization or like application control with SELinux.
For Windows, you need virtualization for everything, which is attached to a desktop, for the reasons mentioned. So with virtualization technics, you could control an application on Windows, too, but only with such technology.
It is not possible to prevent tunneling at all, with the exception to stop connectivity. Not on any system, because this is not possible already in theory.
As an answer on your question:
It would not be possible to do it like breakout does it on a usual X11 desktop, if X11 security extensions are enabled and used. There is a concept with X11, which lets you open windows, which can be controlled, or lets you open windows, which cannot be controlled by other processes.
I've got it running, but do I need to set it in anyway? I have Kerio 2.1.5, so I really don't need XP's firewall doing more than blocking fragmented packets, do I? Sorry, I'm not familiar with such things (obviously). I just don't want Kerio and the XP firewall to clash, or the XP firewall to step on Kerio's toes. Thanks.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.