CouchDB als NoSQL Datenbank ist für meine Webanwendungen inzwischen unverzichtbar. Mein Workflow beim Entwickeln ist deutlich effizienter als früher, als ich noch auf MySQL-Datenbanken gesetzt habe. Ein Feld ergänzen, einen neuen Dokumenten-Typ hinzufügen, alles schnell erledigt. Es muss auch nicht mit Datenbank-Connectoren gearbeitet werden, CouchDB nimmt Anfragen per Rest API entgegen und gibt die Antworten auch darüber aus.
Bei MySQL bedeuteten Änderungen: in phpMyAdmin einloggen (musste erstmal installiert werden), eventuell Tabelle anlegen, Feld hinzufügen, Typ festlegen, Abfrage schreiben, auf keinen Fall Primärschlüssel vergessen und alles schön normalisieren.
Aber bei allen Vorteilen muss eine CouchDB sicher sein, wenn sie direkt aus dem Internet erreichbar ist. Setzt man wie ich auf React, muss die CouchDB aus dem Internet erreichbar sein, da die Webseiten auf dem Rechner des Users gerendert werden und damit der User die Verbindung zur Datenbank direkt herstellt. Bei PHP und React mit Server Side Rendering sieht das anders aus. Dieses Thema werde ich demnächst auch aufgreifen.
nginx als Schutz und Optimierung für CouchDB
Zur Absicherung eurer CouchDB kommt nginx ins Spiel. Nginx kann nämlich nicht nur Webserver sein, sondern auch Reverse Proxy. Das bietet eine Reihe von Vorteilen:
- Begrenzung der Anzahl gleichzeitiger Verbindungen, was einen Schutz gegen Denial-of-Service-Angriffe (DoS) bietet
- sichere SSL/TLS-Konfiguration, für eine sichere Kommunikation zwischen Client und Server. Wichtiger Punkt für Datenschutz und ihr könnt mit einem Single-Domain-SSL-Zertifikat eure Webseite und eure Datenbank absichern
- zudem erlaubt nginx die Verwendung von Zugriffsregeln und -beschränkungen, was eine zusätzliche Sicherheitsebene schafft. Ihr könnt z.B. den Zugriff auf das eingebaute Webfrontend Project Fauxton verbieten oder einschränken
- Offiziell lizenziert 2, 4-ghz-wireless-controller
- kompatibel mit SEGA saturn, SEGA Mega Drive Mini, PC/Mac, PS3 und Switch
Letzte Aktualisierung am 18.09.2024 / Affiliate Links / Bilder von der Amazon Product Advertising API
erste nginx Konfiguration
Die grundlegende Idee besteht darin, nginx so zu konfigurieren, dass alle Anfragen, die an /db gerichtet sind, an CouchDB weitergeleitet werden. Dann könnt ihr, wie schon beschrieben, später ein Single-Domain-SSL-Zertifikat nutzen und benötigt kein Wildcard- oder Multi-Domain-Zertifikat.
Hier ein grundlegendes Beispiel, wie dies in der nginx-Konfigurationsdatei aussehen könnte:
server {
listen 80;
server_name your_domain.com;
location /db/ {
proxy_pass http://localhost:5984/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}In diesem Beispiel wird nginx auf den unverschlüsselten Port 80 eingestellt und leitet alle Anfragen, die an /db gerichtet sind, an CouchDB weiter, der wiederum auf dem gleichen Rechner auf Port auf Port 5984 läuft. Ihr dürft in der Firewall also wirklich nur Port 80 freigeben, damit CouchDB nicht direkt erreichbar ist. Möglich ist es auch, dass CouchDB und nginx auf unterschiedlichen Servern laufen. Gerade wenn ihr Docker verwendet, ist es sogar üblich, dass die beiden in unterschiedlichen Dockern laufen.
Bei unterschiedlichen Servern/Dockern würdet ihr die proxy_pass Direktive also entsprechend auf den internen(!) Netzwerknamen der CouchDB setzen, Beispiel: http://couchdb:5984/
Die proxy_redirect off Direktive verhindert, dass nginx versucht, Weiterleitungen anzupassen, die von CouchDB kommen.
Die letzten drei proxy_set_header Direktiven setzen bestimmte Header für jede weitergeleitete Anfrage, was nützlich ist, um Informationen über den ursprünglichen Client beizubehalten. Sonst würdet ihr z.B. in den Logs von CouchDB nur Zugriffe von nginx sehen, so werden die echten Client-Informationen weitergegeben.
- Wireless Ladegerät: Wirklich kabelloses Solarstrom-Ladegerät mit drahtlosem Ausgang unterstützt…
- 26800mAh Kapazität: Das tragbare Ladegerät in Handy-Größe bietet 8 Aufladungen für das 2000mAh…
Letzte Aktualisierung am 18.09.2024 / Affiliate Links / Bilder von der Amazon Product Advertising API
Zugriffsregeln und -beschränkungen
Mit dieser grundlegenden Konfiguration profitieren wir noch nicht von den am Anfang beschriebenen Vorteilen. Wir müssen jetzt die Zugriffe regeln, vor allem beschränken. Fangen wir damit an, dass jeder Client nur eine bestimmte Anzahl an Zugriffen pro Minute machen darf. Das verhindert DDoS Angriffe. Hier eine neue Konfiguration.
limit_req_zone $binary_remote_addr zone=one:10m rate=60r/m;
server {
listen 80;
server_name your_domain.com;
location /db/ {
proxy_pass http://localhost:5984/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
limit_req zone=one;
}
}Die entscheidende Konfiguration findet mit rate=60r/m statt. Dies bedeutet: pro Minute (/m) darf ein Client 60 Anfragen (Requests, daher 60r) machen. rate=120r/m würde dementsprechend 120 Anfragen pro Client pro Minuten bedeuten, also eine Anfrage je 0,5 Sekunden.
Diesen Wert müsst ihr an eure Anwendung anpassen. Wir übertreiben mal: finden in eurer Webanwendung pro Seitenaufruf 10 Datenbankabfragen statt und der User aktualisiert die Anwendung 10-mal in einer Minute, wäre eine Begrenzung auf 60 sehr ungünstig, ihr würdet den User aussperren.
Dabei sind 10 Aktualisierungen je Minute nicht ungewöhnlich. Stellt euch vor ihr habt eine Webanwendung für Kleinanzeigen. Manche User werden auf den “Weiter”-Button hämmern, weil sie etwas Bestimmtes suchen. Wählt hier also weise 🙂
das Webfrontend Project Fauxton verstecken
Als nächstes empfehle ich euch, das Webfrontend in der Produktivumgebung zu blockieren. Während der Entwicklungsphase wird man es des Öfteren nutzen, geht die CouchDB Live solltet ihr den Zugriff durch Jedermann aber lieber verhindern. Es wird ein typischer Angriffspunkt für Brute-Force Attacken werden.
Hier die weiter ergänzte Konfiguration:
limit_req_zone $binary_remote_addr zone=one:10m rate=60r/m;
server {
listen 80;
server_name your_domain.com;
location /db/_utils/ {
deny all;
return 403;
}
location /db/ {
proxy_pass http://localhost:5984/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
limit_req zone=one;
}
}Hier ist der entscheidende Punkt die zusätzlich hinzugefügte location. Das _utils Verzeichns ist das Verzeichnis der Weboberfläche Project Fauxton. Durch deny all wird für alle IP-Adressen der Zugriff auf dieses Verzeichnis verhindert. Zurückgegeben wird Fehler 403 (Access Forbidden).
- 【Makeblock mBot 2】 Als MINT-Spielzeug mBot 2drei Stufen: Bauen, Kognition und Kreation. Dieser…
- 【Mehr Funktionen, mehr Spaß】 Neben den Grundfunktionen wie Linienverfolgung,…
Letzte Aktualisierung am 18.09.2024 / Affiliate Links / Bilder von der Amazon Product Advertising API
Beachtet, dass die Reihenfolge der location-Direktiven wichtig ist. Nginx wird die erste übereinstimmende location-Direktive verwenden. Daher sollte die spezifischere Regel (/db/_utils) vor der allgemeineren Regel (/db) stehen.
Natürlich gibt es noch viel mehr Möglichkeiten in der Konfiguration und perfekt ist die hier dargestellte Version noch nicht. Vor allem fehlt die Einrichtung eines SSL-Zertifikats, die Einbindung des Zertifikats und die Umstellung auf Port 443. Das werde ich in einem späteren Beitrag aufgreifen und erklären.
Zum Abschluss möchte ich euch den Blog der nginx Entwickler ans Herz legen. Hier findet ihr auch sehr tiefgreifende Themen wie High Availability oder Health Checks.