# LPIC Séance 2
## hardening grub & filesystems
* **Expliquez en détails la chaine de boot d'un PC utilisant UEFI et linux**
1- Mise sous tension de l'ordinateur (Power On) :
2- POST (Power-On Self-Test) :
Le BIOS ou l'UEFI effectue un auto-test du matériel appelé POST pour vérifier que tous les composants matériels essentiels sont opérationnels.
3- Initialisation de l'UEFI
4- Chargement du chargeur d'amorçage (Boot Loader) :
Une fois que l'UEFI est initialisé, il recherche le chargeur d'amorçage (boot loader souvent GRUB) sur le disque dur ou le périphérique de stockage où votre système d'exploitation Linux est installé.
5- Chargement du noyau Linux :
Le chargeur d'amorçage charge le noyau Linux (vmlinuz) dans la mémoire vive (RAM) à partir du système de fichiers du disque dur. Le noyau Linux est le cœur du système d'exploitation, responsable de la gestion du matériel, de la mémoire, des processus et des pilotes de périphériques. Une fois chargé, le noyau est exécuté.
6- Initiation du processus d'initialisation (Init ou systemd) :
Une fois que le noyau est en cours d'exécution, il lance le premier processus, appelé init ou systemd. Init/systemd est le processus d'initialisation du système Linux et il est responsable de démarrer tous les autres processus et services nécessaires au fonctionnement du système.
7- Montage du système de fichiers racine :
Après l'initialisation, le système Linux monte le système de fichiers racine (root file system). Cela signifie que le système d'exploitation accède au disque dur et monte le système de fichiers principal, généralement stocké dans une partition.
8- Lancement de l'espace utilisateur :
Une fois que le système de fichiers racine est monté, le processus d'initialisation (init/systemd) lance les autres processus nécessaires à l'environnement utilisateur, ce qui peut inclure la gestion des sessions utilisateur, l'interface graphique (si installée), les services système, etc.
9- Arrivée à l'interface utilisateur (si configurée) :
Enfin, si on utilise une interface graphique comme GNOME, KDE, ou une autre, elle est chargée et affichée à l'écran, nous permettant d'interagir avec votre système.
* **Protégez grub2 en utilisant un mot de passe (hint : grub2-mkpasswd-pbkdf2 )**
Dans un premier temps, nous nous assurons de la bonne version du GRUB en version 2 :
Le GBRUB étant en version 2 nous pouvons désormais passer à la configuration du mot de passe avec la commande grub-mkpasswd-pbkdf2 comme suit :
Une fois le hash généré, nous le plaçons à la fin du fichier /etc/grub.d/40_custom :
Ensuite, on actualise la configuration du GRUB avec cette commande : grub-mkconfig -o /boot/grub/grub.cfg
Enfin, on redémarre la machine et le mot de passe GRUB doit être rentrée. Enfin, la machine démarre...
* **Est-ce suffisant de protéger grub avec un mot de passe ? Indiquez quel type d'attaque cela permets d'éviter**
La protection de GRUB avec un mot de passe est une mesure de sécurité utile, mais elle n'est pas suffisante pour garantir la sécurité globale d'un système. Elle permet principalement d'éviter une attaque physique ou locale.
* **Trouvez une méthode pour contourner le mot de passe grub et accéder au système de fichier**
Pour contourner le mot de passe grub, la solution est de monter le disque sur le point de montage /mnt. Cette technique permet ensuite d'accéder à l'ensemble de l'arborescence et des fichiers.
* **Listez les différentes méthodes pour chiffrer un disque dur.**
Il existe différentes méthodes pour chiffrer un disque dur :
1) LUKS (Linux Unified Key Setup) :
Il permet de chiffrer des partitions de disque dur, des disques entiers ou des périphériques de stockage amovibles.
2) dm-crypt :
Il est utilisé en conjonction avec LUKS pour chiffrer des dispositifs.
3) Cryptsetup :
C'est un outil de ligne de commande standard pour gérer le chiffrement sous Linux. Il prend en charge LUKS et dm-crypt.
4) EncFS :
C'est un système de chiffrement de fichiers au niveau du système de fichiers. Il est plus adapté au chiffrement de répertoires individuels plutôt qu'à des disques entiers.
5) VeraCrypt
VeraCrypt permet de créer des volumes chiffrés pour stocker des fichiers sensibles.
6) Chiffrement de l'OS :
Le chiffrement de l'OS garantit que toutes les données, y compris les fichiers système, sont chiffrées.
* **Quelle méthode vous semble la plus efficace ? Pourquoi ?**
La méthode la plus efficace consiste à utiliser le chiffrement de l'OS, garantissant ainsi que toutes les données sont sécurisées. De plus, il est possible d'appliquer le chiffrement aux conteneurs à l'aide de VeraCrypt, ce qui offre une protection supplémentaire en cas de compromission en empêchant l'accès aux données les plus sensibles.
* **Le chiffrement est-il suffisant ?**
Le chiffrement à lui seul ne constitue pas une sécurité complète, comme indiqué précédemment. En cas de compromission du système, par exemple, si un attaquant obtient un accès en ligne de commande, il pourrait potentiellement accéder aux fichiers de l'OS qui ont été chiffrés en utilisant la sixième méthode mentionnée.
## usbguard et services
* **En utilisant systemd, listez les services actifs sur la machine (hint : systemctl list-units) (second hint : pensez a regarder les options que vous pouvez passer à la commande)**
```
root@debian-LPIC:/sys/fs/cgroup# systemctl list-units -t service
UNIT LOAD ACTIVE SUB DESCRIPTION
accounts-daemon.service loaded active running Accounts Service
apparmor.service loaded active exited Load AppArmor profiles
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
bluetooth.service loaded active running Bluetooth service
colord.service loaded active running Manage, Install and Generate Color Profiles
console-setup.service loaded active exited Set console font and keymap
cron.service loaded active running Regular background program processing daemon
cups-browsed.service loaded active running Make remote CUPS printers available locally
cups.service loaded active running CUPS Scheduler
dbus.service loaded active running D-Bus System Message Bus
gdm.service loaded active running GNOME Display Manager
ifupdown-pre.service loaded active exited Helper to synchronize boot up for ifupdown
keyboard-setup.service loaded active exited Set the console keyboard layout
kmod-static-nodes.service loaded active exited Create List of Static Device Nodes
low-memory-monitor.service loaded active running Low Memory Monitor
ModemManager.service loaded active running Modem Manager
networking.service loaded active exited Raise network interfaces
NetworkManager-wait-online.service loaded active exited Network Manager Wait Online
NetworkManager.service loaded active running Network Manager
open-vm-tools.service loaded active running Service for virtual machines hosted on VMware
plymouth-quit-wait.service loaded active exited Hold until boot process finishes up
plymouth-read-write.service loaded active exited Tell Plymouth To Write Out Runtime Data
plymouth-start.service loaded active exited Show Plymouth Boot Screen
polkit.service loaded active running Authorization Manager
power-profiles-daemon.service loaded active running Power Profiles daemon
rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service
ssh.service loaded active running OpenBSD Secure Shell server
switcheroo-control.service loaded active running Switcheroo Control Proxy service
systemd-binfmt.service loaded active exited Set Up Additional Binary Formats
systemd-journal-flush.service loaded active exited Flush Journal to Persistent Storage
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running User Login Management
systemd-modules-load.service loaded active exited Load Kernel Modules
systemd-random-seed.service loaded active exited Load/Save Random Seed
systemd-remount-fs.service loaded active exited Remount Root and Kernel File Systems
systemd-sysctl.service loaded active exited Apply Kernel Variables
systemd-sysusers.service loaded active exited Create System Users
systemd-timesyncd.service loaded active running Network Time Synchronization
systemd-tmpfiles-setup-dev.service loaded active exited Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service loaded active exited Create Volatile Files and Directories
systemd-udev-trigger.service loaded active exited Coldplug All udev Devices
systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files
systemd-update-utmp.service loaded active exited Record System Boot/Shutdown in UTMP
systemd-user-sessions.service loaded active exited Permit User Sessions
udisks2.service loaded active running Disk Manager
upower.service loaded active running Daemon for power management
user-runtime-dir@1000.service loaded active exited User Runtime Directory /run/user/1000
user@1000.service loaded active running User Manager for UID 1000
vgauth.service loaded active running Authentication service for virtual machines hosted on VMware
wpa_supplicant.service loaded active running WPA supplicant
```
* **Arretez et desactivez un service inutile (par exemple, avahi) en utilisant systemctl**
```
root@debian-LPIC:/sys/fs/cgroup# systemctl stop avahi-daemon.service
Warning: Stopping avahi-daemon.service, but it can still be activated by:
avahi-daemon.socket
root@debian-LPIC:/sys/fs/cgroup# systemctl stop avahi-daemon.socket
root@debian-LPIC:/sys/fs/cgroup# systemctl disable avahi-daemon.service
Removed "/etc/systemd/system/dbus-org.freedesktop.Avahi.service".
Removed "/etc/systemd/system/multi-user.target.wants/avahi-daemon.service".
Removed "/etc/systemd/system/sockets.target.wants/avahi-daemon.socket".
```
* **USBGuard protège contre de quel type d'attaque ?**
USBGuard aide à protéger l'ordinateur contre les périphériques USB malveillants (alias BadUSB) en mettant en œuvre des capacités de base de liste blanche et de liste noire basées sur les attributs du périphérique.
* **Expliquez les limitations d'USBGuard.**
La limitation de USBGuard se situe au niveau de l'id du périphérique usb, il suffit pour un attanquant d'usurper l'id d'un périphérique usb autoriser pour se connecter à la mahcine et être reconnu.
* **Configurez usbguard pour fonctionner avec les périphériques usb que vous avez de branché**
```
allow id 1d6b:0002 serial "0000:02:02.0" name "EHCI Host Controller" hash "8G9+DxPfLbVnCuw59P+Fxfu6Yxy0AVsuFJ3qRPS0XNM=" parent-hash "Ps1yU1JiZl/dOj3LXAXp9uWQiNXeY3IT3NGW0E96O30=" with-interface 09:00:00 with-connect-type ""
allow id 1d6b:0001 serial "0000:02:00.0" name "UHCI Host Controller" hash "3QuFY0nRVqo+mgnIkqiXmmirRvxPDeP7P3mintodpys=" parent-hash "42PXRxhXx8adD0H10oXgQnna1ED6vikevkSl6cwgdOI=" with-interface 09:00:00 with-connect-type ""
allow id 0e0f:0003 serial "" name "VMware Virtual USB Mouse" hash "F4BFfAiFQzjQxG8oQHVYMFiDF2/zhhARDrRSIj6oij8=" parent-hash "3QuFY0nRVqo+mgnIkqiXmmirRvxPDeP7P3mintodpys=" via-port "2-1" with-interface 03:01:02 with-connect-type "unknown"
allow id 0e0f:0002 serial "" name "VMware Virtual USB Hub" hash "0cDIzeFX6eYg1fPydeh+aK2a/vRVjjj9bIasbHuN5sE=" parent-hash "3QuFY0nRVqo+mgnIkqiXmmirRvxPDeP7P3mintodpys=" via-port "2-2" with-interface 09:00:00 with-connect-type "unknown"
allow id 0e0f:0008 serial "000650268328" name "Virtual Bluetooth Adapter" hash "mx5CJc3v1b6cEpEwxLABwRw2mq2Ev8Ia8eatgaX9KgY=" parent-hash "0cDIzeFX6eYg1fPydeh+aK2a/vRVjjj9bIasbHuN5sE=" with-interface { e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 } with-connect-type "unknown"
```
Lors de l'installation USBGuard a automatiquement ajouter les périphérque ubs déjà brancher à la machine. En l'occurrence on retrouve les controlleur et adaptateur de VMWare comme la machine est virtualiser. Les pérophériques clavier et souris étant virtualiser par VMWare et ne sont pas configurer en "pass-through" se qui veux dire que peux importe la souris et le clavier que je brancherais sur le pc host l'id sera le même.
* **Testez en branchant un autre periphérique usb**
A cause des périphérique virtualiser le test ne peux pas avoir lieu, nous avons quand même essayer de comment la ligne "Virtual USB Mouse" sans réussite car le périphérique souris est passer par le "Virtual USB Hub". Nous n'avons pas commenter d'autre ligne au risque de perdre la main sur la machine.
## sysconf
* **Quelle est la différence entre sysctl et sysconf ?**
sysctl est une commande qui permet d'interagir avec le système de gestion des paramètres du noyau (kernel parameters), Il est principalement utilisé pour lire, configurer et ajuster les paramètres du noyau en temps réel, tels que les paramètres de réseau, les limites de ressources, les paramètres de sécurité, etc.
sysconf est un fichier de configuration qui contient des paramètres du noyau que vous souhaitez configurer de manière permanente et qui sont appliqués au démarrage du système.
* **Quel type d'information peut-on récupérer avec sysctl ? Lesquels vous semblent les plus importantes ?**
Le fichier de configuration sysctl.conf permet de modifier des options de configuration à chaque démarrage du système grâce au service systemd-sysctl.service du gestionnaire de système et de services systemd.
Ces options de configuration peuvent agir à tout niveau :
■ mémoire : configuration de la pagination, des allocateurs, des propriétés des mappings…
■ noyau : contrôle des caches, swap, scheduling…
■ processus : ressources allouées, restrictions d’exécution, cloisonnement…
■ réseau : tailles et caractéristiques des tampons, choix d’algorithmes…
■ systèmes de fichiers : setuid dumps, hard et soft links, quotas…
On peux retrouver l'ensemble des paramètres modifiable dans /proc/sys
```
./abi:
vsyscall32
./crypto:
./debug:
exception-trace kprobes-optimization
./dev:
./dev/cdrom:
./dev/hpet:
./dev/mac_hid:
./dev/parport:
./dev/parport/default:
./dev/scsi:
./dev/tty:
ldisc_autoload
./fs:
./fs/binfmt_misc:
./fs/epoll:
./fs/fanotify:
./fs/inotify:
./fs/mqueue:
./fs/quota:
./fs/verity:
./kernel:
acct hung_task_check_interval_secs ostype pty soft_watchdog
acpi_video_flags hung_task_panic overflowgid random split_lock_mitigate
apparmor_display_secid_mode hung_task_timeout_secs overflowuid randomize_va_space stack_tracer_enabled
arch hung_task_warnings panic real-root-dev sysctl_writes_strict
auto_msgmni io_delay_type panic_on_io_nmi sched_autogroup_enabled sysrq
bootloader_type kexec_load_disabled panic_on_oops sched_cfs_bandwidth_slice_us tainted
bootloader_version keys panic_on_rcu_stall sched_child_runs_first task_delayacct
bpf_stats_enabled kptr_restrict panic_on_unrecovered_nmi sched_deadline_period_max_us threads-max
cad_pid max_lock_depth panic_on_warn sched_deadline_period_min_us timer_migration
cap_last_cap max_rcu_stall_to_panic panic_print sched_energy_aware traceoff_on_warning
core_pattern modprobe perf_cpu_time_max_percent sched_rr_timeslice_ms tracepoint_printk
core_pipe_limit modules_disabled perf_event_max_contexts_per_stack sched_rt_period_us unknown_nmi_panic
core_uses_pid msgmax perf_event_max_sample_rate sched_rt_runtime_us unprivileged_bpf_disabled
ctrl-alt-del msgmnb perf_event_max_stack sched_schedstats unprivileged_userns_apparmor_policy
dmesg_restrict msgmni perf_event_mlock_kb seccomp unprivileged_userns_clone
domainname msg_next_id perf_event_paranoid sem usermodehelper
firmware_config ngroups_max pid_max sem_next_id version
ftrace_dump_on_oops nmi_watchdog poweroff_cmd shmall warn_limit
ftrace_enabled ns_last_pid print-fatal-signals shmmax watchdog
hardlockup_all_cpu_backtrace numa_balancing printk shmmni watchdog_cpumask
hardlockup_panic numa_balancing_promote_rate_limit_MBps printk_delay shm_next_id watchdog_thresh
hostname oops_all_cpu_backtrace printk_devkmsg shm_rmid_forced yama
hung_task_all_cpu_backtrace oops_limit printk_ratelimit softlockup_all_cpu_backtrace
hung_task_check_count osrelease printk_ratelimit_burst softlockup_panic
./kernel/firmware_config:
force_sysfs_fallback ignore_sysfs_fallback
./kernel/keys:
gc_delay maxbytes maxkeys persistent_keyring_expiry root_maxbytes root_maxkeys
./kernel/pty:
max nr reserve
./kernel/random:
boot_id entropy_avail poolsize urandom_min_reseed_secs uuid write_wakeup_threshold
./kernel/seccomp:
actions_avail actions_logged
./kernel/usermodehelper:
bset inheritable
./kernel/yama:
ptrace_scope
./net:
core ipv4 ipv6 mptcp netfilter unix
./net/core:
./net/ipv4/conf:
all default ens33 lo
./net/ipv6/conf:
all default ens33 lo
./net/ipv6/icmp:
echo_ignore_all echo_ignore_anycast echo_ignore_multicast ratelimit ratemask
./net/mptcp:
./net/netfilter:
./net/netfilter/nf_log:
./net/unix:
max_dgram_qlen
./user:
max_cgroup_namespaces max_fanotify_marks max_inotify_watches max_mnt_namespaces max_pid_namespaces max_user_namespaces
max_fanotify_groups max_inotify_instances max_ipc_namespaces max_net_namespaces max_time_namespaces max_uts_namespaces
./vm:
```
Les paramètres les plus importants semblent être liés au noyau (kernel).
Un guide des bonnes pratiques de l'ANSSI concernant la configuration du noyau linux à l'aide de sysctl est disponible a cette adresse : https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf
* **Modifiez un paramètre peu important (le nom de domaine par exemple)**
Pour modifier un paramètre j'utilise la commande "sysctl -w" :
```
user@debian-LPIC:/proc/sys$ sudo sysctl -w kernel.domainname=mondomain.bzh
kernel.domainname = mondomain.bzh
user@debian-LPIC:/proc/sys$ cat kernel/domainname
mondomain.bzh
```
* **Modifiez le même paramètre, mais assurez-vous que la modification soit persistente au reboot**
Pour rendre la modification persistante il est necesaire de modifier le fichier de configuration "/etc/sysctl.d/99-sysctl.conf" :
```
user@debian-LPIC:/proc/sys$ sudo nano /etc/sysctl.d/99-sysctl.conf
```
Et d'entrer notre modification :
```
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
kernel.domainname = mondomain.bzh
```
* **C'est quoi l'ASLR ? C'est pour se protéger de quel type d'attaque ?**
L'ASLR (Address Space Layout Randomization) est un mécanisme permettant de limiter les effets et de complexifier l'exploitation des attaques de type buffer overflow (dépassement de tampon). L'objectif est ici de placer la zone de données dans la mémoire virtuelle de façon aléatoire, changeant ainsi sa position à chaque exécution.
* **Verifiez, en utilisant sysctl, que l'ASLR est bien actif sur votre machine**
Pour activer l'ASLR, on peut utiliser la clé kernel.randomize_va_space et y positionner la valeur 2, qui permet de positionner de façon aléatoire (aka randomiser :/ ) la stack (pile), les pages CDSO (virtual dynamic shared object), la mémoire partagée et le segment de données (data segment), qui contient les variables globales et statiques initialisées par le programme. Positionner la valeur 1 aura le même effet, sauf pour le segment de données. La valeur 0 désactive l'ASLR. Dans notre cas la valeur est à 2 l'ASLR est donc activé.
```
user@debian-LPIC:/proc/sys$ cat kernel/randomize_va_space
2
```
* **Que fait la commande "ldd" ?**
ldd affiche la liste des bibliothèques partagées nécessaires pour chaque programme ou bibliothèque passés sur la ligne de commande.
* **Utilisez cette commande pour illustrer le fonctionnement de l'ASLR**
Pour illustrer l'ASLR nous pouvons utilisez la commande ldd, Cette commande affichera les bibliothèques partagées requises par le binaire ainsi que les adresses mémoire de ces bibliothèques. Si l'ASLR est activé, les adresses mémoire affichées changeront à chaque exécution de la commande, démontrant ainsi la variation aléatoire des emplacements de la mémoire. Si l'ASLR est désactivé, nous pourrons observer que les adresses mémoire restent statiques.
```
user@debian-LPIC:/proc/sys$ ldd /usr/lib/p7zip/7z.so
linux-vdso.so.1 (0x00007ffceff25000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcbbf4bb000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcbbf200000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcbbf49b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcbbf01f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcbbef40000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcbbf6c3000)
user@debian-LPIC:/proc/sys$ ldd /usr/lib/p7zip/7z.so
linux-vdso.so.1 (0x00007ffe17567000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcb77b1b000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcb77800000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcb77afb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb7761f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcb77a1c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcb77d23000)
user@debian-LPIC:/proc/sys$ ldd /usr/lib/p7zip/7z.so
linux-vdso.so.1 (0x00007fff66360000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f227ed48000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f227ea00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f227ed28000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f227e81f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f227ec49000)
/lib64/ld-linux-x86-64.so.2 (0x00007f227ef50000)
```
Nous pouvons constatez que les adresses mémoire des bibliothèques partagées requises par le binaire change à chaque execution de la commande, ce qui veux dire que l'ASLR est bien activer.
* **Désactivez l'ASLR. Voyez-vous une différence avec le retour de la commande ldd ? Si oui, expliquez là**
```
user@debian-LPIC:/proc/sys$ sudo sysctl -w kernel.randomize_va_space=0
kernel.randomize_va_space = 0
user@debian-LPIC:/proc/sys$ ldd /usr/lib/p7zip/7z.so
linux-vdso.so.1 (0x00007ffff7fc9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffff7dbd000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffff7a00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffff7d9d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff781f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffff7cbe000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fcb000)
user@debian-LPIC:/proc/sys$ ldd /usr/lib/p7zip/7z.so
linux-vdso.so.1 (0x00007ffff7fc9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffff7dbd000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffff7a00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffff7d9d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff781f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffff7cbe000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fcb000)
user@debian-LPIC:/proc/sys$ ldd /usr/lib/p7zip/7z.so
linux-vdso.so.1 (0x00007ffff7fc9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffff7dbd000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffff7a00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffff7d9d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff781f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffff7cbe000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fcb000)
```
Comme nous pouvons le constater après désactivation de l'ASLR les adresses mémoire des bibliothèques partagées requises par le binaire ne changent pas, ce qui confirme la désactivation de l'ASLR.
* **Ecrivez un petit programme en C affichant l'adresse d'une fonction (hint : pointeur de fonction)**
```
#include <stdio.h>
// Fonction de démonstration
void fonctionDemo() {
// Le corps de la fonction de démonstration
}
int main() {
// Déclaration d'un pointeur de fonction
void (*ptrFonction)() = &fonctionDemo;
// Affichage de l'adresse de la fonction à l'aide du pointeur
printf("L'adresse de la fonctionDemo est : %p\n", ptrFonction);
return 0;
}
```
* **Testez le programme. Que pensez-vous du résultat ? S'il y a un problème, comment le corriger ?**
```
user@debian-LPIC:~$ gcc pointeur_fonction.c -o pointeur_fonction
```
```
user@debian-LPIC:~$ ./pointeur_fonction
L'adresse de la fonctionDemo est : 0x555555555139
user@debian-LPIC:~$ ./pointeur_fonction
L'adresse de la fonctionDemo est : 0x555555555139
user@debian-LPIC:~$ ./pointeur_fonction
L'adresse de la fonctionDemo est : 0x555555555139
```
Lors de l'exécution du programme on peux se rendre compte que l'adresse de la fonction affichée par notre programme est constamment la même. Pour résoudre se problème il suffit de réactiver l'ASLR.
```
ser@debian-LPIC:~$ sudo sysctl -w kernel.randomize_va_space=2
kernel.randomize_va_space = 2
user@debian-LPIC:~$ ./pointeur_fonction
L'adresse de la fonctionDemo est : 0x564c1776b139
user@debian-LPIC:~$ ./pointeur_fonction
L'adresse de la fonctionDemo est : 0x557c559a4139
user@debian-LPIC:~$ ./pointeur_fonction
L'adresse de la fonctionDemo est : 0x558fff447139
```
* **C'est quoi le NX bit ? W^X ?**
Le NX Bit, pour No eXecute, est une technique de protection d'espace exécutable utilisée dans les processeurs pour dissocier les zones de mémoire contenant des instructions, donc exécutables, des zones contenant des données.
W^X (prononcé "W xor X") est le nom d'une fonctionnalité dédiée à la sécurité informatique. cette fonctionnalité permet à une page d'être accessible soit en écriture soit en exécution, mais en aucun cas les deux à la fois.
* **Quel type d'attaque cela permet de se protéger ?**
Le NX bit (Non-eXecute) et la politique W^X (Write XOR Execute) aident à protéger les systèmes informatiques contre plusieurs types d'attaques malveillantes, en particulier les attaques d'exécution de code, telles que :
Attaques par débordement de tampon : Dans ce type d'attaque, un attaquant exploite une vulnérabilité dans un programme qui lui permet d'écrire un code malveillant dans une zone de la mémoire et de forcer le programme à exécuter ce code, généralement en dépassant les limites de mémoire allouée.
Injection de code malveillant : Cette attaque consiste à injecter du code malveillant dans un programme en cours d'exécution, souvent en exploitant des vulnérabilités de type script ou des erreurs de programmation. Le code malveillant peut être injecté dans la mémoire et exécuté pour compromettre la sécurité du système.
Vers et logiciels malveillants : Ces programmes malveillants peuvent se propager en exploitant des failles de sécurité et en injectant du code malveillant dans des zones de mémoire vulnérables. L'activation du NX bit et de la politique W^X peut aider à prévenir l'exécution de ces codes malveillants.
* **En utilisant dmesg, vérifiez que votre machine est protégée**
```
user@debian-LPIC:~$ sudo dmesg | grep NX
[ 0.000000] NX (Execute Disable) protection: active
[ 3.133653] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
user@debian-LPIC:~$ sudo dmesg | grep "W^X"
user@debian-LPIC:~$
```
Dans mon cas, je peux constater qu'a l'aide de la commande dmesg que la protection NX est active.
* **Peut-on utiliser PaX et grsecurity actuellement ?**
Selon cette article de 2019 de l'ANSSI : https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf
"Le projet grsecurity ainsi que PaX qu’il intègre a été pendant de nombreuses années la référence
en termes de durcissement noyau. Ce patch extrêmement intrusif et complexe n’a jamais été considéré pour inclusion dans le noyau upstream et n’est maintenant plus disponible publiquement"
## capabilities & chroot
* **C'est quoi une capacité ? (capability)**
Sous Linux, une capacité (capability) est un mécanisme de sécurité permettant de déléguer des privilèges spécifiques à un processus plutôt que de lui accorder un accès complet en tant que superutilisateur. Cela permet de limiter les risques de sécurité en octroyant uniquement les permissions nécessaires à une application ou un processus, sans lui donner un accès complet au système. Les capacités sont utilisées pour réduire les risques potentiels en isolant davantage les privilèges au sein du système d'exploitation.
* **Le boulot n'est-il pas déjà fait par suid ? Expliquez pourquoi**
SUID augmente les privilèges d'un processus, mais il le fait de manière globale, ce qui peut être risqué. Les capacités, en revanche, permettent une gestion plus fine des privilèges en attribuant des autorisations spécifiques aux processus, ce qui est plus sûr et adapté à des scénarios où une granularité de contrôle est nécessaire.
* **Listez les différentes capabilities de disponible et groupez les**
- Gestion de processus et du système de fichiers :
CAP_CHOWN : Modifier le propriétaire d'un fichier
CAP_DAC_OVERRIDE : Contourner les contrôles d'accès au fichier
CAP_FOWNER : Modifier le propriétaire d'un fichier système
CAP_FSETID : Modifier les ID de fichier
CAP_KILL : Envoyer des signaux aux processus
CAP_SETGID : Modifier le groupe effectif ID
CAP_SETUID : Modifier l'ID de l'utilisateur effectif
- Gestion des privilèges :
CAP_SETPCAP : Modifier les capacités du processus
- Gestion des processus :
CAP_SYS_CHROOT : Changer la racine du système de fichiers
CAP_SYS_PTRACE : Tracer des processus
CAP_SYS_PACCT : Activer / désactiver la comptabilité du processus
CAP_SYS_ADMIN : Exécuter diverses opérations d'administration du système
- Gestion de la configuration réseau :
CAP_NET_ADMIN : Effectuer diverses opérations d'administration réseau
- Contrôle de la surveillance et des journaux :
CAP_AUDIT_CONTROL : Activer / désactiver les fonctionnalités d'audit
CAP_AUDIT_WRITE : Écrire dans les journaux d'audit
CAP_SYSLOG : Effectuer diverses opérations sur le journal système
* **Récupérez des capabilities de différents binaires de votre système, dans "/usr/bin" et dans "/sbin/"**
* **En utilisant capsh, lancez un processus nécessitant des droits root ordinairement et définissez les capabilities necessaires pour l'execution du processus ( hint : ptrace ou nc)**
Nous allons dans un premier temps copier le binaire "nc" dans le home de l'utilisateur luc pour réaliser les manipulations.
la commande setcap dans ce cas permet d'attribuer au binaire temporaire nc la capacité CAP_NET_BIND_SERVICE, qui est nécessaire pour lier des sockets à des ports réseau inférieurs à 1024.
La dernière commande capsh permet de lancer nc avec des capabilities spécifiques.
Ces commandes permettent de lancer le processus nc avec les capacités spécifiques nécessaires pour écouter sur le port 80 sans nécessiter des privilèges root complets.
* **À quoi sert le chroot ?**
Le chroot est utilisé pour créer un environnement isolé où un processus s'exécute avec un nouveau répertoire racine, restreignant ainsi son accès au système de fichiers à l'intérieur de ce répertoire. Cela renforce la sécurité en empêchant l'accès non autorisé à d'autres parties du système, facilite le développement et les tests, et permet de créer des environnements applicatifs autonomes.
* **Créez un dossier avec le minimum pour lancer un shell bash**
Premièrement j'ai créé un dossier minimal_chroot :
```
user@debian-LPIC:~$ mkdir minimal_chroot
```
Ensuite j'ai créé un dossier /bin pour y copier /bin/bash :
```
user@debian-LPIC:~$ sudo mkdir minimal_chroot/bin
user@debian-LPIC:~$ sudo cp /bin/bash minimal_chroot/bin/
```
Dans un second temps j'ai lister les bibliothèques requise par /bin/bash et les est ajoutées sous la même arborésence dans mon dossier :
```
user@debian-LPIC:~$ ldd /bin/bash
linux-vdso.so.1 (0x00007ffd2b111000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fb62bb73000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb62b992000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb62bcfa000)
user@debian-LPIC:~$ sudo mkdir minimal_chroot/lib/
user@debian-LPIC:~$ sudo mkdir minimal_chroot/lib/x86_64-linux-gnu/
user@debian-LPIC:~$ sudo cp /lib/x86_64-linux-gnu/libtinfo.so.6 minimal_chroot/lib/x86_64-linux-gnu/
user@debian-LPIC:~$ sudo cp /lib/x86_64-linux-gnu/libc.so.6 minimal_chroot/lib/x86_64-linux-gnu/
user@debian-LPIC:~$ sudo mkdir minimal_chroot/lib64
user@debian-LPIC:~$ sudo cp /lib64/ld-linux-x86-64.so.2 minimal_chroot/lib64/
```
Pour finir, j'ai executé la commande suivante :
```
user@debian-LPIC:~$ sudo chroot minimal_chroot/
bash-5.2#
```
Cette commande m'a créé un environnement isolé avec le minimum pour lancer un shell bash
## Mini rapport
Sujet : Alpine vs Gentoo hardened
### 1. Présentation rapide du contexte
Deux distributions populaires pour la sécurité des systèmes Linux, Alpine Linux et Gentoo Hardened, se sont démarquées en adoptant des approches distinctes pour renforcer la sécurité de leurs systèmes. Dans ce rapport, nous allons comparer ces deux distributions en mettant en évidence leurs caractéristiques de sécurité respectives.
### 2. Les éléments techniques permettant de répondre à la question posée
#### 2.1. Alpine Linux :
Alpine Linux se distingue par sa philosophie de légèreté et de simplicité, ce qui en fait un choix attrayant pour les scénarios où la sécurité est primordiale et rapide à mettre en place. Voici une expansion des éléments clés de sa stratégie de sécurité :
**Taille minimale de l'image** : Alpine se caractérise par des images système extrêmement légères. Cette approche réduit la surface d'attaque, car il y a moins de code et de processus en cours d'exécution, ce qui diminue la probabilité de vulnérabilités. La minimisation de la taille de l'image facilite également les mises à jour et les patchs, ce qui est crucial pour maintenir la sécurité du système.
**Paquets compilés en statique** : Alpine compile la plupart de ses paquets en utilisant la compilation statique. Cela signifie que chaque paquet contient toutes les bibliothèques nécessaires, éliminant ainsi les dépendances externes. Cette approche réduit les risques liés aux vulnérabilités dans des bibliothèques tierces, car les paquets sont auto-suffisants. De plus, les mises à jour de bibliothèques système n'impactent pas les applications, ce qui simplifie la gestion de la sécurité.
**Paquets signés** : Alpine signe numériquement ses paquets. Cela garantit l'intégrité des paquets téléchargés et empêche les attaquants de remplacer des paquets légitimes par des versions malveillantes. Les mises à jour sont également vérifiées à l'aide de clés GPG, garantissant que seules les mises à jour authentiques sont installées.
Alpine Linux est couramment utilisé dans les environnements de conteneurs, où la légèreté, la simplicité et la sécurité sont des atouts essentiels. Sa philosophie de minimisation de la surface d'attaque en fait une distribution idéale pour des cas d'utilisation tels que les conteneurs Docker, où chaque octet compte en termes de sécurité.
#### 2.2. Gentoo Hardened :
Gentoo Hardened offre une approche de sécurité plus flexible et personnalisable pour les utilisateurs qui souhaitent un contrôle avancé sur la sécurité de leur système. Voici une expansion des éléments clés de sa stratégie de sécurité :
**Paquets personnalisables** : Une caractéristique distinctive de Gentoo est la possibilité de personnaliser chaque paquet selon les besoins de l'utilisateur. Cela signifie que les utilisateurs peuvent activer ou désactiver des options de compilation spécifiques pour renforcer la sécurité. Par exemple, ils peuvent activer des fonctionnalités de sécurité telles que le Stack Smashing Protector (SSP) pour protéger contre les attaques de débordement de tampon.
Voici le processus de fusion d'un paquet avec Gentoo :
**Stack Smashing Protector (SSP)** : SSP est activé par défaut dans Gentoo Hardened. Cette technique ajoute des protections supplémentaires contre les attaques de débordement de tampon en détectant les tentatives d'écrasement de la pile et en arrêtant l'exécution du programme si une telle tentative est détectée. Cela rend les attaques de débordement de tampon plus difficiles à réussir.
**Position Independent Executables (PIE)** : Gentoo encourage l'utilisation de binaires compilés avec l'option Position Independent Executables (PIE). Cette technique rend plus difficile l'exploitation de vulnérabilités de type "Return-to-libc" en rendant les adresses de mémoire plus imprévisibles. Elle ajoute une couche de sécurité supplémentaire en rendant les attaques par débordement de tampon plus complexes.
Gentoo Hardened offre une personnalisation approfondie des options de sécurité, ce qui en fait un excellent choix pour les utilisateurs expérimentés qui ont des exigences de sécurité spécifiques ou qui souhaitent mettre en place des politiques de sécurité avancées. Cependant, cette personnalisation peut également rendre la gestion plus complexe et nécessiter une expertise plus approfondie en matière de sécurité.
On peut référencer les points communs et les différences sous avec ce tableau :
| Caractéristiques de sécurité | Alpine Linux | Gentoo Hardened |
|---------------------------------|---------------------------------------|-----------------------------------|
| Légèreté | Très léger, images système minimales | Personnalisable mais plus lourd |
| Compilation statique | Oui, pour la plupart des paquets | En fonction des choix de l'utilisateur |
| Signature de paquets | Oui, avec vérification par clés GPG | Pas spécifiquement, dépend des sources |
| Personnalisation | Limitée, favorise la simplicité | Très flexible, permet une personnalisation avancée |
| Stack Smashing Protector (SSP) | Non activé par défaut | Activé par défaut |
| Position Independent Executables (PIE) | Peu couramment activé | Encourage l'utilisation de PIE |
### 3. Conclusion
Alpine Linux et Gentoo Hardened sont deux distributions Linux populaires, chacune offrant une approche unique en matière de sécurité. Le choix entre les deux dépendra des besoins spécifiques de sécurité et des préférences de l'utilisateur.
Alpine Linux se démarque par sa simplicité et sa légèreté, ce qui en fait un excellent choix pour les conteneurs et les environnements où la sécurité est essentielle. La minimisation de la surface d'attaque et l'approche de la compilation statique contribuent à renforcer la sécurité.
Gentoo Hardened, en revanche, offre une personnalisation avancée pour les utilisateurs souhaitant un contrôle total sur la sécurité de leur système. Les options de sécurité telles que SSP et PIE renforcent la sécurité en profondeur.
En fin de compte, le choix entre Alpine et Gentoo Hardened dépendra des besoins spécifiques du projet, de la préférence de l'utilisateur en matière de personnalisation et de la compréhension des implications de sécurité de chaque distribution. Il est également important de noter que d'autres distributions Linux offrent également des fonctionnalités de sécurité robustes, et la recherche approfondie est essentielle pour choisir la meilleure distribution en fonction des exigences de sécurité.
Les systèmes d'exploitation Alpine et Gentoo Hardened sont couramment utilisés dans des contextes client. Une question légitime serait alors de se demander quelles solutions sont appropriées pour assurer une première couche de sécurité pour les systèmes d'exploitation orientés serveur. Dans cette optique, il serait intéressant d'examiner CentOS et SUSE Linux Enterprise Server (SLES), deux systèmes d'exploitation largement utilisés en milieu professionnel, en comparant leurs avantages et leurs différences en termes de mesures de sécurité.
Sign in with Wallet
Connect another wallet