Sophos Firewall Device Access veilig configureren

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

Voor de bredere hardening-context past de hub Sophos Firewall Hardening: best practices voor een veilige configuratie.

Dit gebied is kritisch voor de beveiliging. Normale firewallregels beheren verkeer door de firewall. Device access beheert verkeer naar de firewall zelf. Als WebAdmin of SSH vanuit een onveilige zone bereikbaar is, ontstaat er directe beheerstoegang tot het beveiligingsapparaat.

Belangrijk is ook de API: de Device-Access-vrijgave voor HTTPS/WebAdmin werkt ook voor API-toegang. Sinds SFOS 22 worden API-toegangsbronnen bovendien onder Administration > API access beheerd, maar een toegestane API-host helpt niet als Device Access de lokale HTTPS-toegang vanuit deze zone blokkeert.

⚠️ WebAdmin, SSH en portalen moeten alleen vanuit vertrouwde netwerken bereikbaar zijn. Voor productieve omgevingen is het beter om de toegang te beperken tot een beheernetwerk, een vaste admin-IP, VPN of Sophos Central Firewall Management.

Voor de praktijk helpt dit onderscheid:

• Device Access-zonetabel: dienst in principe per zone toestaan of blokkeren, bijvoorbeeld DNS voor LAN, Ping voor een monitoringzone of SSL VPN voor een benodigde Remote-Access-zone.
• Local Service ACL Exception Rule: toegang nauwer sturen op bron, bestemming en dienst, bijvoorbeeld WebAdmin alleen vanuit het managementnetwerk, SSH alleen vanaf een support-IP of SNMP alleen vanaf het monitoringsysteem.
• Normale firewallregel: verkeer door de firewall toestaan of blokkeren, bijvoorbeeld wanneer een client uit LAN een server in DMZ of een internetdienst benadert.

Daarmee wordt duidelijk: een firewallregel vervangt geen Device Access-hardening. Als HTTPS of SSH via Device Access te breed bereikbaar is, bereikt een client de lokale dienst van de firewall voordat een klassieke doorvoerregel zelfs relevant zou zijn.

Waarom Device Access niet werkt als een firewallregel

Een typische firewallregel staat verbindingen tussen zones toe of blokkeert deze, bijvoorbeeld van LAN naar WAN of van VPN naar Server. Device Access is anders: het gaat hier om diensten die direct op de 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 verbinding met de firewall via SSH.

Dergelijk verkeer heeft als doel niet een server achter de firewall, maar de firewall zelf. Daarom wordt het beheerd via de lokale Service ACL.

Dit is ook de reden waarom Device Access tot de basisverharding van elke Sophos Firewall behoort. Een schone regelset voor LAN-naar-WAN beschermt niet automatisch de beheer- en portaaldiensten van de firewall zelf. Deze diensten moeten afzonderlijk worden gecontroleerd en bewust worden beperkt.

Zonevrijgaven begrijpen

In het bovenste gedeelte van Administration > Device access staat een tabel met zones en diensten. Als een dienst voor een zone is ingeschakeld, mag vanuit deze zone in principe toegang worden verkregen tot deze lokale dienst.

De zonetabel is praktisch, maar grof en geschikt voor duidelijke interne zones, zoals LAN, Management of VPN. Zodra een dienst alleen toegankelijk moet zijn voor individuele admin-IP-adressen, locaties, landen of ondersteuningsdoelen, zijn Local service ACL exception rules de betere keuze.

Voor Custom Zones moet men daarnaast de zone-instellingen controleren. Lokale diensten kunnen daar eveneens worden beïnvloed. Toch blijft Administration > Device access de centrale plaats waar men lokale firewall-diensten bewust vrijgeeft of beperkt.

Typische voorbeelden:

