DAMC 4.2.x, Rweb 4.2.x, sProxy 4.2.x product family will reach End of Maintenance by 2019-12-31 and End of Life in 2020-12-31.
Please visit https://my.denyall.com/cycle-produits.php for further informations.
This document details changes introduced by the 4.2.6 version for DenyAll rWeb.
This version follows version 4.2.5 of DenyAll rWeb. This version is an LTS (Long Term Support).
Official release date
2018, December 12
System : Sync NTP time
A "Synchronize Time " button in the NTP setup now forces an update on the system to sync the clock immediately.
It's especially useful when the system clock has a big difference with the current time and would typically take a long time to sync using the standard time 'drifting' mecanism.
Monitoring : Application healthcheck method selection
In Application/Healthcheck menu, operators can now select the HTTP Method (HEAD or GET) when performing the healthcheck to the backend.
The global Healthcheck setting remains unchanged.
Monitoring : Syslog new Proxy and Legacy mode
Syslog logging now allows the selection between two modes : Proxy (recommanded) and Legacy (for compatibility).
It is recommanded to use the Proxy mode as it enables several benefits over Legacy one such as dynamic port, ipv6 and TCP protocol support.
A Legacy mode remains for compatibility issue in case some troubles are experienced with the default mode.
[DA-9973] - syslog-ng logfile location is "<install_rweb>/logs/syslog-ng.log"
[DA-9737] - Re-enable stunnel trace in syslog
In previous version 4.2.5, the stunnel process logging were shut down to prevent log flooding when connection error occurs but as side-effect it made more complex to debug stunnel related issues.
In 4.2.6 version, the stunnel process logging is re-enabled and customizable through the CoreManager.xml parameter “StunnelDebugLevel" (default = 2), allowing support team to gather debug trace when needed while avoiding log flooding. Increase the loglevel to get more verbosity.
daos10 stunnel: LOG3: writesocket: Connection reset by peer (104)
[DA-9608] - Valid requests rejected by the backend do not generate alerts anymore
Prior to this version, rWeb keep generating alerts even if the request was rejected due to backend reason (414 URI too Long for instance). From this version, no more alerts are generated when the request is rejected by the backend.
[DA-9930] - Automatically adds directives to the Pooling application
In previous version 4.2.5, when activating Pooling Mode, some additionals operations had to be performed :
- To request the application by IP, user must add directive "HttpProtocolOptions unsafe" for the "Polling IN" application.
- To request the aapplication by server name, user must add directive "HttpProtocolOptions unsafe" for the "Poolling IN" application and directive "RequestHeader : set Host <servername of polling in>" for the "Pooling OUT" application.
In 4.2.6 version, these directives are automatically added to the pooling applications, making the pooling application configuration much simpler.
[DA-8209] - Fix Skipping Parameter Analysis
[DA-8734] - Incorrect response code when the request was blocked by XML validation engine
[DA-8735] - Incorrect response code in traffic log when the request was blocked by XML validation engine
[DA-8950] - Fix the time period label in Alert reports
[DA-8953] - CLI accepts NTP Server with domain name
[DA-8976] - Syslog correctly works in IPv6
[DA-9043] - Fix XML "Strip < faultstring >" and "Strip < faultcode >" on some cases
[DA-9093] - Fix ADD action in Header manipulation for HTTP Response
[DA-9101] - Fix Syslog facility
[DA-9105] - Fix Syslog CSV format
[DA-9117] - Fix "Append" action in Header manipulation
[DA-9138] - Fix clear data of "Engine ID" in SNMP
[DA-9231] - Fix incorrect Alert and Traffic log owner on linked applications
[DA-9400] - Fix incorrect behavior for Sslverifydepth check
[DA-9772] - Fix sqlisec engine case consuming max CPU
[DA-9820] - Fix Options in Canonization
[DA-9831] - Allow empty SSLRequireSSL directive
[DA-9854] - Fix nestedsec events catching by Dascript
[DA-9869] - Fix "AuthLDAPRemoteUserisDN" option in LDAP extended mode
[DA-9909] - Fix Log export options
[DA-10008] - Fix application using Websocket backend
[DA-9929] - SNMP server does not work as expected with EngineID
To retrieve the engineID for the client, user must first enter an random engineID on the GUI. After submit, a new ID will be generated in "Generated Engine ID" field . This newly generated engineID can be used in snmp clients.
In the following commands:
- <installation_path> is /opt/rweb on appliances and default installations.
- <patch_name> is the filename of the patch
Caution: if you have modified one of the following files (for performance tuning for example), you will need to keep track of your modifications in order to restore them manually after installing the patch:
cp <installation_path>/bin/init_rweb /tmp/init_rweb.old
cp <installation_path>/admin/conf/CoreManager.xml /tmp/CoreManager.xml.old
cp <installation_path>/admin/conf/httpd.conf /tmp/httpd.conf.old
Caution: if you have installed hotfixes on your current rWeb system, you must uninstall them before installing the cumulative patch. See the README notes of each hotfix for uninstallation instructions.
In order to retrieve which hotfixes have been installed on your system, you can display the following file (see knowledge base reference):
Before you install the patch, we recommend you perform a backup of your installation, as the patcher does not provide rollback.
To do so, you may either:
- Stop the VM and snapshot it (if you run rWeb in a virtualized environment), or
- Perform a backup of the software by logging in the software GUI, clicking "Tools/Admin" and generating a configuration backup. Note: this backup does not include any log (alerts or traffic).
In order for a patch to be applied, rWeb must be stopped.
As support user issue the command below:
sudo <installation_path>/bin/init_rweb stop
Operations are to be performed as support user.
Upload archive in /var/tmp/
Uncompress archive: # tar xzf <patch_name>.tar.gz
Go into patch directory: # cd <patch_name>
Find patch XML file: # ls *.xml
sudo python patcher.py -p <xml_file> -n <installation_path> -v
Restore custom modifications
Once the patch is installed, you may restore your custom modifications by comparing the old and new files using the 2 commands below:
diff <installation_path>/bin/init_rweb /tmp/init_rweb.old
diff <installation_path>/admin/conf/CoreManager.xml /tmp/CoreManager.xml.old
diff <installation_path>/admin/conf/httpd.confml /tmp/httpd.conf.old
and manually inserting your custom modifications in the new files introduced by the patch.
Caution: do not replace the new file by the old one! As each new version may also bring changes in these files, the custom modifications have to be inserted manually in the new files (of the new version).
For instance, if you added memory to tomcat (to boost GUI performance) before patching, by modifying the file /opt/rweb/bin/init_rweb and changing:
export JAVA_OPTS="$JAVA_OPTS -Xms128m -Xmx1024m -XX:MaxPermSize=128m"
export JAVA_OPTS="$JAVA_OPTS –Xms512m -Xmx1024m -XX:MaxPermSize=512m"
you will have to update the new export JAVA_OPTS command in the new /opt/rweb/bin/init_rweb file, which added a java.library.path directive in the new command. It will look like this:
export JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx1024m -XX:MaxPermSize=512m
Once rWeb has been patched and custom modifications are restored, rWeb can be started with the following command (with the support user):
sudo <installation_path>/bin/init_rweb start
Remove temporary files
Once rWeb has been patched, restarted and you checked everything works correctly, you can delete all temporary files created by this patcher by running the following command:
sudo rm –rf <installation_path>/patches/*