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
- install a
Linux
of your choice - reboot in rescue mode that
Linux
distro - download the
Slackware
initrd and prepare the install environment - chroot into the
Slackware
initrd image - partition and install
Slackware
over the existingLinux
- 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.
fail2ban
richiede che si abbia un firewall come nftables
o iptables
attivo.
Changelog
- Nov 20, 2022
-switched all actions tonftables
, as it has now replacediptables
andfail2ban
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 bridgeBloccare 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 proprioHELO/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 recordDNS
.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
:HELO/EHLO
che non possono essere risolti, come stringhe random o domini senza alcunA
record.- falsi
HELO/EHLO
contenenti addirittura uno dei nostri domini, riconoscibili dal fatto che il recordDNS
non corrisponde a uno dei nostriIP
mentre la variabileRELAYCLIENT
non è stata definita; - client il cui
A
record non corrisponde al dominio presente nelHELO/EHLO
. Ciò è palesemente contro laRFC-821
, pertanto la mia configurazione non rifiuterà queste connessioni, che però saranno loggate.