electro575 a écrit 832 commentaires

Si les disques sont alimentés en externe, il ne devrait pas y avoir de problème je pense.

A voir avec l'utilisation de rsync. Je n'utilise pas le hdmi

Résultat d'un petit Wireshark.

Les ports que je peux ouvrir dans mon firewall sont les suivants :
53
443

Les ports qui sont utilisés aléatoirement :
35260
49008

Les IP :
10.0.0.1
10.0.0.3
2.18.117.197

=> Comment autoriser les ports d'entrées utilisés aléatoirement en sortie ? avec les états RELATED,ESTABLISHED

En complément à cela,

J'ai lancé la commande suivante :

ss -nltp

LISTEN   0   5 :::443   :::*   users:(("certbot",pid=3437,fd=8))

A ce qu'on m'a dit c'est de l'ipv6 :::443

Je vous recopie mon pare feu ipv4 avec iptables-persistant (j'ai créé l'exception pour le port 443 tout de même, … je ne comprend pas)

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [13:1456]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4448 -j ACCEPT

#-A OUTPUT -p udp --dport 53 -j ACCEPT
#-A OUTPUT -p tcp --dport 21 -j ACCEPT
#-A OUTPUT -p tcp --dport 80 -j ACCEPT

#-A INPUT -p udp --dport 53 -j ACCEPT
#-A INPUT -p tcp --dport 21 -j ACCEPT
#-A INPUT -p tcp --dport 80 -j ACCEPT

-A INPUT -p tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

#-A OUTPUT -p tcp -m multiport --dports 80,443,8000 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
#-A INPUT -p tcp -m multiport --sports 80,443,8000 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 5222 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5280 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5281 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -p icmp -j ACCEPT

Enfin voila, avec mon pare feu certbot ne fonctionne pas (toujours la même erreur), même un aptitude install en fonctionne pas !

En effet serveur1.fr n'est pas nom de domaine.

Par contre, j'ai remarqué qu'en supprimant les règles de mon part-feu de ma raspberry et avec les ports 443 & 80 ouvert de ma box redirigé vers la raspberry, j'ai réussi à générer un certificat -> plus d'erreur.

Pourtant j'avais bien ajouté les exceptions au port 443 et 80 en INPUT, qu'est-ce que je devrais ajouter en plus comme exception à mon part-feu ?

Voici les règles concernant le port 443 et 80 :

# Certificat (Prosody)
/sbin/iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
/sbin/iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT

root@raspberrypi:/home/pi# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:4448
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-server state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5280 state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5281 state NEW,RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere

Je ne vois pas ce qui peut pauser problème. Qu'est-ce que je dois ajouter comme exception pour que la commande suivante se fasse sans erreur du port 443 : certbot certonly -d serveur1.fr !?

Merci d'avance

Merci pour vos remarques.

J'ai retenté la commande ce matin. J'ai redirigé le port box 443 vers 443 (ou autre du service XMPP) de la pi et idem pour le 80 mais rien n'y fait, j'ai toujours la même erreur (26/12/17 à 19:11) en lançant l'une des deux commandes :

certbot renew --deploy-hook "prosodyctl --root cert import /etc/letsencrypt/live"

certbot renew --dry-run

Effectivement mais je ne vois pas pourquoi je n'arrive pas à en créer ! Il faut que le port 443 soit ouvert ?

Egalement avec la commande qui va bien est-ce que le certificat sera auto-signé => en gros ai-je besoin de le transférer manuellement sur les téléphones ou alors le certificat sera proposé automatiquement ?

Merci

Voici l'erreur que j'ai en ce moment, je pense que c'est parce que je n'ai pas ouvert le port 443 sur ma box mais ouvert sur ma pi.

root@raspberrypi:/home/pi# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/serveur1.fr.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Attempting to renew cert (serveur1.fr) from /etc/letsencrypt/renewal/serveur1.fr.conf produced an unexpected error: HTTPSConnectionPool(host='acme-staging.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x76a50af0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',)). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/serveur1.fr/fullchain.pem (failure)

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/serveur1.fr/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
-------------------------------------------------------------------------------
1 renew failure(s), 0 parse failure(s)

A priori la raison est parce que le certificat créé n'est pas créé par une autorité.

Par quel organisation passer pour créer mon certificat ?

Lien chat secure : https://chatsecure.org/blog/page3/

Actuellement,

1°) oui configurer fail2ban

ssh : OK via fail2ban

sftp : IP non banni si trop de tentatives

xmpp : analyser les logs xmpp

2°) fail2ban avec script d'envoie de mail si IP banni
Si 1°) -> OK pas besoin du 2°)

3°) gérer les IP, non nécessaire si 1°) mis en place.
Nécessaire si changement IP & hacker
->

