802.1X und Radius gegen Wi-Fi Sense auf Win 10-Geräten der lieben Freunde …

Diejenigen unter meine Lesern und Bekannten, die wissen möchten, warum ich neben der Ablehnung der Aushöhlung der Privatsphäre unbedarfter Anwender durch Win 10 auch noch eine besonders kritische Einstellung zum Win10-Feature” “Wi-Fi Sense” vertrete, seien auf folgenden Artikel im Schwester-Blog http://iso-blog.anracom.com hingewiesen:

http://iso-blog.anracom.com/2015/08/13/die-grosse-passwort-sammlung-wi-fi-sense-unter-win-10/

Ich finde es schon ziemlich bemerkenswert, dass die Standard-Installation eines PC-Betriebssystems zu einem Export von sicherheitsrelevanten Passwörtern für Infrastrukturkomponenten auf amerikanische Server führt. Noch interessanter ist, dass ein Password-Sharing über Outlook, Facebook und Skype-Accounts auch in unkontrollierbarer Weise über Dritte und Vierte stattfinden kann, selbst wenn man selbst gar nicht Win 10 benutzt. Siehe hierzu die vielfältigen Links im genannten Artikel. Ich finde, MS hat damit eindeutig eine Grenze des Zumutbaren überschritten.

So, wie es im Moment aussieht, ist jeder Linuxer, der Freunden mit (mobilen) Win 10 Geräten einen Zugriff auf seine WLAN-Infrastruktur gewähren will, jedenfalls gut beraten, die Authentifizierung über 802.1X und einen Radius-Server unter Linux abzuwickeln (WPA2 Enterprise). Angeblich reicht Win 10 die Passwörter in diesem Fall nicht weiter – im Gegensatz zu WLAN-Infrastrukturen mit reiner WPA2 (Personal) Authentifizierung. Dafür, das dies tatsächlich mit einer hohen Wahrscheinlichkeit der Fall ist, spricht jedenfalls die Tatsache, dass ansonsten Sicherheitsinteressen von Firmen berührt wären.

Die strikte Separation eines entsprechenden Gäste-WLAN-Segments vom Rest des Netzes scheint mir zudem angebracht – aber damit erzähle ich sicher nichts Neues.

Da ich relativ viele Bekannte mit Win-Ausstattung habe, die regelmäßig zu Besuch kommen, werde ich daheim wohl einen alten Access Point, der 802.1X unterstützt, reaktivieren müssen. Ist auch ein guter Anlass, sich mal wieder intensiver mit Radius auseinanderzusetzen. So hat etwas Negatives auch wieder eine gute Seite …. und vielleicht ergibt sich aus den gewonnenen Erkenntnissen auch wieder ein Blog-Artikel.

Windows 10 ? Linux !!! … im Namen der informationellen Selbstbestimmung

Manchmal muss man ja mal über den Tellerrand gucken. Für einen Linuxer bedeutet dies einen Blick in Richtung der Hersteller anderer Betriebssysteme – im Besonderen von PC-Betriebssystemen.

Erster Anlass im vorliegenden Fall war, dass eine Bekannte mich fragte, ob sie denn das “kostenfreie” Angebot zum Upgrade ihres PCs auf eine neue Version des Betriebssystems eines bekannten Herstellers wahrnehmen könne und solle. Ich habe ihr geantwortet, dass ich nicht glaube, dass es von kommerziell tätigen Unternehmen irgendetwas kostenfrei gäbe. I.d.R. würde man im Bereich der IT dann mit kommerziell verwertbaren Informationen zu seiner eigenen Person bezahlen. Ansonsten würde ich mich bzgl. des Herstellers nicht kompetent genug fühlen.

Dabei hatte ich gar keine bösen Hintergedanken. Man ist ja von den Großen in der IT-/Web-Branche ja eh’ bereits Einiges gewohnt – und dass wir alle gerade über die sogenannten sozialen Medien dazu beitragen, dass es in wenigen Jahren keine Privatsphäre mehr geben wird, ist unter aufgeklärten Linux-Usern ja auch kaum ein Geheimnis.

Dann kam meine Frau mit ihrem VMware Guest unter Win 7 an und zeigte mir eine Mitteilung, die besagte, dass auch sie zu den Auserwählten gehöre, die ein kostenfreies Upgrade von Win 7 Pro auf Windows 10 Home (!) nutzen könnten. Meine Antwort: kein Bedarf, Win 7 fliegt ja auch in Kürze von unseren virtuellen Systemen runter.

Aber dann meldete sich auch noch einer unserer wichtigeren Kunden … Da wurde ich dann langsam sauer und fing an, eben ein wenig über den Tellerrand ins Internet hinauszuschauen.

Und musste mir die Augen reiben, weil die Verbraucherschützer von Rheinland-Pfalz vor kurzem bereits ein paar nette Kommentare zu dem Thema Windows 10 formuliert hatten, die ich aus dieser Ecke kaum erwartet hätte.

Für jeden, der ein wenig nachlesen will, hier ein paar Links. Jeder mag sich dann selbst seine Meinung bilden:

