Ist Basic access authentication wirklich sicher?

CyborgBeta

Lt. Commander
Registriert
Jan. 2021
Beiträge
1.832
Hi, ich weiß nicht genau, ob ich die richtige Foren-Kategorie erwischt habe (wenn nicht, bitte verschieben)...

Geschichte: Ich bin gerade dabei, einen File-Webserver so abzusichern, dass nur ich und meine Ma darauf Zugriff haben, und frage mich jetzt, ob html basic auth wirklich sicher ist... Ich meine damit das https://de.wikipedia.org/wiki/HTTP-Authentifizierung

Zum Einsatz kommt ein apache2. Ein Impressum gibt es zum Beispiel nicht, und die Website darf deshalb nicht für jeden erreichbar sein...

Frage an euch: Würdet ihr damit auch einen Firmenserver mit sensiblen, wirtschaftlichen Daten absichern (falls ihr eine Firma habt...)? Oder wäre euch das zu riskant? Falls nein, welche einfachen Alternativen gäbe es?

FTP scheidet irgendwie aus, weil das meine Ma nicht bedienen kann, ein extra Client benötigt wird, und nicht mit dem Browser funktioniert (Chrome hat den FTP-Support zum Beispiel eingestellt...)

Danke für eure Ideen. :)
 
Ich zitiere den Wikipedia Artikel:
Der Nutzer kann nicht sicher sein, dass der Webserver wirklich der ist, der er vorgibt zu sein. Ein Spoofing-Angriff kann einen legitimen Webserver vortäuschen, um beispielsweise an weitere Nutzerdaten zu gelangen. Üblicherweise wird für die Authentifizierung des Webservers gegenüber dem Nutzer ein Sicherheitsprotokoll wie Hypertext Transfer Protocol Secure (HTTPS) benutzt, welches mit Hilfe von digitalen Zertifikaten die Identität des Webservers bestätigen kann.
Über http ist das unsicher. Mit https und authentifizierten Server ist das grundsätzlich sicher sofern der (Web)server keine Sicherheitslücken hat. Sobald eine Sicherheitslücke auftaucht kann es allerdings sein, dass der Angreifer schneller ist als man das System gepatcht hat.
CyborgBeta schrieb:
Würdet ihr damit auch einen Firmenserver mit sensiblen, wirtschaftlichen Daten absichern (falls ihr eine Firma habt...)? Oder wäre euch das zu riskant?
Als einzige Sicherheit wäre mir das zu riskant.
CyborgBeta schrieb:
Falls nein, welche einfachen Alternativen gäbe es?
Ich würde ein VPN machen.
 
basic auth ist nur mit verschlüsselung sicher. zusätzlich sollte der server ein rate-limiting haben, damit da nicht irgendwer mit bruteforce rangeht.
 
HTTP-Authentifizierung ist ein Benutzername und Passwort in Klartext (Base64 codiert). Geschützt werden diese Anmeldedaten nur durch die HTTPS Verbindung. Benutzt du ein ordentliches Passwort und TLS ist richtig implementiert dann ist das Ganze ziemlich sicher. Da würde ich mir mehr Gedanken um die Sicherheit vom Webserver machen.
 
CyborgBeta schrieb:
Würdet ihr damit auch einen Firmenserver mit sensiblen, wirtschaftlichen Daten absichern
Nein! Ein Firma sollte die finanziellen Mittel und KnowHow für eine sinnvolle Lösung besitzen, ansonsten sollte sie lieber gleich Insolvenz anmelden.
 
Hm, HTTPS schafft vertrauen gegenüber dem Webserver, also, dass man die richtige URL eingegeben hat... Es ist also eine Client-seitige Sicherheit. Ich kann aber davon ausgehen, dass immer die richtige URL eingegeben wird... IMHO erhöht HTTPS die Sicherheit des Verfahrens/Protokolls nicht...

Den Server konfiguriere ich über SSH... dafür hab ich den SSH-Port geändert, root-Login verboten und alle Ports bis auf zwei (den SSH-Port und den apache2-Port) durch Firewall blockiert (von außen kein Zugriff möglich). Zudem aktualisiert sich der Server alle 24 Stunden selbstständig.

Die "Schwachstelle" kann also nur apache2 sein, das Benutz-/Passwort-Verfahren oder Bruteforce...

Hat jemand eine Idee, wie man Bruteforce-Attacken (so nenne ich das jetzt mal), vermeiden kann, also dass ein Angreifer/eine IP maximal drei Versuche hat, um das richtige Passwort einzugeben, danach wird gedroppt/rejected? Das stelle ich mir nicht gerade leicht vor...
 
