Mémo Debian & VDR

Mise en oeuvre simple de iptable

michael — 2016-11-08T15:40:33Z

Ce petit tuto est la pour une mise en eouvre assez minimaliste de iptable.

Nous pouvons deja voir avec cette commande si des regles sont en place :

iptables -L -n

Nous devrions avoir ce type de resultat si nous avons aucune regle :

Chain INPUT (policy ACCEPT)
num target prot opt source destination Chain FORWARD (policy ACCEPT)
num target prot opt source destination Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

Dans un premier temps, nous allons tout accepter sur l'adresse de loopback :

iptables -A INPUT -i lo -j ACCEPT

La suite des actions sont realise sur l'interface de la carte reseau. Pour faciliter la suite du document, nous allons initialiser une variable contenant le nom de notre interface reseau (Dans mon cas eth0) :

_ETHERNET="eth0"

Nous allons deja accepte toutes les requetes qui sont deja en statut etablis (cela evite de se faire killer :) ) :

iptables -A INPUT -i ${_ETHERNET} -m state --state RELATED,ESTABLISHED -j ACCEPT

Nous autorisons a present les connexions SSH sur le port 22 :

iptables -A INPUT -i ${_ETHERNET} -p tcp -m tcp --dport 22 -j ACCEPT

Nous allons activer une journalisation des paquets qui sont droppes pour ainsi aider a une analyse si quelques choses ne fonctionne pas :

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "iptables-dropped: "
iptables -A LOGGING -j DROP

Tous les autres paquets sont a present droppe via cette commande :

iptables -A INPUT -i ${_ETHERNET} -j DROP

Mise en place de la persistance de notre configuration :

aptitude install iptables-persistent
iptables-save > /etc/iptables/rules.v4

la derniere commande iptables-save sera a refaire a chaque ajout/modification de regle iptables si nous ne voulons pas les perdre lors d'un reboot.

Configuration de syslog pour avoir un fichier de log particulier pour les DROP :

sed -i 's/^#\(.*imklog.*\)/\1/'g /etc/rsyslog.conf
printf ":msg, contains, \"iptables-dropped\" /var/log/iptables.log\n& stop\n" >> /etc/rsyslog.d/iptables.conf
systemctl restart rsyslog

Mise en place d'une rotation de cette log :

printf "/var/log/iptables.log\n{\n\trotate 4\n\tweekly\n\tmissingok\n\tnotifempty\n\tcompress\n\tdelaycompress\n\tsharedscripts\n\tpostrotate\n\t\tinvoke-rc.d rsyslog rotate > /dev/null\n\tendscript\n}\n" >> /etc/logrotate.d/iptables
printf "OK\n"

Limite les acces par SSH

michael — 2016-06-20T09:21:56Z

Limiter les acces en SSH pour ainsi securise un peu plus les acces a notre environnement surtout si celui-ci est accessible en exterieur.

Permettre uniquement un acces par cle pour root

Le parametre PermitRootLogin permet de limiter les acces de root en ssh. Nous allons le permettre mais a l'unique condition que celui-ci utilise une cle SSH. Pour ce faire remplacer dans /etc/ssh/sshd_config, le parametre :
PermitRootLogin *
par
PermitRootLogin without-password

Autoriser uniquement les menbres d'un groupe a acceder en ssh

Le parametre AllowGroups permet de n'autoriser que les membres de ce groupe a acceder au serveur en ssh.

En premier lieu, creer un groupe ssh-allow :

addgroup --system ssh-allow

Ajouter nos utilisateurs dans ce groupe via cette commande :

adduser mon-user ssh-allow

Nous pouvons maintenant ajouter le parametre dans la configuration de sshd dans /etc/ssh/sshd_config :
AllowGroups ssh-allow

Vous pouvez maintenant redemarrer sshd.

ATTENTION : Avant de vous deconnecter de votre ssh, veuillez bien verifier que vous avez acces au serveur en ssh avec votre utilisateur

Installation de FiSH pour irssi

eRen, michael — 2008-05-26T19:46:40Z

