En cours de rédaction...

Je décline toute responsabilité !

• Je ne serais en aucun cas tenu pour responsable des dommages ou préjudices résultant d'une mauvaise configuration.
• Je n'y connais rien en sécurité informatique.
• Vous devrez comprendre et évaluer par vous même ce que vous faîtes. Sinon, il serait souhaitable de ne rien faire.

L'esprit de ce fil est de partager pour être plus efficace en général. Je ne le vois pas comme des émissions de requêtes.

Générer une image par compilation (c.f. Build system usage).

Le système de construction « OpenWrt Builroot » permet de générer des images de micrologiciels pour divers systèmes embarqués. Il est préconisé
d'installer OpenWrt sur du matériel supporté officiellement.

L'objectif étant de construire son image, les connaissances qu'il faudrait avoir, initialement, ou celles sollicitées, c'est tout de même assez conséquent.

Pour quoi générer son image ? Je souhaite élaborer plusieurs images pour pouvoir faire évoluer l'architecture de mon réseau local. Il me semble
que les FAIs n'offrent pas vraiment de véritables perspectives pour les particuliers souhaitant faire de l'auto-hébergement. Je suis sidéré par le niveau
de formation en sécurité informatique. On frôle bientôt le zéro absolu. C'est pas normal de se faire piéger par sa machine uniquement en ouvrant un
message électronique. C'est pas normal qu'une personne puisse commander à distance des milliers de machines compromises.

Pré-requis : l'environnement de compilation

Lisez la page relative à votre système d'exploitation (« Build system setup »).

• Modifier des fichiers
• Installation des paquets
• Vérouiller le compte root
• Ajouter sudo
• Ajouter un nouvel administrateur

Lisez la page Wiki « Build system usage ». Néanmoins, je vous suggère de ne pas suivre la section « Using official build config ».

À cette étape, vous avez téléchargé le dépôt Git de OpenWrt et avez validé les paramètres de configuration spécifiques à votre matériel (Target System, Subsystem, Target Profile). Il est vivement recommandé
d'installer LuCi (jetez un coup d’œil à la page Wiki « Quick image building guide »).

Modifier des fichiers du dépôt Git de OpenWrt

Le fichier de configuration est volumineux. Mais beaucoup de fonctionnalités ne serviront pas à construire l'image.

On peut astucieusement versionner le fichier ne contenant que les modifications de configuration afin de mieux percevoir comment l'image sera personnalisée.

# Write the changes to opendiff.config
./scripts/diffconfig.sh > opendiff.config

Le répertoire scripts (ci-dessus) du dépôt Git OpenWrt contient divers outils automatisant certains processus (e.g. récupérer des progiciels actualisés par le projet OpenWrt).

# Add the new opendiff.config to Git
git add opendiff.config
git commit -m 'OpenWrt v23.05.2: new opendiff.config (see also config.buildinfo)'

# Write changes to .config
cp opendiff.config .config
 
# Expand to full config
make defconfig

Ajouter un nouvel administrateur

Note : Les scripts placés dans 'files/etc/uci-default' ne seront exécutés qu'au premier amorçage du système ou après une mise à niveau via sysupgrade.
J'avais mal lu le Wiki et je croyais que ces scripts étaient exécutés à chaque redémarrage (c.f. uci-default).

Pour renforcer la sécurité d'un système Unix, il est conseillé de créer plusieurs utilisateurs disposant de droits d'administrations spécifiques. Pour ce faire, on désactive la connexion
du super utilisateur « root ». Puis, on utilise un logiciel nommé sudo pour répartir ou contrôler les privilèges d'administration entre utilisateurs. La configuration de 'sudo' dépasse
le cadre de cet article. Je vais reprendre le script trouvé sur le Wiki de OpenWrt.

En cours de rédaction...

CONFIG_BUSYBOX_CUSTOM=y
CONFIG_BUSYBOX_CONFIG_ADDGROUP=y
CONFIG_BUSYBOX_CONFIG_ADDUSER=y
CONFIG_BUSYBOX_CONFIG_FEATURE_ADDUSER_TO_GROUP=y
CONFIG_BUSYBOX_CONFIG_FEATURE_CHECK_NAMES=y
CONFIG_BUSYBOX_CONFIG_FIRST_SYSTEM_ID=100
CONFIG_BUSYBOX_CONFIG_LAST_ID=60000
CONFIG_BUSYBOX_CONFIG_LAST_SYSTEM_ID=999
CONFIG_BUSYBOX_CONFIG_USE_BB_CRYPT=y
CONFIG_BUSYBOX_CONFIG_USE_BB_PWD_GRP=y
CONFIG_BUSYBOX_CONFIG_USE_BB_SHADOW=y

mkdir -p files/etc/uci-defaults
cat << "EOF" > files/etc/uci-defaults/99-custom
USER_NAME="admin"
USER_SSHPUB="SSH_PUBLIC_KEY"
USER_SHELL="/bin/ash"
SUDO_USER="root"
SUDO_GROUP="sudo"
groupadd -r "${SUDO_GROUP}"
useradd -m -G "${SUDO_GROUP}" -s "${USER_SHELL}" "${USER_NAME}"
passwd -l "${SUDO_USER}"
cat << EOI > /etc/sudoers.d/00-custom
%${SUDO_GROUP} ALL=(ALL) ALL
EOI
USER_HOME="$(eval echo ~"${USER_NAME}")"
mkdir -p "${USER_HOME}"/.ssh
cat << EOI > "${USER_HOME}"/.ssh/authorized_keys
${USER_SSHPUB}
EOI
uci set dropbear.@dropbear[0].PasswordAuth="0"
uci set dropbear.@dropbear[0].RootPasswordAuth="0"
uci commit dropbear
/etc/init.d/dropbear restart
EOF

Présenter une démo.

Construire une image originale OpenWrt n'est peut-être pas aussi simple que je le pensais. Cela nécessite de considérer plusieurs aspects dans divers domaines liés étroitement (le matériel, les services, les processus de sécurité...).
Ce sont des facteurs variables mais potentiellement importants. Du coup, je me dis qu'il faudrait au préalable que j'acquiers un peu d'expérience pour former un tout-en-un (administration système et réseau). Mais cela devient compliqué.

Dans une configuration initiale, j'ai l'impression que l'intégration n'est pas point car on ne peut pas pousser le curseur jusqu'au bout. Les choses ne pas prises en compte. Prenons l'exemple suivant. La connexion sécurisée en HTTPS à
l'interface d'administration de la Livebox résidentielle souffre d'un déficit majeur. Dans la plupart des cas, on ne se retrouve pas avec une connexion sécurisée par défaut, mais avec une connexion en HTTP (le certificat étant bien présent
mais pas intégré dans l'environnement des utilisateurs et jamais mentionné dans la documentation en ligne). Comment l'intégrer ? Aucune idée. Cela pourrait laisser supposer que le réseau local est sécurisé ou pas spécialement dangereux.
Toutefois, il paraîtrait que beaucoup d'attaques informatiques soient menées dans le réseau local. Il est recommandé de segmenter les réseaux informatiques des entreprises. Mais les réseaux des particuliers ont une topologie réseau à plat.
Donc, deux poids, deux mesures. Je ne pense pas que ce soit complètement insensé de croire que le contrôle de l'administration de nos appareils puisse ainsi basculer vers les pirates informatiques (en supposant que des failles soient exploitées
sans contre-mesure).