cerhu > linux.debian.user.french

roger.tarani (16/01/2019, 11h00)
Bonjour

J'ai lu pas mal de docs sur le sujet. Et aussi sur les groups et users qui se trouvent toujours présents dans un système Linux.
Comme j'en découvre en permanence, je me dis que je suis loin d'avoir fait le tour !

Je voudrais configurer un serveur Debian absolument minimaliste :

Est-ce que je peux me limiter à configurer resolv.conf et interfaces et le vpn et le fw ? (En retirant tout ce qui est NM resolvconf ou autre)
je le crois mais il y a sans doute d'autres détails à considérer

Il y a aussi de nombreux groups et users "présents pour des raisons historiques" (adm, stadf, etc. )
Que suffit-il de conserver là et parmi d'autres éléments du système ?

Merci
Vincent (16/01/2019, 11h10)
Le 16/01/2019 à 09:50, roger.tarani a écrit :
> Bonjour
> J'ai lu pas mal de docs sur le sujet. Et aussi sur les groups et users qui se trouvent toujours présents dans un système Linux.
> Comme j'en découvre en permanence, je me dis que je suis loin d'avoir fait le tour !
>> Je voudrais configurer un serveur Debian absolument minimaliste :

> Est-ce que je peux me limiter à configurer resolv.conf et interfaces et le vpn et le fw ? (En retirant tout ce qui est NM resolvconf ou autre)
> je le crois mais il y a sans doute d'autres détails à considérer


Si tu installe une debian minimaliste, tu n'aura même pas NM et
resolvconf. ( tasksel avec juste SSH )

> Il y a aussi de nombreux groups et users "présents pour des raisons historiques" (adm, stadf, etc. )
> Que suffit-il de conserver là et parmi d'autres éléments du système ?


Ils ne sont pas génants.
Daniel Caillibaud (16/01/2019, 12h00)
Le 16/01/19 à 09:50, roger.tarani a écrit :
> Bonjour
> J'ai lu pas mal de docs sur le sujet. Et aussi sur les groups et users
> qui se trouvent toujours présents dans un système Linux. Comme j'en
> découvre en permanence, je me dis que je suis loin d'avoir fait le tour !
> Je voudrais configurer un serveur Debian absolument minimaliste :
> Est-ce que je peux me limiter à configurer resolv.conf et interfaceset
> le vpn et le fw ? (En retirant tout ce qui est NM resolvconf ou autre) je
> le crois mais il y a sans doute d'autres détails à considérer


Les détails à considérer sont ton usage, je comprend "minimaliste" comme
"seulement ce dont j'ai besoin" (certains considèreront que minimaliste =>
sans vpn ni fw).

> Il y a aussi de nombreux groups et users "présents pour des raisons
> historiques" (adm, stadf, etc. ) Que suffit-il de conserver là et parmi
> d'autres éléments du système ?


Je suggérerais :

1) À partir d'une install debian minimale (rien de coché à l'installation,
ou une image déjà prête), configurer apt pour ne pas installer les paquets
suggérés, voire recommandés, avec par ex
un /etc/apt/apt.conf.d/81no_reco_sugg qui contiendrait

// on veut pas des recommandés ou suggérés
APT::Install-Recommends "0";
APT::Install-Suggests "0";

2) lister les paquets installés (non auto)
aptitude search '~i !~M'
et virer tout ce dont on a pas l'usage.

Pour en savoir plus sur un paquet :

# sa description
aptitude show xx
# pourquoi il est installé
aptitude why xx

3) pour faire maigrir encore le tout, on peut recommencer l'exercice avec
tous les paquets (`aptitude search ~i`) pour voir si y'aurait pas des
dépendances inutiles installées.

Pour avoir la liste complète (ici avec les paquets auto, mettre ~i à la
place de ~M pour les avoir tous, auto ou pas)

aptitude search ~M -F %p|while read p; do echo -e "\n$p"; aptitude why $p; done

note: on peut bien sûr utiliser apt plutôt qu'aptitude, c'est juste que je
connais la syntaxe aptitude et mal celle d'apt
roger.tarani (17/01/2019, 22h20)
----- Original Message -----
> From: "Daniel Caillibaud" <ml>
> To: debian-user-french
> Sent: Wednesday, January 16, 2019 10:49:54 AM
> Subject: Re: Configuration réseau pour un serveur
> Le 16/01/19 à 09:50, roger.tarani a écrit :
> Les détails à considérer sont ton usage, je comprend "minimaliste"
> comme
> "seulement ce dont j'ai besoin" (certains considèreront que
> minimaliste =>
> sans vpn ni fw).

Oui, c'est vrai !
Je dirais minimaliste ET garantissant une sécurité contre les attaques.
Oui, dit comme ça, ça reste flou comme exigences. Voir plus bas.

[..]
> connais la syntaxe aptitude et mal celle d'apt
> --
> Daniel
> Lorsque vous posez un caméléon sur du tissu écossais,
> il vous fait un bras d'honneur.
> François Cavanna Ok. Merci.


J'ai quelques bases en sécurité mais là je dois admettre meslimites en pratique avec un serveur Debian.
Quel critères fixerais-tu pour garantir que la sécurité est assurée ?
Si par exemple je ferme tous les ports sauf celui écouté et contrôlé, je vire les éventuels paquets troués, j'impose l'utilisation d'un dispositif matériel pour faire de double authentification/2FA : en quoi ça me garantit qu'un attaquant ne pourra pas entrer dans le système ?
roger.tarani (17/01/2019, 22h30)
----- Original Message -----
> From: "Vincent" <vincent>
> To: debian-user-french
> Sent: Wednesday, January 16, 2019 10:02:45 AM
> Subject: Re: Configuration réseau pour un serveur


> Si tu installe une debian minimaliste, tu n'aura même pas NM et
> resolvconf. ( tasksel avec juste SSH ) Comme j'ai appris la configuration réseau à la main, et que ma vie est devenue compliquée avec les resolvconf et NetworkManager (qui font des trucs dans mon dos pas toujours reproductibles) et que cette config ne va pas changer, ça me semble convenir.


> > Il y a aussi de nombreux groups et users "présents pour des raisons
> > historiques" (adm, stadf, etc. )
> > Que suffit-il de conserver là et parmi d'autres élémentsdu système
> > ?

> Ils ne sont pas génants. Alors, laissons-leur la vie !


A tous :
En matière de sécurisation d'un serveur Debian, c'est quoi pour vous la doc de référence ?

Est-ce que [..] peut servir de référence ?
Sinon quel doc vous semble la plus solide ?

Merci
Étienne Mollier (17/01/2019, 23h00)
Bonsoir,

Roger Tarani, le 2019-01-17 :
> En matière de sécurisation d'un serveur Debian, c'est quoi
> pour vous la doc de référence ?
> Est-ce que
> [..]
> peut servir de référence ?
> Sinon quel doc vous semble la plus solide ?


Ce n'est pas forcément spécifique à Debian, mais la
documentation fournie par l'ANSSI est très complète et me semble
assez solide, même si elle commence à dater un petit peu :

[..]

Ce papier ci est spécifique à SSH (même si le plus sûr est de ne
pas le faire tourner du tout) :

[..]

Amicalement,
roger.tarani (17/01/2019, 23h20)
----- Original Message -----
[..]
> Ce papier ci est spécifique à SSH (même si le plus sûr est de ne
> pas le faire tourner du tout) :
> [..]
> Amicalement,
> --
> Étienne Mollier <etienne.mollier>


Ces docs sont bien faites.
J'ai lu en diagonale la doc NP_Linux_Configuration. On parle de bonnes pratiques qu'il faut...appliquer.
Je n'ai pas repéré d'outil de diagnostic et de configuration conforme à ces bonnes pratiques dans la doc (pour vérifier automatiquement que les paramètres vitaux sont bien configurés).
Est-ce que ça existe pour Linux ?

Admettons : si on configure correctement/de manière durcie un système Linux et ssh (plus 2FA pour chaque utilisateur), et toutes les reco de ces docs, c'est quoi les failles qui restent ?
Quelle garantie de sûreté de fonctionnement apporte aujourd'hui les composants logiciels de sécurité comme (open)ssh, utilisés à grande échelle, et dont le code a été examinéspar beaucoup de monde ?
J'ignore comment c'est codé. Après tout, si l'architecture est bien foutue et reste simple, ça peut garantir un composant sûr.
Question ouverte...
Pierre L. (19/01/2019, 00h30)
Peut-être ?
systemctl stop networking

Ok c'est nul... c'est w-end... ;)

Bon courage dans cette quête bien intéressante à suivre ;)

Le 17/01/2019 à 21:16, roger.tarani a écrit :
Étienne Mollier (19/01/2019, 01h40)
Roger Tarani, au 2019-01-17 :
> Je n'ai pas repéré d'outil de diagnostic et de configuration
> conforme à ces bonnes pratiques dans la doc (pour vérifier
> automatiquement que les paramètres vitaux sont bien
> configurés).
> Est-ce que ça existe pour Linux ?


Une recherche dans la base de paquets avec le mot clé
« pentest » m'a sorti une série de métapaquets forensics-*
semblant prometteurs :

$ apt show forensics-all

Peut-être que dans le lot vous trouverez votre bonheur ?

> Admettons : si on configure correctement/de manière durcie un
> système Linux et ssh (plus 2FA pour chaque utilisateur), et
> toutes les reco de ces docs, c'est quoi les failles qui
> restent ?


- Les erreurs humaines, suite à de l'ingénierie sociale par
exemple, du phishing, ou la bête fausse manipulation à base de
phrase de passe tapée dans un canal IRC à la place du champ
prévu dans le formulaire (vécu).

- Les portes dérobées, dans le matériel ou dans le système : il
y a eu des exemples de correctifs embarquant de telles
vulnérabilités dans du code Open Source, parfois ça finit par
se voir.

- Les failles 0day, encore inconnues du grand public mais
exploitées par des entités malveillantes.

- Les menaces physiques...

La liste n'est pas exhaustive, c'est juste ce qui me vient en
tête.

> Quelle garantie de sûreté de fonctionnement apporte
> aujourd'hui les composants logiciels de sécurité comme
> (open)ssh, utilisés à grande échelle, et dont le code a été
> examinés par beaucoup de monde ?
> J'ignore comment c'est codé. Après tout, si l'architecture est
> bien foutue et reste simple, ça peut garantir un composant
> sûr.
> Question ouverte...


Grâce aux bonnes âmes derrière Debian, et pour peu que les
entrées deb-src soient configurées dans le sources.list, pour
voir comment OpenSSH est codé, le plus rapide est de lancer un
petit :

$ apt source openssh # :^D

Quant aux garanties de sûreté, sur le papier, il n'y en a
aucune. Dans la pratique, les problèmes de sécurité dans SSH
agitent du monde. Le mieux que vous puissiez faire est de
rester à jour de vos paquets.

Amicalement,
Daniel Caillibaud (21/01/2019, 12h10)
Le 17/01/19 à 21:16, roger.tarani a écrit :
> J'ai quelques bases en sécurité mais là je dois admettre mes limites en
> pratique avec un serveur Debian. Quel critères fixerais-tu pour garantir
> que la sécurité est assurée ? Si par exemple je ferme tousles ports sauf
> celui écouté et contrôlé, je vire les éventuels paquets troués, j'impose
> l'utilisation d'un dispositif matériel pour faire de double
> authentification/2FA : en quoi ça me garantit qu'un attaquant ne pourra
> pas entrer dans le système ?


Rien ni personne ne pourra te le garantir, tu peux juste faire ce qu'il
faut pour abaisser la probabilité autant que possible.

Cf autres posts sur les bonnes pratiques.

Un truc simple est par ex d'interdire les connexions ssh par mot de passe
(seulement des clés, qui elles ont une passphrase), mais ça garantit rien,
ça empêche seulement ce type d'intrusion.
Discussions similaires
Configuration réseau ethernet et WIFI pour acces internet en réseau

Configuration pour serveur SQL

configuration 2carte reseau sur serveur nt

Configuration matériel pour un serveur web


Fuseau horaire GMT +2. Il est actuellement 22h32. | Privacy Policy