Bug 23577 - univention-firewall für 3.0 überarbeiten
univention-firewall für 3.0 überarbeiten
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Firewall (univention-firewall)
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.0 - RC
Assigned To: Sönke Schwardt-Krummrich
Felix Botner
:
Depends on:
Blocks: 14697 24097 24121 24161
  Show dependency treegraph
 
Reported: 2011-09-09 16:07 CEST by Moritz Muehlenhoff
Modified: 2011-12-13 15:50 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Muehlenhoff univentionstaff 2011-09-09 16:07:54 CEST
univention-firewall sollte überarbeitet werden. Es sind für 22 Dienste ihre Ports gespeichert.

Dazu gibt es drei Stufen:
- Deaktiviert
- Empfohlen (alle Dienste erlaubt ausser ausser Telnet/Time auf Server-Rollen), auf Managed/Mobile Client und Basissystemen sind weitere Dienste geblockt.
- Abgesichert (dabei sind alle Dienste ausser SSH, LDAP und HTTPS geblockt

D.h. per Default accept und dann deny für die ausgewählten Dienste.

Das ganze Prinzip sollte für 3.0 umgedreht werden, also standardmässig deny und der Admin kann dann im UMC-Modul einzelne Dienste nach Wahl freigeben.

Ausserdem gibt es in univention-firewall ein UCR-Modul mit der Möglichkeit iptables-Regel zu definieren. Das müsste auf IPv6 angepasst werden. Alternativ kann es vermutlich auch ersatzlos entfallen, da das direkte Pflegen von iptables-Kommandos im Netz/Literatur besser dokumentiert ist und die Regeln für ein typisches Firewall-Setup vermutlich nicht flexibel genug sind.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2011-10-18 12:43:00 CEST
Die Namensgebung wurde jetzt etwas vereinheitlicht:
- das init.d-Skript heisst jetzt univention-firewall (vorher 
  univention-iptables). Das alte init.d-Skript wird während des Updates
  automatisch aus allen rc.d-Verzeichnissen ausgetragen und das Skript 
  umbenannt nach univention-iptables.disabled

- die UCR-Variablen nutzen weiterhin den "security/packetfilter/"-Prefix:

 - security/packetfilter/defaultpolicy=ACCEPT/REJECT/DROP
   Defaultpolicy, die für die INPUT-Queue gesetzt; die OUTPUT-Queue bleibt auf 
   ACCEPT

 - über security/packetfilter/package/PAKETNAME/PROTOKOLL/PORT/IPADDR=ACTION
   kann jetzt jedes Paket eigene IPTables-Regeln definieren:
   PAKETNAME: kann frei gewählt werden (idealerweise der aktuelle Paketname)
   PROTOKOLL: "tcp" oder "udp"
   PORT: Integer zwischen 1 und 65535 (inkl.)
   IPADDR: "all", "ipv4", "ipv6", IPv4-Adressen, IPv6-Adressen
   ACTION: "ACCEPT", "DROP", "REJECT"

   Beispiel: security/packetfilter/package/univention-samba/tcp/139/all=ACCEPT

   Die entsprechende Filterregel wird anschließend automatisch in
   /etc/security/packetfilter/packetfilter.univention.sh generiert.


 - durch das Anhängen eines Locale-Kürzels kann eine Beschreibung für die 
   jeweilige Regel hinterlegt werden:
   security/packetfilter/package/univention-samba/tcp/139/all/en="used by samba3"
    security/packetfilter/package/univention-samba/tcp/139/all/de="Ein Samba3-Port"

   Die Beschreibung wird als Kommentar zum jeweiligen iptables-Befehl in
   /etc/security/packetfilter/packetfilter.univention.sh gespeichert.

 - Falls die paketspezifischen Einstellungen übergangen oder eigene/zusätzliche 
   Regeln definiert werden sollen, sollten diese als 
   security/packetfilter/PROTOKOLL/PORT/IPADDR=ACTION definiert werden.
   Diese Regeln haben Vorrang vor den security/packetfilter/package/...-Regeln.

 - Falls die paketspezifischen Einstellungen gar nicht genutzt werden sollen, 
   kann die UCR-Variable security/packetfilter/use_packages=false gesetzt 
   werden.

- Benutzerspezifische Erweiterungen können in  
  /etc/security/packetfilter/packetfilter.local.sh definiert werden. Dieses 
  Skript wird beim Start der Firewall NACH dem Skript
  /etc/security/packetfilter/packetfilter.univention.sh ausgeführt. Es können
  dort somit komplexere Regeln realisiert werden bzw. vorhandene geändert 
  werden. Beim Update wird diese Datei nicht überschrieben (sofern sie vom 
  Benutzer geändert wurde).
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2011-10-20 09:06:46 CEST
(In reply to comment #1)
>  - security/packetfilter/defaultpolicy=ACCEPT/REJECT/DROP
>    Defaultpolicy, die für die INPUT-Queue gesetzt; die OUTPUT-Queue bleibt 
>    auf ACCEPT

Als Policy einer Queue wird eigentlich nur ACCEPT und DROP zugelassen. Bei DROP würden jedoch die Pakete einfach verworfen und bei Clients ein unnötiger Timeout abgewartet. Daher wird in der UCR-Variable auch der Wert REJECT zugelassen, der dann intern in eine globale REJECT-Regel in der INPUT-Queue sowie die INPUT-Default-Policy DROP umgesetzt wird.
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2011-10-20 09:17:28 CEST
(In reply to comment #1)
>  - über security/packetfilter/package/PAKETNAME/PROTOKOLL/PORT/IPADDR=ACTION
>    kann jetzt jedes Paket eigene IPTables-Regeln definieren:
[...]
> 
>    Beispiel: security/packetfilter/package/univention-samba/tcp/139/all=ACCEPT

Die Variablen sollten in den Postinst-Skripten HART (also mit "=" statt "?") 
gesetzt werden. Die ermöglicht ein einfaches Update der Firewall-Regeln. Falls 
der Benutzer eine Regel ändern möchte, kann er dies über Variablen nach dem 
Schema security/packetfilter/PROTOKOLL/PORT/IPADDR=ACTION überschreiben.
Comment 4 Sönke Schwardt-Krummrich univentionstaff 2011-10-20 09:41:42 CEST
ICMP wird vollständig erlaubt (eingehend wie ausgehend). Hier sollten die Kerneldefaults ausreichen.

Changelogeintrag wurde erstellt.
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2011-10-21 10:54:49 CEST
- für univention-squid müssen noch komplexere Regeln möglich sein → .d-Verzeichnis
- bei Updates sollte die DefaultPolicy "ACCEPT" sein
- bei Neuinstallationen sollte die DefaultPolicy "REJECT" sein
Comment 6 Philipp Hahn univentionstaff 2011-10-22 09:03:34 CEST
svn28119: Fix missing she-bang in /etc/security/packetfilter.d//50_local.sh
Comment 7 Sönke Schwardt-Krummrich univentionstaff 2011-10-23 19:31:49 CEST
(In reply to comment #5)
> - für univention-squid müssen noch komplexere Regeln möglich sein →
> .d-Verzeichnis

Um komplexere Regeln zu ermöglichen (z.B. für univention-squid) wurde wieder ein .d-Verzeichnis (/etc/security/packetfilter.d/) erstellt. Die UCR-Variablen werden jetzt in den Dateien /etc/security/packetfilter.d/20_univention-firewall_start.sh und /etc/security/packetfilter.d/80_univention-firewall_policy.sh in entsprechende iptables-Regeln umgesetzt.

Benutzer und andere Pakete können dann eigene Skripte in dem Verzeichnis ablegen. Für Benutzer wird ein 50_local.sh dort abgelegt. Die Dateien 
/etc/security/packetfilter/packetfilter.univention.sh und
/etc/security/packetfilter/packetfilter.local.sh sind dafür entfallen.

Die restliche Funktionsweise ist gleich geblieben.

> - bei Updates sollte die DefaultPolicy "ACCEPT" sein
> - bei Neuinstallationen sollte die DefaultPolicy "REJECT" sein

Wurde umgesetzt. Bitte bei der QA prüfen!

Changelogeintrag wurde angepasst.
Comment 8 Felix Botner univentionstaff 2011-11-04 10:39:41 CET
Aktuell funktioniert der nagios NTP Test nicht mehr, wenn auf einem entfernten Server geprüft wird (kein nrpe).

@backup:~# /usr/lib/nagios/plugins/check_ntp  -H master
NTP CRITICAL: No response from NTP server

@master:~# /etc/init.d/univention-firewall stop

@backup:~# /usr/lib/nagios/plugins/check_ntp  -H master
NTP CRITICAL: Offset 124,1967038 secs|offset=124,196704s;60,000000;120,000000;

Das hat vermutlich auch Auswirkungen auf die Zeitsynchronisation selbst.
Comment 9 Sönke Schwardt-Krummrich univentionstaff 2011-11-04 11:15:17 CET
(In reply to comment #8)
> Aktuell funktioniert der nagios NTP Test nicht mehr, wenn auf einem entfernten
> Server geprüft wird (kein nrpe).
> 
> @backup:~# /usr/lib/nagios/plugins/check_ntp  -H master
> NTP CRITICAL: No response from NTP server
> 
> @master:~# /etc/init.d/univention-firewall stop
> 
> @backup:~# /usr/lib/nagios/plugins/check_ntp  -H master
> NTP CRITICAL: Offset 124,1967038 secs|offset=124,196704s;60,000000;120,000000;
> 
> Das hat vermutlich auch Auswirkungen auf die Zeitsynchronisation selbst.

Firewall wurde angepasst:
univention-base-files (1.0.36-1) unstable; urgency=low
Comment 10 Sönke Schwardt-Krummrich univentionstaff 2011-11-04 11:15:54 CET
(In reply to comment #9)
> Firewall wurde angepasst:
> univention-base-files (1.0.36-1) unstable; urgency=low
Korrektur: univention-base-files (1.0.36-2) unstable; urgency=low
Comment 11 Sönke Schwardt-Krummrich univentionstaff 2011-11-04 12:23:03 CET
(In reply to comment #1)
> Die Namensgebung wurde jetzt etwas vereinheitlicht:
>  - über security/packetfilter/package/PAKETNAME/PROTOKOLL/PORT/IPADDR=ACTION
>    kann jetzt jedes Paket eigene IPTables-Regeln definieren:
>    PAKETNAME: kann frei gewählt werden (idealerweise der aktuelle Paketname)
>    PROTOKOLL: "tcp" oder "udp"
>    PORT: Integer zwischen 1 und 65535 (inkl.)

Statt eines einzelnen Ports, kann auch ein Range angegeben werden:
z.B. "137:139"
==> security/packetfilter/package/univention-samba/udp/137:139/all="ACCEPT"
Comment 12 Felix Botner univentionstaff 2011-11-07 12:07:12 CET
univention-dansguardian setzt bei der Installation  folgendes:

ucr set squid/virusscan?yes
ucr set squid/contentscan?yes


Squid wird in diesem Fall auf Port 3129 gestartet. Dafür gibt es aber noch keine Firewall Regel.
Comment 13 Sönke Schwardt-Krummrich univentionstaff 2011-11-07 12:20:05 CET
(In reply to comment #12)
> univention-dansguardian setzt bei der Installation  folgendes:
> 
> ucr set squid/virusscan?yes
> ucr set squid/contentscan?yes
> 
> Squid wird in diesem Fall auf Port 3129 gestartet. Dafür gibt es aber noch
> keine Firewall Regel.

Wenn Port 3129 von außen erreichbar ist, kann der Dansguardian umgangen werden. Dansguardian wird ja dem Squid vorgeschaltet und prüft die Inhalte auf 
Viren/Spam/...

Wie soll hier das Default-Verhalten sein?
Comment 14 Moritz Muehlenhoff univentionstaff 2011-11-07 13:44:50 CET
(In reply to comment #13)
> (In reply to comment #12)
> > univention-dansguardian setzt bei der Installation  folgendes:
> > 
> > ucr set squid/virusscan?yes
> > ucr set squid/contentscan?yes
> > 
> > Squid wird in diesem Fall auf Port 3129 gestartet. Dafür gibt es aber noch
> > keine Firewall Regel.
> 
> Wenn Port 3129 von außen erreichbar ist, kann der Dansguardian umgangen werden.
> Dansguardian wird ja dem Squid vorgeschaltet und prüft die Inhalte auf 
> Viren/Spam/...
> 
> Wie soll hier das Default-Verhalten sein?

Ich denke es sollte nur Port 3128 freigegeben sein. In einer Konfiguration mit Dansguardian sollte außer für Debuggingzwecke kein Zugriff auf den direkten Squid-Port möglich sein.
Comment 15 Felix Botner univentionstaff 2011-11-07 14:04:37 CET
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > univention-dansguardian setzt bei der Installation  folgendes:
> > > 
> > > ucr set squid/virusscan?yes
> > > ucr set squid/contentscan?yes
> > > 
> > > Squid wird in diesem Fall auf Port 3129 gestartet. Dafür gibt es aber noch
> > > keine Firewall Regel.
> > 
> > Wenn Port 3129 von außen erreichbar ist, kann der Dansguardian umgangen werden.
> > Dansguardian wird ja dem Squid vorgeschaltet und prüft die Inhalte auf 
> > Viren/Spam/...
> > 
> > Wie soll hier das Default-Verhalten sein?
> 
> Ich denke es sollte nur Port 3128 freigegeben sein. In einer Konfiguration mit
> Dansguardian sollte außer für Debuggingzwecke kein Zugriff auf den direkten
> Squid-Port möglich sein.

3129 kann standardmäßig geblockt werden, da er eigentlich nur von dansguardian verwendet werden soll. Über entsprechende UCR Variablen kann 3129 ja freigeschaltet werden. Ein entsprechender Changelog Eintrag wurde erstellt. Bitte in der QA auch diesen prüfen.
Comment 16 Felix Botner univentionstaff 2011-11-09 10:21:29 CET
Ich habe einen Backup (2.4-4) und einen Master (3.0) mit univention-firewall. Wenn ich auf dem Backup versuche mit kpasswd das Passwort zu ändern, gibt es folgenden Fehler

->  kpasswd felix
felix@III.ZZZ's Password: 
New password for felix@III.ZZZ: 
Verifying - New password for felix@III.ZZZ: 
kpasswd: krb5_set_password_using_ccache: unable to reach any changepw server  in realm III.ZZZ

Ohne univention-firewall (/etc/init.d/univention-firewall stop) geht es. Vermutlich muss hier der kpasswd Port noch freigegeben werden

-> more /etc/services| grep kpass
kpasswd         464/tcp
kpasswd         464/udp
Comment 17 Sönke Schwardt-Krummrich univentionstaff 2011-11-09 14:24:38 CET
Der UDP-Port 464 wurde jetzt freigeschaltet. Der TCP-port 464 war auf dem Testsystemen vom kpasswd nicht geöffnet worden.

univention-heimdal (5.0.18-1) unstable; urgency=low
Comment 18 Sönke Schwardt-Krummrich univentionstaff 2011-11-10 10:24:27 CET
(In reply to comment #17)
> Der UDP-Port 464 wurde jetzt freigeschaltet. Der TCP-port 464 war auf dem
> Testsystemen vom kpasswd nicht geöffnet worden.

Der TCP-Port wurde jetzt vorsorglich ebenfalls geöffnet.

univention-heimdal (5.0.18-2) unstable; urgency=low
Comment 19 Sönke Schwardt-Krummrich univentionstaff 2011-11-10 10:26:42 CET
Es wurden weitere Firewall-Regeln aktiviert:
univention-virtual-machine-manager-node-xen: TCP Port 8002
univention-virtual-machine-manager-node-xen: TCP Port 8002
univention-virtual-machine-manager-node-kvm: TCP Ports 49152 bis 49215
univention-virtual-machine-manager-node-common: TCP Port 16514

univention-virtual-machine-manager-node (1.0.1-3) unstable; urgency=low
Comment 20 Sönke Schwardt-Krummrich univentionstaff 2011-11-10 10:59:46 CET
(In reply to comment #19)
> Es wurden weitere Firewall-Regeln aktiviert:
> univention-virtual-machine-manager-node-xen: TCP Port 8002
> univention-virtual-machine-manager-node-xen: TCP Port 8002
> univention-virtual-machine-manager-node-kvm: TCP Ports 49152 bis 49215
> univention-virtual-machine-manager-node-common: TCP Port 16514
univention-virtual-machine-manager-node-kvm: TCP Ports 5900 bis 5999
univention-virtual-machine-manager-node-xen: TCP Ports 5900 bis 5999

univention-virtual-machine-manager-node (1.0.1-6) unstable; urgency=low
Comment 21 Sönke Schwardt-Krummrich univentionstaff 2011-11-10 11:00:17 CET
Das Executable-Flag wird jetzt während des Updates von 
/etc/init.d/univention-iptables.disabled entfernt.
Comment 22 Felix Botner univentionstaff 2011-11-11 10:18:43 CET
Changelog Eintrag vorhanden.

OK - beim update wird /etc/rc2.d/S15univention-iptables entfernt, das init 
     Script wird umbenannt und ist nicht mehr ausführbar 
     ls -la univention-iptables.disabled 
     -rw-r--r-- 1 root root 1880  2. Aug 2010  univention-iptables.disabled

OK - Bei updates ist security/packetfilter/defaultpolicy ACCEPT, bei 
     Neuinstallationen REJECT

OK - Anfragen von localhost werden immer erlaubt
     ucr set security/packetfilter/package/univention-apache/tcp/80/all="REJECT"
     Setting security/packetfilter/package/univention-apache/tcp/80/all
     File: /etc/security/packetfilter.d/10_univention-firewall_start.sh
     File: /etc/security/packetfilter.d/80_univention-firewall_policy.sh
     -> /etc/init.d/univention-firewall restart
     Stopping Univention iptables configuration::.
     Starting Univention iptables configuration::.
     root@slave:/etc/security/packetfilter.d# telnet 10.200.7.146 80
     Trying 10.200.7.146...
     Connected to 10.200.7.146.
     Escape character is '^]'.

OK - /etc/security/packetfilter.d//50_local.sh wird beachtet

OK - security/packetfilter/defaultpolicy wird beachtet

OK - security/packetfilter/use_packages funktioniert (keine Regeln
     der Pakete)

OK - security/packetfilter/disabled funktioniert (Firewall
     kann nicht mehr gestartet werden)

OK - Die UCR Variablen (für Pakete) funktionieren 
     ucr set security/packetfilter/package/univention-apache/tcp/80/all="REJECT"
     @10.200.7.145-> telnet 10.200.7.144 80
     Trying 10.200.7.144...
     telnet: connect to address 10.200.7.144: Connection refused

OK - Die Variablen für Benutzer funktionieren (überschreiben die Paket
     Variablen)
     -> ucr get security/packetfilter/package/univention-apache/tcp/80/all
     ACCEPT
     -> ucr get security/packetfilter/dummy/tcp/80/all 
     REJECT
     10.200.7.145-> telnet 10.200.7.144 80
     Trying 10.200.7.144...
     telnet: connect to address 10.200.7.144: Connection refused

An Diensten wurden nur kpasswd, Replication, ldap, ssh, imap(s)/pop(s)/smtp(s), login geprüft. Sollte speziellere Dienste noch Probleme verursachen da benötigte Ports nicht offen sind, einfach diese Bug wieder öffnen.
Comment 23 Felix Botner univentionstaff 2011-11-23 14:36:31 CET
In univention-ftp wird folgendes gesetzt:

ucr set \
        security/packetfilter/package/univention-base-files/tcp/20/all=ACCEPT \
        security/packetfilter/package/univention-base-files/tcp/20/all/en="FTP" \
        security/packetfilter/package/univention-base-files/tcp/21/all=ACCEPT \
        security/packetfilter/package/univention-base-files/tcp/21/all/en="FTP"


Die Variablen sollten wohl besser univention-ftp heißen.
Comment 24 Sönke Schwardt-Krummrich univentionstaff 2011-11-23 15:38:43 CET
(In reply to comment #23)
> In univention-ftp wird folgendes gesetzt:
> 
> ucr set \
>         security/packetfilter/package/univention-base-files/tcp/20/all=ACCEPT \
>         security/packetfilter/package/univention-base-files/tcp/20/all/en="FTP"
> \
>         security/packetfilter/package/univention-base-files/tcp/21/all=ACCEPT \
>         security/packetfilter/package/univention-base-files/tcp/21/all/en="FTP"

s/base-files/ftp/ → FIXED
Comment 25 Felix Botner univentionstaff 2011-11-23 15:56:22 CET
(In reply to comment #24)
> (In reply to comment #23)
> > In univention-ftp wird folgendes gesetzt:
> > 
> > ucr set \
> >         security/packetfilter/package/univention-base-files/tcp/20/all=ACCEPT \
> >         security/packetfilter/package/univention-base-files/tcp/20/all/en="FTP"
> > \
> >         security/packetfilter/package/univention-base-files/tcp/21/all=ACCEPT \
> >         security/packetfilter/package/univention-base-files/tcp/21/all/en="FTP"
> 
> s/base-files/ftp/ → FIXED

OK

Ersatz für univention-ftp wird entpackt ...
univention-ftp (5.0.1-5.30.201111231534) wird eingerichtet ...
Create security/packetfilter/package/univention-ftp/tcp/20/all
Create security/packetfilter/package/univention-ftp/tcp/20/all/en
Create security/packetfilter/package/univention-ftp/tcp/21/all
Create security/packetfilter/package/univention-ftp/tcp/21/all/en
File: /etc/security/packetfilter.d/10_univention-firewall_start.sh
Comment 26 Felix Botner univentionstaff 2011-11-23 16:54:26 CET
univention-snmpd setzt 
security/packetfilter/package/univention-printserver/tcp/161/all/en=
Comment 27 Sönke Schwardt-Krummrich univentionstaff 2011-11-23 17:37:19 CET
(In reply to comment #26)
> univention-snmpd setzt 
> security/packetfilter/package/univention-printserver/tcp/161/all/en=

Fixed in univention-snmpd (4.0.0-9) unstable; urgency=low
Comment 28 Felix Botner univentionstaff 2011-11-24 10:37:58 CET
ok

univention-snmpd (4.0.0-10.29.201111240918) wird eingerichtet ...
Multifile: /etc/snmp/snmpd.conf
File: /etc/default/snmpd
Create security/packetfilter/package/univention-snmpd/tcp/161/all
Create security/packetfilter/package/univention-snmpd/tcp/161/all/en
Create security/packetfilter/package/univention-snmpd/udp/161/all
Create security/packetfilter/package/univention-snmpd/udp/161/all/en
Create security/packetfilter/package/univention-snmpd/tcp/162/all
Create security/packetfilter/package/univention-snmpd/tcp/162/all/en
Create security/packetfilter/package/univention-snmpd/udp/162/all
Create security/packetfilter/package/univention-snmpd/udp/162/all/en
File: /etc/security/packetfilter.d/10_univention-firewall_start.sh
Comment 29 Sönke Schwardt-Krummrich univentionstaff 2011-12-13 15:50:29 CET
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer
neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert
werden: "Clone This Bug"