Die DMZ mit einem Proxy absichern
Sicherheit wird immer wichtiger. Die On-Premises-Infrastruktur abzusichern hat bei vielen unserer Kunden hohe Priorität. Heute geht es um die DMZ und einen Proxy.
Dieser Beitrag ist von 2022. Er bleibt online, weil er nach wie vor nachgefragt wird, beschreibt aber einen Produktstand von damals.
Sicherheit wird immer wichtiger. Die On-Premises-Infrastruktur abzusichern hat bei vielen unserer Kunden hohe Priorität, und wir helfen dabei. Heute geht es darum, wie du deine DMZ mit einem Proxy absicherst.
LDAP, NTP und DNS über einen Proxy
Um eine DMZ abzuschotten, dürfen die benötigten Ports nicht pauschal für alle Systeme geöffnet werden. Eine übliche Schwierigkeit: Wenn sich Domänenbenutzer in der DMZ anmelden wollen, erreichen sie die Active-Directory-Server nicht.
Die Antwort ist ein Proxy Server, der die Anfragen aus der DMZ weiterleitet. Das gilt für die Protokolle NTP, DNS und LDAPS.
Damit die DMZ abgeschottet bleibt, öffnet nur der Proxy die Ports 53 (DNS), 123 (NTP), 636 (LDAPS) und 3268-3269 (LDAP GC) zu den Active-Directory-Servern. Alle anderen Systeme in der DMZ bedient der Proxy Server.

Für den Aufbau brauchst du ein Linux-System als Proxy. Darauf werden die nötigen Dienste installiert und konfiguriert. Wir haben hier ein aktuelles RedHat Enterprise Linux 8 verwendet.
Weil bestimmte Werkzeuge nicht mehr in der Basisdistribution enthalten sind, holst du sie aus der Open-Source-Community.
OpenLDAP
Für das Proxying der LDAP-Anfragen kommt OpenLDAP zum Einsatz. Du bekommst es unter https://ltb-project.org/.
Unsere Konfiguration sieht so aus:
/usr/local/openldap/etc/openldap/slapd.conf
### Schema includes ###########################################################
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/misc.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/microsoft.minimal.schema
## Module paths ##############################################################
modulepath /usr/local/openldap/libexec/openldap
moduleload back_ldap
moduleload rwm
# Main settings ###############################################################
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
### Database definition (Proxy to AD) #########################################
database ldap
suffix "DC=sample,DC=intra"
rootdn "cn=ldap,DC=sample,DC=intra"
rootpw "BIND-PW-PROXY"
readonly yes
protocol-version 3
rebind-as-user yes
uri "ldaps://ADC001,ldaps://ADC002"
idassert-bind bindmethod=simple
binddn="CN=svc-ldap,OU=Service_Accounts,DC=sample,DC=intra"
credentials="BIND-PW-AD"
mode=none
flags=non-prescriptive
tls_reqcert=never
tls_cacert=/usr/local/openldap/etc/openldap/CA.cer # AD Certificate
overlay rwm
rwm-map attribute uid sAMAccountName
### Logging ###################################################################
loglevel 0
### Limits ####################################################################
sizelimit unlimited
### LDAPS ####################################################################
TLSCACertificateFile /usr/local/openldap/etc/openldap/CA.cer # PKI CA Certificate
TLSCertificateFile /usr/local/openldap/etc/openldap/proxyldap001.cer # LDAP Proxy Certificate
TLSCertificateKeyFile /usr/local/openldap/etc/openldap/proxyldap001.key # LDAP Proxy Key
Wenn die Konfiguration steht, startest du den Dienst. Testen kannst du direkt auf dem Proxy.
[root@localhost]# ldapsearch -LLL -x -h localhost -b "DC=sample,DC=intra" -D "cn=ldap,DC=sample,DC=intra" -w "BIND-PW-PROXY" "(objectClass=USER)"
Die Ausgabe sollte jetzt alle Benutzerobjekte des AD liefern.
NTP
Damit Windows als Quelle für den Chrony-Dienst unter Linux taugt, musst du den NTP-Dienst auf den Windows Domain Controllern anpassen. Sonst kann Chrony den NTP-Servern nicht trauen.
Was auf Windows zu tun ist
Zuerst startest du eine CMD als Administrator. Dann führst du diese Befehle aus:
w32tm /config /manualpeerlist:"0.ch.pool.ntp.org,0x8 1.ch.pool.ntp.org,0x8 2.ch.pool.ntp.org,0x8 3.ch.pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /resync /rediscover
w32tm /config /LocalClockDispersion:0
w32tm /config /update
net stop w32time && net start w32time
Die Konfiguration unter Linux
Damit Linux als NTP-Proxy arbeitet, reicht Chrony, das bei RedHat dabei ist. Du passt nur die Konfiguration an und startest danach den Dienst.
/etc/chrony.conf
# These servers were defined in the installation: (Active Directory)
server 192.168.46.100 trust
server 192.168.46.101 trust
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
rtcsync
# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *
# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2
# Allow NTP client access from local network. (DMZ)
allow 10.10.10.0/24
# Serve time even if not synchronized to a time source.
local stratum 5
# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys
# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC
# Specify directory for log files.
logdir /var/log/chrony
# Select which information is logged.
#log measurements statistics tracking
Zum Testen fragst du die Quellen ab.
[root@localhost]# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 192.168.46.100 2 6 1 9 +76us[ +76us] +/- 32ms
^ 192.168.46.101 4 6 1 9 +206us[ +206us] +/- 29ms
DNS
Als DNS Server verwenden wir ISC BIND. Den gibt es für alle aktuellen Linux-Distributionen, und er ist schnell konfiguriert.
Forwards lassen sich dafür einfach einrichten.
/etc/named.conf
options {
listen-on port 53 { 127.0.0.1; 10.10.10.200; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; 10.10.10.0/24; };
forwarders {
192.168.46.100;
192.168.46.101;
};
recursion yes;
dnssec-enable no;
dnssec-validation no;
auth-nxdomain no;
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
Nach dem Start des Dienstes laufen die Abfragen über DNS.
[root@localhost]# nslookup ADC001
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: ADC001.sample.intra
Address: 192.168.46.100
Die Firewall unter Linux
Damit die Systeme in der DMZ die Dienste nutzen können, öffnest du die Linux-Firewall entsprechend.
firewall-cmd --add-service=dns --permanent
firewall-cmd --add-service=ntp --permanent
firewall-cmd --add-port=123/udp --permanent
firewall-cmd --add-port=636/tcp --permanent
firewall-cmd --reload
Fazit
Nach der Konfiguration dieser drei Dienste hast du einen funktionierenden Proxy, der NTP-, DNS- und LDAPS-Anfragen innerhalb der DMZ beantwortet, und du musst nicht alle Systeme durch die Firewall schleusen.
Wenn du deine Sicherheit auf die nächste Stufe bringen willst, melde dich. Wir helfen gerne, deine IT-Infrastruktur abzusichern.