Sophos Firewall v23: Fortschritte, Grenzen und offene Fragen

Seit knapp zwei Wochen teste ich Sophos Firewall v23 in meinem Homelab. Meine erste Bilanz ist gemischt: Die neue Regelansicht gefällt mir, und die REST API ist ein guter Ansatz. Gleichzeitig wirkt die Oberfläche weiterhin wie ein Produkt, dessen einzelne Bereiche zu unterschiedlichen Zeiten entwickelt wurden. Eine neue Tabelle allein macht daraus noch keine durchgehend moderne Administration.

Das beschäftigt mich bei diesem Release mehr als die Zahl der neuen Funktionen. Ich möchte Regeln nachvollziehbar pflegen, wiederkehrende Aufgaben automatisieren und mich zwischen den Bereichen bewegen können, ohne jedes Mal eine andere Bedienlogik vorzufinden. v23 macht dabei Fortschritte, lässt aber einige grundlegende Wünsche offen. Hier ist mein erster Erfahrungsbericht, ergänzt um die technische Einordnung der größeren Änderungen.

Sophos Firewall v23 befindet sich aktuell im Early Access Program (EAP). Wie in den vergangenen Jahren rechne ich mit der finalen Version im Dezember 2026. Ich teste die Firmware seit knapp zwei Wochen in meinem Homelab, aber noch nicht produktiv. Meine Eindrücke zur Bedienung sind eigene Beobachtungen; Leistungsangaben zu HA und WAF stammen von Sophos.

Regelverwaltung: Ein besserer Filter ersetzt nicht jede Gruppenansicht

Die neue Regelansicht gehört zu den Änderungen, die mir im Homelab gefallen. Die durchgehende Tabelle mit anpassbaren und fixierbaren Spalten, Suche und Filtern ist für mich ein guter Schritt. Ziele, Dienste und Schutzprofile nebeneinander darstellen zu können, ist sinnvoller, als für jeden Vergleich mehrere Regeln öffnen zu müssen. Die dauerhaft sichtbare Geräteidentität und der HA-Status passen ebenfalls zu einer Administration, in der man den Überblick behalten muss.

Der Streit um Gruppen ist trotzdem nachvollziehbar. Im frühen Feedback kritisieren Administratoren, dass die neue Ansicht die vertrauten aufklappbaren Gruppen nicht gleichwertig abbildet. Für umfangreiche Regelwerke kann eine lange Tabelle trotz Filtermöglichkeiten unübersichtlich sein. Das ist eine Frage der sicheren Bedienbarkeit, nicht bloß des persönlichen Geschmacks.

Die separate Sophos-Erklärung zur Regelverwaltung präzisiert: Bestehende Gruppen und Regelreihenfolge bleiben erhalten, die neue Tabelle zeigt Gruppenzugehörigkeiten als Spalte, und beide Ansichten sind derzeit umschaltbar. Gruppen werden nicht entfernt. Die neue Ansicht stellt sie anders dar. Diskutierte tagbasierte Organisationsformen sind eine mögliche Weiterentwicklung, keine zugesicherte Funktion des aktuellen Stands.

Mir gefällt die neue Ansicht, trotzdem verstehe ich die Kritik von Admins mit sehr großen Regelwerken. Bei Tausenden Regeln zählt besonders, ob Filter und Darstellung die tatsächlich wirksame Reihenfolge verständlich halten. Eine Gruppe ist keine eigene, von der globalen Reihenfolge unabhängige Sicherheitsbarriere.

Was mich nach diesen knapp zwei Wochen weiterhin stört, ist die fehlende Einheitlichkeit der Oberfläche. Design und Funktionsumfang passen nicht überall zusammen. Funktionen wie das Klonen sind nicht durchgehend nach derselben Logik verfügbar, und auch die responsive Darstellung ist nicht in allen Bereichen gleich gut umgesetzt. Das fällt gerade dann auf, wenn man zwischen verschiedenen Konfigurationsbereichen wechselt.

Von einem solchen Verwaltungswerkzeug erwarte ich, dass vergleichbare Aufgaben auch vergleichbar funktionieren. Wer das Regelwerk aufräumt oder ähnliche Konfigurationen mehrfach anlegt, braucht konsistente Bedienung. Eine einzelne gelungene Ansicht macht die Unterschiede im restlichen Produkt eher deutlicher. Hier wünsche ich mir von Sophos eine Überarbeitung über die Bereichsgrenzen hinweg.

HTTP/2 für WebAdmin ist willkommen, löst dieses Problem aber nicht. Es kann die Übertragung von Seitenelementen verbessern, besonders bei hoher Latenz. Es verändert weder die Bedienlogik noch automatisch die Dauer von Konfigurationsänderungen. Eine belastbare Vorher-nachher-Messung zur Geschwindigkeit lege ich mit diesem Erfahrungsbericht nicht vor.

REST API: Der Fortschritt liegt im überprüfbaren Ablauf

Die REST API halte ich für einen der sinnvollsten Ansätze in v23. Nicht jede wiederkehrende Verwaltungsaufgabe gehört in eine manuell bediente Oberfläche. Die Kombination aus API-Schlüsseln, OpenAPI 3.0 und einem integrierten Guide schafft eine brauchbare Grundlage für eigene Werkzeuge. Unter Administration > API access werden Schlüssel, Ablaufzeiten und erlaubte IP-Hosts verwaltet.

Der praktische Nutzen liegt für mich in kontrollierbaren Abläufen: Ein Werkzeug liest den vorhandenen Zustand, erkennt eine konkrete Abweichung, ändert gezielt einen Wert und fragt das gespeicherte Ergebnis erneut ab. So können sich auch wiederkehrende Aufgaben über mehrere Standorte nachvollziehbar organisieren lassen. Das ist ein sinnvoller Anwendungsfall, kein von mir bereits nachgewiesener Mehrstandort-Rollout.

Eine API allein macht eine Automation noch nicht zuverlässig. Ein nicht erreichbarer Standort muss als Fehler erscheinen. Wiederholungen dürfen keine doppelten Objekte erzeugen, und Teilfehler brauchen ein Protokoll. Genau an solchen Eigenschaften messe ich den Wert einer Integration.

API-Schlüssel gehören auf einen kontrollierten Automationshost, mit begrenzter Gültigkeit und eingeschränktem Netzwerkzugriff. Der interaktive Guide kann echte Anfragen an die Firewall senden. Schreibende Beispiele sind damit tatsächliche Konfigurationsänderungen und verdienen dieselbe Prüfung wie eine Änderung in der Oberfläche.

Offen bleibt für mich die vollständige Abdeckung bestehender Aufgaben. Vorhandene XML-Automationen lassen sich erst ersetzen, wenn die OpenAPI-Datei des konkreten Builds die benötigten Operationen tatsächlich beschreibt. Dass Sophos die WAF-Änderungen weiterhin ausdrücklich der XML API zuordnet, ist ein guter Grund, genauer hinzusehen. Mein Urteil zur REST API lautet deshalb: richtige Richtung, mit entscheidenden Details bei Abdeckung, Fehlerbehandlung und Berechtigungen.

Die WAF wird brauchbarer, bleibt aber eine begrenzte Ressource

Die Web Application Firewall erhält Aktionen pro Site-Path-Eintrag. Das ist praktische Funktionalität für veröffentlichte Anwendungen, die teilweise eine Lücke zur früheren SG/UTM9 schließt. Die vier Aktionen haben klar unterschiedliche Sicherheitswirkungen:

Eine Weiterleitung ist keine interne Backend-Umschaltung. Der Client bekommt ein anderes Ziel. Eine WebSocket-Ausnahme wiederum ist keine weitere Schutzstufe. Bei einer Anwendung mit geschütztem Portal und einem WebSocket-Kanal muss man deshalb bewusst entscheiden, welche Prüfung wo stattfindet. Eine funktionierende Verbindung sagt nichts darüber aus, ob der Verkehr inspiziert wurde.

Pro Site-Path-Route-Eintrag können bis zu 128 Pfade zusammengefasst werden. Das WAF-Regellimit beträgt standardmäßig 100 und lässt sich auf 200 erhöhen. Bestehende WAF-Regeln werden laut Leitfaden mit Protect als Standardaktion in das neue Modell migriert. Die Änderungen werden dort ausdrücklich für Oberfläche und XML API beschrieben. Daraus folgt keine automatische Zusage, dass jeder WAF-Workflow bereits über die neue REST API verfügbar ist.

