Showing posts with label CISCO IOS. Show all posts
Showing posts with label CISCO IOS. Show all posts

Sunday, June 21, 2020

Disable Weak SSH/SSL Ciphers in Cisco IOS

For backward compatibility, most companies still ship deprecated, weak SSH, and SSL ciphers. Cisco is no exception. For the security of your network and to pass a penetration test you need to disable the weak ciphers, disable SSH v1 and disable TLS versions 1.0 and 1.1.

Firefox, Chrome and Microsoft all have committed to dropping support for TLS1.1. Firefox had actually done it in May 2020 but so many US Government sites quit working (during the Covid19 Hysteria) that they rolled back. Microsoft has set July 2020 to remove TLS 1.0/1.1 from IE, Edge Legacy, and Edge Chromium.

This blog covers Cisco IOS software. I plan to do another blog on IOS-XE and Nexus in the future.

Cisco has this document listing the Next Generation Encryption that is supported. 

For IOS-XE, this document has a lot of detail. Search for "ip ssh"

SSH

Network device manufacturers (all of them I think) enabling SSH v1 by default really bothers me. Most Windows users connect with Putty which supports SSH v2. You should set Putty to default to SSH V2:




MAC/Linux users will be using OpenSSh which also supports SSH V2. You may run into situations on MAC/Linux where the weak ciphers are used and OpenSSH won't connect.

You will see a message similar to
ssh mhubbard@10.20.1.7
Unable to negotiate with 10.20.1.7 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
 
This is easy to resolve:

1. Open the SSH config file - gedit ~/.ssh/config
2. Add the necessary host IP and ciphers. KEX is Key Exchange:
        host 10.20.1.7
              KexAlgorithms +diffie-hellman-group1-sha1
              Ciphers 3des-cbc

On a really old switch, I ran into a host key exchange algorithm that I had never even heard of "ssh-dss". I had to add HostKeyAlgorithms=+ssh-dss to connect.

If you will only log into this device once or twice you can use the following without modifying the SSH config file:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 10.20.1.7
You can use the "-G" switch and SSH will show you the ciphers that SSH is offering:
ssh -G mhubbard@10.20.1.7


The OpenSSH site has a page dedicated to legacy ciphers
openssh legacy ciphers

Removing weak SSH algorithms


All of the commands shown are from a 2960x running:
Version 15.2(4)E8 - Mainstream deployment (MD) from 18-Mar-2019

First, let's look at the default SSH setup
show ip ssh
SSH Enabled - version 1.99
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbcc
MAC Algorithms:hmac-sha1,hmac-sha1-96
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): TP-self-signed-1676064512
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCjsPhP/zpPgra0d3wzzt8fDZnKL4sUtCh0DVmV0fH6
m+/Xke7IRMvxg2OEk333uHlKD+Ww6w8D2eMOzY7/R6edHA4UtKXwohJN1OZKS1ltL4tDSZSIeLO3juOL
GfxKBtvGd30Y2jzYYMmTQGP9u1VrKdQRKAU13/c+iOiQPi3Q4w==          

The "version 1.99" means that it supports SSH v1 and v2. We want to disable v1 and remove the cbc and 3Des ciphers. These are "Cipher Block Chain" algorithms and will cause a failure during a penetration test.

From global configuration mode enter the following:
ip ssh version 2 !disable V1

ip ssh server algorithm encryption aes256-ctr aes128-ctr

ip ssh server algorithm mac hmac-sha1

no ip ssh server algorithm mac hmac-sha1-96

You should also perform the following to harden SSH

crypto key generate rsa modulus 4096 label SSH-KEYS

!Note that generating 4096 bit keys can take up to 3 minutes.

ip ssh rsa keypair-name SSH-KEYS !associate keys to SSH

!set minimum bit size for client connection                                

ip ssh dh min size 2048


