Gå til indhold
Dokumentation sslbrain sslbrain.com

Barracuda CloudGen Firewall

Kopiér link til siden “Barracuda CloudGen Firewall”

← Alle integrationer

Firewall og VPN beta

Sætter VPN-tjenestens standardcertifikat i CloudGen og finder certifikater i firewallens og Control Centers lagre.

Appliancen kører pakken og forbinder til Barracuda CloudGen Firewall gennem CloudGen Firewall REST API over HTTPS på port 8443. Der installeres ingen agent på Barracuda CloudGen Firewall.

Sådan forløber det

  1. Appliancen forbinder til Barracuda CloudGen Firewall gennem CloudGen Firewall REST API på port 8443.
  2. Discovery læser certifikatlageret (fra 10.0; på 9.x den ældre certifikatliste), på et Control Center også det globale lager og range- og cluster-lagrene, og lister tjenesterne med navn og modul, så reglen kan nævne VPN-tjenesten. Et 9.x Control Center har ingen certifikatliste for range og cluster i REST API; de meldes som ikke læst.
  3. Installation: pakken kontrollerer, at nøglen hører til certifikatet, åbner en konfigurationssession, læser VPN-tjenestens indstillinger, skriver certifikat, privat og offentlig nøgle med tjenestens øvrige nøgler uændret, læser sessionen tilbage og committer. Et Control Center sender derefter konfigurationen til boxen og venter, til boxen melder opdateringen gennemført. Hvis det fejler: Fejler et trin før commit, rulles sessionen tilbage, og intet er ændret. Besvares commit ikke, afgør en ny læsning af indstillingerne, om certifikatet skiftede. Fejler noget efter commit, melder pakken det som en ændring, der kræver opfølgning, aldrig som uændret. Ender Control Centers opdatering i fejl, eller kan den ikke bekræftes, har Control Center det nye certifikat, mens det ikke kan læses, hvilket boxen bruger; næste forsøg sender konfigurationen igen uden at skrive den på ny.
  4. Bagefter læser pakken VPN-tjenestens tilstand. Tjenesten genstartes kun, når reglen beder om det, og kun på en enkeltstående firewall; en genstart afbryder alle tjenestens VPN-tunneler og forbindelser. Hvis det fejler: På en enkeltstående firewall: var tjenesten oppe før skiftet og er nede efter, og har indstillingerne stadig pakkens certifikat, skriver pakken det certifikat og den nøgle tilbage, den læste i samme kørsel, og melder fejl. En ændring, en anden har lavet siden, overskrives ikke. Control Centers REST API dokumenterer ingen tilstand for en tjeneste på en administreret box, så dér skriver pakken intet tilbage.
  5. Kontrol: pakken finder certifikatet i lageret på dets SHA-256-fingeraftryk, eventuelt under et bestemt navn, og melder manglende kædecertifikater og en ældre post med samme navn. Kunne et lager eller en post ikke læses helt, melder kontrollen, at den ikke kunne afgøre det, i stedet for at certifikatet mangler. Nævner reglen VPN-tjenesten, sammenligner kontrollen i stedet certifikatet i tjenestens committede konfiguration, det samme som installationen skriver.

Tekniske detaljer

Forbindelse
Pakken kører på appliancen, som forbinder over HTTPS til CloudGen Firewall REST API, port 8443. Der installeres ingen agent.
Tjenestens porte
8443
I skal bruge
REST API skal være slået til (HTTPS, port 8443). Brug en administrator med REST-adgang, med brugernavn og adgangskode eller en REST API-token. Til at finde og kontrollere certifikater er læseret nok, fx en kopieret observer-rolle med REST-adgang; installation kræver Manager-rollen for VPN-tjenestens konfiguration. Reglen nævner VPN-tjenesten, som Firewall Admin viser den, og på et Control Center også range, cluster og box.
Platform
CloudGen Firewall og CloudGen Control Center 9.0 og nyere med REST API; certifikatlageret fra 10.0
Handlinger
Discovery, Installation, Kontrol; ingen rollback-handling
Pakker
barracuda-cloudgen-api 1.0.0
Bemærk
  • Barracuda dokumenterer ingen REST-læsning af det certifikat, en kørende VPN-tjeneste bruger, og IPsec/TINA kan ikke kontrolleres med et TLS-handshake. Pakken bekræfter derfor konfigurationen (committet og læst tilbage, når indstillingerne kan læses; på et Control Center sendt til boxen) og, på en enkeltstående firewall, tjenestens tilstand, og melder installationen som gennemført med en advarsel.
  • VPN-tjenestens CA-kæde sættes i Firewall Admin (VPN Settings, Certificate Chain) og har intet felt i REST API; pakken lader den stå, som den er. Har det nye certifikat en anden udsteder end det forrige, installeres det, og resultatet advarer: klienter, der validerer kæden, skal have den nye udsteders certifikater i Certificate Chain.
  • Den forrige nøgle på firewallen erstattes; pakken holder det forrige certifikat og den forrige nøgle kun under kørslen, så den kan skrive dem tilbage. En afbrudt kørsel efterlader en journal på appliancen med fingeraftryk, aldrig nøgler, og næste installation læser først, hvad firewallen har, og melder det, før den skriver.
  • Version 1.0.0 installerer kun VPN-tjenestens standard-servercertifikat. Certifikater til SSL VPN, REST API’ets egen HTTPS-port, administrationen (Firewall Admin) og navngivne VPN-servicecertifikater er ikke med i denne version og vælges fortsat i Firewall Admin.
  • Hvilken tjeneste der bruger et certifikat i lageret, kan ikke læses gennem REST API. Kontrollen melder, om REST API-porten selv viser certifikatet; VPN, SSL VPN og andre tjenester lytter på porte, pakken ikke forbinder til.
  • Discovery og kontrol sender kun læseforespørgsler; installation skriver kun den navngivne VPN-tjenestes indstillinger. REST API-certifikatet kontrolleres som standard; et selvsigneret certifikat på en IP-adresse kan godkendes med sit SHA-256-fingeraftryk.
  • En HA-partner får konfigurationen gennem firewallens egen HA-synkronisering; pakken læser ikke partneren.
  • Barracuda Web Application Firewall er et andet produkt med sin egen API og har sin egen integration.

Kom i gang