• HTTPS: WebAdmin-toegang vanuit het managementnetwerk. Niet breed vanuit WAN toestaan.
• SSH: CLI-toegang voor beheerders of support. Alleen gericht toestaan, bij voorkeur met Public Key.
• Ping/Ping6: monitoring en eenvoudige bereikbaarheidstests. Niet onnodig vanuit onveilige zones activeren.
• DNS: clients gebruiken de firewall als DNS-resolver. Alleen voor interne clientzones activeren.
• SSL VPN: SSL VPN-gebruikers bouwen een verbinding met de firewall op. Extern alleen zo open als nodig en met MFA beveiligen; poort apart in het Remote-Access-gedeelte controleren.
• User Portal: gebruikers downloaden VPN-configuraties of tokens. Extern zo mogelijk via VPN/ZTNA of nauw begrensd.
• VPN Portal: Remote-Access-VPN-gebruikers. Alleen wanneer echt nodig en met MFA beveiligen.
• RED: RED Appliances verbinden zich met de firewall. Alleen voor echte RED-locaties of gedefinieerde bronnen toestaan.
• SMTP Relay: interne systemen gebruiken de firewall als SMTP Relay. Niet als open relay vanuit onveilige zones vrijgeven.
• SNMP: monitoring vraagt firewallwaarden op. Alleen vanaf het monitoringsysteem toestaan; details staan in SNMP Hardware Monitoring.
• Dynamic Routing: routingprotocollen tussen routers en firewall. Alleen activeren in daarvoor bedoelde netwerksegmenten.

In SFOS 22 ondersteunen WebAdmin, VPN Portal en User Portal TLS 1.3. Dat is goed voor de versleuteling, maar verandert niets aan het basisprincipe: een dienst die vanuit te veel bronnen bereikbaar is, blijft een onnodig aanvalsoppervlak. Transportversleuteling vervangt geen nette ACL.

Welke diensten kunnen worden beperkt via ACL Rules?

Via Local Service ACL en ACL Exception Rules kunnen lokale firewall-diensten zeer fijn worden beheerd. Deze diensten zijn bijzonder relevant:

• DNS: de firewall beantwoordt DNS-verzoeken uit netwerken die zij niet zou moeten bedienen.
• Dynamic Routing: routingprotocollen zijn vanuit verkeerde segmenten bereikbaar.
• HTTPS: de WebAdmin Console is voor te veel bronnen bereikbaar.
• Ping/Ping6: de firewall is onnodig zichtbaar en scanbaar.
• RED: RED-diensten zijn vanuit te brede brongebieden bereikbaar.
• SMTP Relay: foutconfiguraties kunnen relay-misbruik bevorderen.
• SNMP: monitoringgegevens zijn vanuit verkeerde netwerken opvraagbaar.
• SSH: directe CLI-toegang tot de firewall is te open.
• SSL VPN: VPN-aanmeldpunten zijn wereldwijd bereikbaar en worden gescand.
• User Portal: portaal-login en VPN-downloads zijn onnodig blootgesteld.
• VPN Portal: Remote-Access-Portal is doelwit van bots en brute-force-pogingen.

Hoe meer van deze diensten 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 dienst alleen daar bereikbaar te maken waar hij echt nodig is.

Toegangsbronnen zo nauw mogelijk definiëren

Een ACL Rule hoeft niet eenvoudigweg Any toe te staan. Als bron kan men zeer fijn werken, bijvoorbeeld met:

• individuele admin-IP-adressen
• beheernetwerken
• IP-bereiken
• IP-lijsten
• FQDN-hosts
• FQDN-hostgroepen
• DNS-hosts of DNS-groepen
• Landobjecten of landengroepen
• Toegewijde VPN- of ondersteuningsnetwerken

Hiermee kan toegang aanzienlijk beter worden beperkt. Een voorbeeld: Als een externe ondersteuningsdienst alleen afkomstig is van een vaste FQDN of een gedefinieerd IP-bereik, zou niet de hele WAN-zone toegang moeten krijgen tot HTTPS of SSH. Als een monitoringsysteem SNMP nodig heeft, zou niet een compleet servernetwerk SNMP op de firewall mogen opvragen.

Bij wereldwijde remote-access-scenario’s is de afbakening moeilijker. Sommige bedrijven kunnen SSL VPN of VPN Portal niet eenvoudig alleen voor Zwitserland, Duitsland of een enkel land vrijgeven, omdat medewerkers wereldwijd onderweg zijn. In dergelijke gevallen moet men daarnaast werken met MFA, logging, restrictieve portaalinstellingen en Threat Feeds.

Beslissingsmodel voor lokale diensten

Voor elke lokale dienst moet men bewust beslissen welk toegangsniveau passend is. Het is zelden zinvol om WebAdmin, SSH, User Portal, VPN Portal, DNS en SNMP op dezelfde manier te behandelen.

