Sophos Firewall XML API-toegang beveiligen

De XML API van de Sophos Firewall is handig voor automatisering, monitoring, back-ups, analyses en integraties. Precies daarom maakt het ook deel uit van het beheer-aanvalsoppervlak. Wie API-toegang toestaat, geeft een systeem de mogelijkheid om configuratiegegevens te lezen of, afhankelijk van de rechten, wijzigingen aan te brengen.

API-toegang moet daarom niet breed worden toegestaan vanuit interne netwerken of willekeurige bronnen. Het is beter om een kleine, gedocumenteerde set van beheernetwerken, automatiseringshosts of vaste partnerverbindingen te gebruiken.

Sinds SFOS 22 heeft Sophos de API-toegangscontrole uitgebreid. De API access settings bevinden zich in het gedeelte Administration > API access, en toegestane bronnen kunnen als IP-hosts worden gedefinieerd. Hierdoor kunnen niet alleen afzonderlijke IP-adressen, maar ook IP-bereiken en netwerken correct worden gemodelleerd.

Wanneer XML API-toegang zinvol is

De XML API is geen standaardtoegang voor normaal beheerwerk. Het gebruik is zinvol wanneer er een specifiek technisch proces achter zit.

Typische toepassingsgevallen:

• Monitoring of inventarisatie.
• Geautomatiseerde configuratiecontroles.
• Back-up- of documentatieprocessen.
• MSP- of integratieplatforms.
• Scripts voor terugkerende administratieve taken.
• Voorbereide wijzigingen vanuit tools zoals Sophos Firewall Config Studio.

Als een proces ook zonder API kan, moet API-toegang niet preventief ingeschakeld blijven. Elke extra interface heeft een eigenaar, een bron, een toegangsconcept en controle nodig.

Wat er is veranderd met SFOS 22

Met SFOS 22 is de XML API-toegangscontrole voor gebruik aanzienlijk beter hanteerbaar geworden:

• De API access settings zijn verplaatst naar het menu Administration > API access.
• API access is standaard uitgeschakeld en moet bewust worden ingeschakeld.
• API-toegang kan worden beperkt tot IP-hosts.
• Hierdoor zijn IP-adressen, IP-bereiken en netwerken als bronnen mogelijk.
• Tot 64 IP-hosts kunnen worden toegestaan.
• Bij de upgrade worden eerder toegestane IP-adressen automatisch omgezet in IP-hostobjecten.
• Gemigreerde objecten krijgen het voorvoegsel apiconfig.

Dit is nuttig voor gebruik, omdat API-bronnen niet langer alleen als losse individuele adressen hoeven te worden beheerd. Men kan een beheernetwerk, een automatiseringshost of een toegewijde hostgroep correct benoemen en later in beoordelingen herkennen.

Basisregel: API alleen vanuit gedefinieerde bronnen toestaan

API access moet net zo worden behandeld als WebAdmin of SSH: zo smal mogelijk, zo breed als nodig.

Zinvolle bronnen zijn bijvoorbeeld:

• een dedicated automatiseringsserver,
• een monitoringsysteem,
• een configuration-management-host,
• een intern managementnetwerk,
• een VPN- of adminnetwerk,
• een duidelijk gedefinieerd partner- of MSP-bronadres.

Niet zinvol zijn:

• volledige clientnetwerken,
• gast- of IoT-netwerken,
• Any,
• vage uitzonderingen zoals “volledig servernetwerk”,
• tijdelijke test-IP-adressen die later worden vergeten.

Als externe dienstverleners API-toegang nodig hebben, moet de bron zo specifiek mogelijk worden gedefinieerd. Daarnaast moet gedocumenteerd zijn waarvoor de toegang wordt gebruikt en wanneer deze weer wordt verwijderd.

Aanbevolen procedure

Het exacte UI-pad kan per SFOS-versie licht verschillen. In SFOS 22 staat de API-configuratie onder Administration > API access.

Praktische procedure:

1. Controleren welk systeem API-toegang nodig heeft.
2. Onder Hosts and services > IP host een duidelijk IP Host-object voor dit systeem maken.
3. Als meerdere bronnen nodig zijn, IP Hosts, IP ranges of netwerken netjes benoemen.
4. Onder Administration > API access API access inschakelen.
5. Onder Allowed IP hosts alleen deze objecten toestaan.
6. Op Apply klikken.
7. Geen brede client- of servernetwerken toevoegen.
8. Toegang testen vanaf de echte automatiserings- of monitoringhost, niet vanaf de admin-laptop.
9. Bronnen die niet meer nodig zijn weer verwijderen.
10. De wijziging documenteren in het change-proces.