http://www.computerbase.de/2015-08/windows-10-microsofts-datensammlung-sorgt-fuer-heftige-kritik/
http://www.welt.de/wirtschaft/webwelt/article145054076/Verbraucherzentrale-warnt-vor-Abhoeranlage-Windows-10.html
https://www.verbraucherzentrale-rlp.de/windows-10—Ueberwachung-bis-zum-letzten-klick-1
http://www.zeit.de/digital/2015-08/windows-zehn-verbraucherzentrale-abhoeranlage-datenschutz
http://www.theguardian.com/technology/2015/jul/31/windows-10-microsoft-faces-criticism-over-privacy-default-settings
http://www.computerworld.com/article/2968288/microsoft-windows/windows-10-makes-diagnostic-data-collection-compulsory.html
http://www.telegraph.co.uk/technology/microsoft/windows/11782807/windows-10-privacy.html
http://www.infoworld.com/article/2956715/microsoft-windows/privacy-and-advertising-in-windows-10-both-sides-of-the-story.html
http://www.newsweek.com/windows-10-recording-users-every-move-
358952

http://www.polygon.com/2015/7/31/9075531/windows-10-privacy-how-to
https://www.reddit.com/r/Windows10/comments/3f38ed/ guide_how_to_disable_data_logging_in_w10
http://lifehacker.com/what-windows-10s-privacy-nightmare-settings-actually-1722267229
http://arstechnica.com/information-technology/2015/08/windows-10s-privacy-policy-is-the-new-normal/
http://www.rt.com/usa/311304-new-windows-privacy-issues/
http://www.computerbase.de/2015-08/kommentar-windows-10/
http://www.sueddeutsche.de/digital/windows-vertrauter-spion-1.2594765
http://www.techrepublic.com/article/windows-10-violates-your-privacy-by-default-heres-how-you-can-protect-yourself/
http://www.zdnet.com/article/how-to-secure-windows-10-the-paranoids-guide/
http://betanews.com/2015/07/31/the-real-price-of-windows-10-is-your-privacy/
http://www.france24.com/en/20150804-windows-10-microsoft-privacy-spying-internet-data-collection-backlash
http://www.heise.de/ix/meldung/Windows-10-Gefaehrlicher-Zertifikats-Wirrwarr-2776810.html
http://www.kuketz-blog.de/kommentar-windows-10-datenschutz-geht-anders/

 
Der wichtigste Link ist vermutlich aber folgender zum “MS Privacy Statement” :

 
Und bitte nicht vergessen, bei jedem der im “Privacy Statement” genannten Punkte – besonders aber bzgl. des Punktes “Personal Data We Collect” auf “Learn More” zu klicken! Erst dann offenbart sich die ganze Vielfalt der erfassten Daten …. bis hinunter auf die Ebene von Mail-Texten, Kontakten und PC- wie Internet-Aktivitäten jeder Form. Flankiert wird das Ganze durch passende “Service Agreements”:

 
Hmmm …, das alles gilt also im Falle einer STANDARD-Installation von Windows 10 Home. Das bedeutet glassklar:

“NO PRIVACY by design” unter Win 10. Oder anders formuliert: Der Respekt vor privaten Daten ist bei MS nicht mehr der Standard.

Mit Interesse habe ich ferner zur Kenntnis genommen, dass das Privacy Statement für ganz unterschiedliche MS Produkte (Windows, Skaype, Outlook, Bing, …) – also vermutlich jeweils separat – gilt. Das allein wirft interessante Fragen auf: Konfiguriert man z.B. Win 10 Home nachträglich – soweit das überhaupt möglich ist – für den Schutz privater Daten, so heißt
das womöglich noch lange nicht, dass die Speicherung von Mailtexten auf MS Servern in den USA im Falle der Nutzung von Outlook (oder des aktuellen Mail-Ablegers) verhindert würde.

Das Akzeptieren des Service Statement ist ferner obligatorisch. Das ist deshalb interessant, weil darüber das weitgehende Datensammeln auch bei Abwahl einiger Datentransferoptionen der Win 10 Home Edition für MS abgesichert wird. Siehe:

 
Eine entsprechende – für normale Anwender/Admins nutzbare – Option zur vollständigen Unterbindung diagnostisch relevanter Daten findet sich offenbar nur in der Enterprise Version von Windows 10. In der Windows 10 PRO und Home Versionen sind dagegen wohl risikobehaftete Klimmzüge über die Registry erforderlich:

 
Siehe beim letzten Link auch die vielfältigen Kommentare …

Das Ganze bedeutet im Klartext: im Falle von Firmen-Lizenzen bietet Win 10 offenbar andere, weitergehende Optionen zum Schutz von PC-Nutzungs- und “privaten” Daten an als im Falle des privaten Einzelanwenders, der dafür sein Upgrade aber kostenlos bekommt.

So wird über das Service Statement für den normalen Home Nutzer indirekt relevant, was MS unter “diagnostischen Daten” subsummiert. Es lese jeder selbst unter den obigen Links nach …

Erstes Fazit:
Arme Win 10 Home User … natürlich gibt es unter Win 10 Optionen, um die Datensammelwut auch nach einer Standardinstallation einzugrenzen. Aber durch die Gültigkeit des Privacy Statements über das reine Windows auf andere MS Produkte (Skype, Outlook, Bing, …) hinaus UND über den Zwang zum Akzeptieren des Service Statements entkommt der Win 10 Home User einer weitgehenden Verwertung von Daten zur Interaktion mit dem System und auch privaten Daten nicht vollständig.
Und wer sagt mir eigentlich bei einem Closed Source System, das Daten verschlüsselt in die USA überträgt, ob das Klicken von irgendwelchen Checkboxen auch das bewirkt, was da versprochen wird ….

