Blog

Private-VLAN Trunk-Port Typen

Standard Trunk Ports

  • Zwischen PVLAN-Switches
  • Überträgt alle VLAN Typen: reguläre VLANs, Primary-VLANs und Secondary-VLANs (Isolated oder Commuity)
  • Beide Switches müssen Private-VLANs unterstützen und gleich konfiguriert sein

Isolated PVLAN Trunk Ports

  • Zu Non-PVLAN Switches
  • Pakete werden nicht mit dem Primary-VLAN getagged sondern mit dem Secondary-VLAN
  • Auf Non-PVLAN Switches kann dann das Secondary-VLAN, zum Beispiel, als ein gewöhnliches Access-VLAN verwendet werden
  • Um weiterhin eine Trennung der Ports auf einem Non-PVLAN Switch zu ermöglichen könnte „Switchport Portected“ verwendet werden

Promiscuous PVLAN Trunk Ports

  • Zu Non-PVLAN Router
  • Pakete werden mit dem Primary-VLAN getagged
  • Zu Routern oder Firewalls die keine Private-VLANs unterstützen, kann dann das Primary-VLAN ganz normal als L3 Routing-Interface konfiguriert werden

Quelle: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/54sg/configuration/guide/config/pvlans.html

HomeKit-Zugriff über getrennte VLANs durch Multicast Forwarding

Geräte

  • Firewall: FortiGate 40F
  • Wifi: UniFi AC Pro Accesspoints
  • Switch: HPE Aruba 2530-8G-PoE
  • Schalter: Shelly Relais mit Open Source HomeKit Firmware
  • Licht: Philips Hue (Bridge + Lampen)
  • Tür: Robin ProLine Doorbell
Home App Zugriff in das segmentierte IoT VLAN

Aufbau

Konfiguration

1. Enable Multicast Forwarding

Fortigate CLI

get system settings

multicast-forward   : enable

multicast-ttl-notchange: enable

Fortigate GUI

  • „Multicast Enhancement“ IGMPv3 im UniFi Controller muss nicht aktiviert werden, wenn Multicast Forwarding auf der ForitGate verwendet wird

2. MultiCast Policy

  • Multicast von und zu VLAN 1 (LAN / PRIVAT) und VLAN 2 (IOT)
  • mDNS spielt bei der HomeKit Kommunikation eine wichtige Rolle
  • Catch All Regeln zum Troubleshooting aktivieren

3. Firewall Policy

  • Firewall Regeln zwischen den Netzen und Geräten
  • Die verwendeten Ports habe ich meistens über das Firewall-Log herausgesucht

Hinweise

  • Wenn vorhanden: vorab Apple TV ausschalten um sicher zu gehen, dass die HomeKit-Geräte nicht über das Internet mit der Apple TV Box als HomeKit-Zentrale kommunizieren
  • Wichtig: Wenn man mehrere iOS Geräte im Netzwerk hat kann es sein, dass das Gerät zum Hinzufügen in der Home App auf dem anderen erscheint!

Probleme

  • Robin Klingel hängt bzw. ist verzögert und sendet keine Benachrichtigung aufs Smartphone
    • Workaround: Neuaufbau der IPv4 Sessions durch öffnen der Home App
      • danach funktioniert die Robin Doorbell wieder normal
    • Test: Robin Doorbell im VLAN 1 behebt die Probleme
    • To Do: Das HomeKit-Protokoll baut ein eigenständiges IPv6 Kommunikationsnetz auf. Durch die Trennung wird nur IPv4 über die Firewall geroutet. Eine zusätzliche IPv6 Konfiguration der Firewall könnte das Problem lösen.

Troubleshooting

Logging

FortiGate GUI => Log & Report => Multicast Traffic

FortiGate GUI => Log & Report => Forward Traffic

Debugging

FortiGate CLI# diagnose sys mcast-session list

Packet Capture

FortiGate GUI => Network => Packet Capture

Links

https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/968606/configuring-multicast-forwarding

https://kb.fortinet.com/kb/documentLink.do?externalID=FD45560

https://medium.com/@gepeto42/using-homekit-devices-across-vlans-and-subnets-aa5ae1024939

Komisches VLAN Verhalten beim Cisco Catalyst 9800 Wireless Controller

Bei der Durchsicht der Cisco Catalyst 9800 Wireless Controller Dokumentationen bin ich auf eine sehr interessante Einstellung gestoßen, die ich mit euch teilen möchte.

Im „Policy Profile“ unter „Access Policies“ gibt es ein Feld zur Einstellung des VLANs. So weit, so klar. Aber jetzt wird es spannend: Hier kann man nicht nur die VLAN-ID konfigurieren, sondern auch einen VLAN-Namen! Und je nachdem was eingestellt wird, verhält sich die Zuweisung anders.

Access Policies
(Bild: Cisco)

