[résolu] Sécurisation pc perso...

numa · 01-11-2016 19:54:42

Tu peux aussi cacher ton port ssh-server avec un port knocking ; c'est sympa à mettre en place principalement sur un serveur dédié (type VPS). Derrière une box, il faut en plus rediriger toute une plage de ports vers ton serveur sinon tu perds tout l’intérêt de la manip.

Après, tu peux passer le "knock" avec un simple hping.

naguam · 01-11-2016 20:14:30

Excuse moi mais je n'ai pas tout compris, je ne suis pas avancé en réseau (meme si ça s'arrange) et je n'ai pas compris certains mots genre hping etc

numa · 01-11-2016 20:27:21

hping et un utilitaire, un peu comme nmap et qui permet de "forger" des paquets.

Pour le port-knocking je te laisse regarder les tutos sur le net mais en gros, ton port ssh n'est pas accessible tant que tu n'envoies pas une certaine combinaison réseau (une requète sur les ports 1000, 2000 et 3000 par exemple). Une fois la combinaison passée, iptables "ouvre la porte" vers ton port ssh. Après tu as un temps limité pour t'y connecter avant que la "porte" se referme.

naguam · 01-11-2016 20:28:28

Ok je vois.... Je me renseigne

Anonyme-7 · 02-11-2016 22:02:36

numa a écrit :

Pour le port-knocking je te laisse regarder les tutos sur le net mais en gros, ton port ssh n'est pas accessible tant que tu n'envoies pas une certaine combinaison réseau (une requète sur les ports 1000, 2000 et 3000 par exemple). Une fois la combinaison passée, iptables "ouvre la porte" vers ton port ssh. Après tu as un temps limité pour t'y connecter avant que la "porte" se referme.

Aucun intêret dans une sécurité sérieusement construite. Le Port Knocking est une configuration courante et rassure que celui qui y croit. Nmap par exemple trouvera le port filtré comme suit: Open|filtered SSH. Résultat zéro, le filtered indique que le port est filtré, toc-toc, qui est là , attends, je vais voir. L'attaquant sait qu'un service est en écoute derrière. S'il veut s'attaquer à ton serveur, avec un Snifer, il écoute et il récupère la séquence du port knocking très simplement.

Continuez à jouer mais soyez conscients que le web ne prodigue pas que des bons conseils, loin de là. Une lecture sérieuse sur le sujet est conseillée. De bons bouquins existent !
Un pare-feu filtre mais ne sécurise rien...! Nada, peanuts !
Et l'on s'étonne que Yahoo se fasse dérober des données... http://www.lefigaro.fr/secteur/high-tec … -voles.php
Allez, avouez, vous travaillez chez Yahoo .
Une sécurité est simple, basée sur la simplicité. Une clé SSH avec chiffrement asymétrique ou symétrique vaut largement votre pare-feu pour une connexion SSH.
https://openclassrooms.com/courses/repr … e-avec-ssh

Dernière modification par Anonyme-7 (02-11-2016 22:09:58)

naguam · 02-11-2016 22:07:54

Bah mon but est juste de cloîtrer mon pc portabe sur lequel il n'y a aucun port en "LISTEN" (netstat -paunt | grep LISTEN)
Et sinon, la seule machine qui me permet le ssh depuis l'extérieur a seulement un port ouvert, le port 6666 en local et 5555 depuis l'extérieur (le passage du port 5555 de l'extérieur au 6666 en local se fait par le NAT/PAT) et je vais lui mettre une authentification par clef et non plus par password.

Donc il ne me reste plus qu'a cloîtrer mon pc portable qui n'a aucun port en "LISTEN" (netstat -paunt | grep LISTEN) (avec un firewall)

Dernière modification par naguam (02-11-2016 22:10:49)

Anonyme-7 · 02-11-2016 22:15:37

Bah mon but est juste de cloîtrer mon pc portabe sur lequel il n'y a aucun port en "LISTEN" (netstat -paunt | grep LISTEN)

No comprendo amigo ! Cloitrer une machine qui n'a pas de processus en écoute, heu... Je t'invite à lire le tuto de openclassrooms en lien dans mon précédent message.
Bonne suite.

naguam · 02-11-2016 22:33:52

Je sais que normalement, tout ports fermés, c'est une machine sécurisée, mais je voulais savoir si il existe des trucs en plus pour sécuriser au max.

Et d'ailleurs, juste pour savoir faire, changer d'adresse mac avec macchanger a chaque démarrages.

Anonyme-7 · 02-11-2016 22:52:58

Je sais que normalement, tout ports fermés, c'est une machine sécurisée, mais je voulais savoir si il existe des trucs en plus pour sécuriser au max.

Oublies la notion ouvert | fermé en tant que telle !
Un processus en écoute ouvre un port, c'est un logiciel serveur (web, ssh etc). Sur ton ordinateur de bureau (Gnu/Linux), aucune application écoute sur le réseau extérieur (Internet) par défaut, ta machine n'est pas joignable, la tentative de connexion sera rejetée par le kernel car aucun logiciel à de processus en écoute. Aucun logiciel n'est là pour répondre, le paquet est détruit purement et simplement.

Tito@Tito:~$ telnet localhost 80

Trying ::1...

Trying 127.0.0.1...

telnet: Unable to connect to remote host: Connection refused

Tito@Tito:~$ telnet localhost 139

Trying ::1...

Trying 127.0.0.1...

telnet: Unable to connect to remote host: Connection refused

Tito@Tito:~$ telnet localhost 145

Trying ::1...

Trying 127.0.0.1...

telnet: Unable to connect to remote host: Connection refused

Debian jessie, XFCE. Il n'y a que Cups qui écoute sur le réseau local, ça c'est normal, ce n'est pas une faille (imprimante réseau)
Après, si tu installes un service (processus), il ouvra un port :

Tito@Tito:~$ telnet debian-facile.org 80

Trying 2001:41d0:52:f00::354...

Connected to debian-facile.org.

Connection closed by foreign host.

Ça c'est le fonctionnement normal. Mettre un pare-feu sur un service en écoute est purement illogique. Le service doit être joignable pour faire son taf...
Pour sécuriser au max comme tu dis, apprends comment fonctionne ton OS, le protocole TCP/IP, etc etc et tu verras que le pare-feu ne sert à rien pour la sécurité mais qu'il est beaucoup plus utile pour les usages précités dans un autre post. La gestion QoS, passerelle, routeur etc etc...

Dernière modification par Anonyme-7 (02-11-2016 22:59:19)

naguam · 02-11-2016 22:58:39

Si j'ai tout compris maintenant et je connais bien mon os sauf niveau réseau et sachant que les ports sont valable dans touts les os...
Tu as l'air d'être agressif alors que je tente de comprendre (ce qui est fait) ce n'est pas très encourageant sur un forum sur lequel les débutants apprennent à force d'être confronté aux cas... Bref
Sinon merci pour l'explication je passe en résolu, j'ai compris bce que je devais savoir.

Dernière modification par naguam (02-11-2016 22:59:25)

Anonyme-7 · 02-11-2016 23:03:09

Agressif ? Non. Mais les légendes urbaines ont la vie dure

Bonne route à toi, mon ami.
Regarde, je t'aime moi, c'est toi qui ne m'aime pas

Dernière modification par Anonyme-7 (02-11-2016 23:04:21)

numa · 02-11-2016 23:35:23

Tito a écrit :

Le Port Knocking est une configuration courante

J'en ai pas l'impression car il faut bien reconnaitre que son utilisation est relativement fastidieuse.

Tito a écrit :

Nmap par exemple trouvera le port filtré comme suit: Open|filtered SSH. Résultat zéro, le filtered indique que le port est filtré, toc-toc, qui est là ,

Au contraire, le port knocking masque le port SSH en écoute ; je vois mal comment nmap pourrait détecter un serveur ssh en écoute sur un port aléatoire bloqué par un pare-feu qui, par définition, ne laissera passer aucune requête à destination ou en provenance de ce port tant que la séquence de knock n'aura pas était initiée.

Tito a écrit :

S'il veut s'attaquer à ton serveur, avec un Snifer, il écoute et il récupère la séquence du port knocking très simplement.

Oui à condition d'avoir accès au réseau, soit physiquement, soit via une machine corrompue. Tu ne lances pas un Snif réseau sans une préparation en amont.

Tito a écrit :

Continuez à jouer mais soyez conscients que le web ne prodigue pas que des bons conseils, loin de là. Une lecture sérieuse sur le sujet est conseillée. De bons bouquins existent !

Je suis entièrement d'accord sur ce point lol

Tito a écrit :

Un pare-feu filtre mais ne sécurise rien...! Nada, peanuts !

Là on rejoint le point précédent ^^ Quand on voit le prix d'un pare-feu type Stromshield, cisco, ... ça serait bien malheureux qu'il ne serve à rien.
Une pare-feu est un filtre réseau, ni plus, ni moins. Il est compétent dans son domaine de compétence.
Par exemple, je vois mal comment mettre en place une DMZ sans pare-feu...

Tito a écrit :

Une sécurité est simple, basée sur la simplicité. Une clé SSH avec chiffrement asymétrique ou symétrique vaut largement votre pare-feu pour une connexion SSH.

Il faut comparer ce qui est comparable ; l'un ne signifie pas qu'il faille se passer de l'autre. Tout comme ajouter un Fail2ban pour se prémunir d'un brute force sur ton SSH, un Portsentry pour les scans réseaux et autres IDS ou IPS... Il en va de même pour l'utilité d'un serveur de mises à jours ou de la mise en place d'un proxy ; chaque brique sécurise la partie qui lui incombe.
Baser sa sécurité uniquement sur une clé SSH c'est avoir une bien grande confiance dans le support qui la contient. Quelqu'un qui pourra lancer un scan réseau sur ton LAN ne devrait pas avoir trop de mal (à terme) à se procurer ta clé privée.

Dans tous les cas, rien ne pourra arrêter une attaque ciblée...

Dernière modification par numa (03-11-2016 00:09:34)

Anonyme-7 · 03-11-2016 14:39:06

Salut, une réponse rapide pour clore ma participation à ce thread

J'en ai pas l'impression car il faut bien reconnaitre que son utilisation est relativement fastidieuse.

Dans le milieu professionnel, si, même très répandu mais pas sur le serveur SSH de madame Michu, il est vrai. Mais de quoi parle-t-on au juste ?

Au contraire, le port knocking masque le port SSH en écoute ; je vois mal comment nmap pourrait détecter un serveur ssh en écoute sur un port aléatoire bloqué par un pare-feu qui, par définition, ne laissera passer aucune requête à destination ou en provenance de ce port tant que la séquence de knock n'aura pas était initiée.
Là on rejoint le point précédent ^^ Quand on voit le prix d'un pare-feu type Stromshield, cisco, ... ça serait bien malheureux qu'il ne serve à rien.

Issue de la doc Nmap , concernant les flags: FIN, PSH et URG, si un RST est reçu, le port est considéré comme étant fermé, tandis qu'une absence de réponse signifiera qu'il est dans l'état ouvert|filtré. Le port est marqué comme filtré si un message d'erreur ICMP « unreachable (type 3, code 1, 2, 3, 9, 10 ou 13) » est reçu. L'avantage principal de ces types de scans est qu'ils peuvent furtivement traverser certains pare-feux ou routeurs filtrants sans état de connexion (non-statefull).
Et encore Nmap est un outil gentil, il existe des choses codées en pearl ou python bien plus performantes. Certains outils permettent même de concevoir soi-même ses propres exploits en fonction d'un audit. Sans parler des failles dans les firmwares dudit routeur, bref...

ÉDIT: je n'interviendrai plus sur ce fil, je ne peux que suggérer de s'intéresser au protocole tcp/ip dont la norme RFC 793 entre autre. De bon bouquins existent sur le sujet, sur la sécurité aussi. C'est un domaine ou je ne suis pas novice. Si vous vous sentez en sécurité derrière vos IDS, pare-feu, je ne peux que vous conseillez de continuer comme ça...!
http://abcdrfc.free.fr/rfc-vf/rfc0793.html

Dernière modification par Anonyme-7 (03-11-2016 15:05:14)

numa · 03-11-2016 16:34:18

Tito a écrit :

Issue de la doc Nmap , concernant les FIN, PSH et URG, si un RST est reçu, le port est considéré comme étant fermé, tandis qu'une absence de réponse signifiera qu'il est dans l'état ouvert|filtré. Le port est marqué comme filtré si un message d'erreur ICMP « unreachable (type 3, code 1, 2, 3, 9, 10 ou 13) » est reçu. L'avantage principal de ces types de scans est qu'ils peuvent furtivement traverser certains pare-feux ou routeurs filtrants sans état de connexion (non-statefull).
Et encore Nmap est un outil gentil, il existe des choses codées en pearl ou python bien plus performantes. Certains outils permettent même de concevoir soi-même ses propres exploits. Sans parler des failles dans les firmwares dudit routeur, bref...

Tito a écrit :

Mais de quoi parle-t-on au juste ?

Honnêtement et je dis ça sans méchanceté, c'est bien joli de vouloir étaler ses connaissances mais il faut garder un minimum de cohérence. Qui a dit qu'on parlait de pare-feu stateless ? C'est sûr que dans ces conditions, un pare-feu (peut-on encore parler de pare-feu ?) ne servira pas à grand chose.
Ton nmap ne détectera pas plus un service ssh en écoute derrière un port 5555 "caché" par un port knocking et netfilter qu'aucun service en écoute derrière un autre port aléatoire. Ton nmap détectera au mieux que tu as un parefeu sur ta station. Les requètes ne passeront pas ton netfilter ; ton nmap ne recevras donc ni SYN/ACK, ni RST, ... il ne recevra simplement rien quelque soit le port scanné.

Je passe sur la partie exploitation de vulns qui n'enlève rien à l'utilité d'un pare-feu.

Tito a écrit :

Bien sûr. Une clé cryptée représente le meilleur moyen actuel pour éviter une authentification et décrypter le contenu de la connexion quand elle est établit.

C'est entendu mais en quoi cela dispense-t-il de mettre en place un filtrage réseau ?

Tito a écrit :

Encore une fois si tu ne maîtrise pas SSH, ne l'installe pas, c'est plus simple.

naguam a écrit :

Tu as l'air d'être agressif alors que je tente de comprendre (ce qui est fait) ce n'est pas très encourageant...

Tout comme naguam, je te trouve aussi agressif lol

Personnellement je n'utilise pas de clé d'authentif car je trouve ça lourd au quotidien : il faut se trimballer la clé sur support amovible en permanence, ce qui induit d'avoir un sauvegarde sur un autre support amovible au cas où le premier viendrait à cramer ou (plus probable) au cas où on viendrait à perdre la clé. Bien entendu, on ne garde pas cette clé d'authentif sur une station car le jour où la machine est compromise (ou qu'on se la fait tirer), adieux la clé. Tu ne diras, y'a toujours la passphrase... oui, y'a toujours la passphrase.
Mais effectivement, c'est ce qu'il y a de mieux en terme d'authentif ssh.

Tito a écrit :

Perso, mon serveur est en ligne sans IDS, pare-feu et tout gadget. J'ai besoin de SSH parfois, il est en ligne est parfaitement accessible. Jusqu'à ce jour, mes logs sont vierges. Il est scanné régulièrement, je m'en balance mais personne n'a à ce jour pu décrypter ma clé SSH.

La majeure partie des scans se contentent de scanner le port 22, voire (mais c'est plus rare) le port 2222. Les logins tentés sont principalement "root", "admin" et "support" associés à des attaques par dictionnaires (enfin, c'est ce que j'ai constaté sur plusieurs mois de logs sur un Honeypot). En supprimant ces variables, en choisissant un mot de passe un minimum robuste et en mettant en place un Fail2ban, tu sécurises déjà grandement ta connexion. Après, personne n'est à l’abri d'un MITM mais il faut déjà tomber dessus et avoir quelqu'un qui sait l'exploiter en face.

Tito a écrit :

C'est un domaine ou je ne suis pa s novice

Je pense aussi avoir quelques connaissances...

Tito a écrit :

j'ai exercé la fonction de responsable réseau pendant 10ans sur Gnu/Linux et FreeBsd....

J'exerce aussi mais pas comme "responsable" ça doit venir de là.

Tito a écrit :

Si vous vous sentez en sécurité derrière vos IDS, pare-feu, je ne peux que vous conseillez de continuer comme ça...!

Je suis aussi adepte du KISS mais pas au point de tout baser sur un mode d'authentif, enfin si tu te sens en sécurité derrière ta clé ssh, je ne peux que te conseiller de continuer comme ça... !

Dernière modification par numa (03-11-2016 20:06:40)

naguam · 03-11-2016 19:54:34

Donc du coup de fais quoi finalement, clef ssh? Firewall? (filtrage ou fail2ban) (mettre un place un système qui banni des adresses mac?)
D'ailleurs, je tatte toujours niveau changement mac a chaques démarrages niveau portable. (J'ai pas envie que un tel sache que j'ai tel pc (ou plutôt carte wifi) sur la wifi public macdo en regardant les adresse mac qui se sont connectées.

numa · 03-11-2016 21:42:47

Tito n'a pas tort quand il dit qu'avant de mettre en place des mécanismes de sécu réseau, il peut être bon de comprendre comment marche un réseau et à quoi servent réellement ces mécanismes.
Ceci étant, attaquer directement avec une RFC peut être vite démoralisant. Va faire un tour sur openclassrooms, juste pour reprendre les bases et tout devrait te sembler plus clair après.

Par exemple, toi qui semble attacher beaucoup d'importance à ton adresse Mac, ce genre de cours pourrait-être utile :
http://www.it-connect.fr/quest-ce-que-larp/

Sinon, pour ce qui est de la clé ssh et du pare-feu, je dirais forcément les deux. Si l'utilisation au quotidien d'un clé te semble galère, reste sur un accès par mot de passe et ajoute un fail2ban (ça ne te dispense pas de bien configurer ton serveur ssh) ; fail2ban va se contenter d'implémenter tes règles de filtrage avec les Ip d'éventuels attaquants (je résume lol).

Enfin, pour ce qui est du hacker à capuche au MacDo et à moins de tomber sur quelqu'un qui t'en veut personnellement et qui va ensuite te suivre jusque chez toi pour tenter de pénétrer ton LAN (si tu bosses à la nasa je dis pas mais sinon y'a peu de chances), le fait de changer d'@Mac à chaque démarrage ne te donnera rien.
Le risque principal dans ce genre de réseau ouvert est une attaque de type arp-spoofing ; d’où mon lien vers "qu'est-ce que l'arp"

Mais c'est déjà bien de poser la question, c'est en forgeant (des paquets) que l'on devient forgeron ^^

Après, c'est tellement vaste...

Dernière modification par numa (03-11-2016 22:17:18)

naguam · 03-11-2016 21:51:17

Merci beacoup des précisions, je me renseigne sur le réseau, (j'ai commandé le livre papier sur les protocoles tcp/ip "j'ai déjà celui de reprendre le contôle avec l'aide de linux et celui sur la programmation en c)
Cette fois ci je repasse vraiment en résolu

mizapar · 03-11-2016 21:55:08

bon, ok je suis noyer sous les termes, de vu je pense que mon site a du soucis a se faire.

mais bon je vous laisse a vos trucs incompréhenssible, je me permet de vous linker ca:
http://www.leblogduhacker.fr/creer-un-s … -securise/
je trouve qu'il y a des trucs interessant sur cela comme sur IT

le truc le plus difficile est en fait de pouvoir detecter une intrusion.

Debian-facile

#26 01-11-2016 19:54:42

Re : [résolu] Sécurisation pc perso...

#27 01-11-2016 20:14:30

Re : [résolu] Sécurisation pc perso...

#28 01-11-2016 20:27:21

Re : [résolu] Sécurisation pc perso...

#29 01-11-2016 20:28:28

Re : [résolu] Sécurisation pc perso...

#30 02-11-2016 22:02:36

Re : [résolu] Sécurisation pc perso...

#31 02-11-2016 22:07:54

Re : [résolu] Sécurisation pc perso...

#32 02-11-2016 22:15:37

Re : [résolu] Sécurisation pc perso...

#33 02-11-2016 22:33:52

Re : [résolu] Sécurisation pc perso...

#34 02-11-2016 22:52:58

Re : [résolu] Sécurisation pc perso...

#35 02-11-2016 22:58:39

Re : [résolu] Sécurisation pc perso...

#36 02-11-2016 23:03:09

Re : [résolu] Sécurisation pc perso...

#37 02-11-2016 23:35:23

Re : [résolu] Sécurisation pc perso...

#38 03-11-2016 14:39:06

Re : [résolu] Sécurisation pc perso...

#39 03-11-2016 16:34:18

Re : [résolu] Sécurisation pc perso...

#40 03-11-2016 19:54:34

Re : [résolu] Sécurisation pc perso...

#41 03-11-2016 21:42:47

Re : [résolu] Sécurisation pc perso...

#42 03-11-2016 21:51:17

Re : [résolu] Sécurisation pc perso...

#43 03-11-2016 21:55:08

Re : [résolu] Sécurisation pc perso...

Pied de page des forums