faehrmann
Anmeldungsdatum: 18. Januar 2016
Beiträge: 38
|
Guten Morgen zusammen, ich habe eine Verständnisfrage zu folgender Situation:
Ich habe einen privaten Root-Server mit der IP-Adresse 11.22.33.44, auf dem u.a. diese Programme installiert sind: Webserver Apache ("lauscht" auf den Ports 80 und 443). Verbindungen an Port 80 werden auf Port 443 umgeleitet. SSH-Server ("lauscht" auf Port 22). shellinabox
Durch "shellinabox" ist es möglich, über eine Weboberfläche eine Verbindung zum SSH-Server aufzubauen.
Das funktioniert auch prima: Wenn ich https://www.domain.tld/shell aufrufe, dann wird shellinabox aufgerufen. Nach erfolgreicher Authentifizierung (Benutzernamen und Kennwort) öffnet sich eine Shell.
Natürlich weiß ich, dass eine SSH-Verbindung via Private-/Public-Key besser/sicherer ist, aber leider ist das in meinem Fall nicht möglich, weil die IT-Abteilung in meiner Firma (Großunternehmen) sehr strikt ist. Ich habe noch nicht einmal die Befugnis, mir ein Programm (Putty o.ä.) auf meinem Notebook zu installieren. Der Zugriff via Weboberfläche ist definitiv die einzige Möglichkeit, um auf meinen privaten Server zuzugreifen!
Um mich vor "normalen" SSH-Angriffen zu schützen, habe ich eine entsprechende iptables-Regel definiert: Der Zugriff auf 11.22.33.44 Port 22 ist nur von der Quell-IP-Adresse 11.22.33.44 möglich. Nun meine Frage:
Der Verbindungsaufbau zum SSH-Server geschieht ja von der IP-Adresse des Webservers, also von 11.22.33.44.
Wie kann ich verhindern, dass ein Angreifer die URL https://www.domain.tld/shell aufruft und 'zig Kombinationen aus Benutzername und Kennwort ausprobiert? Klar: Bei SSH wird nach 3 erfolglosen Login-Versuchen die Verbindung beendet, aber der Angreifer kann es direkt nochmal probieren...
Tools wie fail2ban kann ich meiner Meinung nach nicht verwenden, weil die Quell-IP ja stets die IP-Adresse des Webservers ist, oder? Oder gibt es doch irgendeine Möglichkeit, auf die "ursprüngliche" IP-Adresse (also die IP-Adresse der Person, die die Web-Oberfläche aufgerufen hat) zuzugreifen? In diesem Fall könnte ich fail2ban ja doch nutzen... Ich hoffe, dass ich mich verständlich ausgedrückt habe. Liebe Grüße, Daniel Bearbeitet von sebix: Listensyntax eingefügt.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
faehrmann schrieb: Natürlich weiß ich, dass eine SSH-Verbindung via Private-/Public-Key besser/sicherer ist, aber leider ist das in meinem Fall nicht möglich, weil die IT-Abteilung in meiner Firma (Großunternehmen) sehr strikt ist. Ich habe noch nicht einmal die Befugnis, mir ein Programm (Putty o.ä.) auf meinem Notebook zu installieren.
Putty muss nicht installiert werden. Das Binary kannst du einfach runterladen. Es gibt viele Möglichkeiten SSH irgendwie zu tunneln.
Der Zugriff via Weboberfläche ist definitiv die einzige Möglichkeit, um auf meinen privaten Server zuzugreifen!
Zumindest deines Wissens nach. Man könnte auch nachschauen, welche Ports ungleich 80/443 der Firmen-Proxy durchlässt und anschließend die SSH-Session durch diesen Port tunneln. Siehe. Wenn wirklich nur Port 80 und 443 freigegeben ist, gibt es trotzdem noch Möglichkeiten. Beispielsweise könntest du, sofern du einen Root-Server mit anliegendem IPv6-Subnetz hast, den SSH-Server zusätzlich an einer IPv6-Adresse an Port 443 lauschen lassen. Voraussetzung ist, dass der Proxy IPv6-fähig ist, das ist aber meistens der Fall.
Wie kann ich verhindern, dass ein Angreifer die URL https://www.domain.tld/shell aufruft und 'zig Kombinationen aus Benutzername und Kennwort ausprobiert?
Ich würde zwingend eine HTTP-Basic-Auth davor hängen. Dann muss ein Angreifer diese erstmal knacken. Da du shellinabox vermutlich eh schon via Apache aufrufst, ist das kein Aufwand.
Klar: Bei SSH wird nach 3 erfolglosen Login-Versuchen die Verbindung beendet, aber der Angreifer kann es direkt nochmal probieren...
shellinabox hat nichts mit SSH zu tun.
Tools wie fail2ban kann ich meiner Meinung nach nicht verwenden, weil die Quell-IP ja stets die IP-Adresse des Webservers ist, oder?
Wenn du die Basic-Auth davor hängst, kannst du wieder fail2ban nutzen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
faehrmann schrieb: Durch "shellinabox" ist es möglich, über eine Weboberfläche eine Verbindung zum SSH-Server aufzubauen.
Wenn der Webserver gegen die libwrap gelinkt ist, dann könntest Du z. B. auch die "/etc/hosts.allow"-Datei zur Absicherung, verwenden.
ldd $(which httpd) | grep -i wrap
(oder gleichwertig).
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
lubux schrieb: Wenn der Webserver gegen die libwrap gelinkt ist, dann könntest Du z. B. auch die "/etc/hosts.allow"-Datei zur Absicherung, verwenden.
Ich kenne keinen Webserver, der gegen die libwrap gelinkt ist. Die üblichen, also Apache, nginx und lighttpd, sind es (zumindest unter Debian und Ubuntu) nicht.
|
faehrmann
(Themenstarter)
Anmeldungsdatum: 18. Januar 2016
Beiträge: 38
|
Hallo misterunknown, hallo lubux, erstmal vielen Dank für Eure Antwort. Ich werde den Rat befolgen und eine HTTP-Basic-Auth davor hängen. Fertig. Eine kleine Rückfrage: misterunknown schrieb: faehrmann schrieb:
Klar: Bei SSH wird nach 3 erfolglosen Login-Versuchen die Verbindung beendet, aber der Angreifer kann es direkt nochmal probieren...
shellinabox hat nichts mit SSH zu tun.
In der Konfigurationsdatei von shellinabox (/etc/default/shellinabox) kannst Du doch einstellen, dass SSH verwendet werden soll:
SHELLINABOX_ARGS="-s /:SSH:11.22.33.44" Gruß, Daniel
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
faehrmann schrieb: In der Konfigurationsdatei von shellinabox (/etc/default/shellinabox) kannst Du doch einstellen, dass SSH verwendet werden soll:
SHELLINABOX_ARGS="-s /:SSH:11.22.33.44"
BTW: Funktioniert das auch ohne "PasswordAuthentication" (d. h. nur mit publickey) und einem anderen lauschenden Port (... statt 22) für den sshd? Wenn ja, wie wäre dann der Eintrag für "SHELLINABOX_ARGS="?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
faehrmann schrieb: Ich werde den Rat befolgen und eine HTTP-Basic-Auth davor hängen. Fertig.
Genau.
Eine kleine Rückfrage:
misterunknown schrieb: shellinabox hat nichts mit SSH zu tun.
In der Konfigurationsdatei von shellinabox (/etc/default/shellinabox) kannst Du doch einstellen, dass SSH verwendet werden soll:
SHELLINABOX_ARGS="-s /:SSH:11.22.33.44"
Ok, wenn du das so machst, stimmt das natürlich. Ist das Standard-Verhalten? Hier steht zumindest:
shellinabox benötigt allerdings kein SSH
weshalb ich darauf schloss, dass einfach eine Shell emuliert wird. Wenn du das so einstellen kannst, und kein SSH von außen brauchst, kannst du auch einfach den SSH-Daemon nur auf dem Loopback-Interface lauschen lassen, und in der Konfiguration von shellinabox zu localhost verbinden:
SHELLINABOX_ARGS="-s /:SSH:127.0.0.1"
Dann brauchst du keine Firewall-Regeln dafür.
|
faehrmann
(Themenstarter)
Anmeldungsdatum: 18. Januar 2016
Beiträge: 38
|
misterunknown schrieb: faehrmann schrieb: misterunknown schrieb: shellinabox hat nichts mit SSH zu tun.
In der Konfigurationsdatei von shellinabox (/etc/default/shellinabox) kannst Du doch einstellen, dass SSH verwendet werden soll:
SHELLINABOX_ARGS="-s /:SSH:11.22.33.44"
Ok, wenn du das so machst, stimmt das natürlich. Ist das Standard-Verhalten? Hier steht zumindest:
shellinabox benötigt allerdings kein SSH
weshalb ich darauf schloss, dass einfach eine Shell emuliert wird.
Auszug von http://linux.die.net/man/1/shellinaboxd: ...
-s | --service=service
One or more services can be registered on different URL paths:
SERVICE := <url-path> ':' APPLICATION
There is a pre-defined application, 'LOGIN', which causes the daemon to invoke /bin/login requesting the user's name and password,
and starting his login shell. This is the default option for the root user, if no --service was defined.
Starting /bin/login requires root privileges.
There is another pre-defined application, 'SSH'. Instead of invoking /bin/login, it calls ssh.
This is the default option for unprivileged users, if no --service was defined. This operation is available to both privileged and
regular users. If the optional host parameter is omitted, shellinaboxd connects to localhost.
Alternatively, an application can be specified by providing a user description, a working directory, and a command line:
...
...
Wenn du das so einstellen kannst, und kein SSH von außen brauchst, kannst du auch einfach den SSH-Daemon nur auf dem Loopback-Interface lauschen lassen, und in der Konfiguration von shellinabox zu localhost verbinden:
SHELLINABOX_ARGS="-s /:SSH:127.0.0.1"
Dann brauchst du keine Firewall-Regeln dafür.
Ja, stimmt. Danke für den Tipp. Gruß, Daniel
|
faehrmann
(Themenstarter)
Anmeldungsdatum: 18. Januar 2016
Beiträge: 38
|
Hallo lubux, lubux schrieb: faehrmann schrieb: In der Konfigurationsdatei von shellinabox (/etc/default/shellinabox) kannst Du doch einstellen, dass SSH verwendet werden soll:
SHELLINABOX_ARGS="-s /:SSH:11.22.33.44"
BTW: Funktioniert das auch ohne "PasswordAuthentication" (d. h. nur mit publickey) und einem anderen lauschenden Port (... statt 22) für den sshd? Wenn ja, wie wäre dann der Eintrag für "SHELLINABOX_ARGS="?
Meines Wissens nach funktioniert shellinabox ausschliesslich mit Benutzername/Kennwort.
Eine Authentifizierung via PrivateKey/PublicKey ist mir nicht bekannt. Bezüglich alternativer Port: https://github.com/shellinabox/shellinabox/issues/333 https://github.com/shellinabox/shellinabox/pull/370 Liebe Grüße, Daniel
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
faehrmann schrieb: Auszug von http://linux.die.net/man/1/shellinaboxd:
Ah, ok. Dann kannst du es auch so machen, ohne dass du SSH brauchst:
SHELLINABOX_ARGS="-s /:LOGIN"
Dann kannst du im Zweifelsfall SSH deinstallieren 😛
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
faehrmann schrieb: Meines Wissens nach funktioniert shellinabox ausschliesslich mit Benutzername/Kennwort.
Ja, das ist klar, aber meine Frage bezog sich ja auf ssh, das mit dem shellinabox-Terminal genutzt werden soll/kann:
The terminal connects to a ssh session
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
lubux schrieb: Ja, das ist klar, aber meine Frage bezog sich ja auf ssh, das mit dem shellinabox-Terminal genutzt werden soll/kann.
shellinabox ist einfach nur ein webbasierter Terminalemulator, kein SSH-Client. Der Prozess, der im Hintergrund ausgeführt wird, ist entweder /bin/login oder /usr/bin/ssh auf einen Host. Wenn du innerhalb dieses Prozesses eine neue SSH-Session irgendwohin aufmachst, kannst du dich normal mit PublicKey-Verfahren authentifizieren. Beim eigentlichen Verbindungsaufbau zu shellinabox kannst du aber kein Public-Key-Verfahren nutzen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
misterunknown schrieb: Beim eigentlichen Verbindungsaufbau zu shellinabox kannst du aber kein Public-Key-Verfahren nutzen.
Du verstehst auch nicht was ich meine. Ich kann eine ssh-Session im shellinabox-Terminal (schon beim bzw. während des Verbindungsaufbau(s), mit ssh-user und ssh-Passwort initiieren/nutzen (siehe oben). Kann ich eine ssh-Session im shellinabox-Terminal, auch mit publickey-Verfahren (und nicht Standardport 22 für sshd), statt ssh-user und ssh-Passwort-authetication, initiieren/nutzen?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
lubux schrieb: Ich kann eine ssh-Session im shellinabox-Terminal (schon beim bzw. während des Verbindungsaufbau(s), mit ssh-user und ssh-Passwort initiieren/nutzen (siehe oben). Kann ich eine ssh-Session im shellinabox-Terminal, auch mit publickey-Verfahren (und nicht Standardport 22 für sshd), statt ssh-user und ssh-Passwort-authetication, initiieren/nutzen?
Ah, jetzt verstehe ich. Ja, das geht. Ich habe das gerade mal getestet:
SHELLINABOX_ARGS="--no-beep -s /:LOGIN -s /test:marco:marco:HOME:'ssh marco@host1.example.org'"
Ich habe 2 Services definiert:
Wenn der User "marco" einen validen Key für host1.example.org hat, kommt keine Passwortabfrage.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
misterunknown schrieb: Ja, das geht. Ich habe das gerade mal getestet:
SHELLINABOX_ARGS="--no-beep -s /:LOGIN -s /test:marco:marco:HOME:'ssh marco@host1.example.org'"
Ich habe 2 Services definiert:
Wenn der User "marco" einen validen Key für host1.example.org hat, kommt keine Passwortabfrage.
Hm, bei mir funktioniert das (noch) nicht: shellinabox wird mit dieser Konfiguration (, in der "/etc/default/shellinabox",) gar nicht ge(re)startet. Valider Key ist vorhanden, denn "ssh -oPort=<lauchender-Port-sshd> marco@host1.example.org" funktioniert (ohne PW-Abfrage,) von der Kommandozeile.
|