AlexaLazy - Sicherheitsübeelegungen

Begonnen von Sidey, 12 Januar 2019, 10:58:27

Vorheriges Thema - Nächstes Thema

Sidey

Hi,

Ich habe mir das Fhem Lazy angesehen.
Die Entwicklung passt prinzipiell auch gut, zu dem was ich bereits als Risiko bezüglich einer Alexa Anbindung erkannt habe.

Ich bin allerdings noch etwas skeptisch, ob es wirklich so sicher ist, wie ich es gerne hätte
Es kann gut sein, dass ich es nicht richtig verstanden habe.

Ich fasse grob zusammen, wie ich es verstehe:

Es gibt AWS Lambda Funktionen und einen Skill. Diese werden vom FHEM Verein zur Verfügung gestellt.

Der Verein stellt auch einen Server bereit der als Proxy mit Authentifizierung agiert.

Ein lokal laufendes NodeJS wird über einen SSH Tunnel an den Proxy Server angebunden.

Wie genau Fhem nun an NodeJS hängt, habe ich mir noch nicht angesehen.  Ist glaube ich auch nicht so entscheidend.


Wenn ich das soweit richtig erfasst habe, dann habe ich gegenüber der vorherigen Implementierung folgendes geandert:

1. Ich habe keinen Port im Internet geöffnet auf den potentiell 7 Mrd.
zugreifen können.

2. Ich muss mich nicht mit AWS Lambda Funktionen abgeben.

3. Ich vertraue dem FHEM Verein, dass nur ich über meinen SSH Tunnel auf meinen nodeJS Server zugreife.

Der Letzte Punkt ist auch genau der, mit dem ich hadere.

1. Die Kommunikation läuft über HTTP. Also kann NodeJS nicht feststellen, wer gerade zugreift. Dem Proxy Server dürfte es auch schwerfallen zu erkennen, ob er die Daten an das richtige System leitet.
Eine Prüfung der Gegenstellen mit HTTPS wäre hier sicher Vorteilhaft.

2. Der SSH Tunnel wird über einen Schlüssel etabliert.
Der läuft vermutlich nie ab und ob ich mit dem richtigen Endpunkt kommuniziere, hängt vom DNS ab. Das wird nicht verifiziert (oder?).
Wie sicher die Erzeugung der Schlüssel ist, lasse ich mal offen. Eine Variante über eine anerkannte Zertifizierungsstelle wäre mir lieber.

Diese Annahmen haben mich zur Frage gebracht, ob dieser SSH Tunnel wirklich so gut ist.

Ich würde am liebsten ja bei mir selbst entscheiden wollen, wer auf das nodeJS Zugriff bekommt und es ungern einem anderen System überlassen.

AWS scheinen ja auch Oauth2 Tokens des Accounts zu erstellen unter dem der Echo läuft.
Oauth2 Authentifizierung habe ich bereits über einen Reverse Proxy evaluiert. Das ist nicht wirklich schwierig und man kann die Accounts auch whitelisten.
Gibt es Gründe, die dagegen sprechen die Zugriffe lokal bei sich selbst zu verifizieren?

