feat: Port knocking port + added old website missing posts

posts/knockd_ufw.md

@@ -0,0 +1,140 @@
+---
+title: OpenSSH port knocking with UFW on Debian
+date: "2023-10-10"
+---
+
+<center>
+    <img src="/openssh.png">
+</center>
+&nbsp;
+
+There are quite a few known methods for securing an **OpenSSH** server that you should already be familiar with, such as disabling remote root access, disabling password login or changing the port (22 by default).
+&nbsp;
+Another highly effective method applicable to SSH ports is port knocking. 
+&nbsp;
+Port knocking is a method of opening ports on a machine by making a series of connections to closed ports. The firewall will then react accordingly.
+&nbsp;
+This is very useful, as it allows you to keep your SSH port closed, so it won't show up on port scans (nmap or other).
+&nbsp;
+This can be done directly by configuring `iptables`, but I've opted to use `ufw` coupled with `knockd`.
+&nbsp;
+
+## How does it work ?
+
+`knockd` is the port-knock server that will run on the target machine as a daemon. It is going to handle the connection on the specified ports in the configuration.
+&nbsp;
+`ufw`, our netfilter firewall program, will be called by `knockd` and in ou case edit `iptables` rules.
+&nbsp;
+
+## Installation
+
+So first, install the packages for both of them
+```bash
+apt install ufw knockd
+```
+&nbsp;
+
+## Configuration
+
+Now, let's see how to configure this tools. I assume that you are using Systemd.
+
+&nbsp;
+
+### ufw
+
+The default `ufw` configuration is enough to perform port knocking, it should be as the following. `ufw` has to be enabled to show its default policies.
+
+```bash
+ufw enable
+ufw status verbose | grep Default
+```
+&nbsp;
+
+Output
+
+```bash
+Default: deny (incoming), allow (outgoing), deny (routed)
+```
+&nbsp;
+
+If it is not the case, you can change the default policies.
+
+```bash
+ufw default allow incoming
+ufw default deny outgoing
+```
+&nbsp;
+
+Once it is done, you can reload the `ufw` configuration to make sure the modifications take effect immediatly.
+
+```bash
+ufw reload
+```
+&nbsp;
+
+### knockd
+
+First of all, make sure that you are using the network interface you want.
+&nbsp;
+In `/etc/default/knockd`, you can edit the `knockd` options that will be used with the executed command by the Systemd service.
+
+```ini
+...
+# command line options
+KNOCKD_OPTS="-i eth0"
+```
+&nbsp;
+
+Now we describe how will `knockd` act by editing `/etc/knockd.conf`.
+
+Here is an example of what could be done, in this example our SSH port is `47612`.
+
+```ini
+[options]
+    UseSyslog
+
+[openSSH]
+    sequence = 7264,3981,5410
+    seq_timeout = 5
+    start_command = ufw allow from %IP% to any port 47612
+
+[tmpOpenSSH]
+    sequence = 8792,6137,2058
+    seq_timeout = 5
+    start_command = ufw allow from %IP% to any port 47612
+    tcpflags = syn
+    cmd_timeout = 10
+    stop_command = ufw delete allow from %IP% to any port 47612
+
+[closeSSH]
+    sequence = 4496,1625,7349
+    seq_timeout = 5
+    start_command = ufw delete allow from %IP% to any port 47612
+```
+&nbsp;
+
+In this configuration are described three `knockd` knocks.
+&nbsp;
+**`openSSH`** will add a new `ufw` rule to allow the client IP address on the port 47612 after the received TCP sequence `7264,3981,5410`.
+
+**`tmpOpenSSH`** will add a `ufw` rule that allowed the client IP address on the port 47612 after the received TCP sequence `8792,6137,2058`. This rule is going to timeout and then be removed after 10 seconds
+
+**`closeSSH`** will remove a `ufw` rule that allowed the client IP address on the port 47612 after the received TCP sequence `4496,1625,7349`.
+
+&nbsp;
+
+You can finally start the port-knock server.
+
+```bash
+systemctl restart knockd
+```
+&nbsp;
+
+## Usage
+
+Now everything is setup, you can use the port-knock client `knock` (from the package `knockd`) to perform TCP connections on your target machine.
+&nbsp;
+As example:
+```bash
+knock -v localhost 7264 3981 5410
+```

posts/linux-config.md