• Uitgeschakeld: passend wanneer de dienst in de omgeving niet nodig is. Voorbeeld: SSH permanent uit, als er geen CLI-toegang is voorzien.
• Alleen interne zone: passend wanneer de dienst door veel interne clients wordt gebruikt. Voorbeeld: DNS uit LAN, wanneer clients de firewall als DNS-resolver gebruiken.
• Managementnetwerk: passend voor administratieve of monitoringgerelateerde diensten. Voorbeeld: HTTPS, SSH en SNMP alleen vanuit Management.
• Admin-VPN: passend wanneer beheerders extern moeten werken, maar niet direct vanaf het internet. Voorbeeld: WebAdmin alleen via VPN bereikbaar.
• ACL Exception Rule: passend wanneer toegang vanuit een zeer concrete bron moet komen. Voorbeeld: een support-IP mag tijdelijk HTTPS of SSH gebruiken.
• WAN breed bereikbaar: alleen voor echte Remote-Access-diensten en met extra bescherming. Voorbeeld: SSL VPN voor mobiele gebruikers met MFA, logging en Threat Feeds.

Deze beslissing moet worden gedocumenteerd. Vooral bij uitzonderingen vanuit WAN moet later te achterhalen zijn waarom de dienst bereikbaar is, wie hem nodig heeft en wanneer de uitzondering opnieuw wordt beoordeeld.

WAN-toegang is een uitzondering

WAN is niet zomaar een andere zone. Alles wat vanuit WAN bereikbaar is, wordt gevonden door scanners, bots en brute-force-tools. Daarom moet WebAdmin vanuit WAN niet als normale bedrijfsvariant worden gepland.

Als externe beheerstoegang nodig is, zijn deze varianten meestal veiliger:

• Sophos Central Firewall Management voor administratieve taken.
• Admin-VPN met MFA en een duidelijke gebruikersgroep.
• Een tijdelijke ACL Exception Rule voor een vaste bron-IP.
• Een toegewijd beheernetwerk via Site-to-Site VPN.

Voor het algemene hardingsbeeld past daarnaast Sophos Firewall Health Check correct gebruiken, omdat daar beheerstoegang, MFA, back-ups en regelhygiëne samen worden beoordeeld.

Sophos beschermt WebAdmin er bovendien tegen om voor alle WAN-bronnen te worden vrijgegeven. Als WAN-toegang echt nodig is, moet die via specifieke bronnen zoals afzonderlijke IP-adressen, netwerken of FQDN-objecten worden beperkt. Bestaande oude vrijgaven uit oudere configuraties moeten regelmatig worden gecontroleerd: Sophos kan bepaalde brede WAN-vrijgaven voor WebAdmin of User Portal na langere inactiviteit automatisch deactiveren, terwijl gerichte ACL-uitzonderingen voor concrete WAN-bronnen kunnen blijven gelden.

Local Service ACL Exception Rule

Als een dienst niet voor een hele zone moet worden vrijgegeven, gebruikt men een Local service ACL exception rule. Hiermee kan zeer nauwkeurig worden gedefinieerd wie toegang heeft tot welke lokale dienst.

Pad:

1. Open Administration.
2. Selecteer Device access.
3. Scroll naar Local service ACL exception rule.
4. Klik op Add.

Typische procedure voor een nauwe admin-uitzondering vanuit WAN:

1. Rule name instellen, bijvoorbeeld admin-https-from-support-ip.
2. Rule position op Top zetten als een bestaande Drop- of Allow-regel anders eerder zou gelden.
3. IP version passend bij de bron kiezen, meestal IPv4.
4. Source zone op WAN zetten.
5. Source Network / Host op het concrete admin-IP, een klein adminnetwerk of een onderhouden FQDN-/IP-object zetten.
6. Destination host beperken tot het betrokken firewalladres of interface, als niet bewust alle lokale doelen bedoeld zijn.
7. Services op de benodigde lokale dienst zetten, bijvoorbeeld HTTPS voor WebAdmin of API, niet tegelijk HTTPS en SSH uit gemak.
8. Action op Accept zetten.
9. Opslaan en meteen vanuit toegestane en niet-toegestane bron testen.

Een ACL Exception Rule bestaat in wezen uit deze velden:

• Rule name: unieke naam, bijvoorbeeld admin-https-from-mgmt.
• Rule position: volgorde van de ACL-regels.
• Source zone: zone waaruit de toegang komt, bijvoorbeeld WAN, LAN of VPN.
• Source Network / Host: toegestane admin-IP, managementnetwerk, FQDN Host of IP-lijst.
• Destination host: firewall-IP of interface waarop toegang wordt verkregen.
• Services: lokale dienst, bijvoorbeeld HTTPS, SSH, Ping of DNS.
• Action: Accept of Drop.

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

Voor API-automatisering geldt dezelfde logica. Een host kan onder Administration > API access toegestaan zijn en toch falen als de HTTPS-vrijgave onder Device Access ontbreekt. Omgekeerd mag een HTTPS-vrijgave niet breder worden alleen omdat een API-tool wordt gekoppeld. Voor API-details past Sophos Firewall API-toegang veilig beperken.

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

De Destination host is vooral belangrijk wanneer de firewall meerdere interfaces, alias-adressen, VPN-adressen of aparte portal-/admin-doelen heeft. Een regel moet zo precies mogelijk wijzen naar het firewalladres dat echt beheerd of gebruikt moet worden. Anders werkt een eigenlijk nauwe bronvrijgave plots op meer lokale diensten of interfaces dan gepland.

Lockout vermijden vóór de wijziging

Device-Access-wijzigingen hebben directe invloed op beheer- en portaaltoegang. Daarom moet vóór elke beperking duidelijk zijn hoe men weer toegang krijgt tot de firewall als een regel verkeerd werkt.

Voordat een risicovolle wijziging wordt opgeslagen, moet worden gecontroleerd:

• Is er een tweede beheerder met het juiste rechtenprofiel beschikbaar?
• Is er toegang via een ander netwerk, zoals Management-LAN, Admin-VPN of Sophos Central?
• Is er lokale console- of out-of-band-bereikbaarheid aanwezig als WebAdmin niet meer bereikbaar is?
• Wordt er momenteel aan een HA-cluster gewerkt waarbij een rolwisseling het toegangspad kan veranderen?
• Zijn actuele back-upbestanden, Secure Storage Master Key en noodtoegang gedocumenteerd?
• Is er een kort onderhoudsvenster waarin foutieve toegang onmiddellijk wordt opgemerkt?

Vooral bij externe locaties moet men niet eerst de brede vrijgave verwijderen en daarna testen. Veiliger is de omgekeerde volgorde: nieuwe nauwe ACL Exception Rule maken, toegestane toegang testen, tweede beheerderstoegang bevestigen en pas daarna de oude brede zonevrijgave verminderen.

Wijzigingen veilig uitrollen

Device-Access-wijzigingen kunnen beheerders buitensluiten. Daarom moeten ze niet terloops worden gewijzigd, maar als beheerwijziging worden behandeld.

Beproefde procedure:

1. Documenteer de huidige toegang: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP en Ping.
2. Zorg ervoor dat er een tweede beheerderstoegang is, zoals lokale console, Admin-VPN of Sophos Central.
3. Maak een back-up voordat grotere ACL-wijzigingen worden doorgevoerd.
4. Maak een nieuwe ACL Exception Rule zo specifiek mogelijk.
5. Test toegang vanuit de toegestane bron.
6. Test toegang vanuit een niet-toegestane bron.
7. Controleer Log Viewer of de verwachte gebeurtenissen zichtbaar zijn.
8. Verwijder de oude brede zonevrijgave pas als de nieuwe toegang is bevestigd.
9. Documenteer de wijziging met datum, bron, dienst en verantwoordelijke.

Als meerdere firewalls of HA-clusters betrokken zijn, moet de wijziging eerst worden getest op een systeem met goede terugvalmogelijkheden. Voor HA-omgevingen past daarnaast Sophos Firewall High Availability instellen, omdat beheerstoegang, rolwisselingen en onderhoudsvensters daar samen moeten worden bekeken.

Nacontrole na Device-Access-wijzigingen

Na een aanpassing is het niet voldoende om alleen de eigen WebAdmin-toegang te controleren. Men moet zowel toegestane als niet-toegestane bronnen testen, anders blijft onduidelijk of de hardening echt werkt.