Ich will die Lösung mit dem SSH Tunnel nicht schlecht machen. Aber ich vermute, auf den Proxy Server des Vereins können die gleichen 7 Mrd. Zugreifen, wie auf meinen potentiell im Internet geöffneten Port.
Der Sicherheitsgewinn ist mir dazu noch nicht so visibel :(


Grüße Sidey





Gesendet von meinem Moto Z (2) mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

gvzdus

Hi, ich finde es gut, dass Du mal laut und kritisch über das Sicherheitskonzept nachdenkst.

Allerdings sind an 1-2 Stellen Deiner Fragen m.E. die Fragen schon im Wiki beantwortet, z.B. nach der DNS-Manipulation. Kannst Du bitte noch mal im Wiki den Abschnitt "Sicherheitskonzept und Secrets" lesen?

Zu SSH: Das gilt als sicher, jedenfalls viel sicherer als Passwörter. Nicht umsonst setzt Amazon bei EC2 durchgängig da drauf.

Zu Deiner Sicherheit: Die hängt im Kern am BearerToken, das durchaus in FHEM abrufbar ist (auch wenn Andre es künftig nicht direkt sichtbar macht). Das BearerToken reichst Du einmalig über den Vereinsserver an Amazon weiter, aber es wird auf dem Vereinsserver nicht gespeichert.

Einfach die Einladung, Dich selber zu hacken (oder mich), im Moment geht das noch, weil auf dem Vereinsserver nicht die Kommandos auf den Amazon-IP-Range gefiltert werden:

Schnappe Dir aus Deinem Lizenzschlüssel die erste Gruppe. Ich sage Dir meinen aktuellen ersten Teil: 1469F4

Wenn Du jetzt folgenden Aufruf machst:

curl -H 'Authorization: Bearer 1469F4' https://va.fhem.de/alexa

setzt Du einen Request auf meinen persönlichen Raspberry ab! Feel free!

Wenn Du jetzt noch mein Bearer-Token kennen würdest, dann könntest Du in der Tat meine Geräte steuern! Aber Alexa-FHEM prüft halt das BearerToken mit dem in FHEM hinterlegten, und solange Du das nicht kennst, werden Deine Zugriffe abgelehnt.

Happy testing mit Dir selbst oder mir!

gvzdus

P.S. In der Tat will ich das Kommando im IP-Range auf bekannte Amazon-IPs beschränken.
Ich hatte aber genau darauf gehofft, dass jemand die Frage stellt!

Was lässt sich noch verbessern?
Da die Lambda-Funktion "vom Verein" nicht public ist, kann man hier auch halbwegs brauchbar ein Secret hinterlegen, dass auf der URL

  https://va.fhem.de/alexa

dann geprüft wird. Das ist eine zusätzliche Hürde. Aber wie gesagt: Im Prinzip habe ich auf die Frage gehofft und das an der Stelle bewusst noch offen.

justme1968

von mir auch noch ein paar kurze anmerkungen... (ok... ist doch etwas länger geworden ;))

und eins vor weg: das ganze ist in jedem fall immer ein kompromiss aus sicherheit, komfort und kosten. egal wie man es dreht... du kannst nur zwei der drei optimieren. welche das sind und ob du dann mit dem erst risiko leben möchtest ist die entscheidung jedes einzelnen.


das jemand (oder auch am liebsten mehrere) sich das ganze anschauen und ideen haben ist sehr gut! hierbei sollte aber die zielgruppe nicht aus den äugen verloren werden. das ist weder der sicherheitsfanatiker noch der technisch so versierte der sich alles mit eigenen skills selber einrichtet. sondern es sind die anwender die nicht das können und die zeit und die lust dazu haben.


nun etwas zum konzept:
- wenn man eine lösung anbieten möchte die eine benutzung von alexa mit fhem über einen ganz normal für alle veröffentlichten skill erlaubt ist erst mal ganz abstakt (unabhängig von port forwading oder reverse proxy oder wie auch immer) zwingende voraussetzung das dieser eine skill auf irgend eine art die jeweilige fhem installation des nutzers erreichen kann.

hierzu ist es zwingend nötig das der eine skill bei der aktivierung durch irgend einen mechanismus die möglichkeit bekommt den anwender der diesen skill aktiviert mit seiner fhem installation bzw. mit einem weg diesem fhem kommandos zu senden in verbindung bringen kann.

dazu wird in einem ersten schritt bei dir privat ein token und ein key erzeugt den nur du kennst. bei der skill aktivierung wird dein account mit dem token verknüpft. das token wird bei amazon gespeichert. weder key noch token werden an einer anderen stelle gespeichert.

wenn amazon ein sprach kommando von einem echo erkennt und dem skill zuordnet wird ein event erzeugt das dieses token enthält.

anhand des tokens kann die zuordnung zu dir und der proxy verbindung getroffen werden die du aufgebaut hast. über diese verbindung bekommt dann dein lokales alexa-fhem das event.


- ein grundprinzip ist das niemals jemand direkt von aussen auf deinen rechner zugreift oder direkten zugriff auf dein fhem system hat. das ist einer der gründe warum alexa-fhem nicht direkt ein fhem modul ist sondern ein getrennter prozess.