Let's see what SSH looks like now:
show ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
ip ssh server algorithm encryption aes256-ctr aes128-ctr
MAC Algorithms:hmac-sha1
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): SSH-KEYS
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC5KQxmPn8tyfK+9fq6NC75whEQD02POopz9SE/SKeP
ibO8KM7kSVdwy7anUhmgiX5jGmpecTFoP+txdA+KuEszAL5x8aeNZsPAykqBU6JClIz3fnMKjgoIqFlZ
mwhL0Qow4OGrd52EkRNRxAc2TYpBr5p0ICdaxeHd7etzgXjkwcZpQ1e2kqvV9XU94LBO1R93AgYYLCsT
nFsKga4tvvikXqKuwe3tfWKzNfO4LY1mZE9FXecoNW0Kb8p4U/pO/w69oEbHmmH7BfgWSHCCVZlgBhcf
DtJa+oVnqHrMwVza+ViTMQLghvt63zewvTN2I235K6W+GhgUmx6p+Q62Rsrfrc+4K5ECVKNf7fzmlg6X
Zs+P3WKgP8rh2z7ObTT917pp1VXw4pUkeqCCtMEmkiICO0TzU1dXyuoEPNGeES8wxYOSdaMA0DGEL34p
Ccb6hb1RQbHjSjQZfDOXaZ0UwXtVJ07v7PR7fOhFHem58w2P+qmCwnEYFZrZhizR1y1SUDxs6Z7vZV98
cyoTo98dWG4WDGiHM1loLq3SA3OMfceq5g2waPVBNmpZlzXitCTern1bZ15zdLvhxY1589A/TaSZuMeP
lhjQ1mlYp3qf0Jt7eoaWNPRV/i0VUaRfxNBefiNBI5pS8ybj3bhfWpZe8QOOMAHRahAPPI9PasOBuMHR

In 2020, this is still pretty lame, but keep reading! Cisco has been adding newer ciphers and removing some deprecated ciphers in newer IOS versions. You can check what's available on your version using:

test(config)#ip ssh server algorithm encryption ?
  3des-cbc    Three-key 3DES in CBC mode
  aes128-cbc  AES with 128-bit key in CBC mode
  aes128-ctr  AES with 128-bit key in CTR mode
  aes192-cbc  AES with 192-bit key in CBC mode
  aes192-ctr  AES with 192-bit key in CTR mode
  aes256-cbc  AES with 256-bit key in CBC mode
  aes256-ctr  AES with 256-bit key in CTR mode

test(config)#ip ssh server algorithm mac ?
  hmac-sha1     HMAC-SHA1 (digest length = key length = 160 bits)
  hmac-sha1-96  HMAC-SHA1-96 (digest length = 96 bits, key length = 160 bits)

If you look at Authentication in the output you notice that Public key is an option. I wrote a blog showing how to use SSH keys instead of passwords -
Authenticating to Cisco devices using SSH keys

 

Weak SSL ciphers


First, we will look at the current secure server settings. To see all possible secure server settings:
sh ip http server
  all             HTTP server all information
  connection      HTTP server connection information
  external        HTTP external registration
  history         HTTP server history information
  secure          HTTP secure server status information
  session-module  HTTP server application session module information
  statistics      HTTP server statistics information
  status          HTTP server status information

sh ip http server all        
HTTP server status: Disabled
HTTP server port: 80
HTTP server authentication method: local
HTTP server access class: 0
HTTP server base path: flash:/c2960x-universalk9-mz.152-4.E8/html
HTTP server help root:
Maximum number of concurrent server connections allowed: 16
Maximum number of secondary server connections allowed: 5
Server idle time-out: 180 seconds
Server life time-out: 180 seconds
Server session idle time-out: 180 seconds
Maximum number of requests allowed on a connection: 25
HTTP server active session modules: ALL
HTTP secure server capability: Present
HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite:  dhe-aes-128-cbc-sha dhe-aes-256-cbc-sha
        edche-rsa-aes-256-cbc-sha edche-rsa-rc4-128-sha

HTTP secure server client authentication: Disabled
HTTP secure server trustpoint:
HTTP secure server active session modules: ALL

To see who is connected to the switch over TLS:
sh ip http server connection

HTTP server current connections:
local-ipaddress:port  remote-ipaddress:port in-bytes   out-bytes
  192.168.10.31:443    192.168.10.211:55014 1394       586227


Viewing available current cipher suites