Hinweise, dass die Deaktivierung bestimmter Datentransferoptionen letztlich wenig nutzt, sind hier beschrieben:
http://thehackernews.com/2015/08/windows-10-privacy-spying.html

Weitere “Features” von Win 10 Home
Ein weiteres “interessantes” Feature des kostenfreien Windows 10 Upgrades ist ferner der dann nachfolgende Zwang zum Update:

 
Hinzu kommt ferner eine fundamentale Richtungsänderung zur Behandlung von sicherheitsrelevanten Passwörtern für Wi-Fi-/WLAN-Systeme, zu denen ein Win 10 Gerät Verbindung aufnimmt. Solche Passwörter werden bei unbedarfter Nutzung von Win 10 Home auch auf MS Server transferiert. Und nicht genug damit: Outlook, Skape, Facebook-Kontakte des Win 10 Home Users werden u.U. in die Lage versetzt, dieses Passwort für das WLAN zu nutzen as

Konatkte Siehe zu diesem speziellen Thema
Die große Passwort-Sammlung … Wi-Fi Sense unter Win 10

Zweites Fazit:
Im Summe zeigt nun also der Marktführer für PC-Betriebsysteme mal wieder als Letzter der Großen im IT-Business – dafür aber umso ausgeprägter -, wohin die Reise geht:

Der Nutzer soll den Zugang zu IT- und Internet-Ressourcen künftig nicht mehr mit Geld, sondern mit der Aufgabe seine Privatsphäre bezahlen. Die Kontrolle über den Update-Status der eingesetzten Closed Source Software wird ihm dabei zusätzlich entzogen – selbst wenn dies, wie in einem der genannten Artikel beschrieben, auch mal zu Endlosschleifen führen kann. Will man eigentlich mit solcher “Zwangs-Technik” für Unmündige leben?

Privatsphäre ist wichtig – auch und gerade im Zeitalter des Internets !
Viele Vertreter unserer Eliten (Unternehmer, Politiker, …) reden von der Verantwortung für die kommenden Generationen. Da geht es oft um Geld, Schulden, Umwelt, Klimakatastrophe, Flüchtlingsströme, Bevökerungswachstum etc. etc.. Dass aber die von uns z.T. mitentwickelten Anwendungen fürs Internet diesen Generationen gerade die letzten Schlupfwinkel fürs “Private” stehlen, kommt vielen – gerade SW-Entwicklern – erst langsam zu Bewusstsein.

Die bittere Wahrheit ist: Es braucht für die Aufgabe der Privatsphäre gar keine Geheimdienste …. die voranschreitende, für den Anwender angeblich “kostenfreie” Verschmelzung der Betriebssysteme mit Cloud- und Internet-Diensten genügt dazu völlig …

Dass mit dieser aktuellen Entwicklung der IT gerade die elementaren Fundamente und Grundpfeiler der Demokratie untergraben werden, wird leider nur von wenigen Aufrechten klar gesagt, die dafür im besten Fall als altmodisch bezeichnet werden. My home is my castle – das wahr einmal …. Dabei hatte ich im bayerischen Sozialkundeuntericht vor nunmehr fast 40 Jahren noch gelernt, dass Freiheit und Demokratie mit dem Respekt vor der Freiheit, der Meinung und eben auch der Privatsphäre anderer Menschen beginnen …. die moderne Übersetzung für IT-Belange heißt: Respekt vor der “informationellen Selbstbestimmung”. Die Erfinder von Win 10, Facebook, etc. haben den wohl völlig verloren …. wenn sie ihn denn jemals hatten …

Ich bin deshalb gerne konservativ und meinetwegen auch altmodisch. Und ich nutze deshalb Linux, seine Sicherheitsfeatures und bei Bedarf Tor zum Browsen …. und die sogenannten Cloud-Segnungen und die sog. “sozialen” Medien der Vernichter von Privatsphäre im Internet können mir weiterhin gestohlen bleiben …… egal von wem und unter welcher Version ….. ob unter Android, iOS oder eben Win 10 ….

Ceterum censeo:
Die Schlacht um ein freies Internet – im Sinne freier Individuen mit geschützter Privatsphäre, die selbst entscheiden, wann und was sie an Informationen freigeben – wird gerade zig millionenfach verloren. Das Internet und seine Dienste müssen
deshalb eigentlich neu erfunden werden und zwar exakt nach dem Grundsatz “privacy by design” – von den elementaren Protokollen bis hin zu komplexen Anwendungen. Lasst uns im Sinne der Bewahrung von Demokratie für die nächsten Generationen also endlich damit anfangen …. Das passende Betriebssystem als Grundlage gibt es dafür Gott sei Dank ja schon ….

Wer nun noch wissen möchte, ob Windows 10 denn neben seiner Datensammelwut auch etwas Vernünftiges, z.B. an SW- und Bedienkomfort auf dem Desktop, anbieten könne, der möge folgenden Artikel eines Linux-Anwenders, der Win 10 tatsächlich mal ausprobiert hat, lesen:

Tja, dazu passt dann abschließend noch die Einschätzung in folgendem Artikel:

 

SFTP mit Key-Authentication auf (gehosteten) Linux-Servern für Web-Entwickler mit unterschiedlichen Privilegien – I

Da ich immer mal wieder SSH- und SFTP-Verbindungen für gehostete LAMP-Test- und LAMP-Produktiv-Server unter Linux (genauer: Opensuse) konfigurieren muss, stelle ich in einer Artikelserie mal ein paar Hinweise zu den durchzuführenden Überlegungen und administrativen Schritten zusammen.

Ich setze im nachfolgend beschriebenen Fall nur das interne SSH-Subsystem für SFTP und Dateitransfers auf den Test-/Produktiv-Server ein. Bzgl. eventuell vorzusehender unterschiedlicher Zugriffsrechte der (S)FTP User genügt aus meiner Sicht die Diskussion eines Beispiels mit 2 User-Gruppen und zwei unterschiedlichen (Domain-) Verzeichnissen auf dem Server.

Ich gehe im Folgenden davon aus, dass der Leser bereits über etwas Erfahrung mit der Einrichtung von SSH auf einem Remote-System besitzt. Wenn nicht: Siehe
Strato-V-Server mit Opensuse 12.3 – IV – SSH Key Authentication
und vorhergehende Artikel. Im vorliegenden, ersten Artikel der aktuellen Serie behandle ich grundlegende SSH-Einstellungen nur relativ kurz und diskutiere sie hauptsächlich unter Sicherheitsaspekten. Ein zweiter Artikel befasst sich dann mit der konkreten User-Einrichtung für die SFTP-Nutzung.

Abgrenzung SFTP-Uploads von SVN-Updates über SSH

Wir lassen im diskutierten Kontext die Möglichkeiten von SVN (in Kombination mit SSH) für das systematische Füllen von Domain-Verzeichnissen des (Web-) Test-Servers außer acht – obwohl viele Entwickler dies aus Bequemlichkeit nutzen.

Nach meiner Ansicht hat die Code-Versionsverwaltung in Entwicklungsphasen logisch nur wenig mit dem gezielten Upload konsolidierter Dateien einer bestimmten SW-Test- oder -Produktiv-Version in entsprechende Domainen eines Web-Test- oder -Produktiv-Servers zu tun. Letzteres – also der Upload – entspricht eher Export-Vorgängen (z.B. unter Eclipse) oder eben gezielten FTP-Transfers. Unter diesen Prämissen wie auch unter Sicherheitsaspekten hat SVN auf einem exponierten Test- oder Produktivsystem eigentlich wenig verloren. SVN ist vielmehr Teil der Service-Landschaft der Entwicklungsumgebung im lokalen Netz und dient dort der laufenden Protokollierung von Versionsständen einzelner SW-Files sowie deren Konsolidierung.

Elementare Ziele, Anforderungen und Voraussetzungen

Gehosteter Server
Der Server habe die Adresse “serv@myhoster.net” und sei gehostet. Der reguläre SSH-Zugang zu diesem Server für Verwaltungszwecke erfolge zunächst über einen (unpriviligierten) User “usu” über den (high) Port “xxxxx”. Über den “usu”-Account und die Shell logt man sich dann bei Bedarf als “root” ein.

Authentifizierung über Private/Public SSH-Keys
Ein sicherheitsrelevanter Aspekt ist im Falle gehosteter Server die Authentifizierung der Entwickler mittels

  • eines privaten SSH-Keys auf dem Client
  • sowie dessen Gegenstück, nämlich eines auf dem Server hinterlegten Public Keys,

anstelle von User IDs und Passwörtern. Ich gehe im ersten Beitrag auf die wichtigsten zugehörigen Anweisungen in der SSHD Konfigurationsdatei ein. Durch Key-Authentication lassen sich Brute Force Angriffe auf den SSH-Zugang eindämmen; als Admin sollte man aber nicht übersehen, dass durch ein solches Verfahren auch die Anforderungen an die sichere Verwahrung der Schlüssel auf den Clients steigen.

Passwortschutz des private Keys auf dem Client – ?
Eine “Private Key”-Datei auf einem Client-System stellt eine potentielle Gefahrenquelle dar:

  • Mobile Clients können gestohlen werden.
  • n

  • Desktops wie mobile SSH/SFTP-Clients können gehackt werden.

Ein Passwortschutz des privaten Keys ist deshalb eine Mindestanforderung an die Sicherheit – wenngleich auch das nicht gegen implantierte Key-Logger schützt. Eine interessante Frage ist deshalb:

Was gilt im Zshg. mit Key-Passwortschutz eigentlich für gängige SFTP-Clients?

Welcher SFTP-Client unterstützt den Umgang mit Private Keys, wenn diese im Sinne einer durchgehenden Sicherheit auf den Client-Systemen passwort-geschützt hinterlegt werden sollen? Ich gehe in einem der nachfolgenden Artikel deshalb kurz auf diese Frage ein.