4°) Cas de figure si trop d'essai via plusieurs machines dans la même journée

Bonne feuille de route, merci

Bonjour,

Tu peux aller regarder dans les logs, syslog peut être pour te renseigner.

Oui merci à vous deux

J'ai fait la mise à jour hier.

Tout c'est bien passé, je l'ai fait depuis ssh de mon pc portable.

Par contre, comment je peux récupérer tous le flux qui est passé dans mon terminal ?

Cette commande n'a pas fonctionné :

apt-get dist-upgrade > sortie.txt

Ha okey merci.

Je vais voir ça ce soir.

Bon je vais rester en mode simple sur xfce4.

Je te remercie.

Bonne soirée.

Merci

Oui, et donc est-ce qu'on remet juste les fichiers de configs pour les avoirs à nouveau ?

Soit disant qu'ils disparaissent avec la mise à niveau ! ?

Faut-il désinstaller les paquets avant d'effectuer une mise à jour ?

Bon il y a quelques points obscures encore du manuel pour moi sans avoir pratiqué une mise à niveau. mais quand faut y aller faut y aller.

De mon côté j'ai écris ceci :

I-SAUVEGARDES

1-Complète : Ghost Clonezilla du système

2-Sauvegardes principales :

/etc
/var/lib/dpkg
/var/lib/apt/extended_states
dpkg --get-selections "*" > $HOME/sortie.out

si utilisation de aptitude
/var/lib/aptitude/pkgstates

$HOME

3-Les fichiers de configuration des logiciels

???

II-ETAT DU SYSTEME

1-Lister les paquets installés

aptitude search '~i(!~ODebian)'
apt-forktracer | sort

-Vérifier les actions en cours sur les paquets

vous devez lancer aptitude en mode terminal complet et appuyer sur g (« Go »), … voit site

3-Désactiver l'épinglage APT

Si vous avez configuré APT pour installer certains paquets d'une distribution autre que stable (par exemple, de testing), … voir site

4-Vérifier l'état des paquets

Tous les paquets qui sont dans l'état « Half-Installed » ou « Failed-Config », ainsi que ceux qui sont dans un état d'erreur :

dpkg –audit

5-Vérifier si des sources stretch pour des paquets non-officiels

III-PREPARER LA MISE A NIVEAU

1-Modifier le /etc/apt/source.list

Modifier jessie vers stretch

2-Mise en place « script maj_debian_jessie2stretch.log »

script -t 2>~/upgrade-stretchetape.time -a ~/upgrade-stretchetape.script

3-Se connecter à la machine à upgrade via SSH

ssh user@192.168.X.X

4-Télécharger les sources stretch

apt-get update

5-Mise à jour minimale du système

apt-get upgrade

=> on peut observer si les paquets sont toujours présent.

6-Mise à jour complète du système

apt-get dist-upgrade

---

Il y a t-il besoin d'upgrade avec aptitude également ?

1°) la sauvegarde

Il était écrit dans le manuel officiel que l'upgrade va supprimer des fichiers de mise à jour.

Il suffi de sauvegarder le /etc et de le remettre après la mise à jour pour retrouver la conf des logiciels ?

Idem pour le /home/monuser ?

2°) l'upgrade

apt safe-upgrade te fait une liste des paquets qui vont subir une mise à jour ?

Merci pour l'historique de l'évolution.

3°) lister les paquets d'un distri

Est-il nécessaire de supprimer les paquets installés ou l'on peut les laisser en les surveillant avec apt safe-upgrade ?

En fait pour ristretto, si il ne peut pas envoyer l'image à la corbeille, il me met en erreur alors que Gthumb me propose la suppression définitive.

Gthumb est pas mal à priori

i3-wm remplace xfce4 non ?

Je ne vois pas comment le mettre en place sous xfce4.

Oui, merci pour ton aide.

Ha d'accord, bon ben si mon essai ne fonctionne pas !!!

J'ai trouvé hier cette liste de paramètres :
durable handles (S)
kernel oplocks (S)
kernel share modes (S)
level2 oplocks (S)
lock dir
lock directory
locking (S)
strict locking
lock spin time (G)
max connections (S)
oplocks *
posix locking (S)

Bon faut encore que je creuse

Je devrais essayer avec 2 users différents c'est vrai, ça serait déjà plus simple.

Éventuellement il y a cette doc moins à jour qui peut expliquer le principe de l'oplock :
http://www.oreilly.com/openbook/samba/book/ch05_05.html

C'est étrange que ce principe ne fonctionne que pour windows, pour linux ça ne s'appliquerait pas ?

Merci.

Je vais refaire une config minimale et agrémenter si besoin pour que windows puisse également fonctionner dessus.

Bonne journée.