LandChad.net: Web Guides for Internet Landchads!

Using UFW as a Firewall

Thu, 01 Jul 2021 16:58:11 -0400

Using UFW as a Firewall

Uncomplicated Firewall (UFW) is a front-facing program for the more involved iptables firewall program installed in most GNU/Linux distributions. We can use ufw to restrict machines on the internet to only access the services (SSH, websites etc) you want them to, but it can also be used to prevent programs on the computer itself from accesing parts of the internet it shouldn't.

How to Get It

Log into your server by pulling up a terminal and typing:

ssh root@example.org

This command will attempt to log into your server and run a remote shell. If you leave the settings default, it should prompt you for your password, and you can just copy or type in the password from Vultr's site.

Some VPS providers automatically install ufw, but if you do not have it installed already, install it in the typical way:

apt install ufw

First-Time Setup

You can check the status of ufw right now by running:

ufw status

Without any changes, it should report back Status: inactive. Let's set it up so that only connections to SSH (standardized at port 22) are allowed in, and then enable the firewall:

Careful! Enabling ufw without allowing SSH will block you from remoting to your server. Double-check that you have allowed SSH, and if you have changed the default SSH port, put in that number instead.

ufw default deny incoming # block all incoming connections by default
ufw allow in ssh # or: ufw allow in 22
ufw enable

ufw has an internal list of protocols applications, and the ports used by them. In this case, it knwos SSH is on port 22. We'll go more in detail how to view all protocols ufw knows about. By default, when you allow an incoming port, it allows that port both on IPv4 and IPv6.

With the firewall enabled and allowing only SSH in, all other ports are prortected from incoming requests. To view all your rules, run:

ufw status verbose

A firewall that allows to connect to SSH and their website may look like:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To                           Action      From
--                           ------      ----
22 (SSH)                     ALLOW IN    Anywhere
80,443/tcp (WWW Full)        ALLOW IN    Anywhere
22 (SSH (v6))                ALLOW IN    Anywhere (v6)
80,443/tcp (WWW Full (v6))   ALLOW IN    Anywhere (v6)

If you want to delete e.g. the 'WWW Full' rule, run:

ufw delete allow in 'WWW Full'
ufw reload

Enabling Common Services

You have blocked all incoming ports but SSH, which means no outsiders would be able to access other services, like an email server or your website. You should look at the ports your services are open on and enable them individually. Here is a list of a few common services:

Opening Port Numbers

Suppose you install a Gemini server, which must broadcast on port 1965. By default ufw blocks all incoming connections on all ports, so whenever you install a new service like this you will have to tell ufw to enable the desired port:

ufw allow 1985

Websites: HTTP and HTTPS

HTTP uses port 80 and HTTPS uses port 443. We can enable them like this:

ufw allow 80
ufw allow 443

But ufw additionally knows the typical ports of common serives, so you can also run this:

ufw allow http
ufw allow https

And that will do the same thing. There are also other abbreviations for common port lists:

ufw allow in 'WWW Full'

To see these other "apps" that ufw knows by default, run ufw app list

Email: IMAP, POP3, and SMTP

ufw allow in IMAPS
ufw allow in POP3
ufw allow in SMTP
ufw allow in 'Postfix SMTPS'
ufw allow in 'Mail Submission'

Fine-Tuning Rules

Instead of denying all ports by default, you may want to deny (ignores incoming requests) or reject (explicitly tells requests they're not allowed):

ufw default allow in
ufw deny in PORT
ufw reject in PORT
ufw reload

You can add rules to comments to remember what they are there for:

ufw allow in PORT comment 'Secret SSH'
ufw reload
ufw status verbose

Output:

To                         Action      From
--                         ------      ----
PORT                       ALLOW IN    Anywhere                   # Secret SSH
PORT (v6)                  ALLOW IN    Anywhere (v6)              # Secret SSH

To deny outgoing ports:

ufw deny out PORT

Ratelimiting is useful to protect against brute-force login attacks, like in SSH. Only IPv4 is supported for now. Enable it by running:

ufw limit PORT/tcp

To blocklist IP addresses:

ufw deny from IP_ADDRESS

To read more what you can do with ufw, run:

man ufw

Recovering SSH

If you have accidentally firewalled yourself from logging on your computer, you can recover access by using your VPS's virtual console. On Vultr, this is on your VPS's menu. To the right of the server name, It is the leftmost icon that looks like a monitor.

ufw disable

Creating Your Own Chat Server With IRC

Thu, 01 Jul 2021 16:28:32 -0400

Creating Your Own Chat Server With IRC

Creating your own chat server for you and your friends is easy, and you don't have to rely on a complicated system to get started. IRC is an old but gold protocol, and has clients for basically every operating system made since the 80s, with many powerful modern ones on Linux, Mac, and Windows.

Having a chat server for you and your friends makes it impossible for a group of arbitrarily appointed moderators to deplatform you for wrong-think, and gives you greater freedom of communication.

Installing an IRCd

An IRCd is short for "IRC daemon", which just means an IRC server. The most easy IRCd to setup is Ergo.

The first thing you need to do is create a new user for the server to be run by. This is good practice for installing software/servers manually, as it give you more fine-grained control over which permissions the application has.

useradd -m ergo -s /bin/bash

Next, we want to switch to our newly created ergo user and create the server directory.

sudo -i -u ergo
mkdir server

You can find the latest release of Ergo on its GitHub latest release page.
There are several platforms available, but you want to choose Linux, most likely linux-x86_64.
Once you have selected the correct package, copy its URL and replace with the package URL (still as the ergo user):

wget https://github.com/ergochat/ergo/releases/download/v2.7.0/ergo-2.7.0-linux-x86_64.tar.gz
tar -xf ergo-2.7.0-linux-x86_64.tar.gz
mv ergo-2.7.0-linux-x86_64/*
rm -r ergo-2.7.0-linux-x86_64*

Executing ls -l should now yield something like this:

-rw-r--r-- 1 ergo ergo  118825 Jun  8 00:51 CHANGELOG.md
-rw-r--r-- 1 ergo ergo    1983 May 31 01:48 README
-rw-r--r-- 1 ergo ergo   41440 Jun  8 00:42 default.yaml
drwxr-xr-x 2 ergo ergo    4096 Jul  1 09:01 docs
-rwxr-xr-x 1 ergo ergo 9654272 Jun  8 00:53 ergo
-rw-r--r-- 1 ergo ergo    1753 May 31 01:48 ergo.motd
drwxr-xr-x 2 ergo ergo   12288 Jul  1 09:01 languages
-rw-r--r-- 1 ergo ergo   39722 Jun  8 00:42 traditional.yaml

If you see something similar to the above, that means Ergo is installed, although not quite ready to run yet.

Configuring Ergo

Now that Ergo is installed, you want to configure it to fit the needs of your group.
The configuration in this section is tailored towards a small group of people, and less for a possibly large network, but it should work for any size of group.

First thing, make sure you're still using the ergo user, and are in the ~/server directory.
If you aren't, you can run the following to get back there:

sudo -i -u ergo
cd ~/server

Next, generate certificate files for TLS:

./ergo mkcerts

Ergo comes with a default configuration file with detailed documentation that can be used to guide you through the configuration process. This guide will help you setup the server for a typical use-case, but if you see any settings that you would like to change along the way, go ahead and change them, as long as you know what you're doing.

To start configuring, we need to copy some files:

cp default.yaml ircd.yaml
cp ergo.motd ircd.motd

The next steps involve editing the newly copied ircd.yaml file. If you do not know how to edit text files from the comment line, you can use nano, which is very simple, using arrow keys to navigate, CTRL+O to save, and CTRL+X to exit.
Another option is vim, which is a much more powerful text editor, but has a learning curve. It is only recommended for this guide if you already know it.
Lastly, you can copy the ircd.yaml file to a text editor on your computer and edit it with a GUI text editor of your choice. If that is what you choose to do, you may want to just download the file from Ergo's GitHub, edit it on your computer, clear the ircd.yaml file on the server, and then paste the contents from your computer into the blank file.
No matter how you do it, the next steps assume you can edit the configuration file.

Note:
The options highlighted in this section are not a complete overview of all options. Instead, the options shown are the ones which are most relevant to a small network.
You should read over the configuration file yourself if you are curious about everything you can change.

Network and server names

One of the first properties in the config file is network name. You can change this to whatever you like, as it will show up as the name when you connect to the server.

# network configuration
network:
    # name of the network
    name: "Land-Chat"

Change the server name to your server's domain name.

# server configuration
server:
    # server name
    name: "example.org"

Network password

The next step is optional, depending on if you want your network password protected or not. The benefit of password protection is fairly obvious; nobody can connect to your network unless you gave them the password. If you're wanting to run a public network which anyone can join and create a channel, you want to skip this, but for personal setups, it is highly recommended.

Generate a password to use by executing the following:

./ergo genpasswd

It will ask you to enter a password and confirm it, then you will be given a hashed password.
Copy this password, and paste it into the following field (also removing the # before the password: line):

# password to login to the server, generated using `ergo genpasswd`:
password: ""

Message of the day (MotD)

Change the MotD (Message of the Day) file to the one you copied earlier:

# motd filename
# if you change the motd, you should move it to ircd.motd
motd: ircd.motd

Feel free to edit ircd.motd to your heart's content. Its contents will be sent to clients when they connect to the network.

IP limits

For security purposes, you might want to limit the amount of client connections per IP. For a private network, 4 is likely the maximum amount of connections you will have per IP, so that is a safe value.
If your network is password protected, this is less of an issue, since the only people connecting will be people who have the password. The following is the default, but you can change it to be whichever value you like:

# IP-based DoS protection
ip-limits:
    # whether to limit the total number of concurrent connections per IP/CIDR
    count: true
    # maximum concurrent connections per IP/CIDR
    max-concurrent-connections: 16

IP cloaking

Traditionally, IRC networks expose users' IP addresses to everyone. This is not a good practice for privacy, however. With Ergo, IP cloaking is enable by default. You can enable or disable it if you like, and change how it looks to users.
In this case, netname was changed to "chad".

# IP cloaking hides users' IP addresses from other users and from channel admins
# (but not from server admins), while still allowing channel admins to ban
# offending IP addresses or networks. In place of hostnames derived from reverse
# DNS, users see fake domain names like pwbs2ui4377257x8.irc. These names are
# generated deterministically from the underlying IP address, but if the underlying
# IP is not already known, it is infeasible to recover it from the cloaked name.
# If you disable this, you should probably enable lookup-hostnames in its place.
ip-cloaking:
    # whether to enable IP cloaking
    enabled: true
    # whether to use these cloak settings (specifically, `netname` and `num-bits`)
    # to produce unique hostnames for always-on clients. you can enable this even if
    # you disabled IP cloaking for normal clients above. if this is disabled,
    # always-on clients will all have an identical hostname (the server name).
    enabled-for-always-on: true
    # fake TLD at the end of the hostname, e.g., pwbs2ui4377257x8.irc
    # you may want to use your network name here
    netname: "chad"

Password enforcement adjustments for HexChat (and possibly other clients)

Ergo offers account registration to allow users to do things like use history and bouncer features, register channels, etc.
In clients such as HexChat, server password may conflict with account passwords, so the following setting should be enable if you wish to use accounts with clients such as HexChat.
Note that this could under some circumstances be considered a security hazard, as a user with an account does not need to know the server password to connect, although that user would have needed to register an account before the server had a password, and then a password would need to have been set after the fact, so this can be considered a very small concern if your setup always has had a password.
Also keep in mind that this setting has no effect if your network does not even have a password at all.

# some clients (notably Pidgin and Hexchat) offer only a single password field,
# which makes it impossible to specify a separate server password (for the PASS
# command) and SASL password. if this option is set to true, a client that
# successfully authenticates with SASL will not be required to send
# PASS as well, so it can be configured to authenticate with SASL only.
skip-server-password: true

Multiclient, always-on clients, history, etc

Traditionally, IRC servers have no message history, and once you close your client, you cannot receive messages, and are not shown to be online at all. Ergo includes functionality to allow users to both receive history, and keep their clients "online" even after they have left. It also allows multiple clients to connect to the same account.
If you are running a private network for friends, you should set always-on and auto-away to opt-out, to have all users with accounts to appear as if they are online at all times, and be able to receive messages when they are offline.
For a public network, keep everything as their default values, since you probably do not want randoms having this by default.
If for some reason you do not want any of these features at all, you can set enabled to false, but this is not recommended. Below are the recommended values for a private network (e.g. for friends) where users with accounts will be able to receive messages and history while they are offline.

# multiclient controls whether Ergo allows multiple connections to
# attach to the same client/nickname identity; this is part of the
# functionality traditionally provided by a bouncer like ZNC
multiclient:
    # when disabled, each connection must use a separate nickname (as is the
    # typical behavior of IRC servers). when enabled, a new connection that
    # has authenticated with SASL can associate itself with an existing
    # client
    enabled: true
    # if this is disabled, clients have to opt in to bouncer functionality
    # using nickserv or the cap system. if it's enabled, they can opt out
    # via nickserv
    allowed-by-default: true
    # whether to allow clients that remain on the server even
    # when they have no active connections. The possible values are:
    # "disabled", "opt-in", "opt-out", or "mandatory".
    always-on: "opt-out"
    # whether to mark always-on clients away when they have no active connections:
    auto-away: "opt-out"
    # QUIT always-on clients from the server if they go this long without connecting
    # (use 0 or omit for no expiration):
    #always-on-expiration: 90d

VHosts

IP cloaking was mentioned previously, and somewhat related to that, Ergo includes "vhost" functionality, which allows users to set a custom IP/host string. This is mostly for cosmetic value, and does not interfere with operators being able to see actual IP addresses for banning, but if you do not want it enable for some reason, you can disable it.

# vhosts controls the assignment of vhosts (strings displayed in place of the user's
# hostname/IP) by the HostServ service
vhosts:
    # are vhosts enabled at all?
    enabled: true

Channels

Channels are where everyone on an IRC network talk. By default, anyone can create a channel, and anyone with an account can register one. The difference between a normal channel and a registered one is that the registered one will preserve the operator status of the person who created, whereas a normal channel's owner will lose operator status if they leave the channel or disconnect from the network.
There are various settings for channels available, but the defaults are suitable for a private network with trust among users, or where you just want anyone to have the ability to create a channel. Below are the default values:

# channel options
channels:
    # modes that are set when new channels are created
    # +n is no-external-messages and +t is op-only-topic
    # see  /QUOTE HELP cmodes  for more channel modes
    default-modes: +nt
    # how many channels can a client be in at once?
    max-channels-per-client: 100
    # if this is true, new channels can only be created by operators with the
    # `chanreg` operator capability
    operator-only-creation: false
    # channel registration - requires an account
    registration:
        # can users register new channels?
        enabled: true
        # restrict new channel registrations to operators only?
        # (operators can then transfer channels to regular users using /CS TRANSFER)
        operator-only: false
        # how many channels can each account register?
        max-channels-per-account: 15

Operators (administrators, etc)

The IRC term for an administrator or another privileged user is "operator", or "oper" for short.
Ergo's opers have different permissions that can be granted to them, and are defined in "classes", basically groups of permissions under a name. For example, "chat-moderator" and "server-admin" are defined in the default configuration:

# operator classes
oper-classes:
    # chat moderator: can ban/unban users from the server, join channels,
    # fix mode issues and sort out vhosts.
    "chat-moderator":
        # title shown in WHOIS
        title: Chat Moderator
        # capability names
        capabilities:
            - "kill"
            - "ban"
            - "nofakelag"
            - "roleplay"
            - "relaymsg"
            - "vhosts"
            - "sajoin"
            - "samode"
            - "snomasks"
    # server admin: has full control of the ircd, including nickname and
    # channel registrations
    "server-admin":
        # title shown in WHOIS
        title: Server Admin
        # oper class this extends from
        extends: "chat-moderator"
        # capability names
        capabilities:
            - "rehash"
            - "accreg"
            - "chanreg"
            - "history"
            - "defcon"
            - "massmessage"

The above can be kept with their default values, but you are free to modify them or create any new classes that are appropriate for your setup.
Next, let's actually create an operator account:

# ircd operators
opers:
    # default operator named 'gigachad'; log in with /OPER gigachad 
    "gigachad":
        # which capabilities this oper has access to
        class: "server-admin"
        # custom whois line
        whois-line: is the server administrator
        # custom hostname
        vhost: "gigachad"
        # normally, operator status is visible to unprivileged users in WHO and WHOIS
        # responses. this can be disabled with 'hidden'. ('hidden' also causes the
        # 'vhost' line above to be ignored.)
        hidden: false
        # modes are modes to auto-set upon opering-up. uncomment this to automatically
        # enable snomasks ("server notification masks" that alert you to server events;
        # see `/quote help snomasks` while opered-up for more information):
        #modes: +is acjknoqtuxv
        # operators can be authenticated either by password (with the /OPER command),
        # or by certificate fingerprint, or both. if a password hash is set, then a
        # password is required to oper up (e.g., /OPER dan mypassword). to generate
        # the hash, use `ergo genpasswd`.
        password: ""

This is a modified version of the default oper entry. The account name is "gigachad", but you can change it to anything.
Replace with a password generated by ./ergo genpasswd, and you will have a new oper account to use.
Note that to log into an oper account, clients have to enter /OPER each time they log in. This can be automated by most clients by setting the command to be executed when the client logs in. In the case of HexChat, you can edit your network and add the command to the Connect commands tab of the menu.
You can copy everything from "gigachad" to the end of the line, paste it again, and change the name to create another oper account. Another, less privileged example of an oper is shown as a comment below the above configuration snippet.

Chat history

Traditionally, IRC networks do not store, relay, or handle chat history in any way.
On a privacy standpoint, this is a good thing, since chats are entirely ephemeral and handled by clients.
On a practicality standpoint, this is a bad thing, since people have to keep a client connected 24/7 to see message history.
For normalfriends, this can be a big problem, not only because having to stay online 24/7 is just annoying or infeasible, but also because they are likely used to chat platforms that handle history for them.
With this in mind, enabling history is a good idea if you want to move friends over to IRC, and will make things a lot more pleasant for private networks.

Ergo's history configuration group is very long, so it is encouraged to read over it yourself. This section will go over the most important pieces of that configuration group.

History is not endless (unless you want it to be), and the amount that can be stored for channels is configurable:

# how many channel-specific events (messages, joins, parts) should be tracked per channel?
channel-length: 2048

History is already enabled by default, but that just means it is being collected, not relayed by default. To relay history to clients when they connect, change the following to the amount of messages that you think is appropriate:

# number of messages to automatically play back on channel join (0 to disable):
autoreplay-on-join: 250

History older than a certain time can be configured to be deleted or be inaccessible. The default cutoff time is 1 week, but this is configurable as well.


# options to delete old messages, or prevent them from being retrieved
restrictions:
    # if this is set, messages older than this cannot be retrieved by anyone
    # (and will eventually be deleted from persistent storage, if that's enabled)
    expire-time: 1w

By default, Ergo only stores chat history in memory, so when the server restarts, all history is lost. If you wish to have chat history persist beyond restarts, you must store it in a MySQL database:

# options to store history messages in a persistent database (currently only MySQL).
# in order to enable any of this functionality, you must configure a MySQL server
# in the `datastore.mysql` section.
persistent:
    enabled: true
    # store unregistered channel messages in the persistent database?
    unregistered-channels: true

# connection information for MySQL (currently only used for persistent history):
mysql:
    enabled: false
    host: "localhost"
    port: 3306
    # if socket-path is set, it will be used instead of host:port
    #socket-path: "/var/run/mysqld/mysqld.sock"
    user: "ergo"
    password: "hunter2"
    history-database: "ergo_history"
    timeout: 3s
    max-conns: 4
    # this may be necessary to prevent middleware from closing your connections:
    #conn-max-lifetime: 180s

For privacy reasons, you may want to allow users to delete their own messages in history, or export their messages to JSON:

# options to control how messages are stored and deleted:
retention:
    # allow users to delete their own messages from history?
    allow-individual-delete: true
    # if persistent history is enabled, create additional index tables,
    # allowing deletion of JSON export of an account's messages. this
    # may be needed for compliance with data privacy regulations.
    enable-account-indexing: true

Spam reduction

Most IRC networks have measures in place to reduce chat spam. By default, "fakelag" is enabled in Ergo, and that can deal with most aggregious chat spam.
If you are running a private network where user trust is high, you can disable it so that there are no limits on the speed that messages can be sent.

# fakelag: prevents clients from spamming commands too rapidly
fakelag:
    # whether to enforce fakelag
    enabled: true
    # time unit for counting command rates
    window: 1s
    # clients can send this many commands without fakelag being imposed
    burst-limit: 5
    # once clients have exceeded their burst allowance, they can send only
    # this many commands per `window`:
    messages-per-window: 2
    # client status resets to the default state if they go this long without
      # sending any commands:
    cooldown: 2s

Starting and using your server

Now that Ergo is both installed and configured, you can actually start using it!

Starting the server

First thing, make sure you're still using the ergo user, and are in the ~/server directory.
If you aren't, you can run the following to get back there:

sudo -i -u ergo
cd server

Starting the server is done in one command:

./ergo run

It will stay online until you close the terminal, or press CTRL+C. Don't worry, the next section goes over how to make it run like a normal server with a SystemD service.
If you have not already, make sure the port 6697 is not blocked on your server. If you are using UFW as your firewall, you need to run ufw enable 6697 (not as the ergo user, of course).
If you make and configuration changes while the server is running, you can apply them without restarting by typing /rehash as an operator.

Connecting to the server

To use IRC, you of course need an IRC client. There are many choices available, but the most widely used for Windows and Linux is HexChat. On Mac, you have a slightly nicer option with Textual, although you have to compile it from source if you want to use it for free.
A more user-friendly and modern client choice is TheLounge, which is explained in the last section of this guide, if you want to look into it.

Connecting with HexChat is very easy. When you start it, you will see something like this:

From there, you should click + Add and name the server whatever you like (so you can find it on the server list).
Once you have created a new server and named it, select it and click Edit.... A menu will show up like the one below. Change the domain to whatever domain your server is running on, and make sure to put in your server password if you set one.

Once you're done editing the network, click (X) Close, select your network from the network list, and click Connect.
If all is well, you should be connected!

The process is very similar on Textual.
Create a new network and connect to it. Note that it will ask if you want to connect even though the certificate is unsigned. This is due to the self-signed certificates generated for the server, and is not a problem or security vulnerability, it is just a little annoying.

Surviving restarts with a SystemD service

In the beginning of the last section, Ergo was started by simply running ./ergo run, but this is only suitable for testing. To have a proper server setup, you need to run it as a service. This can be achieved via a SystemD service.

Before creating your service file, make sure you are in ~/server as the ergo user.
Once you have done that, create a file called start.sh with the following content:

#!/bin/bash
./ergo run

Save the file, then mark it as executable:

chmod +x start.sh

Now, create a file called ergo.service with the following content:

[Unit]
Description=Ergo IRC server
After=network.target
# If you are using MySQL for history storage, comment out the above line
# and uncomment these two instead (you must independently install and configure
# MySQL for your system):
# Wants=mysql.service
# After=network.target mysql.service
[Service]
Type=simple
User=ergo
WorkingDirectory=/home/ergo/server
ExecStart=/home/ergo/server/start.sh
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
LimitNOFILE=1048576
# Uncomment this for a hidden service:
# PrivateNetwork=true
[Install]
WantedBy=multi-user.target

You now have your service file, but it is not installed yet. To install it, switch to your normal user, and execute the following lines to install, enable, and start the SystemD service:

ln -s /home/ergo/server/ergo.service /etc/systemd/system/ergo.service
systemctl enable ergo
systemctl start ergo

Ergo is now installed and running as a service, and will automatically start when the system boots.

Registering accounts and channels

Account and channel registration were mentioned multiple times in this guide, and are indeed very important parts of the modern IRC ecosystem. You can connect to most IRC networks and talk without creating an account, but you will not be able to reserve your nickname or register channels, so it is important to register an account.

Registering an account with NickServ

First, make sure you are connected to your IRC network. Once you are, type /nickserv help to make sure NickServ (the registration system) is working propertly.
If all is well, type the following, replacing with the password you want to use:

/nickserv register

At this point, you are now registered!
The final step is to configure authentication with your client.

In HexChat, all that needs to be done is changing Login method to SASL (username + password), and entering your NickServ password that you used earlier into the password field:

In Textual, open up your network in the menu, and click Identity under Server Properties. Enter your password in Personal Password, and check Wait for identification before joining channels.

You will now be logged into your account when you connect to your network.

Registering channels with ChanServ

Once you have an account registered, you can register channels with ChanServ.
To do so, join the channel you want to register, then type the following, replacing with the name of the channel you want to register:

/chanserv register #

You are now the channel owner, and are free to appoint operators, administrators, etc for it. When you go offline, you won't lose ownership, and you cannot be removed as the owner unless you unregister the channel later.

Moderation

Like any chat, there will come a point where you need to use moderation tools to keep things under control. Many IRC setup guides do not go over moderation, so it can be stressful when operators need to actually use moderation tools.
The main difference between IRC and other chat systems in terms of moderation is the difference between channel bans and network bans. Channel ban keeps a person out of channel a channel, whereas a network ban keeps a person out of the entire network.

Understanding masks

Bans are applied "masks", which are formatted pieces of text that contain a user's nick (username), their realname value, and their IP address or host.
This is what a mask looks like: nick!~nick-dude@127.0.0.1.
In bans, asterisks can be used as wildcards, which is useful for banning IP address ranges, patterns of nicknames, or whatever else you can think of.
A ban on the nick person, for example, would look like this: person!*@*.
A ban on anyone with the IP address 127.0.0.1 would look like this: *!*@127.0.0.1

Discovering real IPs

Even if IP cloaking is enabled on your network, you can still obtain real IP addresses/hosts if you are an operator. See the Operators part of the configuration section of this guide on how to become an operator.
To find out a user's real IP, simply type /whois along with the user's nick, and you will see information about the user, along with their real IP address/host.
/whois is not a command that is exclusive to operators, but it does not reveal as much information to non-operators.

Banning someone from the network

Any netword-wide moderation action requires being an operator. See the Operators part of the configuration section of this guide on how to become an operator.
Banning someone from the network is achieved with the /kline command. To see more info on the command, type /helpop kline.

To ban a nick from the network:

/kline andkill !*@*

To ban an IP address or host from the network:

/kline andkill *!*@

To unban a mask, you can use the /unkline command with the mask you want to unban.

Banning someone from a channel

Channel owners, administrators, and operators can ban people from channels. This is not the same as banning someone from the network, since it only has an effect on one channel. Additionally, a channel operator is not the same as a network operator.

To ban someone in a channel, type the following in that channel, replacing with the user's mask:

/mode +b

Note that this will only ban the user, not kick them immediately. You will want to run /kick along with the user's nick to also kick them.
To unban a user, run the command above, but replace the + with a -.
You can see who is banned in a channel by typing /banlist.

Muting people in a channel

By default, anyone can speak in an IRC channel. To change this, you must be a channel owner, administrator, or operator.
Channels, along with users, have modes, which modify their behavior. There is a special mode for channels called m (moderated) which requires users to be privileged in some way to talk.
To set a channel as moderated, type the following in the channel:

/mode +m

Now, users must be an owner, administrator, operator, or be voiced to talk in the channel This be reversed by typing the command above, but changing the + to a -.
To voice a user, run the following, replacing with the user's nick:

/mode +v

Unvoice the user by typing the above command, but replacing the + with a -.

Appointing channel administrators and operators

Assuming you a channel owner, you can appoint both administrators and operators. If you are only an operator, you may only appoint operators.
The difference between administrator and operator is mainly that administrators cannot have their privileges taken away by operators, only owners. To appoint an administrator, type the following, replacing with the user's nick:

/mode +a

To appoint an operator, type the following, replacing with the user's nick:

/mode +o

You can also use /op and /deop on most clients to appoint and remove an operator.
To remove administrator or operator status, run either of the above commands, but replace the + with a -.

Bringing modern-day features to IRC with TheLounge

A large downside to IRC as a protocol is just how old it is, and the limitations that exist because of it. Other old protocols such as HTTP were built to be content-agnostic and versitile, but IRC was built with a very specific set of features, so it has not held up so well to contemporary chat systems.
A notable thing that IRC as a protocol is missing is file uploads, and other fancy features that many other chats have.
With that said, these problems can be fixed by clients, although many clients are still very primitive.

TheLounge is a modern self-hosted IRC web client that tries to make IRC as user-friendly as possible. It can be the answer to many of the complaints that normalfriends may have about IRC. It runs on anything with a web browser, can be "installed" since it is a PWA (Progressive Web App), and is optimized for both desktops and mobile devices. It keeps you logged in even when you are gone, and even supports file uploads and embeds.
Effectively, it brings IRC up to the standard of most other chat systems.

If you would like to setup an instance of TheLounge for you and your friends, you can take a look at their installation guide.
It is a self-hosted web app, so you can run it for multiple people, not just yourself.

Written by Termer

Setting up Gitea

Thu, 01 Jul 2021 16:14:22 -0400

Setting up Gitea

Gitea allows you to self-host your git repositories similar to bare repositories, but comes with additional features that you might know from GitHub, such as issues, pull requests or multiple users. Its advantage over GitLab—another Free Software GitHub clone—is that it is much more lightweight and easier to setup.

Head over to gitea.com to see what it looks like in practice.

Although Gitea is lighter than Gitlab, if you have a VPS with only 512MB of RAM, you will probably have to upgrade. Gitea is more memory-intensive than having just a bare git repository.

Installing Gitea

First install a few dependencies:

apt install curl sqlite3

Unfortunately, Gitea itself is not in the official Debian repos, so we will add a third-party repository for it.

Add the repo's gpg key to apt's trusted keys:

curl -sL -o /etc/apt/trusted.gpg.d/morph027-gitea.asc https://packaging.gitlab.io/gitea/gpg.key

Then add the actual repository to apt:

echo "deb [arch=amd64] https://packaging.gitlab.io/gitea gitea main" > /etc/apt/sources.list.d/morph027-gitea.list

Now we can install Gitea:

apt update
apt install gitea

Since apt automatically enables and starts the Gitea service, it should already be running on port 3000 on your server!

Setting up a Nginx reverse proxy

You should know how to generate SSL certificates and use Nginx by now. Add this to your Nginx config to proxy requests made to your git subdomain to Gitea running on port 3000:


server {
	listen 443 ssl;
	listen [::]:443 ssl;
        ssl_certificate /etc/ssl/nginx/git.example.org.crt;
        ssl_certificate_key /etc/ssl/nginx/git.example.org.key;
        server_name git.example.org;
	location / {
		proxy_pass http://localhost:3000/; # The / is important!
		proxy_redirect off;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}
}

And reload Nginx:

systemctl reload nginx

Setting up Gitea

If everything worked fine you should now see a setup screen when you go to your configured domain in the browser. The options should be pretty self-explanatory, it is only important to select SQLite3 and to replace the base url and SSH server domain with your own.

Database Type:: SQLite3
SSH Server Domain:: git.example.org
Gitea Base URL:: git.example.org

These and other settings can be changed in a configuration file later so don't worry about making wrong decisions right now.

After clicking the install button you should now be able to log into your Gitea instance with the account you just created! Explore the settings for more things to do, such as setting up your SSH keys.

If Gitea does not load fully and has random errors, it is possible that you need to increase your available memory on your VPS. This can usually be done on your VPS-provider's website without too much trouble.

A few extras

Automatically create a new repo on push

This is an incredicly useful feature for me. Open up /etc/gitea/app.ini and add DEFAULT_PUSH_CREATE_PRIVATE = true to the repository section like so:

If you now add a remote to a repository like this

git remote add origin 'ssh://gitea@git.example.org/username/coolproject.git'

and push, Gitea will automatically create a private coolproject repository in your account!

Change tab-width

By default Gitea displays tabs 8 spaces wide, however I prefer 4 spaces. We can change this!

mkdir -p /var/lib/gitea/custom/templates/custom/

And write this into /var/lib/gitea/custom/templates/custom/header.tmpl:

<style>
.tab-size-8 {
	tab-size: 4 !important;
	-moz-tab-size: 4 !important;
}
</style>

Contribution

phire

Hosting Your Own Git Repositories

Thu, 01 Jul 2021 07:19:51 -0400

Hosting Your Own Git Repositories

Once you have your own VPS or other Internet-available server, you can start hosting your own git repositories. The goal of this tutorial is for you to go from

git clone github.com/...

git clone YourLandChadDomainName.xyz/...

so you can cultivate your own homegrown, grass-fed code, rather than relying on a centralized proprietary service like GitHub.

Installing git

You most likely already have it installed on your server, but if not, run:

apt install git

We don't need any additional software, git itself ships with everything needed to host a remote repository!

Creating bare repositories

For each repository you want to host, you will need to manually create what's called a "bare" repository on your server. These hold all the commits and any other git data needed for your repository, but without an expanded "index" in which you can just browse all the files of a certain commit in the file system.

These repositories need to be owned by the git user, and you should probably pick a directory where you will store them all. One sane choice is under /srv/git/, and we will use this as the example directory for the rest of the tutorial, but any other path will do as well.

Become the git user and create the directory

If you're logged in to your server as root and have git installed, you can become the git user by executing

su git

Now navigate to/create your desired directory, for example

cd /srv
mkdir git

Create the repo

Now you can create the bare repository with

git init --bare my-repo.git

By convention, bare repository names end with ".git".

Repeat the above command for any other repositories you want to host.

Syncing local repositories with your server

Set up SSH login for the git user

You will need to be able to login remotely via ssh as the git user we've used before. To do this, you will either need to set up a password for the git user by running passwd git, or copy your public SSH key from your local machine to /home/git/.ssh/authorized_keys. See the SSH keys instructional for details (just log in as git instead of root).

Syncing a new repository with your server

If you've just created a new repository on your local machine, you will need to tell git where the remote repository is to be able to sync with it (using commands like git push or git pull). We do this by defining a "remote" for your repository.

A remote is just a named URL remembered in your repo's configuration. So we need a name and a URL. By convention, the "main" remote is called "origin". The URL has the format user@host:path, where:

user is git, the git user we've already worked with before.
host is your domain name. Alternatively you could even use your server's raw IP address.
path is the absolute path to the repository on the server, in our example /srv/git/my-repo.git

So, to create a new remote, run:

git remote add origin git@yourdomain.xyz:/srv/git/my-repo.git

Now you'll be able to run git push origin master to push your commits or git pull origin to pull from the remote.

Syncing an existing repository

If you've already set up your local repository to sync with a service like GitHub it probably already has a remote called "origin". You can see your repo's remotes with:

git remote -v

You can follow the above instructions, substituting an arbitrary other name other than "origin" to create a differently named remote, e.g.

git remote add vps git@...

Now you'll be able to push/pull with git push vps master and git pull vps, respectively.

Or, to completely sever ties with your centralized git provider, first remove the original origin with: git remote remove origin and then follow the instructions as above.

Contribution

Martin Chrzanowski -- website, donate

Requiring Passwords for Webpages (HTTP Authentication)

Thu, 01 Jul 2021 07:19:27 -0400

Requiring Passwords for Webpages

HTTP basic authentication will allow you to secure parts (or all) of your website with a username and password without the trouble of PHP or Javascript. This will work with any Nginx server.

Installation

We will be using the command htpasswd to make username and password pairs.

apt install apache2-utils

Now think of a username and password and remember them.

htpasswd -c /etc/nginx/myusers username

Type out your password twice to confirm. You can do this as many times as you'd like.

Check out user name password pairs (the password will be securely hashed):

cat /etc/nginx/myusers

Nginx Config and Auth Basic

From here, we are going to edit our websites config file in /etc/nginx/sites-enabled. Have in mind which folder you'd like to secure. Add something like this:

server {
    #...
    location /secret-folder  {
        auth_basic "What's the Password?" ;
        auth_basic_user_file /etc/nginx/myusers ;
    }
    #...
}

If you'd like to do the opposite, such as making the entire site private except for a public section, do this:

server {
    #...
    auth_basic "What's the Password?" ;
    auth_basic_user_file /etc/nginx/myusers ;
    location /public/ {
        #...
        auth_basic off ;
    }
    #...
}

IP Addresses

If passwords aren't enough we can ban an ip or accept one.

location /api {
    #...
    allow 192.168.1.23:8080 ;
    deny 127.0.0.1 ;
}

If you want to check both a username and password with an ip address, use the satisfy directive.

location /api {
    #...
    satify all ;
    allow 192.168.1.23:8080 ;
    deny 127.0.0.1 ;
    auth_basic "What's the Password?" ;
    auth_basic_user_file /etc/nginx/myusers ;
}

Complete Example

http {
    server {
        listen 80;
        root /var/www/website ;
        #...
        location /secret-folder {
            satisfy all ;
            allow 192.168.1.3/24;
            deny 127.0.0.1 ;
            auth_basic "What's the Password?" ;
            auth_basic_user_file /etc/nginx/myusers ;
        }
    }
}

Now check your configuration with nginx -t

Reload nginx and you're good to go!

Contributor - tomfasano.xyz

Cronjobs

Thu, 01 Jul 2021 07:19:04 -0400

Using Cronjobs to run scheduled tasks

Cron is a service that lets you run scheduled tasks. These tasks are called cronjobs. If you have already followed the initial course you will have already used cron when you set up certbot.

What tasks would I want to schedule?

You can schedule anything! Some examples of what you might have done already include:

updatedb to update your locate database
certbot to update renewing of your https certs

Some tasks that you might want to schedule may include:

Package updates - if you really just want to leave your server alone you can automated updating packages on your server
Backups - you may want to backup certain files every day and some every week, this is possible with cron

And many more, anything you can do can be turned into a cronjob.

Basic Cronjobs

This the preferred method for personal tasks and scripts, it's also the easiest to get started with. Run the command crontab -e to access your users crontab

Once you have figured out the command you want to run you need to figure out how often you want to run it and when. I am going to schedule my system updates once a week on at 3:30 AM on a Monday.

We now have to convert this time (Every Monday at 3:30 AM) into a cron time. Cron uses a simple but effective way of scheduling when to run things.

Crontab expressions look like this * * * * * command-to-run The five elements before the command tell when the command is supposed to be run automatically.

So for our Monday at 3:30AM job we would do the following:

 .---------------- minute (0 - 59)
 | .------------- hour (0 - 23)
 | | .---------- day of month (1 - 31)
 | | | .------- month (1 - 12
 | | | | .---- day of week (0 - 6)
 | | | | |
 * * * * *
30 3 * * 1 apt -y update && apt -y upgrade

Some notes

On the day of the week option, Sunday is 0 and counting up from there, Saturday will be 6.
* designates "everything". Our command above has a * in the day of month and month columns. This means it will run regardless of the day of the month or month.
The hour option uses 24 hour time. 3 = 3AM, while use 15 for 3PM.

More examples

Let's add another job, our backup job (for the purposes of this our backup command is just called backup) We want to run backup Every evening at 11PM, once we work out the timings for this we can add the to the same file as the above by running crontab -e This would mean our full crontab would look like this:

0 23 * * * backup

Consecutive times

Suppose we want a command to run every weekday. We know we can put 1 (Monday), but we can also use 1-5 to signify from day 1 (Monday) to day 5 (Friday).

0 6 * * 1-5 echo "Wakey, wakey, wagie!" >> /home/wagie/alarm

The above echo command runs every Monday through Friday at 6:00AM.

Non-consecutive times

We can also randomly specify non-consecutive arguments with a comma. Suppose you have a script you want to run at the midday of the 1st, 15th, and 20th day of every month. You can specify that my putting 1,15,20 for the day of the month argument:

0 12 1,15,20 * * /usr/bin/pay_bills_script

"Every X minutes/days/months"

We can also easily run a command very several minutes or months, without specifying the specific times:

*/15 * * * * updatedb

This cronjob will run the updatedb command every 15 minutes.

Beware of this Rookie Mistake Though...

Suppose you want to run a script once every other month. You might be tempted write this:

* * * */2 *

That might feel right, but this script will be running once every minute during that every other month. You should specify the first two arguments, because with * it will be running every minute and hour!

0 0 1 */2 *

This makes the command run only at 0:00 (12:00AM) on the first day of every two months, which is what we really want.

Consult the website crontab.guru for an intuitive and interactive tester of cronjobs.

User vs. Root Cronjobs

It is important to note that user accounts all have different cronjobs. If you have a user account chad and edit his crontab with crontab -e, the commands you add will be run as the chad user, not root or anyone else.

Bear in mind that if you need root access to run a particular command, you will usually want to add it as root.

System-wide cron directories

crontab -e is the typical interface for adding cronjobs, but it's important to at least know that system-wide jobs are often stored in the file directory. Some programs which need cronjobs will automatically install them in the following way.

Run the command ls /etc/cron* you should see a list of directories and there contents. The directories should be something like the below

/etc/cron.d This is a crontab like the ones that you create with crontab -e
/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly

The directories cron.{hourly,daily,weekly,monthly} are where you can put scripts to run at those times. You don't put normal cron entries here. I prefer to use these directories for system wide jobs that don't relate to an individual user.

Contribution

Mark McNally -- website, Youtube
Edits and examples by Luke

Mirror your site over tor

Thu, 01 Jul 2021 07:15:39 -0400

Mirror Your Site Over Tor

Now that you have a website, why not offer it on a private alternative such as the onion network?

Setting up Tor

Installing Tor

Firstly we need to add the tor repo's to have the latest up to date version or tor.

apt install -y apt-transport-https gpg
echo "deb https://deb.torproject.org/torproject.org buster main
deb-src https://deb.torproject.org/torproject.org buster main" > /etc/apt/sources.list.d/tor.list

Then we need to add the gpg keys to our keyring

curl -s https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --import
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -

Now update and install tor

apt update
apt install tor deb.torproject.org-keyring

Enabling Tor

Then edit the file /etc/tor/torrc, uncommenting the following lines:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

Now start and enable tor at boot

 systemctl enable --now tor

If the next command outputs active in green you're golden!

 systemctl status tor

Now you're server is on the dark web. The following command will give you your onion address:

 cat /var/lib/tor/hidden_service/hostname

Adding the Nginx Config

From here, the steps are almost identical to setting up a normal website configuration file. Follow the steps as if you were making a new website on the webserver tutorial up until the server block of code. Instead, paste this:

        server {
            listen 127.0.0.1:80 ;
            root /var/www/landchad ;
            index index.html ;
            server_name your-onion-address.onion ;
        }

From here we are almost done, all we have to do is enable the site and reload nginx which is also covered in the webserver tutorial.

Update regularly!

Make sure to update Tor on a regular basis by running:

apt update
apt install tor

Contributor - tomfasano.xyz

Cryptocurrency Tutorials Completed

Tue, 29 Jun 2021 08:10:31 -0400

There is now a set of basic tutorials on cryptocurrency wallets and concepts up. The goal here is to allow people to receive tips for sites using all free and open source and peer-to-peer technology.

More tutorials on crypto management and exchanging may be added later, but these focus simply on basic concepts and setting up wallets. They include:

Welcome to LandChad.net!

Mon, 28 Jun 2021 08:21:44 -0400

Welcome to LandChad.net!

This website is for step-by-step tutorials that allow people to host and maintain their own website and other web services on the cheap or free.

There is already a full basic tutorial on website creation on the site here. Following the tutorials can take as little as an hour, but will help you set up a VPS, and NginX server and encrypt your new webpage with Certbot.

Next I plan adding general info on HTML and CSS and how to manage a website.

More stuff like running your own email server and more will be added shortly as more articles are finalized.

LandChad.net: Web Guides for Internet Landchads!

Using UFW as a Firewall

How to Get It

First-Time Setup

Enabling Common Services

Opening Port Numbers

Websites: HTTP and HTTPS

Email: IMAP, POP3, and SMTP

Fine-Tuning Rules

Recovering SSH

Further Reading

Creating Your Own Chat Server With IRC

Installing an IRCd

Configuring Ergo

Network and server names

Network password

Message of the day (MotD)

IP limits

IP cloaking

Password enforcement adjustments for HexChat (and possibly other clients)

Multiclient, always-on clients, history, etc

VHosts

Channels

Operators (administrators, etc)

Chat history

Spam reduction

Starting and using your server

Starting the server

Connecting to the server

Surviving restarts with a SystemD service

Registering accounts and channels

Registering an account with NickServ

Registering channels with ChanServ

Moderation

Understanding masks

Discovering real IPs

Banning someone from the network

Banning someone from a channel

Muting people in a channel

Appointing channel administrators and operators

Bringing modern-day features to IRC with TheLounge

Setting up Gitea

Installing Gitea

Setting up a Nginx reverse proxy

Setting up Gitea

A few extras

Automatically create a new repo on push

Change tab-width

Contribution

Hosting Your Own Git Repositories

Installing git

Creating bare repositories

Become the git user and create the directory

Create the repo

Syncing local repositories with your server

Set up SSH login for the git user

Syncing a new repository with your server

Syncing an existing repository

Contribution

Requiring Passwords for Webpages (HTTP Authentication)

Installation

Nginx Config and Auth Basic

IP Addresses

Complete Example

Cronjobs

What tasks would I want to schedule?

Basic Cronjobs

Some notes

More examples

Consecutive times

Non-consecutive times

"Every X minutes/days/months"

Beware of this Rookie Mistake Though...

User vs. Root Cronjobs

System-wide cron directories

Contribution

Mirror your site over tor

Setting up Tor

Installing Tor

Enabling Tor