Zum Hauptinhalt springen

IP-Allowlist

Die IP-Allowlist beschränkt deine Organisation auf die Netze, die du angibst. Ist die Liste gesetzt, wird eine Anfrage von einer Adresse außerhalb abgewiesen, selbst wenn die Zugangsdaten gültig sind und sich der Nutzer per SSO angemeldet hat.

Sie liegt unter Sicherheit › Zugriff › IP-Allowlist (<your-org>/_admin/security/access/ip-allowlist). Nur Owner der Organisation können sie ändern.

Wo die Liste gilt

Es gibt eine Liste, und sie gilt für jeden der folgenden Bereiche:

BereichWas außerhalb der Liste abgewiesen wird
Web-Verwaltung<your-org>/_admin/*
fremforge-APIhttps://frem.sh/_app/api/v1/orgs/<your-org>/*
Weboberfläche der RepositorysDie Seiten der Organisation und ihre privaten Repositorys, Dateien, Issues, Pull Requests, Releases und Anhänge
Forgejo-REST-APIAufrufe von https://frem.sh/api/v1/ auf die privaten Repositorys der Organisation und auf die Organisation selbst
Git über HTTPSClone, Fetch und Push
Git LFSDownloads und Uploads von Objekten sowie Datei-Locks
Paket-RegistrysJede Registry, einschließlich der Container-Registry
Git über SSHNichts. Siehe Git über SSH ist nicht abgedeckt.

Öffentliche Repositorys bleiben für alle lesbar, weil ihr Inhalt ohnehin öffentlich ist. Ein Mitglied, das in einem öffentlichen Repository angemeldet ist, wird trotzdem geprüft, wenn es pusht, Einstellungen ändert oder die Seiten der Organisation öffnet. Anonyme Besucher sehen nie eine Abweisung: Ein privates Repository sieht für sie genauso aus wie immer.

Die Sicherheitsseite zeigt Wo die Liste gerade gilt mit einer Zeile pro Bereich: Durchgesetzt, Nur protokolliert (mit dem Grund) oder Nicht abgedeckt. Die API liefert dieselbe Information in surfaces. Wenn diese Seite und das Panel sich widersprechen, hat das Panel recht.

Einführung. Die eine Liste für jeden Bereich wird schrittweise eingeschaltet. Bis deine Organisation umgestellt ist, kann das Panel einen Bereich als Nur protokolliert – wird noch ausgerollt anzeigen. Anfragen von außerhalb der Liste werden dann im Audit-Log erfasst, aber nicht abgewiesen. Die Web-Verwaltung und Git über HTTPS werden durchgehend durchgesetzt (bei einer älteren Liste mit dem Scope web nur die Web-Verwaltung; siehe unten).

Die Liste festlegen

  • Verwende die CIDR-Notation: 203.0.113.0/24, 2001:db8::/48. Eine einzelne Adresse ist /32, bei IPv6 /128.
  • Gib einen Bereich pro Zeile an oder trenne sie durch Kommas. Die Obergrenze liegt bei 100 Bereichen.
  • /0 wird abgelehnt. Um jede Adresse zu erlauben, lass die Liste leer.
  • Nimm deine Büro- und VPN-Bereiche auf sowie die ausgehenden Adressen jeder CI, die nicht auf fremforge läuft.
  • Die Seite zeigt Deine Adresse gerade, also die Adresse, die fremforge von dir sieht.

Du kannst dich beim Speichern nicht aussperren. Enthält eine durchsetzende Liste deine eigene Adresse nicht, wird das Speichern abgelehnt: Füge entweder deine Adresse hinzu oder setze zuerst das Häkchen bei Nur-Audit-Vorschau.

Eine Änderung wird auf jedem Bereich innerhalb von etwa einer Minute wirksam.

Nur-Audit-Vorschau

Mit eingeschalteter Nur-Audit-Vorschau erfasst jeder Bereich die Anfragen, die er abweisen würde, lässt sie aber durch. So führst du eine Liste gut ein:

  1. Trage die Bereiche ein und setze das Häkchen bei Nur-Audit-Vorschau. Speichern.
  2. Nutze die Organisation ein oder zwei Tage wie gewohnt, einschließlich CI und aller Integrationen.
  3. Sieh dir die Ereignisse ip_allowlist.would_block im Audit-Log an. Jedes nennt den Bereich, die Adresse, einen Beispielpfad und wie viele Anfragen es zusammenfasst.
  4. Füge legitime Bereiche hinzu, die du übersehen hast.
  5. Entferne das Häkchen bei Nur-Audit-Vorschau. Ab jetzt wird die Liste durchgesetzt.

Von fremforge gehostete Runner

CI-Jobs auf fremforges eigenen Runnern erreichen deine Organisation aus dem Netz von fremforge, nicht aus deinem. Der für einen Job ausgestellte Token funktioniert immer. Von fremforge gehostete Runner erlauben (standardmäßig an) entscheidet, ob andere Zugangsdaten, die von einem Runner aus verwendet werden, etwa ein PAT oder ein OAuth-Token, der als Secret hinterlegt ist, ebenfalls funktionieren. Schalte es aus, wenn ein gestohlener PAT auch dann nutzlos sein soll, wenn er aus einem CI-Job heraus verwendet wird.

Selbst gehostete Runner und externe CI werden wie jeder andere Client nach ihrer ausgehenden Adresse beurteilt. Nimm diese Adressen in die Liste auf.

Wenn ein Owner ausgesperrt ist

Deine Adresse kann sich ändern: ein neues Büro, ein VPN-Ausfall, eine Reise. Break-Glass schaltet jeden Bereich für 24 Stunden auf reines Protokollieren. Nichts wird dauerhaft umgangen, und jeder Schritt wird im Audit-Log erfasst.

  • Selbstbedienung für Owner. Öffne https://frem.sh/_app/ip-allowlist/break-glass?org=<your-org> aus einem beliebigen Netz, angemeldet als Owner. Wir schicken einen signierten Link an die eigene E-Mail-Adresse deines Kontos. Der Link ist 30 Minuten gültig. Öffne ihn und bestätige. Abweisungsseiten und Git-Fehlermeldungen für deine Organisation geben diese Adresse aus.
  • Der Support von fremverk kann dasselbe Break-Glass für deine Organisation auf Anfrage einschalten.

Break-Glass endet nach 24 Stunden von selbst und wird nie verlängert, solange es aktiv ist. Korrigiere die Liste und beende es dann früher mit Break-Glass jetzt beenden auf der Sicherheitsseite.

Aktionen im Audit-Log: ip_allowlist.break_glass.activated, ip_allowlist.break_glass.ended.

Listen, die erstellt wurden, bevor eine Liste jeden Bereich abdeckte

Ältere Listen hatten einen Scope: web (nur Web-Verwaltung) oder web+git (zusätzlich Git über HTTPS). Diese Listen setzen weiterhin dort durch, wo sie es bisher taten. Auf den übrigen Bereichen protokollieren sie Abweisungen, die erfolgt wären, für 30 Tage, nachdem wir die Owner der Organisation benachrichtigt haben, und setzen danach auch dort durch. Die Sicherheitsseite zeigt das Datum.

Um die Wartezeit zu überspringen, verwende Jetzt auf allen Bereichen durchsetzen (Aktion im Audit-Log security.ip_allowlist.enforce_all). Du kannst eine Liste nicht auf einen alten Scope zurückstellen, und jede neue Liste deckt jeden Bereich ab.

Git über SSH ist nicht abgedeckt

Die IP-Allowlist filtert Git über SSH nicht. SSH erreicht fremforge über einen Load Balancer, der die Adresse des Clients durch die eines unserer eigenen Cluster-Knoten ersetzt, sodass wir die Adresse, von der aus sich deine Entwickler verbinden, nicht sehen. Wir beurteilen eine Verbindung nicht nach einer Adresse, von der wir wissen, dass sie falsch ist. Eine Liste, die stillschweigend jeden SSH-Nutzer blockiert oder stillschweigend alle durchlässt und dabei behauptet zu filtern, wäre schlimmer, als es offen zu sagen.

Wenn deine Organisation jede Git-Operation nach IP filtern muss:

  1. Schalte SSH-Protokoll erlauben auf der Seite Authentifizierungsrichtlinie aus. Das ist der Standard für Organisationen, die nach dem 22.05.2026 erstellt wurden.
  2. Lass Mitglieder HTTPS mit Git Credential Manager verwenden (Sichere Anmeldung). Git über HTTPS wird von der Liste abgedeckt.

Ist SSH ausgeschaltet, wird jede Git-Operation über SSH auf die Repositorys der Organisation abgewiesen: Push, Clone und Fetch sowie Git LFS über SSH. Das ist eine Abweisung von SSH als Ganzes, keine IP-Prüfung. Deshalb führt die Sicherheitsseite Git über SSH weiterhin als von der Liste Nicht abgedeckt, und die API gibt ssh_covered: false zurück.

Was eine abgewiesene Anfrage sieht

BereichAntwort
fremforge-API403 not-in-allowlist mit der Adresse, die wir gesehen haben
Weboberfläche, Web-VerwaltungEine Abweisungsseite mit der Organisation und der Adresse sowie dem Break-Glass-Link
Forgejo-REST-API, LFS, Pakete403 mit derselben Meldung
Git über HTTPSgit gibt die Meldung und den Break-Glass-Link aus

Jede Abweisung wird als ip_allowlist.blocked erfasst, jede nur protokollierte Anfrage als ip_allowlist.would_block. Wiederholungen von derselben Adresse auf demselben Bereich werden zu einem Ereignis mit einem count zusammengefasst, sodass eine falsch konfigurierte CI-Schleife das Log nicht flutet.

API

Die Liste ist auch über die fremforge-API verfügbar, mit den Scopes policy:read und policy:write.

# Read: the list, the runner toggle, per-surface modes, break-glass state
curl -H "Authorization: Bearer $TOKEN" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/security

# Replace the list
curl -X PUT -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"cidrs":["203.0.113.0/24","2001:db8::/48"],"audit_only":true,"allow_platform_runners":true}' \
  https://frem.sh/_app/api/v1/orgs/<your-org>/security/ip-policy

Das Objekt ip_allowlist enthält cidrs, scope, audit_only, allow_platform_runners, surfaces (pro Bereich: mode ist enforce oder audit, dazu ein reason), new_surfaces_enforce_at, break_glass_until und ssh_covered.

Über die API gilt der Schutz vor dem Aussperren für die eigene Adresse des Aufrufers. Fehler: invalid-cidr für einen fehlerhaften Bereich, invalid-allowlist für mehr als 100 Bereiche, einen Bereich /0 oder eine Liste, die den Aufrufer blockieren würde, und invalid-scope für einen alten Scope.

Grenzen

  • Kann der Git-Dienst von fremforge die Richtlinien der Organisationen länger als 24 Stunden nicht lesen, hört er auf, die Liste durchzusetzen, statt jede Organisation abzuweisen. Die fremforge-API und die Web-Verwaltung sind davon nicht betroffen. Ein solcher Ausfall ist ein Plattformvorfall, um den wir uns kümmern; im Normalbetrieb ist er nicht zu erwarten.
  • Adressen werden so beurteilt, wie der Edge von fremforge sie sieht. Ein Proxy oder NAT vor deinen Nutzern bestimmt, welche Adresse das ist; nimm also den ausgehenden Bereich des Proxys in die Liste auf.
  • Höchstens 100 Bereiche.