Cisco IOS SSH – changing ports

I’ve happily had IOS devices for many years, coming from a networking background and originally being CCNA trained made the obscure nature of Cisco IOS logical (how on earth did Apple get away with pinching IOS from Cisco as a TLA anyway?)

Devices with external access are limited but sometimes it’s handy to leave SSH around. It’s protected by ACLs and works well enough until now. Attacks on SSH are getting more common and I can see them crossing the various devices I’m responsible for in waves, I was never a big one for changing the port but now it’s necessary I found it’s easy but has a gotcha.

 

It’s a three step process, step 3 being the gotcha:

  1. Tell the SSH to listen on another port (or ports)
  2. Tell the console to use that listener config
  3. Block port 22 in the ACL

The actual commands:

Start in the console and “conf t” then add the new port to listen on (2222 in this case)

ip ssh port 2222 rotary 1

Tell the remote console VTY to use the new config and make sure there’s a suitable ACL

line vty 0 15

 access-class 150 in
 rotary 1

Make sure the ACL blocks port 22

access-list 150 deny tcp any any eq 22

 

My problem was I did all this initial commands from the official guide https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/15-s/sec-usr-ssh-15-s-book/sec-ssh-term-line.html but didnt’ spot that changing the listener port doesn’t turn off the default port (22) and didn’t stop the attacks on that port. The ACL fixes that.

Obviously it’s not a full config and there are plenty of other tutorials on that if you can’t get SSH on your Cisco.

Tiny OpenWrt router

I’ve been quietly playing with OpenWRT on my old TP-Link wall wart routers WR802 and an old Edimax BR-6528n , the Edimax has proved too small but the last versions of the EU WR802 run OpenWRT quite well.

I found the routing functions to be good but the wireless bridging config seemed much flakier than the TP-Link firmware so I used some of the resources that FriedZombie has put up https://www.friedzombie.com/tplink-stripped-firmware/ whcih explain how to strip the bootloader and get back to TP-Link firmware. Initially I used one of the images on the site but later found it relatively easy to do it myself to the latest EU image using his instructions.

 

However I’ve now seen I’m only playing with toys compared to some of the hardware coming on to the market now. This USB-stick-alike has a 400 MHz QCA9331 SoC, 64 MB of RAM, and 16 MB of storage.

minirouter

Checkout DKE Consulting’s work with a USB Stick router running OpenWRT https://dkelabs.com/weaponizing-a-micro-router/ that’s going to be next on my acquisition list.

 

 

ARM Binaries for NAS’s

Just a short note for today. As a hacker of NAS boxes I often find it’s tricky to keep the original firmware and enhance it much. Many NAS’s have a thriving community of people working out how to get in, modify or replace firmware. I’d always suggest starting at NAS_Central first. Even if your specific NAS isn’t listed many of the articles are for similar devices and can offer clues on where to go.

Many, many people compile binaries for many purposes, and if you’re not into compiling or just want to add a simple command (SU, a decent IFCONFIG or something) just ripping a binary can be quick and effective as long as you understand dependencies. Often new binaries need newer flavours of linux on the box which gets tricky again. Understanding how different chips work can help.

One useful site I found recently Exploiting ARM binaries has some really good (and simple) background on some of the older ARM chips, their foibles and how to disassemble/run on QEMU

 

**Update 22/5/19 – NAS Central appears to be off air again since early 2019. You can look at much of the content with the Wayback machine: https://web.archive.org/web/20190314085609/nas-central.org/wiki/main_page **

 

DenyHosts Python and grumpy Ubuntu staff

denyhosts

I’m a keen user of Denyhosts to protect SSH boxes, especially on cheap NAS boxes with fixed libraries/distros. It’s runs on Python 2.3 and above and most of the cheap boxes are now capable of running that and you don’t need to try and match libraries and old versions to get something useful. I know there are newer tools available like fail2ban but DenyHosts can save you on a hacked NAS where no other options exist.

As part of my security practices (and sometimes going around SSH port blocking on corporate firewalls) I occasionally move SSH to other ports using “listenaddress” or “port” in sshd_config or by setting a NAT rule on the edge router. One symptom of this I’ve noticed with 80/443 (yes I know!) is that Denyhosts doesn’t automatically block “Bad protocol” hits as they’re not actually attempts to sign in. I take the view they’re still unwanted as they’re likely to be scanning ranges, and by definition could be back later to try SSH on the host they’ve found. I spotted the USERDEF_FAILED_ENTRY_REGEX in the denyhosts FAQ. I didn’t understand what a regex is as I know nothing about Python but it seemed the answer so I googled and found a rather odd response to the same question in the Ubuntu forums. Back in 2008 Anthro398 had a similar question and got shot down by a staffer as they didn’t seem to quite get it. I thought Anthro398 was perfectly sensible (am I wrong too??) but never got any help… just an argument. Now I get particularly annoyed at sort of attitude, but the good thing was Anthro398 had given a snippet of code –  USERDEF_FAILED_ENTRY_REGEX=sshd.*Bad protocol version identification.* from (::ffff:)?(?P<host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) which didn’t work but at least gave me something to go off.

Being a python and regex numnutz I also found the python regex checker to help me learn: pythex.org , pasting the code from Anthro398 into it plus a snip of my /var/log/messages containing the hits showed the code was broken. After a bit of reading, experimenting in pythex and trying in one of my denyhosts instances I found the mistake. Removing the leading sshd.* was part of the problem as denyhosts parses that elsewhere (don’t ask me I don’t know) then just a change of a : to a ? and it all burst into life! I also managed to lock my IP out of denyhosts by web browsing the box testing it!! As I’d maintained an SSH I could still edit the config and you may also want to look at this FAQ too if you do the same, just removing the IP from /etc/hosts.deny isn’t enough as denyhosts will pop it back in from its working files.

 

So thanks to Anthro398 for all your work, you were nearly there; I considered contributing to the thread but would have to register and then I’d probably get flamed for the temerity to think a little differently about how I set up systems. So I’ll just leave the correct regex here in case anyone wants to use it. Just stop denyhosts and modify denyhosts.cfg to include : USERDEF_FAILED_ENTRY_REGEX=Bad protocol version identification.* from (?:ffff:)?(?P<host>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) before restarting the service again.

All the ususal things apply – consider carefully the risks exposing any SSH or web on a box you may not be able to patch properly, the risk of losing the data on it versus the reason for having it there. Read up on SSH hardening, really really try and set up Key based authentication and disable passwords if you can, at least have key as the default!

 

Tenda F3 Router – oh the joy and the pain

I have a friend who relies on me for trying to rescue him from IT disasters, often of someone elses making. You know the type. Well the latest one got me into hidden serial ports and demonstrated how commodity routers can surprise you.

In the end he shipped me the box, as it goes it’s a nice little unit, badged underneath as “Wireless N300 Easy Setup Router” Model: F3. It was dead, nothing except a stoically solid “SYS” light and  a link light if you connected a device. I suspected flash issues.

The problem was the reset button, I’ve always found these cheap routers can be persuaded to go into a TFTP or Emergence upload mode with a web page to recover firmware, nope not this one despite repeated and varied combinations of reset and power. Using a static arp on a PC to try to get to the default ip (192.168.0.1) also couldn’t ellicit a response.

I’ve seen many tales of hidden serial/console ports in devices often for initial setup or debugging, long since removed by the time the design is finalised but I’d never been too keen to lear on a router that was already working so I had a perfect opportunity. I enlisted a friend to show me the ropes. We opened the device and were confronted with a tiny sircuit board and two chips. Two chips! I am old enough to remember 300bit modems the size of a shoe box and we have a wired/wifi 300N router on two chips, I thoguht there’s no way this is coming back but I was wrong. On the board were clearly four holes ready for a header plug, my previous research suggested this may be a serial port, despite the two chips there’s still a port. My mate spent ten minutes checking the voltage levels, making a quick check of the traces and soldering in a header. Another ten minutes with Putty and a USB-TTL adapter and we had a pulse. A quick flurry of info on power on and then a blank.

Reading the info, the device was obviously booting and trying to go to the flash then hanging for whatever reason but the odd thing was the IP address, not 192.168.0.1 but 192.168.1.58, at first I thought recovery address but I was wrong. After 10 minutes of power…text…ctrl-c.. swear.. repower we hit the ctrl-c at just the right time to get CFE prompt (CFE is a Broadcom low level interface with commands geared at loading and running flash: OpenWRT guide to CFE ). Armed with this, setting up a PC directly into the device I can ping the IP and get my replacement flash ready to go… but will the command work? Noo.. this cursing goes on for an hour, pinging, checking TFTP servers, firewalls, command line and each time getting a TFTP timeout. Scroling down the CFE wiki I notice the emergency web page. Open a browser to the 192.168.1.58 mystery address and there we have a very similar page. Upload the image and away! The image in question being the F3 image from the Tenda website.

So in essence, I needed a serial port to interrupt the boot process at low level so the web page became available to re-flash. Bit wonly on the desing front there!

The kicker came looking at the config, ALL the original config appeared to be there, SSID, keys, passwords were as set last time I’d seen the device working. The penny dropped. The 192.168.158 wasn’t a recovery IP it was the IP in NVRAM from the config. The reset button was no use at all in the state the router had got to, it was using the real config to try and recover itself! Not something you expect.

There was still a nagging thought that the config looked different last time. Even looking back at the support site http://www.tendacn.com/en/product/download/F3.html was odd, the software on the box was obviously Easy Setup but it wasn’t what it came with and the manual on the same site showed many more features. I didn’t get it until I found the F300 router http://www.tendacn.com/en/product/download/F300.html#Firmware well it looks the same, the manula looks very similar to the F3 and I have a serial prot to recover from a bad flash! Download the image, point the device at it and… upgrade! No complaining of wrong versions, no warning or blocking, jsut upgrade and double the feature set! I realised the device had has two SSID’s set as soon as I looked in the new web interface, and all the keys were still there from before the flash failed, despite all my attempts to reset them!

So for me the moral is, take time, read up, ask a friend but persevere. For a 30 Euro router, the F3/F300 can be a very thing, just don’t expect it to be easy to clear your settings.

I’m off to do more reading on Open-WRT for it.

 

Update: Much more Tenda firmware now here https://www.tendacn.com/en/service/download-cata-11.html and version numbers and dates seem to suggest a fundamental change in firmware which may explain the function reductions.