• WebAdmin vanuit managementnetwerk: toegang werkt zoals gepland.
• WebAdmin vanuit normaal clientnetwerk: toegang is geblokkeerd, wanneer niet uitdrukkelijk toegestaan.
• SSH vanuit adminnetwerk: toegang werkt alleen wanneer SSH bewust is vrijgegeven.
• SSH vanuit WAN of gastnetwerk: toegang is geblokkeerd.
• DNS vanuit clientnetwerk: DNS werkt alleen in netwerken die de firewall als resolver moeten gebruiken.
• User Portal of VPN Portal: alleen benodigde portals zijn bereikbaar.
• SNMP vanaf het monitoringsysteem: monitoring werkt, andere bronnen zijn geblokkeerd.

Als een toegang onverwacht werkt, moet niet alleen de ACL Exception Rule worden gecontroleerd. Ook de zonetabel in het bovenste Device-Access-gedeelte, Custom-Zone-instellingen, VPN-zone, proxygedrag en bestaande brede Accept-regels kunnen de oorzaak zijn.

Voor de documentatie volstaat vaak een korte lijst per dienst:

• HTTPS: toegestane bron mgmt-net, reden Admin-toegang WebAdmin, review per kwartaal.
• SSH: toegestane bron support-ip-temporary, reden supportcase, review na ticketafsluiting.
• SNMP: toegestane bron monitoring-server, reden hardware- en interface-monitoring, review halfjaarlijks.
• SSL VPN: toegestane bron WAN, reden Remote Access, review met maandelijkse logcontrole.

Bij elke nacontrole moet bovendien worden nagegaan of succesvolle en geblokkeerde toegangen überhaupt zichtbaar zijn. Voor korte tests is de Log viewer vaak voldoende. Voor langere bewaartermijnen of auditvragen zijn Central Reporting of Syslog beter geschikt, omdat lokale logs roteren of bij storingen verloren kunnen gaan.

Aanbevolen basisconfiguratie

Voor veel productieve omgevingen is de volgende logica zinvol:

• HTTPS/WebAdmin alleen toestaan vanuit Management, Admin-VPN of een vaste admin-IP.
• API alleen uit gedefinieerde automatiserings- of monitoringhosts toestaan en daarnaast HTTPS via Device Access passend beperken.
• SSH standaard uitschakelen en alleen indien nodig gericht toestaan via ACL.
• 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 brongebieden 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; de instelling staat in MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.
• Sophos Central Firewall Management gebruiken als een veilige externe beheerstoegang nodig is.

Voor langere traceerbaarheid moet ook de logstrategie worden gecontroleerd. Lokale logs zijn voldoende voor acute foutopsporing, maar niet voor elke audit- of incident-response-vraag. Als portaal- of beheerstoegang op de lange termijn traceerbaar moet zijn, zijn Central Firewall Reporting of Sophos Firewall Syslog naar SIEM sturen de meer geschikte bouwstenen.

SSH bijzonder voorzichtig behandelen

SSH is zeer nuttig voor troubleshooting en ondersteuning, maar moet niet permanent breed openstaan. Voor SSH geldt:

• Alleen de gebruiker admin kan zich aanmelden via SSH.
• Public-Key-authenticatie is de voorkeursmethode.
• Toegang vanuit WAN moet alleen via vaste bron-IP-adressen of VPN plaatsvinden.
• Na voltooiing van een analyse moet worden gecontroleerd of SSH nog steeds nodig is.

Meer hierover staat in de handleiding Sophos Firewall verbinden via SSH.

Bots, Brute Force en Threat Feeds

In de praktijk ziet men vaak dat te open diensten onmiddellijk door bots worden gevonden. Vooral WebAdmin, User Portal, VPN Portal en SSL VPN zijn getroffen. Ook als een dienst is beschermd door wachtwoord en MFA, genereren openbare logins aanvalspogingen, brute-force-verkeer, logruis en onnodige belasting op de firewall.

Dit betekent niet automatisch dat er een succesvolle aanval plaatsvindt. Het toont echter aan dat de dienst deel uitmaakt van het openbare aanvalsoppervlak. Hoe minder bronnen de login ook maar bereiken, hoe beter.