- es werden zu keinem zeitpunkt kommandos von aussen (egal ob von amazon, vom skill oder vom proxy) direkt ausgeführt (von 'normalen' sicherheistlücken abgesehen gilt das nach besten gewissen auch für ein gehacktes proxy system). das einzige was von amazon über den proxy an deinen lokalen alexa-fhem NodeJs prozess  geschickt wird sind events, die eine aktion beschrieben die amazon einem sprach kommando zugeordnet hat. dieses event wird vom alexa-prozess in kommandos für fhem umgesetzt. d.h. erst hier in deiner lokalen installation und nur für fhem devices die du auch zur steuerung durch alexa freigegeben hast werden die kommandos zusammen gebaut.

- jedes event enthält zur authentisierung ein token das wären den installation lokal bei dir erzeugt wird und das nur du und amazon kennen. dieses token und auch der key der am anfang ein mal zur skill verknüpfung verwendet wird ist nirgends auf dem proxy server oder im skill oder in der lambda funktion gespeichert.

- alexa-fhem akzeptiert nur events von denen das token geprüft werden kann. im falle des proxy wird das token gegen das nur dir bekannte token geprüft.

- auch wenn ein event akzeptiert wird: es lassen sich nicht beliebige geräte steuern sondern nur die geräte die du freigeben hast. d.h. selbst wenn jemand es schaffen würde auf irgend einem weg ein gefakedes event für dein tüschloss ein zu schmuggeln kann er es nicht steuern wenn du das schloss nicht für alexa frei gegeben hast.

deine fragen 1 und 2 stimmen so weit.
deine frage 3 ist zumindest unglücklich formuliert.

ja. es ist nötig das nur du den key kennst und nur du und amazon das token.
ja. es ist nötig das du dem proxy server bzw. dem verein vertraust das tatsächlich keine daten gespeichert werden und das mit den temporär für den betrieb empfangen daten kein missbrauch getrieben wird.

wenn du das nicht kannst ist dieser skill nichts für dich und wenn du trotzdem einen echo mit fhem verwenden möchtest musst du wie bisher alles selber mit einem privaten skill und port forwading machen.

wenn du beides weitergibst hast du ein problem. das hast du aber mit jeder anderen art des cloud zugriffs auf wenn du deine zugangsdaten weitergibst.


zu deinen anderen punkten:

1. was meinst du mit 'wer zugreift' ?

die verbindung zwischen proxy tunnel und alexa-fhem nodejs prozess ist nur für localhost aktiv (siehe code oder netstat). d.h niemand ausser dem tunnel und einem anderen prozess auf deinem eigenen rechner kann events an dein alexa-fhem schicken. diese events müssen deine geheimes token enthalten damit sie verarbeitet werden.

szenarien:
- proxy server ist sicher
    -> die events sind immer zuzuordnen
- netzwerk verkehr wird belauscht/manipuliert
    -> das geht nicht. ssh ist mindestens so sicher wie https
- jemand biegt den proxy server auf einen anderen host um
    -> wenn der ssh key des servers nicht mehr passt wird der tunnel nicht aufgebaut. genau so wie bei https
- der proxy server wird gehackt
    -> ja. es gibt ein problem. das würde es im https fall aber genau so gelten.


2. ein ssh key ist genau so sicher wie ein https zertifikat. beiden liegen die gleichen verfahren zu grunde
    einziger unterschied: du entscheidest selber ob du einem key vertraust und überlässt das nicht einer
    zentralen instanz die nicht immer zuverlässig ist.

ja. ein ssh tunnel ist mindestens so sicher wie eine https gesicherte verbindung.



wenn du selber entscheiden willst: siehe oben. dir bleibt nur der private skill und selber tunnel oder proxy aufbauen.

aber achtung: du musst aufpassen verschlüsselung und authentifizierung (und hier noch mal client und server) durcheinander zu bringen. ssh und https sind erst mal nur verschlüsselung und authentifizierung des servers. nicht des clients.

wenn amazon ein event erkennt und dir schickt wird die verbindung von amazon aus aufgebaut. du bist der server. amazon kann erkennen das du 'echt' bist. du kannst aber nicht erkennen das amazon 'echt' ist. es wird kein client zertifikat verwendet.