ip http secure-ciphersuite ?

  aes-128-cbc-sha            Encryption type tls_rsa_with_aes_cbc_128_sha
                             ciphersuite
  aes-256-cbc-sha            Encryption type tls_rsa_with_aes_cbc_256_sha
                             ciphersuite
  dhe-aes-128-cbc-sha        Encryption type tls_dhe_rsa_with_aes_128_cbc_sha
                             ciphersuite
  dhe-aes-256-cbc-sha        Encryption type tls_dhe_rsa_with_aes_256_cbc_sha
                             ciphersuite
  edche-rsa-aes-256-cbc-sha  Encryption type tls_ecdhe_rsa_aes_256_cbc_sha
                             ciphersuite
  edche-rsa-rc4-128-sha      Encryption type tls_ecdhe_rsa_rc4_128_sha
                             ciphersuite
  null-sha                   Encryption type tls_rsa_with_null_sha ciphersuite



Notice that rc4 and Null are supported!

To verify what was being offered by the switch I ran the nmap ssl-cert and ciphers script.
sudo nmap --script ssl-cert,ssl-enum-ciphers -p 443 192.168.10.31
Nmap scan report for 10.241.3.40
Host is up, received echo-reply ttl 254 (0.10s latency).
Scanned at 2020-06-18 15:28:06 PDT for 3s

PORT     STATE  SERVICE       REASON
443/tcp  open   https         syn-ack ttl 254
| ssl-cert: Subject: commonName=IOS-Self-Signed-Certificate-1302447744
| Issuer: commonName=IOS-Self-Signed-Certificate-1302447744
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2020-06-16T22:55:16
| Not valid after:  2030-01-01T00:00:00
| MD5:   c522 61ff 31c4 c9aa 971d 7cfd 4eb7 14de
| SHA-1: 50fb 7c7d d6a8 86c0 ba67 1293 11d7 f529 058e e1de
| -----BEGIN CERTIFICATE-----
| MIICKzCCAZSgAwIBAgIBATANBgkqhkiG9w0BAQUFADAxMS8wLQYDVQQDEyZJT1Mt
| U2VsZi1TaWduZWQtQ2VydGlmaWNhdGUtMTMwMjQ0Nzc0NDAeFw0yMDA2MTYyMjU1
| MTZaFw0zMDAxMDEwMDAwMDBaMDExLzAtBgNVBAMTJklPUy1TZWxmLVNpZ25lZC1D
| ZXJ0aWZpY2F0ZS0xMzAyNDQ3NzQ0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
| gQDCgxwOBYowFY7GgS3Q81u6CRTzcaEb2SwZvzSsjTLmHPqrB7OYgGukAgs19+Xa
| 8jRS3jY4Q492RtpyBAb4BU9naHXRKvD2zB5e9QDreeFOf73If6f8V/BtjqSozYZW
| N0RPpgqIWVbgQbkr1eBbnXgE1/TO7czYcjae/OTSZwQL1QIDAQABo1MwUTAPBgNV
| HRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFDL08Ihv1OFKYBqkbHJ5wpXt3G7IMB0G
| A1UdDgQWBBQy9PCIb9ThSmAapGxyecKV7dxuyDANBgkqhkiG9w0BAQUFAAOBgQCH
| GxSZ29CUBrvCkDU4knDw9WmdLKqgMl88+dpZmOO758+o4B8lMT0f+Ixny7drFIJ7
| rrkhrqpCHnLDJtXYcINiaKASs3tPIpQ21nQ1r5WTdW8GqaTVcOBIFG0KWlJGVmsF
| RepCnGblGV/3mrUWImNU8xwY+uZS2vAFKAVXYVLk5w==
|_-----END CERTIFICATE-----
| ssl-enum-ciphers:
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       Weak certificate signature: SHA1
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       Weak certificate signature: SHA1
|_  least strength: A
465/tcp  closed smtps         reset ttl 254
993/tcp  closed imaps         reset ttl 254
995/tcp  closed pop3s         reset ttl 254
3389/tcp closed ms-wbt-server reset ttl 254

NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 15:28
Completed NSE at 15:28, 0.00s elapsed
Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.71 seconds
           Raw packets sent: 9 (372B) | Rcvd: 6 (232B)


To secure TLS I upgraded to 15.2.7E2. This release allows TLS 1.0 and 1.1 to be disabled. To pass a penetration test you will need to disable both. Once the upgrade is complete run the following:
test(config)#ip http secure-ciphersuite ?
  aes-128-cbc-sha            Encryption type tls_rsa_with_aes_cbc_128_sha ciphersuite
  aes-256-cbc-sha            Encryption type tls_rsa_with_aes_cbc_256_sha ciphersuite
  dhe-aes-128-cbc-sha        Encryption type tls_dhe_rsa_with_aes_128_cbc_sha ciphersuite
  edche-rsa-aes-256-cbc-sha  Encryption type tls_ecdhe_rsa_aes_256_cbc_sha ciphersuite


