Zugriff auf Rechner im LAN

[scientific]

Hi Leute!

Bei mir ist es demnächst so weit, dass mein neuer Einplatinenrechner ankommt (so der Post-Gott es will, und das Teil endlich einmal Honkong verlässt...)

Ich stelle mir jetzt so manche Fragen... Das Gerät wird daheim als öffentlich zugänglicher Mailserver primär seinen Dienst versehen.
Wenn ich es richtig verstanden habe, dann müsste ich dafür eine sogenannte Demilitarized-Zone am Router einrichten, und den Mailserver dorthin packen.
Mein Plastik-Router vom Internet-Provider bietet eine Einstellung "DMZ-Host" an, an der ich genau eine einzige IP-Adresse konfigurieren kann. Ich nehme einmal an, das wäre ein "Exposed Host" lt. https://de.wikipedia.org/wiki/Demilitar ... Z.E2.80.9C
Diese Einstellung ist lt. dem Wiki-Artikel sowieso besser zu Vermeiden und der Zugriff auf einen Host im LAN besser nur per Portweiterleitung zu realisieren.

Momentan sind die Voraussetzungen diese. Über die Investition eines ordentlichen Routers entscheide ich zu einem späteren Zeitpunkt.

Ich denke, ich werde nur die Ports 22, 25, 80, 143, 443 und 993 des neuen Mailservers nach draußen legen, damit ich Zugriff auf den Mailserver und auch Webmail (Horde) erhalte.
Port 22 benötige ich dann für den SSH-Zugriff aus der Ferne. SSH habe ich mit Client-Zertifikat und One-Time-Password abgesichert.
Für die Zugriffe auf den Mailserver gibts ausschließlich User-Authentifikation mit Passwort in einer TLS/STARTTLS gesicherten Verbindung.
Alle ungesicherten Verbindungen biete ich Serverseitig gar nicht an, und unauthentifiziert geht auch nix (speziell SMTP!)

Für einen VPN-Server fehlt mir zum aktuellen Zeitpunkt noch die Erfahrung, um so einen komfortabel nutzbar auf PC, Laptop und Smartphone zu verwenden. Das wird sicher das nächste Projekt.

Da ich sicher auch gelegentlich auf meinen Laptop daheim zugreifen werde, stelle ich mir die Frage der Reduktion der Angriffsfläche...
Ist es klüger, nur den Mailserver per ssh von außen erreichbar zu machen, um mich dann vom Mailserver zum Laptop zu verbinden, oder würde ein direkter Zugriff (ebenso ausschließlich mit Client-Cert und OTP abgesichert) auf den Laptop genauso sicher sein?

Ich habe bereits eine dynamische DNS-Lösung für meinen Internet-Anschluß daheim eingerichtet. Und ich habe eine eigene Domain, wo ich eine Subdomain eingerichtet habe, die auf den dynamischen-DNS-Eintrag verweist. Das funktioniert sogar schon für Sub-Sub-Domains...
Es klappt bereits die Autoconfig für Thunderbird und auch für Outlook-Webservices, welche ich per ActiveSync mit Horde bereitstelle. Bin selber ganz erstaunt, wie gut das klappt (böser Seitenhieb... das klappt mit Horde unter Linux für Outlook sogar besser als nativ mit einem Exchange-Server, den unser IT-Dienstleister in der Firma für uns betreibt...)

Wie würdet ihr so etwas lösen?

lg scientific

[dufty2]

Wie würdet ihr so etwas lösen?

Bestimmt kein ssh vom Internet aus erlauben
Selbst vom heimischen LAN auf die DMZ per ssh würd' ich mir überlegen.

Wenn's unbedingt sein muss, dann Emails vom Internet abholen,
aber nicht - falls sich das trennen lässt - das Kistchen vom Internet aus administrieren per web/whatever.

[Lord_Carlos]

Wie würdet ihr so etwas lösen?

Bestimmt kein ssh vom Internet aus erlauben
Selbst vom heimischen LAN auf die DMZ per ssh würd' ich mir überlegen.

Jetzt musst du aber auch sagen warum

[DeletedUserReAsG]