du kannst die 'echtheit' nur am oauth token das amzon mit schickt feststellen. dieses ist aber keine signatur des events und gilt für eine stunde. d.h. wenn auf dem weg irgendetwas gehackt wird kann man mit dem einen event beliebig viele weiter erzeugen und senden. innerhalb der einen stunde.

bleibt nur die absender ip. das wird der vereins proxy auch noch tun. wenn du dem nicht vertraust bleibt nur selber machen.



der proxy ist nicht da um einen sicherheitsgewinn zu haben. sondern um allen die es nicht selber machen wollen eine lösung zu bieten, die so sicher wie möglich ist.

das ist unsicherer als alles selber zu machen. aber weniger weil die konzepte unsicher sind sondern weil es zum einen eine instanz mehr ist der man vertrauen muss und zum anderen ein zentraler server potentiell im angriffs- und fehlerfall auswirkungen auf mehr accounts hat als nur deinen eigenen.

womit wir wieder beim abwägen der drei faktoren vom anfang sind. du kannst nicht alle drei optimieren. höchstens zwei.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gvzdus

Da ich ja viel teste, hat sich der Routing-Key bei mir geändert....
12D182
ist aktuell. Ich würde gerne demnächst die Seite zwischen Lambda und Vereinsserver mit einem Secret schützen - besteht die Absicht, mal das Hacking meines Servers zu versuchen?

ThoTo

Zitat von: gvzdus am 13 Januar 2019, 20:38:01
Ich würde gerne demnächst die Seite zwischen Lambda und Vereinsserver mit einem Secret schützen - besteht die Absicht, mal das Hacking meines Servers zu versuchen?

Diese Idee hatte ich auch... Vielleicht lesen professionelle Pentester mit und würden ihre Dienste anbieten?
KNX | MQTT | Docker | Sonos | FHEMapp

"Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher." (Albert Einstein)

Loredo

#6
Ich verschiebe meinen Post aus dem Main Thread mal in diesen hier:






Ist geplant seitens des SSH Servers auch Ed25519 zu unterstützen?


Man könnte auch noch ein wenig was an den Server Einstellungen drehen:


ssh-audit -p 58824 fhem-va.fhem.de


# general
(gen) banner: SSH-2.0-APACHE-SSHD-2.1.1-SNAPSHOT
(gen) compatibility: OpenSSH 7.3+ (some functionality from 6.6), Dropbear SSH 2016.73+ (some functionality from 0.52)
(gen) compression: enabled (zlib, zlib@openssh.com)


# key exchange algorithms
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)
                                            `- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group-exchange-sha1    -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.3.0
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group17-sha512         -- [warn] unknown algorithm
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group15-sha512         -- [warn] unknown algorithm
(kex) diffie-hellman-group14-sha256         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group14-sha1           -- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 3.9, Dropbear SSH 0.53
(kex) diffie-hellman-group1-sha1            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [fail] disabled (in client) since OpenSSH 7.0, logjam attack
                                            `- [warn] using small 1024-bit modulus
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.28


# host-key algorithms
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28


# encryption algorithms (ciphers)
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) arcfour256                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using weak cipher
                                            `- [info] available since OpenSSH 4.2
(enc) arcfour128                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using weak cipher
                                            `- [info] available since OpenSSH 4.2
(enc) aes128-cbc                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher mode
                                            `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.28
(enc) 3des-cbc                              -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher
                                            `- [warn] using weak cipher mode
                                            `- [warn] using small 64-bit block size
                                            `- [info] available since OpenSSH 1.2.2, Dropbear SSH 0.28
(enc) blowfish-cbc                          -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [fail] disabled since Dropbear SSH 0.53
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using weak cipher mode
                                            `- [warn] using small 64-bit block size
                                            `- [info] available since OpenSSH 1.2.2, Dropbear SSH 0.28
(enc) aes192-cbc                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher mode
                                            `- [info] available since OpenSSH 2.3.0
(enc) aes256-cbc                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher mode
                                            `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.47