CyborgBeta schrieb:
Hat jemand eine Idee, wie man Bruteforce-Attacken (so nenne ich das jetzt mal), vermeiden kann, also dass ein Angreifer/eine IP maximal drei Versuche hat, um das richtige Passwort einzugeben, danach wird gedroppt/rejected? Das stelle ich mir nicht gerade leicht vor...
Stichwort hier wäre Fail2Ban. [https://github.com/fail2ban/fail2ban]
 
  • Gefällt mir
Reaktionen: IICARUS und CyborgBeta
mae1cum77 schrieb:
Danke, das habe ich auch gerade gesehen... :

sudo apt install fail2ban

In der jail.local:

Code:
#
# HTTP servers
#

[apache-auth]

enabled  = true
port     = 123meinPort...
logpath  = %(apache_error_log)s

Es hat auch geklappt, ich habe mich gerade selber ausgesperrt:

Code:
:~$ sudo fail2ban-client status apache-auth
Status for the jail: apache-auth
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     5
|  `- File list:        /var/log/apache2/error.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   meineIp...

Nun bin ich zufrieden. :)
 
  • Gefällt mir
Reaktionen: mae1cum77
CyborgBeta schrieb:
Nun bin ich zufrieden. :)
Klingt gut. Kannst dich via Kommando auch entbannen.

Nutze es auch für meinen 'Server', gerade SSH, wenn offen nach außen, wird gerne bombardiert. Solltest du, wenn genutzt, auch konfigurieren.
 
  • Gefällt mir
Reaktionen: CyborgBeta
mae1cum77 schrieb:

Danke, das hat auch geklappt:

Code:
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
enabled  = true
mode     = aggressive
maxretry = 3
port     = meinSshPort...
logpath  = %(sshd_log)s
backend  = systemd

1665568440487.png


maxretry hab ich auf 3 gesetzt, weil sonst iwie vorher schon abgebrochen wird...
 
  • Gefällt mir
Reaktionen: mae1cum77
CyborgBeta schrieb:
HTTPS schafft vertrauen gegenüber dem Webserver, also, dass man die richtige URL eingegeben hat... Es ist also eine Client-seitige Sicherheit. Ich kann aber davon ausgehen, dass immer die richtige URL eingegeben wird... IMHO erhöht HTTPS die Sicherheit des Verfahrens/Protokolls nicht...
Was wie nein, das ist falsch. Ohne "HTTPS" können jedesmal hunderte Personen dein Passwort problemlos abgreifen wenn du es abschickst. Das ist so wie wenn du das Passwort per Postkarte verschickst "Der Postbote wird da schon nicht drauf schauen"

Schockierend, wie du bei solchen wichtigen Dingen hier nur so mit halbem Augen drüber liest.
 
  • Gefällt mir
Reaktionen: CyborgBeta und eigs
Vielleicht dämliche Frage, aber kann fail2ban die eigentliche Sicherheit des sshd kompromittieren?

Wegen HTTPS: Ich bin ja nicht im öffentlichen Hotspot... Ich muss ohnehin darauf vertrauen, dass keiner die Päckchen während des Transports ganz öffnet... und, soweit mir bekannt ist, gilt HTTPS auch nicht für die Dateiübertragung... oder?
 
HTTPS wird zur Herstellung von Vertraulichkeit und Integrität in der Kommunikation zwischen Webserver und Webbrowser (Client) im World Wide Web verwendet. Dies wird unter anderem durch Verschlüsselung und Authentifizierung erreicht.
[https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure]

CyborgBeta schrieb:
Vielleicht dämliche Frage, aber kann fail2ban die eigentliche Sicherheit des sshd kompromittieren?
Welche Sicherheit? Da gibt es nur das Passwort. Fail2Ban überwacht Logs und sperrt, je nach definierten Regeln, den Zugang. Ist also eine zusätzliche Ebene.
 
  • Gefällt mir
Reaktionen: eigs und CyborgBeta
Hier stehts auch nochmal: https://security.stackexchange.com/...https-web-page-will-the-download-also-use-ssl

Also, wenn ich apache2 mit https konfigurieren würde, und das directory listing auch in https ist... dann sollte ssl auch für Dateidownloads gelten...

Aber für https brauche ich ein Zertifikat, das an einer Zertifizierungsstelle hinterlegt ist, weil sonst jeder Webbrowser schimpft - und das ist... sehr umständlich 😩
 
CyborgBeta schrieb:
Aber für https brauche ich ein Zertifikat, das an einer Zertifizierungsstelle hinterlegt ist, weil sonst jeder Webbrowser schimpft - und das ist... sehr umständlich 😩
Dafür empfiehlt sich ein (vorgeschalteter) Proxy ala Nginx oder Traefik v2 mit Cloudflare-DNS-Challenge. Einmal eingerichtet, holt sich das Ganze dann regelmäßig frische Zertifikate.
 
Ich hab es jetzt doch mit SSL abgesichert, dank dieser Anleitung war das ein Kinderspiel:
https://www.digitalocean.com/commun...-apache-with-let-s-encrypt-on-ubuntu-20-04-de

Mein einziger virtual-host sieht jetzt ungefähr so aus:

Code:
<IfModule mod_ssl.c>
<VirtualHost *:1234>
        ServerName my.domain

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/geheim

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory "/var/www/geheim">
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
    </Directory>


SSLCertificateFile /etc/letsencrypt/live/my.domain/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my.domain/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Die anderen virtual-hosts hab ich gelöscht, so dass apache2 wirklich nur auf dem Port lauscht. Überprüft habe ich das mit sudo netstat -tulpen.

Hoffe, hab nix Wesentliches übersehen... Aber es funktioniert augenscheinlich alles so, wie es soll. :)
 
  • Gefällt mir
Reaktionen: BeBur
eigs schrieb:
Da steht, dass SSL bei Downloads möglich ist.
Das widerspricht meiner Aussage ja nicht... Ich habs auch nochmal überprüft, auch die Downloads sind SSL verschlüsselt.

Es gibt keinen Grund, unfreundlich zu werden. Du kennst mich nicht, ich kenne dich nicht, und so gesehen kannst du eine solche Aussage nicht treffen. Also das Bashing einfach sein lassen.

Was mich aber schon noch interessieren würde, wäre die Frage, warum nicht SSL-verschlüsselter Datenverkehr grundsätzlich unsicher sein sollte... Wer liest denn mit? Die NSA? Oder anders: Wer hat die Befugnis dazu, TCP packets während der Übertragung zu öffnen (um es mal laienhaft zu formulieren)? Ich meine, ich bin kein Terrorist, wähle nicht die afd und keine politisch interessante Person, sondern nur ein an IT interessierter Mensch...
 
CyborgBeta schrieb:
Das widerspricht meiner Aussage ja nicht...
Ich dachte du beziehst dich auf deinen Post 12, aber anscheinend hast du dich auf den Post von @mae1cum77 bezogen?
CyborgBeta schrieb:
Es gibt keinen Grund, unfreundlich zu werden.
Sehe ich auch so. Deswegen bin ich auch freundlich geblieben.
CyborgBeta schrieb:
warum nicht SSL-verschlüsselter Datenverkehr grundsätzlich unsicher sein sollte
Ohne SSL (bzw. dem Nachfolger TLS) ist wahrscheinlich gemeint gar keine Verschlüsselung zu verwenden. Dadurch werden die Anmdeldedaten inkl. Passwörter und die Dateien unverschlüsselt übertragen. Grundsätzlich kann jeder über den die Daten geleitet werden oder über Funk erreichen unverschlüsselte oder nicht ausreichend verschlüsselte Daten mitspeichern und auswerten. Natürlich gibt es auch andere Verschlüsselungsstandards die man einsetzen könnte wenn sie von der jeweiligen Anwendung unterstützt wird.
CyborgBeta schrieb:
Wer liest denn mit? Die NSA?
Das weis man nicht. Das können staatliche Organe, Betrüger und Hacker sein.
CyborgBeta schrieb:
Wer hat die Befugnis dazu, TCP packets während der Übertragung zu öffnen
Du musst dich vor denen schützen die die technischen Möglichkeiten und Kompetenz haben.
 
CyborgBeta schrieb:
Es gibt keinen Grund, unfreundlich zu werden. Du kennst mich nicht, ich kenne dich nicht, und so gesehen kannst du eine solche Aussage nicht treffen. Also das Bashing einfach sein lassen.
Keinen Server zu betreiben ist doch eher ein gut gemeinter Rat.
Angefangen hattest du mit:
CyborgBeta schrieb:
Frage an euch: Würdet ihr damit auch einen Firmenserver mit sensiblen, wirtschaftlichen Daten absichern (falls ihr eine Firma habt...)? Oder wäre euch das zu riskant? Falls nein, welche einfachen Alternativen gäbe es?
Jetzt bist du schon runter auf:
CyborgBeta schrieb:
warum nicht SSL-verschlüsselter Datenverkehr grundsätzlich unsicher sein sollte...

Konkret zu der Frage "wer liest denn mit", es haben bei jedem Hop deiner Pakete X Menschen lesenden und schreibenden Zugriff auf deine Daten.

Generell kannst du ja weiter fragen: Wieso root-Zugriff verbieten, fail2ban reicht doch? Wieso Server updaten, wie oft gibt es kritische Sicherheitslücken? Wieso Ports schließen, es laufen doch fast gar keine Dienste außer SSH? Wieso SSH Port ändern, sicheres Passwort und fail2ban reicht doch?

Wieso nicht einfach Cloud-Speicher, das ist doch sogar noch simpler als Webbrowser.
 
Zurück
Oben