Using the GNU Gatekeeper to create TLS tunnels

Most H.323 vendors did not implement encrypting the signaling connection with TLS. They only encrypt the media (RTP). But you can use the two GNU Gatekeepers to encrypt you call signaling even when your endpoints don't support this natively.

Suppose you have 2 locations and want to connect them securely over the public internet.

GnuGk can encrypt call signalling between those locations using TLS and encrypt the media (RTP) using H.235.6 (AES encryption). 

 Configuration for GNU Gatekeeper 1 (prefix 01)

 

[Gatekeeper::Main]

[RoutedMode]
GKRouted=1
H245Routed=1
CallSignalPort=1720
AcceptUnregisteredCalls=1
; make sure H.245 gets tunneled for TLS
H245TunnelingTranslation=1
; add AES media encryption if the endpoint doesn't encrypt itself
EnableH235HalfCallMedia=1
; only allow encrypted calls
RequireH235HalfCallMedia=1
; change the media key after 2^31 operations
EnableH235HalfCallMediaKeyUpdates=1

[Proxy]
Enable=1

[ModeSelection]
0.0.0.0/0=PROXY
; only use routed mode for local calls
192.168.0.0/18=H245ROUTED

[TLS]
EnableTLS=1
PrivateKey=/path/to/server.pem
Certificates=/path/to/server.pem
CAFile=/path/to/rootcert.pem
Passphrase=MySecret
CheckCertificateIP=1

[Gatekeeper::Auth]
FileIPAuth=required;Setup

[FileIPAuth]
; allow all calls from local network
192.168.1.0/24=allow
; only allow TLS encrypted and authenticated calls from elsewhere
any=onlyTLS

[RasSrv::PermanentEndpoints]
; the GnuGk in the other location, serving prefix 02
1.2.3.4:1300=remote-gw;02

[EP::remote-gw]
; use TLS to call remote GnuGk
UseTLS=1 

Configuration for GNU Gatekeeper 2 (prefix 02)

[Gatekeeper::Main]

[RoutedMode]
GKRouted=1
H245Routed=1
CallSignalPort=1720
AcceptUnregisteredCalls=1
; make sure H.245 gets tunneled for TLS
H245TunnelingTranslation=1
; add AES media encryption if the endpoint doesn't encrypt itself
EnableH235HalfCallMedia=1
; only allow encrypted calls
RequireH235HalfCallMedia=1
; change the media key after 2^31 operations
EnableH235HalfCallMediaKeyUpdates=1

[Proxy]
Enable=1

[ModeSelection]
0.0.0.0/0=PROXY
; only use routed mode for local calls
192.168.0.0/18=H245ROUTED

[TLS]
EnableTLS=1
PrivateKey=/path/to/server.pem
Certificates=/path/to/server.pem
CAFile=/path/to/rootcert.pem
Passphrase=MySecret
CheckCertificateIP=1

[Gatekeeper::Auth]
FileIPAuth=required;Setup

[FileIPAuth]
; allow all calls from local network
192.168.1.0/24=allow
; only allow TLS encrypted and authenticated calls from elsewhere
any=onlyTLS

[RasSrv::PermanentEndpoints]
; the GnuGk in the other location, serving prefix 01
1.2.3.5:1300=remote-gw;01

[EP::remote-gw]
; use TLS to call remote GnuGk
UseTLS=1 

Other options

You could also configure the remote GNU Gatekeeper as a neighbor, but beware that the RAS traffic between neighbors will show meta data (whois is caling who) in clear text! 

See the GnuGk manual section on TLS for more details and examples how to generate the OpenSSL certificates. 

 

Howto block H.323 spam calls with fail2ban

When you run the GNU Gatekeeper, you can block spam calls from the well known bots ("MERA RU", "SimpleOPAL" etc.) eg. using a small LUA script in your config.

But that alone doesn't stop the load on the server, because often these bots keep on making calls.

Fail2ban to the rescue!

With this filter definition in /etc/fail2ban/filter.d/gnugk.conf you can check fro rejected calls:

[Definition]
failregex = Dropping call CRV=[0-9]+ from <HOST>:[0-9]+ due to Setup authentication failure
ignoreregex =


And then you can add this jail definition to /etc/fail2ban/jail.local to block the IP:

[gnugk]
enabled  = true
logpath  = /var/log/gnugk.log
filter   = gnugk
bantime  = 6000
maxretry = 2
action   = iptables[name=GnuGk, port=1720, protocol=tcp]


Voila!

What to do when your H.323 videoconferencing equipment reaches end-of-life ?

The big videoconferencing vendors (Polycom, Lifesize, Cisco etc.) only support their products for a limited time. After that they go „end-of-life“ and don't receive any more updates. That doesn't mean they don't work any longer. That H.323 standard how to do video conferences didn't change much in recent years, so there is no need for updates to accomodate other changes. But you there is a certain risk that they may have a security hole that doesn't get fixed any more.

Save money and stay independent

The vendors would prefer if you simply buy something new or subscribe to their proprietary “cloud service”. But to you this means spending money and a possible lock-in into their system versus just keeping systems going that run fine and owning the technology yourself with the independence that comes with it.

Move endpoints inside your firewall to private IPs

One important suggestion is to move end-of-life endpoints away from public IP addresses and to private IPs inside your firewall. Out of convenience many people used to operate their H.323 endpoints on public IPs, but nowadays its not much of a problem to use H.460 NAT traversal and move them to a safe place inside behind a GNU Gatekeeper.

If you have very old endpoints that don't support support H.460 NAT traversal, you can still do this. You just need a 2nd GNU Gatekeeper inside your firewall that tunnels the calls out to your external GNU Gatekeeper on the public IP. (Hey, its a free, you just need a 2nd server!)

Replace infrastructure devices with a GNU Gatekeeper

Some infrastructure devices (gatekeepers, gateways, proxies etc.) need to be on public IPs and thus there is a risk of exposing possible security holes to the open internet. Many of those can be replaced with a GNU Gatekeeper. Keep in mind it can be configured to do many different things that ordinary gatekeepers don't do.

Background: What is an RTP Bleed attack ?

now that hopefully everybody has updated to GnuGk 4.7 here is a little bit of background information on the latest security update:

RTP bleed is an attack that allows the attacker to redirect the RTP media stream (or parts of it) to his own IP without even having to manipulate any IP routing or being in a man-in-the-middle position. It also has good potential to mount a denial of service attack.

This vulnerability is not specific to GnuGk or H.323. It exists in a number of telephony products and RTP proxies. recently Asterisk was found to be vulnerable.

How is this attack possible ?

Originally H.323 announced all the ports that it intended to use inside the signaling and all was well. Then came firewalls and today most endpoints live on private IPs and have no idea what their public IP might be or which port the NAT router assigns then.

Thus H.323 introduced port detection in the form or H.460.19 which only works with registered endpoints and GnuGk extends that to unregistered endpoints with the IgnoreSignaledIPs=1 switch.

This works very well, but it means that GnuGk has to listen to RTP from any IP address and then send RTP for the other direction to what ever IP the sender appears to have. An attacker can now try to send its own RTP packets and trick GnuGk into believing they come from the call participants. And thats really easy, since RTP itself doesn't carry any form of authentication. When receiving such a malicious RTP packet at the right time, GnuGk
would thus send the media stream to the attacker.

The first step to reducing the attack surface is to stop allowing incoming RTP packets to change the send destination after the initial port detection is done. GnuGk has always done this for H.460.19, but not for unregistered calls until version 4.7.

Unfortunately this still leaves the possibility for an attacker to try to send RTP packets before the real call participants do. And since RTP is UDP, it can easily be sent with a spoofed source address to turn this into a hard do defend against denial of service attack.

Since H.323 doesn't make any requirements where RTP will come from, you can't defend against this remaining vulnerability without disrupting some valid configurations.

