| The IBR runs a couple of Internet services for use by IBR members, students, project partners and other external users. Many of them require authentication, others don't. These services include DNS, Web sites and services, email hosting and transport, an LDAP directory, calendar services, mailing lists, and many others. We try to run these services in a way that ensures a reasonably high level of confidentiality and privacy, integrity and authenticity. However, the world keeps changing and we cannot take every meaningful step, when new kinds of risks and weaknesses come up. These are some of the principles and techniques that we generally try to implement for our services: - Enforce encryption. Most services are not available without transport encryption, at least not from the Internet. Others only supply limited access without encryption. Non-encrypted HTTP requests are usually redirected to the corresponding HTTPS URLs.
- Avoid personal data. We try to store personal data only where required and otherwise only if the person supplies the data himself. E.g., our LDAP editor allows every user to add, modify and delete most of his own personal information. When a user account is closed, personal data (home directory, mail folders) is removed after approx. one month. However, many services keep data and logfiles in a way that allows to mine some personally related data. We always try to make sure, that only adminstrators can access such data for debugging and statistics purposes.
- X.509 Certificates. We use "official" X.509 certificates for most of our services (25 services as of 2015-10-30), signed through the german DFN CA infrastructure. For some temporary use cases, we use "Let's encrypt" certificates.
- HTTP Strict Transport Security. We attempt to use HSTS with all our major HTTP servers.
- HTTP Public Key Pinning. We use HPKP with most of our HTTP-based services (those which are based on Apache).
- OCSP Stapling. Some of our HTTP-based services deliver OCSP information along with responses to HTTPS clients.
- DNS-based Authentication of Named Entities. For most SSL-secured services we provide TLSA DNS-RRs (DANE). However, please note the current DNSSEC limitations:
- DNS security. We configured our Domain
ibr.cs.tu-bs.de to be ready for DNSSEC, including the more secure NSEC3 RRs instead of NSEC RRs. Unfortunately, our parent domains do not yet support DNSSEC. Hence, we can only provide DNSSEC authenticity through ISC DLV. - Mail Transport. We not only use TLS for SMTP connections where possible, but we also try to verify peers based on DANE.
- Kerberos. We attempt to supply SSO through Kerberos v5 with many of our services.
- Secure Shell. We supply SSH v2 on most of our hosts and we try to keep consistent host keys, even if hosts are re-installed.
- Regular updates. All of our hosts running services are updated on a regular basis, in almost all cases automatically. This ensures that most new weaknesses get fixed in a timely manner.
- Firewall. Our boundary router restricts IPv4 and IPv6 traffic to traffic either initiated from inside the institute's network or from the Internet only to well-defined service hosts and ports. Other incoming traffic is generally dropped by the firewall. Some specific incoming connection requests (SSH) are rate limited in order to reduce risks based on brute force password attacks.
This list is definetely not complete. However, it's a starting point for those who are interested in our security measures. Questions and feedback are welcome. Drop us an email. |
