[SOLVED] Serial Port RS-232 - Securing console and preventing lockout

Installing and Using OpenWrt
1

Hello all,

I have a device that has an installed and externally-exposed Serial port (MikroTik Routerboard RH433AH). Physical access to the device cannot be totally secured in a manner that would prevent someone from connecting a Serial cable.

  • Is there a way to configure the device to present a prompt for username and/or password when using the Serial port?

I understand that if I were to loose or forget my credentials, this would require me to perform either a button or screwdriver reset.

  • I also need to know if both reset procedures work with the OpenWRT firmware?

This link implies that I'd have to recompile Busybox - meaning, a custom firmware has to be made: https://openwrt.org/docs/guide-user/security/serial.console.password

The doc also states to edit a line in /etc/inittab; but this appears to has been moved to /usr/libexec/login.sh

Does anyone have any updated information on what's really needed?

1 Like
2

If the device requires authentication, it is protected.

Implementing a Serial Port Redirector may be a solution.

3

Huh???

If I connect a Serial cable to the RS-232 port, there is no authentication...I get the LEDE prompt...that's what I wish to enable.

Tell me more about this...

4

Looks to me that you can control it through UCI by setting ttylogin to 1, though I haven't confirmed:
/etc/inittab

::sysinit:/etc/init.d/rcS S boot
::shutdown:/etc/init.d/rcS K shutdown
::askconsole:/usr/libexec/login.sh

/usr/libexec/login.sh

#!/bin/sh

[ "$(uci -q get system.@system[0].ttylogin)" == 1 ] || exec /bin/ash --login

exec /bin/login

Edit: I don't know that I'd want busybox to be "suid" even on a locked-down box. You might want to look at disabling the console entirely when not in failsafe mode. /bin/false might be your ticket to that.

2 Likes
5

All the suggestions above deal with openWRT OS.

These dont solve the problem of bad actors using the bootloader to install a new firmware. You need physical security or a tamper proof seal in addition to the above suggestions

1 Like
6

:star_struck:

To be honest...I thought about that too, and the tamper proof seal is a good idea....otherwise, I'm not concerned about that...everything else I can provide metrics to show that it's been tampered with...as long as the running OS isn't accessed.

In most cases...to 'trust' the device again, you would re-flash with trusted firmware and re-upload your config.

I do want to know more about the backup bootloader...does anyone have a link? I also need to know if it updates with the last OEM firmware upgrade (it appears the main bootloader was).

I'll be honest..I thought it meant that......and I saw no OpenWRT doc page that mentioned:

OK!

/etc/config/system:

config system
option ttylogin '1'

THANK YOU...AGAIN; I ASSUMED (and saw the code referenced enabling...I didn't read hard enough that it was just a UCI line...) BUT NO DOCUMENTATION MENTIONS THE PURPOSE OF THAT OPTION!

I now receive for the default hostname:

Thanks @jeff!!!

LEDE login:

And failsafe still works:

================= FAILSAFE MODE active ================                         
special commands:                                                               
* firstboot          reset settings to factory defaults                         
* mount_root     mount root-partition with config files                         
                                                                                
after mount_root:                                                               
* passwd                         change root's password                         
* /etc/config               directory with config files                         
                                                                                
for more help see:                                                              
http://wiki.openwrt.org/doc/howto/generic.failsafe                              
=======================================================                         
                                                                                
root@(none):/#
1 Like
7

I'm not sure this is solved....as the console still isn't secure...

This means the configs can be accessed still...without a reflash of the firmware???

  • Someone could change it back to 0
  • I assume a Dropdear key and password could be added, and my device could be PWNED...

I think...I need to ask, how do I disable the boot-up failsafe...is it possible??? And would it disable other methods (e.g. failsafe via button and reset jumper functions...what do the buttons do!!!)?

8

Try removing the following line from the reset script in /etc/rc.button

jffs2reset -y && reboot &

Credited to this OpenWrt thread…

https://forum.openwrt.org/viewtopic.php?id=50277

9

It seems this setting controls erasure and reset on a running machine...??? I'm actually OK with that...it's another good to know about the config, tho!!!

In most 'commercial' routers...once it's been configured, there's only one ONLINE method to access the config saved on the device:

  • The username and password

The workaround @jeff gave me fixed only one thing...what's called the 'running configuration.'

If I booted the device over network and made a custom firmware every time I made a config change, that would be fine. I'm worried about the following security concern I see for OpenWRT as an OS:

This assumes that the hacker has access to the devices (which sticks to my thread about console access)...and just the general nature of the security of PRODUCTION routers:

  • With OpenWRT flashed on a device
  • With an exposed console port
  • you simply hit f and [ENTER]
  • you then mount by: mount_root
  • the configs can be accessed...
  1. How can I fix this?
  2. Is disabling the failsafe function on console related to disabling it with with the reset button and screwdriver (if that exists)?
  3. How do I disable both?
  4. Will that disable erasure of configs...and how is that done with the button and screwdriver methods???

At this point, I can test erasure of configs...as I assume I should press it approximately when I hear the beep after the bootloader begins loading the Kernel.

Basically...can I make FAILSAFE DISAPPEAR without disabling erasure and reset???

10

Whoa! Maybe time to back up a bit...

First off, what are you trying to achieve and why?

You don't have to answer here, but what is sooooo valuable about that router or what it is protecting that you're going to such extremes to try to protect a cheap piece of consumer-grade hardware running what is basically a consumer OS? This is coming from someone that was paranoid enough to be running isolated VLANs for IoT devices even before they were called IoT.

Next, there is no such thing as "completely secure". There is only the ability to lengthen the time it takes for someone to achieve the goal. Safes are rated in the number of hours it would likely take for someone to gain access. You either have to make it hard enough that it isn't worth it for them to break into yours, that you'll catch them before they do, or that yours is significantly harder than the next guy's of equivalent value.

Then there's that most people concerned with security know that you can never secure a computer that you can't control physical access to.

If what you're protecting is really that valuable, go buy some commercial gear, locked cages for it, external antennas, and put your cabling into steel conduit.

Oh yeah, you're gluing your Ethernet cables into the router, right?

Want to lock down OpenWRT? There is only so far you can go. No r/w filesystem, remote logging, replace dropbear with OpenSSH, only allow keyed access with 802.11X port-level authentication, no root login, strip out every executable you don't absolutely need,... but it's still not really a secure system. Meh, go with FreeBSD with kern.securelevel cranked up running off optical media or, if you really insist, Linux with SELinux in fully enforcing mode. Better get a couple network sniffers and firewalls to protect it as well, and get an IDS running.

Extreme, perhaps, but I want to get you to laugh yourself back to reality. It's a $100 / 100€ -class consumer router.

What to you really need?

1 Like
11

The device ran MikroTik and never had such an issue...I honestly thought a custom firmware with failsafe OFF would be easy...

I simply want someone not to be able to access the device, save of de-sodering the chip to see the configs.

All other common methods just lead to a rest to default config.

12

So...there's no method to disable failsafe without also disabling the reset of the filesystem???

13

Yeah, there weren't any serious vulnerabilities in the MikroTik firmware, and it was so secure you could trust them when you accessed it with your Windows PC. :wink:

OK, think through this and the implications. You want to disable the ability for the device to boot into a privileged mode where its potentially read-only memory can be altered. You, I assume, wisely don't want a phase in the bootloader where it goes out and retrieves firmware from another source.

You're effectively asking for a write-once device. Once you've configured it, you're done.

If that's really the case, you're looking at the wrong hardware and aren't needing the upgrade and configuration abilities of a consumer-targeted OS.

14

So you can or cannot disable failsafe: yes or no??

If so, how...a setting, a re-compile?

This isn't Fort Knox...I just want a smart kid to not be able to:

Press the [f] key and hit [enter] to enter failsafe mode

And still be able to do a reset of the flash. I'm not talking about a N$@-certified router, here.

LOL...thats why I flashed it with OpenWRT...but it honestly might be in a remote place for long unattended periods...that was what this carrier-grade device was made for.

If it's read only...how can it be altered???

How do you ALL keep someone from reading the private keys of your VPN's, SSH, HTTPS servers, etc.???

15

Not being snarky, but realistically, by limiting physical access to the "boxes" and not using OpenWRT for anything but a dumb AP and using a "full" OS for all services.

On more secure OS implementations, the disks can be forced by the kernel to be read-only, and perhaps allow certain files to be append-only (log files, for example). You can still boot to a lower kern.securelevel later to manage the box, but you can never reduce the kern.securelevel of a running machine.

2 Likes
16

I'm lost at why you keep talking about the running machine, though. It just seems to be just avoiding a simple removal of f [ENTER] during boot...and making it seem like I'm asking for something "ultra-secure..." again, I really thought a line in code and a recompile was the hardest thing I would be told to do.

I'll settle for this, the option ttylogin '1' will do if failsafe cannot be taken out...

It seems you are, a simple yes or no would do...so...to anyone else...

Is there some line in code or configs that will turn off the simple process during boot that allows you to hit f [ENTER]? Nothing hard, a yes or no will do.

17

Have you looked at MiroTik's documentation on serial port usage?

https://wiki.mikrotik.com/wiki/Serial_Port_Usage

18

??

I'm running OpenWRT...AHHH!!

This is rerouting the serial, right???

HOW??? (Using OpenWRT...if failsafe it can't be turned off by code or config...but this still happens after boot, right?)

That information will be OK with me, I otherwise understand the other security "limits" of having direct access to a Linux console or its hardware (like any other OS).

19

My apologies, words can be taken many ways and i wanted to frame my statement as a serious answer. With the level of lock-down you're looking for, you'll likely need to patch the start-up code. If you lock down the box that hard, make sure you can recover with the first-stage boot loader or you'll have a brick if you make any config errors. You also should completely replace dropbox with OpenSSH, only allow keyed access, and get rid of LuCI, to start. Getting rid of the overlay and only using flash would be on the list too. You can only get so far with OpenWRT or any other similar OS.

What you're asking to do will make maintaining the box a nightmare. One mistake and you may have hours of struggle to get it running again, if you even can.

1 Like
20

Is this going to fit the bill for you?
CONFIG_TARGET_PREINIT_DISABLE_FAILSAFE=y

I’m not sure if it protects the serial port as well.

Note that if you ever needed failsafe in the future you’d be stuffed...

1 Like