Votre serveur SSH (Secure Shell) créé, votre Raspberry Pi peut être facilement accessible depuis n’importe où sur Internet. Une fois que les pirates auront découvert votre adresse IP ils s’attaqueront directement au port 22 (port par défaut du serveur SSH). Il est aussi important de modifier son mot de passe Pi, si toutefois une personne tierce arrive à se connecter en SSH à votre Raspberry, il sera facile pour elle de se connecter en utilisant les identifiants par défaut soit : Login : pi et mot de passe : raspberry.
Au sommaire :
Sécuriser le serveur SSH
Modifier le port SSH
Accéder au terminal, soit en direct, soit en utilisant votre SSH (si vous effectuez cette manipulation en SSH, vous risquerez d’être déconnecté à la fin de l’opération : c’est tout à fait normal, il vous suffira juste de vous reconnecter en choisissant votre nouveau port)
Dans le terminal, tapez la commande suivante :
sudo nano /etc/ssh/sshd_config
Cette commande vous permettra d’accéder et de modifier le fichier sshd_config, avec les droits root.
Une fois dans ce fichier vous devriez voir cela :
Au début du fichier, vous devriez voir la ligne :
Port 22 (où 22 est le numéro du port utiliser par le serveur SSH)
Modifier le numéro de port en conséquence, en tenant compte, que le port du serveur SSH doit être 22, ou bien être compris entre 1024 et 65537.
Puis :
Ctrl+o pour sauvegarder le fichier
Ctrl+x pour quitter l’éditeur Nano
Le numéro de port est maintenant modifié.
Connexion avec Putty
Une fois dans Putty, vous n’avez qu’à rentrer l’adresse IP de votre Raspberry et changer le numéro de port (par défaut 22) par celui que vous avez choisi précédemment.
Exemple pour le Raspberry avec comme adresse IP 192.168.1.68 et comme port du serveur SSH 1028
Modifier un mot de passe utilisateur
Toujours dans le terminal et en étant connecté avec la session à laquelle vous voulez modifier le mot de passe
Taper la commande:
passwd
On vous demandera votre ancien mot de passe puis votre nouveau de passe.
Conclusion
Ça y est votre serveur SSH sera maintenant bien mieux protégé qu’auparavant. Il est tous de même possible de vous faire pirater mais ce sera bien plus compliqué, car avant, le pirate n’avait qu’à connaitre votre adresse IP, maintenant il devra connaitre votre adresse IP, le numéro de port du serveur SSH ainsi que votre mot de passe. 🙂
Sous Jessie fini l’accès en root
Mais il y a une astuce lorsque vous développez uniquement en ssh pour contourner la protection les puriste vont crier.
Sudo nano /etc/ssh/sshd_config
Ligne 28 remplacer
PermitRootLogin without-password
par
PermitRootLogin yes
On se retrouve à la maison !!!
Ok merci je ne connaissais pas,
Cordialement
Tom
merci Bruno 🙂
Je suis « Newbies » dans le monde Raspberry.
Est-ce donc pour cela que dans la dernière version, il existe un « Root terminal » ?
Merci
@Caillou le root terminal est une facilité pour ouvrir un terminal directement root à n’utiliser que lorsqu’on a besoin d’effectuer des opérations nécessitant un niveau root sinon on ouvre le terminal normal, c’est un peu comme sous Windows ou l’on peut ouvrir une fenêtre de commande avec « Exécuter en tant qu’administrateur ».
Merci a @Dodutils pour la réponse 🙂
autre petite astuce : changer le mot passe de root
« sudo passwd root »
Entrez le mot de passe : lemotpasse
On vous le demandera une 2eme fois et un message de confirmation apparaitra si les 2 entrées sont identiques .
Oui, merci, la méthode présente dans l’article est la même, il suffit juste d’être connecté sur la session root pour changer le mot de passe root ou la session pi pour changer le mot de passe pi
etc
Cordialement
Tom
Bonjour,
De mon coté je préfère garder le port 22 par défaut, cela évite via mes scripts entre les machines de mon réseau local d’avoir à toujours penser de rajouter le port de connexion.
Par contre, pour l’accès extérieur, je me sert de mon routeur afin d’utiliser un autre port que le 22 depuis internet.
Le port 22 WAN n’est pas routé dans mon LAN, il est bloqué par le routeur.
Par contre, j’utilise par exemple le port 2222 depuis l’accès SSH ou SFTP depuis internet ver mon IP, et c’est mon routeur qui redirige le port 2222 Internet vers mon IP privé du Rpi, port 22.
Voilou 😉
Oui c’est une autre possibilité, un article va être publier sur ce sujet
Cordialement
Tom 🙂
Il faut redemarrer le service ssh pour la prise en compte du nouveau port.
sudo service sshd restart
On peut également mettre plusieurs lignes « Port 22 » avec des ports différents.
Oui, il faut bien redémarrer le service SSH mais en utilisant la commande
Oui bien sur, on peut également rajouter autant de port que l’on le souhaite, par contre toujours en restant dans la bonne plage ( port 22 ou entre 1024 et 65537)
Cordialement
Tom
Salut,
Merci pour le partage.
Le changement de port limite les scripts brute de force sur le port 22 qui sont les plus basiques, les plus avancés faisant un scan et analysant la réponse. Un couplage avec fail2ban pourrait être une solution additionnelle
Une proposition d’authentification par échange de clé aurait été sympa.
Salut,
je ne connaissais pas Fail2Ban, il peut être également une bonne protection supplémentaire
Cordialement
Tom
Il est aussi possible de rediriger les ports via une box. Perso j’ai redirigé le port 1234 vers le port 22 du raspberry.
En dehors de ça, créer un nouvel utilisateur (puis l’ajouter aux sudoers) et supprimer pi est aussi une bonne chose à faire.
Oui c’est pareil, un article est prévu sur la redirection et la traduction d’adresse depuis une box
Cordialement
Tom
En voyant ton commentaire plus bas, je précise que 1234 était un exemple 🙂
Oui bien sur je l’ai également utilisé à titre d’exemple
rhoo, alors qu’il y a un très bon tuto dans le forum.. ^_^
http://forums.framboise314.fr/viewtopic.php?f=3&t=283&sid=f8d3275c032e16bda4166f191f150cee
2è essais : *@$£ de 8min (je comprends)
Bonjour Dyox l’info est passée…
tous les lecteurs du blog ne vont pas sur le forum 😉
cordialement
François
Allo,
Je salue l’initiative car c’est un sujet sur lequel il y a peu de lecture. Je trouve par contre le titre un peu large par rapport au contenu. Voici quelques commentaires complémentaires sur le sujet :
1) Changer le mot de passe par défaut des comptes d’administration de chaque système surtout lorsqu’ils sont accessibles à distance.
2) Ne pas oublier les autres portes d’entrées et leur appliquer le même traitement (VNC par exemple).
3) Globalement, tout système accessible à distance ne devrait pas publier les services d’administration dont il dispose à n’importe quel internaute (et autres « scanners » de ports ouverts). Pour cela, des accès VPN devraient être mis en place pour que les seuls détenteurs des clés de chiffrement puissent se connecter. De cette façon, nul besoin de modifier les ports car les services disponibles (à l’exception des serveurs publics comme un serveur web par exemple qui a besoin du port 80, etc.) n’apparaissent plus aux yeux de ceux qui ne disposent pas des clés de chiffrement (déjouant ainsi les « scanners » de ports).
Il est certain que ce surplus de sécurité se paie par une lourdeur, pour vous, dans la façon d’accéder à votre Raspberry Pi. Il faut donc que le jeu en vaille la chandelle.
4) Dans la même idée et donc selon votre contexte, il ne faut pas seulement penser aux accès distants. En effet, il pourrait être plus facile d’accéder physiquement à votre Raspberry pour se brancher en SSH directement sur le port série. Par défaut, cette option est désactivée dans Raspi-Config. Bien que très pratique, activez la en connaissance de cause seulement. N’oubliez pas non plus, qu’en ayant accès au Raspberry Pi, il est aussi possible de changer la carte SD avec l’OS (et le mot de passe!) de votre choix pour vous permettre d’accéder aux capteurs éventuellement raccordés sur le port GPIO. Même idée avec les composantes réseautiques sur lesquelles il serait possible de se raccorder pour essayer d’attaquer les sessions chiffrées de votre Raspberry Pi.
La sécurité forme un tout dont l’efficacité est celle du maillon le plus faible.
Tout cela à un cout qu’il faut comparer à vos enjeux.
Il existe énormément de moyen de sécurisé son Raspberry, pour le moment je n’en n’est présenté que deux… la suite viendra
Cordialement
Tom
Le commentaire date un peu. Je ne sais pas si tu recois une notification.
Juste pour dire que je ne pense pas que cela soit utile de se prendre la tete avec un VPN. SSH permet de faire pas mal de choses, notamment une connexion avec une clef privé/public, de restreindre des connexions clientes à certaines IP.
Pareil pour le navigateur avec Apache si besoin.
Si le raspberry est chez soi et donc n’a pas de patte réseau directement sur internet (ce qui doit la majorité écrasante des cas), il suffit simplement de changer le routage de port sur sa box internet
Le RPI écoute sur le port 22 sur le réseau interne, et rien n’a été changé dans sa configuration, mais la box route par exemple le port 6666 vers le port 22 du RPI
Depuis l’extérieur on y accède en tapant votre IP publique (celle de la box) et le port choisi 6666 et les paquets sont dirigés vers le RPI port 22
en interne, on se connecte sur l’IP réelle du RPI (son ip sur le réseau interne) port 22
Oui, bien sur.
Un article viendra sur la redirection de port pour plus de détail (comment s’effectue les manipulations, à quoi cela sert …)
Cordialement
Tom
Alors deux problèmes dans cette phrase « le port du serveur SSH doit être 22, ou bien être compris entre 1024 et 65537 »
La première … port 65537 ??? on se croirait dans un de ces films avec un peu d’informatique qui nous affichent des IP ou des ports impossibles erreur de frappe je n’en doute pas mais c’est quand même drôle 😉
Ensuite le port SSH peut très bien être où l’on veut et pas seulement au dessus de 1024 à partir du moment ou il n’empiète pas sur un service qui utilise déjà le port choisi.
Et contrairement à ce que propose @bruno83 je déconseille fortement d’autoriser le login root sur SSH hormis certains usages/besoins spécifiques, il vaut donc mieux limiter le compte auquel on accédera puis faire un sudo -i pour basculer root pas la suite. une fois connecté.
Et attention à ne pas confondre le fichier sshd_config avec ssh_config (sans le « d ») sinon les modifs ne serviront pas à grand-chose 😉
Oui, c’est vrai ! 🙂
Le plus simple est d’utilisé un port à quatre chiffres mais pas trop simple non plus (ex: 1234 ne sera pas plus sécurisé que le port 22, les hackeurs essaye celui la après le 22)
Les modifications de port du serveur SSH sont font bien dans le fichier sshd_config
Cordialement
Tom
Pour mon « attention à ne pas confondre sshd_config et ssh_config » c’était juste une remarque générale pour les débutants qui doivent faire attention à la différence entre le sshd_config qui configure le demon (service) SSH d’où le « d » dans le nom et ssh_config qui configure le client qui sert à se connecter depuis le RasPi vers une autre machine en SSH 😉
Sinon autre astuce sécuritaire on peut aussi paramétrer le sshd pour n’autoriser root que depuis certaines IP donc par exemple faire en sorte qu’il ne soit autorisé que depuis les IP locales sauf l’IP de la Box qui sera l’IP source vue pour une tentative de connexion externe, comme ça on se connecte root « tranquille » quand on est chez soi mais on force à basculer « sudo » si on se connecte depuis l’extérieur.
Et dans ce cas une autre sécurité consistera à ajouter un paramètre dans le fichier /etc/sudoers pour envoyer immédiatement un mail à chaque fois qu’un utilisateur passe root via sudo (vu qu’on aura interdit le « su » tout court) comme ça si quelqu’un se connecte depuis l’extérieur et passe root vous êtes avertis et soit c’est vous et c’est ok, soit c’est pas vous et là au choix on peut envisager aussi un système qui active un shutdown dans la minute après un « sudo » si une action bien particulière n’est pas effectuée (en envoyant aussi un mail d’alerte à ce sujet), comme ça le pirate n’aura pas eu le temps de faire trop de dégâts.
et bonne remarque de @gUI au sujet de changer le login « pi » par défaut.
petite correction je me suis mal exprimé au sujet des IP à filtrer, je voulais dire autoriser uniquement le login root sur les IP locales pour ceux que ça arrange mais interdire les autres IP (qui arrivent donc au travers de la Box).
Ok merci pour l’info 😉
Exact, je trouve bcp plus sécuritaire de couper le login root que de déplacer le port. En déplaçant le port, il faut que l’attaquant le découvre (65k possibilités). Par contre, en déconnectant root *et* pi, il faut que l’attaquant découvre le login, et là, c’est bcp plus que 65k possibilités, surtout si on a fait l’effort de ne pas mettre un prénom.
Et sinon je confirme, pas de contrainte sur le numéro de port (au delà des 1024). Cette règle ne s’applique qu’aux utilisateurs « ordinaires », hors le process SSH est lancé par root, il fait ce qu’il veut. D’ailleurs un grand classique c’est d’utiliser 443 : ce port réservé à HTTPS est très souvent ouvert dans les proxy/firewall d’entreprise, contrairement au 22. Du coup le serveur SSH reste plus facilement accessible.
Ok merci pour l’info 🙂
Bonjour,
merci à François de rappeler la base de la sécurité car certains ont tendance à l’oublier parfois. Comme cela a été dit par Christophe, la première sécurité à laquelle on ne pense pas dans certains cas c’est le simple accès physique à la machine. Ensuite il faut un firewall correctement configuré et changer le port par défaut est toujours recommandé également. Pour l’accès ssh, comme le rappelle dodutils le mieux est de n’autoriser l’accès qu’à un compte non administrateur et uniquement par clef ssh.
Il existe encore une protection supplémentaire. Fermer les ports au niveau du firewall et n’ouvrir les ports que temporairement au moment de l’accès avec la technique du « port knocking ». Technique qui consiste donc à frapper à la porte avec un code (en fait on accède à différents ports avec une séquence bien précise) pour qu’on accepte d’ouvrir un port donné juste le temps d’établir la connexion (quelques secondes).
Avec tout ça impossible de trouver un port ouvert avec un scan, il faut posséder la séquence pour ouvrir le port, la clef ssh pour accéder au premier compte et enfin le mot de passe du compte administrateur.
Amis paranoïaques … à vos claviers !
Bonjour bzh44
C’est Tom qui s’y est collé, je n’y suis pour rien 😉
et pour un premier article il a provoqué de la réaction 🙂
on attend les prochains impatiemment !
cordialement
François
Pour sécuriser le truc et l’utiliser qu’en LAN mon adresse réseau 192.168.1.0/24
Je rajoute une utilisation uniquement en local
Dans le fichier sshd_config
AllowUsers root@192.168.1.*
PermitRootLogin yes
pour ne pas avoir à utiliser de clef qui est le top du top lol
A+ bruno
@bruno83 exactement ce que j’ai proposé dans mon avant-dernier commentaire, n’autoriser le root que sur les IP locales pour ceux qui tiennent vraiment à pouvoir se connecter root direct.
Bonjour,
Merci, c’est en lissant votre post et vos remarques judicieuses que j’ai rajouté cette ligne (AllowUsers pi root@192.168.1.* pi@*) c’était juste pour donner le formalisme de l’écriture à d’autres néophytes comme moi.
Ainsi je ne change pas mes habitudes et je sécurise le truc
A+ bruno
erreur
AllowUsers root@192.168.* pi@*
C’est une autre possibilité
Cordialement
Tom 🙂
le summum de la sécurité : ne pas insérer de carte SD, ne pas alimenter la carte, ne pas la connectée au réseau, ne pas la sortir de sa boite … et enterrer la boite dans une grande forêt, seul, de nuit en ayant un peu bu mais sans laisser de traces … plus personne n’y accédera même pas vous (selon le taux d’alcoolémie) =D
Bonjour
(c) Tesson
C’est ce que je dis sans arrêt aux futurs techniciens que je forme : « Le seul moyen de protéger un poste informatique c’est de le poser sur une table dans une pièce fermée à clé, sans le relier ni au secteur ni au réseau ». Après si on en décide autrement il faut prendre les précautions nécessaires à sa protection 🙂
Il m’est arrivé récemment de ne même plus pouvoir me connecter à un Raspberry Pi placé sur un bureau juste à côté. Faut dire que j’avais appuyé sur l’inter de la multiprise en branchant l’alim du RasPi… Même pas pu accuser le chat, il n’y en a pas 🙁
En informatique on dit aussi : « Si tu barricades la porte, ils passeront par la fenêtre »… en gros, fais ce que tu peux, il y aura toujours une faille quelque part. Pas très rassurant. Il y a un livre pas mal à ce sujet chez ENI :
En tout cas merci à Tom pour cet article qui pourra servir de mise en garde aux débutants. Il ya beaucoup de lecteurs sur le blog (plus de 5000 par jour) mais pas beaucoup comme Tom qui osent se lancer dans l’exercice, pas si facile, de l’écriture. On n’est pas à l’abri de faire une erreur, on s’expose aux critiques… mais on y va ! Quand je vois le nombre de commentaires très constructifs qui ont suivi, je pense que ce genre d’alerte est nécessaire. Merci également à tous ceux qui ont contribué à enrichir le débat 🙂
Cordialement
François
oulala tres decu d’un coup donc je vais ramener mon grain de sel.
alors pour sécuriser votre ssh et je vous le dit pour m’etre fait piraté un serveur sur internet ma solution elle est pas si compliqué que ca et je peux vous assurer que derriere vos authentification seront plus simple et que vous serez avertit en cas de probleme ( c’est un peu a ca que sert l’informatique.
ma securisation chez moi se fait en deux etapes la premiere une authentification avec cle publique franchement ca parrait compliqué au premier abord mais une fois qu’on la fait ca peut se repliquer sur tout vos RPI serveur linux afin de n’avoir qu’une clé pour vous connecter a tous.
je vous ferais bien un tuto pour ca mais vu qu’il y en a des centaines je vous ai trouvé celui la qui utilise putty ce qui motivera les allergique a la ligne de commande meme si je ne pense pas qu’il y en ai beaucoup vu qu’on parle de SSH :
http://blog.oceanet-technology.com/vision-expert/authentification-ssh-par-paire-de-cles-priveepublique/
si vous voulez le faire en ligne de commande allez voir la :
http://www.git-attitude.fr/2010/09/13/comprendre-et-maitriser-les-cles-ssh/
la securité d’authentification est determiné par le nombre de bit que vous fera votre clé, perso j’utilise des clé 2048 bits sur mes serveurs mais c’est des 16 core avec 32go de ram et la connexion met 1-3 secondes donc sur un RPI je vous conseille de rester dans du 256 voir 512 afin que l’authentification ne prennent pas trop de temps. je vous laisse lire ce tres bon article sur la longueur des clés et n’oubliez pas ce n’est pas la taille qui compte, quoi que ! http://www.strong-password.com/blog/post/2011/02/22/Longueur-de-cle-et-paranoia.aspx
après une fois que vous avez fait ca et que vous l’avez testé vous desactivez tous les autres moyens d’authentification et deja la ca sera dur de vous pirater votre RPI.
une fois que vous avez fais cela deuxieme etape est pas beaucoup plus compliqué vous allez rajouter dans votre fichier /etc/ssh/sshrc ce qui suit :
####################################################################
DATE=
date "+%d.%m.%Y--%Hh%Mm"IP=
echo $SSH_CONNECTION | awk '{print $1}'REVERSE=
dig -x $IP +shortHOSTNAME=
hostname -secho « Information sur l’utilisateur connecte
IP: $IP
REVERSE: $REVERSE
Date: $DATE
User: $USER
» | mail -s « Utilisateur connecte sur ton RPI en SSH » toto@toto.com
#########################################################################
pour ceux qui n’aurait pas compris cela enverra un mail sur la boite mail que vous aurez choisi a chaque fois que quelqu’un se connectera en ssh a votre RPI ( pour ca il faut configurer l’envoi de mail en ligne de commande et je vous avoue que ayant un serveur smtp sur mon serveur linux ca se fait tout seul mais je vais essayer de vous faire un tuto pour tout configurer de A a Z ca sera plus simple.
bon après il existe une troisième etapes qui est pas mal c’est de bloquer les ip qui tente de se connecter avec fail2ban mais je pense que si votre RPI est en local ca a peut d’interet, cette solution ne sert que pour les attaque repeté donc bruteforce ( c’est ce que j’ai eue perso) surtout que ca prend un peu de resource donc un peu bete de rajouter fail2ban pour surcharger le RPI
Bonjour blegoff
bien joué !
la solution de Tom s’adresse à des débutants en RasPi qui souhaitent avoir un minimum de sécurité.
l’authentification par clé était programmée pour la suite 🙂
ça va faire avancer le schmilblick
en tout cas merci pour ce grain de sel qui ressemble plus à tas de sel !! 😀
cordialement
François
Bonjour Blegoof, comme l’a dit François, cet article s’adresse à des novices ou des personnes qui souhaitent sécuriser leur SSH s’en trop se compliqué avec tout de même un peu de sécurité !
Plusieurs l’ont également demander donc un article sera rédiger sur une sécurité plus élevée (clé, Fail2Ban, …)
Cordialement
Tom
Je me permets de mettre les 2 cours de OC (OpenClassrom) :
La connexion sécurisée à distance avec SSH (avec clé)
https://openclassrooms.com/courses/reprenez-le-controle-a-l-aide-de-linux/la-connexion-securisee-a-distance-avec-ssh
et sécuriser son serveur (fail2ban est à la fin)
https://openclassrooms.com/courses/securiser-son-serveur-linux
Cela fait un très bon complément pour ceux qui veulent comprendre/approfondir/piqûres de rappel… leurs connaissances
Merci dyox
Cordialement
Tom 🙂
Accessoirement, changer le port d’un service est un peu inutile, sauf à le mettre dans la tranche haute au dessus de 10 000 (et encore…)
Le nombre de fois où, ayant perdu le port d’un service, et sans accès à internet où j’ai lancé un nmap pour voir les ports ouverts…
Et les outils de hacking se fichent de savoir quel est le port ssh, ils voient un port ouvert, ils tentent une connexion dessus, ils regardent le retour et ils devinent le service derrière
(par exemple le scan reçoit « 220 example.com ESMTP Postfix » et hop, il sait qu’il a affaire à un serveur de mail Postfix)
Après je dis « un peu inutile » parce que c’est surtout pour des attaques ciblées que ces tests sont fait… pas des attaques d’envergure.
Merci pour l’info 🙂
Et pour donner un exemple « pratique », j’ai un NAS Synology à la maison. Les ports par défaut pour accéder à l’interface web sont le 5000 pour le http, et le 5001 pour le https. Maintenant, imaginons quelqu’un en veut à mon réseau. Première chose, je lance un nmap (un outil très puissant) sur cette belle adresse que j’ai trouvée sur Internet (ici, c’est du réseau local, mais le principe est le même)
https://s23.postimg.org/53kooptqj/show-me1.png
On peut voir que je suis un sale pirate… euh un militant pour la vie privée car le service TOR tourne sur mon NAS
Ce qu’on peut voir en revanche, c’est qu’il y a 2 ports consécutifs qui sont utilisés (5000 et 5001) et ce n’est pas courant chez un particulier (je passe outre les VPN, TOR, NFS….). On voit aussi 2 ports dans la tranche haute (50001 et 50002)
Analyse des 5001 et 5002
https://s23.postimg.org/xhq48lhaj/show-me2.png
Oh en fait ce ne sont pas des services UPNP et complex-link, mais un serveur ngix en http et en https
Analyse des ports 50001 et 50002
https://s23.postimg.org/qfs6medor/show-me3.png
Ooooh, le port UPnP est sur le 50001 en fait… et le 50002 c’est un autre serveur web (lighttpd) qui y est configuré… Et en plus, je sais quelle version du noyau tourne sur le serveur !
2 minutes, j’ai trouvé 3 entrées potentielles, la version de l’OS qui tourne, et même la version d’un des 2 serveurs web qui a peut-être des failles
merci pour cette belle démo mioux ! 🙂
sympa cette explication c’est clair c’est net j’adore.
bon par contre au lieu de securiser nos RPI, ca va motiver certain a se mettre au hacking lol
C’est ce genre de messages qui m’ont poussés à me renseigner de plus en plus sur la sécurité. J’avais même installé un backtrack (devenu depuis kali linux) sur une VM au taff pour montrer les points faibles du réseau à notre admin, suite à une attaque chez nous, où on avais une personne qui nous redémarrait tous les postes et quelques serveurs tout les samedi soir, en plein pendant certain traitements.
J’ai donc lu un super livre (dont j’ai oublié le nom) de 800 pages qui t’explique pendant 400 pages que de toute façons, les attaques informatique en entreprise, c’est pas de l’extérieur que ça vient :D, et les premiers points « informatiques » qui montrent comment certaines pratiques régulièrement mise en avant sont inutiles voire contre productive (dont ce fameux changement de port qui est plus inutile que contre productif)
Salut mioux je ne peux pas te repondre donc je me repond a moi meme, oui en general un bon admin securité est en general un bon hacker, quand je vois le nombre d’admin securité qui ne se base que sur des livres « standard » pour mettre en place une politique de securité ca me laisse perplexe.
si tu retrouve le titre du livre dont tu parles ca m’interesserai de me le procurer ?
Moi non plus je ne peux pas répondre au commentaire suivant 😀
Malheureusement, je n’arrive pas à le retrouver, et je l’ai donné à mon ancienne boite (à la base mon frère l’avait trouvé dans une poubelle pendant une de ses tournées d’éboueur).
ah bon ben je pars faire toutes les poubelles uen par une lol, plus serieusmeent je vais essayer de trouver un bouquin de 800 pages avec beaucoup de pratique !
Pour rajouter de l’eau au moulin. Personnellement je possède également un Syno avec les ports 5000 et 5001 bien connu est des raspberry en réseau interne chez moi.
Mais pour connaître des attaques type nmap citées plus haut, je n’ai rien d’accessible depuis l’extérieur.
Comment je fait : Un VPN configuré dans mon routeur (FreeBox) en mode serveur. Reste à configurer le VPN côté client (outil intégrés dans Windows). Et vous avez une connexion crypté avec chez vous. Ensuite vous pouvez utiliser Putty, le navigateur web et tous le reste puisque vous êtes chez vous.
Vous pouvez même accéder à votre routeur (FreeBox) et démarrer les postes à distance avec WakeOnLan, puis prendre la main dessus.
Résultat pas de ports ouvert vers l’extérieur.
Sinon il faut se régaler avec la série Mr. Robot :)))
merci François-Paul
tant qu’il y aura des ordinateurs on jouera à « missile » – « anti-missile’ 🙂
Pas simple de faire des articles là dessus car il faudrait traiter des multiples box qui existent…
A moins que les FAI ne veuillent bien fournir chacun une box et une connexion gratuite –D
mais nan là je rêve 🙂
73’s
François
Sidi -i pour passer en root