Sophos Firewall toegang beveiligen: Device Access configureren

Onder Administration > Device access wordt vastgelegd vanuit welke zones lokale services van Sophos Firewall bereikbaar zijn. Dit zijn bijvoorbeeld HTTPS voor de WebAdmin Console, SSH voor CLI-toegang, Ping, DNS, User Portal, VPN Portal en andere services.

Dit onderdeel is beveiligingskritisch. Normale firewallregels sturen verkeer door de firewall. Device access stuurt verkeer naar de firewall zelf. Als WebAdmin of SSH bereikbaar is vanuit een onbetrouwbare zone, ontstaat directe managementtoegang tot het beveiligingsapparaat.

⚠️ WebAdmin, SSH en portals mogen alleen bereikbaar zijn vanuit vertrouwde netwerken. In productieomgevingen is het beter om toegang te beperken tot een managementnetwerk, een vast admin-IP, VPN of Sophos Central Firewall Management.

Waarom Device Access geen firewallregel is

Een typische firewallregel staat verbindingen tussen zones toe of blokkeert ze, bijvoorbeeld LAN naar WAN of VPN naar Server. Device Access is anders: het gaat om services die direct op Sophos Firewall draaien.

Voorbeelden:

• Een beheerder opent https://172.16.16.16:4444.
• Een client gebruikt de firewall als DNS-server.
• Een monitoringsysteem pingt de firewall.
• Een gebruiker opent het User Portal of VPN Portal.
• Een beheerder maakt via SSH verbinding met de firewall.

Dit verkeer heeft niet een server achter de firewall als doel, maar de firewall zelf. Daarom wordt het via de lokale service ACL geregeld.

Daarom hoort Device Access ook bij de basis-hardening van elke Sophos Firewall. Een nette LAN-naar-WAN-regelset beschermt niet automatisch de management- en portalservices van de firewall zelf. Deze services moeten apart worden gecontroleerd en bewust worden beperkt.

Zonevrijgaven begrijpen

Bovenaan Administration > Device access staat een tabel met zones en services. Als een service voor een zone actief is, is toegang tot deze lokale service vanuit die zone in principe toegestaan.

De zonetabel is praktisch, maar grofmazig. Ze past goed bij duidelijke interne zones zoals LAN, Management of VPN. Zodra een service alleen bereikbaar mag zijn voor specifieke admin-IP-adressen, locaties, landen of supportdoelen, zijn Local service ACL exception rules de betere keuze.

Typische voorbeelden:

Bij Custom Zones kan de bereikbaarheid van lokale services ook via de zone-instellingen worden beïnvloed. Toch moet Device Access altijd bewust worden gecontroleerd, omdat dit het centrale overzicht voor lokale firewallservices is.

Welke services kan men met ACL Rules beperken?

Met Local Service ACL en ACL Exception Rules kan men lokale firewallservices zeer precies sturen. Vooral deze services zijn relevant:

Hoe meer van deze services bereikbaar zijn vanuit WAN, gastnetwerken, IoT-netwerken of vaag gedefinieerde zones, hoe groter het aanvalsoppervlak wordt. Het doel is niet om alles uit te schakelen, maar om elke service alleen daar bereikbaar te maken waar hij echt nodig is.

Bronnen zo strak mogelijk definiëren

Een ACL Rule hoeft niet simpelweg Any toe te staan. Als bron kan men heel precies werken, bijvoorbeeld met:

• afzonderlijke admin-IP-adressen
• managementnetwerken
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts of DNS groups
• Country objects of landengroepen
• dedicated VPN- of supportnetwerken

Daarmee kan toegang veel beter worden begrensd. Een voorbeeld: als een externe supportdienst alleen vanaf een vaste FQDN of een gedefinieerd IP-bereik komt, mag niet de hele WAN-zone toegang krijgen tot HTTPS of SSH. Als een monitoringsysteem SNMP nodig heeft, mag niet een volledig servernetwerk SNMP op de firewall kunnen opvragen.

