feat: publish tarpit, new drafts

3 files changed, 22 insertions, 192 deletions

diff --git a/drafts/2021-10-06-write-your-own-ssh-tarpit-in-rust-with-async-std.php b/drafts/2021-10-06-write-your-own-ssh-tarpit-in-rust-with-async-std.php
deleted file mode 100644
index 26824da..0000000
--- a/drafts/2021-10-06-write-your-own-ssh-tarpit-in-rust-with-async-std.php
+++ /dev/null
@@ -1,192 +0,0 @@
-<?php
-$title = "Write Your Own SSH Tarpit in Rust with async-std";
-if (isset($early) && $early) {
-	return;
-}
-include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
-?>
-
-<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. It's kind of like those YouTubers who purposely joke around with phone scammers as long as possible to waste their time and have fun. 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 attacker whatever information I want. For example, I want to be able to pipe a Unix Fortune across the network to the attacker very slowly. I want to relish in the knowledge that if the attacker 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/src/commit/4fa2c2a100dba6b264cc232963f6d797ffb671cf/Cargo.toml">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, 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. I also want the user to pick what gets written.
-</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>
-</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>
diff --git a/drafts/2021-11-19-agile-is-not-an-excuse.php b/drafts/2021-11-19-agile-is-not-an-excuse.php
new file mode 100644
index 0000000..24afa4f
--- /dev/null
+++ b/drafts/2021-11-19-agile-is-not-an-excuse.php
@@ -0,0 +1,18 @@
+<?php
+$title = "Agile Is Not an Excuse";
+if (!empty($early)) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+Don't use agile software development as a crutch or an excuse for not adding value. Reacting to change and pivoting for your stakeholders only works when you go from one "swimlane" or "track" to another. It doesn't work when you move cyclically from one project to another whenever one seems more important than the other to you, management, stakeholders, etc.
+
+Don't use agile software development as the excuse to have stories "done" in a certain number of sprints. Quarterly predictions should not confine the process to days or weeks.
+
+Remember:
+
+- Individuals and interactions over processes and tools
+- Working software over comprehensive documentation
+- Customer collaboration over contract negotiation
+- Responding to change over following a plan
diff --git a/drafts/your company isnt doing SRE.php b/drafts/your company isnt doing SRE.php
index fdb1e5e..87ebcae 100644
--- a/drafts/your company isnt doing SRE.php
+++ b/drafts/your company isnt doing SRE.php
@@ -2,3 +2,7 @@ your company probably isn't doing SRE Google SRE - embracing risk - 50% time is
 for free thought and development if your "devops" are so busy doing ticket work
 they're asking for you to hire, you're not doing SRE
 https://sre.google/sre-book/introduction/
+
+Don't forget the chapter that says 50% time for development
+
+Don't forget the one that says no new deployments when ops are at capacity. "But the business needs this" well then the business needs to hire more people.