@@ -0,0 +1,30 @@
+---
+title: Linux environment
+date: "2023-02-20"
+---
+
+I've been using only Linux for years now, I've almost always used GNOME and even i3 but without any real configuration effort. Now I have a working environment that I find very practical and that allows me to be fast and more comfortable.
+
+## Overview
+
+<p align="center" width="100%">
+  <img src="/workflow.png">
+</p>
+
+<center>
+  <em>Overview of my current Linux environment</em>
+</center>
+
+&nbsp;
+
+## Easy to install
+
+I have made an automatic installation with Ansible for a faster, easier and more customizable environment setup.
+&nbsp;
+The Nix installation assumes that SELinux is disabled, because Nix has made its own security system.
+&nbsp;
+<p align="center" width="100%">
+  <img src="/nix_security.png">
+</p>
+
+[*Source*](https://github.com/theobori/self-config)

posts/nes-utilities.md

@@ -160,3 +160,5 @@ Address 0x1e05
 Value 0xad
 Compare value 0x8d
 ```
+
+[*Source*](https://github.com/theobori/nes-utils)

posts/teeworlds-utilities.md

@@ -111,15 +111,15 @@ import {
 } from 'teeworlds-utilities';
 
 const mergeTest = async () => {
-  const skin = new Skin();
-  await skin.load('https://teedata.net/databasev2/skins/teedata/teedata.png');
+  const teedata = new Skin();
+  await teedata.load('https://teedata.net/databasev2/skins/teedata/teedata.png');
 
-  const skin_src = new Skin();
-  await skin_src.load('https://teedata.net/databasev2/skins/irradiated%20sunny/irradiated%20sunny.png');
+  const sunny = new Skin();
+  await sunny.load('https://teedata.net/databasev2/skins/irradiated%20sunny/irradiated%20sunny.png');
 
-  skin
+  teedata
     .copyParts(
-      skin_src,
+      sunny,
       SkinPart.FOOT,
       SkinPart.FOOT_SHADOW,
       SkinPart.DEFAULT_EYE,

posts/tf-doom.md

@@ -0,0 +1,37 @@
+---
+title: Terraform chaos engineering
+date: "2023-06-03"
+---
+
+I first saw [kubedoom](https://github.com/storax/kubedoom) and thought it was pretty cool, so I decided to do the same for Terraform, knowing that I was working with it for professional projects. 
+ 
+The principle is very simple, each enemy represents a Terraform resource, if an enemy dies, the associated resource is destroyed.
+
+## How it works ?
+
+The main program is `tf-doom`', which creates a UNIX socket, listens to it and simultaneously launches an X11 virtual server (Xvfb), a VNC server (x11vnc) attached to this X session and `psdoom` (DOOM writing to the UNIX socket). 
+ 
+Everything we've just described will be encapsulated in a Docker container.
+ 
+The binaries `Xvfb` and `x11vnc` are used to create a cross-platform graphical access to `psdoom` inside the container.
+ 
+`psdoom` will continuously write to the UNIX socket to signal `tf-doom` to send Terraform resource information. When an enemy is killed, `psdoom` writes the associated resource name to the socket.
+ 
+<p align="center" width="100%">
+    <img src="/tf-doom.png" width="80%">
+</p>
+
+&nbsp;
+
+## Demo
+
+This demo has been realized with the test Terraform project, every steps to reproduce it are detailed in the README file on the repository.
+&nbsp;
+<p align="center" width="100%">
+    <video controls width="80%">
+        <source src="/tf-doom.mp4" type="video/mp4">
+        <a href="/tf-doom.mp4">MP4</a>
+    </video>
+</p>
+
+[*Source*](https://github.com/theobori/tf-doom)

posts/tf-neuvector.md

@@ -0,0 +1,89 @@
+---
+title: Terraform NeuVector provider
+date: "2023-06-04"
+---
+
+This project is used to manage NeuVector's configuration and its most revelant resources. I was asked to automate the configuration of the solution in a fairly specific context. Initially, I had made a rather well-organized bash script that could apply these resources, but not destroy them.
+ 
+I then asked around and very quickly found Terraform. So I learned how to use it and made a module that could manage any NeuVector resource, including creation and destruction only.
+ 
+A huge problem was the token that NeuVector provides tends to timeout quite quickly (300 seconds by default).
+
+So I decided to create a Terraform provider to handle all this cleanly. The language best suited for this is Go, so I learned it. Hashicorp explains that it's best to separate the client library from the provider.
+
+<p align="center" width="100%">
+    <img src="/terraform_provider.png" width="90%">
+</p>
+
+So I created a Go SDK for NeuVector before using it in the provider, you can find it out [here](https://github.com/theobori/go-neuvector).
+&nbsp;
+Now the provider is able to fully manage the implemented resources (create, delete, update and import).
+
+## Use cases
+
+The provider Terraform block looks like below.
+
+```hcl
+terraform {
+  required_providers {
+    neuvector = {
+      source = "theobori/neuvector"
+      version = "0.4.1"
+    }
+  }
+}
+
+provider "neuvector" {
+  base_url = "https://127.0.0.1:10443/v1/"
+  username = "admin"
+  password = "admin"
+}
+```
+
+&nbsp;
+
+Once it is declared in the configuration, you can start using it as you want. Here's a Terraform example that could be applied after installing NeuVector.
+
+```hcl
+resource "neuvector_eula" "eula" {
+    accepted = true
+}
+
+resource "neuvector_registry" "registry_test" {
+  name                   = "docker.io"
+  registry_type          = "Docker Registry"
+  filters                = ["*"]
+  registry               = "https://registry.hub.docker.com/"
+  rescan_after_db_update = true
+  auth_with_token        = false
+  scan_layers            = true
+}
+
+resource "neuvector_group" "group_test" {
+  name = "mytestgroup"
+
+  criteria {
+    key   = "pattern"
+    value = "[a-z]"
+    op    = "regex"
+  }
+
+  criteria {
+    key   = "namespace"
+    value = "example"
+    op    = "="
+  }
+}
+
+data "neuvector_group_metadata" "group_metadata" {
+    name = neuvector_group.group_test.id
+}
+
+resource "neuvector_service_config" "service_config_test" {
+  services = data.neuvector_group_services.group_metadata.services
+
+  not_scored = true
+}
+```
+
+[*Source*](https://github.com/theobori/terraform-provider-neuvector)

posts/theoboricafe.md

@@ -0,0 +1,23 @@
+---
+title: FOSS accessible services
+date: "2023-09-24"
+---
+
+<center>
+  <img src="/open_source.png" width="30%">
+</center>
+
+&nbsp;
+
+The aim of the project is to provide FOSS (Free Open Source Software) services to anyone who wants to use them. For the moment, the machine(s) used are small and consequently there are a limited number of services and features. This can of course evolve over time, depending on resources and motivation.So, if you're looking for performance above all else, I'd recommend [deuxfleurs.fr](https://deuxfleurs.fr/) or [chatons.org](https://www.chatons.org/).
+
+If you want to use some of my services that required an authentification, feel free to send me an email with one of the addresses listed on the [homepage](/).
+&nbsp;
+It's all about privacy and security. The aim is to be able to use simple and efficient services such as [Nextcloud](https://nextcloud.com/) or [SearXNG](https://docs.searxng.org/), but also to avoid Google, Microsoft, etc. Server configuration and DNS entries are automated and open source on GitHub. See [theobori-cafe organization](https://github.com/theobori-cafe).
+&nbsp;
+Every services status can be checked at [status.theobori.cafe](https://status.theobori.cafe).
+&nbsp;
+While setting up the server(s) and services, I learned some interesting things about network and system security. By the way, an onion [hidden service](https://lojtlkafmrphjhmmksiqsabghyia353ueyfszo6mgqttxaczuata7aid.onion) is available.
+&nbsp;
+
+This project will continue and evolve over time.

posts/tinychip.md

@@ -0,0 +1,42 @@
+---
+title: CHIP-8 emulator
+date: "2023-03-08"
+---
+
+I wanted to learn the basics of emulator development and emulation in general. So I decided to make a CHIP-8 emulator.
+
+In fact it's a misuse of language to say that it's an "emulator" because CHIP-8 is a language, so we should rather say "interpreter".
+
+## How does it works ?
+
+So, basically there are three main components that make it works. The **CPU**, the **API** and the Core (kernel).
+ 
+The **API** polls the keyboard inputs and send them to the **CPU** that put them in the right memory location.
+ 
+The **CPU** fetch, decode and execute an instruction from a **ROM** (program or game), it can change the **VRAM** and the **CPU** registers, etc ..
+Depending of the **CPU** state, the window draw the **VRAM** throught the **API**.
+ 
+There are approximately n instructions executed per second for a frequency of n hz (n is 500 by default). The sound and delay timers are managed with 60hz.
+
+ 
+
+<p align="center" width="100%">
+  <img src="/breakout_320_160.png" width="40%">
+  <img src="/space_invaders_320_160.png" width="40%">
+</p>
+
+&nbsp;
+
+<p align="center" width="100%">
+  <img src="/ibm_logo_640_320.png" width="60%">
+</p>
+
+&nbsp;
+
+## Some extra informations
+
+As I said, it supports some quirks for specific instructions, because according to some old documents,`fx55`, `fx65`, `8xy6` and `8xye` dont have the same semantic depending of the machine they were implemeneted on.
+&nbsp;
+I implemented the 36 instructions + the 4 I was taking before to be compatible with more ROM.
+
+[*Source*](https://github.com/theobori/tinychip)