Wo persistentes "SSH-hardening" konfigurieren ?

[Wayne Train]

Hi,

wo tweake ich am besten die SSH-Settings der OPNsense, sodass sie bei Updates nicht überschrieben werden ?

In dieser Datei ?

/usr/local/etc/ssh/sshd_config

Oder gibt es doch noch was in der GUI, was ich übersehen habe ?

Ich frage, weil zum Teil suboptimale MACs und Kex genutzt werden...

MFG Wayne

[franco]

Hi Wayne,

Warum nicht hier: https://github.com/opnsense/core/issues/new/choose 


Grüsse
Franco

[Wayne Train]

Hi Franco,
ich bin leider nicht bei Github.
Anbei die Liste:

Code: [Select]

# key exchange algorithms
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)
(kex) diffie-hellman-group14-sha1           -- [warn] using weak hashing algorithm


# host-key algorithms
(key) ecdsa-sha2-nistp256                   -- [fail] using weak elliptic curves
                                            `- [warn] using weak random number generator could reveal the key


# message authentication code algorithms
(mac) umac-64-etm@openssh.com               -- [warn] using small 64-bit tag size
(mac) hmac-sha1-etm@openssh.com             -- [warn] using weak hashing algorithm
(mac) umac-64@openssh.com                   -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using small 64-bit tag size
(mac) umac-128@openssh.com                  -- [warn] using encrypt-and-MAC mode
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
(mac) hmac-sha1                             -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm


# algorithm recommendations (for OpenSSH 7.9)
(rec) -diffie-hellman-group14-sha1          -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha256 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove
(rec) -hmac-sha1                            -- mac algorithm to remove
(rec) -hmac-sha2-256                        -- mac algorithm to remove
(rec) -hmac-sha2-512                        -- mac algorithm to remove
(rec) -umac-64@openssh.com                  -- mac algorithm to remove
(rec) -umac-128@openssh.com                 -- mac algorithm to remove
(rec) -hmac-sha1-etm@openssh.com            -- mac algorithm to remove
(rec) -umac-64-etm@openssh.com              -- mac algorithm to remove
MFG
Wayne

[JeGr]

Das möchtest du einbauen oder das wird akzeptiert und soll raus oder was soll deine Liste aussagen, Wayne? Hast du schon geprüft, was die Sense überhaupt "akzeptiert"?

[Wayne Train]

Hi JeGr,

das ist der Output eines Audit-Scans und der zugehörigen warnings / alerts / recommendations. Du kannst auch gerne selbst mal scannen. Nmap listet dir auch alles, was die OPN anbietet:

Code: [Select]

nmap -p 22 -sS --script ssh2-enum-algos.nse $IP_DEINER_OPNSENSE
Ich habe nur die gelistet, die kritisch sind, bzw. besser unterbunden werden.

Wenn du so fragst, wäre es natürlich wünschenswert, wenn man die Crypto an sich für SSH so wie für die Web-GUI tweaken könnte.

MFG Wayne

[JeGr]

Danke, wollte nur wissen, ob das Live gegen die aktuellste Version getestet war. Bin da sogar durch Messung im Lab etwas ernüchtert worden :/

OPNsense Stable

Code: [Select]

22/tcp open  ssh
| ssh2-enum-algos:
|   kex_algorithms: (10)
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|       diffie-hellman-group14-sha256
|       diffie-hellman-group14-sha1
|   server_host_key_algorithms: (5)
|       rsa-sha2-512
|       rsa-sha2-256
|       ssh-rsa
|       ecdsa-sha2-nistp256
|       ssh-ed25519
|   encryption_algorithms: (6)
|       chacha20-poly1305@openssh.com
|       aes128-ctr
|       aes192-ctr
|       aes256-ctr
|       aes128-gcm@openssh.com
|       aes256-gcm@openssh.com
|   mac_algorithms: (10)
|       umac-64-etm@openssh.com
|       umac-128-etm@openssh.com
|       hmac-sha2-256-etm@openssh.com
|       hmac-sha2-512-etm@openssh.com
|       hmac-sha1-etm@openssh.com
|       umac-64@openssh.com
|       umac-128@openssh.com
|       hmac-sha2-256
|       hmac-sha2-512
|       hmac-sha1
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com


OPNsense Devel

Code: [Select]

identisch siehe Stable


pfSense Stable

Code: [Select]

22/tcp open  ssh                                 
| ssh2-enum-algos:                               
|   kex_algorithms: (2)                         
|       curve25519-sha256@libssh.org             
|       diffie-hellman-group-exchange-sha256     
|   server_host_key_algorithms: (4)             
|       ssh-rsa                                 
|       rsa-sha2-512                             
|       rsa-sha2-256                             
|       ssh-ed25519                             
|   encryption_algorithms: (6)                   
|       chacha20-poly1305@openssh.com           
|       aes256-gcm@openssh.com                   
|       aes128-gcm@openssh.com                   
|       aes256-ctr                               
|       aes192-ctr                               
|       aes128-ctr                               
|   mac_algorithms: (8)                         
|       hmac-sha2-512-etm@openssh.com           
|       hmac-sha2-256-etm@openssh.com           
|       hmac-ripemd160-etm@openssh.com           
|       umac-128-etm@openssh.com                 
|       hmac-sha2-512                           
|       hmac-sha2-256                           
|       hmac-ripemd160                           
|       umac-128@openssh.com                     
|   compression_algorithms: (2)                 
|       none                                     
|_      zlib@openssh.com                         

und noch weiter eingeschränkt

pfSense Devel (2.5 upcoming)

Code: [Select]

22/tcp open  ssh                           
| ssh2-enum-algos:                         
|   kex_algorithms: (2)                     
|       curve25519-sha256@libssh.org       
|       diffie-hellman-group-exchange-sha256
|   server_host_key_algorithms: (4)         
|       rsa-sha2-512                       
|       rsa-sha2-256                       
|       ssh-rsa                             
|       ssh-ed25519                         
|   encryption_algorithms: (6)             
|       chacha20-poly1305@openssh.com       
|       aes256-gcm@openssh.com             
|       aes128-gcm@openssh.com             
|       aes256-ctr                         
|       aes192-ctr                         
|       aes128-ctr                         
|   mac_algorithms: (6)                     
|       hmac-sha2-512-etm@openssh.com       
|       hmac-sha2-256-etm@openssh.com       
|       umac-128-etm@openssh.com           
|       hmac-sha2-512                       
|       hmac-sha2-256                       
|       umac-128@openssh.com               
|   compression_algorithms: (2)             
|       none                               
|_      zlib@openssh.com                   


Ich denke, da sollte man sich ggf. an die Settings der aktuellen Devel anpassen, die da definitiv besser aufgestellt ist. Selbst unsere default Linux Hosts haben anscheinend eine stärkere SSH Konfiguration als die Default OPNsense, was mich etwas "irritiert" hat. Hat da auch Hardened BSD keine besseren Defaults für den OpenSSH-Server?

Allerdings @Wayne den:

(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)

würde ich als "vielleicht" drinlassen. Mir persönlich wäre curve25519 auch lieber, aber er ist der letzte KEX, der noch "abwärtskompatibel" mit älteren Clients etc. ist. Klar sollte man die aktualisieren, gerade bei Zugriffen auf Firewalls, aber es gibt ja doch einige, die sich da Dinge gebastelt und automatisiert haben, deren Clients ggf. älter sind und mit halbwegs vernünftig ausgewürfelten Moduli sollte der noch ganz OK sein.

Bei den MACs ähnlich. Klar ist das dann total gut und sicher auf OpenSSH 7.9+ eingestellt, bringt nur nichts, wenn man Clients hat die sich dann nicht mehr verbinden können.

Aber mit besseren Defaults UND manueller Möglichkeit diverse Cipher/Algos abzuwählen nach eigenem Gusto, wäre das natürlich der beste Zwischenweg.

[Wayne Train]

:-) Genau.

ich war auch etwas von den Socken, weil ich eigentlich dachte, dass das bei einer FW eher selten vorkommt. Außer bei Cisco ;-)...
Vorerst werde ich das wohl erstmal hart in die Config des Systems tackern.

LG

[fabian]

man muss hier halt auch aufpassen und mit vielen clients testen:

net/ssh (ruby)
openssh
jsch (java)
paramiko (python)
putty (wird gerne unter Windows verwendet)
...

Das Problem ist, dass hier sehr viel Automatisierung kaputt gehen kann und man daher nicht zu viel abdrehen kann. Bei den oberen zwei würde ich mir keine Sorgen machen. Die anderen kenne ich zu wenig aber Curve 25519 ist ziemlich sicher noch nicht durchgehend verfügbar.

[JeGr]

> Das Problem ist, dass hier sehr viel Automatisierung kaputt gehen kann und man daher nicht zu viel abdrehen kann.

Genau was ich sage. Gerade Java Clients sind notorisch dafür uralte Standards mit sich rumzuschleppen und Fremdlibraries sind da auch nicht immer so gern auf der Höhe der Zeit.

Putty und Co sind aber unter Windows aktuell. Paramiko hat IMHO sogar erst im Juni diesen Jahres was über ed25519 gelernt (*seufz*). Jsch würde ich in hohem Bogen zum Fenster raustreten weil Alteisen - 5 Jahre nach ED25519 Einführung unterstützen die immer noch ein Set an Cipher, Algos und MACs das zum Davonlaufen ist.

Aber ja, es ist "schwierig" da gebe ich Fabian gern recht, die Frage ist nur, muss sich ein Security Produkt / Firewall Gateway nach der Software richten oder muss die Software mit den Anforderungen klarkommen? Solange keiner die Werte anzieht wird auch niemand updaten - ist zumindest unsere Erfahrung. Erst nachdem wir bspw. beim Hosting die Schrauben zugedreht haben was OpenSSH, OpenSSL, Webserver TLS, SFTP statt FTP/FTPS zugedreht haben, kam überhaupt mal Bewegung rein.

"Mimimi mein Mac kann sich nicht mehr verbinden!" - "Und was benutzen Sie?" - "Tool X" -> Suche nach Tool X, unterstützt seit einem Jahr mit Update neuere SSH Parameter... "Und schonmal geupdated?" "Nö mussten wir nie..."

Just sayin'

[fabian]

Genau was ich sage. Gerade Java Clients sind notorisch dafür uralte Standards mit sich rumzuschleppen und Fremdlibraries sind da auch nicht immer so gern auf der Höhe der Zeit.

Putty und Co sind aber unter Windows aktuell. Paramiko hat IMHO sogar erst im Juni diesen Jahres was über ed25519 gelernt (*seufz*). Jsch würde ich in hohem Bogen zum Fenster raustreten weil Alteisen - 5 Jahre nach ED25519 Einführung unterstützen die immer noch ein Set an Cipher, Algos und MACs das zum Davonlaufen ist.

Und das ist in den IDEs von JetBrains verbaut. Damit können zum Beispiel die Plugins direkt aus der IDE installiert werden.Gut, das reicht wenn des auf der Entwicklerversion geht.

Aber ja, es ist "schwierig" da gebe ich Fabian gern recht, die Frage ist nur, muss sich ein Security Produkt / Firewall Gateway nach der Software richten oder muss die Software mit den Anforderungen klarkommen?

Wenn der Client mit A geht und mit B nicht, dann wird der User B den schwarzen Peter zuschieben, weil A geht ja - auch wenn der Client das Problem hat.

Solange keiner die Werte anzieht wird auch niemand updaten - ist zumindest unsere Erfahrung. Erst nachdem wir bspw. beim Hosting die Schrauben zugedreht haben was OpenSSH, OpenSSL, Webserver TLS, SFTP statt FTP/FTPS zugedreht haben, kam überhaupt mal Bewegung rein.

Das glaub ich dir gerne. Wenn man bedenkt was da noch alles draußen ist, nur weil es noch "supported" ist, könnte man weinen. Die Supportzeiträume sind dazu da, dass man genug Zeit zur Migration hat und nicht um keine Updates zu machen.

[JeGr]

> Und das ist in den IDEs von JetBrains verbaut. Damit können zum Beispiel die Plugins direkt aus der IDE installiert werden.Gut, das reicht wenn des auf der Entwicklerversion geht.

Leider. Ich weiß :/

> Das glaub ich dir gerne. Wenn man bedenkt was da noch alles draußen ist, nur weil es noch "supported" ist, könnte man weinen.

Schau nur mal Richtung VPN bei IPSec: Zum Heulen was man da teils für Verbindungsprofile bekommt, 2019 noch mit 3DES und MD5...

> Wenn der Client mit A geht und mit B nicht, dann wird der User B den schwarzen Peter zuschieben, weil A geht ja - auch wenn der Client das Problem hat.

Vereinfacht ausgedrückt vielleicht, ja. Der gleiche User wird aber genauso A dafür zerreißen, wenn bspw. dann eine Sicherheitslücke auftritt, die man hätte mit den Voreinstellungen von B verhindern können. Wie mans macht... und wie gesagt, wenn das bekannt ist/angekündigt ist UND entsprechend dokumentiert(!) dann meckert bei einem spezifischen Produkt wie einer Firewall kaum jemand. Zumindest kein Firmenkunde oder Prosumer würde da nach 3s Nachdenken noch meckern dass er seinen Client updaten musste weil der noch urzeitliche Standards beherrscht hat