# message authentication code algorithms
(mac) hmac-md5                              -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
(mac) hmac-sha1                             -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1-96                          -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.47
(mac) hmac-md5-96                           -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.5.0


# algorithm recommendations (for OpenSSH 7.3)
(rec) -diffie-hellman-group14-sha1          -- kex algorithm to remove
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha256 -- kex algorithm to remove
(rec) -diffie-hellman-group1-sha1           -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha1   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) +curve25519-sha256@libssh.org         -- kex algorithm to append
(rec) +ssh-ed25519                          -- key algorithm to append
(rec) +rsa-sha2-256                         -- key algorithm to append
(rec) +rsa-sha2-512                         -- key algorithm to append
(rec) -blowfish-cbc                         -- enc algorithm to remove
(rec) -3des-cbc                             -- enc algorithm to remove
(rec) -aes256-cbc                           -- enc algorithm to remove
(rec) -arcfour256                           -- enc algorithm to remove
(rec) -aes192-cbc                           -- enc algorithm to remove
(rec) -arcfour128                           -- enc algorithm to remove
(rec) -aes128-cbc                           -- enc algorithm to remove
(rec) +aes128-gcm@openssh.com               -- enc algorithm to append
(rec) +chacha20-poly1305@openssh.com        -- enc algorithm to append
(rec) +aes256-gcm@openssh.com               -- enc algorithm to append
(rec) -hmac-sha2-512                        -- mac algorithm to remove
(rec) -hmac-md5-96                          -- mac algorithm to remove
(rec) -hmac-sha2-256                        -- mac algorithm to remove
(rec) -hmac-sha1-96                         -- mac algorithm to remove
(rec) -hmac-md5                             -- mac algorithm to remove
(rec) -hmac-sha1                            -- mac algorithm to remove
(rec) +hmac-sha2-256-etm@openssh.com        -- mac algorithm to append
(rec) +hmac-sha2-512-etm@openssh.com        -- mac algorithm to append
(rec) +umac-128-etm@openssh.com             -- mac algorithm to append



Den SSH Server zu härten ist da kein großer Aufwand, muss man eben halt nur machen.




Für den TLS HTTP Dienst gäbe es auch noch ein wenig zu tun:
https://www.ssllabs.com/ssltest/analyze.html?d=va.fhem.de&s=88.99.31.202&hideResults=on&latest
- TLS 1.0 und 1.1 ausschalten; Bonus: Aktivierung von TLS 1.3
- Umstellung auf LetsEncrypt EC Zertifikat (oder zumindest Wechsel von RSA 2048 auf 4096 Bit Schlüssel)
- Aktivierung von OCSP Stapling
- Abgleich der Settings mit Mozilla TLS Modern compatibility Empfehlungen




Der Form halber verweise ich auch noch auf den SecurityHeaders Report mit dem aktuellen Ergebnis "F" (betrifft eher Client-Server-Kommunikation Vereinsserver<>Alexa):
https://securityheaders.com/?q=va.fhem.de%2Falexa&hide=on&followRedirects=on


Wenn Hilfe beim härten der Serverdienste und der Client-Server-Kommunikation gewünscht ist, meldet euch gerne per PN.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Hi Loredo,

danke, lass mal hier weiter diskutieren.

Zu den SSH-Protokollen: Da ist mir jeder Ratschlag sehr willkommen. In der Tat wird derzeit vorzugsweise ein klassisches RSA-Paar ausgehandelt - das habe ich gewählt, weil ich mir davon die höchste Kompatibilität mit dem Client, auf dem alexa-fhem läuft, verspreche. Wenn Du mir Ratschläge zusammenstellen magst: "Versuch es doch der Reihe nach so, siehe der Artikel" ist das willkommene Mitarbeit!

Zu TLS: Fände ich gut, müsste aber Rudi König machen, denn der ist das "Gate". Das Abschalten der Alt-Protokolle TLSv1 & TLSv1.1 als Empfehlung kenne ich, setze es aber bei "meinen" Webservern nicht um, weil es Androids bis Lollipop ausschließt (Android bis inkl. 4.4).

Die Header-Thematik finde ich etwas übertrieben: Für die Kommunikation Lambda<=>Verein reden wir einem HTTPS-Client (nodejs), der interessiert sich nicht für Browser-Header, egal ob HSTS, CSP, Frames o.ä.

