Reboot électrique distant

2018-05-07 Par sujet kaliderus 
Bonsoir,
Bonjour,

Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Avec ceci par exemple ?
https://support.usr.com/products/remotemanagement/console-server-product.asp?sku=USR4204#

Mais avec ce truc (je ne sais même pas comment l'appeler en Français),
est-ce que je vais pouvoir établir une communication analogique (comme
dans l'ancien temps) avec le modem qui lui sera collé au derrière,
sachant que je suis avec Free en dégroupé.

Ou un switch administrable, et dans ce cas, je suis tributaire de la
présence d'un réseau ip bien accessible et adéquatement configuré.

Je me tâte, si vous avez d'autres
pistes/conseils/tuyaux/infos/idées/ou/que/sais/je j'en serai
heureux...

Merci.

Ajout d'une route sur une interface virtuelle

2018-05-07 Par sujet Frederic Zulian 
​bonjour,

J'ai une Freebox en mode routeur avec un PC portable faisant office de
serveur Web.​

Je souhaite transformer mon pc portable en routeur et mettre la Freebox en
bridge.

Est-il techniquement possible de passer ma Freebox en bridge puis de
transformer le PC portable en routeur
en utilisant sa seule interface physique.

Dans ce cas il y aurait sur la même interface physique trois interfaces
virtuelles  :

- eth0 ou enp2s0  avec mon ip  publique

- eth0:1 192.168.1.x

- tunl0 en 44.151.31.x

Les seuls routeurs que j'ai pu monter sur la base de PC  disposaient d'une
carte réseau par interface
(une pour l'ip publique, une pour un réseau privé, une troisième carte pour
un deuxième réseau privé.

D'ou la question  est-ce que le routage peut-être fonctionnel avec une
seule carte réseau ?


Frédéric ZULIAN

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Pascal Hambourg 

Le 07/05/2018 à 17:39, Olivier a écrit :

Le 7 mai 2018 à 16:00, hamster  a écrit :


Pour les oublis de phrase de passe par contre, y'a pas de solution
miracle : il faut s'en rappeller.


Il y a d'autres solutions.


Faut-il saisir une  phrase de passe quand un système est chiffré ?


Pas forcément.
D'une part, il n'y a pas forcément de phrase de passe. Par exemple 
dm-crypt, l'infrastructure de chiffrement sur laquelle se base LUKS, 
n'en utilise pas. Si on utilise dm-crypt sans LUKS, il faut fournir la 
clé de chiffrement (une des rôles de LUKS consiste à chiffrer et 
déchiffrer la clé de chiffrement grâce à une phrase de passe).
D'autre part, il ne faut pas forcément la /saisir/. On peut la /fournir/ 
par tout moyen.



Si oui, à quel moment (au boot, uniquement si on boote avec une clé, ...) ?


Au moment où on a besoin de déchiffrer le contenu. S'il s'agit du 
système, au démarrage évidemment.

Re: longue attente au boot

2018-05-07 Par sujet Eric Degenetais 
D'après ce que j'ai compris, le traitement proposé repose sur deux pistes
extérieures au noyau :
1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de qualité,
sinon utiliser un autre appel système
2) utiliser le bootloader pour conserver l'entropie lors d'un reboot pour
que le générateur soit plus rapidement près sans sacrifier la sécurité

Éric Dégenètais

Le 7 mai 2018 17:42,  a écrit :

Bonjour,

C'est un bug lié au fonctionnement du générateur d'entropie du noyau...
Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car
ça corrige une faille de sécu mais dans les programmes en espace
utilisateur (en gros, ton système attend qu'il y ait assez d'entropie pour
démarrer gdm).

Tu peux booter sur l'ancien noyau en attendant.

Julien

Re: Station diskless et Debian testing

2018-05-07 Par sujet BERTRAND Joël 
BOITEUX, Frederic a écrit :
>   Bonjour,
> 
>   Je crois que depuis Stretch, le protocole NFS est passé par défaut en TCP, 
> est-ce que tu as bien configuré ton accès NFS si tu veux accéder à un serveur 
> qui est toujours en UDP (j'imagine en NFSv3) ? Voir les options de mount, 
> comme « proto=udp » …

Bonsoir,

Tout est en TCP et en v3, client comme serveur. J'ai viré le lockd et
fait un rapport d'erreur sur le noyau. Avec un noyau plus ancien et la
même version de nfsd/lockd, ça ne provoque pas ce genre d'erreur sur le
serveur.

Bien cordialement,

JKB

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Wallace 


Le 07/05/2018 à 17:22, andre_deb...@numericable.fr a écrit :
> On Monday 07 May 2018 15:06:41 Olivier wrote:
>> Imaginons un serveur Debian :
> ou tout autre serveur finalement :-)
>
>> Quelle stratégie mettre en place pour diminuer au maximum les 
>> conséquences néfastes suite à un vol du serveur ?
> Sauf si le contenu de la partition du serveur est chiffré,
> si le serveur est physiquement volé, 
> ou que le pirate a le temps de rester devant l'ordinateur seul,
> il pourra faire ce qu'il veut avec un live-CD.
> Aucune parade possible dans ce cas.
>
> C'est très rare que des ordinateurs soient volés dans des data-center,
> ils sont tellement sécurisés au niveau des entrées.
Alors sans parler de vol, on peut parler de vol légal ou d'abus de
pouvoir, exemple :
- requête judiciaire par forcément fondée (pour constater et embêter
plus qu'autre chose) avec retrait des serveurs pour expertise judiciaire
- duplication de machine virtuelle et analyse vécu plusieurs fois fait
par des hébergeurs pas neutres du tout ou par des clients curieux de
comprendre comment nos installations Linux marchaient mieux que les
leurs sur leur cloud privé

Le chiffrement de serveur est donc plus utile qu'on ne le pense.

>
>
> Ce qui explique, entre autres, que plus de 50% des serveurs pros 
> sont maintenant sous GNU/Linux.
Une personne chez Azur MS disait lors d'une conférence d'une solution
open source que plus de 60% de leurs serveurs hébergés sur leur cloud
sont sous Linux. Et un autre chiffre d'estimation basé plus sur la
partie web parle de 80% de serveurs Linux. Vu le nombre d'instance chez
Azur plutôt orienté Windows et le taux bien plus haut en usage web donne
la fourchette de la vrai valeur entre 60 et 80%.





signature.asc
Description: OpenPGP digital signature

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Olivier 
Le 7 mai 2018 à 17:53, hamster  a écrit :

>
>
> Si tu chiffre l'intégralité d'une partoche avec luks, il faut donner la
> phrase de passe au boot si tu le démarre normalement, et au moment ou tu
> veux accéder a la partoche si tu boote avec une clef puis essaye de la
> lire.
>
>
Merci beaucoup pour ces précisions.

Dans mon cas, je chiffre la totalité du système. Au (re-)démarrage, il
faudra saisir une passe-phrase à la console, c'est bien ça ?

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet hamster 
Le 07/05/2018 à 17:39, Olivier a écrit :
> Le 7 mai 2018 à 16:00, hamster  > a écrit :
>
> Pour les oublis de phrase de passe par contre, y'a pas de solution
> miracle : il faut s'en rappeller.
>
>
> Faut-il saisir une  phrase de passe quand un système est chiffré ?

Bien sur, sinon le fait de chiffrer n'a pas de sens. Quand tu met une
serrure sur une porte, il faut donner un tour de clef a chaque fois que
tu veux l'ouvrir…

> Si oui, à quel moment (au boot, uniquement si on boote avec une clé,
> ...) ?

Ca dépend ce que tu chiffre et comment.

Si tu chiffre un fichier ou un dossier, il faut donner la phrase de
passe au moment ou tu veux y accéder.

Si tu chiffre l'intégralité d'une partoche avec luks, il faut donner la
phrase de passe au boot si tu le démarre normalement, et au moment ou tu
veux accéder a la partoche si tu boote avec une clef puis essaye de la lire.

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Pierre Malard 

> Le 7 mai 2018 à 17:31, Raphaël POITEVIN  a écrit :
> 
> andre_deb...@numericable.fr writes:
>> As tu vu l'émission d'Élise Lucet sur FR2 il y a peu,
>> le danger est le chiffrage à distance d'un ordinateur.
>> Le pirate (et non le hacker) enverra le code de déchiffrage
>> contre quelques bitcoins anonymes.
>> Des entreprises sont alors contraintes de payer,
>> une ne l'a pas fait et elle a dû fermer boutique.
>> Mais il s'agit d'ordinateurs sous Windows...
>> Ce qui explique, entre autres, que plus de 50% des serveurs pros
>> sont maintenant sous GNU/Linux.
> 
> Avez-vous remarqué d’ailleurs, que quand on interviewe des spécialistes
> du sujet et quand on leur demande si GNU/Linux es plus sécurisé que
> Windows, ils sont toujours embêté et n’osent pas répondre clairement ?
> Serait-ce une volonté de ne pas se mettre les éditeurs de logiciels à
> dos ?

Ou plus simplement pour ne pas susciter de stériles challenges… Genre
« j’en ai une plus longue que la tienne ».

Sinon, je serait très intéressé pour avoir des sources sur la répartition
réelle GNU/Linux vs Windows. Les 50% annoncés, d’où viennent ils ?

Cordialement



--
Pierre Malard

   « Tous les Français ambitionnent pour la France un grand rôle
   dans le monde. Ce n'est point par des aventures guerrières qu'elle
   le trouvera, c'est en donnant aux peuples l'exemple et le signal
   de justice. »
Jean Jaures - "L'idéal de justice" 
- 1889
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: longue attente au boot

2018-05-07 Par sujet julien 
Bonjour,

C'est un bug lié au fonctionnement du générateur d'entropie du noyau...
Un bug est ouvert mais apparemment ça ne sera pas corrigé sur le noyau car ça 
corrige une faille de sécu mais dans les programmes en espace utilisateur (en 
gros, ton système attend qu'il y ait assez d'entropie pour démarrer gdm).

Tu peux booter sur l'ancien noyau en attendant.

Julien

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Olivier 
Le 7 mai 2018 à 16:00, hamster  a écrit :

>
>
> Pour les oublis de phrase de passe par contre, y'a pas de solution
> miracle : il faut s'en rappeller.
>
>
Faut-il saisir une  phrase de passe quand un système est chiffré ?
Si oui, à quel moment (au boot, uniquement si on boote avec une clé, ...) ?

Re: longue attente au boot

2018-05-07 Par sujet Eric Degenetais 
bonjour,
ça semble lié à la résolution d'une CVE récente : une faille de sécurité
était créée par le fait que les générateurs de nombres aléatoires
n'attendaient pas d'avoir assez d'entropie pour générer des nombres
vraiment aléatoires, ce qui rend les clefs générées prédictibles.
Le patch a semble-t'il rendu l'appel bloquant jusqu'à accumulation d'une
entropie suffisante (ce qui se traduit par des comportements surprenants,
comme par exemple une accélération du boot par l'appui de touches ou le
déplacement de la souris), d'où l'allongement du délai au boot.

Cordialement

__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org


Le 7 mai 2018 à 15:30, Frédéric Baldit  a écrit :

>
> Bonjour,
>
> j'expérimente, depuis une réinstallation de stretch sous un PC portable
> amd64 (ASUS N55JV) avec le bureau gnome un long temps d'attente au boot.
>
> Je n'ai pas chronométré à la seconde près, mais à ma montre l'écran de
> login apparaît, de façon reproductible, au bout de deux minutes.
> Auparavant sur le même ordi. et sous stretch cela durait moins de
> 30s (je pense).
>
> Lors de la réinstall. le disque dur (un SSD) a été repartitionné (j'ai
> gardé le même schéma que lors d'une install. de stretch précédente et
> le système a été entièrement réinstallé.
>
> J'utilise le pilote propriétaire nvidia et bumblebee pour gérer (avec
> optimus) le démarrage à la demande de ma carte dédiée.
>
> J'ai testé (avec gnome-disks) l'état de mon SSD (le test long): cela
> dit il est sain (même si l'indicateur wear-leveling-count est à 25, le
> disque ayant (environ) 5 ans.
>
> Aussi, curieusement, j'ai une situation (que je n'avais pas avant): une
> fois connecté sous gnome (après les 2 min d'attente), un Ctrl+Alt+F1 me
> renvoit sur un nouvel écran de login graphique (et pas sur un login en
> mode console). Je ne sais pas si c'est normal...
>
> Je n'ai trouvé aucune piste prometteuse sur les posts des forum. Les
> messages de dmesg indiquent une grosse attente lors du boot (justement
> de environ 120s) qui se termine par la ligne:
>
> random: crng init done
>
> En fichier attaché la sortie texte de la commande dmesg.
>
> Apparemment (recherche sur google) il se pourrait que le (nouveau)
> système de boot systemd puisse être fautif, mais je n'en sait rien.
>
> Si quelqu'un a une idée, merci d'avance. Comme d'habitude toute
> suggestion est bienvenue. Je peux fournir les renseignements
> susceptibles d'aider (sur la machine et le système).
>
> Cordialement,
>
> --
>   Frédéric Baldit
>
>

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Raphaël POITEVIN 
andre_deb...@numericable.fr writes:
> As tu vu l'émission d'Élise Lucet sur FR2 il y a peu, 
> le danger est le chiffrage à distance d'un ordinateur.
> Le pirate (et non le hacker) enverra le code de déchiffrage
> contre quelques bitcoins anonymes.
> Des entreprises sont alors contraintes de payer,
> une ne l'a pas fait et elle a dû fermer boutique.
> Mais il s'agit d'ordinateurs sous Windows...
> Ce qui explique, entre autres, que plus de 50% des serveurs pros 
> sont maintenant sous GNU/Linux.

Avez-vous remarqué d’ailleurs, que quand on interviewe des spécialistes
du sujet et quand on leur demande si GNU/Linux es plus sécurisé que
Windows, ils sont toujours embêté et n’osent pas répondre clairement ?
Serait-ce une volonté de ne pas se mettre les éditeurs de logiciels à
dos ?
-- 
Raphaël

longue attente au boot

2018-05-07 Par sujet Frédéric Baldit 

Bonjour,

j'expérimente, depuis une réinstallation de stretch sous un PC portable
amd64 (ASUS N55JV) avec le bureau gnome un long temps d'attente au boot.

Je n'ai pas chronométré à la seconde près, mais à ma montre l'écran de
login apparaît, de façon reproductible, au bout de deux minutes.
Auparavant sur le même ordi. et sous stretch cela durait moins de
30s (je pense).

Lors de la réinstall. le disque dur (un SSD) a été repartitionné (j'ai
gardé le même schéma que lors d'une install. de stretch précédente et
le système a été entièrement réinstallé.

J'utilise le pilote propriétaire nvidia et bumblebee pour gérer (avec
optimus) le démarrage à la demande de ma carte dédiée.

J'ai testé (avec gnome-disks) l'état de mon SSD (le test long): cela
dit il est sain (même si l'indicateur wear-leveling-count est à 25, le
disque ayant (environ) 5 ans.

Aussi, curieusement, j'ai une situation (que je n'avais pas avant): une
fois connecté sous gnome (après les 2 min d'attente), un Ctrl+Alt+F1 me
renvoit sur un nouvel écran de login graphique (et pas sur un login en
mode console). Je ne sais pas si c'est normal...

Je n'ai trouvé aucune piste prometteuse sur les posts des forum. Les
messages de dmesg indiquent une grosse attente lors du boot (justement
de environ 120s) qui se termine par la ligne:

random: crng init done

En fichier attaché la sortie texte de la commande dmesg.

Apparemment (recherche sur google) il se pourrait que le (nouveau)
système de boot systemd puisse être fautif, mais je n'en sait rien.

Si quelqu'un a une idée, merci d'avance. Comme d'habitude toute
suggestion est bienvenue. Je peux fournir les renseignements
susceptibles d'aider (sur la machine et le système).

Cordialement,

--
  Frédéric Baldit

[0.00] microcode: microcode updated early to revision 0x22, date = 
2017-01-27
[0.00] Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) 
(gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.88-1 
(2018-04-29)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 
root=UUID=008405b6-78a7-45b4-960a-fac0a3cebfac ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9e010fff] usable
[0.00] BIOS-e820: [mem 0x9e011000-0x9e017fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9e018000-0x9e84] usable
[0.00] BIOS-e820: [mem 0x9e85-0x9ead5fff] reserved
[0.00] BIOS-e820: [mem 0x9ead6000-0xad8edfff] usable
[0.00] BIOS-e820: [mem 0xad8ee000-0xadaf2fff] reserved
[0.00] BIOS-e820: [mem 0xadaf3000-0xade25fff] usable
[0.00] BIOS-e820: [mem 0xade26000-0xaeb25fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xaeb26000-0xaef59fff] reserved
[0.00] BIOS-e820: [mem 0xaef5a000-0xaeffefff] type 20
[0.00] BIOS-e820: [mem 0xaefff000-0xaeff] usable
[0.00] BIOS-e820: [mem 0xafc0-0xcfdf] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00042f1f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI 2.0=0xadeae000  ACPI=0xadeae000  SMBIOS=0xaef58418 
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASUSTeK COMPUTER INC. N550JV/N550JV, BIOS N550JV.208 
11/19/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x42f200 max_arch_pfn = 0x4
[0.00] MTRR default type:

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet andre_debian 
On Monday 07 May 2018 15:06:41 Olivier wrote:
> Imaginons un serveur Debian :

ou tout autre serveur finalement :-)

> Quelle stratégie mettre en place pour diminuer au maximum les 
> conséquences néfastes suite à un vol du serveur ?

Sauf si le contenu de la partition du serveur est chiffré,
si le serveur est physiquement volé, 
ou que le pirate a le temps de rester devant l'ordinateur seul,
il pourra faire ce qu'il veut avec un live-CD.
Aucune parade possible dans ce cas.

C'est très rare que des ordinateurs soient volés dans des data-center,
ils sont tellement sécurisés au niveau des entrées.

> Quelques réflexions en vrac:
> 1. J'imagine possible de différencier les  moyens de protection selon la
> confidentialité des informations du serveur (pas besoin de protéger le code
> binaire du programme cp, mais impératif de protéger un fichier contenant
> des mots de passe) mais c'est peut-être fastidieux de maintenir dans le
> temps une telle classification. Est-il possible de tout chiffrer ?
> 2. Comment se protéger contre un attaquant qui essaie une infinité de
> combinaison login-mot de passe ?
> 3. Comment se protéger contre un attaquant qui boote avec un disque 
> externe ?
> 4. Un disque chiffré est-il plus fragile face aux problèmes hardware (bad
> sector, ...) ou plus compliqué à exploiter (sauvegarde, restauration, ...) ?
> 5. Existe-t-il des dispositifs matériels à prévoir pour faciliter ce qui
> précède ?

La menace réside plutôt ici :
Pour empêcher des intrusions à distance sur le serveur, que veux tu blinder ?
C'est un vaste sujet.
SSH essentiellement je pense, 
et le serveur Web + site, empêcher des réinjections de codes php et sql.
Il y a bien des solutions proposées sur le net.

As tu vu l'émission d'Élise Lucet sur FR2 il y a peu, 
le danger est le chiffrage à distance d'un ordinateur.
Le pirate (et non le hacker) enverra le code de déchiffrage
contre quelques bitcoins anonymes.
Des entreprises sont alors contraintes de payer,
une ne l'a pas fait et elle a dû fermer boutique.
Mais il s'agit d'ordinateurs sous Windows...
Ce qui explique, entre autres, que plus de 50% des serveurs pros 
sont maintenant sous GNU/Linux.

André

KVM et OpenVSwitch

2018-05-07 Par sujet Olivier 
Bonjour,

Je vais refondre dans les prochaines semaines mon infrastructure pour la
virtualisation avec KVM.

Actuellement :
- mes VMs ont des interfaces réseau virtuelles qui correspondent chacune à
un pont (paquet bridge-utils)
- j'ai quelques VMs Debian qui implémentent du routage (IP forwading + NAT
avec iptables) et quelques services annexes (DHCP, DNS) quand une des VMs a
besoin de ce type de service, (ie quand je simule l'environnement réseau
d'un projet).

J'ai découvert l'existence du projet OpenVSwitch.
Je découvre qu'il est intégrable à KVM.
Il apporte, semble-t-il, la possibilité de virtualiser sur plusieurs hôtes
KVM.

Voici mes questions:

1. J'ai du mal à comprendre si oui ou non un switch virtuel OVS pourrait ou
non remplacer mes VMs dédiées au routage. Qu'en penser sachant que je cible
une implémentation sous Stretch ? Buster changerait-il la donne sur ce
sujet ?

2. J'imagine que la prise en main d'un OpenVSwitch ne doit pas être facile;
qu'en pensez-vous ? Existe-t-il des interfaces graphiques pour aider à
cette prise en main (j'ai en mémoire de grands moments de solitude quand le
réseau ne fonctionne pas comme on l'espère alors toute aide pour comprendre
ce qui se passe est la bienvenue) ?

Slts

Re: Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet hamster 
Le 07/05/2018 à 15:06, Olivier a écrit :
> 1. J'imagine possible de différencier les  moyens de protection selon
> la confidentialité des informations du serveur (pas besoin de protéger
> le code binaire du programme cp, mais impératif de protéger un fichier
> contenant des mots de passe) mais c'est peut-être fastidieux de
> maintenir dans le temps une telle classification. Est-il possible de
> tout chiffrer ?

Oui, et c'est meme le mieux. Quand je dis "tout chiffrer", c'est toute
la partition, meme la "table of contents", meme le journal. Et c'est une
bonne idée de tout chiffrer, meme la partition sytème, et en particulier
la swap. Pour faire ca, luks est ton ami.

> 2. Comment se protéger contre un attaquant qui essaie une infinité de
> combinaison login-mot de passe ?

fail2ban

> 3. Comment se protéger contre un attaquant qui boote avec un disque
> externe ?

Tout chiffrer avec luks.

> 4. Un disque chiffré est-il plus fragile face aux problèmes hardware
> (bad sector, ...) ou plus compliqué à exploiter (sauvegarde,
> restauration, ...) ?

Si tu chiffre la partoche elle meme avec luks, tu y accède (et donc le
sauvegarde) comme n'importe quel système de fichier. Le noyau se charge
de tout chiffrer / déchiffrer a la volée, mais toit tu ne le vois pas.
Pour les soucis de type bloc défectueux, je sais pas te répondre. C'est
a ca que servent les sauvegardes et/ou la redondance (un serveur avec
les disques qui sont pas en raid, ca fait bizarre).

Pour les oublis de phrase de passe par contre, y'a pas de solution
miracle : il faut s'en rappeller.

Les attaques les plus difficiles a contrer sont de type "evil maid". On
ne peut pas tout chiffrer : quand il démarre, il te demande ta phrase de
passe, le petit bout de code qui te demande ta phrase de passe ne peut
pas etre chiffré puisqu'il doit etre lu avant que tu ne donne ta phrase
de passe. Le danger est donc un attaquant qui modifie ce petit bout de
code non chiffré et lui rajoute une fonction d'enregistrement de ta
phrase de passe. Puis il laisse le serveur fonctionner comme si de rien
n'etait. La prochaine fois que tu reboote, tu tape ta phrase de passe,
ca l'enregistre quelque part et l'attaquant peut alors te voler ton truc
et lire les partitions chiffrées vu qu'il a la phrase de passe.

> 5. Existe-t-il des dispositifs matériels à prévoir pour faciliter ce
> qui précède ?

Je sais pas te répondre.

Quelle stratégie contre le vol d'un serveur ?

2018-05-07 Par sujet Olivier 
Bonjour,

Imaginons un serveur Debian
Quelle stratégie mettre en place pour diminuer au maximum les conséquences
néfastes suite à un vol du serveur ?

Quelques réflexions en vrac:

1. J'imagine possible de différencier les  moyens de protection selon la
confidentialité des informations du serveur (pas besoin de protéger le code
binaire du programme cp, mais impératif de protéger un fichier contenant
des mots de passe) mais c'est peut-être fastidieux de maintenir dans le
temps une telle classification. Est-il possible de tout chiffrer ?

2. Comment se protéger contre un attaquant qui essaie une infinité de
combinaison login-mot de passe ?

3. Comment se protéger contre un attaquant qui boote avec un disque externe
?

4. Un disque chiffré est-il plus fragile face aux problèmes hardware (bad
sector, ...) ou plus compliqué à exploiter (sauvegarde, restauration, ...) ?

5. Existe-t-il des dispositifs matériels à prévoir pour faciliter ce qui
précède ?

Slts

RE: Station diskless et Debian testing

2018-05-07 Par sujet BOITEUX, Frederic 
Bonjour,

  Je crois que depuis Stretch, le protocole NFS est passé par défaut en TCP, 
est-ce que tu as bien configuré ton accès NFS si tu veux accéder à un serveur 
qui est toujours en UDP (j'imagine en NFSv3) ? Voir les options de mount, comme 
« proto=udp » …

Cdlt,
Fred.

-Message d'origine-
De : BERTRAND Joël  
Envoyé : samedi 28 avril 2018 18:30
À : debian-user-french@lists.debian.org
Objet : Re: Station diskless et Debian testing

Bonsoir à tous,

J'avance sur mon problème. Je viens de m'apercevoir que mon syslog est 
plein de lignes comme ceci :

Apr 28 17:35:23 hilbert kernel: [282745.749938] lockd: server
192.168.10.128 not responding, still trying Apr 28 17:35:23 hilbert kernel: 
[282745.749969] xs_tcp_setup_socket:
connect returned unhandled error -107
Apr 28 17:35:29 hilbert kernel: [282751.810082] lockd: server
192.168.10.128 OK
Apr 28 18:27:15 hilbert kernel: [285857.121396] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:15 hilbert kernel: 
[285857.373345] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:16 hilbert kernel: 
[285858.641114] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:25 hilbert kernel: 
[285866.965630] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:26 hilbert kernel: 
[285868.225678] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:28:36 hilbert kernel: 
[285938.011610] lockd: server
192.168.10.128 OK
Apr 28 18:28:37 hilbert kernel: [285939.019589] lockd: server
192.168.10.128 OK
Apr 28 18:28:45 hilbert kernel: [285947.627997] lockd: server
192.168.10.128 OK
Apr 28 18:28:47 hilbert kernel: [285949.139779] lockd: server
192.168.10.128 OK

Il y a donc un truc qui casse au moins NFSv3 dans le noyau 4.15.17-1 de 
chez Debian. Je précise que lorsque je me prends ce genre d'erreur depuis mon 
poste de dev, toutes les autres machines diskess utilisant le même serveur 
(arm, x86 FreeBSD...) fonctionnement parfaitement. Je n'arrive pas à savoir si 
lockd par en timeout sur l'erreur 107 ou si c'est le contraire.

Bien cordialement,

JKB

This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

Re: renseignement pour se connecter à un nas

2018-05-07 Par sujet BERTRAND Joël 
Bonjour,

Personnellement, c'est iSCSI depuis une machine qui fait serveur de
fichier. Ça permet de centraliser les droits. Le NAS est vu comme un
disque du serveur de fichier. Naturellement, j'ai un brin Ethernet qui
est dédié à la communication serveur de fichiers-NAS.

Cordialement,

JKB

Re: renseignement pour se connecter à un nas

2018-05-07 Par sujet Bernard Schoenacker 


- Mail original -
> De: err...@free.fr
> À: debian-user-french@lists.debian.org
> Envoyé: Dimanche 6 Mai 2018 22:27:47
> Objet: Re: renseignement pour se connecter à un nas

> j'ai utilisé plusieurs NAS, et toutes les fois que c'était possible,
> je me suis servi de sshfs.
> 
> sshfs a le mérite d'être simple à utiliser et à configurer (il suffit
> de configurer un serveur ssh sur le nas).

bonjour,

il s'agit d'un QNAP TS 251 et donc je me suis rendu sur le site du
fabricant et j'ai vu qu'il fallait employer nfs ...

merci
pour tout

slt
bernard