Sophos Firewall XML API-toegang beveiligen

De XML API van de Sophos Firewall is handig voor automatisering, monitoring, back-ups, analyses en integraties. Hiermee kan dezelfde configuratie ook reproduceerbaar op meerdere firewalls worden toegepast wanneer het proces nauw is afgebakend en getest. 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.

In oudere SFOS-versies stond de API-configuratie onder Backup and firmware > API. Houd bij het vergelijken met oudere instructies rekening met dit gewijzigde menupad.

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.

HTTPS beschermt credentials alleen betrouwbaar tegen onderschepping en manipulatie als de client het firewallcertificaat valideert. Het automatiseringssysteem moet daarom de naam uit het certificaat gebruiken, de uitgevende CA vertrouwen en stoppen bij certificaat- of hostnaamfouten. Opties zoals curl -k omzeilen deze controle en horen niet thuis in productietaken.

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.
• Negatieve test: Stuur vanaf een gecontroleerde testhost die bewust niet onder Allowed IP hosts staat hetzelfde onschadelijke leesverzoek en controleer of de API dit afwijst zonder configuratiegegevens terug te sturen. Versoepel of verwijder geen productieautorisatie enkel om deze test uit te voeren.
• 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.

XML-requests bewust opbouwen en beoordelen

Versiegrens: De SFOS 22-instructies noemen browsers als XML-clients. Vanaf SFOS 23.0 sluit de specifieke verzendinstructie voor XML-verzoeken browsers expliciet uit; gebruik Postman of een gecontroleerde Linux-commandline voor deze POST-verzoeken. Het algemene XML-overzicht noemt nog browsers, maar staat browser-POST in SFOS 23.0 daarmee niet toe. De lokale REST API met beheerderssleutels is een aparte interface, geen nieuwe authenticatiemethode voor deze XML-payloads.

De hier getoonde configuratiequery’s en wijzigingen gebruiken HTTP POST naar dezelfde APIController. Lezen, aanmaken, bijwerken of verwijderen wordt bepaald in de XML-payload, niet in de HTTP-methode. XML <Get> betekent lezen, niet automatisch HTTP GET; ook de Object Usage-query met de naam “API GET request” wordt per HTTP POST verstuurd. Certificaatexport hieronder is een afzonderlijk gedocumenteerde HTTP GET-uitzondering. De buitenste structuur bestaat uit <Request>, <Login> en precies de benodigde bewerking:

• <Set operation="add"> maakt ondersteunde objecten, regels of policies aan.
• <Set operation="update"> wijzigt instellingen die niet als nieuw object kunnen worden aangemaakt.
• <Get> leest configuraties of statusgegevens.
• <Remove> verwijdert ondersteunde objecten. Vaste instellingen zoals de SSL/TLS Inspection-configuratie kunnen niet worden verwijderd, maar alleen bijgewerkt.
• <Filter> beperkt een leesquery. De algemene criteria zijn =, != en like; afzonderlijke statistiekquery’s ondersteunen aanvullende criteria.

Als operation bij <Set> ontbreekt, behandelt SFOS de request als add. Dat is geen onschuldige standaardwaarde: een request die als update bedoeld was, kan mislukken of op het verkeerde object werken. APIXMLTags documenteert het optionele alfanumerieke attribuut transactionid op <Set>; het maakt het eenvoudiger om request en response aan elkaar te koppelen. Volg voor gespecialiseerde bewerkingen het objectvoorbeeld in API help van de geïnstalleerde SFOS-build. Het certificaatvoorbeeld plaatst transactionid op <Certificate>; deze uitzondering is geen algemene regel voor plaatsing op entiteitstags binnen <Set>.

Het optionele attribuut APIVersion in <Request> gebruikt versiespecifieke syntaxis. De exacte objecttags, attributen, statuscodes en voorbeeldconfiguraties moeten daarom afkomstig zijn uit API help van de geïnstalleerde SFOS-build; payloads mogen niet ongecontroleerd tussen versies worden overgenomen.

Een kleine leesquery heeft schematisch deze opbouw:

<Request>
  <Login>
    <Username>api-reader</Username>
    <Password>SECRET</Password>
  </Login>
  <Get>
    <IPHost></IPHost>
  </Get>
</Request>

api-reader en SECRET zijn placeholders. Het echte secret hoort in de beveiligde secret store van het tool, niet in een XML-bestand in de repository. De test is pas geslaagd als de response onder <Response> de verwachte inhoud en onder <Status> een passende status toont. Een HTTP-succes of Send successful in Postman bewijst op zichzelf niet dat SFOS de gewenste bewerking heeft uitgevoerd. Controleer bij schrijfacties ook het doelobject in WebAdmin en de wijziging in de Audit Trail.