Kein SSH-Shell-Zugang
Die User – hier Entwickler – sollen das SSH-basierte SFTP nur für File-Transfers nutzen; sie sollen auf dem Server jedoch keinen Shell-Zugang über SSH erhalten. Administrative Aufgaben auf Test- oder Produktiv-Servern remote durchzuführen, bleibt in unserem Szenario ausschließlich Server-Administratoren vorbehalten.

Verzeichnisse, Entwicklergruppen und Rechte
Während die Einrichtung des SFTP-Servers für eine Key-Authentifizierung nur wenig von Vorgehensweisen abweichen dürfte, die bereits an anderer Stelle im Internet beschrieben sind, ist in unserem Beispiel ein zusätzlicher Punkt folgender:

In Web-Entwicklungsprojekten ist es sinnvoll, definierte Gruppenrechte und manchmal auch User-Rechte auf bestimmten SFTP-Verzeichnissen des Servers – die dort in der Regel Web-Domain-Verzeichnisse umfassen – zu erzwingen. Warum?

  • Einerseits will man die User (Entwickler) womöglich in Log-Dateien unterscheiden können. Man wird Ihnen (genauer: ihren UIDs) deshalb in jedem Fall unterschiedliche Authentifizierungs-Keys zuordnen. Ferner sollen die Entwickler ggf. aber auch gruppenübergreifend kollaborieren. Deshalb braucht man abgestimmte Lese- und Schreib-Rechte auf Verzeichnissen für eine (oder mehrere) definierte Gruppe(n). Für die Darstellung besonderer Privilegien können auch user-bezogene Rechte erforderlich werden. Das Schreibrecht wird man auf einem exponierten Web-Server in jedem Fall so gut wie nie “others” zuordnen.
  • Zudem ist zu gewährleisten, dass der Webserverprozess selbst transferierte Directories und Files lesen und im Falle der Bereitstellung von dynamisch geschriebenen Download-Dateien auch beschreiben kann. Der User, unter dem der Webserver-Prozess läuft, muss auch dann wieder Teil einer Gruppe werden, wenn man “others” keine Schreibrechte zuordnen will.
  • Es ist durchaus normal, dass unterschiedliche Privilegien des Zugriffs auf Verzeichnisse in ein und derselben Verzeichnis-Hierarchie für die Mitglieder unterschiedlicher Entwicklergruppen gefordert werden. Der Zugang zu bestimmten Verzeichnissen und Subverzeichnissen soll in unserem Beispiel per SFTP Chroot und durch das Setzen von Zugriffsrechten auf bestimmte Verzeichnisse limitiert werden. Die Entwickler sollen in unserem Beispiel in 2 Gruppen mit unterschiedlichen Zugriffsrechten auf die Verzeichnishierarchie unterteilt werden.

Wir lassen ferner Zugriffe nur auf Web-Domain-verzeichnisse zu; wir erlauben den Entwicklern keinen Zugriff auf private Home-Verzeichnisse.

Zwei Entwickler-Gruppen mit unterschiedlichen Privilegien
Wir diskutieren in unserem Beispiel den abgestuften Zugriff zweier unterschiedlich privilegierter Entwicklergruppen auf Verzeichnisse unterhalb eines Chroot-Jails “/srv/www/htdocs/webs/project”.

/srv/www/htdocs/webs/project
|
— test
|
— adm
|
— rc

Die Subverzeichnisse entsprechen z.B. verschiedenen Web-Domainen oder Entwicklungsprojekten mit jeweils weiteren Sub-Sub-Verzeichnissen. Da unterschiedliche Berechtigungen für die Domain-Verzeichnisse gegeben sein sollen, werden im Beispiel zwei
Usergruppen devgrp1 und devgrp2 eingerichtet.

Zusätzlich wird der Zugriff der Gruppe “devgrp2” auf Inhalte eines weiteren Chroot-Verzeichnis – hier “test” – eingeschränkt. Die Mitglieder der “devgrp1” dürfen dagegen auf alle definierten Domain-Verzeichnisse zugreifen. Sie sind deshalb zugleich sekundäre Mitglieder der “devgrp2”.

Als Beispiel-User wählen wir hier die User “alpha” (Mitglied von “devgrp1” und “devgrp2”) und “beta” (Mitglied von “devgrp2”). Andere Berechtigungsszenarien lassen sich später aus diesem Beispiel zwanglos ableiten.

  • Mitglieder devgrp1: alpha (Zugriff auf alle Verzeichnisse)
  • Mitglieder devgrp2: beta, alpha (Zugriff nur auf Inhalte von “test”)

Grundlegende Konfiguration und Sicherheitsaspekte der SSH-Einrichtung

Wie man einen Opensuse-Server bei einem Hoster wie Strato grundsätzlich für einen SSH-Zugang mit verschobenem Port und Key-Authentifizierung konfigurieren kann, habe ich bereits in früheren Artikeln in diesem Blog besprochen. Siehe etwa:
Strato-V-Server mit Opensuse 12.3 – IV – SSH Key Authentication
und vorhergehende Artikel.

Ich gehe in diesem Artikel entsprechend davon aus, dass es bereits einen elementar eingerichteten SSH-Service gibt und diskutiere nur einige wichtige Optionen der Konfigurationsdatei “/etc/ssh/sshd_config” des einzurichtenden SSHD-Daemons (s.u.).

