Shutting down a firewall remotely via a password less script

I got this working, ill post my solution today

Yes I agree with you, of course sudo can be a problem, but other mistakes have to be made that it becomes dangerous. Smarthome and other critical applications should run in an isolated network.

Even without sudo, a compromised openhab is not a good scenario!

If we now create ssh-keys for the user Openhab to the firewall, then it would work (without the sudo problem on the OH system) But the whole thing would be a security problem, because if Openhab is attacked, one would be able to log in to the firewall. On the firewall we have sudo right again …

I think we should start with the safety in other places!

Securing a system is a wholistic activity. You don’t start here and ignore over there. And building a fort around your network and solely relying on that for your security is never sufficient.

I think this is my main point. It’s not just the sudoers that I have a problem with. The entire scenario is shady as hell and i’d have my credentials revoked if I ever suggested anything remotely like this scenario professionally.

So what would be an alternative if you just had to control a firewall from OH? What if you installed a daemon on the firewall that you can attentive with and only allows this one command? Then you are not exposing your OH machine itself through the executecommandline and sudo not are you necessarily exposing the firewall in the same way, particularly if the shutdown command is modified to allow what ever non privileged user the daemon ribs as to issue the shutdown command.

But that’s more work.

I have revoke the Posting … all happy now?

Now its your turn! :wink:

But here is the big difference. I’m not advocating giving some service which has some exposure to the outside world (through myopenhab.org) running inside a LAN permission to log into the firewall, the thing that protects your LAN from attack, and change the firewall’s settings in those posts. That’s the shady part. That’s locking your door but leaving the key under the welcome mat.

Giving openHAB sudo permission with no password, on specified commands, while not particularly safe, is no where near as risky as that. So I have no qualms about giving advice on how to set up the openhab user to use sudo.

Rich I did not do anything else! I have nothing connected with the outside world! I have suggested the same as you in connection with the Exec Binding!

I do not suggest to connect a service with the outside world. Here are the lines I suggested:

Here my results … it works :slight_smile:

ToDo:

sudo ssh-keygen -t rsa
sudo ssh-copy-id -i /root/.ssh/id_rsa.pub kris@192.168.1.254

sudo nano -f /etc/sudoers.d/010_pi-nopasswd

openhab ALL=(ALL) NOPASSWD: ALL

sudo /etc/init.d/sudo restart

sudo nano /etc/openhab2/rules/shutdown.rules

rule "Shutdown Firewall"
  when
      Item shutdownfirewall changed to ON
  then
      shutdownfirewall.postUpdate(OFF)
      Thread::sleep(100)
      executeCommandLine("sudo bash /etc/openhab2/scripts/shutdown.sh")
  end

sudo nano /etc/openhab2/scripts/firewall_shutdown.sh

  #!/bin/bash
  ssh kris@192.168.1.254 'sudo shutdown -h now'

sudo chown openhab:openhab /etc/openhab2/scripts/firewall_shutdown.sh
sudo chmod u+x /etc/openhab2/scripts/firewall_shutdown.sh

1 Like

???

You contradict yourself there?

First you say sudo is a bad idea and later you say that you have no problem with sudo for openhab …

If you use openHAB with myopenhab.org, your openHAB is connected to the outside world.

I have no doubt that it works.

This gives ssh keys to root. There is nothing wrong with that, per se, but typically there is no reason to give root permission to log into another machine. It’s far better to give openhab the ssh certs to log into the other machine and then give sudo permission on that other machine permission for the login user to perform some action.

Don’t sudo to ssh. There is no need to and it only opens vulnerabilities because you are giving root permission to do something it normally wouldn’t have permission to do and because root isn’t loginable, you are giving some other user (openhab) sudo permissions it would not otherwise need.

Never ever edit a sudoers file without using visudo. If you get one character wrong you will lock yourself out of your machine preventing any user from running a command with sudo and you will have to mount your media on some other machine to fix the error in the sudoer’s file.

This is a big no no. You may as well run openHAB as root. You have given permission for the openhabn user, a user whose only reason for existing is to limit what the openHAB process can do if it has an error or becomes compromised, permission to run any command with sudo without requiring a password. And in this case, if I understand correctly, you are only giving openhab sudo permission so it can ssh to the firewall as root, which, as already discussed, is unnecessary. Not only have you given openhab permission to run a command as root that doesn’t need to be run as root, you’ve given it permission to run all commands as root.

You ran it after giving openhab sudo permission? There is no need to reboot the machine after editing sudoers.

The sudo bash is unnecessary. The #!/bin/bash in the script will start up a bash shell for you.

If you just give the openhab user the ssh certs then you can avoid all the sudos on the OH machine and leave that vulnerability closed.

But then we come to the big problem I have with the whole scenario. Assuming your openHAB is exposed to myopenhab.org the following becomes possible:

  1. Attacker compromises your account on myopenhab.org or myopenhab.org itself becomes compromised giving the attacker access to your OH’s REST API.

  2. Attacker creates a Rule through the REST API using executeCommandLine, let’s say val results = executeCommandLine("sudo ls"); logInfo("bad guy", results) and then another to grep for the results from the logs and send that in some way. There are all sorts of options.

  3. “Hmmm, that command succeeded, no password required, I can run anything as root I bet.”

  4. Attacker crafts a new Rule with a new executeCommandLine to download and install a Remote Access Tool, may with a Root Kit.

  5. Attacker starts to look around and notices this script that logs into your firewall. Jackpot! Attacker uses those credentials and certificates to log into your firewall and opens up a port so they can directly access your LAN. They look at the DHCP leases to see what other machines are on your network and go about compromising all of your other machines.

