Säkra åtkomst till Sophos Firewall XML API

Sophos Firewalls XML API är praktisk för automatisering, övervakning, säkerhetskopiering, analyser och integrationer. Just därför utgör den också en del av hanteringsytan för attacker. Att tillåta API-åtkomst ger ett system möjlighet att läsa konfigurationsdata eller, beroende på behörighet, göra ändringar.

API-åtkomst bör därför inte tillåtas brett från interna nätverk eller från godtyckliga källor. Det är bättre med en liten, dokumenterad uppsättning av hanteringsnätverk, automationsvärdar eller fasta partneråtkomster.

Sedan SFOS 22 har Sophos utökat API-åtkomstkontrollen. API access settings finns under Administration, och tillåtna källor kan definieras som IP-värdar. Detta gör det möjligt att modellera inte bara enskilda IP-adresser, utan även IP-områden och nätverk på ett korrekt sätt.

När XML API-åtkomst är meningsfull

XML API är ingen standardåtkomst för vanligt administrativt arbete. Det är meningsfullt att använda den när det finns en konkret teknisk process bakom.

Typiska användningsfall:

• Övervakning eller inventering.
• Automatiserade konfigurationskontroller.
• Säkerhetskopierings- eller dokumentationsprocesser.
• MSP- eller integrationsplattformar.
• Skript för återkommande administrativa uppgifter.
• Förberedda ändringar från verktyg som Sophos Firewall Config Studio.

Om en process kan fungera utan API bör API-åtkomst inte förbli aktiverad i förebyggande syfte. Varje ytterligare gränssnitt behöver en ägare, en källa, ett åtkomstkoncept och en kontroll.

Vad som har ändrats med SFOS 22

Med SFOS 22 har XML API-åtkomstkontrollen blivit betydligt mer hanterbar:

• API access settings har flyttats till menyn Administration.
• API-åtkomst kan begränsas till IP-värdar.
• Som källor kan IP-adresser, IP-områden och nätverk användas.
• Upp till 64 IP-värdar kan tillåtas.
• Vid uppgradering omvandlas tidigare tillåtna IP-adresser automatiskt till IP-värdobjekt.
• Migrerade objekt får prefixet apiconfig.

Detta är användbart för driften eftersom API-källor inte längre behöver hanteras som lösa enskilda adresser. Man kan namnge ett hanteringsnätverk, en automationsvärd eller en dedikerad värdgrupp korrekt och senare känna igen dem i granskningar.

Grundregel: Tillåt API endast från definierade källor

API-åtkomst bör behandlas enligt samma princip som WebAdmin eller SSH: så snävt som möjligt, så brett som nödvändigt.

Lämpliga källor är till exempel:

• en dedikerad automationsserver,
• ett övervakningssystem,
• en konfigurationshanteringsvärd,
• ett internt hanteringsnätverk,
• ett VPN- eller adminnätverk,
• en tydligt definierad partner- eller MSP-källadress.

Inte lämpliga är:

• hela klientnätverk,
• gäst- eller IoT-nätverk,
• Any,
• oklara “servernätverk komplett”-frisläppningar,
• temporära test-IP-adresser som senare glöms bort.

Om externa tjänsteleverantörer behöver API-åtkomst bör källan definieras så specifikt som möjligt. Dessutom bör det dokumenteras vad åtkomsten används till och när den ska tas bort.

Rekommenderad procedur

Den exakta UI-sökvägen kan variera något beroende på SFOS-version. I SFOS 22 ligger API-konfigurationen under Administration.

Praktisk procedur:

1. Kontrollera vilket system som behöver API-åtkomst.
2. Skapa ett tydligt IP-värdobjekt för detta system.
3. Om flera källor behövs, namnge IP-värdar eller nätverk korrekt.
4. Tillåt API-åtkomst endast för dessa objekt.
5. Ange inga breda klient- eller servernätverk.
6. Testa åtkomst med det berörda verktyget.
7. Ta bort källor som inte längre behövs.
8. Dokumentera ändringen i förändringsprocessen.

För befintliga installationer efter en uppgradering till SFOS 22 bör man dessutom söka efter objekt med prefixet apiconfig. Dessa objekt har skapats från äldre API-tillåtna poster och bör granskas, namnges eller rensas.

API-åtkomst och användarrättigheter

En käll-IP ensam är inget fullständigt säkerhetskoncept. Begränsningen begränsar bara varifrån API:n är tillgänglig. Dessutom måste det vara klart med vilket konto API-åtkomst sker och vilka rättigheter detta konto har.

För produktiva miljöer bör man kontrollera:

• Används ett eget API- eller servicekonto?
• Har kontot endast de nödvändiga behörigheterna?
• Är det tydligt dokumenterat vilken person eller vilket team som är ansvarigt för kontot?
• Lagrar man lösenordet eller hemligheten säkert?
• Tas åtkomsten bort när integrationen inte längre används?
• Är ändringar spårbara via granskningsloggar?

Delade administratörskonton är problematiska för API-processer. Om flera system eller personer använder samma konto blir spårbarheten svagare. För förändringsanalyser är Sophos Firewall Audit Trail Logs granska relevant.

MFA och API-användare efter SFOS 22

MFA är viktigt för interaktiva administratörsåtkomster. För API- och automationsprocesser måste man dock medvetet planera hur autentisering ska fungera. Ett skript, övervakningsverktyg eller integrationssystem kan inte enkelt ange en OTP-kod om den använda användaren tvingar MFA.

