UpgradesRelease notice for Ingate Firewall® 4.3.4 and Ingate SIParator® 4.3.4
Release name: |
Ingate Firewall® 4.3.4
Ingate SIParator® 4.3.4 |
The new version can be found here
Security improvements
* A kernel deadlock issue has been fixed. [Tracking ID: 2447]
Fixed SIP-related problems
* A problem related to unsupported URI schemes has been fixed. [Tracking
ID: 2467]
* Problems related to setup of media streams between a B2BUA server on
the Internet and a client on the LAN behind the Ingate have been
fixed. [Tracking ID: 2412]
* Problems related to media setup in scenarios with a B2BUA SIP server
that uses re-INVITE to perform media shuffle have been fixed.
[Tracking ID: 2468]
* A bug causing the blacklist interval timer to malfunction has been
fixed. [Tracking ID: 2419]
Other fixed problems
* Unnecessary updates of flash memory has been removed. This applies to
Ingate Firewall 1180, 1200 and 1880 as well as Ingate SIParator 18, 20
and 88. [Tracking ID: 2452]
* An issue related to using QoS features together with PPPoE has been
fixed. [Tracking ID: 872]
* Applying the configuration is now faster, especially in configurations
with IPsec tunnels. [Tracking ID: 2409]
* An issue related to NATing statically routed networks has been fixed.
[Tracking ID: 2353]
* An issue preventing import of private certificates in PEM format has
been fixed. [Tracking ID: 2424]
Known problems
Known security problems
* A vulnerability for XSS exploits have been found.
The security cookie used for accessing the web interface of the
product may be stolen and used for logging in to the product from a
host or network configured to be accepted for configuration.
The attack requires knowledge about the IP address of the Ingate
product in use. The administrator must be tricked to follow a link on
a malicious web site using the same client and browser he or she uses
for accessing the Ingate product. This may enable the malicious site
to steal the cookie without the administrators notice. The timing of
the theft is critical, since the security token has a limited lifetime
of 10 minutes. The administrator must follow a link on the malicious
site within 10 minutes after accessing the Ingate product, or the
attack will fail. [Tracking ID: 2174]
Workaround:
To minimize the risk of this happening Ingate recommends that access
control setup in the Ingate product is kept as tight as possible. Only
internal networks, trusted VPN tunnels or specific IP addresses should
be allowed to configure the Ingate product. Additionally it is
important to always log out before accessing other sites.
Known VPN-related problems
These problems are only relevant if IPsec or the built-in PPTP server is
used.
* Packets with a destination address that belongs to either end of a
tunnel will appear to be encrypted in the log, even when they should
not be encrypted. This is a problem with the log only. [Tracking ID:
46]
* The local endpoint must be chosen so that it is the address closest to
the next-hop router for that peer. This means that mobile clients must
always connect via the same interface (typically the interface
connected to the Internet). [Tracking ID: 508]
* In order to properly remove an IPsec CA the firewall needs to be
rebooted. [Tracking ID: 1178]
Workaround:
Disable all IPsec peers and apply the configuration. This will clear
all previous IPsec state. Then enable the peers and apply the
configuration again.
Known SIP-related problems
These problems are only relevant if the SIP module is enabled.
* The SIP module may block while it waits for RADIUS authentication.
This effectively means that only RADIUS servers located on a LAN
should be used. Additionally the RADIUS server should preferably not
enable any brute force attack prevention mechanism that delays the
response in case of a faulty username/password combination. [Tracking
ID: 1425]
* Selecting transport '-' in Static Forwarding should mean that standard
procedures are followed to determine transport but currently means
same as selecting 'UDP'. [Tracking ID: 2043]
* SIP accounts available with the Advanced SIP Routing module do not
handle media correctly in cases where media passes the Ingate.
[Tracking ID: 2334]
Known Failover-related problems
This problem is only relevant if failover is used.
* Upgrading a failover team is a complex operation. To upgrade it, you
must break the team and upgrade each machine in turn. This will
require a number of reboots and network outages. See the separate
failover upgrade document which is available on the upgrade web.
[Tracking ID: 499]
|