Ein paar Hinweise und Warnungen:

Je nachdem, was man an Hosting-Paket (Virtual Server etc.) geordert hat, richtet der Provider eine elementares Linux mit SSH-Zugang ein – meistens ausschließlich für den User root. In der Regel wird man das System in einem ersten Schritt upgraden/updaten und danach auch die SSH-Konfiguration remote und schrittweise abändern. Dabei ist Vorsicht angebracht! Man will sich bei Experimenten mit der SSH-Konfiguration ja schließlich nicht selbst vom Systemzugang ausschließen. Bitte beachten Sie die diesbzgl. Hinweise in den oben genannten Artikeln. Unbedingt sollte man sich beim Provider nach Notfall-Maßnahmen im Falle eines nicht mehr möglichen SSH-Zugangs erkundigen. Meist ist das Booten eines Notfall-Systems mit anschließendem Platten- und Dateizugriff möglich …. Die Notfall-Maßnahmen sollte man auch mal ausprobieren …

Im Zshg. mit SSH- und System-Startup-Modifikationen ist dafür zu sorgen bzw. zu prüfen, dass der SSHD-Daemon bei jedem (automatischen) Systemstart aktiviert wird. Gerade bei gehosteten Servern ist dies ein kritischer Punkt. Provider fahren u.U. die gehosteten Server ohne Rückfrage automatisch rauf und runter, wenn Wartungsmaßnahmen dies erfordern. Nach einem solchen Reboot muss natürlich der SSH-Service auch wieder verfügbar sein.

Jemand der SSH selbst auf einem gehosteten Server konfiguriert, sollte sich deshalb auf Opensuse-, Red Hat- und künftig wohl auch Debian-Systemen mit den entsprechenden Optionen des “systemctl”-Kommandos von “systemd” vertraut machen und überprüfen, dass der SSH(D)-Service für den automatischen Start beim Booten aktiviert ist. Unter Opensuse führt

systemctl enable sshd.service

zur Aktivierung. Den aktuellen Service-Zustand – inkl. Aktvierung – prüft man mit:

mylinux:~ # systemctl status sshd.service
sshd.service – OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Sat 2015-08-08 09:16:50 CEST; 3h 9min ago
Process: 1615 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/
SUCCESS)
Main PID: 1650 (sshd)
CGroup: /system.slice/sshd.service
└─1650 /usr/sbin/sshd -D
 
Aug 08 09:16:50 mylinux sshd-gen-keys-start[1615]: Checking for missing server keys in /etc/ssh
Aug 08 09:16:50 mylinux sshd[1650]: Server listening on 0.0.0.0 port xxxxx.
Aug 08 09:16:50 mylinux sshd[1650]: Server listening on :: port xxxxx.

Das korrekte Reboot-Verhalten des gehosteten Servers ist nach Systemeingriffen natürlich nicht nur für SSH/SFTP sondern auch andere Serverdienste zu testen.

Ferner gilt:

Bevor man bestimmte User definitiv vom SSH-Zugang ausschließt, sollte man immer die Zugangsmöglichkeit für einen oder mehrere verbleibende User explizit testen. Mindestens ein verbleibender User sollte immer vorhanden sein.

Ähnliches gilt für die Umstellung auf Key Authentication:

Bevor man eine passwort-basierte Authentisierung für alle User abstellt, sollte man zunächst ausschließlich mit userspezifischen Festlegungen arbeiten und für einzelne User die Funktionstüchtigkeit der Key-Authentifizierung testen. Zur Einrichtung userspezifischer SSHD-Konfiguration dienen die “Match”-Anweisung und zugehörige Blöcke am Ende (!) der SSHD-Konfigurationsdatei. Man lese hierzu unbedingt die ssh-man-Seiten.

Auch der nachfolgende Artikel

SFTP mit Key-Authentication auf (gehosteten) Linux-Servern für Web-Entwickler mit unterschiedlichen Privilegien – II

zeigt beispielhaft, wie man userspezifische Anweisungen anlegt und wie diese aussehen können.

SSH-Zugang für root?
Der direkte SSH-Zugang für root sollte auf einem exponierten System i.d.R. nicht zugelassen werden. Er ist auch überhaupt nicht erforderlich. Erlaubt werden soll und muss der SSH-Zugang im Anfangsstadium dagegen für einen bereits erwähnten, unpriviligierten User “usu”.

Ein solcher unpriviligierter User muss auf dem gehosteten Server erstmal eingerichtet werden. Meist existiert auf gehosteten Servern anfänglich nur der User root. Bevor man den SSH-Zugang für root sperrt, muss der Zugang inkl. Shell-Nutzung für den neuen unpriviligierten User explizit getestet werden. Die Zugangsdaten des unpriviligierten Users sind vom Admin geheimzuhalten. Dieser Account bleibt sein Weg ins System – über den “usu”-Account erfolgt dann indirekt über “su -” der Login als root.

Für den User “usu” sei auf unserem Server bereits ein Public/Private-Key-Paar eingerichtet. Siehe hierzu den oben erwähnten Artikel. Wie man das für andere Accounts macht, zeigt beispielhaft auch der zweite Artikel dieser Serie.