Toute la manipulation se déroule dans le sous-répertoire "src" dans ma home. Les sources de irssi, de FiSH, et de MIRACL sont requis, ainsi que la "glib" paquet "libglib2.0-dev" sur ma plateforme.

Pré-requis

aptitude install irssi-dev libglib2.0-dev

Toutes les commandes qui vont suivre ne nécessitent pas les droits root et devront être effectuées avec un user normal de préférence. Si possible le user utilisant irssi.

Récupération des sources

cd ~ mkdir src cd src

Récupérez l'archive FiSH sur le site ici
ou tapez les commandes suivantes :

wget http://fish.secure.la/irssi/FiSH-irssi.v1.00-RC5-source.zip unzip FiSH-irssi.v1.00-RC5-source.zip cd FiSH-irssi.v1.00-RC5-source/

Compilation de miracl.a

Pour compiler libfish.so il est nécessaire de générer le fichier "miracl.a", Multiprecision Integer and Rational Arithmetic, pour plus de précisions sur ce "projet", voir ici

Nous créons un répertoire dans le répertoire de FiSH.

mkdir MIRACL cd MIRACL cp ../mir_amd64 amd64 wget ftp://ftp.computing.dcu.ie/pub/crypto/miracl.zip unzip -j -aa -L miracl.zip

Pour les architecture 32bits, tapez :

bash linux

et pour les 64bits, tapez :

bash amd64

Vous pouvez tester la bonne compilation de miracl.a avec la commande :

./pk-demo

Il calcule des clés de différentes longueurs pour Alice et Bob :-)

Recopiez le précieux fichier dans les sources de FiSH

cp miracl.a ../

Compilation de "libfish.so"

cd ~/src/FiSH-irssi.v1.00-RC5-source

Il faut modifier le Makefile de "FisH" pour lui indiquer où se trouvent les sources de "irssi" ainsi que le chemin où se trouve "glib". Remplacer les trois premières lignes du Makefile par celles-ci :

glib_inc = /usr/include/glib-2.0 glib_dir = /usr/lib/glib-2.0 irssi_dir = /usr/include/irssi

Compilation :
Pour les architectures 32bits, tapez :

make

et pour les 64bits, tapez :

make amd64

Vous devriez (tout comme chez moi, vu que je déroule ce tuto en même temps que je l'écris), obtenir cette ligne :

Compiling finished -->> /home/toto/src/FiSH-irssi.v1.00-RC5-source/libfish.so

Il ne reste plus qu'à recopier le fichier libfish.so dans le répertoire modules de irssi (répertoire général ou de votre HOME) :

Si vous êtes le seul à utiliser irssi sur votre PC :

mkdir -p ~/.irssi/modules/ cp libfish.so ~/.irssi/modules/

Si vous souhaitez l'installer dans le répertoire général de irssi, les droits root sont nécessaires :

cp libfish.so /usr/lib/irssi/modules/

Utilisation de "libfish.so"

Une fois dans irssi vous chargerez ce module à l'aide de la commande suivante :

/load fish

irssi répond :

21:13 - !- FiSH : Using default password to decrypt blow.ini... Try /setinipw to set a custom password.
21:13 - !- Irssi : FiSH v1.00 - encryption module for irssi loaded ! URL : http://fish.sekure.us
21:13 - !- Irssi : Try /helpfish or /fishhelp for a short command overview
21:13 - !- Irssi : Loaded module fish/core

Vous pouvez également automatiser le chargement du module en tapant cette commande :

echo '/load fish' >> ~/.irssi/startup

Remarque : L'échange des clés se fait sur le serveur irc ...

Bon chat :-)

Source d'information :
http://fish.secure.la/
http://www.shamus.ie/

Mise à jour :
– Corrections des liens vers fish.secure.la (01.02.2010)
– Installation des pré requis (26/05/2008)
– Version 1.00Rc5 de Fish (26/05/2008)
– Correction de lien (26/05/2008)
– Compilation 32 et 64 bits (26/05/2008)

