Weak algorithm supported

Help!
1

Hi ,

I am new to haproxy i installed it and configure to run it in port 2222 .

after that security scan was done by the org and i got port 2222 is using weak algorithms like below . The scan report is these type weak algorithm are supported or enable in port 2222.

can any one help me to resolve these issue .

The following weak key exchange algorithms are enabled :

diffie-hellman-group-exchange-sha1
diffie-hellman-group1-sha1

The following client-to-server SHA-1 Hash-based Message Authentication Code (HMAC) algorithms are supported :

hmac-sha1
hmac-sha1-etm@openssh.com

OS using ubuntu 18.04
haproxy version 1.8.8

my configuration is like bellow :-

======================================================
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon

# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private

# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
#  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
#  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
#ECDH+AES256:DH+AES256:ECDH+AES128
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

defaults
log global
mode tcp
option tcplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

backend haproxy_scp
balance first
server fs1 someip:22 check
server fs2 anotherip:22 check

frontend haproxy_in
bind *:2222
mode tcp
log-format "%ci:%cp [%t] %ft %b/%s %Tw/%Tc/%Tt %B %ts %ac/%fc/%bc/%sc/%rc %sq/%bq dst:%[var(sess.dst)] "
tcp-request content set-var(sess.dst) ssl_fc_sni
default_backend haproxy_scp

frontend stats
bind *:80
mode http
stats enable
stats hide-version
stats refresh 30s
stats show-node
stats auth admin:password
stats uri /haproxy?stats

======================================================

2

You should follow one or both of these links. The first explains hardening with stronger ciphers. The second actually provides the parameters you can put directly into your config and options on if you want more modern support, intermediate (or general-purpose), or old (do not use this one).

3

No, you are TCP tunneling SSH traffic, none of this has anything to do with the TLS ciphers used in haproxy for TLS termination.

If you want to remove weak SSH key exchange ciphers you need to do that on the backend SSH server.

FWIW, things like ssl_fc_sni will never work, because TLS/SSL and SSH are not the same thing.

4

Do you want me to remove that ssl_fc_sni and try .

5

i configured backend sshd_configure file under /etc/ssh/ location in server with required ciphers .

but those are only Appling to port 22 where ssh is running .

But here haproxy is using 2222 port it adding weak algorithms .

when i do ssh -vvv i can not see those algorithms and i can see it is working port 22 in log

But when i do ssh -vvv -p 2222 ip 0r hostname here
it is giving the weak algorithms(diffie-hellman-group-exchange-sha1) in log .

6

No, it is not. Haproxy does not implement the SSH protocol.

You need to update the SSH configuration in your backend servers:

server fs1 someip:22 check
server fs2 anotherip:22 check
7

Yes , i did that please check below my config file . also restarted the sshd service .

still where accessing using ssh -vvv -p 2222 ipaddress

i still see in kexalgorithm there is weak ciphers

MicrosoftTeams-image (2)
MicrosoftTeams-image (2)1920×694 70.1 KB

================================================================
root@zrdm61ecsmr01cmr001:/etc/ssh# cat sshd_config

$OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

This is the sshd server system-wide configuration file. See

sshd_config(5) for more information.

This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

The strategy used for options in the default sshd_config shipped with

OpenSSH is to specify options with their default value where

possible, but leave them commented. Uncommented options override the

default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

Ciphers and keying

#RekeyLimit default none

Logging

SyslogFacility AUTHPRIV
#LogLevel INFO

Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

Expect .ssh/authorized_keys2 to be disregarded by default in future.

#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

Change to yes if you don’t trust ~/.ssh/known_hosts for

HostbasedAuthentication

#IgnoreUserKnownHosts no

Don’t read the user’s ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

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

#PasswordAuthentication yes
#PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Kerberos options

#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange 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. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

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 yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

no default banner path

Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

override default of no subsystems

Subsystem sftp /usr/lib/openssh/sftp-server

Example of overriding settings on a per-user basis

#Match User anoncvs

X11Forwarding no

AllowTcpForwarding no

PermitTTY no

ForceCommand cvs server

MACs hmac-sha2-256,hmac-sha2-512,umac-128@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256

root@zrdm61ecsmr01cmr001:/etc/ssh#

================================================================

8

Are you sure? According to HAProxy’s documentation: ssl-default-bind-ciphers

sets the default string describing the list of cipher algorithms (“cipher suite”) that are negotiated during the TLSv1.3 handshake for all “bind” lines which do not explicitly define theirs.

I read this as any bind line that doesn’t define some sort of cipher will use defaults. Even with TCP Passthrough, I imagine HAProxy has to do some sort of TCP Handshaking to accept the connection to pass it through… or am I understanding this incorrectly?

9

Yes it need to

10

You are understanding this incorrectly.

SSH is not SSL/TLS just like TCP is not SSL/TLS. A TCP handshake is not a TLS handshake.

11

Ok , i got you then How can i resolve this . what i need to configure in haproxy conf file

12

There is nothing to be done in the haproxy configuration file, like I told you.

Everything is in the ssh daemon configuration on your servers. If this doesn’t work you are either configuring them wrong, you are not on the correct box, or you are testing it wrong, I can’t possibly tell you which one it is.

You have multiple backend server, are you sure you updated all of them?

13

Gah! Sure enough, TCP happens on Layer 4. TLS happens on Layer 6. SSH and HTTP are Layer 7. Thanks for the clarification!

@kiran608 There is no additional configuration to be done in HAProxy. You are seeing weak ciphers because your SSH server(s) is presenting them. Did you restart the sshd service after making changes? Is your testing suite caching results?

14

Yes those are all up to date . And what do you mean by testing .

as i told earlier i am using this command
ssh -vvv -i kk855k.pem -p 2222 kk855k@166.193.164.191

in command -vvv will give some log we can what ciphers it is using .

that is the screen shot i have added in above reply .

If you think this is the wrong way of testing or not proper way please let me know how to test it .

Coming to ssh daemon in the server it is configured with kex algorithm . MACs , ciphers .

when we do normal ssh with port 22 i am not seeing weak ciphers. Also security scan tool not reporting this port . it is ony reporting 2222 port that where haproxy is running .
Then how it is related to ssh daemon configuration .

15

yes did bro , whatever configuration we done in sshd , it is perfectly reflecting to port 22 ,

but it is not reflecting on port 2222 where haproxy is running .

16

Like I said, it’s impossible for me to tell you what exactly is going wrong here. The only thing I can tell you is that haproxy connects one TCP connection with another one in this configuration. It is not technically possible to downgrade or introduce new SSH key exchange alghoritms in haproxy because haproxy doesn’t implement SSH.