Dieser Aufforderung schließe ich mich an. Alle meine Server sind via ssh aus’m Internet heraus erreichbar – wäre furchtbar, wenn es einen Grund gibt, der dagegenspricht.

[scientific]

Administration per Webapp... nein, das kommt mir nicht auf meinen Rechner.
Ich bin mir ziemlich sicher, dass ein ssh ohne root-Zugang, Userzugang ausschließlich per Client-Zertifikat wesentlich sicherer ist, als ein Admin-Zugriff per Webapp...

Abgesehen davon, administriere ich meine Server lieber per Commandline und Config-File als per Web-Administrationsoberfläche... Da weiß ich dann nämlich, was ich wo reingeschrieben habe, und komfortabler ist es allemal.

Aber Gründe gegen einen SSH-Zugang würden mich jetzt ebefalls interessieren...

lg scientific

[MSfree]

Aber Gründe gegen einen SSH-Zugang würden mich jetzt ebefalls interessieren...

Mich auch

Wenn du SSH mit Keys und Onetime-Password absicherst, steht dem Zugang aus dem Internet wenig im Wege. Eventuell wäre noch Failtoban als zusätzlich Ebene gegen Bruteforce-Angriffe in Betracht zu ziehen. Aber gegen ein erreichbares SSH aus dem Internet spricht nichts.

Und das, was in den Plastikroutern als DMZ bezeichnet wird, ist alles, nur nicht demilitarized. Es handelt sich immer um exposed Hosts. Abgesehen von den falschen Begriffsverwendung ist das aber auch nicht weiter schlimm. Du kannst den Server problemlos mit iptables abdichten, so daß der Server nach aussen nur die erwünschten Verbindungen zuläßt und alles ander abweist. Ich weiß, daß man das auch durch Nicht-zur-Verfügung-Stellen von Diensten erreichen kann, einfacher und sicherer gegen einen versehentlich übersehenen Dienst geht es aber mit iptables.

Der Vorteil eines exposed Hosts ist auch, daß alle Anfragen, die an den eventuell löcherigen Router gestellt werden, direkt an den exposed Host geleitet werden und der Plastikrouter so gar nicht erst zum Angriff genutzt werden kann, der leitet ja alles weiter, bis auf (theoretisch) ICMP.

[scientific]

Aber Gründe gegen einen SSH-Zugang würden mich jetzt ebefalls interessieren...

Mich auch

Wenn du SSH mit Keys und Onetime-Password absicherst, steht dem Zugang aus dem Internet wenig im Wege. Eventuell wäre noch Failtoban als zusätzlich Ebene gegen Bruteforce-Angriffe in Betracht zu ziehen. Aber gegen ein erreichbares SSH aus dem Internet spricht nichts.

Und das, was in den Plastikroutern als DMZ bezeichnet wird, ist alles, nur nicht demilitarized. Es handelt sich immer um exposed Hosts. Abgesehen von den falschen Begriffsverwendung ist das aber auch nicht weiter schlimm. Du kannst den Server problemlos mit iptables abdichten, so daß der Server nach aussen nur die erwünschten Verbindungen zuläßt und alles ander abweist. Ich weiß, daß man das auch durch Nicht-zur-Verfügung-Stellen von Diensten erreichen kann, einfacher und sicherer gegen einen versehentlich übersehenen Dienst geht es aber mit iptables.

Der Vorteil eines exposed Hosts ist auch, daß alle Anfragen, die an den eventuell löcherigen Router gestellt werden, direkt an den exposed Host geleitet werden und der Plastikrouter so gar nicht erst zum Angriff genutzt werden kann, der leitet ja alles weiter, bis auf (theoretisch) ICMP.

Ah ja... fail2ban läuft bei mir sowieso auch.

Aber die Geschichte mit dem exposed host ist mir so nicht bewusst gewesen. Dass man mit so einem Ding einen Router quasi auch "absichern" kann...

Was ich dazu las ist ja, dass der alles an diesen Host durchreicht, außer es gibt eine Portforwarding-Regel zu einem anderen genateten Rechner.
Das bedeutet, ich stelle meinen Mailserver dann als exposed Host ein, öffne auf dem Gerät dann nur die Handvoll Ports für SSH, Mail und Webzugriff, und für alle anderen Anfragen ist der Router dann nur ein Abflussrohr ins Nirvana, ohne selber Schaden durch einen Angriff nehmen zu können? Verstehe ich das so richtig?

Gibts eigentlich erfolgreiche Angriffsszenarien, wo ein Rechner per iptables alle Ports - trotz lauschender Dienste - geschlossen hat, und ein Angreifer dennoch Zugrif darauf erlangen kann?

lg scientific

[MSfree]

Das bedeutet, ich stelle meinen Mailserver dann als exposed Host ein, öffne auf dem Gerät dann nur die Handvoll Ports für SSH, Mail und Webzugriff, und für alle anderen Anfragen ist der Router dann nur ein Abflussrohr ins Nirvana, ohne selber Schaden durch einen Angriff nehmen zu können? Verstehe ich das so richtig?

Ja, das ist richtig. Allerdings kann ich nicht garantieren, daß der Router wirklich alles forwardet. Ich traue den Herstellern dieser Plastikteile durchaus zu, einen "Wartungszugang" offen zu halten, der nicht an den exposed Host durchgereicht wird. Und, wie gesagt, ICMP (z.B. Typ 8 = ping) wird wohl grundsätzlich nicht geforwardet.

Gibts eigentlich erfolgreiche Angriffsszenarien, wo ein Rechner per iptables alle Ports - trotz lauschender Dienste - geschlossen hat, und ein Angreifer dennoch Zugrif darauf erlangen kann?

Die Schwachstelle lauert letztlich in den Diensten, die du nach aussen öffnest. Wenn dein SMPT-Server eine Schwachstelle hat, kann darüber eventuell der Server übernommen werden, weil dazu ja ein nach aussen offener Port genutzt wird.

[scientific]

Ja, die offenen Ports sind mir schon bewusst, dass die Dienste dahinter Lücken haben (können) und ein Einfallstor sind.

Aber schirmt iptables einen Port wirklich so dicht ab, dass da nix sein kann? Oder kann man eventuelle Bugs in iptables ausnutzen, um einen geschlossenen Port doch auf zu bekommen?

lg scientific

[MSfree]

Aber schirmt iptables einen Port wirklich so dicht ab, dass da nix sein kann?

Ja, solange deine Filterregeln nicht fehlerhaft sind, beißt ein Angreifer hier auf Granit.

Oder kann man eventuelle Bugs in iptables ausnutzen, um einen geschlossenen Port doch auf zu bekommen?

iptables ist letztlich nur ein Werkzeug, um die Netfilterregeln im Linuxkernel zu konfigurieren. Es wird normalerweise nur einmal beim Booten aufgerufen und setzt die Filter im Kernel, oder man ruft es (manuell) auf, um Regeln zu ergänzen, zu ändern oder zu entfernen.

Natürlich könnte der Kernelcode fehlerhaft sein und man könnte im Fehlerfall auch darüber Zugriff bekommen.
Die Liste der bekannten und längst geschlossenen Vulnerabilities ist allerdings ausserordentlich kurz:
https://www.cvedetails.com/vulnerabilit ... ables.html

Ich denke, man kann davon ausgehen, daß iptables und der Netfilter-Code im Kernel sehr sicher sind.

[dufty2]

Dieser Aufforderung schließe ich mich an. Alle meine Server sind via ssh aus’m Internet heraus erreichbar – wäre furchtbar, wenn es einen Grund gibt, der dagegenspricht.

Sagen wir so, ich kenne keinen Grund der dafür spricht

Im Enterprise-Umfeld wird das jedenfalls gar nicht in Erwägung gezogen,
der Admin-Zugriff erfolgt stets von einem Admin-Host aus (und falls das Umfeld größer - von einem Admin-Netz). Switche in DataCenter z. B. werden quasi out-of-band per 172er-Netz über ihr "eth0" administriert.
Kann sein, dass im Zuge von "Alles in die Cloud" sich das ändert.

Steht das Kistchen neben mir im Wohnzimmer, bekommt es nicht mal ein sshd, wozu auch.