Die zweite große Änderung betrifft die Verarbeitung: Sophos stellt die WAF auf Apache Event MPM um. Der Hersteller beschreibt eine bessere Nutzung der Worker und mehr Belastbarkeit bei parallelen Anfragen. Die im Launch-Beitrag genannten ungefähr 800 parallelen Anfragen beziehen sich auf eine mögliche Sättigung der bisherigen Architektur, nicht auf ein universelles altes Regellimit oder einen garantierten neuen Durchsatz.

Für mich sind die zusätzlichen Pfadaktionen ein greifbarer Fortschritt. Die Leistungsversprechen bewerte ich getrennt davon: Auch eine bessere Warteschlange kann eine Anwendung unbrauchbar langsam machen. Antwortzeiten, Fehlerquoten und Backend-Latenz zählen mehr als die Zahl akzeptierter Verbindungen. Einen WAF-Benchmark unter vergleichbarer Last liefere ich hier nicht. Mehr konfigurierbare Regeln bedeuten keine entsprechend größere Appliance.

Die neue HTTP/2-Unterstützung für WebAdmin sollte man ebenfalls nicht mit WAF-Protokollunterstützung verwechseln. Im verlinkten Reddit-Thread wird HTTP/2 für die WAF als Zukunftswunsch diskutiert. Eine Antwort beschreibt Interesse daran, aber keine Zusage. Daraus mache ich keine v23-Funktion, erst recht keine Zusage für HTTP/3.

Hochverfügbarkeit: 300 ms sind noch keine unterbrechungsfreie Anwendung

Die HA-Änderungen gehören für mich zu den interessantesten Punkten. Sophos nennt ein verkürztes Erkennungsfenster für Peer-Ausfälle: von vier Sekunden auf 300 Millisekunden. Daraus entsteht die Herstellerangabe einer ungefähr 13-fach schnelleren Erkennung.

Diese Zahl beschreibt die Ausfallerkennung. Sie ist keine Garantie, dass eine Telefonverbindung, ein VPN oder eine Anwendung nach 300 ms wieder normal arbeitet. Die Übernahme durch den verbleibenden Knoten, die Zustellung des Verkehrs durch benachbarte Geräte und das Verhalten bestehender Sitzungen gehören ebenfalls zum Ergebnis. Ein Ping allein bildet das schlecht ab.

Zusätzlich bezieht die HA-Überwachung bestimmte Hardwarekomponenten wie die SSD ein. Ein Knoten kann über den HA-Link noch antworten, obwohl sein Datenträger bereits Probleme verursacht. Hardwarezustand als Umschaltkriterium ist deshalb sinnvoll. Der anschließende Betrieb auf einem gesunden Knoten ersetzt allerdings weder die Ursachenanalyse noch den Austausch defekter Hardware.

Ebenso relevant ist die bevorzugte Verarbeitung der HA-Heartbeats über einen vom normalen Datenverkehr getrennten Verarbeitungspfad. Die Priorität passt sich laut Sophos an die Last an. Das soll verhindern, dass verspätete Lebenszeichen unter hoher CPU- oder Verkehrslast als Geräteausfall interpretiert werden. Der Leitfaden spricht von deutlich weniger verpassten Heartbeats und unerwarteten Umschaltungen, nicht von einer absoluten Immunität gegen Fehlumschaltungen.

Diese Architekturänderungen halte ich für sinnvoll. Eine verkürzte Erkennungszeit bringt allerdings wenig, wenn ein Cluster unter Last unnötig umschaltet. Für eine produktive Abnahme zählen deshalb beide Eigenschaften zusammen. Aus meinen bisherigen Homelab-Eindrücken leite ich keine gemessene HA-Unterbrechungszeit oder Aussage zur Stabilität unter Produktionslast ab.

DNS und Patchstatus: Zwei verschiedene Arten von Vertrauen

DNS over HTTPS verschlüsselt den Transport zum gewählten Resolver. DNSSEC prüft dagegen die Signaturkette signierter DNS-Daten. Die Verfahren ergänzen sich: DoH macht eine DNS-Antwort nicht allein authentisch, DNSSEC macht die Anfrage nicht vertraulich. Der Resolver sieht weiterhin, was er auflösen soll, und nicht jede Zone ist signiert.

