Datei Firewall¶
Der Zweck der ownCloud Firewall ist es, die Ausführung von internem Code für Anforderungen in ownCloud zu verhindern, die einer Reihe von admin-definierten Regeln verstoßen. Das ermöglicht es Administratoren, das Benutzerverhalten nach vielen Kriterien auszuschließen, einschließlich der geographischen Lage, Größe der Anfrage, der abgerufenen App usw.
Konfiguration¶
Die Konfiguration der ownCloud Enterprise Firewall wird von einer JSON-formatierten Zeichenfolge in der ownCloud Konfigurationsdatei ausgeliefert. Dieser String kann in die Datei config.php mit dem Admin-Interface innerhalb von ownCloud geschrieben werden.
Die Konfiguration besteht aus einem einzelnen JSON String, der ein Array von Objekten enthält. Jedes Objekt in dem Array ist eine Bedingung, die für die Firewall erfüllt sein muß, so dass die Aufforderung in Anspruch genommen werden kann.
Wenn zum Beispiel - ownCloud einen neue Anforderung erhält werden die Bedingungen im Regelwerk gegen die Kriterien der IP-Adresse des Nutzers, des User-Agent, der Anmeldedaten usw. bewertet - und von der Anfrage generiert. Nur wenn alle Bedingungen erfüllt wird ownCloud die Anforderung ausführen dürfen. Andernfalls wird der Benutzer einen Empfangs HTTP 403 Statusfehler erhalten, was bedeutet, "Anforderung verboten".
Die Regelsätze können mit mehreren Bedingungen, einschließlich Boolesche Operatoren konstruiert werden. Damit kann eine Anforderung, durch die Firewall, zum Beispiel, wenn es eine der beiden spezifischen Bedingungen erfüllt sind, bearbeitet werden.
Reihenfolge der Vorgänge¶
Die Reihenfolge der Operationen bei der Auswertung eines Regelsatzes ist wichtig für die Effizienz. Eine richtige Erstellung der Bedingungen kann die Leistung der Firewall verbessern.
Wenn ownCloud wertet die Bedingungen sequentiell aus und addiert sie zu einem Stapel, bis ein Operator erreicht wird, wie etwa ein OR oder AND . Bei Erreichen eines Operators, arbeitet die Firewall die erforderliche Anzahl von Bedingungen von dem Stapel zur Auswertung des Operator ab. Das Ergebnis der Auswertung wird in den Stapel zurückgeschoben.
Alle Bedingungen, die im Stapel bleiben, werden zu allen Bedingungen und Vorgängen zum Regelsatz hinzugefügt werden, und werden dann ausgewertet. Alle diese Bedingungen werden so an die Firewall übergeben (als ob der AND Operator zwischen jeder von ihnen stehen würde) und werden von dieser entsprechend verwendet, um die Anforderung ablaufen zu lassen.
Zusätzlich zu AND und OR Operationen, verwendet die Firewall auch NOT sowohl als einen Operator als auch als einen Parameter, um das Ergebnis jeder Bedingung zu invertieren.
Zustandsparameter¶
Innerhalb jeder Bedingungsdefinition in einem Regelsatz, ist es möglich, Parameter, die den Zustand begrenzen zu definieren. Beispielsweise hat die Bedingung "Subnetz" einen Parameter, der einen Admin den Bereich des Teilnetz in Bits zuweist. Andere Bedingungen haben ähnliche Parameter und Bedingungen können keine oder mehrere Parameter haben.
API Hinweis: In der aktuellen Revision der Firewall werden die Parameter und die Beschreibung einer Bedingung innerhalb der definierten Regel Klasse verwendet, die diese Bedingung implementiert. In künftigen Versionen der Firewall werden die Typen der Parameterwerte, die innerhalb der definierten Regel Klassen verwendet werden, auch über die Administrationsoberfläche eingeben werden.
Regeldefinitionen¶
Jede definierte Regel muss einen Typ umfassen. Es gibt zwei Arten von Regeln, die für Firewalls anwendbar sind: Bedingungen und Operatoren. Die Bedingungen vergleichen auf Anfrage die Kriterien mit bestimmten voreingestellten Werte. Deren Ergebnisse bestimmen, ob die Firewall den Pass-Through von einer Anfrage durchläßt. Operatoren kombinieren die Ergebnisse der Bedingungen und ermöglichen eine Regel zu erzeugen, die verschiedene Arten von Anfragen unter anderen Umständen beinhalten kann.
Bedingungen¶
Der Typ einer Bedingung "Bedingung". Bedingungen müssen einen "check" Wert enthalten, der den Typ beschreibt der geprüft werden soll, dass wird durchgeführt, wenn die Bedingung bewertet wird. Der "check" Wert muss in einem als in Kleinbuchstaben eingebenen Regelsatz vorgesehen werden.
Jede Bedingung kann ein "negieren" Wert haben. Wenn der "negieren" Wert true ist, dann wird das Ergebnis der Bedingung negiert werden. Zum Beispiel, um ein Teilnetz von IP-Adressen zu blockieren, benutzen Sie die CIDR-Regel, dass das Subnetz verwendet und negiert die Regel, so dass Anfragen aus diesem Subnetz scheitern. Es ist auch möglich, jede Bedingung mit einem NOT Operator zu versehen, der die gleiche Funktion erfüllt.
Jeder Zustand kann auch eine "failmessage" oder Parameter "passmessage" enthalten. Der Wert dieses Parameters wird im Log von ownCloud gespeichert für den Fall, dass die Bedingung ausgeführt wird und ausfällt oder durchläuft. Beachten Sie, dass das Hinzufügen dieses Parameters an eine Bedingung signifikante Auswirkungen auf die Leistung als solches habern kann, dieser Parameter sollte nur verwendet werden, um die Firewall-Regelsätze zu debuggen.
Hier finden Sie eine Liste der Überprüfungen, die von der Firewall, zusammen mit den Parametern, die sie benötigen, unterstützt werden.
CIDR¶
Der CIDR Zustand erlaubt nur die Anforderungen, die sich aus einer IP-Adresse ergeben, die mit einer CIDR-Maske übereinstimmten und von dort stammen.
Parameters :
cidr
Die CIDR Adressmaske, wird in einem Format ähnlich dem 192.168.1.0/24 verwendet.
Beispiel:
Diese Bedingung wird den Parameter "negieren" um sicherzustellen, dass der Antrag nicht von einem bestimmten Subnetz kommt:
{
"type": "condition",
"check": "cidr",
"cidr": "117.22.0.0/15",
"negate": true
}
Regex¶
Der Regex Zustand erlaubt nur die Anforderungen, die erfolgreich einem regulären Ausdruck auf eine bestimmte Anfrage von Kriterien entsprechen.
Parameter:
regex
Den regulären Ausdruck im Vergleich zu verwenden. Dieser reguläre Ausdruck muss begrenzt werden. Beispielsweise: #p#
criteria
Der Name der Kriterien, die auf dem regulären Ausdruck entsprechen.
Beispiel:
Dieser Zustand überprüft, um sicherzustellen, dass die Anfrage die die Kriterien enthält den Buchstaben "P" verwendet:
{
"type": "condition",
"check": "regex",
"regex": "#p#",
"criteria": "request"
}
subnet¶
Der Subnet Zustand ermöglicht eine Anforderung nur auszuführen, wenn die Anfrage aus einer bestimmten Anzahl von Bits der IP-Adresse des Servers stammt. Zum Beispiel, um zu ermöglichen das Anforderungen vom Subnetz 192.168.1.0 bis 192.168.1.255 verwendet werden sollte der Parameter "bits" 24 gesetzt werden, das die ersten drei Bytes der IP-Adresse umfasst.
Parameters:
bits
Die Anzahl der Bits, die erforderlich sind, um die IP-Adresse des Servers in Übereinstimmung mit eine Anfrage zu bringen.
Beispiel:
Dieser Zustand überprüft, um sicherzustellen, dass der Antrag aus auf dem gleichen Subnetz wie der Server stammt:
{
"type": "condition",
"check": "subnet",
"bits": 24
}
upload¶
Der Upload Zustand ermöglicht eine Antrage nur dann auszuführen, wenn es ein Upload versucht wird. Beachten Sie, dass diese Bedingung in zweierlei Hinsicht nützlich sein kann:
- Erfordert eine Anforderung die einen Upload erfordern, bevor eine weitere Bedingung ausgeführt wird, wie eine Größenbeschränkung.
- Erfordert eine Anforderung keinen Upload, wird (durch Hinzufügen des negierten Parametes) als Alternative in ein OR Operator verwendet.
Parameter: None.
Beispiel:
Diese Bedingung wird den Parameter "negieren", um sicherzustellen, dass der Antrag kein Upload ist:
{
"type": "condition",
"check": "upload",
"negate": true
}
Verb¶
Ein Verb Zustand ermöglicht eine Anforderung nur, wenn die Anforderung eines bestimmte HTTP-Verb verwendet wird.
Parameter:
verb
Eine durch Kommata getrennte Liste der Verben, die dieser Bedingung übergeben wird. Beachten Sie, dass HTTP-Verben Groß- und Kleinschreibung unterscheiden und sind in der Regel erforderlich, um in Großbuchstaben eingegeben werden.
Beispiel:
Diese Bedingung prüft, um sicherzustellen, dass die Anforderungsmethode entweder ein GET oder PUT ist:
{
"type": "condition",
"check": "verb",
"verb": "GET,POST"
}
Loggedin¶
Der LoggedIn Zustand ermöglicht eine Anforderung nur, wenn der Benutzer angemeldet ist.
keine Parameter.
Beispiel:
Diese Bedingung setzt den negierte Parameter und verlangt, dass der Benutzer nicht eingelogget ist:
{
"type": "condition",
"check": "loggedin",
"negate": true
}
Usergroup¶
Der Usergroup Zustand ermöglicht eine Anforderung nur, wenn der Benutzer ein Mitglied der angegebenen Gruppe oder Gruppen ist.
Parameter:
group
Eine durch Kommata getrennte Liste der Gruppen, von denen der Benutzer ein Mitglied sein muß - von mindestens einer.
Beispiel:
Bei diesem Zustand muss ein Benutzer in der Gruppe "admin" Mitglied sein:
{
"type": "condition",
"check": "usergroup",
"group": "admin"
}
Time¶
DerTime Zustand ermöglicht eine Anforderung nur, wenn der Antrag innerhalb eines bestimmten Zeitbereichs gemacht wird. Die Prüfung wird gegen GMT durchgeführt. Wenn das Ende der Zeit erreciht ist, bevor die Zeit beginnt, dann ersteckt sich der Bereich über Nacht.
Parameter:
begin
Der Beginn des Zeitbereichs, im Format HH: MM. PM Zeiten sind in Zahlen, die größer als 12 ausgedrückt.
end
Das Ende des Zeitbereichs, im Format HH: MM. PM Zeiten sind in Zahlen, die größer als 12 ausgedrückt.
Beispiel:
Dieser Zustand erfordert eine Anforderung die von 9.00 bis 05.00 GMT auftret:
{
"type": "condition",
"check": "time",
"begin": "9:00",
"end": "17:00"
}
Sizeup¶
Der SizeUp Zustand ermöglicht einen Antrag nur dann, wenn die Größe der Anfrage unter einer bestimmten Grenze ist. Dies begrenzt die Menge an Daten, die zum Server übertragen werden können, und können das hochladen von unerwünschten großen Daten verhindern. Diese Regel gewährleistet nicht, das von einem Client aus die Übertragung verhindern werden kann (und der Server den Empfang) der Daten vor der Regel wirksam, aber unter bestimmten Umständen (insbesondere PUT Anfragen, wie sie über WebDAV mit einem ordnungsgemäß konfigurierten Server initiiert) die Übertragung von Daten verhindern kann.
Parameter:
limit
Die maximale Anzahl von Bytes, die erlaubt sind, und die in der Anfrage übertragen werden.
Beispiel:
Diese Bedingung setzt voraus das alle Übertragungen an den Server auf weniger als etwa 100 kb sein müssen.
{
"type": "condition",
"check": "sizeup",
"limit": 100000
}
Operatoren¶
Die Typen von einem Operator sind "Operatoren". Die Operatoren müssen auch einen "Operator" Wert enthalten, der die Art der Operation, die von den Bedingungen die noch im Stapel aufgeführt sind beschrieben werden. Der Wert "Operator" müß als Kleinbuchstaben im Regelsatz vorgesehen werden.
Operatoren können auch den Parameter "count" enthalten, die eine alternative Reihe von Bedingungen definiert, um aus dem Stapel zu fallen. Dies kann nützlich für die effiziente Kombination von mehreren Operationen in einem komplizierteren Regelsatz sein.
Hier finden Sie eine Liste der Operatoren, die in der Firewall unterstützt werden.
and¶
Der AND Operator benötigt zwei Bedingungen aus dem Stapel (es sei denn, es wird ein count Parameter angegeben). Jede Bedingung wird ausgewertet, bis einer ausgewertet false oder es keine weiteren Bedingungen zu bewerten gibt, (die in einer Ergebnisliste true als Antwort). Das Ergebnis des Operators wird auf den Stapel geschoben.
Der AND Operator gibt bei Fehlern, wenn eine der Bedingungen, nicht ausgewertet werden kann false . Die vorher auf den Stapel geschoben Bedingungen des AND Operators werden so optimiert, dass diese wahrscheinlich zurückkehren und false als die erste Bedingung bei dieser Anfrage ausgeführt wird. Dadurch werden die anderen ausgeführt werden, was Ausführungszeit spart.
Or¶
Der OR Operator erstellt zwei Bedingungen auf dem Stapel (es sei denn, es wird ein count Parameter angegeben). Jede Bedingung wird ausgewertet, bis eine ausgewertet true oder es keine weiteren Bedingungen zu bewerten gibt, (die in einer Ergebnisliste false als Antwort wiedergibt). Das Ergebnis des Operators wird auf den Stapel geschoben.
Der OR Operator gibt bei Fehlern, wenn eine der Bedingungen, nicht ausgewertet werden kann true . Die vorher auf den Stapel geschoben Bedingungen des OR Operator erden so optimiert, dass diese wahrscheinlich zurückkehren und true als die erste Bedingung bei dieser Anfrage ausgeführt wird. Dadurch werden die anderen ausgeführt werden, was Ausführungszeit spart.
Not¶
Der NOT Operator verwendet eine Bedingung aus dem Stapel. Die "negieren" Eigenschaft dieses Zustand wird umgeschaltet, dann wird der Zustand wieder auf dem Stapel abgelegt. Der NOT Operator verwendet nicht die Bedingung, so das sie eine modifizierte Auswertung erzwingt.
log¶
Der LOG Operator verwendet eine Bedingung auf dem Stapel und wertet sie aus. Das Ergebnis der Auswertung wird in den ownCloud Log geschrieben zusammen mit dem Parameter "message" der Bedienungsperson.
Der LOG Operator hat keinen Einfluss auf den Ausgang der Bewertung des Regelsatzes, aber es kann Bedingungen enthalten, die nicht auf andere Weise durch Betreiber von Fehlern, die die Leistung beeinträchtigen würden, auszuführen. Die Log-Einträge werden in eine Datei bei jeder Anfrage geschrieben, und können signifikant Auswirkungen auf die Leistung als solches haben, der Betreiber sollte diese nur während des Debuggens Firewall-Regelsätze verwenden.
Verfügbare Merkmale¶
Es gibt einige Bedingungen, die der Administrator bestimmten Kriterien, auf denen sie agieren festlegen können. Hier finden Sie eine Liste von Kriterien, die von der Firewall gesammelt werden, um die an die Bedingungen für die Auswertung übergeben werden.
User-agent¶
Der wörtliche User-Agent-String der durch den Clienten ausgeliefert wird
agent¶
Eine übersetzte User-Agent-String, kann enthalten:
desktop¶
Welcher Desktop-Sync-Client verwendet wird.
ios¶
Angabe des ownCloud IOS-Clienten.
android¶
Angabe des ownCloud Android-Clienten.
webdav¶
Indicating a webdav request.
Public¶
Welche gemeinsame öffentliche URL verwendet wird.
Request-url¶
Die angeforderte URI.
request¶
Das Gleiche wie Request-URI
Remote-addr¶
Die Remote-IP-Adresse des Benutzers.
IP¶
Das Gleiche wie bei der remote-addr
time¶
UTC-Zeitstempel.
Server-time¶
Server Zeitzone Zeitstempel
User-time¶
User Zeitzone Zeitstempel
user¶
Das ownCloud OC_User Objekt des angemeldeten Benutzers
groups¶
Die ownCloud Gruppen-IDs, die dem aktuellen Benutzer gehören
app¶
Der Name der Anwendung, auf sich die Anforderung bezieht
appfile¶
Die Datei der Anwendung, die angefordert wurde
method¶
Das HTTP-Verb das für die Anforderung verwendet wird
Beispiel für Regelsätze¶
Hier ist ein Beispiel-Regelsatz, der Anforderungen an Uploads stellt die nur erlaub sind, wenn sie innerhalb Subnetz liegen oder mit dem iOS-Clienten des Servers übereinstimmen:
[{
"type": "condition",
"check": "upload",
"negate": true
},
{
"type": "condition",
"check": "subnet",
"bits": 24
},
{
"type": "condition",
"check": "regex",
"regex": "#^ios$#",
"criteria": "agent"
},
{
"type": "operator",
"operator": "or",
"count": 3
}
]
Das folgende Beispiel zeigt einen Regelsatz, der es nur Benutzern in der "admin" Gruppe ermöglicht, Dateien auf ownCloud hochzuladen:
Die folgende Regelsatz wird verwendet, um hochgeladene Videos von einem bestimmten IP-Bereich (58.14.0.0/24 in diesem Fall) zu blockieren. Das kann nützlich sein um Uploads von weniger wünschenswerten Ländern zu blockieren:
