Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Jean-Michel OLTRA 

Bonjour,


Le lundi 11 avril 2016, afrinc a écrit...


> Brider les IPs…

> Du genre en préfixant la clef dans ~/.ssh/authorized_keys d'un :
> from="123.45.67.89"

> cf : man authorized_keys, section AUTHORIZED_KEYS FILE FORMAT 

> Cette méthode fonctionne bien sûre que sur les IPs fixe, et donc ne sert
> à rien dans le cas d'un besoin d'accès "nomade" au serveur SSH.

Je faisais ça via un pare-feu, et une set pour gérer l'accès (avec
ipset). En cas de nomadisme, il était facile pour un autre admin de
créer une entrée dans la set adéquate avec l'ip du nomade. Le nomade
pouvait se connecter, puis supprimer son entrée (et se couper la
branche…) pour sortir. C'est gérable lorsqu'il n'y a pas un nomadisme
incessant, et lorsque c'est uniquement à l'occasion.

-- 
jm

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Francois Lafont 
On 11/04/2016 13:23, Vincent Lefevre wrote:

> La seule chose que je peux voir est la connexion depuis une nouvelle
> adresse IP ou une adresse IP n'appartenant pas à un ensemble de blocs
> prédéterminés par l'utilisateur. Ce n'est pas forcément illicite, mais
> cela permet à l'utilisateur de vérifier.
> 
> Après, je n'ai pas cherché comment mettre cela en place.
> 
> Si la crainte est une attaque consistant à deviner la clé privée par
> une succession limitée d'essais (e.g. à cause d'un trou de sécurité
> pas encore connu par les développeurs), alors fail2ban est une
> première protection.

Ok, merci pour ces infos Vincent. Effectivement, à part en vérifiant
l'IP source, il ne doit pas avoir beaucoup d'autres options.

-- 
François Lafont

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Francois Lafont 
Hello,

On 11/04/2016 17:09, Olivier wrote:

> Si on suppose qu'en tant qu'administrateur, les opérations à effectuer à
> distance sur une machine demandent très souvent les privilèges de root,
> selon cette méthode, il faut se connecter par clé en tant qu'un utilisateur
> lamda, puis escalader en tant que root.

C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh
n'est pas possible... avec un mot de passe (de toute façon celui-ci fait dans
les 30 caractères environ).

Au passage, je m'étais planté dans mon message précédent, ce n'est pas
"PermitRootLogin false" qu'on a mais "PermitRootLogin without-password" ce
qui veut donc dire que :

a) une connexion "ssh root" est impossible via son mot de passe;
b) une connexion "ssh root" est possible via une clé ssh.

Ceci étant, le cas b) n'est pas utilisé chez nous car nous ne déployons pas
(en vérité on l'a fait mais on le fait plus désormais) de clé publique ssh
dans /root/.ssh/authorized_keys.

Donc oui, en effet, on se connecte en ssh avec notre compte perso (qui
possède un mot de passe qu'on ne saisit jamais car on utilise notre clé ssh)
et ce compte est en effet « sudo » (pour les admins).

> Pour cette escalade, dois-tu saisir le mot de passe de root (commande su)
> ou utilises-tu de préférence sudo ?

On utilise sudo et on a configuré sudo (via notre gestionnaire de conf) pour
qu'on (les admins) puisse lancer "sudo cmd" sans demande de mot de passe _sauf_
dans le cas où la commande est "su" elle-même. Ceci étant, je crois bien que
cette petite exception avec "su" est plus cosmétique qu'autre chose. ;)

> Dans ce dernier cas (sudo) comment est gérée la saisie du mot de passe (
> NOPASSWORD ? saisie du mot de passe ? ...)

NOPASSWORD donc modulo la petite exception avec la commande su.

-- 
François Lafont

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Vincent 
Le 11/04/2016 16:07, afrinc a écrit :
> Le 11/avril - 15:14, honeyshell a écrit :
>> Dans le cas d'une passphrase heureusement fail2ban fait le travail.
>> D'un point de vue sécurité je n'imagine pas ssh sans passphrase.
>>
>> Je ne sais pas si il existe un script qui avertit par mail en cas
>> d'échec répétitifs détectés par Fail2ban sur la passphrase?
>>
>> Un script qui avertirait par mail en cas d'une connexion via une IP
>> non connue serait aussi intéressant? (bien sûr brider les IP serait la
>> solution idéale)
> 
> Brider les IPs…
> 
> Du genre en préfixant la clef dans ~/.ssh/authorized_keys d'un :
> from="123.45.67.89"
> 
> cf : man authorized_keys, section AUTHORIZED_KEYS FILE FORMAT 
> 
> Cette méthode fonctionne bien sûre que sur les IPs fixe, et donc ne sert
> à rien dans le cas d'un besoin d'accès "nomade" au serveur SSH.
> 

Pour le cas des nomades ou accès extérieurs, il y a la solution du
VPN/tunnel ou d'un serveur intermédiaire. Dans le dernier cas, il y a
plusieurs solution:
- config ssh ProxyCommand : https://wiki.gentoo.org/wiki/SSH_jump_host
- Logiciel dédié qui gère l'accès selon groups,heure,etc...

Dans le cas du serveur intermédiaire, les clés ne sortent pas de
l'entreprise et seul le serveur intermédiaire est exposé.


-- 
EON Vincent
http://www.lws.fr
--
Siége social:
LIGNE WEB SERVICES
4, RUE GALVANI
75017 PARIS - FRANCE
---

Ce message et toute pièce jointe sont confidentiels et doivent être
protégés contre toute divulgation. Si vous n'êtes pas le destinataire de
ce message, merci de téléphoner ou d'envoyer un email à l'expéditeur, et
de détruire ce message et toute pièce jointe.

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Olivier 
Le 9 avril 2016 à 22:38, Francois Lafont  a écrit :

> Bonsoir,
>
> Perso, voici comment je fais. Je ne sais pas si bien comme il faut ou non.
> Si certains ont des remarques, je suis preneur bien sûr.
>
> Sur les serveurs que j'administre, le mot de passe root existe mais il
> fait dans les ~30 caractères et je ne l'utilise jamais. De toute façon la
> connexion en tant que root via ssh est impossible (PermitRootLogin false).
> C'est juste un mot de passe spécial coup dur ;). Ensuite, tout passe par
> des paires de clés ssh. On va dire que j'ai globalement 2 machines (une
> chez moi et une à mon travail) avec chacun sa paire de clés ssh et les clés
> publiques sont déployées sur les serveurs au niveau de root et d'un compte
> flaf qui est sudo (je reviens sur ce point ci-dessous).
>
Si on suppose qu'en tant qu'administrateur, les opérations à effectuer à
distance sur une machine demandent très souvent les privilèges de root,
selon cette méthode, il faut se connecter par clé en tant qu'un utilisateur
lamda, puis escalader en tant que root.
Pour cette escalade, dois-tu saisir le mot de passe de root (commande su)
ou utilises-tu de préférence sudo ?
Dans ce dernier cas (sudo) comment est gérée la saisie du mot de passe (
NOPASSWORD ? saisie du mot de passe ? ...)

>
> La chose qui me semble _absolument_ indispensable pour ce type de clés (ie
> utilisées par un humain, en l'occurrence moi-même, et pas dans un script
> non interactif), c'est une bonne passphrase sur chaque chaque clés privées.
> Pour ce type de clés, je pense que c'est vraiment imprudent de ne pas avoir
> de passphrase. Ensuite, avoir un agent ssh qui tourne sur sa machine de
> travail pour n'avoir à saisir la passphrase qu'une seule fois à chaque
> début de session me semble un _excellent_ compris entre sécurité et
> commodité.
>
> Je sauvegarde quelque part au chaud mes 2 paires de clés ssh.
>
> Enfin, et c'est un point important je pense, les clés publiques sur les
> serveurs sont déployées via un logiciel de gestionnaire de configuration
> (en l'occurrence Puppet). Si jamais je me fait piquer une paire de clés
> ssh, le temps que le pirate arrive à me casser la passphrase, je peux
> supprimer les clés publiques des serveurs et en redéployer une nouvelle en
> une dizaine de minutes.
>
> Voilà.
>
> --
> François Lafont
>
>

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet afrinc 
Le 11/avril - 15:14, honeyshell a écrit :
> Dans le cas d'une passphrase heureusement fail2ban fait le travail.
> D'un point de vue sécurité je n'imagine pas ssh sans passphrase.
> 
> Je ne sais pas si il existe un script qui avertit par mail en cas
> d'échec répétitifs détectés par Fail2ban sur la passphrase?
> 
> Un script qui avertirait par mail en cas d'une connexion via une IP
> non connue serait aussi intéressant? (bien sûr brider les IP serait la
> solution idéale)

Brider les IPs…

Du genre en préfixant la clef dans ~/.ssh/authorized_keys d'un :
from="123.45.67.89"

cf : man authorized_keys, section AUTHORIZED_KEYS FILE FORMAT 

Cette méthode fonctionne bien sûre que sur les IPs fixe, et donc ne sert
à rien dans le cas d'un besoin d'accès "nomade" au serveur SSH.

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Grégory Reinbold 

Salut

Le 11/04/2016 15:14, honeyshell a écrit :

Dans le cas d'une passphrase heureusement fail2ban fait le travail.
D'un point de vue sécurité je n'imagine pas ssh sans passphrase.

Moi si, script sshfs auto avec clé sans pass.


Je ne sais pas si il existe un script qui avertit par mail en cas
d'échec répétitifs détectés par Fail2ban sur la passphrase?

logcheck ?


Un script qui avertirait par mail en cas d'une connexion via une IP
non connue serait aussi intéressant? (bien sûr brider les IP serait la
solution idéale)



--
Grégory Reinbold

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet honeyshell 
Dans le cas d'une passphrase heureusement fail2ban fait le travail.
D'un point de vue sécurité je n'imagine pas ssh sans passphrase.

Je ne sais pas si il existe un script qui avertit par mail en cas
d'échec répétitifs détectés par Fail2ban sur la passphrase?

Un script qui avertirait par mail en cas d'une connexion via une IP
non connue serait aussi intéressant? (bien sûr brider les IP serait la
solution idéale)

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Jean-Michel OLTRA 

Bonjour,


Le lundi 11 avril 2016, Vincent Lefevre a écrit...


> La seule chose que je peux voir est la connexion depuis une nouvelle
> adresse IP ou une adresse IP n'appartenant pas à un ensemble de blocs
> prédéterminés par l'utilisateur. Ce n'est pas forcément illicite, mais
> cela permet à l'utilisateur de vérifier.

A une époque, et dans un contexte bien donné, j'avais bridé l'accès ssh
sur les ip publiques des administrateurs (nous étions 3).

Bon, l'un d'entre eux a refilé l'accès root à un quatrième, qui n'a pas
pu se connecter, par conséquent…

-- 
jm

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Sébastien NOBILI 
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit :
> On 2016-04-08 14:26:03 +0200, Sébastien NOBILI wrote:
> > Je ne parlais pas de chiffrer les clés SSH, mais de chiffrer la clé USB.
> 
> Quel est l'intérêt de chiffrer la clé USB alors que la clé SSH est
> déjà chiffrée en standard (de manière optionnelle, mais je suppose
> que l'utilisateur a choisi une passphrase non vide)?

Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si :
— pas de passphrase (ok, pas forcément top, mais tellement pratique),
— la clé contient d’autres données en clair (ce qui est mon cas, d’où ma
  remarque, mais on sort un peu du sujet initial).

Sébastien

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Vincent Lefevre 
On 2016-04-11 00:10:21 +0200, Francois Lafont wrote:
> À partir du moment où on se fait piquer sa clé privée, comment un
> serveur pourrait-il détecter qu'une connexion ssh est illicite alors
> que justement le contrat est "seul le détenteur de la clé privée
> pourra se connecter" ? Je serais curieux d'avoir des infos sur tout
> ça.

La seule chose que je peux voir est la connexion depuis une nouvelle
adresse IP ou une adresse IP n'appartenant pas à un ensemble de blocs
prédéterminés par l'utilisateur. Ce n'est pas forcément illicite, mais
cela permet à l'utilisateur de vérifier.

Après, je n'ai pas cherché comment mettre cela en place.

Si la crainte est une attaque consistant à deviner la clé privée par
une succession limitée d'essais (e.g. à cause d'un trou de sécurité
pas encore connu par les développeurs), alors fail2ban est une
première protection.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Vincent Lefevre 
On 2016-04-09 18:45:36 +0200, David Demonchy wrote:
> 1 machine 1 jeu de clé.
> C'est à dire que chaque serveur à sa clé, mais aussi chaque client (pc
> perso, boulot et smartphone)
> Pour résumé, j'ai 3 jeux de clés par machine qui nécessite une connexion ssh.
> Si 2 machines peuvent communiquer entre elles, elles ont aussi leurs
> jeu de clés.

Tu as un jeu de clés pour chaque couple (client,serveur)???

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet Vincent Lefevre 
On 2016-04-08 14:26:03 +0200, Sébastien NOBILI wrote:
> Je ne parlais pas de chiffrer les clés SSH, mais de chiffrer la clé USB.

Quel est l'intérêt de chiffrer la clé USB alors que la clé SSH est
déjà chiffrée en standard (de manière optionnelle, mais je suppose
que l'utilisateur a choisi une passphrase non vide)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Conseils sur la sécurisation de ses accès par SSH

2016-04-11 Par sujet merkedanke 
comment un serveur pourrait-il détecter qu'une connexion ssh est 
illicite alors que justement le contrat est "seul le détenteur de la 
clé privée pourra se connecter" ?<
une politique horaire , 2 admin ... le problème a déjà été abordé et 
même en multiclé , les clés ont été compromises. c'est de l'entière et 
unique responsabilité du détenteur(S) des clés. il s'agiraît donc de 
personnes peu dignes de confiance.

Re: Pourquoi drupal7 a besoin de MySQL ? / Choix d'un CMS

2016-04-11 Par sujet Sébastien NOBILI 
Bonjour,

Le vendredi 08 avril 2016 à 23:50, kaliderus a écrit :
> Le 8 avril 2016 à 23:41, Sébastien Dinot  a écrit :
> > kaliderus a écrit :
> >> Ce qui est surprenant c'est que sur ma machine j'ai bien PostgreSQL
> >> d'installé mais si je demande drupal7, aptitude m'oblige à installer
> >> MySQL.
> >
> > Puis-je avoir plus d'infos sur les commandes lancées, les paquets
> > PostgreSQL installés ?
> >
> Avec plaisir :
> - Je lance aptitude (mode console)
> - Je sélectionne le paquet drupal7 ( touche +)
> - J'appuie sur g
> 
> aptitude search '~ipostgresql'
> i A postgresql-9.4
> i A postgresql-client-9.4
> i A postgresql-common
> i   postgresql-contrib
> i A postgresql-contrib-9.4
> i   postgresql-doc
> i A postgresql-doc-9.4

Le comportement que tu rencontres me semble tout à fait normal. Tu as bien un
PostgreSQL installé et fonctionnel, mais du point de vue du gestionnaire de
paquets, ce n’est pas le cas car il te manque le meta-paquet « postgresql ».

Si tu installes ce meta-paquet et que tu recommences ta manip, il ne devrait
plus te proposer d’installer MySQL.

Sébastien

Re: P r o x m o x e t D e b i a n

2016-04-11 Par sujet merkedanke 
Version raspberry< (olimex²pinguinos ou une montre connectée "hackée" 
qui sait ?): il y a bien quelqu'un chez eux qui va proposer cela un 
jour ou l'autre ... cela ne m'inquiète pas du tout ... le tout est 
d'être hors-champs et de ne contenir que le service approprié 
(freedombox offrent des solutions alternatives non-parfaite et 
non-épuré mais des plus attrayantes).


l'idée m'est venu suite à des proches en transit _ le téléphone est 
souvent coupé ou/et surveillé et le courrier (ups?) pas toujours 
distribué. Passer un message sans passer par un service officiel tout en 
bénéficiant d'une infrastucture existante me semblait évident, 
l'autonomie et l'indépendance restant acquises à-priori (dans les faits 
, on en est loin).


Pour un environnement de mail : je dirais tout dépend des compétences 
de la personne qui l'installe.réflexion bien immature à ce sujet.


En somme [...]< donc c'est envisageable, voilà un point positif qui 
réponds pleinement à mes interrogations.