L'idée est de permettre l'accès à tout le monde, sans mot de passe, à un répertoire du serveur Debian.
(et d'empêcher les utilisateurs connectés d'en sortir !).

Le script global-deb vous permet de faire cette installation automatiquement

Passez en root

su -

1) Installez VsFTPd

apt install vsftp -y

systemctl enable vsftpd 

2) Renommez le fichier de configuration par défaut afin de le préserver

mv /etc/vsftpd.conf /etc/vsftpd.conf.BAK

3) Ecrivez votre propre fichier de configuration (/etc/vsftpd.conf) avec le contenu suivant :

### CONFIG FTP PUBLIC ###
listen=NO
listen_ipv6=YES

anonymous_enable=YES
anon_root=/srv/ftp/ANON
no_anon_password=YES
hide_ids=YES

# Si vous voulez donner le droit d'écrire et d'uploader, décommentez les lignes suivantes :
#write_enable=YES
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
#anon_other_write_enable=YES
#anon_umask=022

local_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd

# Bon à savoir, pas de session anonyme possible en FTPS !
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=NO

# Dans le cas où vous voudriez restreindre l'accès au serveur à une seule interface, entrez l'IP de l'interface du serveur voulue et décommentez les 2 lignes.
# Par défaut, VsFTPd écoutera sur toutes les interfaces
#listen=YES
#listen_address=IP-DE-LINTERFACE-VOULUE

4) Créez le répertoire pour les anonymes :

mkdir -p /srv/ftp/ANON/PUBLIC

chown nobody:nogroup /srv/ftp/ANON

chmod a+rwx /srv/ftp/ANON/PUBLIC

Les utilisateurs pourront uploader dans le dossier "PUBLIC" mais pas à la racine de leur répertoire.

5) Redémarrez le serveur :

systemctl restart vsftpd

Les utilisateurs peuvent désormais se connecter sans mot de passe.

Le script pour Debian 11 ne fonctionne pas sur Bookworm

Le script général a été mis à jour.

Voici comment procéder :

En root :

su -

apt install python3 shared-mime-info unzip apt-show-versions libapt-pkg-perl libauthen-pam-perl libio-pty-perl libnet-ssleay-perl curl -y

curl -L -O https://www.webmin.com/download/deb/webmin-current.deb

dpkg -i webmin-current.deb

systemctl restart webmin

On accède toujours à la console via le navigateur web d'un client sur le même réseau (à moins de changer cela dans /etc/webmin/miniserv.conf) :

https://IP-SERVEUR-WEBMIN:10000

Plusieurs outils vous permettent de faire cela : stress, s-tui, stressapptest etc..
C'est utile pour tester le bon fonctionnement des alertes d'un superviseur (entre autres)

Nous allons utiliser le plus basique : stress, mais vous pouvez installer s-tui si vous souhaitez voir qques couleurs sur votre ligne de commande !

1) Passez en root :

su -

2) Installer stress, s-tui, stressapptest

apt install stress s-tui stressapptest -y

3) Effectuez un test de stress.
On considère que :
- le test doit durer 5minutes
- vous avez 2 consoles SSH ouvertes. L'une pour monitorer (avec top,htop,btop..), l'autre pour exécuter la commande de stress
- on veut de la verbosité !
- on ne lance qu'un processus (-c) de stress.

stress -c 1 -t 2m -v

Le stress devrait couvrir 100% de la capacité du CPU.

Si vous souhaitez un stress "plus contrôlé" (il vous faut au moins 2 coeurs sur votre serveur) :

stress -c 1 -i 50 -t 2m -v

(faîtes varier le nombre pour augmenter ou diminuer la charge CPU jusqu'à arriver au niveau de stress que vous souhaitez...)).
Il faut parfois attendre environ 1 minute pour atteindre le maximum de stress occasionné par le nombre indiqué (ça monte d'un coup au début, puis il faut attendre pour franchir un nouveau pallier), et vous verrez le CPU monter subitement d'un coup.

Si vous souhaitez utiliser s-tui, lancez simplement :

s-tui

Si vous souhaitez essayer stressapptest :

stressapptest -m 1 -M 300 -s 120

va tester 300Mo de RAM pendant 120 secondes. (par exemple.. mais vous pouvez également stresser le CPU avec stressapptest.. Voir MAN)

On doit passer par Snap, ce qui n'est pas vraiment une bonne idée sur un serveur debian... néanmoins, je précise comment procéder :

1) Passer en root

su -

2) Installer snapd

apt install snapd -y

3) Installer le noyau de snap

snap install core

4) Installer btop

snap install btop

5) Redémarrer votre serveur :

reboot

Vous pouvez à présent vous servir de btop... :

btop

La commande "locate" (qui s'installe) créée une base de données (un index... en termes windosiens) qui vous permettra ensuite de recherche des fichiers de façon récursive, beaucoup plus rapidement qu'avec find !

On passe en root :

su - 

On installe locate :

apt install locate -y

On lance l'indexation de la totalité des fichiers (elle se refera automatiquement tous les jours) :

updatedb

Et maintenant on peut commencer à chercher !

locate .conf

... vous sortira la liste de tous les fichiers .conf présents !

Voir

man locate

pour obtenir plus d'informations sur les options disponibles !

Lorsque vous démarrez votre serveur et passez en root, vous obtenez un prompt tel que

root@debian:~#

(c'est ce "debian" que nous allons changer en "SRV-DEBIAN" pour l'exemple).

Le renommage d'un serveur debian se fait en remplaçant le nom actuel dans 2 fichiers :
- /etc/hosts
- /etc/hostname

Pour ce faire, passez en root (si vous n'y êtes pas déjà)

su -

Puis modifiez les 2 fichiers comme annoncé plus haut (vous pouvez utiliser les 2 commandes suivantes en copier/coller pour aller plus vite, sinon utilisez nano /etc/hosts et nano /etc/hostname pour modifier à la main, puis remplacez debian par SRV-DEBIAN)

sed -i "s/debian/SRV-DEBIAN/" /etc/hosts

sed -i "s/debian/SRV-DEBIAN/" /etc/hostname

Enfin, redémarrez votre serveur :

reboot

Nftables isn't as straightforward to use as iptables...
We have a few operations to perform beforehand:

Create a table, which will contain:
our 'input' and 'output' chains (the inbound and outbound directions for our flows).
Create our usual firewall rules
Ntables operates on the principle of tables.

The following is an introduction to nftables.. Further exploration will be necessary

1) Create a table
It will contain our 'chains', which in turn will contain our 'rules'.
I name it 'default' because I don't intend to create multiple for this tutorial... But of course, you can create multiple tables !

nft add table ip default

(replace ip with ip6 for an IPv6 table)

To display our created table:

nft list tables

To delete our table :

nft delete table ip default

2) Creating input and output chains:

nft add chain ip default INBOUND_TRAFFIC { type filter hook input priority 0; }

nft add chain ip default OUTBOUND_TRAFFIC { type filter hook output priority 0; }

To view the chains :

nft list table ip default

To remove a chain :

nft delete chain ip default OUTBOUND_TRAFFIC

3) Creating our rules
We open what we need, then we close.
The last rule is used to close

Example : opening a port for TCP (such as HTTPS, for your web server)

nft add rule default INBOUND_TRAFFIC tcp dport 443 accept

Allow ping (but not to be pingable)

nft add rule default OUTBOUND_TRAFFIC icmp type echo-request accept

nft add rule default INBOUND_TRAFFIC icmp type echo-reply accept

Allow HTTPS outbound :

nft add rule default OUTBOUND_TRAFFIC tcp dport 443 accept

Closing :

nft add rule default INBOUND_TRAFFIC drop

nft add rule default OUTBOUND_TRAFFIC drop

To view our rules :

nft -a list table ip default

Each rule is identifiable by its position and cas thus be replaced or modified more easily than before.

To delete the rule at "handle 1":

nft delete rule default OUTBOUND_TRAFFIC position 1

To add a rule just before position 1 :

nft insert rule default OUTBOUND_TRAFFIC position 1 ip daddr 132.18.24.16 drop

Ban an IP

nft add rule default INBOUND_TRAFFIC ip saddr 132.18.24.16 drop

nft add rule default OUTBOUND_TRAFFIC ip saddr 132.18.24.16 drop

To ban an entire subnet, replace the IP with CIDR notation: 132.18.24.16/24

Delete all rules from the OUTBOUND_TRAFFIC in our "default" filter :

nft flush chain default OUTBOUND_TRAFFIC

Create a scripted rules file : /etc/nftables.conf
A file with a default table already exists; we can make a copy and write our own file, as shown below :
In a way similar to IPF, we indicate the command to use at the beginning of the script.
Please note, what follows is very basic (SSH, http, https, and ping):

#!/sbin/nft -f

# Flush last ruleset :
flush ruleset 

# Creation of the default table
add table default

# Creation of inbound and outbound flows
add chain ip default INBOUND_TRAFFIC { type filter hook input priority 0; }
add chain ip default OUTBOUND_TRAFFIC { type filter hook output priority 0; }

# List of rules
add rule default INBOUND_TRAFFIC tcp dport 22 accept
add rule default OUTBOUND_TRAFFIC tcp sport 22 accept

add rule default INBOUND_TRAFFIC tcp sport 80 accept
add rule default OUTBOUND_TRAFFIC tcp dport 80 accept

add rule default INBOUND_TRAFFIC tcp sport 443 accept
add rule default OUTBOUND_TRAFFIC tcp dport 443 accept

add rule default INBOUND_TRAFFIC udp sport 53 accept
add rule default OUTBOUND_TRAFFIC udp dport 53 accept

add rule default INBOUND_TRAFFIC icmp type echo-request accept
add rule default OUTBOUND_TRAFFIC icmp type echo-reply accept

# Close the firewall :
add rule default INBOUND_TRAFFIC drop
add rule default OUTBOUND_TRAFFIC drop

I encourage you to refer to the following article for further details (especially regarding the flags) :
https://wiki.gentoo.org/wiki/Nftables/Examples#Typical_workstation_.28separate_IPv4_and_IPv6.29

L'idée ici, c'est de migrer GLPI d'un serveur nommé "SOURCE" à un serveur nommé "DESTINATION".

Pré-requis :
- GLPI est correctement installé et fonctionnel sur le serveur SOURCE.
- Il a été initialisé proprement et nous avons rajouté un utilisateur afin de vérifier que l'utilisateur sera bien migré.

La migration en deux mots :

La méthode que je vous propose est de faire un dump SQL de glpi (sur le serveur SOURCE), de le compresser, puis de l'envoyer via scp/sftp sur le serveur DESTINATION.

Sur le serveur DESTINATION, nous allons tout simplement réinstaller glpi avec le script global-DEB3 (rubrique 7, choix 4, en prenant soin de recréer le même nom de base SQL et le même utilisateur privilégié sur la base SQL pour GLPI).
ATTENTION, la version de GLPI doit être rigoureusement la même sur les 2 serveurs. Dans le script, il s'agît de la 10.0.4. Ce tuto vous montre comment réinstaller GLPI manuellement, à vous de changer la version téléchargée de GLPI si vous le souhaitez.

Grâce à un ordinateur CLIENT (avec un environnement de bureau) sur le même réseau que le serveur DESTINATION, nous nous connecterons à l'IP du serveur DESTINATION, nous installerons GLPI en initialisant la nouvelle base SQL, comme s'il s'agissait d'une nouvelle installation. Nous nous loguerons dans GLPI grâce à l'utilisateur par défaut glpi/glpi, puis nous retournerons sur le serveur DESTINATION puis nous importerons le dump arrivé du serveur SOURCE dans la nouvelle base SQL.... GLPI n'y voit que du feu !

Sur le Serveur SOURCE :
(Passez en root pour commencer)

su -

