<commit_before><h2>ShellSquid</h2>

<pre>
At its core, shellsquid is just a dynamic and configurable http(s) reverse proxy. The intended purpose is to enable teams to share a single Internet facing interface and port when handling multiple reverse payloads ("shells").

The original version of shellsquid used customized payloads to determine routing, and was overly complex. This version uses hostnames and is much more straight forward. A common way of configuring payload routing is to register a single domain with a wildcard DNS record, and then use subdomains to route payloads.
</pre>

<h2>Dependencies</h2>
<pre>
None, shellsquid is written in Go and uses boltdb.
</pre>


<h2>Configuration</h2>
<p>Configuration is done via a JSON file in `config.json`. The following values are supported:
  <br>
  <pre>
  {
  "proxy": {
    "ssl": {
    "enabled": true,
    "listener": ":443",
    "key": "key.pem",
    "cert": "cert.pem"
    },
    "http": {
      "enabled": true,
      "listener": ":80"
    }
  },
  "admin": {
    "listener": ":1337",
    "key": "key.pem",
    "cert": "cert.pem"
  },
  "jwt_key": "<strong>insert secret key here</strong>",
  "bolt_db_file": "squid.db"
  }
</pre>
<pre>
You will need to generate a certificate and key files separately. For example, a self signed certificate can be generated using the the following syntax and should be stored in the root of the project directory:

openssl req -x509 -newkey rsa:2048 -nodes -keyout <strong>key.pem</strong> -out <strong>cert.pem</strong> -days XXX
</pre>
</p>


<h2>Starting the server</h2>
<pre>$ ./shellsquid</pre>

<h2>Metasploit Configuration</h2>
<pre>This version of shellsquid does not require any special handlers! There are still some considerations to make when configuring your multi-handler. The reason for these configurations it to control the `payload_uri` that is generated by the handler, we need that to output the address of our proxy and not the actual handler. Configuration steps:
</pre>
<ul>
  <li>set LHOST to the hostname of your record.</li>
  <li>set LPORT to the listening port of the proxy. If it's an http(s) payload and your proxy is configured to listen on 443, then set it to 443.</li>
  <li>use the advanced options of `ReverseListenerBindPort` and `ReverseListenerBindAddress` to set the actual interface and port for the handler to use.</li>
  <li>run like normal.</li>
</ul>
<h3>MSF Configuration Example</h3>
<pre>
It is easier to think of ShellSquid as a reverse HTTP proxy, such as NGINX. For example, an HTTP request is sent to NGINX based on a FQDN (e.g., foo.bar.com) along with the respective HTTP Host header. The NGINX proxy then routes the request to the appropriate application content.

ShellSquid is similar; the HTTP based reverse shell fires and connects back to ShellSquid with the LHOST payload set to a FQDN. It is important to note that ShellSquid can route numerous shells based on subdomain. So say we have the following list:

  * foo.bar.com
  * baz.bar.com
  * fud.bar.com

All of the these FQDNs would route based on their subdomain components. ShellSquid would then parse the HTTP Host header and route the connection to the actual MSF multi handler designated by the "show advanced" syntax within MetaSploit. The following images provide a sample configuration:

<img src="styles/images/msf_fqdn.png" style="width: 100%"/><br>
<strong>Setting the Proxy Listener to a FQDN</strong><br>
<img src="styles/images/msf_advanced.png" style="width: 100%"/><br>
<strong>Setting the Backend (i.e., shoveled/proxied) listener to the actual lhost and lport established in ShellSquid</strong>
</pre>

<h2>Security</h2>
<pre>
Authentication and authorization is performed using JSON Web Tokens ("JWT"). The administrative portion of the application is configured by default to listen on a separate port and interface than the http and https proxy handler. Access to the administrative interface is done using a username and password. Currently, all users have the same permissions and can change the passwords of other users. This is fully intentional, everyone is an admin. There didn't seem like there was much to be gained by having a finegrained permissions model.
</pre>

<h2>Development</h2>
<pre>
<strong>Server: </strong>The server is written in Go and uses boltdb. Configuration is done in `config.json`. This project uses godep for dependency management. To start the server:

# Install godep
$ go get github.com/tools/godep

# Run the server, all dependencies are managed and stored in the using godep in the Godeps directory<commit_msg>change images url<commit_after><h2>shellsquid</h2>

<pre>
At its core, shellsquid is just a dynamic and configurable http(s) reverse proxy. The intended purpose is to enable teams to share a single Internet facing interface and port when handling multiple reverse payloads ("shells").

The original version of shellsquid used customized payloads to determine routing, and was overly complex. This version uses hostnames and is much more straight forward. A common way of configuring payload routing is to register a single domain with a wildcard DNS record, and then use subdomains to route payloads.
</pre>

<h2>Dependencies</h2>
<pre>
None, shellsquid is written in Go and uses boltdb.
</pre>


<h2>Configuration</h2>
<p>Configuration is done via a JSON file in `config.json`. The following values are supported:
    <br>
    <pre>
  {
  "proxy": {
    "ssl": {
    "enabled": true,
    "listener": ":443",
    "key": "key.pem",
    "cert": "cert.pem"
    },
    "http": {
      "enabled": true,
      "listener": ":80"
    }
  },
  "admin": {
    "listener": ":1337",
    "key": "key.pem",
    "cert": "cert.pem"
  },
  "jwt_key": "<strong>insert secret key here</strong>",
  "bolt_db_file": "squid.db"
  }
</pre>
    <pre>
You will need to generate a certificate and key files separately. For example, a self signed certificate can be generated using the the following syntax and should be stored in the root of the project directory:

openssl req -x509 -newkey rsa:2048 -nodes -keyout <strong>key.pem</strong> -out <strong>cert.pem</strong> -days XXX
</pre>
</p>


<h2>Starting the server</h2>
<pre>$ ./shellsquid</pre>

<h2>Metasploit Configuration</h2>
<pre>This version of shellsquid does not require any special handlers! There are still some considerations to make when configuring your multi-handler. The reason for these configurations it to control the `payload_uri` that is generated by the handler, we need that to output the address of our proxy and not the actual handler. Configuration steps:
</pre>
<ul>
    <li>set LHOST to the hostname of your record.</li>
    <li>set LPORT to the listening port of the proxy. If it's an http(s) payload and your proxy is configured to listen on 443, then set it to 443.</li>
    <li>use the advanced options of `ReverseListenerBindPort` and `ReverseListenerBindAddress` to set the actual interface and port for the handler to use.</li>
    <li>run like normal.</li>
</ul>
<h3>MSF Configuration Example</h3>
<pre>
It is easier to think of shellSsuid as a reverse HTTP proxy, such as NGINX. For example, an HTTP request is sent to NGINX based on a FQDN (e.g., foo.bar.com) along with the respective HTTP Host header. The NGINX proxy then routes the request to the appropriate application content.

shellsquid is similar; the HTTP based reverse shell fires and connects back to shellsquid with the LHOST payload set to a FQDN. It is important to note that shellsquid can route numerous shells based on subdomain. So say we have the following list:

  * foo.bar.com
  * baz.bar.com
  * fud.bar.com

All of the these FQDNs would route based on their subdomain components. shellsquid would then parse the HTTP Host header and route the connection to the actual MSF multi-handler designated by the "show advanced" syntax within MetaSploit. The following images provide a sample configuration:

<img src="images/msf_fqdn.png" style="width: 100%"/><br>
<strong>Setting the Proxy Listener to a FQDN</strong><br>
<img src="images/msf_advanced.png" style="width: 100%"/><br>
<strong>Setting the Backend (i.e., shoveled/proxied) listener to the actual lhost and lport established in shellsquid</strong>
</pre>

<h2>Security</h2>
<pre>
Authentication and authorization is performed using JSON Web Tokens ("JWT"). The administrative portion of the application is configured by default to listen on a separate port and interface than the http and https proxy handler. Access to the administrative interface is done using a username and password. Currently, all users have the same permissions and can change the passwords of other users. This is fully intentional, everyone is an admin. There didn't seem like there was much to be gained by having a finegrained permissions model.
</pre>

<h2>Development</h2>
<pre>
<strong>Server: </strong>The server is written in Go and uses boltdb. Configuration is done in `config.json`. This project uses godep for dependency management. To start the server:

# Install godep
$ go get github.com/tools/godep

# Run the server, all dependencies are managed and stored in the using godep in the Godeps directory
{'fraction_non_alphanumeric': 0.08560523446019629, 'fraction_numerical': 0.009596510359869139, 'mean_word_length': 4.291979226774379, 'pattern_counts': {'":': 36, '<': 129, '<?xml version=': 0, '>': 129, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '89503', 'n_tokens_mistral': 2715, 'n_tokens_neox': 2573, 'n_words': 1270}