cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1955
Views
20
Helpful
7
Replies

SF300 and SG300 Switches F/W ver 1.4.11.5

ajitsgovilkar
Level 1
Level 1

Hello Champs,


Can we secure SF300 and SG300 Switches with F/W ver 1.4.11.5 using SHA-2 against weak KEX and MAC algorithms ?

What are the commands to execute ?


If this can not be done for SHA-2, Can we secure SF300-24 Switch with F/W ver 1.4.11.5 using SHA-1 against weak KEX and MAC algorithms ?

What are the commands to execute ?


This is a bit urgent. Awaiting your earliest advise.


Thanks in advance.

Ajit Govilkar

7 Replies 7

Jitendra Kumar
Spotlight
Spotlight

Edited..

 

Below is the details :-

isco IOS

It always starts with the generation of a public/private keypair that will be only used for the SSH-process. In this command we use a dedicated label "SSH-KEY" which we later assign to the SSH-config. The default-keylength ist typically too small, it's time to move to a stronger crypto. For new setups I only use 4096 Bit keys. Thats more then recommended on sites like http://www.keylength.com and makes the session-setup a little slower. But by far not that slow that it's unusable. And it typically doesn't hurt to have better crypto then the others.

 

crypto key generate rsa label SSH-KEY modulus 4096

 

The RSA-Keypair is assigned to the SSH-config:

 

ip ssh rsa keypair-name SSH-KEY

 

Next we only allow SSH version 2. By default also version 1 is allowed:

 

ip ssh version 2

 

When the SSH-session is established, the session-keys are computed with the Diffie-Hellmann key exchange protocol. By default this is done with 768 Bit, which is not state-of-the-art any more. For my setups (with MacOS and Linux clients) I configure a bitlength of 4096 Bit. If you are using Putty in the actual version (0.63 at the time of writing), this is more then Putty can handle. You should change to a more powerful terminal like SecureCRT or use only a size of 2048 Bit which is still very secure. And if your IOS is to old, this command will also not be available.

 

ip ssh dh min size 4096

 

Depending on your needs you could enable the logging of SSH-login-events:

 

ip ssh logging events

 

The last step is to restrict the vty-lines to only use SSH, so that Telnet is not allowed any more:

 

line vty 0 4
  transport input ssh

 

In some setups, where SSH has to be reachable over the internet, I also change the SSH-port to something non-standard. This won't really increase the security of the setup, but it gives less log-entries from bots that try to login to SSH with commonly used username/password-combinations.

 

ip ssh port 7890 rotary 1
!
line vty 0 4
  rotary 1

 

 

If the IOS-device is running at least 15.5(2), then it's possible to disable unwanted algorithms. In security-audits, all CBC-ciphers are often a problem.

 

By default there are many algorithms supported:

 

rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96

 

With the following config only aes256-ctr with hmac-sha1 is allowed on the router:

 

ip ssh server algorithm encryption aes256-ctr
ip ssh server algorithm mac hmac-sha1

 

rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes256-ctr
MAC Algorithms:hmac-sha1

 

Usernames and Passwords in Cisco IOS

There are different ways in IOS to configure users with corresponding passwords. For SSH, the Router/Switch doesn't need the cleartext password. That means you should not configure your users with

rtr(config)#username USER password PASS

 

Better configure your users with hashed passwords. If you are running a recent IOS, you can configure the passwords to be hashed with PBKDF2:

rtr(config)#username USER algorithm-type sha256 secret VERYSECUREPASSWORD

 

If your IOS doesn't support this new username-parameter, you configure them the following way:

rtr(config)#username USER secret VERYSECUREPASSWORD

 

 

Some more protection-mechanisms that should be thought about are Control-Plane-Protection and Management-Plane-Protection. But that is not SSH-specific.

 

Cisco ASA

The setup on the ASA has the same goal as on IOS, but there are less options to secure SSH. The syntax is also a bit different:

 

crypto key generate rsa modulus 4096
ssh version 2
ssh key-exchange group dh-group14-sha1

 

The keylength is dependent on the ASA platform in use. The legacy ASAs are not capable of a keylength larger then 2048 Bit. On the actual 5500-X devices, 4096 Bit is also possible.

The command "ssh key-exhange group group14-sha1" was introduced in 8.4(4.1) and 9.1(2).

 

Starting with 9.6(1) and 9.1(7), it's possible to limit the ciphers that are allowed on the ASA.

 

These are the defaults:

asa(config)# show ssh | inc Cipher
Cipher encryption algorithms enabled: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
Cipher integrity algorithms enabled: hmac-sha1 hmac-sha1-96

 

The available options are:

 

asa(config)# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
Encryption Algorithms:
all: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
low: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
medium: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
fips: aes128-cbc aes256-cbc
high: aes256-cbc aes256-ctr
Integrity Algorithms:
all: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
low: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
medium: hmac-sha1 hmac-sha1-96
fips: hmac-sha1
high: hmac-sha1

 

With the following config only aes256-ctr with hmac-sha1 is allowed on the ASA:

ssh cipher encryption custom aes256-ctr
ssh cipher integrity custom hmac-sha1

 

