Upgrading firmware on switches, routers and/or firewalls is a common task for network administrators. Normally I am used to downloading the new firmware from the console of the switch. I normally download the software from a (T)FTP server. While configuring a bunch of HPE 2930F switches for SSH access I noticed that I had the option to configure “ip ssh filetransfer”.
I was curious what I would be able to do with this command and I figured out that it is useful for uploading new firmware to the switch. With the command I am able to upload software from a session on my laptop to the switch. I tested this in my home network with a firmware upgrade of my own HPE 2930F switches.
At first I enabled the “ip ssh filetransfer” option. Ofcourse you need to configure the regular SSH access to the switch, but I guess everybody enables SSH and disables Telnet by default!!!
2930F-01(config)# ip ssh
filetransfer Enable/disable secure file transfer capability.
I downloaded the new software image to my laptop and copy the software via SCP to the switch as primary flash image.
MacBook:Downloads rjn$ scp WC_16_05_0003.swi firstname.lastname@example.org:/os/primary
The software is copied directly to the switch. You can check this on the switch:
2930F-01# show flash
Image Size (bytes) Date Version
—————– ———— ——– ————–
Primary Image : 28793113 12/08/17 WC.16.05.0003
Secondary Image : 20530856 10/26/16 WC.16.02.0014
You can also copy the file as secondary flash image and change the boot image via:
2930F-01(config)# boot system flash secondary
To activate the new software, just reload the switch. And don’t forget to get a backup of the configuration first.
Plink stands for PuTTY Link and is a command-line connection tool similar to Unix ssh. As a networking consultant I often need to support customers from remote locations. Access to their networking equipment is mostly blocked from unknown locations. Sometimes it is allowed to directly access networking equipment, like a company firewall, from a known location. An example of such a known location could be the public IP space of my companies headquarters.
But how can I support somebody if I am not at my companies headquarters? Most Unix boys already know the answer to that questions…. SSH (Secure SHell) tunneling.
To create a SSH tunnel you need a SSH server and a SSH client. Most Unix servers can be configured as SSH servers by installing OpenSSH. There are also a lot of SSH server applications for the Windows platform. I configure and place the SSH server at my headquarters. Since the SSH server uses my companies “allowed” public IP space, the server could connect directly, if allowed, to the customers equipment.
By using the SSH tunnel I use my companies SSH server as some kind of man-in-the-middle server. I connect to my companies SSH server via a SSH remote connection. I configure the connection to forward certain localhost connections from my laptop through the SSH tunnel and let the SSH server setup a new connection to the final destination by forwarding the traffic.
An example would be accessing a Cisco ASA firewall via ASDM from my laptop. At first I create the SSH tunnel to my companies SSH server. I “tell” the connection to forward traffic to my localhost on port TCP/1234 to the SSH server and the SSH server should forward the connection to the customers firewall on port TCP/443. That means that my laptops ASDM application uses my companies public IP space to access the customers firewall. Since my companies public IP space is allowed to access the customers firewall, I can use ASDM on my laptop. Even if I am at a completely different location.
I use Windows 7 as operating system on my laptop, so for SSH tunneling I have to use a third-party application. I always use Plink, which I copy to the C:\Windows\system32 directory, so I can run it from the command-line. Plink can be configured with different parameters, like shown below:
PuTTY Link: command-line connection utility
Usage: plink [options] [user@]host [command]
(“host” can also be a PuTTY saved session name)
-V print version information and exit
-pgpfp print PGP key fingerprints and exit
-v show verbose messages
-load sessname Load settings from saved session
-ssh -telnet -rlogin -raw
force use of a particular protocol
-P port connect to specified port
-l user connect with specified username
-batch disable all interactive prompts
The following options only apply to SSH connections:
-pw passw login with specified password
Dynamic SOCKS-based port forwarding
Forward local port to remote address
Forward remote port to local address
-X -x enable / disable X11 forwarding
-A -a enable / disable agent forwarding
-t -T enable / disable pty allocation
-1 -2 force use of particular protocol version
-4 -6 force use of IPv4 or IPv6
-C enable compression
-i key private key file for authentication
-noagent disable use of Pageant
-agent enable use of Pageant
-m file read remote command(s) from file
-s remote command is an SSH subsystem (SSH-2 only)
-N don’t start a shell/command (SSH-2 only)
open tunnel in place of session (SSH-2 only)
The best way to use Plink is by creating a batch file, which can be run from the command-line. My batch file looks like this:
plink.exe -v -x -a -T -C -noagent -ssh -L 127.0.0.1:1234:18.104.22.168:443 <username>@<IP SSH server>
The command configures a SSH connection to <IP SSH server> using username <username>. All connections from my laptop to 127.0.0.1 on TCP/1234 are forwarded by the SSH server to the remote IP address 22.214.171.124 on TCP/443. You can add more statements to the batch file, by just adding another –L command, like shown below.
plink.exe -v -x -a -T -C -noagent -ssh -L 127.0.0.1:1234:126.96.36.199:443 -L 127.0.0.1:1235:188.8.131.52:22 <username>@<IP SSH server>
After executing the batch file, you will receive a login prompt to enter the user credentials for the SSH server. After entering the credentials you are ready to go. Just start ASDM or another application and connect to the localhost on port TCP/443 or TCP/22. The traffic will be forwarded through the SSH tunnel and from the SSH server to the final destination.
Of course you need to make some preparations to use this solution, like installing the SSH server and publishing the SSH server to the internet. You also need to have SSH access on the remote location, because else you cannot create the SSH tunnel.
Since you are publishing a server to the internet, it is important to “strip” that server. Make sure there are no vulnerable or unnecessary services running on the server and always patch the server to the appropriate level. It is also recommended to use some kind of two-way authentication, like one-time passwords. That way you know you have a secure environment to access the assets at the final destination.
In the end you will have a secure environment with which you can support your customers or access other resources on the internet or on your internal network.
When configuring a Cisco device I always configure some kind of banner, which is displayed when logging in. This banner contains some information, like security warnings and general information. There are different kind of banners.
I was used to configuring a banner login with different variables, like shown below:
banner login ^
You have entered device $(hostname).$(domain) at line $(line) $(line-desc)
This works fine when connecting with Telnet to the device, but this doesn’t work when using SSH. For security reason, I always use SSH to connect to devices, but I didn’t notice the “corrupt” banner since recently.
Banner login doesn’t support SSH:
“When accessing the security appliance through Telnet or SSH, the session closes if there is not enough system memory available to process the banner messages or if a TCP write error occurs. Only the exec and motd banners support access to the security appliance through SSH. The login banner does not support SSH.”
The example below shows the output from a banner motd and a banner login when connecting via SSH.
ssh -l admin 10.10.66.12
You have entered device $(hostname).$(domain) at line $(line) $(line-desc)
You have entered device C877.booches.nl at line 1
The first banner is de banner login and the second is the banner motd. So when using SSH to connect to a device, it is better to use a banner motd or a banner exec.
Lately there are a lot of changes in the firmware and the ASDM for the Cisco ASA firewalls. This means a lot of copying from files to the flash memory of the specific appliances. Normally when upgrading the software from an appliance I use a computer on the customer network. This could be my own laptop or I take over a computer remotely.
Using my own laptop is never a problem, but when I would like to upgrade a firewall remotely I first have to build a VPN tunnel. Take over a computer, download the specific software for the appliance. Install some kind of FTP or TFTP service and start the upload procedure.
A couple of weeks ago a friend of mine brought up the Secure Copy Server feature for Cisco ASA appliance. This features gives to the ability to securely upload files remotely to the flash memory of the appliance. Secure copy is a often used feature in the open source community and the usage is simple. It is a very powerful tool, but it never crossed my mind to use it in conjunction with the ASA appliances.
The Secure Copy Server is enabled with the following command:
ssh scopy enable
After enabling the Secure Copy Server you have the ability to securely copy files to the flash memory of the ASA appliance. Linux or Mac OS X users normally use some kind of terminal to establish a secure copy connection. Windows users could use PuttySCP for uploading files to the flash memory. The syntax for using PuttySCP is in general the same as using a Linux shell. The syntax looks like:
pscp.exe <source> <user>@<destination host>:<flash file name>
An example would be:
pscp.exe asa804-k8.bin email@example.com:asa804-k8.bin
I guess I will use this feature more often from now on.