Begrenzung des SSH-Zugangs auf bestimmte IP-Adressen?
Eine spezielle Sperre des Zugangs für allgemeine Host-IP-Adressen bzw. eine Zugangserlaubnis für definierte IP-Adressen gestalte ich normalerweise über eine Firewall und nicht über die SSH-Konfiguration. Die Firewall erlaubt dann für vordefinierte IPs den Zugang zu einem definierten High Port xxxxx für SSH und zu einem definierten Port für HTTPS.

Es sei an dieser Stelle aber ausdrücklich auch darauf hingewiesen, dass die weiter unten benutzte Anweisung

AllowUsers uid

Zusätze der Form

AllowUsers uid@ip.add.re.ss

erlaubt. Gerade bei wenigen SSH/SFTP-Usern, die immer von Clients mit fixer IP-Adresse aus zugreifen, ist das eine gute Möglichkeit, die Nutzung des SSH-Services weiter einzugrenzen.

An dieser Stelle sei auch angemerkt, dass man auf Systemen mit mehreren Netzwerk-Interfaces eingrenzen kann, auf welchem Interface der SSHD angeboten werden soll. Dies geht über die IP-Adresse, die dem Interface zugeordnet ist und der Direktive “ListenAddress”. Für mehr Informationen siehe etwa:
http://www.thegeekstuff.com/2011/
05/openssh-options/

Portverschiebung – Obfuscation
Der Nutzen einer Zuordnung des SSH-Services zu einem selbst definierten Port (hoher Portnummer) wird unterschiedlich diskutiert. Ich persönlich ändere den SSH-Port regelmäßig ab, da zumindest meine Erfahrung zeigt, dass die Anzahl bestimmter Angriffsversuche von Skript-Kiddies danach zurückgeht. Nachfolgend steht “xxxxx” für eine 5-stellige High-Port-Nummer.

Ausschnitte aus der SSHD-Konfigurationsdatei “/etc/ssh/sshd_config”

Nachfolgend ein paar Anweisungen aus einer finalen Konfigurationsdatei für den SSHD als Grundlage von SFTP:

Port xxxxx 
# z.B. Port 64311

AllowUsers usu 
PermitRootLogin no
....
....
RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile   .ssh/authorized_keys

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  ....
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox          # Default for new installations.

# override default of no subsystems
#Subsystem      sftp    /usr/lib/ssh/sftp-server -u 0007
Subsystem       sftp    internal-sftp

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

MaxSessions 50
MaxAuthTries 20
MaxStartups 20

....
.....

Hinweis zur SFTP-Aktivierung:
Zu beachten ist die Aktivierung des internen SSH SFTP-Subsystems über

Subsystem    sftp    internal-sftp

Das ist zunächst die einzige Stelle, an der SFTP hier überhaupt ins Spiel kommt! Und noch ein Hinweis für für erfahrene Admins: die “-u” Option von internal-sftp wird hier nicht angewendet. Wir kommen darauf im 2-ten Artikel dieser Serie zurück.

Wichtiger Hinweis zum schrittweisen Vorgehen:
Bitte beachten Sie, dass Sie eine solche finale Konfiguration, die den SSH-Port verschiebt sowie root-Zugang und einen passwort-basierten Zugang grundsätzlich ausschließt, im Sinne der obigen Warnungen nur schrittweise etablieren sollten. Sehen Sie hierzu die oben erwähnten anderen Artikel dieses Blogs.

Kommentierung einiger sicherheitsrelevanter Anweisungen in der SSHD-Konfiguration

So absurd sich das anhören mag: Ein grundsätzliches Problem im Zusammenhang mit SFTP ist gerade, dass wir auf dem entsprechenden Server SSH einrichten müssen.

Der Grund für diese Aussage ist: SSH in den Händen gewiefter und böswilliger User stellt ein enormes potentielles Sicherheitsproblem dar. Siehe z.B.:
http://
www.informit.com/articles/article.aspx?p=602977

https://threatpost.com/encrypted-tunnels-enable-users-circumvent-security-controls-060109/72742

Eines der größten Probleme ist, dass User mit Shellzugang SSH dazu benutzen können, um sog. “Reverse Tunnels” zu privaten Systemen durch Firewalls hindurch zu etablieren, und in diesem Zusammenhang sogar eigene Port-Forwarding Tools einsetzen. Die aus meiner Sicht wirksamen Sicherheitsmaßnahmen gegen dieses Gefährdungspotential sind in diesem Zusammenhang:

  1. den Zugang zu SSH auf wenige User einzugrenzen
  2. den Usern, die SSH lediglich als Basis von SFTP oder als Basis von geplanten, verschlüsselten Tunneln zu Applikationen einsetzen dürfen, den Shellzugang zu entziehen.
  3. Massive Strafandrohungen bei Verletzung von Policies, wenn Administratoren Shell-Zugangsrechte erteilt werden müssen.

Welche Einstellungen in der obigen Datei sshd_config betreffen die Sicherheit?

Wir erkennen zunächst das Sperren des root-Users für SSH über die Anweisung “AllowUsers”. Ein irgendwie geglückter SSH Crack beinhaltet dann zumindest nicht unmittelbar das Risiko einer Betätigung mit Root-Rechten.

Ferner sehen wir die Festlegung eines besonderen Ports “xxxxx” für den SSH-Service. Dieser TCP-Port muss natürlich in der Firewall geöffnet werden. Die Verschiebung des SSH-Services vom Standardport hält gewiefte Angreifer, die ausführliche Portscans unternehmen, deshalb nicht lange ab.

Password-Authentifizierung ist trotz PAM im Sinne der Kommentare im Konfigurationsfile abgeschaltet. Wir lassen PAM hier an, um auf PAM-Ebene noch weitere Möglichkeiten zur User-Einschränkung bzw. User-Überwachung zu bekommen. Wer dem nicht traut, kann die Nutzung von PAM aber auch abschalten.

Die Zeilen

RSAAuthentication yes
PubkeyAuthentication yes

sorgen dagegen für die von uns gewünschte Authentifizierung mit asymmetrischen RSA-Schlüsseln.

Unterbinden von Port Forwarding und Gateways für Tunnel
Da wir für SFTP kein TCP-Forwarding über SSH benötigen, schalten wir es aus Sicherheitsgründen ab. Die Nutzung unseres Servers als SSH-Gateway ist aus Sicherheitsgründen völlig unerwünscht. Wir schalten deshalb auch den Parameter GatewayPorts ab. X11 sollen unsere lieben SFTP-User natürlich auch nicht nutzen.

Das Einrichten und Nutzen von problematischen Reverse Tunnels über unseren Server ist damit künftig für unsere Entwickler schon nicht mehr so ohne weiteres möglich. Wir müssen weiter unten dennoch den Shell-Zugang für die definierten SFTP-User “alpha” und “beta” sperren, denn, wie die SSH-man-page so schön ausführt, gilt

Note that disabling TCP forwarding does not improve
security unless users are also denied shell access, as they can
always install their own forwarders.

U.a. netcat, portfwd und socat sind entsprechende Tools. See
https://www.digi77.com/the-art-of-port-forwarding-on-linux/
http://29a.ch/2009/5/10/forwarding-ports-using-netcat
Aber es geht u.U. auch einfacher:
http://clinging-to-reality.blogspot.com.br/2014/06/reverse-ssh-tunnel-if.html

Ein grundsätzlich wichtiger Punkt ist in diesem Kontext immer auch, dass ein umsichtiger Admin dafür sorgt, dass der sshd-Dämon auf dem Server nicht von jedermann gestartet werden kann:

chmod 754 /usr/sbin/sshd

Zur Sicherheit sollte man auch Compiler deaktivieren,
um das Kompilieren eigener Module aus eigenen Source-Quellen zu unterbinden.

Siehe zu einer Diskussion von Gefahren durch SSH und im Besonderen durch SSH Reverse Tunnels etwa:
http://www.techexams.net/forums/off-topic/67117-circumventing-network-security-via-ssh-tunneling.html

Einige Aspekte der Sicherheit werden im Zusammenhang mit verketteten Tunneln auch in folgendem Artikel angesprochen:
https://linux-blog.anracom.com/2013/11/22/ssh-getunnelter-datenbankzugang-fur-gehostete-lamp-server-i/

Sicherheitsanforderungen im Umgang mit privaten Schlüsseln

An dieser Stelle ist der dringende Hinweis angebracht, dass das sichere Verwahren von privaten Schlüsseln auf SSH/SFTP-Clients weiterer Schutzmaßnahmen bedarf. Hinsichtlich der Sicherheit ist immer die gesamte Kette der involvierten Systeme zu betrachten! Ein SSH-Auth-Key auf einem Windows-System in einem privaten oder öffentlichen Netzwerkumfeld ist ohne weitere Schutzmaßnahmen ggf. gefährlicher als eine Authentifizierung mit User IDs und einem generierten Passwort! Ferner:
Es gibt Leute,

  • die die Verwendung ein und desselben Key-Paars für verschiedene Server
  • und die dauerhafte Verwahrung von Keys auf einem System ohne weitere Verschlüsselungskomponenten wie etwa für die Dateisysteme, auf denen die Schlüssel gelagert werden,

für potentiell gefährlich halten. Gerade der zweite Punkt ist im Zusammenhang mit einem oben bereits diskutierten Diebstahl (z.B. eines Laptops) unbedingt zu unterstreichen. Ich meine aber, dass der generellen Absicherung der Client-Systeme im regulären Betriebszustand eine ebenso große Bedeutung zukommt. Auf einem Client-System, das mit Key Loggern und Trojanern kompromittiert wurde, nutzt der Einsatz einer schlüsselbasierten Authentisierung gar nichts.

Es versteht sich aus meiner Sicht von selbst, dass der private Schlüssel zusätzlich durch ein Passwort geschützt sein sollte. Man tut deshalb gut daran, sich nach FTP-Clients umzusehen, die Key-Authentifizierung mittels passwortgeschützten Private Keys unterstützen.

Genug für heute. Der nächste Artikel

SFTP mit Key-Authentication auf (gehosteten) Linux-Servern für Web-Entwickler mit unterschiedlichen Privilegien – II

befasst sich dann mit der konkreten Einrichtung unserer SFTP-User.

Allgemeine Links

http://www.unixlore.net/articles/five-minutes-to-even-more-secure-ssh.html

http://www.thegeekstuff.com/2011/05/openssh-options/