Bij bestaande installaties na een upgrade naar SFOS 22 moet men daarnaast zoeken naar objecten met de prefix apiconfig. Deze objecten zijn gemaakt uit oudere API-allow-vermeldingen en moeten worden gecontroleerd, hernoemd of opgeschoond.

Toegang gericht testen

Het API-endpoint staat meestal onder:

https://<Firewall-IP-of-hostname>:<Port>/webconsole/APIController

De poort is de HTTPS-poort van de WebAdmin Console. Als de adminpoort onder Administration > Admin settings is aangepast, moet de API-tool dezelfde poort gebruiken. De API werkt met XML-payloads via HTTP POST, niet als een klassieke REST-API met aparte GET-, POST-, PUT- en DELETE-endpoints.

Een zinvolle test beantwoordt niet alleen de vraag of inloggen mogelijk is. De test moet aantonen of de juiste bron is toegestaan, of het account de benodigde bewerking mag uitvoeren en of het resultaat in het audit- of change-proces traceerbaar blijft.

Voor acceptatie moeten deze punten afzonderlijk worden gecontroleerd:

• Bron: De test loopt vanaf de echte automatiserings-, monitoring- of integratiehost, niet vanaf de admin-laptop.
• Toegang: De firewall accepteert het bron-IP alleen als het passende IP Host-object in API access is toegestaan.
• Account: Het gebruikte API- of serviceaccount heeft alleen de benodigde rechten.
• Secret: Gebruikersnaam, wachtwoord of token komen niet terecht in shell-history, tickets, chats of screenshots.
• Audit: De toegang of wijziging is traceerbaar in het audit- of change-proces.
• Rollback: Voor schrijfacties bestaan een backup, rollbackpunt en ongevaarlijke leestest.

curl-voorbeelden met gebruikersnaam en wachtwoord in de URL zijn snel gekopieerd en later lastig uit logs te verwijderen. Beter is een korte test met een dedicated serviceaccount, tijdelijk testsecret, veilige opslag en latere rotatie als een secret in een onveilige context is gebruikt.

Voor gestructureerde tests is een Postman-collectie vaak netter dan een snel gekopieerd shell-commando. Ook daar moeten firewalladres, poort, gebruikersnaam, wachtwoord en objectwaarden als variabelen of secrets worden beheerd, niet hard in requests, screenshots of tickets. De collectie is geen beveiligingsconcept, maar helpt lees- en schrijfacties reproduceerbaarder te testen.

Een bereikbare API bewijst nog niet dat de geplande wijziging inhoudelijk veilig is. Voor productieve schrijfacties moet daarom eerst een ongevaarlijke leesquery werken en daarna een kleine, gecontroleerde wijziging worden getest.

API-toegang en gebruikersrechten

Een bron-IP alleen is geen volledig beveiligingsconcept. De beperking beperkt alleen van waar de API bereikbaar is. Daarnaast moet duidelijk zijn met welk account de API-toegang plaatsvindt en welke rechten dit account heeft.

Voor productieve omgevingen moet men controleren:

• Wordt er een eigen API- of serviceaccount gebruikt?
• Heeft het account alleen de benodigde rechten?
• Is duidelijk gedocumenteerd welke persoon of welk team verantwoordelijk is voor het account?
• Wordt het wachtwoord of geheim veilig opgeslagen?
• Wordt de toegang verwijderd als de integratie niet meer wordt gebruikt?
• Zijn wijzigingen via auditlogs te volgen?

Gedeelde beheerdersaccounts zijn problematisch voor API-processen. Als meerdere systemen of personen hetzelfde account gebruiken, wordt de traceerbaarheid zwakker. Voor wijzigingsanalyses is Sophos Firewall Audit Trail Logs controleren relevant.

Voor een dedicated API-account is een strak proces beter dan een snel gekopieerde full admin. In de Sophos-documentatie verschijnt dit onderdeel als Allow API access to administrators: niet alleen de bron wordt toegestaan, ook de administrator of het profiel moet de juiste toegang hebben.