De officiële Postman-collectie veilig gebruiken

Download en importeer de actuele Postman-collectie. De collectie dekt slechts een deel van de ondersteunde requests; de lokale API help van de firewall toont alle bewerkingen en de build-specifieke voorbeeldconfiguraties en entiteitsdefinities. Vervang vóór de eerste request onder Collection Variables alle vier meegeleverde voorbeeldwaarden apiadmin, Admin@12345, 172.16.16.16 en 4444 door de waarden username, password, firewall-ip en firewall-port van de eigen omgeving. Ook de opgenomen objectwaarden zijn voorbeelden en mogen niet zonder controle worden verzonden.

Gebruik voor een eigen request methode POST, de hierboven getoonde endpoint en de key reqxml onder Body > form-data. Test eerst Authenticate > Sign in en daarna een ongevaarlijke <Get>-query. Pas als bron, account, response en audit kloppen, volgt een kleine schrijfactie met voorbereid rollback.

Gevoelige XML-imports: Controleer vóór het importeren van wachtwoorden of andere gevoelige waarden in API help van de geïnstalleerde build of de specifieke bewerking SecureStorageMasterKey en het attribuut Token op <Request> vereist en welke invoer geldig is. In het POST-voorbeeld van SFOS 23 is SecureStorageMasterKey een afzonderlijke invoer in de body; Token staat op <Request> in de XML van het bodyveld reqxml. Verstuur alleen de voor die bewerking bevestigde invoer op de goedgekeurde POST-body-/XML-locaties. Houd sleutels, wachtwoorden en tokens in deze workflow buiten URL’s, shellgeschiedenis en logs; dit betekent niet dat elke XML-query een token vereist.

De documentatie bevat daarnaast nog een tegenstrijdig URL-voorbeeld voor de hoofdsleutel. Voer de gevoelige import niet uit zolang een bronnenconflict, vereiste invoer of de interpretatie daarvan voor de geïnstalleerde build onduidelijk blijft; vraag Support om opheldering. De afzonderlijk beveiligde certificaatexport via HTTP GET hieronder blijft een aparte uitzondering.

Een geëxporteerde collectie kan credentials of omgevingswaarden bevatten. Reinig collecties voordat ze worden gedeeld, sla secrets niet als platte tekst op in Initial Values en roteer testwachtwoorden na een lek.

Object Usage vóór wijzigingen opvragen

De API kan voor ondersteunde objecten de naam en Usage Count teruggeven. Hiervoor worden statistiektags zoals <IPHostStatistics> gebruikt in plaats van de normale objecttag. Een filter op namen van IP Hosts ziet er bijvoorbeeld zo uit:

<Request>
  <Login>
    <Username>api-reader</Username>
    <Password>SECRET</Password>
  </Login>
  <Get>
    <IPHostStatistics>
      <Filter>
        <key name="Name" criteria="like">branch</key>
      </Filter>
    </IPHostStatistics>
  </Get>
</Request>

SFOS 22 ondersteunt deze gebruiksquery voor IP Hosts, IP Host Groups, MAC Hosts, FQDN Hosts en groepen, Country Groups, Services en Service Groups, evenals Interfaces, Zones, Gateways en SD-WAN Profiles. Naamfilters ondersteunen onder meer like, not like, startswith, in, = en !=; de Usage Count daarnaast >, >= en getallenlijsten met in.

De response bevat momenteel alleen de objectnaam en het aantal toepassingen, niet de afhankelijke configuraties. Een Usage Count van 3 vermeldt dus niet welke drie regels of profielen betrokken zijn. Controleer vóór een update- of remove-bewerking ook Object usage in WebAdmin of Config Studio. Een waarde van 0 is evenmin toestemming voor ongecontroleerd verwijderen: backup, afhankelijkheidscontrole en een gerichte test blijven verplicht.

Live Users via de API aan- en afmelden

SFOS kan een gebruiker via de API als Live User aan- of afmelden. Dit is geschikt voor een integratie met een extern authenticatiesysteem waarvoor het eigenaarschap duidelijk is geregeld, maar het is geen algemene snelkoppeling om de normale gebruikersaanmelding te omzeilen. Een onjuiste aanmelding koppelt verkeer aan een identiteit en kan daardoor gebruikersgebaseerde firewall- of webregels beïnvloeden.

Voor de beheerder die de bewerking uitvoert, moet Manage live users onder Profiles > Device access > Identity op Read-write staan. Het hiervoor bedoelde endpoint is:

https://<Firewall-IP-of-FQDN>:<Port>/xmlapi/v1/authentication/networkuser

