Best practice for securing UCS - info requested


#1

We would like to move our UCS to the DMZ. Main reason is to make SAML public.

What are your recommendations to secure UCS against brute force attacks?

Considerations:

  • both UCS login and SAML login are available on the same FQDN
  • password lockout doesn’t seem to work (Ldap Account sperren nach X Logins)
  • Apache Mod_Security is another option to secure the server. Is it available in UCS?
  • what are the other options?

#2

Hey,

Yes, mod_security is available: install the package »libapache2-modsecurity«.

Generally you should follow basic advice for making severs available to the public:

[ul][li]Lock down all ports that don’t have to be accessible from everywhere via firewall rules. You can use the Univention Firewall script (which isn’t documented that well, unfortunately) for it or disable Univention’s firewall and roll your own script. For example, you normally don’t want the Samba ports to be reachable.[/li]
[li]Make sure that the firewall(s) separating your DMZ from your internal network only allow connections from the DMZ to the internal networks that are required. If you don’t need to ssh from your DMZ UCS server to internal hosts then don’t allow that.[/li]
[li]Logins to the services should be restricted to accounts that really need it. How this is done differs from service to service. If you have web services that don’t allow you to limit the valid logins then consider to use Apache’s authentication mechanism in addition to the web service’s own login method as Apache lets you specify valid users/groups.[/li]
[li]Implement secure password policies. Length trumps everything else regarding computational complexity, so make sure to use policies with long passwords. Special characters aren’t that important.[/li]
[li]Deploy additional tools that limit the effect of brute-force attacks. One of those is the aforementioned mod_security for Apache. Another one is the fail2ban (also available on UCS) which is a general tool for blocking incoming connections for source addresses which fail to log in to a service for a short time (e.g. ten minutes). fail2ban can work with multiple services including but not limited to Apache, SSH, FTP…[/li]
[li]Make sure logs are available offsite. This usually involves having a syslog server running somewhere, e.g. in your internal network. Then configure the UCS syslog (rsyslog in this case) to send logs to the central syslog server.[/li]
[li]Use log analysis tools on the central syslog collection site that will alert you to unusual and unexpected events.[/li][/ul]