But, had you not given openhab sudo permission on all commands, had you not configured openHAB to log in a shutdown your firewall, surveil and compromise your entire LAN would be much more difficult or maybe even impossible to accomplish and keep secret from you.

This is why I say the whole thing is shady. There should be no path from openHAB to your firewall that an attacker could compromise. Don’t even give the openhab user the certificates to log in to the firewall. Isolate the openhab user and give it as few permissions to do things as feasible and no more. Don’t allow openHAB to control important security related infrastructure to your LAN unless your openHAB is completely isolated (i.e. no myopenhab.org connection, no access to the Internet on that machine to download stuff).

A better way to shutdown your firewall remotely is to just use the firewall’s API and if you have to do it remotely, set up a VPN. Or put the firewall on a controllable outlet.

No I did not. I said giving openhab sudo permission ON ALL COMMANDS is a bad idea. Giving openhab sudo permission on SPECIFIC COMMANDS is a less bad idea.

I have fewer concerns about giving the openhab user permission on just one or two commands (in your case only /usr/bin/ssh). But as I said, it’s pointless to give it permission for ssh, and my whole concern doesn’t really have to do with the sudo in the first place. My concern is making it so openHAB can control your firewall.

In your case, the openhab users shouldn’t have any sudo permissions in the first place because it’s pointless to sudo only to ssh into another machine. It opens up vulnerabilities and gives you no added capabilities.

I give it up … you’re right and I’m stupid …

As last … ssh-keys on a compromised computer is always a big problem.

I understand that it makes attackers easier with this configuration. But if I offer the attacker no point to attack, then it is not dangerous either.

IoT just does not belong directly to the internet!

You are not using myopenhab.org then I must assume.

The first run of this command lets you decide which editor to use, so the file will not be corrupted!

Critical systems do not belong in any cloud!
I do not use the service myopenhab.org!

Yes it will. You need to run

sudo visudo -f /etc/sudoers.d/010_pi-nopassowrd

You are running nano instead of visudo. When you edit the file without using visudo there are no checks on the file before it is made active. If you have a typo or syntax error it will break your sudo.

The first time you run visudo, yes indeed, it lets you choose what editor visudo will use. But that doesn’t mean you can just use that editor to edit the file after that. You must always go through visudo.

So back to a solution, based on the discussion, i’d assume this:

sudo ssh-keygen -t rsa
sudo ssh-copy-id -i /root/.ssh/id_rsa.pub kris@192.168.1.254

`sudo visudo

openhab ALL=(ALL) NOPASSWD:  /sbin/poweroff, /sbin/reboot, /sbin/shutdown

sudo nano /etc/openhab2/rules/shutdown.rules

rule "Shutdown Firewall"
  when
      Item shutdownfirewall changed to ON
  then
      shutdownfirewall.postUpdate(OFF)
      Thread::sleep(100)
      executeCommandLine("sudo bash /etc/openhab2/scripts/shutdown.sh")
  end

sudo nano /etc/openhab2/scripts/firewall_shutdown.sh

  #!/bin/bash
  ssh kris@192.168.1.254 'shutdown -h now'

sudo chown openhab:openhab /etc/openhab2/scripts/firewall_shutdown.sh
sudo chmod u+x /etc/openhab2/scripts/firewall_shutdown.sh

Of course you are right with visudo … I was (for whatever reason) at the crontab …

sudo crontab -e. … here comes the editor selection.

If you give the openHAB user the ssh certs there is no reason to give the openhab user any sudo permissions at all.

But as written, you need to give the openhab user sudo permissions to run the ssh command only. Presumably the Kris user on the firewall already has sudo permission to call shutdown. If not, you need to edit the sudoers on the firewall to give user kris those permissions.

1 Like

Can someone clean up this thread and remove all the chat and just post a working solution?

The short answer is no. I don’t think it is the place of any moderator to “clean” up any thread without the permission of each and every poster, in which case they can delete their own posts.

As far as I can tell, there is no single post here that is not related to the OP.

There are examples of everything you need in the thread above.

  1. Give the openhab user the ssh certificates to log into the firewall. They will go in ~openhab/.ssh which is usually /var/lib/openhab2.
  2. Create a shell script with the ssh and the command just like in Kevin’s posts only do not use sudo to run ssh.
  3. Make sure the user kris has sudo permissions to run the shutdown command on the firewall, which seems to be the case in the OP.

If you want clarity, you can add the solution to the OP or post a reply with the solution and check the box to mark it as the solution.

All done, and it works. However the results from the log output show something different

results- Permission denied, please try again.
Permission denied, please try again.

But the Firewall reboots etc.

rule "Shutdown VoIP"
  when
      Item shutdownvoip changed to ON
  then
      shutdownvoip.postUpdate(OFF)
      Thread::sleep(100)
      executeCommandLine("bash /etc/openhab2/scripts/shutdown_voip.sh")
  end

19:00:33.328 [INFO ] [clipse.smarthome.io.net.exec.ExecUtil] - executed commandLine 'sudo bash /etc/openhab2/scripts/voip_restart.sh'
19:00:33.479 [INFO ] [lipse.smarthome.model.script.exectest] - results- Permission denied, please try again.
Permission denied, please try again.
openhab@192.168.1.6: Permission denied (publi