Cisco erklärt es so:

The behavior is different depending on the AP mode. For an AP in local mode/Flex Central switching:

●      Specifying vlan-name = default, client is assigned to VLAN 1

●      Using vlan-id 1, a client is assigned to the wireless management VLAN

There is a warning to remind a user of this.

For an AP in FlexConnect local switching mode:

●      Specifying vlan-name = default, client is assigned to VLAN 1

●      Using vlan-id 1, a client is assigned to the FlexConnect native VLAN

By default, if the user does not configure anything under the policy profile, the WLC assigns vlan-id 1 so clients will use the wireless management VLAN in local mode and the AP native VLAN for FlexConnect.

Quelle: https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9800-series-wireless-controllers/guide-c07-743627.html#Networkcontrollersettings

Ich hoffe ich konnte euch hiermit ein paar graue Haare, für das nächste Wireless Controller Deployment, ersparen! Happy networking!

Aruba NetEdit

Neues Management Tool für Aruba Switches.

NetEdit Test-Installation

„The NetEdit product is a browser-based client/server application. The NetEdit server is provided as an Open Virtual Appliance (OVA). The NetEdit application uses a web browser-based user interface and provides automation of search, edit, validation, deployment, and audit for network configurations. It provides intelligent assistance and continuous validation to help ensure that device configurations are consistent, compliant, and error free. NetEdit can be used without retraining by leveraging existing netoworking knowledge and experience with switch configurations. This enables administrators to automate switch configuration change workflows without any programming.“

NetEdit Datasheet – https://www.arubanetworks.com/assets/_de/ds/DS_NetEdit.pdf

DHCP-Relay auf Aruba Switches konfigurieren

Config

Der DHCP-Relay Agent ist per Default eingeschaltet und muss nur aktiviert werden falls in der Running-Config „no dhcp-relay“ sichtbar ist.

HP Switch(config)# dhcp-relay

Relay-Funktion am gewünschten VLAN konfigurieren und als IP-Adresse den DHCP-Server angeben. Zur Eingabe eines sekundären DHCP-Servers einfach den Befehl wiederholen.

HP Switch(config)# vlan 1
HP Switch(vlan-1)# ip helper-address 1.2.3.4

Troubleshoot

HP Switch# show ip helper-address vlan 1
HP Switch# display dhcp relay statistics

Debug

Wireshark Capture Filter für DHCP Frames

udp port 68 or port 67

Unifi Controller Migration

Methode A

Migration-Wizard

https://help.ui.com/hc/en-us/articles/115002869188-UniFi-Migrating-Sites-with-Site-Export-Wizard

Methode B

AP Handover

  1. Konfigurations-Backup importieren
    https://help.ui.com/hc/en-us/articles/204952144-UniFi-How-to-Create-and-Restore-a-Backup#3
  2. Am alten Controller: Neue Inform URL der Accesspoints konfigurieren

Methode C

Manual „Forget“ Migration

  1. Controller Installation über den UniFi Setup Wizard
  2. Discover-Methode zum neuen Controller umstellen (Zum Beispiel über DNS-Record)
    https://help.ui.com/hc/en-us/articles/204909754-UniFi-Device-Adoption-Methods-for-Remote-UniFi-Controllers
  3. Händische Migration der Access Points
    • Alter Controller => Devices => AP => Configure => Manage => Forget
    • Der AP setzt sich dadurch zurück, rebootet und findet dann zum neuen Controller
    • Am neuen Controller den AP adaptieren
    • Diese Schritte bei allen Accesspoints wiederholen
Hinweis

Um den Accesspoint zu „vergessen“ könnte dieser auch über die physische Reset-Taste oder über SSH auf Werkseinstellungen zurückgesetzt werden.

https://help.ui.com/hc/en-us/articles/205143490-UniFi-How-to-Reset-Devices-to-Factory-Defaults

Methode D

Manual SSH Migration

  1. Controller Installation über den UniFi Setup Wizard
  2. SSH-Verbindung zum AP herstellen und auf Werkseinstellungen zurücksetzen:
    sudo syswrapper.sh restore-default
  3. Nach dem Reset erneut eine SSH-Verbindung zum Accesspoint aufbauen und danach die Inform URL konfigurieren:
    set-inform http://ip-of-controller:8080/inform

Cisco Firepower Release 6.6.1

Hier die wichtigsten Neuerung der aktuellen FTD Firewall-Software von Cisco, für euch zusammengefasst:

  • FMCv benötigt Minimum 28GB RAM: 32GB empfohlen
  • 6.6 ist der letzte Major Release der den Cisco Firepower User Agent unterstützt
  • Multi-instance Clustering
  • VRF Support
  • DTLS 1.2 Unterstützung für Remote Access VPNs (AnyConnect)
  • Site-to-site VPN IKEv2 support for multiple peers
  • Time-based access rules
  • Schnellere Datenbank für Connection and Security Intelligence Events
    • Darum wird mehr RAM benötigt
  • Neues Webinterface („Light theme“) wird zum Standard
  • Firepower Device Manager: PPPoE Support

