Some services such as Extranets and web mailer are often run on top of UCS server in the DMZ. This article describes the actions to consider when running a UCS 4.x server reachable from the Internet.
Starting with version 4.2, UCS features an improved portal, which gives users a central overview of all applications and domain services available in the domain. Using the Univention portal, administrators can offer their users easy access to all their needed apps, without asking them to remember URLs or aliases, leading to the services. This portal page is individually configurable: You can not only change the design to your taste, but also determine which web services are displayed to which user.
Feel free to check out the new portal in our online demo.
Remarks Before Starting
This entry is not a comprehensive security analysis for any purpose. It only tries to hint where extra work might be necessary. We also highly recommend running UCS through an application firewall.
UCS in the DMZ
The following topology is a simple example of how a DMZ can be integrated into an UCS domain to provide services like groupware or cloud file services to clients from the internal network as well as clients coming from the Internet.
Example topology of a DMZ within an UCS domain.
Cloud icon by
freepik.com, Firewall icon by “madebyoliver”
UCS as Firewall
UCS is not a firewall distribution. When running UCS Servers productively, it is highly advisable to not use a firewall of the same distribution, to prevent bugs from affecting both systems in the same way. Also, hardware firewalls are most often more efficient than any software based solutions.
If you are using virtualization on top of your hardware, it is strongly advisable not to make the virtualization servers accessible from the outside. In case your hardware does not support more than one network interface, you might want to consider methods such as VPN or VLAN to separate your virtualization servers from the actual DMZ. See the official documentation on how to set up VLANs.
A most crucial question is whether to run the DMZ as part of your productive domain or as a separate domain. Depending on this you might also need to choose different roles for your servers.
One Domain vs. Separate Domains
It far most comes down to the applications you are planning to deploy within your DMZ. If many of them require a large number of your employees to authenticate themselves with credentials, it might be a better idea to create one domain and require a stronger password. On the other hand, if you are only running mail proxies and external web servers the few administrative accounts can easily be maintained without causing to much trouble.
We recommend using separate domains and our solution to Sync Users and Groups into the DMZ Domain.
In case only need to authenticate some departments, you should also consider splitting your LDAP into separate containers and only to replicate those.
For most of the services a member server should be able to provide the basis for most of the services.
In some cases, it might make sense to run an additional DC Slave within the DMZ. Especially if you have multiple services requiring LDAP access it might make more sense to only drill one hole for a slave into your firewall then to open up multiple passes. Also if you want to only replicate parts of your user base or not want to show any non-DMZ computers to the outside, this would be the right approach.
However, under no circumstances will you want to place a DC Master or DC Backup within your DMZ. If an attacker gets hold of a master or backup there, it will be nearly impossible to recover your domain.
To minimize attack points, you will only want to run the bare minimum of services on your servers. We will here walk you through deactivating the default Domain Services.
Uninstall the Display Server
UCS uses an Xorg server for the initial configuration and setup as well as to display the IP address of the server. However, this service is not needed anymore afterwards but represents a security risk. Remove it and other obsolete packages with the following command
apt-get purge xserver-xorg xserver-xorg-core firefox-en firefox-esr openbox x11-utils x11-xserver-utils xauth xbitmaps xfonts-base xfonts-encodings xfonts-utils xinit xserver-common \ xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-video-all xserver-xorg-video-* xterm adwaita-icon-theme hicolor-icon-theme \ libfontenc1 libid3tag0 libgphoto2-6 libgphoto2-l10n libgphoto2-port10 libqt4-xml libqtcore4 libqtgui4 libx11-protocol-perl libx11-xcb1 libxatracker2 libxcb-dri2-0 libxcb-dri3-0 \ libxcb-glx0 libxcb-present0 libxcb-shape0 libxcb-sync1 libxcb-util0 libxcb-xfixes0 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxfont1 libxft2 libxinerama1 \ libxkbcommon0 libxmuu1 libxrandr2 libxshmfence1 libxss1 libxtst6 libxv1 libxvmc1 libxxf86dga1 libxxf86vm1 univention-welcome-screen univention-system-setup-boot apt-get autoremove apt-get clean apt-get autoclean ucr commit reboot
UMC - Web Server
In case you are running something else than a web server, for example, a mail server, you most probably do not want Apache to offer the UMC to the users. You can switch it off using the following UCR variable:
ucr set apache2/autostart=no
If Apache was already running before, the service itself, as well as the UMC web server have to be stopped:
service apache2 stop service univention-management-console-server stop service univention-management-console-web-server stop
In case you want to change the default directory set the variable:
ucr set apache2/documentroot=/my/web/dir/
same applies to the start page:
ucr set apache2/startsite=my/startpage.html
Thereby a relative path uses apache2/documentroot as its prefix. Thus in this example the start page would have to be found at:
Unless you are planning on running domain joined Microsoft Windows Systems, there is absolutely no need to run a Samba Installation in your DMZ. If you have installed it, uninstalling it is the preferred way over disabling it.
Univention Listener Cache
The Univention Listener is caching the passwords, usernames and groups of the authenticated users which might pose a security threat if an attacker gets hold of the system and can read out or copy the cache. This copy would enable the attacker to try to decrypt the passwords, if he can copy the full system or parts of the listener cache. The usage of sufficiently cryptic passwords can reasonably delay the attack.
The firewall is defined through many UCR variables. You can review them by issuing the following command:
ucr search security/packetfilter
First, you might want to change the default policy to silently drop packages. To do this you need to change the following Variable:
ucr set security/packetfilter/defaultpolicy='DROP'
The different rules are separated in the following way
security/packetfilter/package/<system package>/<transport protocol>/<port>/<destination>: <policy>
If you are changing any of the variables you need to restart the firewall:
service univention-firewall restart
If you want to check your firewall you can use tools like nmap or other port checking services.
Which TCP / UDP ports on the DC master must be accessible by other UCS systems can you find out in this article.
Regarding Docker Apps and ports you may find the following article helpful:
Integration with UCS/Firewall
You may want to perform a more extensive security/penetration check of your system. Because there are various tools to do so it is hard to give concrete recommendations, but for example the linux distribution Kali offers a substantial collection of pre installed tools which are suitable for penetration tests.
It is advisable to automatically log inactive users out, if they are connected via SSH. You can easily create the necessary settings by adding them to root and the skel profile with the following commands:
echo TMOUT=599 >> /root/.profile echo export TMOUT >> /root/.profile echo TMOUT=599 >> /etc/univention/skel/.profile echo export TMOUT >> /etc/univention/skel/.profile
The 599 is the time in seconds for the logout to take affect.