pourquoi dans une DMZ: si jamais ton reverse proxy a un bug et donc le pirate a acces a ce serveur, il n’est pas capable d’ateindre les autres serveurs sur les ports de mgt tel que le ssh.
Oui, d’accord, mais il n’y a pas d’obligation.
Si il a accès au proxy inverse, il fait ce qu’il veut puisqu’il y a déjà des règles pour aller de la DMZ vers le LAN.
Si il a accès au proxy inverse, il fait ce qu’il veut puisqu’il y a déjà des règles pour aller de la DMZ vers le LAN.
Pas vrai, tu peux n’ouvrir que le port https et donc, limiter le risque. sur le même réseau, tous les ports sont ouverts sauf si tu as mis un FW sur le server même
il n’y a jamais d’obligation pour de la securité. Mais plus tu augmentes ta securité plus tu diminues le risque de te faire hacker.
tu ne sauras jamais être sur a 100% sauf si tu n’es pas conncté a internet.
De même, il faut que cela reste gérable. d’ou ma proposition pour PFsense. on est sur le FW, si celui-ci se fait hacké, les pirates ont accès a tout.
il faut aussi que la sécurité que l’on cherche a mettre en place soit bien gérée et configurée, cela ne sert a rien de créer des Vlan différents pour avoir une DMZ si l’on laisse tout ouvert au niveau FW…
et dernier point super important, cela doit etre compatible WAF
Si il a accès au proxy inverse, il peut changer les règles de redirection, donc rentrer avec le port 443 puis aller sur une autre machine avec le port qu’il souhaite.
dans le cas d’une DMZ, non. puisque le FW le bloquera. celui-ci n’autorise que le 443
c’est en gros, ce que fait le modune DNS de jeedom.
Salut,
Je pense que tout est dit, vis à vis de la DMZ. Plus on cloisonne et plus c’est difficile de passer chaque étape jusqu’au coeur de l’infrastructure
Pour un particulier, c’est pas aussi crutial que pour une banque par exemple. Il faut juste adapter la mesure fasse à ses coûts (fonctionnement et configuration/maintenance)…
Concernant les requêtes à filtrer qui sont moins nombreuses, fail2ban contient déjà une très longue liste de modèle set sauf à passer sa vie à scruter les logs en direct, il est vachement plus réactif qu’un humain.
2019-11-28 01:01:32,318 fail2ban.filter [411]: INFO [apache-noscript] Found 182.92.230.136 - 2019-11-28 01:01:32
2019-11-28 01:01:32,866 fail2ban.actions [411]: NOTICE [apache-noscript] Ban 182.92.230.136
Moi, réagir et créer la règle ipban en moins de 550ms, je sais pas faire …
Les meilleurs bots, passent 3 ou 4 requêtes avant d’être bloqués… Mais très souvent ils évitent de flooder les serveurs car trop voyant. La log n’est pas pleine de trucs inutiles.
C’est pas parfait mais à l’image de l’eau de javel, ça élimine 99%. J’apprendrais à vivre avec les 1% restants que je trouverai dans la log
Encore plus simple que la dmz complète, le RP en docker sur un réseau docker isolé. Il expose juste son port web admin et le HTTPS pour les reverse. Côté gestion/waf c’est le plus simple aujourd’hui
Parfaitement d’accord
Par contre l’image docker officielle de jeedom n’est pas des meilleurs… Prendre un docker pour s’en servir comme une VM (car basé sur une distrib complète), ça embraque 99% des trucs inutiles dans le container… C’est dommage.
1 « J'aime »
Oui pas faux, jeedom est le dernier service que j’héberge hors docker 
En plus avec le mode d’update qui touche parfois la dB, pas très compatible
2 « J'aime »
Bonjour,
Si on crée un fichier /etc/fail2ban/jail.local qui ne contient que ces infos là, il prend le pas sur l’autre (jail.conf) uniquement sur les paramètres du .local ?
En d’autre termes (en me relisant je ne me trouve pas clair moi-même 
), faut-il recopier la config complète dans le .local en faisant ses arrangements ou peut-on y mettre juste ce qu’on veut modifier ?
Salut,
Le .local complète le .conf ça évite de mélanger tes fichiers et ceux du package.
Il n’y a rien d’autre à mettre dedans que ce que j’ai copié (Il faut quand même regarder si les plages d’ip sont les bonnes, ainsi que le chemin/nom des logs à prendre en compte)
Pour moi encore plus simple, wireguard (VPN) sur le syno, juste un port UDP ouvert vers le syno.
Aucune attaque possible sur Jeedom qui n’est pas exposé et tout l’intégralité de mon LAN local est accessible via android ou PC même de l’étranger, et ce qui me permet également d’avoir une navigation internet plus fluide dans les pays merdiques.
Je pense pas qu’on puisse faire plus simple et plus sécurisé pour atteindre Jeedom et tout son réseau local sans avoir besoin de services type DNS externes ni de ports TCP ouverts pour atteindre tout ses équipements…
Wireguard existe aussi pour OPNsense et marche parfaitement bien, tout le réseau de ma boite et de certains de mes clients est accessible comme ça. Jamais eu d’attaque sur un port UDP exotique.
C’est de plus le VPN le plus rapide, sur mon syno avec 1Gbit de connexion internet j’ai 500Mb/s de debit dans les 2 sens, soit 10 fois plus que les VPN classiques.
Sur un serveur xéon là je suis à donf…
Et vu les clefs de certificats nécessaires des 2 côtés c’est un pas un hacker du dimanche qui pourra rentrer… Et même un pro aura du mal à essayer de passer sans se faire ban par le filtre IPS…
1 « J'aime »
C’est assez difficile en entreprise ou tu n’es pas administrateur de la machine « client » et que tu ne peux sortir qu’en http ou https.
Alors du coup vous conseillez quoi pour sécuriser. J’ai routeur RT AC68U declaré un DMZ dans la freebox. Celui ci n’emet pas de wifi. Ce routeur et relié a un RT AC88U en mode AP pour le wifi au Rez de chaussé
Chez Asus il y a le AIprotection mais je ne sais pas trop ce que ca vaut.
Pour acceder a jeedom j’utilise les DNS jeedom.
Comment feriez vous pour sécuriser ?
Relier mon ASUS a un service VPN ?
Merci pour vos conseils
Il me semble que tu peux déjà activer le vpn sur le Asus
oui mais quel VPN ? il faut choisir un service avec un abonnement ?
Non regarde tes option et après sur ton téléphone tu mets un client vpn
Mon ip publique ? 
Chez les nazis tu veux dire ? 
T’as au moins le mail aussi (IMAP, SMTP, POP) j’imagine soit potentiellement TCP (25, 110, 465, 587, 993)
Et aussi très souvent sur les réseau archi fermés, le port UDP 53 (servant à la résolution dns) est ouvert en sortant.
J’ai moi même mon serveur SIP dans un tunnel sur le TCP 443 pour être certain qu’il marche même dans les quelques rare hotels qui bloquent tout en sortant.