path: root/posts/2021-11-28-write-your-own-ssh-tarpit-in-rust-with-async-std.php

<h1>Write Your Own SSH Tarpit in Rust with async-std</h1>


<p class="description">
	A software tarpit is simple and fun. Long story short, it's sort of a reverse denial-of-service attack. It usually works by inserting an intentional, arbitrary delay in responding to malicious clients, thus "wasting their time and resources." I recently learned about <a href="https://github.com/skeeto/endlessh"><code>endlessh</code></a>, an SSH tarpit. I decided it would be a fun exercise to use Rust's <code>async-std</code> library to write an SSH tarpit of my own, with my own personal <em>flair</em>. If you want to learn more about <code>endlessh</code> or SSH tarpits I highly recommend reading <a href="https://nullprogram.com/blog/2019/03/22/">this blog post</a> by the <code>endlessh</code> author.
</p>

<h2>Goals</h2>

<p>
	So what does an SSH tarpit need to do? Basically, an SSH tarpit is a TCP listener that very slowly writes a never-ending SSH banner back to the client. This all happens pre-login, so no fancy SSH libraries are needed. Really, the program just needs to write bytes [slowly] back to the incoming connection and never offer up the chance to authenticate (see the blog post above to learn more). So now I'm getting a to-do list together. My program needs to...
</p>

<ol>
	<li>Listen for incoming TCP connections on a given port</li>
	<li>Upon receiving an incoming connection, write some data to the TCP stream</li>
	<li>Wait a little bit (say 1-10 seconds) and then repeat step 2</li>
	<li>Upon client disconnect, continue working on other connections and listening for new ones</li>
	<li>Handle many of these connections at the same time with few resources</li>
</ol>

<p>
	Additionally, to spruce things up and have more fun, I'm adding the following requirements:
</p>

<ul>
	<li>The listening port should be user-configurable (to make debugging easier)</li>
	<li>Client connection and disconnection events are logged, so I can see who is stuck in the pit and when</li>
	<li><em>The data written back to the client should be user-configurable</em></li>
	<li>The data is written one word at a time</li>
</ul>

<p>
	That's right. It's probably a waste of resources, but I want to be able to feed the client whatever information I want. For example, I want to be able to pipe a Unix Fortune across the network to the client very slowly. I want to relish in the knowledge that if the client manually debugs the data coming down the pipe, they'll see their fortune.
</p>

<h2>Implementation</h2>

<p>
	I've chosen Rust and the recently-stabilized <a href="https://async.rs/"><code>async-std</code></a> library for a variety of reasons. First, I like Rust. It's a good language. Second, <code>async-std</code> offers an asynchronous task-switching runtime much like Python's <code>asyncio</code>, or even JavaScript's <code>Promise</code> (even though things work a little differently under the hood). Long story short, it allows for easy concurrent programming with few resources and high performance. Everything I could want, really. It also comes with a variety of useful standard library API features reimplemented as asynchronous tasks.
</p>

<p>
	For starters, I need to include <code>async-std</code> as a dependency. I'm also going to pull in <a href="https://docs.rs/anyhow/1.0.44/anyhow/"><code>anyhow</code></a> for friendlier error handling.
</p>

<p>
	<a href="https://git.53hor.net/53hornet/fortune-pit/tree/Cargo.toml?id=ee0cf0bb9ccee29a5ac7f8cdc1bfd43dde8b8791">Cargo.toml:</a>
<pre>
<code>
[package]
name = "fortune-pit"
version = "0.1.0"
edition = "2018"

[dependencies.async-std]
version = "1"
features = ["attributes"]

[dependencies.anyhow]
version = "1"
</code>
</pre>
</p>

<p>
	Now I've gotta actually write some code. I already said I wanted to listen for incoming TCP connections, so I'll start with a <code>TcpListener</code>.

<pre>
<code>
use anyhow::Result;
use async_std::net::TcpListener;

#[async_std::main]
async fn main() -> Result<()> {
    let listener = TcpListener::bind("0.0.0.0:2222").await?;
    Ok(())
}
</code>
</pre>

Better yet, I'll make the bind port configurable at runtime. In a live environment, it would be best to run this on port 22. But for testing purposes, as a non-root user, I'll run it on 2222. These changes will let me do that at will. I'll also print a nicer error message if anything goes wrong here.
</p>

<p>
<pre>
<code>
use anyhow::{Context, Result};
use async_std::net::{Ipv4Addr, SocketAddrV4, TcpListener};
use std::env;

#[async_std::main]
async fn main() -> Result<()> {
    let listener = TcpListener::bind(read_addr()?)
        .await
        .with_context(|| "tarpit: failed to bind TCP listener")?;
    Ok(())
}

fn read_addr() -> Result<SocketAddrV4> {
    let port = env::args()
        .nth(1)
        .map(|arg| arg.parse())
        .unwrap_or(Ok(22))
        .with_context(|| "tarpit: failed to parse bind port")?;

    Ok(SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), port))
}
</code>
</pre>

There. Slightly more complicated, but much more convenient.
</p>

<p>
	Now I need to actually do something with my <code>TcpListener</code>. I'll loop over incoming connections and open streams for all of them. Then I'll write something to those streams and close them.

<pre>
<code>
use anyhow::{Context, Result};
use async_std::{
    io::prelude::*,
    net::{Ipv4Addr, SocketAddrV4, TcpListener},
    prelude::*,
};
use std::env;

#[async_std::main]
async fn main() -> Result<()> {
    let listener = TcpListener::bind(read_addr()?)
        .await
        .with_context(|| "tarpit: failed to bind TCP listener")?;

    let mut incoming = listener.incoming();
    while let Some(stream) = incoming.next().await {
        let mut stream = stream?;
        writeln!(stream, "Here's your fortune!").await?;
    }

    Ok(())
}

fn read_addr() -> Result<SocketAddrV4> {
    let port = env::args()
        .nth(1)
        .map(|arg| arg.parse())
        .unwrap_or(Ok(22))
        .with_context(|| "tarpit: failed to parse bind port")?;

    Ok(SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), port))
}
</code>
</pre>

And it works! If I <code>cargo run -- 2222</code>, passing my port as the first argument, I get a very basic TCP server. I can test it with <code>nc(1)</code>.

<pre>
<code>
$ nc localhost 2222
Here's your fortune!
^C
</code>
</pre>
</p>

<p>
	Great. But not there yet. First of all, I want the user to pick what gets written. Second, my client immediately receives a response. I want to keep feeding information to the client over and over until it gives up. I don't want it to time out waiting for nothing.
</p>

<p>
	So let's read in whatever the user wants to send along on STDIN. I thought this would be better than reading a file because it's really easy to send files to STDIN with pipes or redirection. It also lets you write the output of commands like <code>fortune(6)</code>.

<pre>
<code>
async fn read_banner() -> Result<String> {
    let mut banner = String::new();
    io::stdin()
        .read_to_string(&mut banner)
        .await
        .with_context(|| "tarpit: failed to read banner")?;
    Ok(banner)
}
</code>
</pre>

I can then read that banner in <code>main()</code>:

<pre>
<code>
let banner = read_banner().await?;
</code>
</pre>
</p>

<p>
	Now comes the tarpit part, continuously writing that banner to the client slowly until they disconnect. I'll write a <code>handler()</code> function that will spawn with every new client connection instead of doing everything in the closure in <code>main()</code>. The handler will accept a new client's <code>TcpStream</code> and a borrow-able reference to the banner. The first thing I'll do is read the client's address. It's more fun if we can see who is connected and how long they've been stuck. Then I'll log that to STDERR. Finally, I'll loop over every whitespace-separated word in the banner forever, writing a single word at a time to the stream and sleeping between each word for a predefined duration. If I can no longer write to the client, I'll assume they've disconnected and bail out. We don't want our tarpit to trap our system in itself.

<pre>
<code>
static DURATION: Duration = Duration::from_secs(1);

async fn handler(mut stream: TcpStream, banner: Arc<String>) {
    let peer_addr = stream
        .peer_addr()
        .map(|p| p.to_string())
        .unwrap_or_else(|_| String::from("(unknown)"));
    eprintln!("connected\t{}", peer_addr);
    for word in banner.split_inclusive(char::is_whitespace).cycle() {
        if stream.write_all(word.as_bytes()).await.is_err() {
            eprintln!("disconnected\t{}", peer_addr);
            return;
        }
        task::sleep(DURATION).await;
    }
}
</code>
</pre>

Note: I'm using an <code>Arc</code> so that all of my asynchronous tasks can read from the same underlying banner data instead of cloning it.
</p>

<h2>Altogether Now</h2>

<a href="https://git.53hor.net/53hornet/fortune-pit/tree/src/main.rs?id=ee0cf0bb9ccee29a5ac7f8cdc1bfd43dde8b8791">Here is the entire program (click for Git)</a>.

<pre>
<code>
use anyhow::{Context, Result};
use async_std::{
    io,
    io::prelude::*,
    net::{Ipv4Addr, SocketAddrV4, TcpListener, TcpStream},
    prelude::*,
    task,
};
use std::{env, sync::Arc, time::Duration};

static DURATION: Duration = Duration::from_secs(1);

/// Listens for incoming TCP connections and handles them.
#[async_std::main]
async fn main() -> Result<()> {
    let listener = TcpListener::bind(read_addr()?)
        .await
        .with_context(|| "tarpit: failed to bind TCP listener")?;

    let banner = Arc::new(read_banner().await?);

    let mut incoming = listener.incoming();
    while let Some(stream) = incoming.next().await {
        match stream {
            Err(e) => {
                eprintln!("error\t{}", e);
                continue;
            }
            Ok(s) => {
                let banner = banner.clone();
                task::spawn(handler(s, banner));
            }
        }
    }

    Ok(())
}

/// Handles a single TCP connection, continuously writing banner to the TCP stream sloooooowly.
async fn handler(mut stream: TcpStream, banner: Arc<String>) {
    let peer_addr = stream
        .peer_addr()
        .map(|p| p.to_string())
        .unwrap_or_else(|_| String::from("(unknown)"));

    eprintln!("connected\t{}", peer_addr);

    for word in banner.split_inclusive(char::is_whitespace).cycle() {
        if stream.write_all(word.as_bytes()).await.is_err() {
            eprintln!("disconnected\t{}", peer_addr);
            return;
        }
        task::sleep(DURATION).await;
    }
}

/// Reads address port to bind to from first arguent.
fn read_addr() -> Result<SocketAddrV4> {
    let port = env::args()
        .nth(1)
        .map(|arg| arg.parse())
        .unwrap_or(Ok(22))
        .with_context(|| "tarpit: failed to parse bind port")?;

    Ok(SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), port))
}

/// Reads banner to be written to client from STDIN.
async fn read_banner() -> Result<String> {
    let mut banner = String::new();
    io::stdin()
        .read_to_string(&mut banner)
        .await
        .with_context(|| "tarpit: failed to read banner")?;
    Ok(banner)
}
</code>
</pre>

<h2>Execution</h2>

<p>
	Now let's have a laugh. For my banner, I've selected the entirety of Michael Crichton's <em>Jurassic Park</em>:

<pre>
<code>
$ head jp.txt
"The InGen Incident"

The late twentieth century has witnessed a scientific gold rush of astonishing proportions: the
headlong and furious haste to commercialize genetic engineering. This enterprise has proceeded
so rapidly-with so little outside commentary-that its dimensions and implications are hardly
understood at all.
Biotechnology promises the greatest revolution in human history. By the end of this decade, it
will have outdistanced atomic power and computers in its effect on our everyday lives. In the
words of one observer, "Biotechnology is going to transform every aspect of human life: our
medical care, our food, our health, our entertainment, our very bodies. Nothing will ever be the
</code>
</pre>
</p>

<p>
	I'll run the tarpit on my localhost, and bind to port 22.

<pre>
<code>
# ./fortune-pit 22 < jp.txt
</code>
</pre>

And then on another host, I'll use OpenSSH to connect to my tarpit:

<pre>
<code>
ssh 192.168.1.3 -v -p 22
OpenSSH_7.9p1, OpenSSL 1.1.1k-freebsd  24 Aug 2021
...
debug1: ssh_exchange_identification: "The InGen Incident"
debug1: ssh_exchange_identification:
debug1: ssh_exchange_identification: The late twentieth century has witnessed a scientific gold rush of astonishing proportions: the
debug1: ssh_exchange_identification: headlong and furious haste to commercialize genetic engineering. This enterprise has proceeded
debug1: ssh_exchange_identification: so rapidly-with so little outside commentary-that its dimensions and implications are hardly
debug1: ssh_exchange_identification: understood at all.
debug1: ssh_exchange_identification: Biotechnology promises the greatest revolution in human history. By the end of this decade, it
</code>
</pre>

And presto, our SSH client is trapped reading Jurassic forever. Note that OpenSSH is flushing debugging lines on the exchange ID with every newline. If your banner has no newlines, you may not see this until the buffer fills (if at all). We can quit with <code>Ctrl+C</code> and take a look at our "logs":

<pre>
<code>
# ./fortune-pit 22 < jp.txt
connected       192.168.1.2:41826
disconnected    192.168.1.2:41826
</code>
</pre>
</p>

<h2>Improvements</h2>

<p>
	The SSH RFC specifies that lines written for the banner cannot exceed 255 characters including carriage return and line feed. This program imposes no such restriction, although it would probably be fairly easy to break up incoming text into 255 character lines and write those one word at a time.
</p>

<p>
	It's probably also worth noting that should any lines begin with <code>SSH-</code>, they're interpreted as SSH protocol version identifiers, causing the client and server to begin their authentication dance. Normally, unless the following data is valid, this results in a disconnect. In a worst-case scenario, if you pipe a completely legitimate protocol version, the client will successfully attempt authentication.
</p>

<h2>A Security Feature or a Toy?</h2>

<p>
	I will never run this on a production system and leave it there. It's a curiosity, not a security feature. I have a couple of reasons for this. First, I have no business writing homebrew software that stays running on TCP 22 all day every day. That's just not something I trust myself with or want to troubleshoot and maintain.
</p>

<p>
	Second, there is an argument going around that this is beneficial because it "wastes time and resources for attackers." This is a fallacy. We can't save the world by trolling attackers, no matter what Reddit tells you. Why? Botnets. For example, as an experiment, I did run this on a production, web-facing server for about a week. By the end I had lots of connects and disconnects from all over the world, and about 20 or so clients were still trapped in the tarpit when I killed it. Some of them were from known malicious Russian hosts, but more often than not, they were random. The awful reality is these trapped hosts were probably end-users' malware-infected hosts being bought and sold into botnets around the world. Trapping them and tying up their resources is a cold way to get back at an attacker that will just go and buy more bots, or write better malware to hang up when they discover tarpits like this one.
</p>

<p>
	So enjoy the tarpit, make it your own, use it to screw with your friends if you share a server. But use a good firewall and leave the guerilla web defense protocols idea behind.
</p>