Générer une clé gnupg

eRen, michael — 2008-04-15T18:00:23Z

Générer une clé gnupg permettant de transmettre des messages (mail, Jabber...) signés et/ou chiffrés.

Gpg est installé par défaut sur la distribution Debian.

Nous passons donc directement à la création de notre clé gpg privée.

Ouvrez un nouveau shell et tapez les commandes suivantes :

gpg --gen-key

Il va vous créer un répertoire .gnupg dans votre Home.

A la première question, répondre "1" (DSA and Elgamal (default))

En passant, pour créer une clé RSA qui fait plus que signer, taper :

gpg --expert --gen-key

Ensuite, vous pouvez modifier la taille de la clé mais la valeur par défaut convient déjà très bien.

Laissez le choix par défaut pour la date d'expiration.

Confirmez avec "Y" que tous les renseignements sont corrects.

Il va à présent vous demander de renseigner votre nom et votre adresse e-mail (Cela sera utile pour vos correspondants, qui pourront ainsi savoir a qui appartient la clef). Vous pouvez aussi éventuellement attacher un commentaire.

Vous devez maintenant confirmer que les renseignements précédants sont corrects en tapant "O".

A présent, entrez une passphrase pour protéger votre clé. (C'est une phrase, pas un mot de passe !!!).

La clé va à présent se générer. Il faudra créer de l'aléatoire en démarrant des applications. Par exemple, en écoutant de la musique... Pour ainsi permettre la génération d'une clé très aléatoire.

Quelques commandes usuelles :

1) Lister son trousseau de clés publiques

Format court

gpg --list[-secret]-keys

Format long

gpg --list[-secret]-keys --keyid-format long

2) Ajouter une clé

gpg --import nouvellecle.asc

3) Exporter une clé publique (cas le plus fréquent la sienne, pour pouvoir la communiquer)

Récupérer le nom de l'utilisateur dont on souhaite exporter la clé, à l'aide de la commande gpg --list-keys

Exporter la clé dans un fichier, au format ASCII (utile pour "Mailer" la clé) :

gpg --armor --output MaClePub.asc --export "Nom_De_Lutilisateur"

Sans l'option --armor la clé est générée au format binaire.

4) Exporter sa clé privée

gpg --export-secret-key -a >MaClePriv.key