Sophos beschreibt DoH zu Sophos oder einem generischen Anbieter und eine vereinfachte Aktivierung von DNS Protection. Daraus folgt nicht, dass alle Clients automatisch den vorgesehenen DNS-Weg verwenden. Browser mit eigenem DoH, interne Resolver und private Namensräume gehören in die Planung. Für mich zählt hier, dass interne und externe Namen weiter über den richtigen Weg aufgelöst werden und Filter sowie DNSSEC-Validierung nachvollziehbar entscheiden.

Die neue Hotfix-Ansicht ist weniger spektakulär, aber für den Betrieb sehr wertvoll. Unter Backup and Firmware werden angewandte Sicherheitsupdates mit CVE, Beschreibung, Datum, Schweregrad und Advisory-Link sichtbar. Der Leitfaden nennt außerdem Log Viewer, E-Mail-Benachrichtigungen und Central Firewall Reporting.

Eine Firmware-Versionsnummer allein beschreibt damit den Patchstand nicht vollständig. Ein Hotfix-Eintrag kann den Nachweis einer konkreten Korrektur erleichtern. Er beweist weder, dass jede Schwachstelle geschlossen wurde, noch, dass eine zuvor angreifbare Firewall nie kompromittiert war.

Wiederkehrende Firmware-Zeitpläne in Sophos Fusion ergänzen diese Transparenz durch gestaffelte Rollouts und Ausnahmen pro Firewall. Major-Updates können optional einbezogen werden. Für mich sollte eine Testgruppe zuerst kommen, danach die Prüfung der kritischen Funktionen und erst dann die nächste Gruppe. Automatisierung verkürzt Handarbeit; sie ersetzt keinen Wiederherstellungsplan.

DHCP, mDNS und Routing verdienen einen eigenen Abnahmetest

Der DHCP-Dienst wird auf die neue Control Plane umgestellt. Sophos beschreibt bessere Lease-Verarbeitung, größere Reservierungsbestände, eine vorgeschaltete Firewall-Prüfung gegen Floods und zusätzliche Einstellungen in der Oberfläche. Das ist keine bloß kosmetische Änderung. Gerade bei einem grundlegenden Dienst wie DHCP verdienen Leases, Verlängerungen, Reservierungen und spezielle Optionen Aufmerksamkeit. Eine erreichte Internetseite belegt nicht, dass auch PXE oder ein selten gestartetes Spezialgerät korrekt versorgt wird.

Der mDNS-Reflector ermöglicht Diensterkennung über ausgewählte VLANs beziehungsweise Subnetze mit IPv4 und IPv6. Dabei lassen sich Interfaces und Dienste auswählen. Er öffnet nicht automatisch die anschließende Datenverbindung. Ein Drucker kann sichtbar werden, während der Druckauftrag mangels passender Regel scheitert. Umgekehrt sollte ein Gästenetz nicht deshalb interne Geräte entdecken dürfen, weil die bequemste Einstellung alle Dienste reflektiert. Negative Tests gehören hier zur Abnahme.

Beim Routing aktualisiert Sophos FRR und ergänzt eine gemeinsame Konsole. BFD für BGP und statische Routen wird ausdrücklich als experimentell für Standalone-Deployments beschrieben. BFD erkennt Ausfälle von Weiterleitungspfaden und ist nicht mit dem HA-Heartbeat gleichzusetzen. Der experimentelle Status ist für mich ein klarer Grund, daraus noch keine produktive Abhängigkeit zu machen.

IPv6 IPoE, 4in6-Tunnel einschließlich IPIP/DS-Lite und VNE-bezogenes DDNS erweitern die Anschlussmöglichkeiten, unter anderem für Japans Xpass. Verbesserungen an Tunnelendpunkten sowie MTU/MSS sind nützlich, wenn der Provider dieses Modell verlangt. Daraus folgt keine pauschale Lösung aller IPv6-Themen. Für IONOS Cloud nennt Sophos die Bereitstellung eines offiziellen Images per Bring Your Own Image, ohne Marketplace-Eintrag und mit manuellem Lebenszyklusmanagement.

Identität: Das Firewall-Update liefert nicht alle Voraussetzungen mit

