Cisco Firepower Release 6.7

Veröffentlicht am November 5, 2021 von bho

Wichtige Neuerung aus meiner Sicht

Manage FTD on a data interface
- Ein sehr nützliches Feature für Remote Deployments
- Das Outside-Interface (Data) kann jetzt auch als Management-Interface für die Verbindung zum Firepower Management Center verwendet werden
Update the FMC IP address on the FTD
AnyConnect module support for RA VPN
AnyConnect management VPN tunnels for RA VPN
Single sign-on for RA VPN
- SAML 2.0
- Super für Azure AD Implementierungen
FTD RA VPN now supports LDAP authorization using LDAP attribute maps.
Virtual Tunnel Interface (VTI) and route-based site-to-site VPN
URL filtering and application control on traffic encrypted with TLS 1.3 (TLS Server Identity Discovery)
Configuration rollback
Deploy intrusion and file policies independently of access control policies
FMC single sign-on for external users

Vor dem Upgrade gilt es zu beachten, dass der Firepower User Agent ab diesem Release nicht mehr unterstützt wird, und auch einige Hashing- und Verschlüsselungsmethoden, die als nicht mehr sicher gelten, müssen vor dem Update migriert werden.

Deprecated Features in Version 6.7

Cisco Firepower User Agent software and identity source
Less secure Diffie-Hellman groups, and encryption and hash algorithms

Alle Neuerung im Detail findet man unter:

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

Private-VLAN Trunk-Port Typen

Veröffentlicht am August 30, 2021September 27, 2021 von bho

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

int gi0/24
    switchport mode trunk

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

int gi0/24
    switchport mode private-vlan trunk
    !switchport private-vlan trunk native vlan 100
    switchport private-vlan allowed vlan 20,30
    switchport private-vlan association trunk 10 20,30

If there is no native VLAN configured, all untagged packets are dropped

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

int gi0/24
    switchport mode private-vlan trunk promiscuous
    switchport private-vlan mapping trunk 10 20,30
    switchport private-vlan trunk allowed 10,40

Alle gewünschten primary (VLAN-ID 10) und regular VLANs (VLAN-ID 40) mit „allowed“-Befehl angeben

Verfiy

show vlan
show interface gi0/24 switchport

Quellen:

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

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9200/software/release/16-12/configuration_guide/vlan/b_1612_vlan_9200_cg/configuring_private_vlans.html

HomeKit-Zugriff über getrennte VLANs durch Multicast Forwarding

Veröffentlicht am Juni 30, 2021Juni 30, 2021 von bho

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

Veröffentlicht am April 14, 2021August 23, 2021 von bho

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.

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

Veröffentlicht am März 29, 2021 von bho

Neues Management Tool für Aruba Switches.

„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

Veröffentlicht am Februar 3, 2021August 23, 2021 von bho

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

Veröffentlicht am Januar 4, 2021August 23, 2021 von bho

Methode A

Migration-Wizard

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

Methode B

AP Handover

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

Methode C

Manual „Forget“ Migration

Controller Installation über den UniFi Setup Wizard
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
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

Controller Installation über den UniFi Setup Wizard
SSH-Verbindung zum AP herstellen und auf Werkseinstellungen zurücksetzen:
sudo syswrapper.sh restore-default
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

Veröffentlicht am Oktober 27, 2020August 23, 2021 von bho

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

Veröffentlicht am August 17, 2020August 23, 2021 von bho

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

Veröffentlicht am August 5, 2020August 23, 2021 von bho

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