1) Exporter la base SQL de glpi.
(la mienne s'appelle glpidb)

mysqldump -uroot -p glpidb > /tmp/glpidb.sql.BAK

(attention à l'option -p pour le mot de passe de l'utilisateur root de mysql... si vous n'en avez pas défini, ne mettez pas l'option !)... ça donnerait ça :

mysqldump -uroot glpidb > /tmp/glpidb.sql.BAK

2) La compresser pour facilier l'envoi.
Deux méthodes : Personnellement je préfère zip à tar.gz ... mais chacun son choix.

apt install zip -y

cd /tmp

zip glpidb.sql.BAK.zip glpidb.sql.BAK

3) Envoyer la backup SQL sur le serveur DESTINATION
(là encore, beaucoup d'options... scp, sftp etc... pour changer un peu, je vais utiliser sftp.
Remplacez le port 22 par un autre si vous l'avez changé sur DESTINATION).
Je vais envoyer le fichier dans le répertoire /tmp sur le serveur DESTINATION

sftp -oPort=22 adminweb@IP-SERVEUR-DESTINATION

sftp> put /tmp/glpidb.sql.BAK.zip /tmp/

sftp> exit

Sur le Serveur DESTINATION :

(Passez en root pour commencer)

su

Ci-dessous la procédure manuelle si vous n'utilisez pas le script global-DEB3 pour réinstaller GLPI :

1) Installer mariadb, apache, php et unzip

apt install mariadb-server apache2 unzip php php-curl php-gd php-json php-mbstring php-ldap php-zip php-bz2 php-mysql php-xml php-intl libapache2-mod-php -y

systemctl enable apache2

mysql_secure_installation

attention avec le mot de passe root pour mysql.. Si vous en définissez un, alors il faudra mettre l'option -p dans les commandes suivantes (ici je n'en mets pas, pour l'instant)

2) Créer une base SQL pour accueillir notre backup
(attention, le nom de la base SQL doit être RIGOUREUSEMENT IDENTIQUE à celui de la base sur le serveur SOURCE)

mysqladmin -uroot create glpidb

3) Créer l'utilisateur privilégié sur cette base 
(attention, les identifiants de l'utilisateur doivent être RIGOUREUSEMENT IDENTIQUES à ceux de l'utilisateur privilégié sur la base SQL glpidb du serveur SOURCE)

mysql -uroot -e"GRANT ALL ON glpidb.* TO 'adminglpi'@localhost IDENTIFIED BY 'P@ssw0rd'"

4) Installer GLPI :

wget https://github.com/glpi-project/glpi/releases/download/10.0.4/glpi-10.0.4.tgz -P /tmp

cd /tmp

tar xvzf glpi-10.0.4.tgz

rm /var/www/html/index.html

