Interacting With the Cisco ASA CLI Using the HTTPS Interface
Most people are familiar with interacting with the ASA over HTTPS to get captures off the box, but every CLI mode is available using a browser. There are a lot of handy practical situations where you’d want to do this, including simply avoiding using a steaming pile of Java. Below is the simplest way to both show off how this works, and one of the better usage cases:
https://x.x.x.x:port/exec/show run
Just drop in the IP address and port you’d normally use to access HTTPS/ASDM on your ASA. leave the spaces in the command, the ASA will take care of %20-ifying them. An HTTP basic auth box will pop up – just enter the credentials you’d normally use for HTTPS/ASDM access. You will be greeted by a web page with simply “show run” output. This is even more useful with incredibly verbose things like “show conn” or “show tech”. No more ASCII transfers in SecureCRT or worrying about right-click auto-pasting the whole output back into putty by mistake. It saves a ton of time if you’re like me, and you use screen or tmux with pretty much every session. Getting verbose output out of a tmux/screen session can be awful. Another great use:
https://x.x.x.x:port/exec/packet-tracer input inside icmp 192.168.254.254 8 0 8.8.8.8 detail
The above came up recently in IRC, and I find it to be a particularly good use case for direct HTTPS interaction. With packet-tracer, especially in verbose mode, I tend to need to do some correlation between different parts of the output. I find a web browser to be a much more convenient place to Ctrl+f, or just scroll around to different parts of the output.
As I mentioned up top, every CLI mode I can think of is available via the HTTPS interface…including config mode. Let’s say you’re on a machine in a freshly provisioned DMZ, and you need to get into the ASA and tweak some ACL settings or something, but the ticket monkeys forgot to include SSH access in your change request. Assuming you’re cool enough to not have to wait for a new change request to go through, you could do this:
https://x.x.x.x:port/exec/ssh 192.168.254.254 255.255.255.255 DMZ1
Note that “exec” is still there – it doesn’t change to “config” like you might expect. Using config mode in this way will obviously be a corner case, but it can come in handy nonetheless. I’ve used it a few times to enable telnet temporarily if I hit the “it says I’ve used all 5 SSH connections but none are actually used” bug where SSH sessions become orphaned and eventually none are available for actual use (CSCts72188 I believe, but I could be wrong…bug details on that ID are currently unavailable).
There are a couple caveats. Normally, you can type naturally as you would on the command line. But if you need to access a sub-config mode or use a command that includes the slash character, using the HTTPS interface is a little different. To access sub-config modes like interface config, you need to use a slash in the browser address bar instead of a space. And to use an actual “slash” character, you need to specify “%2F” in the browser address bar since the slash itself is a delimiter:
https://x.x.x.x:port/exec/interface Ethernet0%2F0/security-level 100
So, the above is the equivalent of issuing the following at the actual CLI:
interface Ethernet0/0
security-level 100
One of the coolest uses for accessing the CLI using HTTPS is scripting. You can use it on a Linux CLI or in scripts to get periodic output for something like perfmon. Or in cronjobs to get output from the box without having to fumble around with expect scripts. Note that in this case, you’ll probably have to irresponsibly specify authorization credentials inline. Or store them in a script if you want to dodge leaving auth traces in your history file. So be careful what systems you run scripts like this from.
lynx -auth=username:password --source "https://x.x.x.x:port/exec/show ver"
using “–source” here allows for use of CLI pipes and redirects or inclusion in loops:
while true ; do lynx -auth=username:password --source "https://x.x.x.x:port/exec/show perfmon" ; sleep 1 ; done
It’s probably safest to store auth creds in a script under /root/scrtipts/ or something like that where the unwashed public can’t get to it without pwning the box. A simple script like the one below will do the trick in most cases, using $1 to let you specify the command you want to run as a command line argument:
#!/bin/bash
lynx -auth=username:password --source "https://x.x.x.x:port/exec/$1"
Used as such:
[0][root@iggmcp:/root/scriptss]# ./asa_https.sh "show int ip brief"
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 X.X.X.X YES CONFIG up up
Ethernet0/1 unassigned YES unset up up
---SNIP---
Still have to use %2F in place of the slash character:
[0][root@iggmcp:/root/scriptss]# ./asa_https.sh "show int eth0%2F0"
Interface Ethernet0/0 "outside", is up, line protocol is up
Hardware is i82546GB rev03, BW 100 Mbps, DLY 100 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Input flow control is unsupported, output flow control is off
---SNIP---
Credit here goes to Magnus Mortensen via the Cisco TAC Security Podcast episode 18, which is surprisingly good for being a vendor podcast. I recommend it for those awful moments when you realize you’re up to current with Packet Pushers but you still need more audio Nerd-Kibble to keep your brain going.
Crossposted from my article at Packet Pushers
Recent Comments