test(config)#ip http secure-ciphersuite edche-rsa-aes-256-cbc-sha aes-256-cbc-sha
test(config)#ip http tls-version ?
  TLSv1.0  Set TLSv1.0 version Only
  TLSv1.1  Set TLSv1.1 version Only
  TLSv1.2  Set TLSv1.2 version Only
test(config)#ip http tls-version tlsv1.2
To verify, I re-ran the nmap ssl-cert and ciphers scripts. This time only TLS 1.2 is enabled.
sudo nmap --script ssl-cert,ssl-enum-ciphers -p 443 192.168.10.31
Nmap scan report for 192.168.10.31
Host is up, received echo-reply ttl 254 (0.0072s latency).
Scanned at 2020-06-18 15:50:03 PDT for 3s

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack ttl 254
| ssl-cert: Subject: commonName=IOS-Self-Signed-Certificate-1302447744
| Issuer: commonName=IOS-Self-Signed-Certificate-1302447744
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2020-06-16T22:55:16
| Not valid after:  2030-01-01T00:00:00
| MD5:   c522 61ff 31c4 c9aa 971d 7cfd 4eb7 14de
| SHA-1: 50fb 7c7d d6a8 86c0 ba67 1293 11d7 f529 058e e1de
| -----BEGIN CERTIFICATE-----
| MIICKzCCAZSgAwIBAgIBATANBgkqhkiG9w0BAQUFADAxMS8wLQYDVQQDEyZJT1Mt
| U2VsZi1TaWduZWQtQ2VydGlmaWNhdGUtMTMwMjQ0Nzc0NDAeFw0yMDA2MTYyMjU1
| MTZaFw0zMDAxMDEwMDAwMDBaMDExLzAtBgNVBAMTJklPUy1TZWxmLVNpZ25lZC1D
| ZXJ0aWZpY2F0ZS0xMzAyNDQ3NzQ0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
| gQDCgxwOBYowFY7GgS3Q81u6CRTzcaEb2SwZvzSsjTLmHPqrB7OYgGukAgs19+Xa
| 8jRS3jY4Q492RtpyBAb4BU9naHXRKvD2zB5e9QDreeFOf73If6f8V/BtjqSozYZW
| N0RPpgqIWVbgQbkr1eBbnXgE1/TO7czYcjae/OTSZwQL1QIDAQABo1MwUTAPBgNV
| HRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFDL08Ihv1OFKYBqkbHJ5wpXt3G7IMB0G
| A1UdDgQWBBQy9PCIb9ThSmAapGxyecKV7dxuyDANBgkqhkiG9w0BAQUFAAOBgQCH
| GxSZ29CUBrvCkDU4knDw9WmdLKqgMl88+dpZmOO758+o4B8lMT0f+Ixny7drFIJ7
| rrkhrqpCHnLDJtXYcINiaKASs3tPIpQ21nQ1r5WTdW8GqaTVcOBIFG0KWlJGVmsF
| RepCnGblGV/3mrUWImNU8xwY+uZS2vAFKAVXYVLk5w==
|_-----END CERTIFICATE-----
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 1024) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       Weak certificate signature: SHA1
|_  least strength: A

NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.99 seconds
           Raw packets sent: 5 (196B) | Rcvd: 2 (72B)

Results

You can see that it still uses SHA1 as the certificate signature. You can use  Ciphersuite Info to compare different ciphers.

What about SSH?

Let's see what's new for SSH in 15.7.2E2.
ip ssh server algorithm mac ?
  hmac-sha1      HMAC-SHA1 (digest length = key length = 160 bits)
  hmac-sha1-96   HMAC-SHA1-96 (digest length = 96 bits, key length = 160 bits)
  hmac-sha2-256  HMAC-SHA2-256 (digest length = 256 bits, key length = 256
                 bits)
  hmac-sha2-512  HMAC-SHA2-512 (digest length = 512 bits, key length = 512
                 bits)


ip ssh serv algorithm encryption ?