mv glpi/* /var/www/html/

chown -R www-data:www-data /var/www/html

chmod -R 755 /var/www/html

systemctl start apache2

Sur le PC CLIENT :
1) Utiliser le navigateur internet pour vous connecter au serveur DESTINATION :

http://IP-DESTINATION

GLPI apparaît. Procédez à une installation, comme d'habitude. Initialiez GLPI avec sa base SQL.
Une fois arrivé sur l'écran d'identification utilisateur, identifiez-vous en glpi/glpi puis retournez sur le serveur DESTINATION

Sur le Serveur DESTINATION :

1) Décompresser et importez la backup

cd /tmp

apt install unzip -y

unzip glpidb.sql.BAK.zip 

cat glpidb.sql.BAK | mysql -uroot glpidb

Voilà, c'est terminé.

- Une fois votre site web dûment installé et configuré (avec libapache2-mod-evasive),
- Une fois la correspondance entre le nom du site et l'IP du serveur faite dans le fichier /etc/hosts (du serveur),
- Une fois la configuration d'iptables (ou d'nftables) dûment effectuée,
- Une fois fail2ban dûment configuré (utilisez le script général debian !... paramétrer fail2ban contre les DDoS avec apache est particulièrement casse-pied sur debian)

Il est temps de tester la résistance à une attaque DDoS !

Utilisez la commande suivante directement depuis votre serveur web :

ab -n 1000 -c 20 https://VOTRE-SITE-WEB:PORT/

Si vous souhaitez simuler une vraie attaque, depuis une autre machine, vous pouvez installer bon nombre de logiciels pour cela !
J'utilise ddosify sur FreeBSD, mais il est peu courrant sur Linux.
Il est néanmoins présent sur Github pour Linux et peut être installé facilement sur Debian ou Fedora.
https://github.com/ddosify/ddosify

Voici comment l'installer sur Debian : (passez en root)

apt install wget -y

wget -qO ddosify.deb https://github.com/ddosify/ddosify/releases/latest/download/ddosify_amd64.deb

apt install -y ./ddosify.deb

rm -rf ddosify.deb

Voici la syntaxe pour attaquer votre serveur :

ddosify -t https://VOTRE-SITE-WEB:PORT -n 1000

(n'oubliez pas de faire un enregistrement dans votre fichier /etc/hosts sur votre client qui attaque.. pour qu'il trouve la correspondance entre l'URL indiquée et l'IP du serveur web !)
-t pour indiquer l'URL
-n pour indiquer le nombre de requête à lancer à l'URL

Vérifier si vous êtes banni :

fail2ban-client banned

Vous débannir :

fail2ban-client unban --all

Vous avez créé votre demande de signature de certificat SSL, et vous ne vous souvenez plus des informations que vous avez entrées lors de la création.. Pas de soucis :

openssl req -in votredemande.csr -noout -text | less

En plus de permettre l'automatisation horaire des tâches, Cron permet aussi d'exécutez des commandes ou des scripts au démarrage dxe votre serveur... Il existe, bien entendu, d'autres méthodes pour exécuter un script au démarrage, mais je trouve que cron est la façon la plus simple. (sinon, allez voir du côté de systemd...)

Pour cela, rien de plus simple.
Rendez-vous dans crontab et procédez comme suit :

crontab -e

Choisissez votre éditeur de texte (nano, vi)
Lorsque le fichier cron s'ouvre, ajouter la ligne suivante à la fin :

@reboot la commande ou le script que vous souhaitez voir executer au démarrage
@reboot une seconde commande...

Redémarrez Cron :

service cron restart

Voilà !
C'est terminé.

Nous connaissons tous les groupes de sécurité linux pour octroyer ou non un accès à certains dossiers à des utilisateurs.
Et pour certains, nous savons la galère que ça peut vite devenir lorsque le nombre d'utilisateurs croît ou que le nombre de divergences de permissions au sein d'un même répertoire grandit.

Comment faire, lorsque nos utilisateurs (connectés via un service FTP par exemple) sont chrootés dans leur répertoire personnel, pour leur donner accès au DocumentRoot d'un site web (par exemple) ?
A moins de chrooter tous les utilisateurs directement dans /var/www et de jouer des groupes pour autoriser ou non l'accès à certains dossiers du site en fonction des niveaux de privilèges des utilisateurs, on peut utiliser autre chose.

Il existe une solution simple à mettre en oeuvre : bindfs
Le paquet est présent dans le dépôt debian.

apt install bindfs -y

Je vous incite à consulter la documentation de bindfs, je ne montre ici qu'un exemple simple.

Bindfs va créer un miroir du dossier cible choisi, à l'emplacement de votre choix, et va vous permettre de créer des permissions différentes sur le dossier miroir de celles du dossier cible !
Ainsi, prenons l'exemple d'un développeur, à qui on va lier le DocumentRoot d'un site-à-la-con directement dans son dossier personnel, en lui octroyant les droits de lecture/écriture/exécution sur les fichiers à l'intérieur alors que l'on a rien touché au DocumentRoot, auquel il n'a normalement pas accès.

On commence par créer le dossier miroir :

mkdir /home/developpeur/site

On fait le lien ensuite :

bindfs -u developpeur -p 0700 /var/www/site-à-la-con /home/developpeur/site

Nous avons ici octroyé à l'utilisateur developpeur (-u developpeur) tous les droits - lecture/écriture/exécution, ce qui n'est pas forcément le mieux, c'est pour l'exemple !) - (-p 0700) sur le contenu du site-à-la-con qui va se retrouver lié dans le dossier site de son espace personnel.
Il pourra donc effectuer les modifications qu'il veut sur le contenu du dossier, instantanément mis-à-jour avec le dossier cible, sans sortir de son dossier utilisateur !

Même topic que sur Apache mais avec Nginx.

On peut faire une redirection générale des requêtes http vers https pour tous les sites.
(Sans changer les ports http et https dans un premier temps)
On crée un vhost avec ce qui suit :

server {
    listen 80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

Et on relance nginx

service nginx restart

------------------------------------------------------------------------------------------------------------------------------------------------------
Pour effectuer une redirection spécifique sur un vhost en particulier (classique HTTP vers HTTPS sans changement des ports 80 et 443), il faut soit créer un vhost,soit rajouter l'encart suivant dans le fichier du vhost concerné :

server {
    listen IP-SERVEUR:PORTHTTP;
    server_name NOM-DU-SITE;
    return 301 https://$host$request_uri;
}

Et on relance nginx

service nginx restart

Le problème se pose lorsque les ports 80 et 443 ont été changé :
(imaginons, le port http 80 -> 5501 et le port https 443 -> 5502)

server {
    listen IP-SERVEUR:5501;
    server_name NOM-DU-SITE;
    return 301 https://NOM-DU-SITE:5502;
}

Et on relance nginx

service nginx restart

Si vous avez décider d'utiliser d'autres ports que les ports 80 (http) et 443 (https) pour vos sites, alors les vous devez remplacer les ports d'écoute par défaut d'Apache, par ceux que vous allez utiliser.
Par défaut, Apache n'écoute que les ports 80 et 443.

Vous devez donc aller modifier le fichier /etc/apache2/ports.conf et remplacer les ports 80 et 443 par ceux de votre choix !

Puis relancer apache.

apachectl graceful

Facile !
Il y a tellement de façon de faire qu'on s'y perdrait...
- avec la directive Redirect
- avec un rewrite module
- avec une directive .htaccess
- avec un ProxyPass...

On va faire au plus simple avec la directive Redirect, (même si savoir faire un proxypass n'est pas superflu) !

Première chose, vous devez avoir un site en HTTPS fonctionnel ! (évidemment).
Donc vous devez déjà avoir un vhost SSL pour votre site, avec certificat signé par une autorité distante (ou autosigné si vous faîtes juste une maquette)
(rappel : le script global vous permet de le faire automatiquement !)

Pour mettre en place une redirection HTTP vers HTTPS, il faut donc créer un nouveau vhost (ou utiliser le vhost SSL de votre site et rajouter l'encart suivant avant ou après l'encart de votre site SSL).

<VirtualHost IP:PORTHTTP>
       ServerName NOM-DU-SITE
       Redirect permanent / https://NOM-DU-SITE:PORTHTTPS/
</VirtualHost>

A vous de remplacer l'IP:PORTHTTP selon votre configuration
Si vous joignez votre site sur le socket 192.168.1.200:80 (en http), alors mettez ça !
Si vous joignez votre site sur le socket 150.0.0.200:8081 (en http), alors mettez ça !
Ne laissez évidemment pas IP:PORTHTTP !

Autre point FONDAMENTAL dans la directive Redirect... Vous devez préciser le port HTTPS si vous utilisez un autre que le 443 !
ET SURTOUT, N'OUBLIEZ PAS LE / A LA FIN DU SOCKET !!! SINON CA NE FONCTIONNERA PAS !!

Voilà, c'est aussi simple.

Passons maintenant aux ports d'écoutes d'Apache.
Si vous avez décidé d'utiliser d'autres ports que les ports 80 (http) et 443 (https), alors les directives indiquées ci-dessus dans les vhosts ne suffiront pas, puisqu'Apache n'écoute que les ports 80 et 443 par défaut.
Si vous précisez 8081 ou autre, apache n'écoutera pas ce port à moins de faire la modification suivante :
Vous devez donc aller modifier le fichier /etc/apache2/ports.conf et remplacer les ports 80 et 443 par ceux de votre choix !
Puis relancer apache.

Là encore, pourquoi faire simple quand on peut faire compliqué :
comprenez aussi que le lien du dépôt ci-dessous sera probablement caduque quand vous lirez cet article..
Allez récupérer le lien le plus actuel sur la page suivante : https://dev.mysql.com/downloads/repo/apt/

apt install wget -y

wget https://repo.mysql.com/mysql-apt-config_0.8.24-1_all.deb

apt install ./mysql-apt-config_*_.deb -y

apt update

apt install mysql-server -y

systemctl enable mysql

mysql_secure_installation

Comme toujours avec Debian, pourquoi faire simple quand on peut faire compliqué :

apt install lsb-release apt-transport-https ca-certificates wget -y

wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | tee /etc/apt/sources.list.d/php.list

apt update

apt install apache2 libapache2-mod-php8.0 php8.0 -y

systemctl enable apache2

La Procédure d'installation se déroule en 2 parties :
- celle du plugin, pour le serveur GLPI
- celle des agents, installés sur les différents terminaux

Pour installer le plugin FusionInventory sur GLPI, vous devez déjà avoir installé GLPI (voir Installer GLPI).
Sur ce tuto, on va installer la dernière version de FusionInventory (la 10.0.3) qui n'est compatible qu'avec la version 10.0.3 de GLPI.
Autrement dit, vous devez VRAIMENT avoir suivi le tuto ci-dessus et avoir installé GLPI 10.0.3 (ce que le script vous propose d'ailleurs de faire, ainsi que de télécharger FusionInventory !).

-------------------------------------------------------------------------------------------
INSTALLATION DU PLUGIN FUSIONINVENTORY SUR GLPI

Evidemment, vous aurez pris soin de faire une sauvegarde de votre base SQL glpi avant !!

Si vous avez exécuté le script d'installation de GLPI avec FusionInventory, alors vous pouvez passer l'étape 1)

1) Téléchargez FusionInventory
Sur votre serveur Debian GLPI, passer en root

su - 

Puis tapez les commandes suivantes :

apt update

apt install unzip -y

Rendez-vous ensuite dans votre dossier glpi sur le serveur.
Nous avions choisi dans le tuto d'installation de glpi de placer tous les fichiers de glpi dans le vhost par défaut d'apache. Adaptez la suite en fonction de votre DocumentRoot glpi.

cd /var/www/html/plugins

wget https://github.com/fusioninventory/fusioninventory-for-glpi/releases/download/glpi10.0.3%2B1.0/fusioninventory-10.0.3+1.0.zip

unzip fusioninventory-10.0.3+1.0.zip

rm fusioninventory-10.0.3+1.0.zip

chown -R www-data /var/www/html/plugins

2) Faire l'installation du plugin via l'interface web de GLPI,
connectez-vous en tant qu'utilisateur "glpi"
Configuration, Plugins, descendez tout en bas et cochez "FusionInventory",
cliquez sur l'icône de dossier tout à droite (avec un +) pour installer.
Une fois installé, une notification vous propose d'activer. Faîtes-le.
4) Réglez le problème "Cron"
Sur le serveur GLPI, toujours en root :

echo '*/1 * * * * /usr/bin/php7.4 /var/www/html/glpi/front/cron.php &>/dev/null' >> /etc/crontab