Bij globale Remote Access-scenario’s is afbakening lastiger. Sommige bedrijven kunnen SSL VPN of VPN Portal niet zomaar alleen voor Zwitserland, Duitsland of één land vrijgeven, omdat medewerkers wereldwijd werken. In zulke gevallen moet men aanvullend werken met MFA, logging, restrictieve portalinstellingen en Threat Feeds.

Local Service ACL Exception Rule

Als een service niet voor een hele zone moet worden vrijgegeven, gebruikt men een Local service ACL exception rule. Daarmee kan men heel precies definiëren wie toegang krijgt tot welke lokale service.

Pad:

1. Administration openen.
2. Device access selecteren.
3. Naar Local service ACL exception rule scrollen.
4. Add aanklikken.

Een ACL Exception Rule bestaat in hoofdzaak uit deze velden:

Voor WebAdmin-toegang vanaf internet mag men nooit Any als bron gebruiken. Sophos voorkomt WebAdmin-toegang vanuit de WAN-zone voor alle bronnen bewust, omdat dit een hoog risico zou zijn. Als WAN-toegang echt nodig is, moet die alleen via specifieke bron-IP-adressen, gedefinieerde netwerken, FQDN-objecten of andere smalle bronnen worden toegestaan.

Ook de volgorde is belangrijk. ACL Exception Rules worden van boven naar beneden geëvalueerd. Een hogere Drop-regel kan een latere Accept-regel ineffectief maken. Omgekeerd kan een te breed geformuleerde Accept-regel latere beperkingen ondermijnen. De regelvolgorde moet daarom net zo bewust worden gecontroleerd als bij firewallregels.

Aanbevolen basisconfiguratie

Voor veel productieomgevingen is de volgende logica zinvol:

• HTTPS/WebAdmin alleen toestaan vanuit Management, admin-VPN of een vast admin-IP.
• SSH standaard uitschakelen en alleen indien nodig gericht via ACL toestaan.
• DNS alleen activeren in zones waar clients de firewall echt als DNS-server gebruiken.
• Ping toestaan voor interne monitoringsystemen, maar niet algemeen vanuit WAN.
• User Portal, VPN Portal en SSL VPN alleen activeren als ze nodig zijn.
• RED alleen toestaan voor locaties of bronbereiken waar daadwerkelijk RED Appliances staan.
• SNMP alleen toestaan voor het monitoringsysteem.
• SMTP Relay alleen toestaan voor gedefinieerde interne systemen.
• Dynamic Routing alleen activeren in routingsegmenten waar dynamische routingprotocollen echt worden gebruikt.
• MFA voor WebAdmin, VPN Portal en Remote Access controleren.
• Sophos Central Firewall Management gebruiken als veilige externe managementtoegang nodig is.

SSH bijzonder voorzichtig behandelen

SSH is erg nuttig voor troubleshooting en support, maar mag niet permanent breed openstaan. Voor SSH geldt:

• Alleen de gebruiker admin kan via SSH inloggen.
• Public-key-authenticatie is de voorkeur.
• Toegang vanuit WAN mag alleen via vaste bron-IP-adressen of VPN plaatsvinden.
• Na afloop van een analyse moet worden gecontroleerd of SSH nog nodig is.

Meer hierover staat in de handleiding Via SSH verbinden met Sophos Firewall.

Bots, brute force en Threat Feeds

In de praktijk ziet men heel vaak dat te open services direct door bots worden gevonden. Vooral WebAdmin, User Portal, VPN Portal en SSL VPN worden getroffen. Zelfs als een service met wachtwoord en MFA is beveiligd, veroorzaken publieke logins aanvalspogingen, brute-force-verkeer, ruis in logs en onnodige belasting op de firewall.

Dat betekent niet automatisch dat een aanval succesvol is. Het laat wel zien dat de service deel uitmaakt van het publieke aanvalsoppervlak. Hoe minder bronnen überhaupt tot de login komen, hoe beter.

Als een portal wereldwijd bereikbaar moet zijn, zijn landenfilters of afzonderlijke bron-IP-adressen vaak niet genoeg. In zulke omgevingen adviseren wij aanvullend Third-Party Threat Feeds. Threat Feeds leveren de firewall continu actuele Indicators of Compromise, bijvoorbeeld kwaadaardige IP-adressen, domeinen of URL’s. Bekende scanners, botnets en aanvallers kunnen daardoor worden geblokkeerd voordat ze WebAdmin, VPN Portal, SSL VPN of andere gepubliceerde services bereiken.

