Reference12r1:Concept Reverse Proxy: Difference between revisions
(8 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[Category: Concept|Reverse Proxy]] | [[Category:Concept|Reverse Proxy]] | ||
[[Category:Concept_Reverse_Proxy]] | |||
The Reverse Proxy is a software module, which is available on innovaphone gateways. It is designed to allow safe access to services of the innovaphone PBX from the public internet. To accomplish this the gateway must be accessible from the public internet either by NAT port forwarding, or directly. The reverse proxy forwards traffic to configurable destinations. | The Reverse Proxy is a software module, which is available on innovaphone gateways. It is designed to allow safe access to services of the innovaphone PBX from the public internet. To accomplish this the gateway must be accessible from the public internet either by NAT port forwarding, or directly. The reverse proxy forwards traffic to configurable destinations. | ||
The access to internal destinations can be limited in several ways and algorithms to detect attacks are implemented, which are used to put ip addresses into a blacklist. | The access to internal destinations can be limited in several ways and algorithms to detect attacks are implemented, which are used to put ip addresses into a blacklist. | ||
Line 127: | Line 128: | ||
The general format is | The general format is | ||
<syntaxhighlight lang="cpp"> | |||
struct { | struct { | ||
word - offset H.323 mappings | word - offset H.323 mappings | ||
Line 136: | Line 137: | ||
byte [] - Mappings | byte [] - Mappings | ||
} | } | ||
</syntaxhighlight> | |||
;offsets: The offsets are a byte offset into the var content to where the mappings info is stored | ;offsets: The offsets are a byte offset into the var content to where the mappings info is stored | ||
;hostname: A variable length zero terminated hostname | ;hostname: A variable length zero terminated hostname | ||
Line 142: | Line 143: | ||
For the mappings the following structure is used: | For the mappings the following structure is used: | ||
<syntaxhighlight lang="cpp"> | |||
struct { | struct { | ||
IPaddr addr; | IPaddr addr; | ||
Line 155: | Line 156: | ||
char path[]; | char path[]; | ||
}; | }; | ||
</syntaxhighlight> | |||
;addr: The destination IP address, as IPv6 address. If the destination is IPv4 the mapped IPv4 format is used (::ffff:<IPv4>) | ;addr: The destination IP address, as IPv6 address. If the destination is IPv4 the mapped IPv4 format is used (::ffff:<IPv4>) | ||
;port: The port used for TCP | ;port: The port used for TCP | ||
Line 165: | Line 166: | ||
:;MAP_DEFAULT - 4: Default path for a given host | :;MAP_DEFAULT - 4: Default path for a given host | ||
;path: A zero terminated path | ;path: A zero terminated path | ||
;ext1, ext2, ext3: Fields | ;ext1, ext2, ext3: Fields reserved for extensions. With these fields, the mapping header is an even 32 bytes | ||
; next : is the offset in bytes from the beginning of this map to the beginning of the next one. It must be 0 for the last map for a host | |||
If nets is set the following structure is used at the indicated offset: | If nets is set the following structure is used at the indicated offset: | ||
<syntaxhighlight lang="cpp"> | |||
struct { | struct { | ||
word count; | word count; | ||
Line 177: | Line 179: | ||
} net; | } net; | ||
} | } | ||
</syntaxhighlight> | |||
;count: Number of networks in the list | ;count: Number of networks in the list | ||
;spare: Used for 4 bytes alignment | ;spare: Used for 4 bytes alignment | ||
Line 215: | Line 217: | ||
== Known Problems == | == Known Problems == | ||
[[:Category:Problem_Reverse_Proxy|Known Problems]] |
Latest revision as of 22:20, 20 November 2023
The Reverse Proxy is a software module, which is available on innovaphone gateways. It is designed to allow safe access to services of the innovaphone PBX from the public internet. To accomplish this the gateway must be accessible from the public internet either by NAT port forwarding, or directly. The reverse proxy forwards traffic to configurable destinations. The access to internal destinations can be limited in several ways and algorithms to detect attacks are implemented, which are used to put ip addresses into a blacklist. The reverse proxy supports H.323, SIP, HTTP and LDAP over TCP or TLS.
Configuration
The reverse proxy only accepts any connections on the supported protocols, if the port numbers for these protocols are configured. The well-known port numbers or non standard port numbers can be used for these protocols.
A timeout may be configured until which an entry in the blacklist is removed automatically.
A threshold suspicious requests per minute can be used to tune detection of attacks.
Forwarding to internal destinations is based on the addressed host. For this the received requests are analyzed and for each supported protocol different elements are used to identify the addressed host.
Basic Operation
Connections are accepted on the configured port. The received protocol is analyzed to determine the addressed host and a internal connection is established to this host. If the incoming connection is TCP for the internal connection TCP is used as well, if the external connection is TLS, for the internal connection TLS is used. If only TCP or only TLS is configured for the internal connection it is used regardless if the incoming connection was TCP or TLS.
If the Check Certificate checkmark is set, for the internal connection TLS is used only if the received certificate matches the user name within the protocol. This way a host receiving a request through the Reverse Proxy using TLS can assume that the connection was authenticated using a valid certificate, which matches the user.
Access to a configured protocol may be limited to certain networks. This is done by configuring a list of networks in a addr:mask form.
H.323
For H.323 registrations, the gatekeeper identifier received in GatekeeperRequest or RegistrationRequest messages is matched to the Name configured for the host. Only H.323 over H.225 (H.450-17) is supported.
For calls without registration a destination in the for <user>@<domain> is expected. <domain> is matched to the Name configured for the host. This can be used for H.323 open federation.
SIP
For SIP registration the domain part of the FROM header of a REGISTER message is matched to the Name of the configured host.
Also SIP INVITE messages are forwarded by the Reverse Proxy, if the FROM URI matches with the configured host.
HTTP
For HTTP requests the host header is matched to the Name of the configured host. If within a single TCP/TLS connection requests are sent to different hosts, the outgoing connections are terminated and for the request to the other host a new connection is established.
The path which may be accessed can be restricted, by configuring the allowed path. If the pass is configured with a trailing '/' no access to folders inside this path is allowed.
LDAP
For LDAP the LDAP_BIND message is analysed. A user in the form <domain>\<user> is expected and the <domain> is matched to the domain part of the name of the configured host.
Attack detection
Attacks are detected based on the frequency of unsuccessful requests. If more then a configured number of such requests are received within a sliding window of 1min the originating IP address is put into the black list.
To provide some indication about current suspicious requests a list with the the 10 remote IP addresses with the highest number of requests is displayed.
Blacklist/Whitelist
A blacklist/whitelist mechanism is used to block IP addresses or grant access to IP addresses regardless of attack detection. An entry into list can be configured with a timeout, so that it will be removed after the timeout automatically. Entries generated by the attack detection use the configured timeout.
A blacklist entry can be easily changed to a whitelist entry by setting the whitelist checkmark.
Reverse Proxy with innovaphone PBX
The innovaphone PBX has some features implemented especially for integration with the Reverse Proxy.
Controlling Authentication
On the innovaphone PBX up to 8 Reverse Proxies can be configured which are used to forward requests to the PBX. A Reverse Proxy is identified by its IP address. Optionally a certificate name can be configured for a Reverse Proxy, to verify that the connection really sent by the Reverse Proxy and not just relayed by some other equipment.
Registrations through a Reverse Proxy are only accepted if the Reverse Proxy flag at the destination device is set. This way no unexpected registration is possible. When the Assume TLS checkmark is set, a registration received from the Reverse Proxy via TLS is assumed to be authenticated with a proper TLS certificate on the Reverse Proxy already. So no further authentication is required on the PBX. Such a registration is accepted also if TLS Only is set on the device. If a registration from the Reverse Proxy is received via TCP password authentication is required.
Support for multiple Slave PBXs
To address a specific Slave PBX through a Reverse Proxy, a GK-ID with the format <domain>/<location> can be used. A PBX ignores anything in the GK-ID after the '/'. This way in the Reverse Proxy for each slave PBX sharing all the same domain a separate host entry can be configured.
On the phone this format can be used to address the correct destination PBX.
If the registration redirect mechanism shall be used, so that all client can share the same configuration, normally the PBX redirects to the IP address of the correct slave. In this case this does not work since from the public internet the internal addresses are inaccessible, so DNS Names must be configured on all PBXs. In the external DNS these DNS names must all be resolved to the Remote Proxy. The PBX changes the redirect GK-ID to contain the new location in the above format.
The physical location of the phone in case of redirection is the PBX to which the first registration was made. The PBX uses the <physical-location>@domain... format of the GK-ID on redirection.
Physical location and registration PBX can be configured manually on the phone by using a GK-ID of <physical-location>@domain/<registration PBX>
Support for Standby PBXs
To address different PBXs for the primary and the alternate registration different GK-IDs have to be used for the primary and alternate (standby) PBX in the form of <domain>/<location> with a different location for primary and alternate. This way in the reverse proxy different host entries can be configured to address the active and standby PBX. To configure this on innovaphone endpoints a GK-ID in the form <domain>/<primary>:<alternate> can be configured. For the primary registration <domain>/<primary> and for the alternate registration <domain>/<alternate> is then used.
Configuration Items used
Command line arguments
The reverse proxy uses the following command line arguments (the arguments found on the "config change REVERSE-PROXY" line:
- /h323 <port>
- The H.323/TCP listening port
- /sip <port>
- The SIP/TCP listening port
- /ldap <port>
- The LDAP listening port
- /http <port>
- The HTTP listening port
- /h323s <port>
- The H.323/TLS listening port
- /sips <port>
- The SIP/TLS listening port
- /ldaps <port>
- The LDAPS listening port
- /https <port>
- The HTTPS listening port
- /expire <mins>
- The blacklist expiration timeout in minutes
- /threshold <num>
- Number of suspicous requests per minute, which causes a blacklist entry
- /public-nat-addr <ip-address>
- The public address of the NAT router, which forwards the requests to the RP. Needed for SIP, so that the correct address for further requests can be provided
- /log-http-rej
- Log rejected HTTP requests
- /log-http-fwd
- Log forwarded HTTP requests
- /log-ldap-rej
- Log rejected LDAP requests
- /log-ldap-fwd
- Log forwarded LDAP requests
- /log-sip-rej
- Log rejected SIP requests
- /log-sip-fwd
- Log forwarded SIP requests
- /log-h323-rej
- Log rejected H.323 requests
- /log-h323-fwd
- Log forwarded H.323 requests
VARS used for Host definitions
The name of the VARS for host definitions is formed as follows:
RPRXY/H<FNV-1a Hash of Hostname>/<sequence>
- FNV-1a Hash of Hostname
- The hash is calculated as defined in FNV-1a Hash (32-bit)
- sequence
- If multiple host names yield the same hash value, different sequence numbers are used to create uniqque names
The vars create lines in the config file create these vars. Example:
vars create RPRXY/HD93FC082/00000 ...
The flags used for these VARS are pb (permanent, binary)
The content of the VARS is binary, optimized for quick access to the relevant data.
The general format is
struct {
word - offset H.323 mappings
word - offset SIP mappings
word - offset LDAP mappings
word - offset HTTP mappings
char [] - Hostname, variable length
byte [] - Mappings
}
- offsets
- The offsets are a byte offset into the var content to where the mappings info is stored
- hostname
- A variable length zero terminated hostname
- mappings
- Start of the mappings. All mappings are on 4 bytes aligned offsets
For the mappings the following structure is used:
struct {
IPaddr addr;
word port;
word ports;
word nets;
word flags;
word next;
word ext1;
word ext2;
word ext3;
char path[];
};
- addr
- The destination IP address, as IPv6 address. If the destination is IPv4 the mapped IPv4 format is used (::ffff:<IPv4>)
- port
- The port used for TCP
- ports
- The port used for TLS
- nets
- Offset from the beginning of the mapping to a network filter list, if present. If no filter is defined 0 is set
- flags
- Flags defined for the mapping. The following values are used:
- MAP_CERT - 1
- If set, the certificates of incoming TLS connections are checked
- MAP_APP - 2
- App Login
- MAP_DEFAULT - 4
- Default path for a given host
- path
- A zero terminated path
- ext1, ext2, ext3
- Fields reserved for extensions. With these fields, the mapping header is an even 32 bytes
- next
- is the offset in bytes from the beginning of this map to the beginning of the next one. It must be 0 for the last map for a host
If nets is set the following structure is used at the indicated offset:
struct {
word count;
word spare;
struct {
IPaddr addr;
IPaddr mask;
} net;
}
- count
- Number of networks in the list
- spare
- Used for 4 bytes alignment
- net
- Array of addr/mask pairs for the networks, as IPv6 addresses.
VARS used for White/Black list entries
RPRXY/I<FNV-1a Hash of address>/<sequence>
- FNV-1a Hash of the address
- The hash is calculated as defined in FNV-1a Hash (32-bit)
- sequence
- If multiple addresses yield the same hash value, different sequence numbers are used to create uniqque names
The vars create lines in the config file create these vars. Example:
vars create RPRXY/IC2D83483/00000 ...
The flags used for these VARS are pb (permanent, binary)
The content of the VARS is binary, optimized for quick access to the relevant data.
The following structure is used for the content:
struct { dword addr[4]; byte white; byte fill[3]; time_t date; word description_len; char description[128]; };
- addr
- The address on the list
- white
- True if white list entry
- fill
- For alignment
- date
- Unix timestamp of entry into list
- description_len
- Length of description
- description
- Description text without terminating zero. A maximum length of 128 characters is stored.