Wrapper scripts for LXC unprivileged containers

22 dicembre 2022 Roberto Puzzanghera 0 commenti

Index

• Part 1: Introduction
• Part 2: Basic configuration files
• Part 3: Creating an unprivileged container on Slackware
• Part 4: Scripts overview
• Part 5: Natting example
• Browse the scripts' folder

---

A common use of the LXC unprivileged containers is to isolate services like sql, ftp, httpd, mail etc. in an host server where the only user who will ever login is root. In this case, handling the unprivileged containers can be quite annoying.

In fact, one would like to have all the containers inside the same directory, tipically /lxc, while LXC will install them in the $HOME/.local/share/lxc directory of the container's owner user. In addition, root has to administer a container as its owner user (i.e. using sudo -u <user>), by defining the configuration file and other parameters by means of a long command to type and remember. If you have many unprivileged containers and have to perform tasks like start/stop/attach frequently, your patience will come to an end very quickly.

This is the reason why at a certain point I started to write my own wrapper scripts for the most common LXC commands. Nothing special, but it seems that no one has published any tools to simplify the LXC common tasks with unprivileged containers, so it may be worth posting here what I have done.

Converting a Linux installation to a Slackware one in an OVH Kimsufi server

27 novembre 2022 Roberto Puzzanghera 0 commenti

This article explains how to convert a given Linux distribution to a Slackware one in an OVH kimsufi server.

It is inspired by the Slackware wiki page Install Slackware on an online.net Dedibox BareMetal Server, which explains the same for a Dedibox BareMetal Server on online.net.

The plan is to

1. install a Linux of your choice
2. reboot in rescue mode that Linux distro
3. download the Slackware initrd and prepare the install environment
4. chroot into the Slackware initrd image
5. partition and install Slackware over the existing Linux
6. configure the fresh installed Slackware and reboot

Impostare il firewall con fail2ban

20 novembre 2022 Roberto Puzzanghera 0 commenti

• Versione: 1.0.2
• Maggiori informazioni qui
• Howto (wiki)
• Manuale

Fail2ban ispeziona i log file (ad es. /var/log/apache/error_log) e banna IPs che mostrano un comportamento sospetto -- troppe password sbagliate, tentativi di  exploits, etc. Generalmente Fail2Ban è quindi usato per aggiornare le regole del  firewall al fine di rigettare gli indirizzi IP durante un intervallo di tempo settabile, benchè ogni altra azione (come l'invio di una mail di notifica) può anche altresì essere impostata. Tra le altre cose Fail2Ban mette a disposizione dei filtri per diversi servizi come apache, courier, ssh, etc.

Mostrerò brevemente come installare e configurare fail2ban per rigettare le connessioni di IP sospetti, specialmente quelli riguardanti la patch qmail-dnsrbl. Ciò evita di essere bannati noi stessi da spamhaus, che è gratuito solo fino a 100.000 query al giorno.

fail2banrichiede che si abbia un firewall come nftables o iptables attivo.

Changelog

• Nov 20, 2022
  -switched all actions to nftables, as it has now replaced iptables and fail2ban has support for it. Just replace "iptables" with "nftables" in your jails.
• Nov 18, 2022
  - fail2ban upgraded to v. 1.0.2
  - jails now have a different action's declaration (iptables[type=multiport] instead of iptables-multiport[])
  - added a short note on how to configure the server with a network bridge
  leggi tutto

  Bloccare gli HELO/EHLO con falso DNS

  26 febbraio 2022 Roberto Puzzanghera 0 commenti

  La Sezione 3.5 del documento RFC-821 afferma che

  The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.

  The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

  Non ammettere i client con un record DNS bacato nel proprio HELO/EHLO può essere sensato non solo perché suggerito dalla RFC di cui sopra, ma anche una cosa conveniente per l'amministratore, che non dovrà perdere il suo tempo ad aggiungere continuamente record alla whitelist per colpa dei client regolari che non hanno settato bene il proprio record DNS.

  Ma d'altra parte, è un dato di fatto che praticamente tutti gli spammers utilizzino nel loro HELO domini che non appartengono loro -spesso addirittura uno dei nostri stessi domini (cosa ovviamente intollerabile)-, oppure delle stringhe random o domini che non sono riconducibili ad alcun IP.

  Per esempio, consideriamo le seguenti righe del mio log (ne ho sempre moltissime):

  2022-02-01 10:19:53.142643500 helo-dns-check: HELO [yq3H9cDKgS] from [109.237.103.41] doesn't solve
  2022-02-01 09:53:05.772497500 helo-dns-check: HELO [sagredo.eu] is a local domain but IP [183.240.55.119] is not a RELAYCLIENT

  Penso che, a prescindere da cosa dica l'RFC sopra menzionato, non si commetta un peccato mortale se si respingono almeno i client che riportano gli errori di cui sopra.

  Spiegherò quindi qui sotto come settare un filtro che respinga i seguenti problemi a livello DNS:

  1. HELO/EHLO che non possono essere risolti, come stringhe random o domini senza alcun A record.
  2. falsi HELO/EHLO contenenti addirittura uno dei nostri domini, riconoscibili dal fatto che il record DNS non corrisponde a uno dei nostri IP mentre la variabile RELAYCLIENT non è stata definita;
  3. client il cui A record non corrisponde al dominio presente nel HELO/EHLO. Ciò è palesemente contro la RFC-821, pertanto la mia configurazione non rifiuterà queste connessioni, che però saranno loggate.
  leggi tutto
  • Prec.
  • 1
  • 2
  • 3