ich habe einen UCS4.x jetzt als “Slave” Server bei einem Provider (root-Server, öffentliche IP) laufen. Der verbindet sich via OpenVPN (pfSense Firewall) mit dem lokalen Domänennetzwerk.
Auf dem Root-Server habe ich Kopano installiert und nun einmal mit nmap auf die offenen Ports an der öffentlichen IP geschaut.
Nmap scan report for ...
Host is up (0.0076s latency).
Not shown: 988 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
110/tcp open pop3
143/tcp open imap
389/tcp open ldap
443/tcp open https
465/tcp open smtps
636/tcp open ldapssl
993/tcp open imaps
995/tcp open pop3s
8080/tcp open http-proxy
8443/tcp open https-alt
Nmap done: 1 IP address (1 host up) scanned in 4.75 seconds
Auf bleiben müssen (Remote Zugriff und Kopano Email): 22, 25,110, 143, 465, 993, 995.
Was ist mit den LDAP-Ports? das wundert mich etwas, dass die offen sind- die braucht doch eigentlich im Internet keiner, oder?
POP3 nutzt auch keiner mehr, oder braucht Kopano den?
Was ist mit 8080 und 8443? Da meldet sich Kopano CalDav Gateway, das sollte offen bleiben, oder?
Wenn ich in die UCS Registry schaue, finde ich die folgenden Einträge:
security/packetfilter/package/univention-ldap-server/tcp/389/all: ACCEPT
security/packetfilter/package/univention-ldap-server/tcp/389/all/en: LDAP
security/packetfilter/package/univention-ldap-server/tcp/636/all: ACCEPT
security/packetfilter/package/univention-ldap-server/tcp/636/all/en: LDAPS
Nun kann ich die bestimmt auf “DENY” setzen- aber blockiere ich dann auch die Pakete auf dem localhost-Interface? Und auf dem OpenVPN InterfacE? Auf beiden wird es bestimmt benötigt, oder?
afaik ist der LDAP Port für die Netzinterne Kommunikation geöffnet, sofern der Server im Netz steht würde ich meinem Bachgefühl folgend den auch nach extern schließen (von localhost muss Kopano aber weiterhin zugreifen können).
Sofern kein Anwender Pop3/IMAP/Caldav können diese Port natürlich auch geschlossen bleiben.
Was in deiner Liste allerdings fehlt ist http/https für den Zugriff auf die WebApp/ActiveSync.
danke für die (wenn auch subjektive) Bestätigung, ich hatte ja das gleiche Gefühl.
Habe nun die LDAP-Ports geschlossen und dafür auf dem OpenVPN und localhost aufgemacht.
for i in 389 636 7389 7636; do \
ucr set security/packetfilter/package/univention-ldap-server/tcp/$i/10.101.0.3="ACCEPT";\
ucr set security/packetfilter/package/univention-ldap-server/tcp/$i/10.101.0.3/en="LDAP on OpenVPN";\
ucr set security/packetfilter/package/univention-ldap-server/tcp/$i/127.0.0.1="ACCEPT;"\
ucr set security/packetfilter/package/univention-ldap-server/tcp/$i/127.0.0.1/en="LDAP on localhost"; \
ucr unset security/packetfilter/package/univention-ldap-server/tcp/$i/all/en;\
ucr unset security/packetfilter/package/univention-ldap-server/tcp/$i/all;\
done
Nachdem ich dann einen Neustart der Firewall durchgeführt habe
service univention-firewall restart
zeigt er mir auch alles richtig an und auch nmap ist wohl jetzt glücklich (und damit ich):
Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-18 11:39 CET
Nmap scan report for ***öffentliche IP***
Host is up (0.011s latency).
Not shown: 990 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
110/tcp open pop3
143/tcp open imap
443/tcp open https
465/tcp open smtps
993/tcp open imaps
995/tcp open pop3s
8080/tcp open http-proxy
8443/tcp open https-alt
Starting Nmap 6.00 ( http://nmap.org ) at 2016-11-18 11:15 CET
Nmap scan report for ***OpenVPN IP***
Host is up (0.024s latency).
Not shown: 988 filtered ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
110/tcp open pop3
143/tcp open imap
389/tcp open ldap
443/tcp open https
465/tcp open smtps
636/tcp open ldapssl
993/tcp open imaps
995/tcp open pop3s
8080/tcp open http-proxy
8443/tcp open https-alt
Wunderbar, Problem gelöst, jetzt habe ich im Univention-DNS noch den Eintrag für das Slave System von der öffentlichen IP auf die OpenVPN IP umgebogen und jetzt sieht das eigentlich alles recht gut aus!