Die Entra-ID-Erweiterung betrifft Synchronized User ID im Zusammenspiel mit Sophos Endpoint. Sie ist nicht einfach eine neue Bezeichnung für die bereits bekannte Portalanmeldung. Der Leitfaden beschreibt hybride Umgebungen mit lokalem AD und Entra ID, Zuordnung über UPN beziehungsweise sAMAccountName und Windows-Endpoint-Unterstützung ab der genannten Endpoint-Version 2025.1. Eine Entra-ID-Umgebung allein liefert diese Erkennung nicht. Endpoint-Version, Lizenz und bestehende SSO-Konfiguration müssen passen.

Google Workspace wird als OpenID-Connect-Identity-Provider für Captive Portal, VPN Portal, Sophos Connect und WebAdmin beschrieben, einschließlich IdP-erzwungener MFA. Der Leitfaden nennt einen einzelnen IdP für einen jeweiligen Satz von Diensten. Anmeldung und Autorisierung bleiben getrennte Prüfungen: Ein gültiges Google-Konto darf nicht versehentlich Verwaltungsrechte erhalten.

Beim MFA-Onboarding kann der QR-Code per E-Mail zugestellt werden. Für neue Installationen ist das laut Leitfaden der Standard, bestehende und migrierte Installationen behalten den Portalweg. Unbenutzte Codes verfallen nach 24 Stunden. Ein QR-Code zur Registrierung enthält das für den Authenticator relevante Geheimnis; das Postfach und der Wiederholungsprozess müssen entsprechend geschützt werden. E-Mail ist nicht allein wegen des Transportwegs eine sichere Identitätsprüfung.

Für gemeinsam genutzte Server beschreibt Sophos SATC mit einem XDR Sensor neben einer bestehenden Endpoint- oder AV-Lösung. Das soll benutzerbezogene Regeln ermöglichen, obwohl mehrere Sitzungen dieselbe Server-IP teilen. Unterstützte Betriebssysteme, Lizenzierung und die konkrete Kombination mit Drittsoftware sind vor einem Rollout zu prüfen.

Die neue Chromebook-Erweiterung basiert auf Manifest V3 und ist für alle unterstützten SFOS-Versionen gedacht. Sie ist deshalb kein exklusiver Grund für ein v23-Upgrade. Bei gemeinsam genutzten Geräten interessiert mich vor allem, ob die Zuordnung nach Abmeldung und Benutzerwechsel zuverlässig endet.

KI und NDR: Die Entscheidung muss sichtbar bleiben

Der Firewall-Assistent in Sophos Fusion konzentriert sich in Phase 1 auf Firewall-Regeln. Er liest Konfiguration und beantwortet Fragen. Die gezielte Ausnahme: Er kann eine neue Regel anlegen, deaktiviert und am Tabellenende. Prüfung und Aktivierung bleiben beim Administrator. Sein Datenzugriff entspricht laut Leitfaden dem über Fusion SSO sichtbaren Umfang des Administrators.

Diese Begrenzung gefällt mir. Trotzdem muss ein Entwurf auf konkrete Objekte, Dienste, Benutzer, Sicherheitsprofile und Regelposition geprüft werden. Auch eine deaktivierte Regel ist bereits eine gespeicherte Konfigurationsänderung. Gute Formulierungen des Assistenten sind kein Sicherheitsnachweis.

Die Webkategorie Generative AI und passende Anwendungsfilter unterstützen die Kontrolle zugelassener KI-Dienste im Umfeld von Sophos AI Defense. Eine Domainfreigabe beantwortet aber nicht, welche Daten in einen Prompt gehören. Netzwerksteuerung ist keine vollständige inhaltliche Prüfung aller Uploads oder ein Ersatz für Datenklassifizierung. Zusätzliche Sophos-Dienste, Lizenzen und deren eigener Funktionsumfang müssen gesondert betrachtet werden.

Für NDR Essentials und NDR Active Threat Intelligence beschreibt Sophos zusätzliche Alarmierung ohne automatische Endpoint-Isolation beziehungsweise roten Heartbeat-Status. Das trennt Sichtbarkeit von unmittelbarer Sperrung. Es ist keine Aussage, dass sämtliche Active-Threat-Response-Aktionen abgeschaltet werden. Wenn die Reaktion ausbleibt, braucht der Alarm einen Verantwortlichen und einen Eskalationsweg.