service cron restart

Retourner sur l'interface web de glpi, Configuration, Actions automatiques, cherchez et cliquez sur "TaskScheduler" (en page 3), descendez en bas de la page et cliquez sur Exécuter.

Voilà, le problème Cron est résolu.

-------------------------------------------------------------------------------------------
INSTALLATION D'UN AGENT SUR UN TERMINAL WINDOWS

1) Télécharger l'agent :
https://github.com/fusioninventory/fusioninventory-agent/releases
(choisir l'installeur windows avec l'architecture correspondante)

2) Installer l'agent :
Pour l'installer, clic-droit sur le fichier télécharger, exécutez en tant qu'administrateur, 
Type d'installation "Complète" (et non par défaut)
Mode Serveurs : http://IP-SERVEUR-GLPI/plugins/fusioninventory
Ne pas cocher "installation rapide"
Passez SSL et Options Proxy pour cette première installation (à moins que vous ne l'ayez fait à côté).
Mode d'Exécution comme un Service Windows,
Laissez les Options du Serveur HTTP intégré par défaut
Options Diverses, cocher (en plus du raccourci) "Lancer un inventaire" et "Rechercher les machines virtuelles dans les dossiers personnels".
Laissez tout le reste par défaut.

Votre machine va remonter sur le GLPI après une petite minute.
On peut alors la voir dans Administration, FusionInventory, Agent.

Sur Debian, la configuration réseau se fait dans le fichier /etc/network/interfaces :
Il est faut être root (ou utiliser sudo si vous êtes autorisé)

su -

nano /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# exemple de configuration statique sur l'interface enp0s3 :
allow-hotplug enp0s3
iface enp0s3 inet static
address 192.168.1.25
netmask 255.255.255.0
gateway 192.168.1.254

# exemple de configuration dynamique sur l'interface eth0
allow-hotplug eth0
iface eth0 inet dhcp

La configuration des serveurs DNS peut-être faîte dans le fichier ci-dessus, mais se fait aussi dans un autre fichier : /etc/resolv.conf

nano /etc/resolv.conf

# pour CloudFlare :
nameserver 1.1.1.1
nameserver 1.0.0.1

 Mise-à-jour du mardi 23 janvier 2023 à 12h30
Amélioration du script d'installation de wordpress en https sur le vhost par défaut

Mise-à-jour du vendredi 13 janvier 2023 à 14h45
Amélioration du script vsftp

Mise-à-jour du jeudi 12 janvier 2023 à 23h40
Ajout de la configuration automatique de fail2ban, service par service, avec filtre DDoS pour apache

Mise-à-jour du jeudi 12 janvier 2023 à 12h15
nombreuses modifications dans les vhost apache et nginx, ajout des redirections de ports...

Mise-à-jour du jeudi 12 janvier 2023 à 10h
Ajout de la configuration automatique d'iptables

Mise-à-jour du vendredi 6 janvier 2023 à 19h
Ajout de la configuration automatique d'un site en https avec nginx

Mise-à-jour du lundi 21 novembre 2022 à 14h
modification des paramètres php pour le script glpi, ajout de fusioninventory 10.0.3

Mise-à-jour du mercredi 03 novembre 2022 à 14h35
Passage de GLPI à la version 10.0.4 et ajout de la possibilité d'installer directement sur le vhost par défaut

Mise-à-jour du mercredi 08 juin à 10h
Correction de 2 erreurs, partie SSH et Création d'utilisateur.
Ajout de AllowUsers dans SSH

Mise-à-jour du mardi 07 juin à 14h50
Ajout de la génération de clé privée et demande de signature dans le menu 7, isolé de la création d'un vhost

Mise-à-jour du lundi 06 juin à 00:20
Correction d'une condition dans l'ajout de droits à un utilisateur

Mise-à-jour du dimanche 05 juin à 12:05
Correction d'une erreur dans le menu [1], la variable du case n'était pas la bonne 

Mise-à-jour du samedi 04 juin à 14h :40
Le menu [4] permet d'envoyer la clef publique du serveur à un autre serveur via ssh-copy-id, avec choix du port du serveur distant, de l'utilisateur et du chemin de la clef publique à envoyer.

Le menu [8] comporte désormais la possibilité de (re)créer une partition unique (ext4 ou ntfs) sur un disque.
(je dois dire que manipuler fdisk pour créer une table ntfs lorsqu'une partition ext4 a déjà été créée a été un petit casse-tête dans le script).

Mise-à-jour du vendredi 03 juin à 22h30 :
Le menu [1] comporte désormais :
- un sous-menu pour configurer DNS, DHCP/static
Le menu [9] comporte désormais :
- l'installation d'un serveur FTP, avec/sans SSL et avec/sans connexion anonyme
- l'installation du serveur de mail Postfix
- l'installation de webmin
Le menu [4] comporte désormais
- un sous-menu pour la configuration du pare-feu, permettant de rajouter/enlever des règles, activer/désactiver le pare-feu mis en place

Le menu principal a aussi une entrée pour quitter le script

Mise-à-jour du vendredi 21 juillet à 09:30
Installation de webmin sur Debian 12

Mise-à-jour du samedi 29 juillet à 09:30
Passage à GLPI 10.0.9
Il semblerait qu'il y ait un problème avec un paquet mis à jour dans le dépôt debian depuis 2 jours.. des bugs d'affichage surviennent.. à surveiller.

VsFTPd :
Réparation de l'installation d'un serveur pour anonymes, avec autorisation ou non d'écrire dans le répertoire.

Mise-à-jour du vendredi 4 août à 09:30
Problème résolu pour GLPI.
Problème résolu pour VsFTPd et le fait de permettre aux anonymes d'écrire, créer des dossiers et uploader

Ce script vous permet de configurer :

[1] - Réseau"
[2] - Nom d'hôte, FQDN"
[3] - Mettre à jour le système"
[4] - Sécuriser le serveur"
[5] - Utilisateurs, droits et propriété"
[6] - Installer/Désinstaller un programme"
[7] - Site internet/intranet - SSL"
[8] - Partitionnement"
[9] - Programmes divers"

Je rappelle qu'il NE FAUT PAS exécuter les scripts en étant connecté au serveur depuis un client via SSH !!
Vous devez être DIRECTEMENT SUR LE SERVEUR pour exécuter ces scripts.
PAS DE CONNEXION SSH !!
Beaucoup d'erreurs vont se produire autrement !
Et vous DEVEZ ETRE ROOT !

Télécharger « global-deb13.sh »

su -

wget https://lstu.fr/global-deb13 -P /tmp

chmod 740 /tmp/global-deb13

cd /tmp

./global-deb13

Je rappelle qu'il NE FAUT PAS exécuter les scripts en étant connecté au serveur depuis un client via SSH !!
Vous devez être DIRECTEMENT SUR LE SERVEUR pour exécuter ces scripts.
PAS DE CONNEXION SSH !!
Beaucoup d'erreurs vont se produire autrement !
Et vous DEVEZ ETRE ROOT !

Ce script vous permet de créer un site wordpress sur un vhost perso ou d'utiliser le vhost par défaut d'Apache, d'activer SSL dessus (clé privée perso ou générée automatiquement, certificat auto-signé ou signé par une autorité distante, création d'une demande de signature par une autorité distante à partir d'une clé privée générée automatiquement ou importée manuellement, et intégration du certificat signé par une autorité distante à partir de la clé privée automatiquement ou importée manuellement).

Télécharger « wordpressSSL-DEB.sh »

apt install wget -y

wget http://ekladata.com/enwOBmUp6VddLpzK_KX76ZHVzN0/wordpressSSL-DEB.sh -P /tmp

chmod 740 /tmp/wordpressSSL-DEB.sh

./tmp/wordpressSSL-DEB.sh

Je rappelle qu'il NE FAUT PAS exécuter les scripts en étant connecté au serveur depuis un client via SSH !!
Vous devez être DIRECTEMENT SUR LE SERVEUR pour exécuter ces scripts.
PAS DE CONNEXION SSH !!
Beaucoup d'erreurs vont se produire autrement !
Et vous DEVEZ ETRE ROOT !

Ce script vous permet de créer un vhost ou d'utiliser le vhost par défaut d'Apache, d'activer SSL dessus (clé privée perso ou générée automatiquement, certificat auto-signé ou signé par une autorité distante, création d'une demande de signature par une autorité distante à partir d'une clé privée générée automatiquement ou importée manuellement, et intégration du certificat signé par une autorité distante à partir de la clé privée automatiquement ou importée manuellement).

Télécharger « vhostSSL-DEB.sh »

apt install wget -y

wget http://ekladata.com/-iOy3M_-RVKau9b0lbi9HoNBbY0/vhostSSL-DEB.sh -P /tmp

chmod 740 /tmp/vhostSSL-DEB.sh

./tmp/vhostSSL-DEB.sh

L'objectif est de configurer un site intranet (avec vhost) sur apache, en utilisant ssl.

SSL exige qu'un certificat soit délivré par une autorité de certification.
Puisqu'il s'agît d'un site intranet, accessible uniquement sur le réseau de l'entreprise, plutôt que de nous adresser à une autorité de certification sur internet, nous allons nous-même créer notre propre autorité de certification pour nous délivrer un certificat à nous-même !

Etape 1 : s'identifier en root, installer apache et openssl, activer ssl.

apt update && apt upgrade -y

apt install apache2 -y

systemctl start apache2 && systemctl enable apache2

a2enmod ssl

Etape 2 : Clé privée et demande de signature

mkdir /etc/apache2/ssl

cd /etc/apache2/ssl

1) Créer la clé privée pour apache : 

openssl genrsa -aes256 4096 > cleprivapache.key

2) Créer un certificat normal, qui servira de fichier de demande de signature à notre autorité : 

openssl req -new -key cleprivapache.key > demandesignature.csr

Nous allons à présent envoyer notre demandesignature.csr au serveur windows (ou à une authorité sur internet) afin d'obtenir un certificat signé !
Ici, je montre l'exemple d'un serveur windows qui va se charger de certifier.

Par exemple, depuis notre serveur Windows, nous allons récupérer la demandesignature.csr sur le serveur web :
dans un invité de commandes :

scp root@IP-SERVEUR-WEB:/etc/apache2/ssl/demandesignature.csr C:\chemin\ou\télécharger\votre\clef

Ensuite, sur le serveur windows,
Ouvrir PowerShell :
positionnez-vous dans l'emplacement de demandesignature.csr (il était dans E:\ chez nous)

cd E:\

certreq -attrib "CertificateTemplate:WebServer"

Une fenêtre s'ouvre, choisir demandesignature.csr (il est nécessaire de choisir "Tous les fichiers" en bas à droite pour voir le fichier s'afficher).
Puis, choisir un emplacement pour enregistrer le certificat (le nommer certifapache.crt).
Ensuite, renvoyez votre certifapache.crt sur votre serveur web :

scp E:\certifapache.crt root@IP-SERVEUR:/etc/apache2/ssl

Nous aurons besoin des 2 fichiers suivants pour notre vhost : 
- certifapache.crt (le certificat autosigné)
- cleprivapache.key (clé privée pour apache)

Dernière étape très importante, modifier les permissions de vos clefs et certificats :
(à n'effectuer qu'après avoir tout généré !)

chmod -R 600 /etc/apache2/ssl

Etape 4 : créer (ou copier s'il est donné) le dossier du site (jesuissuper)

mkdir /var/www/jesuissuper

vi /var/www/jesuissuper/index.html 

Etape 5 : le vhost.

cd /etc/apache2/sites-available/

cp default-ssl.conf defaul-ssl.conf.BAK

mv default-ssl.conf jesuissuper.conf

vi jesuissuper.conf

# On édite le fichier, avec au moins les informations (dé-commentées) suivantes :

<VirtualHost _default_:443>
     ServerName jesuissuper
     DocumentRoot /var/www/jesuissuper
     SSLEngine on
     SSLCertificateFile /etc/apache2/ssl/certifapache.crt
     SSLCertificateKeyFile /etc/apache2/ssl/clefprivapache.key
</VirtualHost>

On enregistre et on quitte

Etape 6 : activer la configuration du vhost

a2ensite jesuissuper.conf

(le nom des sites possibles s'affiche), tapper jesuissuper

Etape 7 : redémarrage d'apache2

apachectl graceful

(ou systemctl restart apache2)

Etape 8 : l'enregistrement DNS. 
Faîtes un enregistrement DNS sur votre hôte.

cas 1 : le PC est sur Linux :

vi /etc/hosts

IP-DU-SERVEUR-WEB      jesuissuper

cas 2 : le PC est sous windows.
modifier le fichier hosts (cliquez ici pour accéder à la procédure), y ajouter la même ligne qu'au-dessus

Etape 9 : Importer le certificat d'autorité sur votre navigateur Firefox : ca.crt sur votre PC 
(via scp ou winscp)
Lancez Firefox, paramètres, cherchez "certificats", affichez les certificats, onglet Autorités, Importer

L'objectif est de configurer un site intranet (avec vhost) sur apache, en utilisant ssl.

SSL exige qu'un certificat soit délivré par une autorité de certification.
Puisqu'il s'agît d'un site intranet, accessible uniquement sur le réseau de l'entreprise, plutôt que de nous adresser à une autorité de certification sur internet, nous allons nous-même créer notre propre autorité de certification pour nous délivrer un certificat à nous-même !

Etape 1 : s'identifier en root, installer apache et openssl, activer ssl.

apt update && apt upgrade -y

apt install apache2 -y

systemctl start apache2 && systemctl enable apache2

a2enmod ssl

Etape 2 : Créer notre propre Autorité de Certification (ca)

mkdir /etc/apache2/ssl

cd /etc/apache2/ssl 

openssl genrsa 4096 > ca.key

openssl req -new -x509 -days 365 -nodes -key ca.key > ca.crt

Etape 3 : Créer le certificat auto-signé
1) Créer la clé privée pour apache :
Il y a 2 façons de faire. Soit vous stipulez un mot de passe lors de la création (ce qui vous posera problème dans certaines applications. Soit vous n'en créez pas :
- Avec mot de passe :

openssl genrsa -aes256 4096 > cleprivapache.key

-(ou) Sans mot de passe (je vous suggère de mettre sans mot de passe pour la suite du tuto) :

openssl genrsa 4096 > cleprivapache.key

2) Créer un certificat normal, qui servira de fichier de demande de signature à notre autorité :

openssl req -new -key cleprivapache.key > demandesignature.csr

3) Faire signer notre demande de signature par notre propre autorité de certification (ca)

openssl x509 -req -in demandesignature.csr -out certifapache.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

Nous aurons besoin des 2 fichiers suivants pour notre vhost : 
- certifapache.crt (le certificat autosigné)
- cleprivapache.key (clé privée pour apache)

Dernière étape très importante, modifier les permissions de vos clefs et certificats :
(à n'effectuer qu'après avoir tout généré !)

chmod -R 600 /etc/apache2/ssl

Etape 4 : créer (ou copier s'il est donné) le dossier du site (jesuissuper)

mkdir /var/www/jesuissuper

vi /var/www/jesuissuper/index.html 

Etape 5 : le vhost.

cd /etc/apache2/sites-available/

cp default-ssl.conf defaul-ssl.conf.BAK

mv default-ssl.conf jesuissuper.conf

vi jesuissuper.conf

# On édite le fichier, avec au moins les informations (dé-commentées) suivantes :

<VirtualHost _default_:443>
     ServerName jesuissuper
     DocumentRoot /var/www/jesuissuper
     SSLEngine on
     SSLCertificateFile /etc/apache2/ssl/certifapache.crt
     SSLCertificateKeyFile /etc/apache2/ssl/cleprivapache.key
</VirtualHost>

On enregistre et on quitte

Etape 6 : activer la configuration du vhost

a2ensite jesuissuper.conf

(le nom des sites possibles s'affiche), tapper jesuissuper

Etape 7 : redémarrage d'apache2

apachectl graceful

(ou systemctl restart apache2)

Etape 8 : l'enregistrement DNS. 
Faîtes un enregistrement DNS sur votre hôte.

cas 1 : le PC est sur Linux :

vi /etc/hosts

IP-DU-SERVEUR-WEB      jesuissuper

cas 2 : le PC est sous windows.
modifier le fichier hosts (cliquez ici pour accéder à la procédure), y ajouter la même ligne qu'au-dessus
Etape 9 : Importer le certificat d'autorité sur votre navigateur Firefox : ca.crt sur votre PC 
(via scp ou winscp)
Lancez Firefox, paramètres, cherchez "certificats", affichez les certificats, onglet Autorités, Importer

Installer Shorewall

loguez-vous en root
apt install shorewall -y

Nous devons à présent configurer 3 fichiers :

1) d'abord les zones que l'on va utiliser dans les règles :
echo "net ipv4" >> /etc/shorewall/zones
echo "fw firewall" >> /etc/shorewall/zones

2) la carte réseau qui sera connectée à l'interface internet (évidemment, changez le nom de votre interface si ce n'est pas eth0)
echo "net eth0 detect" >> /etc/shorewall/interfaces

3) les règles de pare-feu des zones :
echo "fw net ACCEPT" >> /etc/shorewall/policy
echo "net all DROP info" >> /etc/shorewall/policy
echo "all all REJECT info" >> /etc/shorewall/policy

4) Configurer les règles de pare-feu :
echo "ACCEPT all fw tcp 80" >> /etc/shorewall/rules
echo "ACCEPT all fw tcp 443" >> /etc/shorewall/rules
echo "ACCEPT all fw tcp 22" >> /etc/shorewall/rules

5) Démarrer le pare-feu
systemctl start shorewall
systemctl enable shorewall

apt install mailutils

mail -s "Ceci est l'objet de l'email" email@destinaire.truc
cc : indiquez un mail de copier, puis tappez entrer
Inscrivez à présent le contenu de votre mail

Tappez CTRL+D pour envoyer votre message

Autre méthode pour envoyer tout le contenu d'un fichier texte :

mail -s "Ceci est l'objet de l'email" email@destinataire.truc << cat fichier.txt

Envoyer à plusieurs destinataires en même temps :

mail -s "Ceci est l'objet..." email@destinataire1.truc,email@destinataire2.truc

2 serveurs Debian.
A joue le rôle de client et adresse à B (le serveur de Forward Proxy) ses requêtes web et ftp, sur le port 8080

Configuration de A :

vi /etc/profile.d/proxy.sh
# inscrire et modifier
export http_proxy="http://IP-DE-B:8080/"
export https_proxy="https://IP-DE-B:8080/"
export ftp_proxy="ftp://IP-DE-B:8080:/"
export socks_proxy="https://IP-DE-B:8080/"
export no_proxy="127.0.0.1,localhost"

Pour configurer le gestionnaire de paquets APT afin qu'il passe lui aussi par le forward proxy :

vi /etc/apt/apt.conf.d/80proxy
# inscrire et modifier
Acquire::http::proxy "http://IP-DE-B:8080/";
Acquire::https:proxy "https://IP-DE-B:8080/";
Acquire::ftp::proxy "ftp://IP-DE-B:8080/";

Pour ne configurer que wget à faire des requêtes vers le Forward Proxy :

vi /etc/wgetrc
#inscrire et modifier le port au besoin
use_proxy=yes
http_proxy=127.0.0.1:8080
https_proxy=127.0.0.1:8080

Faîtes un reboot

Pour tester :

env | grep -i proxy

Pour la configuration de B, voir l'article concerné

Comment configurer un serveur Nginx (SRV-PROXY), afin qu'il agisse comme proxy pour des clients dans son LAN ?
Les clients vont adresser leurs requêtes http et https au proxy sur le port 8080, le proxy doit adresser toutes leurs requêtes en https

sur SRV-PROXY :

apt install nginx -y

systemctl start nginx

systemctl enable nginx

cd /etc/nginx/sites-enabled

cp default forward

vi forward
# copier la configuration suivante :
server {
        listen 8080;
        location / {
                 resolver 8.8.8.8;
                 proxy_pass https://$http_host$uri$is_args$args;
        }
}
# ESC : wq

systemctl restart nginx

Voilà, le forward proxy est en place

loguez-vous en root
Notre disque rajouté est sur /dev/sdb. C'est lui que nous voulons partitionner et formater

En cas de doute, regardez les disques présents sur votre système :

fdisk -l

créer un point de montage (genre /disksup)

mkdir /disksup

Lancez fdisk pour /dev/sdb :

fdisk /dev/sdb

Vous pouvez afficher les options possibles en appuyant sur m :

m

Pour formater votre volume, lancez les commandes suivantes :

n

p

laissez le reste par défaut
une fois les paramètres terminés, n'oubliez pas la touche 

w

pour formater en ext4

mkfs.ext4 /dev/sdb1

pour monter le disque :

mount /dev/sdb1 /disksup