Konfigurationsbeispiel eines Notebooks für den Einsatz in unterschiedlichen Netzen mit 'firewalld' und 'NetworkManager'

Aus Linupedia.org
Wechseln zu: Navigation, Suche
Höhe=24px
Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

--Gehrke (Diskussion) 22:09, 24. Okt. 2016 (CEST)

Im Folgenden soll eine Beispielkonfiguration für ein Notebook gezeigt werden, welches auf den Einsatz in Netzwerken mit unterschiedlichen Sicherheitsanforderungen eingerichtet ist. Dieses System soll in vertrauenswürdigen Netzen (wie beispielsweise dem eigenen LAN oder WLAN) eine bestimmte Netzwerkfunktionalität wie SSH oder den File-Daemon von Bacula auf diesem Notebook erlauben. In anderen Netzen dagegen soll nur eine sehr eingeschränkte Netzwerk-Konnektivität erlaubt sein.

Dabei soll die Zuordnung anhand der Auswahl des Netzwerkes im NetworkManager erfolgen, welche bei bekannten Netzen in der Regel automatisch durchgeführt wird. Beispielsweise beim Wechsel vom (als sicher eingestuften) heimischen LANs in ein unsicheres öffentliches WLAN nach einem Ruhezustand des Notebooks.

Der Dienst firewalld kennt für die Gruppierung von Sicherheitsanforderungen das Konzept der Zonen. Dabei enthält die Definition der Zone eine vollständige Beschreibung, welche Netzwerkdienste von oder zu dem jeweiligen System zulässig sind. Es werden von der Distribution eine Reihe von Zonen-Definitionen mitgeliefert, welche sich im Grad der Netzwerk-Freigibigkeit unterscheiden. Für das vorliegende Beispiel werden 2 vorgefertigte Zonen-Definitionen (work und public) kopiert und entsprechend der Anforderungen angepasst.

Die gewünschten Eigenschaften der Zonen sind:

  • work: SSH und bacula-fd nur vom bacula-Server (172.16.21.10)
  • public: Keinerlei Zugriff (auch kein SSH)


Dieses Beispiel basiert auf der Distribution CentOS 7. Um eine effektive und eindeutig dokumentierbare Vorgehensweise darzustellen, soll für alle administrativen Zugriffe auf die verwendeten Tools das jeweilige Command Line Interface (CLI) verwendet werden.


Konfiguration

Um dieses Ziel zu erreichen, sind zwei Subsysteme zu konfigurieren:

  • firewalld: Dieser Dienst übernimmt die dynamische Konfiguration und Steuerung der lokalen Firewall. Die von der Distribution vorgegebenen Templates (XML) für die beiden Zonen werden kopiert und angepasst, so dass die Konfiguration persistent zur Verfügung steht.
  • NetworkManager: Der Dienst konfiguriert und steuert die Netzwerkanbindung dynamisch. Bekannten Netzen soll anhand der UUID die Zone 'work' zugewiesen werden. Andere Netze behalten die Default-Zone 'public'.

firewalld

Im ersten Schritt werden die durch die Distribution vorgegebenen Zonen-Definitionen kopiert. Die folgenden Änderungen erfolgen auf den hier erzeugten Kopien:

# mkdir /etc/firewalld/zones
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/
# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/

Die geänderten Definitionen enthalten die Umsetzung für die oben genannten Anforderungen:

# cat /etc/firewalld/zones/work.xml 
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Work</short>
  <description>For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <rule family="ipv4">
    <source address="172.16.21.10"/>
    <service name="bacula"/>
    <accept/>
  </rule>
</zone>
# cat /etc/firewalld/zones/public.xml 
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
</zone>

Neustart der Firewall:

# systemctl restart firewalld.service

NetworkManager

Vorhandene Netze anzeigen:

# nmcli connection show
NAME                                        UUID                                  TYP              GERÄT  
Freifunk                                    fec93f72-3488-4008-abfc-ec372d6f8806  802-11-wireless  --     
WLAN1                                       82be9628-2709-495f-a389-d209b74fcd05  802-11-wireless  --     
VPN1                                        ec0aa457-d3ec-4089-8c8f-1a53a8a33374  vpn              --     
LAN1                                        ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8  802-3-ethernet   --     
enp2s0                                      8c1c5b53-0c80-44df-8c49-678b6d122d42  802-3-ethernet   enp2s0 
WLAN2                                       1e906b64-4909-4dbe-8d81-705ea64767b4  802-11-wireless  wlp8s0 
VPN2                                        23c0b2c5-b5a6-4e82-95b2-9b198074391d  vpn              --

Man erkennt, dass das Notebook kabelgebunden über das Interface enp2s0 am Netzwerk enp2s0 und per WLAN über wlp8s0 am eigenen Funk-Netzwerk WLAN2 hängt.

Die Zuordnung der Zone 'work' an beide Netze erfolgt über die UUID der Netze im NetworkManager:

# nmcli connection modify 8c1c5b53-0c80-44df-8c49-678b6d122d42 connection.zone work
# nmcli connection modify 1e906b64-4909-4dbe-8d81-705ea64767b4 connection.zone work

Anschließend werden die Verbindungen noch aktiviert:

# nmcli connection up uuid 8c1c5b53-0c80-44df-8c49-678b6d122d42
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/38)
# nmcli connection up uuid 1e906b64-4909-4dbe-8d81-705ea64767b4
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/39)

Überprüfung

Abschließend ist die Konfiguration zu überprüfen.

Die Anzeige im Falle der Verbindung in den heimischen Netzen zeigt, dass die beiden Interfaces enp2s0 und wlp8s0 der Zone 'work' zugeordnet sind:

# firewall-cmd --get-active-zones
work
  interfaces: enp2s0 wlp8s0

Anzeige der Konfiguration dieser Zone:

# firewall-cmd --zone=work --list-all
work (active)
  interfaces: enp2s0 wlp8s0
  sources: 
  services: ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules: 
        rule family="ipv4" source address="172.16.21.10" service name="bacula" accept

Dagegen sollte bei einer Verbindung zu einem anderen Netzwerk die Default-Zone 'public' zugeordnet sein. Im folgenden Beispiel besteht ausschließlich eine Verbindung zum WLAN 'Freifunk':

# nmcli connection show
NAME                                        UUID                                  TYP              GERÄT  
Freifunk                                    fec93f72-3488-4008-abfc-ec372d6f8806  802-11-wireless  wlp8s0 
enp2s0                                      8c1c5b53-0c80-44df-8c49-678b6d122d42  802-3-ethernet   --     
WLAN1                                       82be9628-2709-495f-a389-d209b74fcd05  802-11-wireless  --     
VPN1                                        ec0aa457-d3ec-4089-8c8f-1a53a8a33374  vpn              --     
LAN1                                        ee9ee0aa-57b9-4c5d-9c76-d2722986c5d8  802-3-ethernet   --     
enp2s0                                      8c1c5b53-0c80-44df-8c49-678b6d122d42  802-3-ethernet   -- 
WLAN2                                       1e906b64-4909-4dbe-8d81-705ea64767b4  802-11-wireless  -- 
VPN2                                        23c0b2c5-b5a6-4e82-95b2-9b198074391d  vpn              --

Dementsprechend zeigt die Prüfung, dass für das WLAN-Interface wlp8s0 die Zone 'public' gesetzt wurde und das derzeit nicht verbundene enp2s0 ohne Zuordnung verbleibt:

# firewall-cmd --get-active-zones
public
  interfaces: wlp8s0

Es ist zu erkennen, dass SSH im Bereich services nicht zugelassen ist:

# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: wlp8s0
  sources: 
  services: 
  ports: 
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

Dabei erfolgt die Zuordnung der Zonen automatisch in Reaktion auf die Auswahl des Netzwerkes im NetworkManger. Eine manuelle Auswahl der Zone ist hierfür nicht erforderlich.

Links