Zu den kleineren Änderungen gehören ID-basierte Referenzen für E-Mail-Content-Control-Lists und versionierbare Webkategoriedefinitionen im Backend. Solche Details bekommen selten die große Bühne, können aber für konsistente Konfigurationen bei Updates und Wiederherstellungen relevant sein.

Vor dem Upgrade steht die Migration

Die wichtigste Änderung steht nicht unter KI: Sophos entfernt den nativen eDirectory-Servertyp. Laut v23-Authentisierungsdokumentation muss eine bestehende eDirectory-Konfiguration vor dem Upgrade auf einen unterstützten Authentisierungstyp migriert und entfernt werden. Andernfalls scheitert das Upgrade.

Das ist für betroffene Umgebungen ein echtes Migrationsprojekt. Ein erfolgreicher Login mit einer Ersatzintegration belegt noch nicht, dass automatische Benutzererkennung, Gruppenzuordnung und alle darauf aufgebauten Regeln weiter funktionieren. Wer bisher Verzeichnis-SSO nutzt, muss die neue Benutzerzuordnung separat nachweisen. Ich würde diese Umstellung vor dem Firmwarewechsel abschließen, damit sich ein Authentisierungsproblem später eindeutig eingrenzen lässt.

Auch EAP1 selbst ist eine Grenze. Sophos verweist für den Support während des Early Access Programs auf die Community-Foren. Für mich gehört dieser Stand in eine kontrollierte Testumgebung mit Wiederherstellungsplan. Die öffentliche Ankündigung ist keine Freigabe für die eigene kritische Infrastruktur.

Was das frühe Feedback tatsächlich belegt

Der verlinkte EAP1-Feedback-Thread enthält neben Kritik an der Regelansicht auch die Meldung eines VMware-Nutzers: Nach dem Upgrade von 22.0.1 seien Ping und SSH erreichbar gewesen, WebAdmin jedoch auch nach 30 Minuten nicht. In einem vom Suchindex erfassten späteren Antwortstand meldete derselbe Nutzer, dass die Oberfläche nach ungefähr 40 Minuten wieder erreichbar war.

Das ist eine einzelne Meldung ohne von mir reproduzierte Ursache. Ich behandle sie weder als allgemeinen VMware-Fehler noch als normale Upgrade-Dauer. Sie erinnert aber daran, Managementzugriff, Upgrade-Zeitfenster und Wiederherstellung gezielt zu prüfen. Frühe Threads verändern sich schnell; Antworten und Gegenbeispiele gehören genauso zur Bewertung wie die erste Problembeschreibung.

Im Reddit-Release-Thread zeigen WAF-Fragen außerdem, welche Lücken Betreiber weiterhin beschäftigen. Das ist hilfreicher Kontext, aber weder ein Benchmark noch eine vollständige Liste bestätigter Produktfehler.

Meine erste Bilanz nach knapp zwei Wochen

Nach knapp zwei Wochen im Homelab gefällt mir die Richtung von Sophos Firewall v23, aber das Release wirkt für mich noch nicht aus einem Guss. Die neue Regelansicht ist ein guter Schritt. Die REST API ist der richtige Ansatz, um wiederkehrende Aufgaben kontrolliert zu automatisieren. Bei der Oberfläche bleiben dagegen Unterschiede in Design, Funktionsumfang und responsiver Darstellung, die ich von einer modernen Firewall-Administration so nicht erwarte.

HA, WAF und Patchtransparenz sind für mich technisch wichtigere Themen als das KI-Label. Ihre angekündigten Verbesserungen verdienen Aufmerksamkeit. Meine ersten Tests ersetzen aber weder einen Lastvergleich noch die Erfahrung mit einem produktiven Cluster. Bei diesen Punkten bleiben die Herstellerangaben und die Abnahme in der jeweiligen Umgebung entscheidend.

Ich teste v23 weiter im Homelab. Für einen produktiven Einsatz ist mir diese erste Phase noch zu früh. Bis zur finalen Version wünsche ich mir vor allem, dass Sophos die gute neue Regelansicht zum Maßstab für die übrige Oberfläche macht: konsistente Aktionen, brauchbare Darstellung bei unterschiedlichen Fenstergrößen und weniger Unterschiede zwischen vergleichbaren Aufgaben. Das würde mir im Alltag mehr bringen als eine weitere isolierte Funktion auf der Release-Liste.

Bis zum nächsten Mal,
Euer Joe

FAQ