Dit endpoint verwerkt aan- en afmeldingen parallel. De algemene APIController kan dezelfde bewerkingen serieel verwerken. Een bestaande integratie mag daarom niet zonder test worden gemigreerd alleen vanwege dit verschil in gedrag.

Een payload voor aanmelden kan er zo uitzien:

<Request>
  <LiveUserLogin>
    <Admin>
      <UserName>api-liveusers</UserName>
      <Password>ADMIN_SECRET</Password>
    </Admin>
    <UserName>testuser</UserName>
    <IPAddress>192.0.2.25</IPAddress>
    <MacAddress>AA-BB-CC-DD-EE-FF</MacAddress>
  </LiveUserLogin>
</Request>

Om af te melden wordt dezelfde logische gebruiker met LiveUserLogout verzonden:

<Request>
  <LiveUserLogout>
    <Admin>
      <UserName>api-liveusers</UserName>
      <Password>ADMIN_SECRET</Password>
    </Admin>
    <UserName>testuser</UserName>
    <IPAddress>192.0.2.25</IPAddress>
    <MacAddress>AA-BB-CC-DD-EE-FF</MacAddress>
  </LiveUserLogout>
</Request>

api-liveusers, ADMIN_SECRET, testuser, 192.0.2.25 en het MAC-adres zijn voorbeeldwaarden. Gebruikersnaam, IP-adres en MAC-adres moeten bij de werkelijke sessie passen. Bewaar het admin-secret in de beveiligde secret store van het hulpmiddel en verstuur het in de HTTP-POST-body, niet in een URL, shellgeschiedenis, logbestand of gedeelde collection.

Na het aanmelden moet de gebruiker onder Current activities > Live users met Client type API client verschijnen. Een gecontroleerde test controleert daarna de verwachte beslissing van de gebruikersgebaseerde regel. Na het afmelden mag de sessie niet meer als actieve API-client worden vermeld. Blijft de gebruiker zichtbaar, controleer dan eerst payload, gebruikersnaam, IP-adres, MAC-adres en API-response; meld niet op goed geluk een andere Live User-sessie af.

Certificaten via de API overdragen of exporteren

Certificaten zijn een bijzonder geval omdat naast XML ook bestanden worden overgedragen. Gebruik om een certificaat aan te maken of bij te werken in de Postman-desktopapp een form-data-request met drie delen: certificaatbestand, Private Key-bestand en reqxml met een <Set><Certificate>...</Certificate></Set>-payload. Bestandsnamen, formaat, actie en certificaatnaam in de XML moeten bij de geüploade bestanden passen.

Private Keys horen uitsluitend op het beveiligde admin-endpoint en mogen nooit in een cloudcollectie, ticket of repository terechtkomen. Beoordeel na Send eerst <Response> en <Status> en controleer vervolgens onder Certificates > Certificates of precies het verwachte certificaat, de passende sleutel en de juiste keten aanwezig zijn. Toewijzing en diensttest volgen de procedure Certificaten op Sophos Firewall importeren en toewijzen. Het volledige automatiseringstraject van de openbare CA via de buildspecifieke upload tot de diensttoewijzing en externe controle staat in Een Sophos Firewall-certificaat via de XML API vernieuwen en diensten controleren.

Een <Get><Certificate/></Get>-request levert een .tar-archief met certificaten, Private Keys en Entities.xml, geen normaal XML-resultaat. Het werkt dus niet als gewone Postman-response. De specifieke certificaatinstructie documenteert HTTP GET via Linux of browser; beide varianten zetten credentials in de reqxml van de URL.

SFOS 23.0: Deze GET-instructie noemt nog browsers, terwijl de POST-instructie ze uitsluit. Dat bewijst geen verbod op alle HTTP GET-verzoeken en evenmin een browserexport die op deze firmware is getest. Neem geen oudere browserinstructies over en veronderstel niet dat POST dezelfde download oplevert. Verifieer vóór export met Support of in een toegestaan testsysteem het CLI GET-pad en veilig credentialbeheer voor de geïnstalleerde build; exporteer niet zonder die verificatie.

Gebruik voor een geverifieerde export alleen een tijdelijk, beperkt account op een beveiligde beheerhost, log URL of opdracht niet en roteer daarna het geheim. Valideer TLS-certificaat en hostnaam; neem -k uit fabrikantvoorbeelden niet over in productie. Het archief is uiterst gevoelig: versleuteld opslaan met beperkte toegang, gecontroleerd uitpakken en overbodige kopieën veilig verwijderen.

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. De algemene planning van persoonlijke accounts en beperkte profielen staat in Sophos Firewall-beheerders en profielen veilig instellen; voor automatiseringen blijft het hier beschreven afzonderlijke serviceaccount bepalend. 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.

