Shutting down a firewall remotely via a password less script

You seem to have been around a lot of this area before. This is sort of related, regarding two sudo for different users.

Yeah this is different in that im executing a command as openhab, but logging in as another user. This is non interactive. Different to the example in the link youve posted

Why do you run the ssh command using sudo (sudo ssh ....)? There should be no need to do so. The ssh client is executed on your local openHab node, not on the pfsense node.

When generating the private/pub keys, were you logged in as user openhab?

Unless you run openHAB as user root (which you shouldn’t), this will not work. Normally, openHab will run as user openhab so you will need to generate the private/public key pair as user openhab (at least that is the easiest way to do it since they will then end up in the correct home directory). If your running openhabian, then the home directory for the openhab user is not /home/openhab/

The way works … because root has the ssh-keys & user openhab have access to sudo

I’m going to quote Rich here:

Anyone reading this who cannot ‘guess the rest’ should not follow the advise given in this thread. Anyone who can ‘guess the rest’ will understand that he/she should not follow the advise given in this thread.

I think marcel was correct to post that quote.

The whole idea of computer security is defense in depth. Why don’t we just run everything as root all the time? Why don’t we just log in as root instead of needing to sudo all the time? Why is there a a firewall on the host machine? Why are there file permissions?

It’s ALL to make it more difficult for an attacker to compromise a machine and to limit what they can do on a given machine if they are successful.

When you give the openhab user no password permission to run all commands, you may as well just run openHAB as root. When you run openHAB as root, if someone compromises the machine or compromises your account on myopenhab.org, they can literally do anything on your machine.

So no, the need to protect and limit what the openhab user can do is not limited to just those who expose their OH to the internet. That quote is applicable here as well as to the other thread. It’s a bad idea to give openHAB blanket sudo permissions. It’s a bad idea to run openHAB as root. And honestly, IMHO, it’s a bad idea to install and use the Exec binding. If I could, I’d disable the executeCommandLine Action too. Since I can’t, I rely on the Docker container to limit the damage that can be done should my openHAB get compromised.

1 Like

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!