1. Maak onder Profiles > Device access een administratorprofiel met de benodigde rechten.
2. Maak onder Authentication > Users een administratorgebruiker voor het API-proces.
3. Wijs het passende administratorprofiel toe.
4. Beperk Access time als de toegang slechts tijdelijk nodig is.
5. Beperk Login restriction for device access indien mogelijk tot de bedoelde bronnen.
6. Sta daarna API access en Device Access voor de juiste bron toe.

Sophos ondersteunt de officiële API’s en ongewijzigde voorbeeldscripts. Eigen integraties, wrappers en automatiseringen hebben toch een interne eigenaar, tests en een rollbackconcept nodig. “Werkt in het lab” is niet genoeg voor productieve schrijfbewerkingen.

MFA en API-gebruikers na SFOS 22

MFA is belangrijk voor interactieve administrator-toegang. Voor API- en automatiseringsprocessen moet authenticatie echter bewust worden gepland. Een script, monitoringtool of integratiesysteem kan niet zomaar een OTP-code invoeren als de gebruikte gebruiker MFA afdwingt.

In de Known Issues-lijst is een SFOS 22-special case gedocumenteerd: na een upgrade kunnen API-gebaseerde configuratiewijzigingen bij gemigreerde gebruikers mislukken als MFA actief is en geen one-time token wordt meegegeven. Niet-gemigreerde gebruikers kunnen zich in bepaalde gevallen anders gedragen. Operationeel is belangrijk dat men daaruit geen slordig “MFA overal uit” maakt, maar API-accounts netjes scheidt.

Aanbevolen aanpak:

1. Voor API-processen een eigen serviceaccount gebruiken.
2. Het account alleen de benodigde rechten geven.
3. API access aanvullend beperken tot vaste IP Hosts of managementnetwerken.
4. Controleren of MFA voor dit account technisch en operationeel zinvol is.
5. Als MFA voor het API-account niet praktisch is, het account extra strak controleren via bron, rechten, secret-opslag en audit trail.
6. Na een SFOS 22-upgrade alle API-processen met lees- en schrijfacties testen.

⚠️ API-gebruikers zonder MFA zijn geen vrijbrief voor brede rechten. Als een API-account om technische redenen zonder MFA draait, moeten bron-IP, rechten, wachtwoordopslag, verantwoordelijkheid en auditbaarheid strakker worden gecontroleerd.

Dit punt is vooral belangrijk bij automatiseringen die niet alleen lezen, maar ook configuratie wijzigen.

Voor productieve API-wijzigingen moeten minstens drie zaken worden gecontroleerd:

• Er is een actuele Sophos Firewall-backup beschikbaar.
• Het geplande API-account kan met succes een ongevaarlijke leesquery uitvoeren.
• Bij voorbereide massawijzigingen uit Sophos Firewall Config Studio werken de gegenereerde API- of curl-aanroepen met het geplande account.

Afbakening tot Device Access

De API-toegangscontrole is niet hetzelfde als Device Access. Device Access regelt lokale firewall-diensten zoals WebAdmin, SSH, User Portal, VPN Portal, DNS of Ping. De API access settings regelen daarentegen de toegang tot de beheersinterface van de XML API.

Toch behoren beide onderwerpen tot de managementverharding. Elke laag beperkt een ander deel van het aanvalsoppervlak:

• Device Access correct configureren: lokale firewall-diensten zoals WebAdmin, SSH, User Portal, VPN Portal, DNS of Ping
• API access control: IP-hosts die de XML API aanvullend mogen gebruiken
• MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren: interactieve logins voor WebAdmin, VPN Portal en Remote Access
• Named Admins en duidelijke rollen: Traceerbaarheid en schadeomvang van beheer- en serviceaccounts

Als een beheernetwerk WebAdmin, SSH en API mag gebruiken, moet dit netwerk bijzonder goed worden beschermd. Een gecompromitteerde client in het beheernetwerk is anders een directe toegang tot het firewallbeheer.

Gebruik en beoordeling

API-toegang moet regelmatig worden gecontroleerd. Vooral na migraties, dienstverlenerswisselingen, automatiseringsprojecten of firewall-upgrades blijven vaak oude bronnen staan.

Zinvolle beoordelingsvragen:

• Welke IP-hosts mogen momenteel API-toegang gebruiken?
• Zijn er objecten met het voorvoegsel apiconfig?
• Zijn deze objecten nog nodig?
• Komen namen en beschrijvingen overeen met het daadwerkelijke doel?
• Zijn er gedocumenteerde verantwoordelijken?
• Worden API-toegangen in een wijzigings- of auditproces meegenomen?
• Is er een actuele back-up voor grotere API-gebaseerde wijzigingen?

Voor API-gebaseerde wijzigingen moet altijd een back-up beschikbaar zijn. Het artikel Sophos Firewall Back-up maken of herstellen beschrijft waar men op moet letten bij back-up, herstel en compatibiliteit.

Typische fouten

• API access toegestaan voor een volledig clientnetwerk: Elke gecompromitteerde client uit dit netwerk kan de API bereiken.
• Oude apiconfig-objecten niet gecontroleerd: Gemigreerde oude uitzonderingen blijven ongemerkt actief.
• Serviceaccount gebruikt volledige adminrechten: Een gecompromitteerd secret heeft een onnodig grote impact.
• API-automatisering gebruikt een MFA-plichtige admin: Script of tool kan na SFOS-upgrade bij schrijfacties mislukken.
• Verkeerde poort in de tool: De admin-HTTPS-poort is gewijzigd, maar de tool gebruikt nog de oude poort.
• REST-logica verwacht: De tool stuurt REST-methoden in plaats van XML-payload via HTTP POST naar APIController.
• Tijdelijk provider-IP blijft actief: Externe toegang blijft langer mogelijk dan gepland.
• Geen documentatie van het doel: Latere admins weten niet of een vrijgave nog nodig is.
• API-wijzigingen zonder backup: Foutieve automatisering is lastiger terug te draaien.

Probleemoplossing

Als een tool de XML API niet bereikt, moet men gestructureerd controleren:

1. Klopt de bron-IP vanuit het perspectief van de firewall?
2. Is de bron toegestaan als IP-host, IP-bereik of netwerk?
3. Is er na een upgrade een apiconfig-object gegenereerd, maar niet correct aangepast?
4. Staat Device Access lokale WebAdmin/API-toegang vanuit deze zone toe?
5. Gebruikt het tool het juiste firewalladres en de juiste admin-HTTPS-poort?
6. Kloppen gebruikersnaam, wachtwoord of geheim?
7. Heeft het account de benodigde rechten?
8. Dwingt het account MFA af, terwijl het tool geen eenmalige token kan doorgeven?
9. Zijn er routerings-, NAT- of proxy-effecten tussen het tool en de firewall?
10. Is de toegang opzettelijk verwijderd door een verhardingsmaatregel?
11. Is getest vanaf het juiste bronsysteem of alleen vanaf de admin-client?

Als een API-wijziging onverwachte gevolgen heeft, eerst de laatste back-up veiligstellen en daarna audit trail, Config Studio-vergelijking en getroffen firewall-objecten controleren. Bij live-verkeerproblemen helpen Log Viewer en Packet Capture meer dan de API zelf.

Checklist

Voor activering:

• Doel van de API-toegang documenteren.
• Bronsysteem duidelijk bepalen.
• IP-hostobject met duidelijke naam maken.
• Serviceaccount en rechten controleren.
• MFA-gedrag van het API-account bewust vaststellen.
• Back-up- en rollback-proces vaststellen.
• Testmethode zonder secret-lek vastleggen.

Tijdens gebruik:

• API-toegang alleen toestaan voor gedefinieerde bronnen.
• Geen brede client-, gast- of IoT-netwerken toestaan.
• apiconfig-objecten na upgrades controleren.
• Dienstverlenerstoegangen tijdig en inhoudelijk controleren.
• Geheimen beschermd opslaan en bij personeels- of toolwissel vernieuwen.
• Secrets roteren als ze in shell history, tickets of onveilige opslag terecht zijn gekomen.
• API-lees- en schrijfoperaties na SFOS-upgrades gericht testen.

Bij beoordeling:

• Toegestane API-bronnen regelmatig controleren.
• Niet meer benodigde IP-hosts verwijderen.
• Wijzigingen met audit trail en wijzigingstickets afstemmen.
• Automatiseringsprocessen na firmware-updates testen.

FAQ