In het officiële voorbeeld krijgt het profiel Read-write voor Objects en Network. Dit is geen algemene aanbeveling: bij integraties met alleen leestoegang en andere API-taken blijven niet-benodigde onderdelen op None of Read-only; schrijftoegang wordt pas na een gecontroleerde leestest toegekend.

Sophos ondersteunt de officiële API’s en ongewijzigde voorbeeldscripts. Sophos Technical Support geeft geen advies of probleemoplossing voor aangepaste integraties; Sophos verwijst dit werk naar de verantwoordelijke Sophos Partner of Sophos Professional Services. Eigen integraties, wrappers en automatiseringen hebben daarom 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.

De huidige Known Issues-lijst documenteert NC-177609 voor SFOS 22.0.0 GA Respin Build 411: 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 behouden het eerdere gedrag totdat ze MFA-onboarding doorlopen. De officiële workaround is een afzonderlijk API-account zonder MFA of uitsluiting van dat account van MFA. Dit is geen reden om MFA voor interactieve administrators uit te schakelen; controleer voor nieuwere builds eerst de Release Notes en Known Issues.

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, maar beide controles werken samen. Device Access regelt lokale firewall-diensten zoals WebAdmin, SSH, User Portal, VPN Portal, DNS of Ping. De instellingen voor API access bepalen daarnaast welke IP Hosts de XML API mogen gebruiken. Belangrijk: de Device Access-toestemmingen voor de WebAdmin Console gelden ook voor API-toegang.

In de praktijk moet API access zijn ingeschakeld, moet de bron in de API access-instellingen zijn toegestaan en mag Device Access de lokale beheertoegang tot de firewall niet blokkeren. 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.

Voor toegang vanaf WAN mag HTTPS/WebAdmin niet voor de volledige WAN-zone worden ingeschakeld. Als externe API- of beheerstoegang werkelijk nodig is, gebruikt men een Local service ACL exception rule met een nauw begrensde Source, de passende Service HTTPS, een vastgelegde regelpositie en een gedocumenteerde periode.

HA: toegang na een failover controleren

In een HA-cluster wordt de firewallconfiguratie van de Primary naar de Auxiliary gesynchroniseerd; de dedicated HA-link en Administration Ports worden niet gesynchroniseerd. API-clients moeten daarom de bedoelde clusternaam of het gedeelde interfaceadres gebruiken en niet ongemerkt afhankelijk zijn van een nodespecifiek beheeradres.

Herhaal na de HA-configuratie, een certificaatwijziging of failover een leestest en een negatieve test. Controleer DNS-resolutie, certificaatnaam, bron-IP, adminpoort, API access en Device Access. Een gesynchroniseerd hostobject bewijst op zichzelf niet dat het volledige netwerk- en TLS-pad na de rolwisseling werkt.

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.
• Alleen de HTTP-status gecontroleerd: De eigenlijke API-bewerking is mislukt, hoewel het transport succesvol was. Beoordeel <Response> en <Status>.
• Set zonder bewerking verzonden: SFOS behandelt de request als add, hoewel een update was gepland.
• MFA-instellingen of tokens kunnen niet worden geïmporteerd: De payload moet het lege element <tokenid/> bevatten.
• Een gebruiker kan niet worden verwijderd: Geef in de <Remove>-payload de exacte gebruikersnaam op als <Name>username</Name>. Controleer vóór het request het account, de afhankelijkheden, de back-up en de rollback.
• Usage Count als volledige afhankelijkheidslijst opgevat: De statistiek levert aantal en naam, maar niet de betrokken regels of profielen.
• Live User aangemeld zonder sessiecorrelatie: Gebruikersnaam, IP-adres en MAC-adres passen niet bij de werkelijke sessie, waardoor gebruikersgebaseerde regels verkeerd kunnen beslissen.
• Certificaatarchief onbeschermd opgeslagen: De API-export kan Private Keys bevatten en hoort niet thuis in Downloads, tickets of gedeelde opslag.
• 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.

Sla bij een geweigerde of foutieve XML-bewerking eerst <Response> en <Status> op. Controleer daarna apiparser.log, validation.log en validationError.log onder Diagnostics > Troubleshooting logs; Sophos koppelt deze bestanden aan API-vertaling en API-validatie. Sophos Firewall-service- en logbestanden beschrijft het filteren en exporteren. Verwijder secrets voordat u een logfragment deelt.

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.
• De geplande XML-bewerking en verwachte <Status> documenteren.

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.
• Object Usage en afhankelijke configuraties vóór update- of remove-bewerkingen controleren.
• API-gebaseerde Live User-aanmeldingen met API client, de regelbeslissing en een correcte afmelding valideren.
• Certificaatbestanden, Private Keys en API-exports uitsluitend beschermd verwerken.

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