Als een portaal wereldwijd bereikbaar moet zijn, zijn landfilters of individuele bron-IP-adressen vaak niet voldoende. In dergelijke omgevingen raden we daarnaast Third-Party Threat Feeds aan. Threat Feeds leveren de firewall continu actuele Indicators of Compromise, zoals 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 diensten bereiken.

Het eigen artikel Sophos Firewall Threat Feeds legt planning, allowlisting en werking uit.

Veelgemaakte fouten

Firewallregel in plaats van Device Access gecontroleerd

Als WebAdmin, SSH, DNS of Ping naar de firewall niet bereikbaar zijn, 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 toegestaan vanuit te veel zones

WebAdmin moet niet vanuit elke interne zone bereikbaar zijn. Een gastnetwerk, IoT-netwerk of VoIP-netwerk heeft normaal gesproken geen toegang nodig tot het firewallbeheer. Ook intern moet men ervan uitgaan dat er gecompromitteerde clients kunnen bestaan. Een apart beheernetwerk of een Admin-VPN vermindert dit risico aanzienlijk.

DNS niet geactiveerd voor clientzone

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

User Portal en VPN Portal verward

Het User Portal en het VPN Portal zijn verschillende diensten. Afhankelijk van het remote-access-concept moet worden gecontroleerd welk portaal echt nodig is. Vaak wordt een portaal geactiveerd omdat een gebruiker een keer een configuratie moest downloaden, maar daarna blijft het jarenlang open. Dergelijke oude lasten moeten regelmatig worden verwijderd.

Als portalen vanaf het internet bereikbaar moeten blijven, moet men niet alleen de checkbox controleren. Belangrijk zijn MFA, gebruikersgroepen, token-/provisioningproces, verloop van tijdelijke gebruikers, logging en de vraag of het portaal na de rollout nog permanent nodig is.

Web Proxy uitzondering over het hoofd gezien

Als de Web Proxy wordt gebruikt, kunnen HTTP- en HTTPS-verzoeken vanuit proxy-oogpunt intern lijken. Dit 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. Dergelijke regels omzeilen het eigenlijke veiligheidsvoordeel van de ACL-uitzondering. Beter is een kleine, duidelijke regel met een duidelijke bron en precies de benodigde diensten.

Drop-regel op 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.

Omgekeerd kan een brede Accept-regel bovenaan de lijst latere Drop-regels praktisch waardeloos maken. Na elke regelwijziging moet daarom niet alleen de nieuwe regel, maar ook de matchlogica van de regels erboven worden gecontroleerd.

SSL VPN en VPN Portal te open gelaten

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

Problemen oplossen

Als een lokale dienst 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 dienst in Administration > Device access voor deze zone toegestaan?
4. Is er een passende Local service ACL exception rule?
5. Geldt er mogelijk een hogere ACL-regel met Drop?
6. Is de dienst op een andere poort geconfigureerd?
7. Wordt de toegang via VPN, proxy of NAT anders gezien dan verwacht?
8. Geeft de Log Viewer een aanwijzing?
9. Kan Packet Capture de verbindingspoging op de interface zien?

Voor ondersteuningsverzoeken kan het nuttig zijn om een gerichte ACL Exception Rule te maken en deze na voltooiing weer te verwijderen of te deactiveren.

Bedrijfschecklist

• WebAdmin niet breed vanuit WAN bereikbaar.
• SSH alleen tijdelijk of vanuit beheer-/admin-netwerken toegestaan.
• DNS alleen actief voor clientzones die de firewall echt als resolver gebruiken.
• SNMP alleen toegestaan vanaf het monitoringsysteem of monitoringnetwerk.
• User Portal, VPN Portal en SSL VPN alleen actief als ze in het remote-access-concept nodig zijn.
• MFA voor WebAdmin, VPN Portal en Remote Access gecontroleerd.
• API-toegang alleen vanuit gedefinieerde hosts toegestaan en met Device Access afgestemd.
• ACL Exception Rules met duidelijke bron, dienst en doel benoemd.
• Tijdelijke ondersteuningsregels met vervaldatum gedocumenteerd.
• Toegang vanuit toegestane en niet-toegestane bronnen getest.
• Logging, Central Reporting of Syslog voor relevante portaal- en beheerstoegang gecontroleerd.
• Kwartaalreview voor WebAdmin, SSH, SNMP, User Portal, VPN Portal en SSL VPN gepland.

FAQ