So you may have noticed the "SSH Blocking" room which contains posts that have lots of IP addresses.  What's up with that?

Well, a large number of bots are always scanning the internet looking for SSH servers.  Why?  Dunno, probably related to email spam.  Luckily, my SSH is locked down nicely (except for the citadel login, but that's a different story).  So I wrote a script that looks in /var/log/auth.log looking for SSH authentication failures.  Then blocks them.  There's a table in my ipfw config that exists solely to keep a list of IP addresses I don't want connecting to my server.

The full script is below.

#!/usr/local/bin/php
&?php

$data = shell_exec("cat /var/log/auth.log | grep sshd | grep -v 0.0.0.0 | grep -oE \"([0-9.]+){7,}\" | sort | uniq -c");

$data_list = explode("\n", $data);
foreach ($data_list as $v) {
	$tmp = explode(" ", trim($v));
	if ($tmp[0] >= 5) {
		$banlist[$tmp[1]] = $tmp[1];
	}
}

/*
$data = shell_exec("cat /var/log/auth.log | grep sshd | grep -v \"::\" | grep user | grep -oE \"\]:.+port\" | grep -oE \"([0-9a-f]{1,4}:[^ ]+)\" | sort | uniq -c");

$data_list = explode("\n", $data);
foreach($data_list as $v) {
	$tmp = explode(" ", trim($v));
	if ($tmp[0] >= 5) {
		$banlist[$tmp[1]] = $tmp[1];
	}
} // */
$data = shell_exec("ipfw table 1 list | awk '{print \$1}' | grep -oE \".[^/]+\" | grep -vE \"/[0-9]+\"");
$data_list = explode("\n", $data);

foreach ($data_list as $v) {
	$blocked[$v] = $v;
}

// free up some memories
unset($data);
unset($data_list);
unset($tmp);

$count = 0;
$message = "I looked in /var/log/auth.log and found a number of entires I didn't like.  Here's a list of IP addresses I saw.\n\n";
$ipfwdata = file_get_contents("/etc/ipfw.auto");

foreach ($banlist as $v) {
	if (!empty($v)) {
		if (empty($blocked[$v])) {
			shell_exec("ipfw table 1 add $v");
			$count++;
			$message .= "Block [$v]\n";
			$ipfwdata .= "\nipfw -q table 1 add $v";
		}
	}
}

print("count: $count");

if ($count != 0) {
	$message .= "\n" . shell_exec("fortune") . "\n";

	file_put_contents("/etc/ipfw.auto", $ipfwdata);

	mail("Charlie Root ", "Blocked Skiddies [$count]", $message, array("X-Mailer" => "banner"));
}

IGnatius thinks Citadel could become a big thing.  I have my doubts, but I can also see potential.  It's a decent CMS platform as-is, tho it could use a little work on that front.  I've also seen people wanting to use it as a forum.  Well it kinda already does that, if you're into email threading, but it doesn't do that if you're thinking of the typical forum hierarchy.  Mail is also a problem.

E-mail started out with a small set of extremely simple protocols.  Unfortunately, these protocols support things like "mail relays", and the protocol specification does not require a server to require user authentication before sending mail.  The internet's current mail system is outdated.  We need new protocols (and servers for them) that disallow relaying.  It's bad when a mail message passes through 3 or 4 servers just to get to your server, when it could have simply gone directly to your server.

With Citadel, we have a protocol designed for Citadel to Citadel communication, it's also the same protocol that webcit (the web front-end for Citadel) and citadel (the text client) use to talk to citserver (the actual Citadel server).  There has been some effort to get links established within a Citadel network, but there doesn't seem to be much progress here.  I have a proposition.

Mortar - an internal network of Citadel servers all acting as a single node.  This would be like what we already have with a web server with multiple application servers behind it all running the same webapp.  Distributed loads, to handle more users.

Netadel - a network of Citadel nodes where the mail functionality of Citadel can be used to pass private email between users.  Can also be used to propagate room messages, so users on different Citadels can communicate publicly within shared rooms.  A Netadel would have to be established between the owners of the Citadels, so while a CA-signed cert can be used here, the trust factor is really just between the operators, so a self-signed cert is perfectly acceptable here.

Citanet - the internet of Citadel.  Generic propagation (room sharing) can be done here, but this is really just for an email service.  All communication here should require a CA-signed cert.

When a message or email is sent either in a Netadel or a Citanet, the classic (and outdated) email systems of the larger internet are not used.  These messages are always transferred directly between the Citadels of the sender and recipient.  With a lot of people not wanting to use Big Tech anymore due to their politics, policies, or whatever, Citadel has the possibility of becoming truly great.  One of the biggest problems on the internet is mail spam.  Spam vastly outnumbers legitimate email.  The Citadel protocol can be used to curb this problem.  Part of the specification would have to be that no relaying is ever possible.  The specification would also need to require encrypted links between all Citadels.  With these two requirements, spam can be cut down.  Additionally, spam filtering can be applied to outgoing messages.  Imagine blocking an outbound message because SpamAssassin says it is spam.

I have been considering building my own Citadel-compatible system, using the Citadel protocol.  Having more than one implementation would be a great first step in making Citadel a somewhat standard protocol.  It also gives administrators options.  The one thing I don't like about Citadel is how it really only uses 2 main programs (citserver and webcit) to provide all functionality on all client-facing protocols.  I would write my Citadel implementation slightly differently - where each client-facing protocol is implemented in its own service.  This is a more modular approach and would give admins the ability to use different drop-in components from different developers.  This would work beautifully well with multiple developer teams making all these components but using the standard Citadel protocol on the back-end.