But is most cases RTP will come from the same IP or at least the same network where the signaling comes from. Thus GnuGk introduces a new switch in version 4.7 so you can tell GnuGk to only accept RTP from these IPs (RestrictRTPSources=Net). Thus an attacker would have to be inside the calling parties network to cause harm which is way more
difficult that to be just anywhere on the internet.

If you use a load balancer or routed mode gatekeepers distributed over multiple networks, you need to take more elaborate steps to secure your network, but the vast majority of users should be able to secure their configurations with RestrictRTPSources=Net. Since we violate the H.323 standard a bit here, the switch is off by default and you will
need to set it explicitly.

I hope this clarifies the issue and explains why you should update and secure your configuration!

GNU Gatekeeper 4.7 (security update)

This version is purely a security update and has no new features. All users are encouraged to update, especially if you use port detection (IgnoreSignaledIPs=1) you should update ASAP.

It has been discovered that GnuGk is vulnerable in some configurations for RTP bleed attacks (https://rtpbleed.com/). By updating to version 4.7 only the first packets in each media stream influence the media destination.

To further secure your configuration, you can set

[Proxy]
RestrictRTPSources=Net

to only accept RTP from the same class C network that the call signaling came from. Please beware that this may break a few valid calls where this condition isn't met.

You can download the new version from
https://www.gnugk.org/h323download.html


Please see the full change log below.

Changes from 4.6 to 4.7

• fixes for RTP Bleed
• new switch [Proxy] RestrictRTPSources=IP or Net to limit accepting RTP from the call signal IPs or the respective class C network
• new switch [Proxy] LegacyPortDetection=1 to keep port detection help for some very old and broken endpoints that will make your gatekeeper vulnerable to RTP Bleed attacks
• BUGFIX(ProxyChannel.cxx) replace @ip or ip## from aliases when using RedirectCallsToGkIP
• BUGFIX(ProxyChannel.cxx) better initialization of sendmsg() structs
• new command line option: now you can use -S instead of --strict (needed on BSD systems)

GNU Gatekeeper 4.4 released

GNU Gatekeeper 4.4 was released today. This is mainly a bug fix release
with only 2 new features.

If you use SSH on your status port you are urged to update as soon as
possible and also if you use LUA scripting. Two serious bugs have been
fixed for these features where GnuGk can be crashed remotely.

A new feature is the RequireOneNet policy that allows you to restrict
access to publicly accessible traversal gatekeepers. Now you can easily
define that one end of all calls must terminate in one of your own
networks and prevent abuse of your resources by 3rd parties.

The other new feature is a significant improvement to the MakeCall
command on the status port. It is now able to establish video calls and
supports virtually all endpoints by using GnuGk's call reroute feature.

Changed config switches:

• [Proxy] ProxyForNAT now defaults to OFF
• [CTI::MakeCall] DisableFastStart has been removed, fastStart is now always disabled

You can download the new version from
http://www.gnugk.org/h323download.html

Please see the full change log below.

These know bugs haven't been addressed, yet:

• when GnuGk acts as a H.460.18 client (as client in a H.460.18 traversal zone with another gatekeeper or as child gatekeeper), it currently does not send a keep-alive on the Q.931 TCP connection  during a call
• bandwidth management currently only applies to calls from registered endpoints and ignores unregistered calls completely

Changes from 4.3 to 4.4

• [CTI::MakeCall] TransferMethod can now also be Reroute, DisableFastStart switch removed
• BUGFIX(MakeCall.cxx) fix MakeCall bearer capabilities to support video calls
• BUGFIX(ProxyChannel.cxx) don't send Notify after call Reroute: Polycom RealPresens  starts a flood of Status messages
• BUGFIX(GkStatus.cxx) call ssh_init() and ssh_finalize() only on application start and shutdown
• BUGFIX(ProxyChannel.cxx) fix IP check for IgnoreSignaledPrivateH239IPs= switch
• new accounting/authentication policy RequireOneNet
• pass full RRQ message to LuaAuth
• BUGFIX(ProxyChannel.cxx) when opening a port from a PortRange fails, try next port  regardless of errno
• BUGFIX(lua.cxx) add mutex for LUA interpreter, because it is not thread safe
• added message type parameter in RouteRequest event (ARQ, Setup, LRQ)
• BUGFIX(yasocket.cxx) fix UDP with LARGE_FDSET on Solaris, OpenBSD and NetBSD
• BUGFIX(RasTbl.cxx) fix crash on invalid AliasTypeFilter setting
• changed default setting: [Proxy] ProxyForNAT now defaults to off, if you want to keep the previous behaviour, please set it explicitely

GNU Gatekeeper 4.3 released

I'm happy to announce the release of GNU Gatekeeper 4.3.

This new version contains a number bug fixes and some security fixes.


Fuzzy testing surfaced methods to crash GnuGk remotely, causing at least a denial of service. So all users are encouraged to update.

The most notable new feature are probably the events for Setup messages on the status port so now you can see all calls. In addition, LuaAuth has been given access to more information about received messages and can end your status port sessions with Ctrl-C now.

Important bug fixes are in the H.460 NAT traversal code where sometimes keep-alive intervals could be too long in older versions and a bug where GnuGk might have missed port re-negotiations in some cases.

The IgnoreSignaledIPs port detection code also has a few bug fixes to detect cases where it should be turned off automatically because its either not needed because the parties use another form of NAT traversal or non-symmetric ports where the detection algorithm may cause more harm than good.

You can download the new version from
https://www.gnugk.org/h323download.html


Enjoy!


Changes from GnuGk 4.2 to 4.3

• BUGFIX(ProxyChannel.cxx, gkh235.cxx, gkauth.h) fix crashes found with PROTOS
• new authentication policies LuaPasswordAuth, HttpPasswordAuth
• BUGFIX(configure.in) fix check for LUA 5.2 or higher
• connection to the status port can now also be ended with Ctrl-C
• new switch [Routing::DNS] RewriteARQDestination= to preserve URLs in ARQs
• disable IgnoreSignaledIPs when one party is not using the same RTP ports for forward and reverse channels in same RTP session
• BUGFIX(RasTbl.cxx) don't allow higher TTL for H.460.18 registrations  than set by H46018KeepAliveInterval= switch
• add variables message, srcInfo and vendor to LuaAuth
• print message on status port when Setup is received
• BUGFIX(ProxyChannel.cxx) disregard IgnoreSignaledIPs=1 switch when caller supports some form of NAT traversal (to avoid both sides waiting for first RTP packet)
• BUGFIX(ProxyChannel.cxx) enable H.245 tunneling for H.460.17 even when Innovaphone forgets the flag
• BUGFIX(ProxyChannel.cxx) make sure CRV is 0 for all RAS messages when using H.460.17 even when they relate to a call
• BUGFIX(ProxyChannel.cxx) re-do H.460.19 port detection when a new logical channel is opened on the same port
• print number of CPU cores and thread configuration on startup
• BUGFIX(RasTbl.cxx) fix display of H.460.17 for registrations on status port
• BUGFIX(ProxyChannel.cxx) fix dead lock causing reroutes to fail

New GNU Gatekeeper 4.0 Features

H.235 password authentication

Until now, GnuGk only supported MD5 password tokens well. The password
only secured RRQ and ARQ messages in the direction from the endpoint to
the gatekeeper and MD5 is considered a pretty weak algorithm. MD5
tokens are widely supported by vendors and are usually called "H.235",
but strictly speaking they aren't part of any ITU spec.

The new implementation in GnuGk closely follows the H.235.1
specification. It secures all RAS (RRQ, ARQ, BRQ, DRQ etc.) and all
Q.931 (Setup, Alerting etc.) messages. It also secures both directions,
so the gatekeeper can check every message if it is really from the
endpoint and also the endpoint can make sure its really talking to its
gatekeeper.

The interpretation of H.235.1 varies between vendors (or their
implementation is just buggy, your call). Thats why GnuGk defaults to
rather strict checks, but has configuration switches ([H235] config
section) to enable interoperability with vendor implementations.

During development I ran tests with AudioCodes, Polycom, Inovaphone and
H323Plus endpoints.

For example if you are using a AudioCodes gateway, you should set

[Gatekeeper::Auth]
SimplePasswordAuth=required;RRQ,ARQ,DRQ,RAI,Setup,Alerting,Connect,ReleaseComplete,Facility

[H235]
UseEndpointIdentifier=1
RequireH2351GeneralID=0
FullQ931Checking=1
You can even tighten security with CheckID=1 in [SimplePasswordAuth].

Per endpoint codec filtering

Suppose you have this MCU, that works fine when endpoints use H.263,
but a lot of calls using H.264 fail. Now you can simply disable H.264
in your GnuGk config, even if that MCU doesn't give you that option:

[RoutedMode]
H245Routed=1

[EP::MyMCU]
DisabledCodecs=genericVideoCapability
Now that MCU can't negotiate H.264 any more and all calls will use
H.263. All other endpoint can still use all codecs.

Or suppose you have a Radvision MCU that is rather strict about using
symmetric codecs. Many endpoints don't handle symmetric codec
requirements correctly, but it often helps to simply disable H.239 if
you aren't using it away:

[EP::RadvisionMCU]
DisabledCodecs=extendedVideoCapability;genericControlCapability
If all your endpoints follow all the specs, you'll probably never need
this feature. Unfortunately not all do and thats when this feature
comes in handy.

IPv6 and IPv4-IPv6 conversion

Actually this is not a new feature in GnuGk 4.0, but 4.0 brings some
significant bug fixes and improvements.

We all know IPv6 will come some day, but hasn't so far, because some
equipment still works better with IPv4 or some network doesn't support
it, yet etc.

With GnuGk, you don't have to convert your network to IPv6, you can
simply add it as another option and GnuGk will convert between IPv4 and
IPv6 whenever necessary. So you can keep all your legacy endpoints that
only support IPv4 and still have them reach other endpoints that work
on IPv6.

I would suggest you give IPv6 a try in your network now, before things
get very urgent and must be done in a rush.

The config part in GnuGk is rather easy:

[Gatekeeper::Main]
EnableIPv6=1
In all places where you can put an IPv4 address, you can also place an
IPv6 address.

BTW: If you want to see your IPv6 H.323 calls in Wireshark, you need a
new version. I worked with the Wireshark developers to get the
disection fixed. That patch will probably be in 2.0.0rc1.

GNU Gatekeeper 3.8 released

I am pleased to announce a new release of the GNU Gatekeeper, version 3.8, available from https://www.gnugk.org/h323download.html.

This release includes source code sutitable for (Linux, Windows, MacOS, FreeBsd, NetBSD, OpenBSD and Solaris) and executables for Linux.

In addition to the new GnuGk version, I'm also happy to announce the general availability of the new Web Interface.


In response to the current wave of H.323 spam / hacking GnuGk 3.8 has a number of improvements to security related features:

• endpoint IDs are now completely random and not as easily guessable as they were before
• GnuGk is now using better random numbers in security relevant places
• new authentication modules using LUA scripts called LuaAuth
• new switch [RasSrv::ARQFeatures] CheckSenderIP=1 to make sure ARQs  come from the same IP as the initial registration
• FileIPAuth is now able to check ARQ messages
• AliasAuth updated to work with H.460.18 endpoint
• PrefixAuth was extended to support unregistered calls
• SQLAuth can now operate on SrcInfo fields using %{SrcInfo}
• improvements to the addpasswd utility.

Other new non-security related features include:

• The CatchAll policy now rewrites the destination alias which makes it easier to send CatchAll calls to MCU rooms.
• You can now filter out whole capability classes, eg. all video or H.239 capabilities if some of your endpoints have trouble handling them
• A new switch [Gatekeeper::Main] MinH323Version= lets you set the H.323 version GnuGk identifies itself as using (up to the latest version 7). This is mainly to deal with endpoint that switch features when they believe they are talking to older endpoints (which one shouldn't be doing...)
• a number bugs and crashes fixed