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, 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-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 toestaan vanuit gedefinieerde bronnen

API-toegang moet op dezelfde manier worden behandeld als WebAdmin of SSH: zo beperkt mogelijk, zo breed als nodig.

Zinvolle bronnen zijn bijvoorbeeld:

• een toegewijde automatiseringsserver,
• een monitoringsysteem,
• een configuratiebeheerhost,
• een intern beheernetwerk,
• een VPN- of beheernetwerk,
• een duidelijk gedefinieerd partner- of MSP-bronadres.

Niet zinvol zijn:

• hele clientnetwerken,
• gast- of IoT-netwerken,
• Any,
• onduidelijke “servernetwerk compleet”-toestemmingen,
• 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 worden gedocumenteerd waarvoor de toegang wordt gebruikt en wanneer deze weer wordt verwijderd.

Aanbevolen procedure

Het exacte UI-pad kan enigszins variëren afhankelijk van de SFOS-versie. In SFOS 22 bevindt de API-configuratie zich onder Administration.

Praktische procedure:

1. Controleren welk systeem API-toegang nodig heeft.
2. Voor dit systeem een uniek IP-hostobject maken.
3. Als meerdere bronnen nodig zijn, IP-hosts of netwerken correct benoemen.
4. API-toegang alleen voor deze objecten toestaan.
5. Geen brede client- of servernetwerken invoeren.
6. Toegang testen met het betreffende tool.
7. Niet meer benodigde bronnen weer verwijderen.
8. Wijziging documenteren in het wijzigingsproces.

Bij bestaande installaties na een upgrade naar SFOS 22 moet men ook zoeken naar objecten met het voorvoegsel apiconfig. Deze objecten zijn gegenereerd uit oudere API-toestemmingen en moeten worden gecontroleerd, benoemd of opgeschoond.

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.

MFA en API-gebruikers na SFOS 22

MFA is belangrijk voor interactieve beheerderslogins. Voor API- en automatiseringsprocessen moet men echter bewust plannen hoe authenticatie moet werken. Een script, monitoringtool of integratiesysteem kan niet zomaar een OTP-code invoeren als de gebruikte gebruiker MFA afdwingt.

In de lijst met bekende problemen is een SFOS-22-uitsondering gedocumenteerd: Na een upgrade kunnen API-gebaseerde configuratiewijzigingen bij gemigreerde gebruikers mislukken als MFA actief is en er geen eenmalige token wordt doorgegeven. Niet-gemigreerde gebruikers kunnen zich in bepaalde gevallen anders gedragen. Voor gebruik is het belangrijk dat men hieruit geen onzuivere “MFA overal uit” maakt, maar API-accounts correct scheidt.

Aanbevolen aanpak:

1. Voor API-processen een eigen serviceaccount gebruiken.
2. Het account alleen met de benodigde rechten uitrusten.
3. API-toegang daarnaast beperken tot vaste IP-hosts of beheernetwerken.
4. Controleren of MFA voor dit account technisch en operationeel zinvol is.
5. Als MFA voor het API-account niet praktisch is, het account bijzonder nauwkeurig controleren op bron, rechten, geheimopslag en audit trail.
6. Na een SFOS-22-upgrade alle API-processen met lees- en schrijfoperaties testen.

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

Dit punt is vooral belangrijk bij automatiseringen die niet alleen lezen, maar ook configuraties wijzigen. Voor productieve API-wijzigingen moet er een actuele back-up van de Sophos Firewall beschikbaar zijn. Bij voorbereide massa-aanpassingen vanuit Sophos Firewall Config Studio moet men bovendien controleren of de gegenereerde API- of curl-aanroepen met het geplande account werken.

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:

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

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. Gebruikt het tool het juiste firewalladres en de juiste poort?
5. Kloppen gebruikersnaam, wachtwoord of geheim?
6. Heeft het account de benodigde rechten?
7. Dwingt het account MFA af, terwijl het tool geen eenmalige token kan doorgeven?
8. Zijn er routerings-, NAT- of proxy-effecten tussen het tool en de firewall?
9. Is de toegang opzettelijk verwijderd door een verhardingsmaatregel?

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.

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.
• 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