Alle neuen Features im Detail:

https://www.cisco.com/c/en/us/td/docs/security/firepower/660/relnotes/firepower-release-notes-660/features.html

https://www.cisco.com/c/en/us/td/docs/security/firepower/660/66x/relnotes/firepower-release-notes-66x/features.html

AnyConnect Auto Connect Script

AnyConnect Verbindung herstellen über Script unter Windows.

ACHTUNG! Bei dieser Methode wird der VPN-Benutzer und das Passwort im Klartext auf der lokalen Festplatte gespeichert. Aus Sicherheitsgründen würde ich eine zertifikatbasierte Authentifizierung empfehlen.

1. Textdatei mit Verbindungsdaten

connect MYVPNGW
Username
Password

2. Batch-Script

@echo off
set "host=192.168.1.1"

REM Check if internal host is available.
ping -n 1 "%host%" | findstr /r /c:"[0-9] *ms"

if %errorlevel% == 0 (
    REM echo Success.
    REM echo CONNECTED - %time% %date%>> %TEMP%\anyconnect_script_log.txt
) else (
    REM echo FAILURE.
    taskkill /f /im vpnui.exe
    "%ProgramFiles(x86)%\Cisco\Cisco AnyConnect Secure Mobility Client\vpncli.exe" -s < %USERPROFILE%\myvpn.txt
    REM echo RECONNECT- Script executed at %time% %date%>> %TEMP%\anyconnect_script_log.txt
    start "" "%ProgramFiles(x86)%\Cisco\Cisco AnyConnect Secure Mobility Client\vpnui.exe"
)

WebVPN Sicherheitslücke in ASA und FTD Firewalls

Eine Sicherheitslücke in den Firewalls von Cisco ermöglicht einem Angreifer aus der Ferne Dateien aus AnyConnect und WebVPN (Clientless SSL VPN Portal) auszulesen.

Bei dem Angriff gibt es keinen Zugriff auf Systemdateien des zugrundeliegenden Firewall-Betriebssystems. Laut Cisco hat ein Angreifer aber Lesezugriff auf „WebVPN configuration, bookmarks, web cookies, partial web content, and HTTP URLs.“

Cisco hat die Sicherheitslücke als „High“ eingestuft (Critical wäre die höchste Warnstufe). Für jemanden der nur AnyConnect im Einsatz hat sollte es nicht zu schlimm sein, wenn Standard-Konfigurationsdateien aus dem WebVPN ausgelesen werden können, da dadurch keine sensitiven Informationen abgegriffen werden können.

Ein Update auf eine gepatchte Firewall-OS Version würde ich trotzdem empfehlen. Wie sich oft zeigt können vermeintlich harmlose Sicherheitslücken für weitere kritische Attacken ausgenutzt werden. Auch bei dieser Sicherheitslücke hat der Hersteller weitere Informationen veröffenltich, die jetzt viel bedrohlicher klingen: „As an example, this could allow an attacker to impersonate another VPN user and establish a Clientless SSL VPN or AnyConnect VPN session to the device as that user.“

Ich bin gespannt ob die ursprüngliche Einstufung des CVSS Scores bald auf „kritisch“ geändert wird und noch weitere Details bekannt werden, ob Angreifer das genannte Beispiel bereits ausnutzen.

Link zum Security Advisory und einer Übersicht der gepatchten Firewall Betriebssystemversionen:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ro-path-KJuQhB86

Firepower Remote IP Change

Wechsel der ISP Public-IPs für das Management- und Outside-Interface für Cisco Firepower Appliances mit FTD.

  1. FTD: SSH zur aktuellen Management-IP
    zum Beispiel mit Putty oder CLI "ssh admin@1.1.1.1"
  2. FTD: Aktuelle Netzwerkkonfiguration anzeigen
    show network
  3. FTD: Neue Management IP Einstellungen konfigurieren
    configure network ipv4 manual 2.2.2.1 255.255.255.248 2.2.2.6
  4. FMC: Die Management IP im Firepower Management Center ändern (1.1.1.1 => 2.2.2.1)
    Devices => Device Management => Edit
    Device => Management => Edit
  5. FTD: SSH zur neuen Management-IP
    zum Beispiel mit Putty oder CLI "ssh admin@1.1.1.1"
  6. FTD: Status überprüfen
    expert => sudo sftunnel_status.pl
  7. FMC: Neue Outside-IP konfigurieren
    Device => Outside-Interface: 2.2.2.2 => Deploy
  8. GEDULD! (Hat bei mir ca. 10min gedauert bis der Status im FMC und FTD wieder „grün“ war.)