On the ASA, the SSH-access has to be allowed from the management-IPs:

 

ssh 10.10.0.0 255.255.0.0 inside
ssh 192.0.2.100 255.255.255.255 outside

 

Cisco Nexus

The Nexus by default uses only 1024 Bit keys, and only supports SSH version 2.

The only available option (to my knowledge and based on the config guide) is to use keys with a maximum length of 2048 Bits for the SSH-server:

 

ssh key rsa 2048 force
 

 

Client-config on MacOS (and Linux)

On a default-install of MacOS and also some Linux-versions, the optimum crypto is not always negotiated. For that, some settings should be adjusted to provide more security.

 

SSH-parameter can be configured at two places:

  • globally at /etc/ssh_config
  • per User at ~/.ssh/config

 

In the systemwide config on MacOS the following three lines are most relevant for the used cryptography of the SSH-sessions (shown are the defaults on OS X Mavericks 10.9):

 

#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96

 

There are a couple of changes needed to make SSH-sessions more secure:  

Ciphers

If you don't have any legacy devices to manage you can remove everything other then the AES-ciphers. If there are still older devices like Catalyst 2950 to manage, 3des-cbc could be left in the config:

 

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc

 

I prefer to not have any legacy crypto in my cipher-string. If I have to connect to a legacy device, I specify that on the ssh-command which is shown later in this document.

Based on the manpage (and also based on the used OpenSSH-version which is 6.2p2 on both Mavericks and Yosemite), modern cipher-types like AES-GCM should also work. But when trying to configure them I only get the error „Bad SSH2 cipher spec“.  

When connecting to Cisco routers and switches, typically the  CBC-versions are used, the more modern CTR is only supported with IOS 15.4 which at least I don't use yet.

KexAlgorithms

This option controls the Key-Exchange. A more secure config on Mac OS is the following:

 

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

 

I removed the ElipticCurve algorithms as they are suspected to contain backdoors. 

The probably trustworthy curve25519 from D.J. Bernstein is only available starting with OpenSSH 6.6p1. Based on the availability, this algorithm should be added.

The last option in this line is again for legacy systems. Again, I don't have these configured, instead I use these options only for the sessions where needed.

MACs

In this default I don't like the MD5 MACs and that the more secure ones don't have the highest priority. So this line should be cleaned up and rearranged:

 

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

 

Just notice the etm-MACs in the line. These are not relevant for accessing Cisco Network-devices, but can strengthen the crypto when connecting to other SSH-servers. A little excursion into Message Authentication Codes:  

The protocols SSL/TLS, IPsec and SSH by default use different methods to encrypt the data and protect the integrity:

  • SSL: mac-then-encrypt. The MAC is build first, then MAC and data are encrypted.
  • IPsec: encrypt-then-mac. The data is first encrypted, the MAC is build over the encrypted data.
  • SSH: encrypt-and-mac. The data is encrypted, but the MAC is build over the cleartext data.

Cryptographers have shown that the method used by IPsec is the most secure one. This method (encrypt-then-mac) can also be used by SSH when supported on both the client and server.

Update: RFC 7366 defines an extention to TLS that also allows to use "encrypt then mac".

 

What will change for our SSH-sessions with this new config? Before activating the config-changes, this is an SSH-session (on a Cisco 3560 with IOS 15.0(2)SE5):

 

c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
1 2.0 IN aes128-cbc hmac-md5 Session started ki
1 2.0 OUT aes128-cbc hmac-md5 Session started ki

 

The used crypto is aes-128-cbc with an MD5-HMAC. After applying the new client-config, the used crypto is much better (as far as possible with this IOS):

 

c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes256-cbc hmac-sha1 Session started ki
0 2.0 OUT aes256-cbc hmac-sha1 Session started ki

 

 

This is the used  ~/.ssh/config that still includes the legacy methods:

 

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

 

As mentioned earlier, I also removed the legacy crypto from my ~/.ssh/config:

 

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

 

If an ssh-session to a legacy device is still needed, the older crypto has to be specified with the ssh-command. This is an example for a connection to an old Catalyst 2950:

 

Thanks,

Jitendra

Thanks,
Jitendra

@Jitendra Kumarthis looks like a copy past which website you get it from. would be great if you show the link too. its a good practice to give credit to the person who wrote the document. you just copy paste its called plagiarism

Sorry, I forgot to put the discussion link in the post...

 

Thanks,

Jitendra

 

Thanks,
Jitendra

here found the link

https://community.cisco.com/t5/security-documents/guide-to-better-ssh-security/ta-p/3133344

 

 

please give credit to the person who wrote instead of doing a copy paste

Hi

 

 Switches with standard IOS allow you to choose the encryption algorithm but Small Business switch does not.  Basically you can enable or disable SSH and that´s all.

 

sg300.JPG

as mentioned by @Flavio Miranda This is correct.

Youtube link how to enable ssh and here cisco youtube channel on this switch and another one to make it more secure with generating Public key authentication enable-public-key-authentication-ssh-cisco-sg300-switches/ 

please do not forget to rate.
Review Cisco Networking for a $25 gift card