3des-cbc    Three-key 3DES in CBC mode
  aes128-cbc  AES with 128-bit key in CBC mode
  aes128-ctr  AES with 128-bit key in CTR mode
  aes192-cbc  AES with 192-bit key in CBC mode
  aes192-ctr  AES with 192-bit key in CTR mode
  aes256-cbc  AES with 256-bit key in CBC mode
  aes256-ctr  AES with 256-bit key in CTR mode


Now we can eliminate the ancient HMAC-SHA1 and CBC ciphers from our switch!

First, we will add the sha2 HMACs
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512

Then remove the sha1 hmacs
no ip ssh server algorithm mac hmac-sha1
no ip ssh server algorithm mac hmac-sha1-96

And now the encryption
ip ssh server algorithm encryption aes256-ctr aes192-ctr aes128-ctr

The results

show ip ssh

SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
Encryption Algorithms:aes256-ctr,aes192-ctr,aes128-ctr
MAC Algorithms:hmac-sha2-256,hmac-sha2-512
KEX Algorithms:diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): SSH-KEYS
Modulus Size : 4096 bits
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDCsyuZ8/lMCNHSLREb6vGQoBVehYQQI0+eJlanuyq5
f+iTqFcceR7vvXP14JhHmXe2lkygOZ8VIeilMJkpS8q748TaBL9QfmUAdDkbbk1wYPNKM2sLn/ACuerf
ImNa4vQFNaP28zqaCMhre/Z0DCRJvDnOXs2fepQnQZ6ZvbOgwMRw6rvTiLcPYlB46VlaS6T1ogEbsPLz
HG1e2UeGOnxyIU9j99+sUq3h5omoxtOd33c7ygyBgghBm+G4rHoD4EsJmejK2/Ai1PsjHIN16EaTAB0Y
MiIFByAYr4/Hr+6ANejxDrFpeY3DDBTvXIcES3S+C/Ch6JEoFVfHufc5ni8OReE7KQhrBctNfhoXvFRO
wITNNyyu/jk1LLDTaLFbL/auw/eXGXlXXerWRFY6HvmAbQannl9wryvy97Hm4LJVO+DtTspwvw4IKrQT
HDMdyXvTI6RMjIlGb/7hiUeFb33wx7sw/DwkgjyUCWh8R8nCEoLfpz7qOchW2/WSj+608m62Eh6WDy5q
qkDpstQRD7AbE2OBtiuYgYJaNJfZ1qhIQXlvtQCTgRRS2TvInnoGg+STD2+lWR5WufgKEO778tNDXt3H
YRSdD2N1YcjXG+y0hB/xjvWSoMkr+G2Btxtm8QPgvXQRe9aFU/kALMBKBJ6Q+rDXr2QbyA7zpDudkAn3

Security Header Enhancements

For IOS-XE devices, starting with 16.4.1, the Nginx/HTTP headers have the following settings for increased security:

Nginx – Web user interface - 
Nginx applications take care of the headers for their response. As Web UI is one of the NginX application, it adds the security headers. 

The three headers are the following:

  •     X-XSS-Protection: 1; mode=block
  •     X-Frame-Options: SAMEORIGIN
  •     X-Content-Type-Options: nosniff


Do the same thing to your Linux Servers

There is a good chance your organization is running some Linux servers. Out of the box, CentOS/Ubuntu will have several weak ciphers. It's very easy to correct that but you will need root privileges.

First, we will check what ciphers your server is offering. If the server has a public IP address you can go to https://sshcheck.com and enter the FQDN or the IP address. You will get back a comprehensive report back with suggestions on which items should be disabled.

If the server is internal you can use nmap's ssh-enum script:
sudo nmap --script ssh2-enum-algos 192.168.10.239

This will return a list of the crypto offered by your server.

Update the sshd config file

The sshd config file is located at /etc/ssh. We need to open it and add the suites we want. First we will make a backup copy.

sudo cd /etc/ssh
sudo cp sshd_config sshd_config.bak
sudo nano sshd_config

Add the following (Make sure these fit your company's security policies)
ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

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

KexAlgorithms diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256,curve25519-sha256,curve25519-sh$

You can add these anywhere. I put them just below the section
"# Ciphers and keying".

Press ctrl+x, enter Y to save the file and enter to complete.

You can use
sudo sshd -t
to verify the changes. If there are no mistakes in the configuration file nothing will be displayed. If there are errors you get a message with the line number where the error occurred.

You can use
sshd -T
to dump the current ssh configuration.

Now we just need to restart the ssh daemon;
sudo systemctl restart sshd


Check your work

Refresh the sshcheck page or rerun nmap. You should see just the cipher suites you entered. Here is nmap against my server:
nmap --script ssh2-enum-algos -sV -p22 hubbardonnetworking.com

Starting Nmap 7.70 ( https://nmap.org ) at 2020-06-24 22:15 PDT
Nmap scan report for hubbardonnetworking.com (107.170.203.230)
Host is up (0.026s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms: (6)
|       diffie-hellman-group14-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|       diffie-hellman-group-exchange-sha256
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|   server_host_key_algorithms: (5)
|       ssh-rsa
|       rsa-sha2-512
|       rsa-sha2-256
|       ecdsa-sha2-nistp256
|       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: (5)
|       umac-128-etm@openssh.com
|       hmac-sha2-256-etm@openssh.com
|       hmac-sha2-512-etm@openssh.com
|       umac-128@openssh.com
|       hmac-sha2-256
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.70 seconds
 
I have a Python script that presents a menu with several nmap security scripts. If you haven't used nmap much it is worth a look.

Python tool for nmap scripts

References

Putty SSH V2
SSH Algorithms for Common Criteria Certification
Cisco IOS HTTP Services Command Reference

Sunday, November 9, 2014

Debugging Cisco Device Authentication to a Microsoft NPS Server

You have configured a Microsoft Network Policy Server to use as a RADIUS server for your Cisco devices. But for some reason your logins aren't successful. Use the following to trouble shoot the NPS Server:

Enable Logging on the NPS Server
Open a cmd window and enter:
netsh ras diagnostics set rastracing * enabled


Be sure to disable afterward (netsh ras diagnostics set rastracing * disabled).

These logs are saved to %windir%\tracing. You can find more detailed infromation on logging at Enabling RAS Tracing in Vista/Longhorn Server 


Accounting logs are saved to C:\Windows\system32\LogFiles by default. You can change this by clicking on “Accounting” in the NPS console.

Click Start, Run and enter GPEDIT.MSC
Enable both success/failure at Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Logon/Logoff -> Audit Network Policy Server.

In the command window  run “netsh nps show eventlog” and “netsh nps show filelog” on the NPS server, check that the results are:

C:\Windows\system32>netsh nps show filelog

File log configuration:
---------------------------------------------------------
Accounting                     = Enabled
Authentication                 = Enabled
Periodic accounting status     = Enabled
Periodic authentication status = Enabled
Directory                      = C:\Windows\system32\LogFiles
Format                         = ODBC formatting
Delete old logs                = Enabled
Frequency                      = Monthly logs
Max size                       = 10 MB

C:\Windows\system32>netsh nps show eventlog

Event log configuration:
---------------------------------------------------------
Accepted authentication requests = Enabled
Rejected authentication requests = Enabled

Viewing NPS logs

Open Server Manager and expand Diagnostics, Event Viewer, Custom Views, Server Roles, Network Policy and Access Server

Request Not Matching the Network Policy


If you see the following on the client you are using to log in 'Line has invalid autocommand " ppp negotiate  "' it probably means that the request isn't matching the network policy you created. Putty will close the session before you can see the message. If you try to log in and it looks successful but the session immediately closes try using a different client.

You can verify by looking at the NPS logs. Find the failed attempt, double click, and select the Detail tab. Scroll down until you can see the ProxyPolicyName. Right below that will be the Network Policy name that was matched. You can see in the example below that it's blank.

The reason this causes the " ppp negotiate " is that the default policy in NPS has a service-type of PPP.

From the "Details" tab of the NPS server log viewer:
ProxyPolicyName CISCO-Radius
NetworkPolicyName -
AuthenticationProvider Windows
AuthenticationServer NPS.LAB.PRI
AuthenticationType PAP

In this example I had moved the NPS server to a new AD domain and the policy just wouldn't match. I deleted it, created a new one and all was good.


Invalid Radius Client

It’s possible the client is using a different interface to communicate with the NPS server than the one you configured. The event log entry for an invalid client is 13. You can filter the log to see if your device is using the address you expected.


You can use "ip radius source-interface InterfaceName" to force radius to use a specific interface. For example, if the management interface is vlan 18 use:

ip radius source-interface Vlan18


Invalid Username/Password

If the user entered an invalid username or password event ID 6273 will be recorded. Filter the log on 6273 to find the details. The log records the “friendly Client name”, the Client IP address and message about the failed credentials.



Note: If the RADIUS keys don't match between the device and the client entry in the NPS server you will also get the same message in the log!

NPS Logs show "Access Granted" but the switch doesn't get a response

This was probably a fluke but in one instance I had changed the hostname AND IP address of a switch. The NPS server showed Access Granted but when I looked at the detail in the log the NASIPv4Address was correct but the ClientName and ClientIPAddress were the old values so NPS was sending the response to the wrong IP. I reloaded the switch and it worked correctly.



No Log Entries

There are a few reasons that the log doesn’t contain any entries from the device. The device will accept the first method that has a successful username/password match. I once entered the “Local” keyword before the RADIUS group in the authentication string. I had a local username that was the same as my AD username but with a different password.

The device would see the local username and incorrect password and terminate the login attempt. No log entries were recorded because the device stopped the login attempt as soon as the “Local” method failed.

You may also have put in the wrong IP address of the NPS server in your RADIUS definition. The commands below will help you trouble shoot that.

Finally, if you don't authorize the NPS server in AD it won't show any log entries.

Verifying IOS RADIUS configuration
sh aaa servers – lists the IP of the server and the ports it is using. Make sure that you used the same ports on the NPS server and the device.
#sh aaa server
RADIUS: id 1, priority 1, host 10.140.47.205, auth-port 1645, acct-port 1646


User successfully authenticated
USER ATTRIBUTES
service-type         0   1 [Login]
priv-lvl             0   15 (0xF)

There are many debugs you can enable for trouble shooting RADIUS. The six listed below seem to be enough to solve most issues.

debug aaa authentication
debug aaa sg-server-selection
debug aaa protocol radius
debug aaa author
debug radius elog
debug radius verbose

With these enabled, you will see the following for a wrong password and a successful login:

*******************************************
User entered wrong password
024847: Sep 29 21:03:57.710 PDT: AAA/BIND(00001047): Bind i/f
024848: Sep 29 21:03:57.711 PDT: AAA/AUTHEN/LOGIN (00001047): Pick method list 'UseRadius'
024849: Sep 29 21:03:57.711 PDT: RADIUS/ENCODE(00001047): ask "Please enter your username:"
024850: Sep 29 21:03:57.711 PDT: RADIUS/ENCODE(00001047): send packet; GET_USER
024851: Sep 29 21:04:01.992 PDT: RADIUS/ENCODE(00001047): ask "Please enter your password:"
024852: Sep 29 21:04:01.992 PDT: RADIUS/ENCODE(00001047): send packet; GET_PASSWORD
024853: Sep 29 21:04:06.781 PDT: RADIUS/ENCODE(00001047):Orig. component type = Exec
024854: Sep 29 21:04:06.781 PDT: RADIUS(00001047): Config NAS IP: 0.0.0.0
024855: Sep 29 21:04:06.781 PDT: RADIUS(00001047): Config NAS IPv6: ::
024856: Sep 29 21:04:06.781 PDT: RADIUS/ENCODE: Best Local IP-Address 10.140.119.207 for Radius-Server 10.140.47.205
024857: Sep 29 21:04:06.781 PDT: RADIUS(00001047): Sending a IPv4 Radius Packet
024858: Sep 29 21:04:06.782 PDT: RADIUS(00001047): Started 5 sec timeout
024859: Sep 29 21:04:06.877 PDT: RADIUS: Received from id 1645/10 10.140.47.205:1645, 
Access-Reject, len 20

User entered correct password
024865: Sep 29 21:06:12.137 PDT: AAA/BIND(00001048): Bind i/f
024866: Sep 29 21:06:12.137 PDT: AAA/AUTHEN/LOGIN (00001048): Pick method list 'UseRadius'
024867: Sep 29 21:06:12.138 PDT: RADIUS/ENCODE(00001048): ask "Please enter your username:"
024868: Sep 29 21:06:12.138 PDT: RADIUS/ENCODE(00001048): send packet; GET_USER
024869: Sep 29 21:06:14.844 PDT: RADIUS/ENCODE(00001048): ask "Please enter your pasword:"
024870: Sep 29 21:06:14.844 PDT: RADIUS/ENCODE(00001048): send packet; GET_PASSWORD
024871: Sep 29 21:06:19.677 PDT: RADIUS/ENCODE(00001048):Orig. component type = Exec
024872: Sep 29 21:06:19.677 PDT: RADIUS(00001048): Config NAS IP: 0.0.0.0
024873: Sep 29 21:06:19.677 PDT: RADIUS(00001048): Config NAS IPv6: ::
024874: Sep 29 21:06:19.678 PDT: RADIUS/ENCODE: Best Local IP-Address 10.140.119.207 for Radius-Server 10.140.47.205
024875: Sep 29 21:06:19.678 PDT: RADIUS(00001048): Sending a IPv4 Radius Packet
024876: Sep 29 21:06:19.678 PDT: RADIUS(00001048): Started 5 sec timeout
024877: Sep 29 21:06:19.692 PDT: RADIUS: Received from id 1645/11 10.140.47.205:1645, 
Access-Accept, len 152
024878: Sep 29 21:06:19.692 PDT: AAA/AUTHOR/EXEC(00001048): processing AV priv-lvl=15
024879: Sep 29 21:06:19.692 PDT: AAA/AUTHOR/EXEC(00001048): processing AV priv-lvl=15
024880: Sep 29 21:06:19.692 PDT: AAA/AUTHOR/EXEC(00001048): processing AV service-type=1
024881: Sep 29 21:06:19.693 PDT: AAA/AUTHOR/EXEC(00001048): 
Authorization successful


In this debug I forgot to enter the key in the RADIUS section

001939: Sep 24 13:04:48 PST: RADIUS/ENCODE(00000040):Orig. component type = Exec
001940: Sep 24 13:04:48 PST: RADIUS:  AAA Unsupported Attr: interface         [221] 4   125716940
001941: Sep 24 13:04:48 PST: RADIUS/ENCODE(00000040): Unsupported AAA attribute clid
001942: Sep 24 13:04:48 PST: RADIUS/ENCODE(00000040): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
001943: Sep 24 13:04:48 PST: RADIUS(00000040): Config NAS IP: 10.200.18.36
001944: Sep 24 13:04:48 PST: RADIUS(00000040): Config NAS IPv6: ::
001945: Sep 24 13:04:48 PST: RADIUS/ENCODE(00000040): acct_session_id: 54
001946: Sep 24 13:04:48 PST: RADIUS(00000040): sending
001947: Sep 24 13:04:48 PST: RADIUS: No secret to encode request (rctx:0x7A46DCC)
001948: Sep 24 13:04:48 PST: RADIUS: Unable to encrypt (rctx:0x7A46DCC)
001949: Sep 24 13:04:48 PST: RADIUS: No secret to encode request (rctx:0x7A46DCC)
001950: Sep 24 13:04:48 PST: RADIUS: Unable to encrypt (rctx:0x7A46DCC)
001951: Sep 24 13:04:48 PST: %RADIUS-4-RADIUS_DEAD: RADIUS server 10.1.52.59:1645,1646 is not responding.
001952: Sep 24 13:04:48 PST: %RADIUS-4-RADIUS_ALIVE: RADIUS server 10.1.52.59:1645,1646 is being marked alive.
001953: Sep 24 13:04:48 PST: RADIUS: No secret to encode request (rctx:0x7A46DCC)
001954: Sep 24 13:04:48 PST: RADIUS: Unable to encrypt (rctx:0x7A46DCC)
001955: Sep 24 13:04:48 PST: RADIUS: No secret to encode request (rctx:0x7A46DCC)
001956: Sep 24 13:04:48 PST: RADIUS: Unable to encrypt (rctx:0x7A46DCC)
001957: Sep 24 13:04:48 PST: RADIUS: No secret to encode request (rctx:0x7A46DCC)
001958: Sep 24 13:04:48 PST: RADIUS: Unable to encrypt (rctx:0x7A46DCC)
001959: Sep 24 13:04:48 PST: RADIUS/DECODE: No response from radius-server; parse response; FAIL

001960: Sep 24 13:04:48 PST: RADIUS/DECODE: Case error(no response/ bad packet/ op decode);parse response; FAIL