I listan över kända problem är ett SFOS-22-undantag dokumenterat: Efter en uppgradering kan API-baserade konfigurationsändringar misslyckas för migrerade användare om MFA är aktiv och ingen engångstoken överförs. Icke-migrerade användare kan i vissa fall bete sig annorlunda. För driften är det viktigt att man inte gör ett osnyggt “MFA överallt av”, utan att API-konton separeras korrekt.

Rekommenderad strategi:

1. Använd ett eget servicekonto för API-processer.
2. Utrusta kontot endast med de nödvändiga rättigheterna.
3. Begränsa API-åtkomst ytterligare till fasta IP-värdar eller hanteringsnätverk.
4. Kontrollera om MFA är tekniskt och operativt meningsfullt för detta konto.
5. Om MFA inte är praktiskt för API-kontot, kontrollera kontot särskilt noggrant genom källa, rättigheter, hemlagring och granskningsspår.
6. Efter en SFOS-22-uppgradering, testa alla API-processer med läs- och skrivoperationer.

⚠️ API-användare utan MFA är ingen fribiljett för breda rättigheter. Om ett API-konto av tekniska skäl drivs utan MFA måste käll-IP, rättigheter, lösenordslagring, ansvar och spårbarhet kontrolleras noggrannare.

Detta är särskilt viktigt vid automationer som inte bara läser utan också ändrar konfiguration. Innan produktiva API-ändringar bör en aktuell säkerhetskopiering av Sophos Firewall finnas tillgänglig. Vid förberedda massändringar från Sophos Firewall Config Studio bör man dessutom kontrollera om de genererade API- eller curl-anropen fungerar med det planerade kontot.

Avgränsning till Device Access

API-åtkomstkontroll är inte detsamma som Device Access. Device Access styr lokala brandväggstjänster som WebAdmin, SSH, User Portal, VPN Portal, DNS eller Ping. API access settings styr däremot åtkomsten till hanteringsgränssnittet för XML API.

Trots detta hör båda ämnena ihop för att stärka hanteringen. Varje lager begränsar en annan del av attackytan:

Om ett adminnätverk får använda WebAdmin, SSH och API bör detta nätverk skyddas särskilt väl. En komprometterad klient i hanteringsnätverket är annars en direkt ingång till brandväggshanteringen.

Drift och granskning

API-åtkomst bör regelbundet granskas. Särskilt efter migrationer, tjänsteleverantörsbyten, automationsprojekt eller brandväggsuppgraderingar finns ofta gamla källor kvar.

Lämpliga granskningsfrågor:

• Vilka IP-värdar får för närvarande använda API-åtkomst?
• Finns det objekt med prefixet apiconfig?
• Är dessa objekt fortfarande nödvändiga?
• Stämmer namn och beskrivningar med det faktiska syftet?
• Finns det dokumenterade ansvariga?
• Beaktas API-åtkomst i en förändrings- eller granskningsprocess?
• Finns det en aktuell säkerhetskopiering före större API-baserade ändringar?

Innan API-baserade ändringar bör alltid en säkerhetskopiering finnas tillgänglig. Artikeln Skapa eller återställa säkerhetskopiering av Sophos Firewall beskriver vad man bör tänka på vid säkerhetskopiering, återställning och kompatibilitet.

Typiska fel

Felsökning

Om ett verktyg inte når XML API bör man strukturerat kontrollera:

1. Stämmer käll-IP:n ur brandväggens perspektiv?
2. Är källan tillåten som IP-värd, IP-område eller nätverk?
3. Har ett apiconfig-objekt skapats efter en uppgradering men inte anpassats korrekt?
4. Använder verktyget rätt brandväggsadress och port?
5. Stämmer användarnamn, lösenord eller hemlighet?
6. Har kontot de nödvändiga rättigheterna?
7. Tvingar kontot MFA, även om verktyget inte kan överföra en engångstoken?
8. Finns det routing-, NAT- eller proxy-effekter mellan verktyget och brandväggen?
9. Har åtkomsten avsiktligt tagits bort genom en härdningsåtgärd?

Om en API-ändring har oväntade effekter, säkerställ först den senaste säkerhetskopieringen och kontrollera sedan granskningsspår, Config Studio-jämförelse och berörda brandväggsobjekt. Vid problem med live-trafik är Log Viewer och Packet Capture mer användbara än själva API:n.

Checklista

Innan aktivering:

• Dokumentera syftet med API-åtkomsten.
• Bestäm källsystemet tydligt.
• Skapa IP-värdobjekt med beskrivande namn.
• Kontrollera servicekonto och behörigheter.
• Fastställ medvetet MFA-beteendet för API-kontot.
• Fastställ säkerhetskopierings- och återställningsprocess.

Under drift:

• Tillåt API-åtkomst endast för definierade källor.
• Frigör inga breda klient-, gäst- eller IoT-nätverk.
• Granska apiconfig-objekt efter uppgraderingar.
• Kontrollera tjänsteleverantörsåtkomster tidsmässigt och funktionellt.
• Lagra hemligheter skyddat och förnya vid personal- eller verktygsbyte.
• Testa API-läs- och skrivoperationer specifikt efter SFOS-uppgraderingar.

Vid granskning:

• Granska tillåtna API-källor regelbundet.
• Ta bort IP-värdar som inte längre behövs.
• Jämför ändringar med granskningsspår och förändringsbiljetter.
• Testa automationsprocesser efter firmwareuppdateringar.

FAQ