Meer hierover: Sophos Firewall Threat Feeds

Veelgemaakte fouten

Firewallregel gecontroleerd in plaats van Device Access

Als WebAdmin, SSH, DNS of Ping naar de firewall niet bereikbaar is, helpt een normale firewallregel niet. Het verkeer gaat niet door de firewall heen, maar eindigt op de firewall zelf. Daarom moet Administration > Device access worden gecontroleerd.

WebAdmin vanuit te veel zones toegestaan

WebAdmin mag niet vanuit elke interne zone bereikbaar zijn. Een gastnetwerk, IoT-netwerk of VoIP-netwerk heeft normaal geen toegang tot firewallbeheer nodig. Ook intern moet men rekening houden met gecompromitteerde clients. Een apart managementnetwerk of admin-VPN verkleint dit risico duidelijk.

DNS niet geactiveerd voor de clientzone

Als clients de firewall als DNS-server moeten gebruiken, moet DNS voor de juiste zone toegestaan zijn. Anders bereiken clients wel het firewall-IP, maar krijgen ze geen DNS-antwoord. Omgekeerd mag DNS niet worden toegestaan vanuit zones waar de firewall helemaal niet als DNS-resolver moet worden gebruikt.

User Portal en VPN Portal verwisseld

User Portal en VPN Portal zijn verschillende services. Afhankelijk van het Remote Access-concept moet worden gecontroleerd welk portal echt nodig is. Vaak wordt een portal geactiveerd omdat een gebruiker ooit een configuratie moest downloaden, waarna het jarenlang open blijft. Zulke resten moeten regelmatig worden verwijderd.

Web Proxy-special case over het hoofd gezien

Als Web Proxy wordt gebruikt, kunnen HTTP- en HTTPS-aanvragen vanuit proxy-perspectief intern lijken. Dat kan invloed hebben op hoe toegang tot WebAdmin, Captive Portal, VPN Portal of User Portal wordt gecontroleerd. In omgevingen met proxy moet men daarom bijzonder nauwkeurig testen welke toegang echt mogelijk is.

ACL-regel te breed geformuleerd

Een ACL Exception Rule met Source zone: Any, Source Network / Host: Any en Services: HTTPS, SSH is bijna nooit een goed idee. Zulke regels omzeilen het eigenlijke beveiligingsvoordeel van de ACL-uitzondering. Beter is een kleine, duidelijke regel met een eenduidige bron en precies de benodigde services.

Drop-regel op de verkeerde positie

Als een drop-regel boven een accept-regel staat, kan de toegestane toegang toch worden geblokkeerd. Bij ACL Exception Rules is de volgorde daarom net zo belangrijk als bij firewallregels.

SSL VPN en VPN Portal te open gelaten

Remote Access moet vaak van buiten bereikbaar zijn. Toch moet worden gecontroleerd of alle landen, netwerken en gebruikersgroepen echt toegang nodig hebben. Als een strakke bronbeperking niet mogelijk is, moeten MFA, logging en Threat Feeds des te consequenter worden ingezet.

Troubleshooting

Als een lokale service niet bereikbaar is, helpt deze volgorde:

1. Klopt het doel-IP van de firewall?
2. Komt de client uit de verwachte zone?
3. Is de service onder Administration > Device access voor deze zone toegestaan?
4. Is er een passende Local service ACL exception rule?
5. Matcht er mogelijk een hogere ACL-regel met Drop?
6. Is de service op een andere poort geconfigureerd?
7. Wordt de toegang door VPN, proxy of NAT anders gezien dan verwacht?
8. Geeft Log Viewer een aanwijzing?
9. Ziet Packet Capture de verbindingspoging op het interface?

Voor supporttoegang kan het zinvol zijn om een gerichte ACL Exception Rule te maken en die na afloop weer te verwijderen of te deactiveren.

Meer informatie

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Via SSH verbinden met Sophos Firewall
• MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren