Login › seeseekey.net

Bei einer Nextcloud-Installation kam es beim versuchten Login für einen der Nutzer zu folgender Fehlermeldung:

Zu viele Anfragen aus Ihrem Netzwerk. Versuchen Sie es später erneut oder wenden Sie sich an Ihren Administrator, wenn dies ein Fehler sein sollte.

Hintergrund ist die Erkennung von häufigen Logins bzw. Brute-Force-Attacken. In einem solchen Fall hilft es die entsprechende Datenbanktabelle oc_bruteforce_attempts zu inspizieren. Ist dort die entsprechende IP-Adresse des Nutzers oft verzeichnet, können diese Einträge gelöscht werden. Anschließend sollte der entsprechende Nutzer wieder in die Nextcloud-Installation einloggen können.

Vor ein paar Tagen war ich auf der Suche nach einer lokalen Suchmaschine, mit der ich einen größeren Datenbestand durchsuchen wollte. Fündig geworden bin ich bei FESS, welches sich selbst als Enterprise Search Server beschreibt. Einen solchen wollte ich im Rahmen einer Testinstallation unter Ubuntu aufsetzen. Im ersten Schritt wird dazu der entsprechende Nutzer angelegt und in diesen gewechselt:

adduser --disabled-password --gecos "" fess
su fess
cd

Anschließend wird das aktuelle Release heruntergeladen und entpackt:

wget https://github.com/codelibs/fess/releases/download/fess-13.10.2/fess-13.10.2.zip
unzip fess-13.10.2.zip 
mv fess-13.10.2 fess
rm fess-13.10.2.zip

Danach kann FESS testweise gestartet werden:

cd fess/bin/
./fess

Der Server hört anschließend auf dem Localhost auf Port 8080. Über die entsprechende URL:

http://localhost:8080

kann FESS dann aufgerufen werden. Soll FESS über Nginx als Reverse Proxy angesteuert werden, so muss unter Nginx eine entsprechende Konfiguration für die Seite angelegt werden:

nano /etc/nginx/sites-available/example

In dieser Datei wird nun die Konfiguration hinterlegt:

server {
  listen 443;
  listen [::]:443 default_server;

  ssl on;
  ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
  ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

  server_name example.org;

  location / {
      proxy_pass http://localhost:8080;
  }
}

Nach einem Neustart von Nginx mittels:

service nginx restart

ist der Service über die gewünschte URL erreichbar. FESS arbeitet in Verbindung mit Elasticsearch; für den produktiven Einsatz, sollte eine entsprechende Instanz installiert und für die Zusammenarbeit mit FESS konfiguriert werden. Wird dies nicht getan, läuft FESS mit einer Embedded-Variante von Elasticsearch. Für erste Gehversuche und Tests reicht dies aber völlig aus.

Die Oberfläche von FESS im Entwicklermodus

Soll FESS als Service laufen, muss eine entsprechende systemd-Unit angelegt werden.

nano /etc/systemd/system/fess.service

Diese Unit wird nun wie folgt definiert:

[Unit]
Description=FESS Server
After=network.target

[Service]
Type=simple
User=fess
Group=fess
WorkingDirectory=/home/fess/fess/bin
ExecStart=/home/fess/fess/bin/fess
Restart=always
Environment=USER=fess HOME=/home/fess

[Install]
WantedBy=multi-user.target

Nachdem die Unit gespeichert wurde, kann sie aktiviert und gestartet werden:

systemctl enable fess
systemctl start fess

Über die Oberfläche kann sich als Administrator angemeldet werden. Die Standardzugangsdaten lauten:

Nutzername: admin
Passwort: admin

Nach dem ersten Login müssen diese geändert werden. Für einen ersten Testlauf kann in den Einstellungen unter Crawler -> Web oder Crawler -> Dateisystem ein erstes Ziel definiert werden. Anschließend kann der Vorgang manuell über die Symbolleiste oben rechts gestartet werden. Nachdem der Vorgang abgeschlossen ist, kann über das Frontend von FESS gesucht werden.

Die administrative Oberfläche von FESS

Die offizielle Seite des Projektes ist unter fess.codelibs.org zu finden. Das Projekt ist unter der Apache License lizenziert und damit freie Software.

Unter Linux existieren eine Reihe von Nutzern. So nutzt der Nutzer des Systems einen Nutzer und auch viele andere Dienste legen Nutzer an, wie z.B. www-data. Wenn für einen Dienst ein Nutzer angelegt werden soll, so könnte der Nutzer wie folgt angelegt werden:

adduser example

Damit würde ein vollwertiger Nutzer mit einem Passwort erzeugt werden. Soll nun ein Nutzer ohne Passwort erzeugt werden, so muss der adduser-Befehl um eine Option erweitert werden:

adduser --disabled-password example

Damit wird ein Nutzer ohne Passwort angelegt. Trotzdem wäre es noch möglich sich über diesen Nutzer anzumelden. Wenn dies nicht gewünscht ist, kann der Nutzer dementsprechend angelegt werden:

adduser --disabled-login example

Dem Nutzer ist es damit nicht mehr möglich sich einzuloggen. Allerdings kann durchaus mittels su in den Kontext des Nutzers gewechselt werden, z.B. um im Kontext des Nutzers einen Dienst zu installieren.

Der Unterschied zwischen den beiden Optionen ist, dass die Option disabled-password nur das Passwort deaktiviert, aber Logins über ein SSH-Schlüsselpaar zulassen würde. Bei der Option disabled-login ist dies nicht der Fall. Hier ist kein Login mehr möglich. Rückgängig gemacht werden kann die Beschränkung des Nutzers, indem für den Nutzer ein Passwort gesetzt wird.

Im technischen Bereich wird des Öfteren von den Begriffen Authentisierung, Authentifizierung und Autorisierung geredet. Das Problem an diesen Begrifflichkeiten ist das sie gerne durcheinander gebracht werden. Doch was bedeuten die Begriffe nun konkret? Fangen wir mit dem Begriff Authentisierung an.

Der Prozess, bei dem eine Person einen Nachweis vorlegt, dass die dargestellte Identität korrekt ist, die Authentisierung. Im IT-Kontext kann dies z.B. durch einen Login mit einem Nutzernamen und einem Passwort bewerkstelligt werden. In der physischen Welt wäre für die Authentisierung z.B. ein Ausweis geeignet. Wenn die von der Person gelieferten Daten wie ein Login oder ein Ausweis geprüft werden, so stellt dies eine Authentifizierung dar.

Authentisierung und Authentifizierung am Beispiel der Kommunikation eines Nutzers mit einem Server

Nachdem die Identität bestätigt wurde, muss im letzten Schritt ermittelt werden, ob die Person die entsprechende Berechtigung besitzt. Dies ist die sogenannte Autorisierung. Erst wenn die Authentisierung, Authentifizierung und Autorisierung erfolgreich durchgeführt wurden, kann die entsprechende Aktion durchgeführt werden.

Um sich mit einem Rechner per SSH zu verbinden, kann ein Passwort oder ein kryptografisches Schlüsselpaar genutzt werden. Aus Gründen der Sicherheit sollte ein Login über SSH per Passwort im Normalfall nicht möglich sein. Stattdessen sollte sich immer über das Schlüsselpaar identifiziert werden. Dazu wird ein privater und ein öffentlicher Schlüssel generiert. Der öffentliche Schlüssel wird beim Zielserver in der Datei:

.ssh/authorized_keys

hinterlegt. Für die nötigen kryptografischen Operationen wird schließlich der private Schlüssel genutzt, welcher auf dem eigenen Rechner verbleibt. Normalerweise wird so nur ein Schlüsselpaar genutzt. Allerdings kann es durchaus vorkommen, das nicht nur ein Schlüssel, sondern mehrere unterschiedliche Schlüssel für die Verbindung zu unterschiedlichen Servern verwendet werden soll. Diese müssen dann auf dem eigenen Rechner vorgehalten werden. In diesem Fall muss der SSH-Client darüber informiert werden mit welchem Schlüssel die Anmeldung erfolgen soll. Normalerweise würde der Client wie folgt genutzt werden:

ssh root@example.com

In diesem Fall würde der Standardschlüssel aus dem ~/.ssh/-Verzeichnis genutzt werden. Soll nun ein bestimmter Schlüssel genutzt werden so muss der Parameter -i angegeben werden:

ssh -i .ssh/otherkey root@example.org

Damit kann der Schlüssel spezifiziert werden, welcher für die Verbindung genutzt werden soll. Eine andere Möglichkeit ist es für die einzelnen Server eine Konfiguration in der Datei ~/.ssh/config zu hinterlegen.

Host example.com
IdentityFile ~/.ssh/id_rsa

Host example.org
IdentityFile ~/.ssh/otherkey

So können unterschiedliche Schlüssel für unterschiedliche Server genutzt werden.