5) Importer sa clé privée (cas d'un 2ème trousseau situé sur un autre PC)
Recopier la fichier sur le deuxième PC à l'aide d'un moyen sûr (clé USB par exemple)

gpg --import --allow-secret-key-import MaClePriv.key

Si vous rencontrez ce message d'erreur en voulant encrypter :

gpg --encrypt --recipient 'Nom du destinataire' 'Nom du fichier à encrypter' gpg: AABBCCDD: Rien ne dit que la clé appartient vraiment à l'utilisateur nommé.

Vous devez "faire confiance à l'utilisateur" à l'aide de la commande suivante :

gpg --edit-key 'Nom du destinataire'
Au prompt gpg, taper :
trust

Plusieurs niveau de confiance vous sont proposés, sélectionnez 5 par exemple, puis quit pour quitter gpg. Maintenant vous ne devriez plus avoir le message d'erreur, lors de l'utilisation de la clé de cet utilisateur

Mise à jour :
– Passage dans la catégorie Sécurité (27.05.2008)
– Ajout d'un commentaire pour faire confiance à une clé (29.12.2008)

Installation de stunnel4

michael — 2008-02-02T21:40:29Z

Mise en place du ssl sur un protocole ne supportant pas nativement le ssl (pop, smtp, imap, vnc...). Les explications données ci-dessous permettent de créer un tunnel ssl grâce à stunnel.

Le tutoriel monte un tunnel ssl avec échange de clés publiques. Si le serveur n'a pas la clé publique du client celui ci n'acceptera pas la connexion, même si le client a la clé publique du serveur. Et inversement, si le serveur a la clé publique du client mais que le client n'a pas la clé publique du serveur, la connexion sera refusée aussi. Chaque partie doit avoir la clé publique de l'autre. Aucun échange automatique n'est effectué.

L'exemple est de "ssliser" un serveur telnet. Je suppose que le serveur telnet est installé.

On peut tout à fait ssliser tout autre serveur, la seule contrainte est que le serveur soit en TCP. Par contre, le ftp ne peux pas être "sslisé" avec cette méthode. Voir le man de stunnel pour plus d'info.

L'installation a été testée sous Debian avec la version 4.21 de stunnel. Cela devrait fonctionner avec d'autres distributions.

I - Pré-requis

Installation des packages nécessaires

aptitude install stunnel4 openssl

Mise en place de l'arborescence

Nous stockerons notre clef privée et notre certificat public dans /var/lib/stunnel4/. Les certificats publics reçus, dans /var/lib/stunnel4/certs/

mkdir -p /var/lib/stunnel4/certs chown stunnel4:stunnel4 /var/lib/stunnel4/certs

Sauvegarde du fichier exemple de stunnel

cd /etc/stunnel mv stunnel.conf stunnel.conf.example

Autoriser stunnel à démarrer, pour ce faire éditer /etc/default/stunnel4 et modifier ENABLED=0 par ENABLED=1

L'installation est divisée en deux parties :
Si vous êtes le serveur suivez le tuto ici.
Si vous êtes le client suivez le tuto ici

++++

II - Serveur

Se placer dans le répertoire qui contiendra notre clé privée

cd /var/lib/stunnel4/

2.1 - Génération de la clé

La clé sera valable 1 an. Si vous vous voulez générer une clé sans durée de validité mettre -days 0

openssl req -newkey rsa:2048 -x509 -nodes -days 365 -out stunnel-serveur.pem -keyout stunnel-serveur.pem

(Pour laisser en blanc les demandes d'infos mettre un . (point), le code pays est obligatoire)

Changement des droits et du propriétaire sur la clé

chmod 600 stunnel-serveur.pem chown stunnel4:stunnel4 stunnel-serveur.pem

Génération du paramètre DH

dd if=/dev/urandom count=2 | openssl dhparam -rand - 512 >> stunnel-serveur.pem

Création du certificat public

openssl x509 -in stunnel-serveur.pem -out stunnel-serveur.cert chown stunnel4:stunnel4 stunnel-serveur.cert

Vous devez maintenant envoyer votre certificat public stunnel-serveur.cert à vos clients par tous moyens à votre convenance.

A la réception du certificat de vos clients, les copier dans /var/lib/stunnel4/certs/

cd /var/lib/stunnel4/certs/ chown stunnel4:stunnel4 stunnel-client.cert

Vous pouvez renommer le certificat pour plus de lisibilité dans votre répertoire /var/lib/stunnel4/certs/ surtout si vous stockez beaucoup de certificats.

mv stunnel-client.cert client-tintin.cert

Création d'un lien symbolique sur notre fichier

Le lien symbolique est obligatoire pour que les certificats puissent être vu par stunnel.

ln -s client-tintin.cert openssl x509 -hash -noout -in client-tintin.cert.0

2.2 - Configuration

Création du fichier de configuration. Pour plus de simplicité, le fichier de configuration, porte le nom du service que je vais mettre à disposition. La seule contrainte est qu'il doit être dans /etc/stunnel/ et qu'il est l'extension .conf

cd /etc/stunnel/ vi telnet-serveur.conf

copier le contenu suivant dans telnet-serveur.conf

cert = /var/lib/stunnel4/stunnel-serveur.pem RNDfile = /dev/urandom chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 3 CApath = /certs ; Si vous souhaitez disposer de log, décommentez les 2 lignes ;debug = 7 ;output = /var/log/stunnel4/stunnel.log [telnet-ssl] accept = 2023 connect = 23

Vous pouvez aussi récupérer le même fichier de conf ici. Pour l'installer faites ceci :

cd /etc/stunnel/ wget http://vdrbox.lautre.net/fichiers/stunnel4/telnet-serveur.conf

Changement des droits sur le fichier telnet-serveur.conf

chown stunnel4:stunnel4 telnet-serveur.conf

Vous pouvez maintenant démarrer stunnel :

/etc/init.d/stunnel4 start

Si vous êtes derrière un routeur pensez à ouvrir le port spécifié à la ligne accept. Dans mon cas, le port 2023 devra être redirigé sur la machine hébergeant stunnel

Conclusion

++++

III - Client

Se placer dans le répertoire qui contiendra notre clé privée

cd /var/lib/stunnel4/

3.1 - Génération de la clé

La clé sera valable 1 an. Si vous vous voulez générer une clé sans durée de validité mettre -days 0

openssl req -newkey rsa:2048 -x509 -nodes -days 365 -out stunnel-client.pem -keyout stunnel-client.pem

(Pour laisser en blanc les demandes d'infos mettre un . (point), le code pays est obligatoire)

Changement des droits et du propriétaire sur la clé

chmod 600 stunnel-client.pem chown stunnel4:stunnel4 stunnel-client.pem

Génération du paramètre DH

dd if=/dev/urandom count=2 | openssl dhparam -rand - 512 >> stunnel-client.pem

Création du certificat public

openssl x509 -in stunnel-client.pem -out stunnel-client.cert chown stunnel4:stunnel4 stunnel-client.cert

Vous devez maintenant envoyer votre certificat public stunnel-client.cert à votre serveur par tous moyens à votre convenance.

A la réception du certificat du serveur, le copier dans /var/lib/stunnel4/certs/

cd /var/lib/stunnel4/certs/ chown stunnel4:stunnel4 stunnel-serveur.cert

Vous pouvez renommer le certificat pour plus de lisibilité dans votre répertoire /var/lib/stunnel4/certs/ surtout si vous stockez beaucoup de certificats.

mv stunnel-serveur.cert serveur-tartampillon.cert

Création d'un lien symbolique sur notre fichier

Le lien symbolique est obligatoire pour que les certificats puissent être vu par stunnel.

ln -s serveur-tartampillon.cert openssl x509 -hash -noout -in serveur-tartampillon.cert.0

3.2 - Configuration

cd /etc/stunnel/ vi telnet-client.conf

cert = /var/lib/stunnel4/stunnel-client.pem RNDfile = /dev/urandom chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 3 CApath = /certs ; Si vous souhaitez disposer de log, décommentez les 2 lignes ;debug = 7 ;output = /var/log/stunnel4/stunnel.log client = yes [telnet-ssl] accept = 127.0.0.1:4023 connect = hostnameserveur:2023

Vous pouvez aussi récupérer le même fichier de conf ici.

Pour l'installer faites ceci :

cd /etc/stunnel/ wget http://vdrbox.lautre.net/fichiers/stunnel4/telnet-client.conf

Changement des droits sur le fichier telnet-client.conf

chown stunnel4:stunnel4 telnet-client.conf

Il sera nécessaire de modifier le hostnameserveur par le nom DNS du serveur ou par son adresse IP.

Vous pouvez maintenant démarrer stunnel :

/etc/init.d/stunnel4 start

et vous connectez au serveur telnet en utilisant stunnel :

telnet 127.0.0.1 4023

Conclusion

++++

IV - Conclusion

Un fichier de conf stunnel légèrement documenté est disponible ici. Voir aussi le man de stunnel

man stunnel4

Voici un petit schéma de la transaction sans stunnel, toujours avec notre exemple de client/serveur telnet. Entre parenthèses est indiqué le port de la transaction.

En rouge : Transaction Internet

Client telnet (23) <—> Flux non chiffré <—> Serveur telnet (23)

On voit donc que les transactions entre le client et le serveur ne sont pas chiffrées et qu'une personne peut sniffer la transaction et ainsi récupérer le mot de passe.

La transaction avec stunnel.

Client telnet (23) <—> Flux non chiffré <—> (23) stunnel client (2023) <—> Flux chiffré <—> (2023) stunnel serveur (23) <—> Flux non chiffré <—> Serveur telnet (23)

A présent seul la partie en réseau local est non chiffrée. Si stunnel et le serveur (ou le client) tourne sur la même machine, cela reste en localhost donc aucun risque. La partie la plus exposée, (Internet) est maintenant chiffrée grâce à stunnel.

V - Remerciements

Merci à eRen pour ses tests et son aide à la rédaction du tuto.
Merci à un anonyme pour ses tests et les corrections.

Mise à jour :
– Changement d'hébergeur (08.05.2008)
– Divers corrections (16.07.2008)
– Changement typographie (20.12.2008)
– Corrections des liens interne (21.12.2008)

Installation d'un serveur SFTP chrooté

michael — 2007-05-31T10:17:29Z

Installation d'un serveur SFTP dans un environnement chrooté grâce à MySecureShell

Le SFTP est une amélioration du FTP. C'est un protocole de communication fonctionnant au-dessus de SSH pour transférer et gérer des fichiers à distance. Definition Wikipedia

Installation des packages nécessaires

aptitude install openssh-client openssh-server

Je n'aborderai pas la configuration de openssh-server. Des liens existent sur Internet pour une configuration plus fine.

Je reviendrai juste sur la configuration de la variable PermitRootLogin du fichier /etc/ssh/sshd_config qui est par défaut à Yes. Je conseille de la mettre à No pour eviter les attaques par brute force. Apres avoir changé cette variable, redémarrer SSH.

/etc/init.d/sshd restart

Installation de MySecureShell

La dernière version disponible lors de la rédaction est la 0.95

cd /usr/local/src wget http://freefr.dl.sourceforge.net/sourceforge/mysecureshell/mysecureshell_debian_1.15.i386.deb dpkg -i mysecureshell_debian_1.15.i386.deb

Télécharger sftp_config (générique)

wget http://vdrbox.lautre.net/fichiers/Debian/ssh/sftp_config mv sftp_config /etc/ssh/

Vérification de la bonne installation

Pour vérifier et corriger d"éventuels problèmes avec MySecureShell, on utilise la commande sftp-verif. On la lancera maintenant pour verifier que tout est bien initialisé.

sftp-verif

S'il y a des Failed, veuillez répondre "y" pour que l'erreur soit corrigé.

Relance de MySecureShell

/etc/init.d/mysecureshell start

Configuration de MySecureShell

Si vous avez déjà créé vos utilisateurs pour lesquels vous voulez une connexion SFTP chrooté, il faut modifier leur shell dans /etc/passwd

test:x:1006:500:test:/home/test:/bin/sh

Remplacer "/bin/sh" (ou un autre shell tel que /bin/bash), par /bin/MySecureShell, votre nouvelle ligne devrait ressembler à ceci :

test:x:1006:500:test:/home/test:/bin/MySecureShell

Création d'un utilisateur avec le shell chrooté pour SFTP

adduser test --shell /bin/MySecureShell

Veuillez répondre ensuite aux questions habituelles lors de la création d'un user.

Nous allons définir un utilisateur Admin de MySecureShell, celui-ci aura les droits de modifié la configuration via MSS Graphical Tool qui est une application Java. Elle peux tourner sur toutes les plateformes, il suffit seulement d'avoir JAVA d'installé.

Création de notre user admin

adduser admin-mysecure --shell /bin/MySecureShell

Editer /etc/ssh/sftp_config et rajouté les lignes suivantes juste après .

IsAdmin true
VirtualChroot false

Après avoir ajouté ses lignes, veuillez relancé mysecureshell

/etc/init.d/mysecureshell restart

Vous pouvez lancer MSS Graphical Tool, pour configurer MySecureShell via l'interface graphique.

Signification des différentes directives du fichier sftp_config -> http://mysecureshell.sourceforge.ne...

Liens utiles :
– MySecureShell
– Forum MySecureShell
– MSS Graphical Tool
– Manuel
– Directives

Mise à jour :
– Nouvelle version de MySecureShell (1.15) (21.03.2009)