KERNUN release 3.13 RELEASE NOTES ================================= KERNUN release 3.12.3-h1 RELEASE NOTES ====================================== General ------- 1/ The update of IDS-AGENT rules now requires a licence with component IPS. 2/ The update of ADAPTIVE-DATABASE rules now requires a licence with component ATC. KERNUN release 3.12.2-h3 RELEASE NOTES ====================================== KERNUN release 3.12.2-h2 RELEASE NOTES ====================================== KERNUN release 3.12.2-h1 RELEASE NOTES ====================================== KERNUN release 3.12.2 RELEASE NOTES ====================================== General ------- 3/ The configuration of ADAPTIVE-FIREWALL has been reworked. In some situations, IDS-AGENT that was in non-blocking mode will be automatically changed to blocking mode by the upgrade script. The mode of IDS-AGENT is now specified solely by item IDS-AGENT.BLOCKING. KERNUN release 3.12.1-h6 RELEASE NOTES ====================================== KERNUN release 3.12.1-h5 RELEASE NOTES ====================================== KERNUN release 3.12.1-h4 RELEASE NOTES ====================================== KERNUN release 3.12.1-h3 RELEASE NOTES ====================================== KERNUN release 3.12.1-h2 RELEASE NOTES ====================================== KERNUN release 3.12.1-h1 RELEASE NOTES ====================================== KERNUN release 3.12.1 RELEASE NOTES ====================================== General ------- 4/ Some SSL/TLS ciphers that were present in 3.11.7 and earlier versions were removed in 3.12 because they became considered weak. Some of them are now added back but they need to be enabled in item SSL-PARAMS.CIPHERS because their usage is not recommended. KERNUN release 3.12 RELEASE NOTES ====================================== General ------- 5/ Configuration of AK47 and IPS has been completely changed and renamed to ADAPTIVE-FIREWALL. Refer to samples/cml/ids.cml for more information. 6/ Log file /var/log/kernun-snort is no longer used by IPS/IDS engine. IPS/IDS engine (which is now called IDS-AGENT) logs to file /var/log/kernun-ids-agent. The old file /var/log/kernun-snort is still being created and rotated so as to preserve records that might have been created there in previous versions. KERNUN release 3.11.7-h3 RELEASE NOTES ====================================== KERNUN release 3.11.7-h2 RELEASE NOTES ====================================== KERNUN release 3.11.7-h1 RELEASE NOTES ====================================== KERNUN release 3.11.7 RELEASE NOTES ====================================== General ------- 7/ Suricata IPS/IDS configuration has been completely changed and renamed to IPS. Refer to samples/cml/ids.cml for more information. 8/ For all interfaces IPS listens on, it is necessary to disable various hardware offloadings by adding flags -rxcsum -tso -toe -lro to ifconfig. Otherwise, IPS will set these flags when starting and unset them when stopping which will cause the interface to be restarted. The disabling can be done by item interface.dev, e.g.: dev em0 media "autoselect -rxcsum -tso -toe -lro"; KERNUN release 3.11.6 RELEASE NOTES ====================================== KERNUN release 3.11.5-h2 RELEASE NOTES ====================================== KERNUN release 3.11.5-h1 RELEASE NOTES ====================================== KERNUN release 3.11.5 RELEASE NOTES ====================================== KERNUN release 3.11.4-h4 RELEASE NOTES ====================================== KERNUN release 3.11.4-h3 RELEASE NOTES ====================================== KERNUN release 3.11.4-h2 RELEASE NOTES ====================================== KERNUN release 3.11.4-h1 RELEASE NOTES ====================================== KERNUN release 3.11.4 RELEASE NOTES ====================================== KERNUN release 3.11.3-h1 RELEASE NOTES ====================================== 9/ Suricata IPS/IDS was upgraded to version 4.1.2. It is recommended to review and update the SURICATA-YAML configuration file referenced by the kernun.cml configuration. See the new sample file in /usr/local/etc/suricata/suricata.yaml.sample. KERNUN release 3.11.2 RELEASE NOTES =================================== KERNUN release 3.11.1 RELEASE NOTES =================================== KERNUN release 3.11 RELEASE NOTES ================================= Statistics / Reporter --------------------- 10/ A new version of the PostgreSQL database server is installed, which is incompatible with a database created by previous versions. Hence the reporter database must be reinitialized and rebuilt by parsing statistical log files. During the first boot after upgrade, a new empty database is initialized. The old database is retained, so it can be used in the case of downgrade. The existence of an old database can be tested by command # reporter_manage test_old_db If downgrade to the previous Kernun installation is not needed, the old database should be deleted by command # reporter_manage rm_old_db After an upgrade and reinitialization of a new database, old (rotated) Kernun statistical log files are moved from /data/log to /data/log/stopped, so they are not automatically parsed and stored in the new database. The administrator should move these logs back by command # reporter_manage start_old_logs when the increased load caused by parsing these log files does not interfere with normal system operation. Configuration / listen-on 11/ The definition of the listen-on.transparent soket by a reference, e.g. listen-on {transparent ^system.LAN.ipv4.host port 443;} is obsolete since now. The definition by the name is recomended, e.g. listen-on {transparent iface LAN version ipv4 port 443;} The reason is better interface management when restarting a proxy. The conversion script makes the right substitution in the configuration during the upgrade procedure, further uses of reference definitions are not corrected however. The listen-on.non-transparent definition is not affected. KERNUN release 3.10.4-h1 RELEASE NOTES ====================================== General ------- 12/ Diskdb configuration files can now import content from other files using syntax: #import /path/to/file This is used in /etc/kernun-fsdb-include, so that custom additions to kernun-fsdb-include can be made in a separate file /etc/kernun-fsdb-include.local. This is prefferable to directly editing /etc/kernun-fsdb-include, as it avoids the need to manually resolve an occasional conflict during upgrade. The administrator should consider moving all custom additions from /etc/kernun-fsdb-include into /etc/kernun-fsdb-include.local. KERNUN release 3.10.3-h2 RELEASE NOTES ====================================== General ------- 13/ The sample configuration file samples/shared/dns-bad-boys-list has been removed in favor of samples/include/dns-dirty-domains.cml. If using this removed file, administrators needs to update configuration of affected machines before (preferably) or during upgrade process. Change: shared-file DNS-BAD-BOYS-LIST { path "samples/shared/dns-bad-boys-list"; format native; } To: include "samples/include/dns-dirty-domains.cml"; And change: dns-proxy DNS { ... ## Some DNS servers break rules request-acl DNS-BAD-BOYS { query-name { < DNS-BAD-BOYS-LIST }; query { A } resolve ROOT-SERVERS; reply { * } permit; ignore-void-rr; ignore-missing-aa; accept; } ... } To: dns-proxy DNS { ... ## Some DNS servers break rules request-acl DIRTY-DOMAINS { query-name { $dns-dirty-domains }; query { * } resolve ROOT-SERVERS; reply { * } permit; ignore-void-rr; ignore-missing-aa; accept; } } Please refer to samples/cml/dns-proxy.cml for more information. 14/ The SSH RSA host key for the Kernun machine may change with upgrading to 3.10.3-h2 or above. This affects the administrator when connecting to Kernun using ssh or GUI. In this case the known_hosts file must be corrected manually according to the hint printed by ssh. This issue also can influence the application of the configuration if it is not applied locally (i.e., it is applied from one cluster member to another). In this case the known_hosts must be corrected manually on the Kernun machine FROM WHICH the configuration application is performed according to the hint printed by ssh/gui. KERNUN release 3.10.2 RELEASE NOTES =================================== General ------- 15/ Since this version, the behavior MIME-TYPE recognition has changed. application/octet-stream is now reported for documents with unrecognizable mime-type. Moreover, if MAGIC recognition method returns application/octet-stream, it is considered as unrecognized and the next recognition method is used. KERNUN release 3.10.1 RELEASE NOTES =================================== General ------- 16/ Since this version, reporter engine silently removes old records from the database to free up disk space when needed (see KERNUN-CHANGES). Check free space on /data partition before upgrade. If lower than 30%, be aware that some of the oldest records in the reporter database are likely to be deleted after upgrade which can result in missing data for monthly statistics. KERNUN release 3.10 RELEASE NOTES ================================== General ------- 17/ Since this version, Kernun automatically sets on the rc.conf variables gateway_enable="YES" ipv6_gateway_enable="YES". They still only take effect for the traffic tagged NOTRANSP in packet filter (given that sysctl net.inet.ip.transparency=1). This behavior can be overriden in the system.sysctl section of the configuration file. KERNUN release 3.8.5 RELEASE NOTES ================================== Known issues ============ General ------- 18/ Since Kernun 3.8.2 conflicts between new distribution versions and backup versions of /etc/master.passwd files and /etc/group files are checked by automatic script and merged properly. This feature will take effect since upgrading from Kernun 3.8.2 and later versions. If you come across to such a conflict now, you can try to use the automatic merging script manually. This can be done by copying newer version of 'sysmgr' and 'kernun.subr' scripts to current system using the following sequence of commands (WARNING: it supposes that a new Kernun 3.8.2 is installed on partition 2, change appropriate paths if different partition has been used for installation): mount /dev/da0s2a /2 cp /2/usr/local/kernun/lib/kernun.subr /usr/local/kernun/lib/kernun.subr cp /2/usr/local/kernun/bin/sysmgr /usr/local/kernun/bin/sysmgr sysmgr merge_users_groups / /2 If upgrading from the Kernun GUI, these commands should be executed after the GUI reports conflicts in /etc/master.passwd and/or /etc/group. Then choose to use the distribution files as the conflict resolution. 19/ Ensure that the system files resolv.conf, dhcpd(6).conf, hosts, ipsec.conf, racoon/*, krb5.conf, periodic.conf and pf.conf are not maintained manually. If they are, please migrate their configuration into kernun.cml. As they are generated regardless of presence or absence in the kernun.cml since Kernun 3.8.1 (see KERNUN-CHANGES), they would be effectively removed if not configured in kernun.cml. 20/ When upgrading to KERNUN 3.8 from a previous release, consider converting the /var/log/kernun into /var/log/kernun-debug and /var/log/kernun-stats. Since release 3.8, the statistics are generated from the kernun-stats file. If the statistics are to be generated properly, at least the relevant logs (i.e., cca last 30 days) should be converted. To convert the logs, follow this procedure: a) Upgrade the system normally, reboot it to the new version b) Ensure that all the constraint of the conversion scripts are met (see output of convert-logs.sh -h, section Constraints) c) Delete files /var/log/kernun-{stats,debug}.*.bz2 if they exist d) Run convert-logs.sh -c in order to convert the current /var/log/kernun e) Restart the syslog daemon (/etc/rc.d/syslogd restart) f) Convert the old logs in several cycles, depending on their size. Keep in mind that this operation can be time consuming depending on he log size. Be sure that the log rotation does not happen during the log conversion. In several turns run convert-logs -a . This command takes newest logs and converts them to the new format. g) Remove the remaining /var/log/kernun.*.bz2 files if they are not to be converted. 21/ KERNUN release 3.7 should be run on a FreeBSD 8.3-RELEASE or a patchlevel marked 8.3-RELEASE-p*. We strongly discourage running it on any other operating system version. 22/ The only recommended and supported way of Kernun installation is from the bootable USB flash drive or by the installer (sysmgr or GUI) in a running Kernun system. 23/ For correct inter-version configuration conversion, the CHROOT-DIR items within proxies must precede all 3rd level ACLs (DOC-ACLs and MAIL-ACLs). 24/ 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. 25/ 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. 26/ 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. 27/ 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. 28/ In Kernun 3.0 and newer, the installation and upgrade procedures have been completely redesigned. See the Kernun Handbook for details. 29/ 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. 30/ 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. 31/ 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. 32/ 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. 33/ 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. 34/ 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. 35/ 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 36/ Protocol VRRP is replaced by the implementation of CARP protocol in FreeBSD. See carp(4) manual page for more information. 37/ 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. 38/ 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 --------- 39/ 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. 40/ Also, ftp-proxy does not implement FTP security extensions (see RFC 2228). Http-proxy ---------- 41/ 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. 42/ 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", * } ... } ... } 43/ 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 --------- 44/ 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; } ... } 45/ 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 ----- 46/ If NOD32 antivirus engine (nod32lms-2.15) should run on the firewall machine, port misc/compat4x is required.