Für den Nutzer, der von Amazon "rübergeschickt" wird:
Für den "Connect" / Skillverknüpfung: Ich halte mir zugute, beim verweisenden Link auf der Check-Seite das "No-Referer"-Attribut gesetzt zu haben :-)
Bei der Registrierungsseite denke ich, dass die Frame-Header und CSP-Header Sinn ergeben.

Wie eingangs erwähnt:
Vor allem würden mich Empfehlungen für eine Reihenfolge des SSH-Key-Generierens interessieren, bzw. ein Link zu einem guten Artikel dazu.

Loredo

#8
Zitat von: gvzdus am 12 Januar 2019, 11:50:23
P.S. In der Tat will ich das Kommando im IP-Range auf bekannte Amazon-IPs beschränken.
Ich hatte aber genau darauf gehofft, dass jemand die Frage stellt!

Die Idee ist gut, aber es ist nicht ganz trivial betriebssicher umzusetzen. Da sich in den Wolken häufig so viel ändert, kann man sich nicht darauf verlassen, dass die IP Ranges lange bestand haben. Das manuell nachzuverfolgen ist oft aufwändig und fehleranfällig. Azure bietet eine API zur Abfrage aller IP Ranges und URLs an, mit denen man seine Firewalls etc. automatisch mit den gültigen IP Ranges versorgen kann.
Ob es sowas bei AWS gibt, kann ich nicht sagen, aber es lohnt ggf. mal zu googlen.

Zitat von: gvzdus am 14 Januar 2019, 18:06:54
Zu den SSH-Protokollen: Da ist mir jeder Ratschlag sehr willkommen. In der Tat wird derzeit vorzugsweise ein klassisches RSA-Paar ausgehandelt - das habe ich gewählt, weil ich mir davon die höchste Kompatibilität mit dem Client, auf dem alexa-fhem läuft, verspreche. Wenn Du mir Ratschläge zusammenstellen magst: "Versuch es doch der Reihe nach so, siehe der Artikel" ist das willkommene Mitarbeit!

Im Grunde bist du da auf Server Seite absolut flexibel. Es müssen eigentlich nur 2 Verbindungsarten unterstützt werden: Ed25519 und als Fallback RSA mit einem 4096 Bit Schlüssel, DSA und auch ECDSA sollten ausgeschlossen werden.
Ich habe gesehen, dass Apache SSHd verwendet wird, daher kann ich dir nicht genau sagen, wie man den damit füttert. Mit dem OpenSSH Server kann ich dir folgendes Script aus meiner eigenen Host Configuration liefern:


# Harden SSH server settings
rm -rf /etc/ssh/ssh_host_dsa*
rm -rf /etc/ssh/ssh_host_ecdsa*
if [[ ! -f /etc/ssh/ssh_host_rsa_key || $(ssh-keygen -lf /etc/ssh/ssh_host_rsa_key | cut -d " " -f 1) -lt 4096 ]]; then
  rm -f /etc/ssh/ssh_host_rsa*
  ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" -o -a 100
fi
if [[ ! -f /etc/ssh/ssh_host_ed25519_key || $(ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key | cut -d " " -f 1) -lt 256 ]]; then
  rm -f /etc/ssh/ssh_host_ed25519*
  ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" -o -a 100
fi
if [ -f /etc/ssh/moduli ]; then
  awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.safe
  mv -f /etc/ssh/moduli.safe /etc/ssh/moduli
fi
if [ ! -f /etc/ssh/sshd_config.bak ]; then
  mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
echo "Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

StrictModes yes
PasswordAuthentication no
#PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
PrintMotd no
PermitRootLogin without-password
AcceptEnv LANG LC_*
Subsystem   sftp   /usr/lib/openssh/sftp-server

# Crypto hardening
#
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
HostKeyAlgorithms ssh-ed25519,ssh-rsa
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

# Disable all forwarding methods
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
AllowAgentForwarding no
X11Forwarding no" > /etc/ssh/sshd_config
fi
systemctl restart ssh