Aber soll Leute geben, die unbedingt meinen, während Ihres 3-wöchigen Jamaika-Urlaubs adminstrativ tätig werden zu müssen.
Zumal das Zertifikat für ssh ja dann auch in irgendeiner Form mitgeschleppt werden muss.
Sorry, kann ich nicht verstehen ....

[MSfree]

Im Enterprise-Umfeld

Stimmt, da die Windowsserver sich nur über RDP administrieren lassen, fällt SSH natürlich von vorn herein aus.
*SCNR*

[DeletedUserReAsG]

Sagen wir so, ich kenne keinen Grund der dafür spricht

Im Enterprise-Umfeld wird das jedenfalls gar nicht in Erwägung gezogen […]

a) denke ich nicht, dass dieses Umfeld hier von Belang ist, hier ging’s nicht um Firmen, sondern um ’n Platinchen zuhause (zudem sind mir sehr wohl so einige Unternehmen bekannt, die ihre Linuxmaschinen via ssh bedienen, ob sie sich mit dem Spaceship-Buzzword umschreiben, weiß ich hingegen wieder nicht) und b) denke ich nicht, dass es eine sinnvolle Alternative zur Administration via ssh in dem hier relevanten Umfeld gibt.

Bestimmt möchtest du mir aber deine Lösung für folgendes Szenario verraten: ich bin nicht dort, wo meine Kiste ist, aber meine Kiste braucht administrative Zuwendung. Hinfahren, Tastatur und Monitor anklemmen und Aufgaben erledigen ist keine Option, das wären pro Kiste etwa 1500km Fahrt, für eine Maschine gar ’n mehrstündiger Flug über‘n Atlantik. Was also nimmst du, wenn ssh in deinen Augen inadäquat ist?

Aber auch Serverkistchen zuhause laufen in der Regel ohne Monitor/Keyboard, und wer mehr als einen Rechner samt Kabelei hat, kennt in der Regel den Aufwand, den das Anschließen dieser Sachen mit sich bringt. Secure Shell bietet sich also auch hier an – es sei denn, deine (noch zu benennende) Lösung macht’s tatsächlich überflüssig. Nun verrate auch deine Lösung, die ssh ersetzt. Oder benenne zumindest die Probleme, die ssh in deinen Augen mit sich bringt.

Ansonsten: anderen pauschal von etwas abraten, nur weil man für sich selbst keinen Vorteil drin erkennt, ist … zumindest fragwürdig.

[dufty2]

Bestimmt möchtest du mir aber deine Lösung für folgendes Szenario verraten: ich bin nicht dort, wo meine Kiste ist, aber meine Kiste braucht administrative Zuwendung.

Dein Hoster stellt Dir eine Admin-Umgebung zur Verfügung und von dieser aus wird dann auf Deine (v)Server adminsitrativ zugegriffen.

[DeletedUserReAsG]

Ich möchte meinen Hoster weitgehend aus dem System raushalten. Insbesondere möchte ich Sachen auf den Kisten machen, die im Szenario des Hosters nicht vorgesehen sind (angepasstes System, eigene Software, auf nspawn-Container verteilte Dienste, etc.). Weitere Vorschläge?

[BenutzerGa4gooPh]

Uppss, 2 Fraktionen stoßen zusammen: Die "Mietserverfraktion" und die "Firmennetzwerkfraktion". Erstere kann nur remote adminsitrieren, die andere hat die Wahl. Und scientific muss seinen Server und dessen (Remote-) Administrationsbedarf selber einordnen.

Zu Exposed Host: Wenn man sich "umliest", wird "Exposed Host" allgemein dafür verwendet, eine (semi-)professionelle Firewall-Router-Kombination (PFSense & Co.) hinter einem Plastikrouter ohne Doppel-NAT zu betreiben. U. a. mit der einfacheren Möglichkeit, aus dem Internet zu administrieren. Der Plastikrouter wird somit nur als XDSL-Modem und (DECT-)Telefonanlage benutzt. So ist die Hoffnung, nur der Plastikrouter-Hersteller weiß es genau.

Für scientific mit Server hinter Plastikrouter ist m. E. Portforwarding sicherer, da damit nur explizit geforwardete Ports extern erreichbar sind. Passieren ja vllt. Konfigurationsfehler oder der Server ist während Konfiguration/Tests temporär "etwas" offen. Ziel sollte trotzdem sein, den Server so zu konfigurieren, dass er wie ein Mietserver abgesichert im Internet stehen könnte.

Ansonsten lausche ich mit offenen Poren äh Ports dem Thread interessiert weiter.

Edit:
Eine DMZ würde (vom WAN betrachtet) nicht viel allzu viel mehr tun, als für Server mit öffentlichen IPs den WAN-Zugriff nur auf bestimmte Ports zuzulassen. Neben sicherem Management und Verhinderung von DOS. Also für privat anstelle "Entenscheiß-Enterprise" - musste kurz überlegen und dann lachen - Portforwarding. Den Bedarf von Remote-Administration kann man m. E. wirklich bedenken ... wegen Faulheit oder KISS-Prinzip.

[DeletedUserReAsG]

… ich halt’s halt für ein ganz kleines bisschen affig, jemandem, der ’n ARM-Platinchen als lokales Serverkistchen einrichten will, mit Entenscheiß-grade-Uberlösungen zu kommen und vom millionenfach bewährten Secure-Shell abzuraten …

[scientific]

Ich überlege ja auch im Hinblick auf meinen derzeitigen Noch-Arbeitgeber...

Ich hab die Situation eh schon öfter dargelegt... Auf 20-30 Standorten verteilt je ein PC/Laptop mit Drucker und dann auf 3-5 Standorten 10-50 PC/Laptops mit einigen zentralen Druckern.

Die kleinen Standorte entsprechen eigentlich klassischen Home-PC-Arbeitsplätzen mit verschiedenen Internetanbindungen. Vom UMTS-Stick bis zum Netzwerkzugang über ein gesichertes Firmennetzwerk einer Fremdfirma.

Wie bringe ich die am besten so in ein Netz, dass ich die sicher aus der Ferne warten kann, mit geringstmöglichem Aufwand.

Mein Mailserver am Platinchen daheim ist eine sehr nützliche (weil ich endlich meine Mails unter meine Fuchtel bekomme) Spielerei, um auch solche Szenarien austesten und lösen zu können.

Aber prinzipiell weiß ich immer noch nicht, warum man Server nicht mittels ssh administrieren sollte, außer "weil man das nicht macht"...

Bei mir in der Firma werden Comouter auch nicht repariert "weil man das nicht macht", und Windows wird eingesetzt "weil man das macht"...

Ich würd mich so über Linux-Rechner freuen, da 98% unserer User ausschließlich per RDP auf einen Terminalserver zugreifen. Die Windowsmaschinen sind größtenteils ungewartet, weils eh wurscht ist. Kleine konfigurationsänderungen bleiben aus, weil die Zeit für administration by turnschuh nicht reicht...

Mit Linuxmaschinen könnte ich vieles über ein zentrales Firmenrepo anpassen, und wo es nicht reicht, gehts immer noch per ssh auf die Maschine. (mit solchen Lösungen, wie für mein Platinchen hinter Plastikrouter)
Und wenns noch immer nicht reicht dann halt abt (administration by turnshuh)...

Daher will ichs auch genauer wissen...

Lg scientific

[TomL]

… ich halt’s halt für ein ganz kleines bisschen affig, jemandem, der ’n ARM-Platinchen als lokales Serverkistchen einrichten will, mit Entenscheiß-grade-Uberlösungen zu kommen und vom millionenfach bewährten Secure-Shell abzuraten …

Ich glaube auch nicht, dass SSH für diesen Zweck ein Problem ist.... allerdings würde ich dann ganz sicher nicht Port 22 am Plastikrouter forwarden, sondern um das Grundrauschen zu reduzieren irgendeinen jenseits von 50000 - das hat ansonsten keine Bedeutung, schafft aber deutlich mehr Ruhe auf der Leitung. Persönlich würde ich aber dennoch kein SSH nutzen, sondern OpenVPN und mich bei Wartungsnotwendigkeit einfach entweder via VNC oder SSH durch den Tunnel auf den Patienten aufschalten.
Mit OpenVPN kann ich gleichzeitig auch noch die normale Netzinfrastruktur als regulärer Client (cups, mounts, etc) nutzen und zudem auch noch sicher surfen. Und zwei offene Ports, also für SSH und OpenVPN halte ich für ungeschickt. Ich nutze OpenVPN in 2 Sessions (TCP und UDP) bereits seit etlichen Jahren und kann nur bestätigen, dass das beispielos stabil läuft. Für den Zweck ist OpenVPN wegen des größeren Spielraums m.E. die bessere Lösung.

j.m.2.c.

[DeletedUserReAsG]

Kann man sicher machen, wenn man ansonsten schon ’n VPN offen hat. Nur, um ssh zu tunneln, wär’s etwas sinnfrei.

[TomL]

Kann man sicher machen, wenn man ansonsten schon ’n VPN offen hat. Nur, um ssh zu tunneln, wär’s etwas sinnfrei.

Das ich den Server von unterwegs warte ist eher die Ausnahme.... mir gehts tatsächlich mehr um die Services wie Mailserver, radicale, samba, ggf. sogar cups ... und natürlich surfen über meinen Router. Aber gelegentlich nutze ich dann den Tunnel auch für den Zugriff via dann "internen" SSH. Kann sein, dass das etwas oversized ist, wenn man nur einen Wartungszugriff braucht. Allerdings empfinde ich OpenVPN aber auch als fix eingerichtet.....

[BenutzerGa4gooPh]

Auf 20-30 Standorten verteilt je ein PC/Laptop mit Drucker und dann auf 3-5 Standorten 10-50 PC/Laptops mit einigen zentralen Druckern.

Die kleinen Standorte entsprechen eigentlich klassischen Home-PC-Arbeitsplätzen mit verschiedenen Internetanbindungen. Vom UMTS-Stick bis zum Netzwerkzugang über ein gesichertes Firmennetzwerk einer Fremdfirma.

Wie bringe ich die am besten so in ein Netz, dass ich die sicher aus der Ferne warten kann, mit geringstmöglichem Aufwand.

Arten von VPNs:
https://www.elektronik-kompendium.de/si ... 512041.htm
Die grossen Standorte Site-to-Site-VPN mit professionellen Router/FWs. PFSense und OPNSense eingeschlossen. Eine Firma sollte dafuer wenigstens regelmaessig spenden oder einen Servicevertrag haben und Hardware von den Firmen beziehen, bei denen die Entwickler angestellt sind. Hilft so auch der Open-Source-Community.

[dufty2]

Aber prinzipiell weiß ich immer noch nicht, warum man Server nicht mittels ssh administrieren sollte, außer "weil man das nicht macht"...

Ich habe nicht geschrieben, ssh soll nicht verwendet werden.
Solange aber für das ssh-Protokoll und seine Implentierung nicht deren Korrektheit formal bewiesen wurde,
ist von einer Schwachstelle auszugehen.
Im Security-Palaver spricht man vom
Principle of least privilege
Solange etwas nicht unbedingt notwendig ist, wird es auch nicht eingesetzt.
=> Auf meinen Client hier benötige ich keinen sshd, also bleibt er außen vor (es gibt überhaupt keine offenen Ports auf diesen client hier).

Zum Thema VPN ist derzeit wireguard groß im Gespräch, Teile davon wurden auch formal bewiesen,
bei OpenVPN eher weniger (falls ich das noch richtig in Erinnerung habe).

[novalix]

Aus den Snowden-Papieren habe ich mir mal vor einiger Zeit die Dokumente angeschaut, die sich explizit mit ssh beschäftigen. Da waren ganz interessante Hacks drin beschrieben. Allerdings bezogen die sich alle darauf dem Ziel eine kompromittierte Variante des sshd unterzuschieben. Direkte Angriffsvektoren auf den sshd hatte die NSA keine, die nicht auf Fehlkonfigurationen und/oder schwachen Passwörtern oder ausspähbaren Keys beruhten; also mehr oder weniger das, was die Script-Kiddies auch im Werkzeugkasten haben.
Mein Fazit:
Ein solide konfigurierter sshd ist, solange man sich einigermaßen sicher sein kann, dass es die Software ist, die man installieren wollte, ein recht gut geeignetes Instrument zur Fernwartung. Millionen FliegenAdmins können nicht irren.