KERNUN release 3.6.4 RELEASE NOTES =================================== Known issues ============ General ------- 1/ KERNUN release 3.6.4 should be run on a FreeBSD 8.2-RELEASE or a patchlevel marked 8.2-RELEASE-p*. We strongly discourage running it on any other operating system version. 2/ The only recommended and supported way of Kernun installation is from the bootable installation CD or by the installer (sysmgr or GUI) in a running Kernun system. 3/ For correct inter-version configuration conversion, the CHROOT-DIR items within proxies must precede all 3rd level ACLs (DOC-ACLs and MAIL-ACLs). 4/ The libmagic library used for file type detection based on magic numbers calls external utilities for decompressing data compressed by bzip2 or pkzip. To be able to detect types of these compressed files correctly, the proxy must not be run chrooted, that is, the proxy configuration must not contain item CHROOT-DIR. 5/ Upgrade from Kernun older than 3.5-h3: Some networking software that communicates via SSH (for example, WinSCP) inappropriately invokes a login shell and does not command the SSH daemon to create a pseudoterminal. This can confuse the Kernun code for logging contents of user sessions, yielding a process superscript consuming 100% CPU when a SSH connection is closed. In Kernun 3.5-h3, this problem was solved by not starting session logging for sessions that do not run on a pseudoterminal. This fix works for all users in new installations and for user root in upgrades. Users with UID 0 other than root must be fixed by manually copying /root/.profile to their home directories. 6/ Upgrade from Kernun older than 3.3.2: Handling of libmagic data files, used for file type recognition based on data patterns (magic numbers), was changed in 3.3.2. In earlier versions, a proxy that used libmagic needed at least two SHARED-FILE sections in the configuration: one with a path to a "magic" file, referenced by DOCTYPE-IDENTIFICATION.MAGIC, and the second one with a path to a "magic.mime" or "magic.mime.mgc" file, not referenced by a proxy. Since 3.3.2, only "magic.mime" should be specified in the configuration and referenced by proxies. The configuration conversion script executed automatically during an upgrade fixes common cases of magic file configurations. In a rare case of an anomalous configuration, it may be necessary to fix the magic file SHARED-FILE sections manually. 7/ Upgrade from Kernun 3.0 and 3.1: The format of RRD databases used to store data for system graphs was changed. All the files *.rrd in directory /data/rrd/ should be deleted. This will also delete the history of system parameters values. 8/ In Kernun 3.0 and newer, the installation and upgrade procedures have been completely redesigned. See the Kernun Handbook for details. 9/ Upgrade from Kernun Firewall 2.x: a) Backup all files that you want to preserve. At least, keep your /usr/local/kernun/conf/kernun.cml,v. b) Install Kernun 3.X. c) Copy files from backup to the new Kernun system. d) Upgrade the configuration using cml-cnv.sh: # cd /usr/local/kernun/conf; cml-cnv.sh -o kernun.cml This reports names of processed files. e) Review the upgraded configuration (files with .out suffix). f) Move the upgraded files to their original names (those without .out). g) Genarate and apply the new configuration. h) Reboot the system or restart reconfigured subsystems. 10/ Upgrade from Kernun 3.0: The license file format was changed. A new license file (/usr/local/kernun/license.dat) is needed, the old license file from 3.0 will not work. 11/ Upgrade from Kernun 3.0: The format of RRD databases used to store data for system graphs was changed. Files with names like /data/rrd/sys.*.rrd should be deleted. This will also delete the history of system parameters values. 12/ Upgrade from Kernun 3.0 prior to 3.0.4-H1: The format of RRD databases used to store data for CARP graphs was changed. Files with names like /data/rrd/carp.*.rrd should be deleted. This will also delete the history of values of RRD parameters. 13/ Upgrade from Kernun 3.0: In 3.0, system backup and upgrade saved all files from a system partition, except files listed in file /etc/kernun-fsdb-exclude. In 3.1, only files listed in file /etc/kernun-fsdb-include are saved. File /etc/kernun-fsdb-exclude has been removed. 14/ Item SYSTEM.PRODUCT should be specified in the configuration. It defines the type of the target Kernun product where the configuration will be applied. Both CML and GUI warns if the administrator tries to configure a component not available in the target product or not licensed. Standard product specifications are available as section variables defined in file samples/include/products.cml. Item SYSTEM.PRODUCT is also set automatically during initial configuration of a newly installed Kernun system according to the product type and contents of the license file. 15/ IMPORTANT: If for any reason the operating system is rebuilt from the source code, it is required to apply vital operating system patches included with Kernun. This must be repeated every time the FreeBSD source code tree gets updated. After updating FreeBSD by cvsup or another means, run the following commands: # /var/db/pkg/kernun-base/+INSTALL patch # /var/db/pkg/kernun-base/+INSTALL kernel 16/ Protocol VRRP is replaced by the implementation of CARP protocol in FreeBSD. See carp(4) manual page for more information. 17/ When matching destination addresses of transparent connections during initial phase of ACL in proxies, the item `to transparent {...}' may be used. General configuration syntax allows for regular expressions in this case, but when matching IP addresses, regular expressions have no meaning and never match (they are supposed to match against real host names in later ACL phases). Thus, if regular expression is present in an item `to transparent {...}', it will never be used for matching. Currently, no warning message is issued in this case. This issue will be addressed in later releases. 18/ If logging to syslogd is used by a chrooted proxy, syslogd must open an additional socket in the chroot directory. Syslogd is able to open up to 19 additional sockets. If more are needed (because there are more than 19 different chroot directories), it is necessary to enlarge the constant MAXFUNIX in /usr/src/usr.sbin/syslogd/syslogd.c and rebuild syslogd. Ftp-proxy --------- 19/ The ftp-proxy can only perform EPSV, PASV and PORT data connections to servers. EPRT connection from client is always translated to PORT connection to the target server. As for EPSV/PASV, EPSV is always tried first for any passive connection and if it fails (server does not seem to support it), ftp-proxy falls back to PASV. Neither LPRT nor LPSV (see RFC 1639) are supported. 20/ Also, ftp-proxy does not implement FTP security extensions (see RFC 2228). Http-proxy ---------- 21/ It seems that some WWW servers (particularly, MS IIS 5.0) do not authenticate individual HTTP requests as described in RFC2616, but they authenticate connections instead. This is not compliant with RFC2616. Once an authenticated request (Basic authentication) takes place in a connection, all other requests in that connection are considered authenticated by IIS. Moreover, when NTLM authentication is used, all requests must fall into the same connection. To address these issues (and also for bettern efficiency) http-proxy supports persistent connections both from clients and to servers. A persistent connection to a server is always closed when the corresponding connection from a client is closed. Hence, the same connection to the server is never used for requests by the two different users unless the requests by different users are sent by the client on the same connection. Note that when a proxy is explicitly specified in IExplorer, the browser refuses to use NTLM authentication. This means that it will work if and only if the connections from browser are transparent. 22/ If filtering is on, http-proxy sends an Accept-Encoding header to servers to ensure that the encoding will be known to the http-proxy and it will be able to decode and filter documents. However, some servers may answer badly if they receive Accept-Encoding header. The workaround to this issue involves filtering out the Accept-Encoding header from the request. This can be achieved in http-proxy(8) configuration by: http-proxy HTTP-PROXY { ... request-acl { ... allow-req-hdr { ! "Accept-Encoding", * } ... } ... } 23/ Several proxies support communication using SSL/TLS. If SSL/TLS is used on connections from clients to the proxy, the proxy requires a valid SSL server certificate (X.509) and a corresponding private key to run. Although it is possible to generate a dummy self-signed certificate, we strongly recommend to request server certificate from a real Certificate Authority (CA). Follow the instructions of your preferred CA to get certificates for Kernun proxies. Place the certificate and its corresponding private key on the firewall and refer to those files with configuration directive "id" in the "ssl-params" section used for the connections from clients (as specified by session-acl.ssl). Dns-proxy --------- 24/ If dns-proxy is in "query...resolve" mode, it tries hard to get authoritative responses; in fact, it refuses to send unauthoritative responses back to clients. however, some name servers do not return authoritative responses even if they are in fact authoritative. An example of such a domain is mail-abuse.org. which serves to identify possible SPAM (unsolicited commercial e-mail) sources. The workaround to this issue involves definition of a list of name servers authoritative for the mail-abuse.org. domain and let the dns-proxy forward requests for this domain to that list (i.e., not resolve from root servers). This can be achieved in kc(1) configuration: ns-list MAIL-ABUSE-LIST { server NS-EXT.VIX.COM. [204.152.184.64]; server EAST1.MAIL-ABUSE.ORG. [157.22.13.82]; server WEST1.MAIL-ABUSE.ORG. [204.152.184.196]; server EUROPE1.MAIL-ABUSE.ORG. [204.152.186.195]; } dns-proxy DNS-PROXY { ... request-acl MAIL-ABUSE { query-name mail-abuse.org; accept; query a forward MAIL-ABUSE-LIST; reply { a, cname } permit; } ... } 25/ Please note that dns-proxy does not implement A6 queries. BIND named may generate a lot of them when in forwarding mode. Therefore, if a BIND named is configured to forward all queries to Kernun dns-proxy, we recommend the following items to be added to the options section: options { ... forward only; fetch-glue no; ... } NOD32 ----- 26/ If NOD32 antivirus engine (nod32lms-2.15) should run on the firewall machine, port misc/compat4x is required.