Wenn du dazu eine spezielle Doku brauchst, müsste ich googeln. Ansonsten ist "man ssh-keygen" und "man sshd_config" aber sehr hilfreich die Parameter zu entschlüsseln.




Den SSH Client Key generierst du ja für den Fall, dass der User noch keinen hat.
Das habe ich vor einiger Zeit schonmal in das FHEM Docker Image eingebaut, weshalb du dort spicken könntest:
https://github.com/fhem/fhem-docker/blob/2eeead5012188d802257136e6d77c1356aa826bb/src/entry.sh#L85-L122

Das SSH Key Pinning macht aber nur für das Image Sinn (und müsste ich auch aktualisieren, wenn du neue Server Keys generierst  ;) ). Ist auch nur dafür da, dass beim ersten Verbindungsaufbau sich auch niemand dazwischen hängen kann. Für den SSH Client ist "StrictModes yes" recht wichtig. Damit einige Optionen immer zur Anwendung kommen und du dem User das in der ~/.ssh/config nicht vorgeben kannst (man weiß ja nicht, was er noch für Verbindungen aufbauen will), solltest du diese Optionen beim Verbindungsaufbau mittels "-o" direkt mit übergeben (siehe "man ssh").

Zitat von: gvzdus am 14 Januar 2019, 18:06:54
Zu TLS: Fände ich gut, müsste aber Rudi König machen, denn der ist das "Gate". Das Abschalten der Alt-Protokolle TLSv1 & TLSv1.1 als Empfehlung kenne ich, setze es aber bei "meinen" Webservern nicht um, weil es Androids bis Lollipop ausschließt (Android bis inkl. 4.4).

Hatte ich bei der Umstellung auf den Vereinsserver schon erwähnt, wurde aber dann wohl nicht weiter beachtet. Ich kenne auch das genaue Setup von Markus nicht - möglich, dass man dabei auch das Setup aller anderen Vereinsseiten inkl. des Forum mit berücksichtigen müsste (bzw. ggf. entkoppeln mittels Offloading o.ä.). Ich will aber nicht ausschließen, dass Markus das eh auf seiner wohl eher laaaangen Todo Liste hat.
Zu Android 4.4 muss man IMHO nicht Rückwärts kompatibel sein - da wäre ich streng und würde sagen "da muss eh ein aktuelleres Gerät her" (wobei Android seine Aktualitäts- und Sicherheitsprobleme ohnehin nicht im Griff hat, aber das ist eine ganz andere Debatte  ;D ).

Zitat von: gvzdus am 14 Januar 2019, 18:06:54
Die Header-Thematik finde ich etwas übertrieben

War ja auch eher der Vollständigkeit halber. Der Nutzen bei Maschinen-Kommunikation ist auch nicht bei allem ganz so hoch wie bei manuellen Zugriffen.
Für die Registrierungsseite kann ich nochmal schauen und einen Vorschlag machen. Wenn du selbst schauen möchtest: Diesen Generator nutze ich gerne. HSTS kann man setzen, aber da man ohnehin über den Redirect dorthin gelangt ist das eher unwichtig.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatHatte ich bei der Umstellung auf den Vereinsserver schon erwähnt, wurde aber dann wohl nicht weiter beachtet.
"Nicht beachtet" ist nicht ganz richtig.
"Nach Kosten/Nutzen Analyze auf spaeter verschoben" trifft es eher.

Loredo

Wenn man keine weitere Rückmeldung erhält, dann lässt sich das leider nur schwer unterscheiden, Rudi.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Danke, ich setze zumindest EC statt RSA ganz hoch auf die Prio-Liste mit Commitment < 7 Tage.

Loredo

Ein solches Commitment ist jetzt übertrieben, aber schön, dass du eine Rückmeldung dazu gibst,, vielen Dank!  :)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Ich habe es mal auf die Schnelle probiert, und so ganz unverändert klappt es nicht, sich per Hand einen Ec25519-Key zu konfigurieren und dann zum Server zu gehen.

Der Grund ist hier zu finden:
https://github.com/apache/mina-sshd/blob/master/README.md

Sprich, ich muss noch weitere Module einbinden, was ich dann natürlich erst mal testen muss.

Loredo

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER