Reason: it is impossible to resolve domains of Microsoft from the dns root servers because of their misconfiguration. Domains that suffer this problems are microsoft.com, akadsn.net, windowsupdate.com and maybe more.
Treatment: One possible solution is not to resolve these particular domains from the dns root servers but to forward requests to a different nameserver, probably the provider's. This solution is vulnerable from the dns spoofing attack because dns-proxy relies on the foreign dns server answers.
Example of dns-proxy configuration: (relevant part only)
ns-list NS-ISP { # Define ISP's nameservers
server dns1.myisp.tld { [123.45.67.89] };
server dns2.myisp.tld { [12.34.56.78] };
}
dns-proxy DNS {
...
request-acl MSOFT { # This acl forwards requests to ISP
query-name { microsoft.com, akadns.net, windowsupdate.com };
query { a, mx } forward NS-ISP;
reply * permit;
accept;
}
request-acl RESOLVE { # Default acl. Resolves all requests from ROOT-SERVERS
query * resolve ROOT-SERVERS;
reply * permit;
accept;
}
...
Treatment: Another possible solution is to define fake adresses for unresolvable domain. The disadvantage is obvious: you must keep the IPs up-to-date yourself.
Example of dns-proxy configuration: (relevant part only)
request-acl MSOFT {
query-name { download.microsoft.com };
query { a } fake;
fake 43200 a [195.113.150.6];
accept;
}
Reason: The web server does not comply with standards of HTTP procotol. It is often caused by broken HTTP headers sent from the web server, header duplication, or headers missing at all.
Treatment: Tuning http-proxy(5) can solve some cases, e.g. header-too-long error (the hdr-line-len item).
In some cases the damage of the headers is so serious (e.g. the Content-type header is sent twice with different values, Content-length header missing, or headers completely missing) that it is not possible to parse the HTTP protocol and the web server responce is unable to go through http-proxy.
If you are sure you want to allow such a web server, it is necessary to use tcp-proxy as a "bypass" for that particular web server.
You can also send a request to the development team for enhancing http-proxy funcionality to handle particular broken headers.
As the SESSION-END message of particular connection appears in the kernun log file after the end of the connection, log file does not help in solving this problem. Use monitoring(5) for this purpose.
At first activate monitoring in the proxy configuration:
http-proxy HTTP {
listen-on {
...
}
chroot-dir "/usr/local/kernun/root";
...
monitoring {
comm-dir "/var/monitor";
}
...
}
The file
/usr/local/kernun/root/var/monitor/monitor.HTTP.pid
is created when HTTP proxy starts. Therefore you must reload or restart the HTTP proxy. (Reload is enough because it send a signal to the running proxy to finish up all active connections and then quit, and concurrently starts a new proxy process to handle new incoming connections. Restart kills the running proxy and so all active connections die too, and starts new proxy process.)
The file monitor.HTTP.pid contains binary information about connections the proxy is currently handling. You can gain the information from all the monitor files in the same directory by the monitor(1) program. You likely will want to enable monitoring in more proxies then just in the HTTP. Make sure they all use the same comm-dir and chroot-dir. Monitor program shows top-N connections that are consuming the most of the bandwidth.
Examples:
fw# monitor -d /usr/local/kernun/root/var/monitor/ # gives plain text output
fw# monitor -g -d /usr/local/kernun/root/var/monitor/ # gives html output
Reason: Spammers and spamming robots develop. From time to time a new spamming technique appears which antispam softwares don't detect.
Treatment: It looks like this is neverending fight. The only advice is: keep antispam software up-to-date, use antispam's learning technique and gently tune spam scores in the configuration.
Reason: system performance, quality, servicing.
Server hardware gives you more then a "fast processor". It is more stable, more sufficient, especially on network interfaces (checksum offload), bus (interrupts) etc.
Kernun actually dos not have icmp-proxy. It is planned to 2.5 version. If you want to get ping through kernun in local networks (e.g. between intranet and DMZ) you can use fastrouting in packet filter.
Treatment: Besides plugging the server into UPS unit you can set the fsck_y_enable variable to "YES" in /etc/rc.conf. As the /etc/rc.conf file is generated by KGB (Kernun Generation Base) this variable must be set in kernun.cml:
system MYFIREWALL {
...
rc-conf {
set-env fsck_y_enable YES;
...
}
...
}
Possible reason: The maximum number of children of the process was reached. The number of children of the parent proxy process is currently equal to the value set in tcpserver.max-children (default is 50).
Solution: Raise the value tcpserver.max-children.
In some cases the proxy child process does not end despite that no data pass through the proxy process any more. It happens because the server or the client does not end the tcp connection properly. In this case tune values cl2srv-halfclosed-time, cl2srv-idle-timeout,srv2cl-halfclosed-time, srv2cl-idle-timeout, max-bytes-in, max-bytes-out, max-time in session-acl section.
Solution: There is currently no ntp-proxy in Kernun Firewall. You have two choices: