dev_endboard/README.md

## Description

endboard is a textboard, intented for the use as a small service on tor 
or i2p. It was written with the goal of anonymity and security, both for
the users and the admin. 
Some things work differently in the darknets, and the code needs 
to reflect this. I developed endboard based on the codebase of smolBBS 
(see below) for my site terminus.i2p. Basically I wanted something 
lightweight (1*) that would work on both tor and i2p and be easy
to setup (without an external database). I guess the big time of forums 
and boards is over (making way for TikTok), anyway I couldn't find 
anything that really suited me. 
smolBBS came close at least in the approach, so I started from there. 

(1*) lightweight in terms of ease of installation and maintenance. 
Code minification was a target in the beginning, but I had to give it up
to make space for all the features I wanted.


### For the users

The textboard allows anonymous and pseudonymous posting, and it has optional,
very unprecise timestamps (like: Q1/2025, meaning first quarter of the year 25).
Secure name:tripkey combinations are autogenerated with each post, but 
can be replaced with custom combinations. A valid name:tripkey combination
allows to have a kind of identity that can be used for just one message,
a thread, a sub, or the whole board. Posts can be edited using it as auth.
Only one sub is created automatically (main), others can be created by 
giving a new name for the sub when posting in main.
An overboard lets you keep the overview over the latest postings.
Also, users can define their own multifeeds, including or excluding 
subs of their choice.
There can be replies to posts, which bumps the original posts to the top
of the sub and the overboard (if enabled). A sage button can be used to
not bump a thread. An autosage option can be used to prevent megathreads
from blocking the overboard.
A (very simple) captcha can be used to protect from some spam.
Individual threads, subs or the whole board can be dumped to a json file. 
The dump of the whole board can be reimported into other instances of 
endboard, which will replicate all messages from the existing board
(the "save overboard" link actually dumps all posts on the board, 
including those that are not actually displayed on the overboard).
A landing page provides an overview of the site and the subs, and it 
lets the user choose between different display styles.
If enabled, users can make automated posts via a bot api.
A simple bbcode dialect can be used to display headlines, bold text, 
underlined text, strikethrough text, spoilers and links.


### For the admin

All options can be configured in one config file (or two, if the 
webserver counts). 
After login, the admin has access to a panel in which posts and subs can
be deleted. Also, logs can be reviewed and messages imported 
(from other instances of endboard).
The administration is fairly straightforward, like the user interface. 
Be careful when deleting posts, and especially whole subs, as they 
cannot be restored.
Data backup should be done on a regular basis, this can be achieved by 
simply copying the database file.
For the use of the admin panel, no cookies are necessary.
Moderators can help with the administration. In contrast to the admin, 
a message or sub deleted by a moderator is not actually deleted and can 
be restored after.
The access to the admin panel and the moderators panel can be disabled 
in the config file, if needed.
For sites which are actively targeted and want to maximize security, 
the interface for users, the panel for the admin and the panel for the 
moderators could listen on three different addresses, where only the one
for the users would be public and the other two would be kept secret.
A simple fail2ban mechanism can be used to restrict the number of 
unsuccessful logins (if exceeded, the interface will sent 
429 - too many requests).


### Technical description

endboard is written in php and works with the versions 7 and 8. The 
modules used are php-mbstring, php-json, php-fpm and php-sqlite3. 
All posts are stored in a single database file (the path of which can
be configured).
The webserver used is nginx. Other servers should work as well, provided
that they can perform server rewrites and the admin replicates the one
from nginx (provided with the config file).

The php is (with the exception of the calls to sqlite3) procedural. The 
php code for the control flow is in two files: 
index.php and /mob/index.php (for the mobile site). The configuration is
defined in config.php (/etc/opt/endboard).
The functions are in six files in /opt/endboard.

Paths were chosen according to recent Linux standards (config goes to /etc, 
working files to /var, the actual website to /srv). 
Custom paths can be used, but will need adaption of config file 
and/or index.php.

### Release history:

* 0.63 : changed from hash() to password_hash() for passwords, thanks anon.
* 0.64 : fixed a bug in destroy_token(), which would not log you out,
         although claiming to do so
* 0.65 : introduced new function filter(), to get rid of lenghty 
         substr(preg_replace constructions
         fixed a bug in check_free_space()
         minor optimizations (like empty instead of isset)
* 0.66 : put in some additional safety for the admin & mod tokens_
* 0.67 : fixed two embarrassing bugs that prevented the admin and the mods
         from logging in
* 0.70 : various bugfixes and reformatting
* 0.71 : introduction of mobile design (thanks, anon !)
* 0.73 : added features: sage, autosage, timestamps, secure tripcodes, editing
         of messages, clickable links for post references, debug interface
         for desktop site (to do list for mobile site)
         also took functions out of index.php and put them in six smaller
         files 
* 0.80 : bugfixes, changed css link scheme to name


### Other features of endboard:

1) to have pretty urls (means: well readable), the request parameters 
   are parsed directly from $_SERVER['REQUEST_URI'], instead of using 
   the $GET array. 
   This leads to links like : http://terminus.i2p/s/main instead of 
   http://terminus.i2p/?s=main.

2) treatment of bots: there are a lot of crawlers, spiders and scrapers 
   out there that don't respect robot.txt, this is just a fact of the 
   internet. There is no reason to make it easy on them, though.
   In fact, I can think of a lot of reasons not to. Therefore, several 
   links which are not visible to the users are sprinkled over the site.
   Garbage data is sent to any bot that follows. More garbage
   data is fed to bots that even follow links on the garbage site 
   itself. Badly coded bots and scripts can crash under the number of 
   links that is sent to them. Stay off my site next time.
   Bots can also be blocked from the site on the basis of the ips. 
   Obviously, this works better for i2p than for tor.

3) endboard provides a shortform to view subs, based on the first match. 
   So, http://terminus.i2p/s/m will lead to the sub 'main', because this
   is the first match. http://terminus.i2p/s/me will lead to 'meta'.
   The shortform is casesensitive, so http://terminus.i2p/s/p will lead 
   to 'pr0n', but http://terminus.i2p/s/P will lead to 'PP'.


## Opsec


### Best practises that were followed in the coding of endboard:

* all user input is checked and filtered before further use
* in particular, all tags are stripped from posted texts
* no javascript, no cookies, no tracking is used anywhere
* config file and database are not in webroot
* all passwords and keys are hashed with the bcrypt function used by php
 password_hash(). 
 (except the keys for the bots, as those are not considered sensitive)
* all interactions with the db take place via prepared statements
* the panels for mods and admins can be disabled in the config file


### Best practises that were _not_ followed in the coding of endboard:

* the access to the admin and mod panels (after initial authentification 
 with name/password) is done via a server generated token which is 
 transmitted in part via links to GET requests.
 As such, this is a bad practise because it could enable an attacker to 
 acquire this token and thus steal the admin session. To make this 
 harder, the token is very long (250 characters), so that it cannot be 
 memorized, and is not fully displayed in the address bar. Also, each 
 token has a limited lifetime (that can be set in the config file) and is
 deleted once the admin or mod logs out.
 On top of that, the token is regenerated after each transaction, so that
 even if an attacker could get hold of an existing token, it would only
 be valid until the next activity of the admin or mod. If an attacker
 was able to steal the token and use it successfully, the admin or mod
 would notice with their next click (which would generate an error message
 on account of their own (now invalidated) token).
 The reason for all this is that I did not want the admin of the board 
 to have to have cookies enabled, which would be the normal way of 
 dealing with this (or to give credentials for each activity, like it 
 was in earlier versions). 
 There are risks implied with this new approach, but it is better than 
 cookies imo. Another implication of this is that endboard absolutely 
 needs end-to-end encryption to be provided by the underlying network, 
 like it is the case with tor and i2p. On clearnet, it would be trivial 
 to steal a token for any machine between client and server (like it 
 used to be with pop and ftp passwords, remember?).
 On the darknets, this approach should work fine, though, and you don't 
 have to worry about cookies identifying you as the admin of an 
 infamous textboard :-).


## Changes from smolBBS

Almost no original code is left from smolBBS, the leftovers are the 
captcha generation and a part of the spam check. I also stayed with the 
idea of having different modes of the site to structure the code 
(although there are a lot more now). 
All in all, endboard has a lot more features today, and is not really 
comparable any longer. Thanks go to sandlind for the initial inspiration
 to make a board that is just simple and working.


## Installation instructions

The following instructions use debian, because I'm lazy. Adapt to your 
system if needed. The setup of a tor hidden service or an eepsite is not
part of the instructions, as these topics are covered in countless other
instructions already. 
The same for securing your server and making sure it doesn't blab.


### Update your system and install needed components:

``` apt update && apt upgrade -y```

``` apt install -y php php-json php-mbstring php-sqlite3 php-fpm nginx```

### Make directories:

``` mkdir -p /srv/endboard/mob /etc/opt/endboard```

``` mkdir -p /var/opt/endboard /opt/endboard```

### Distribute files to webroot (from directory of the endboard archive):

``` cp -rv ./srv/* /srv/endboard/```

### Distribute function files (from directory of the endboard archive):

``` cp -v ./opt/*.php /opt/endboard/```

### Distribute config file to etc (from directory of the endboard archive):

``` cp -v ./etc/config.php /etc/opt/endboard/```

### Give ownership of working directory to webserver:

``` chown -R www-data:www-data /var/opt/endboard```

### Copy config file for nginx (from directory of the endboard archive):

``` cp ./etc/endboard /etc/nginx/sites-available/```

Edit the two config files according to your needs (at the very least, 
define the landing page and the name of the admin account). 

### Enable the site:

``` ln -s /etc/nginx/sites-available/endboard /etc/nginx/sites-enabled/```

### Then, test and restart web server:

``` nginx -t && systemctl reload nginx```

### Don't want to type too much ?

After updating your system, installing the needed components and editing
the two config files, you can also use the install script to do the rest
for you, like this:

``` ./install.sh all```

### First use

Before you publish your servers address anywhere, open your browser and 
go to http://youraddress.i2p/aa (or locally to http://127.0.0.1/aa).

If everything went well, this will take you to a form where you can set 
your admin password. Be sure to do that first.

You will need the admin token generated by the server, you can get it 
like this:

``` tail -n 1 /var/opt/endboard/admin_$name_token.txt```

(where $name is the name you have defined for the admin account).

Then, put the name of the admin as defined in the config-file, the token
that you obtained, and a suitable password. Passwords need to be 10 
characters at least, must contain at least one letter, and cannot 
consist of only one letter. 

After this procedure, you can disable the admin interface in the config 
file, if you want, and only enable it when needed.

### Moderators

If enabled in the config file (take_applications), users can apply to be
moderators under:

http://youraddress.i2p/ap

The form requires a name and an email address (although a phonenumber or
other kind of contact could be put here as well).

The admin can enable, disable and delete moderators accounts from 
the admin panel.

For normal moderation, a moderators account is enough and should be used
in the day-to-day work. The admin account is only needed to view logs, 
change the status of moderators accounts, import messages or delete 
posts from the db (whereas the moderators can only hide posts so that 
they are not displayed any longer).



## Risks when using endboard:

* bugs in the code of endboard, this is still the beta version
* if you run a public server somewhere on the internet, you are 
 responsible for the content that is posted. Although it is quite 
 unlikely that you can/will be held accountable (if you do the setup 
 right), it is still advisable to delete content that is illegal in your
 jurisdiction in a reasonable timeframe. 
 If you don't do that, this is on you.


## Limits of the endboard software


### Admin

Currently, there is only one admin account, the name of which is defined
in the config file. If the password is lost, it cannot be reset. 
Instead, the name of the admin account needs to be changed.
In future versions, other admin accounts can be defined.
Setting the password of the admin account during first use requires 
knowledge of the name that is defined in the config file, as well as a 
token generated by the server (in /var).
In theory, an attacker could send a flood of requests with guessed names
and tokens before the admin was able to set their password. 
Because of the length of the token this approach is very unlikely 
to succeed.


### Network

endboard relies on being on a darknet that provides full end-to-end 
encryption between client and server (which is the case for both tor 
and i2p). While endboard will run on the clearnet or on a Lan just fine 
(for the users), the panels for the admin and the moderators are not 
secured against attackers that are able to read the traffic between the 
browser and the server. ssl could probably be used for this, but 
clearnet is not the usecase anyway, so I will put no work into it.


### Traffic

The php and database components of endboard are able to manage a lot of 
traffic, by darknet standards. Using sqlite3 is faster than using a 
separate db engine, at least when it comes to read requests.
When it comes to concurrent write requests, sqlite3 is slower in 
managing them, but still fast enough (I guess...). 
Several posts arriving at the exactly the same point in time will be 
treated one after another, without dropping any of them (according to 
some testing, this should work with up to 46 posts per second
and possibly more).
Chances are that the latency of the connections and the network 
resources play a larger role than the potential waiting time 
(but no precise measurements have been done yet).


### Captcha

The captcha is simple, and its parameters can be read directly from the 
source of the page. A moderately skilled attacker could write a bot that
cracks it and spam the board.
Since captcha systems provide little protection in general, it is not 
used by default.
A postform can still be only used once, and for a limited time, 
since it is preloaded with a token.


### Log files

endboard logs events like deletions, imports, authorization failures and
others to the db. The logs can be viewed on the admin panel, although 
the view is not very sophisticated. This needs more work. 
Another option would be to log to /var/log or syslog. Maybe in future
versions.


### Display on mobile screens

For some reason the display on small screens used to suck. Along came
one anon who made a working proposal. This is the current status, it is
implemented, but still experimental. More work is needed to smooth the
edges.
The mobile site can be found under /mob/. It does not include all the
functions for admins and mods, those should be used with the original
site.


### Number of posts, number of subs

The theoretical maximum number of rows in a table is 2^64 
(18446744073709551616 or about 1.8e+19). This limit is unreachable since
the maximum database size of 140 terabytes will be reached first.
A 140 terabytes database can hold no more than approximately 1e+13 rows,
and then only if there are no indices and if each row contains very 
little data.  (http://stackoverflow.com/questions/1546947/ddg#9456705)

I'm not sure what this means for the users of endboard, but I'm pretty 
confident that nobody will post more content than a terabyte to a board 
like this. A terabyte of text only, that's an assload of posts.
That's as precise as it gets for now.


## Changes from earlier versions

The code has been almost completely rewritten. A lot of features have 
been added, and a lot of bugs were fixed. 
The most notable change is that endboard uses sqlite3 now instead of 
storing the messages in json files.

## Licence stuff

* The writing of the code of endboard started some time ago with another
* software called smolBBS. Although there is almost no original code 
* left now, I still regard endboard as a fork of smolBBS.
* The author of smolBBS has required that the following text be 
* distributed with any redistribution, so here it goes. 
* The license and other conditions apply to endboard as well.
*
* IRC: *dulm @ irc.rizon.net
*
* Copyright (C) 2020 sandlind
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met:   
*
* (1) Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer. 
*
* (2) Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* (3)The name of the author may not be used to
* endorse or promote products derived from this software without
* specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.