Sommaire
Bonjour,
Le but de ce journal est de raconter la petite expérience que j'ai faite en fin de semaine dernière.
On entend souvent que le net est dangereux, qu'il est important de sécuriser ses serveurs.
Je vais donc expliquer l'expérience que j'ai réalisé. Je dois cependant avertir les lecteurs qui administre déjà un(des) serveur(s), ou ceux qui regarde les logs de leur parefeu perso que ce journal ne va strictement rien leur apprendre de nouveau. Je pense que vous devez tous faire le même constat. Ce journal s'adresse aux autres ….
Pour réaliser mon expérience, j'ai mis en route 2 machines virtuelles avec des systèmes minimalistes.
*La première machine (gw) contient le paquet iptables et les règles qui permettent de bloquer l'ensemble des connexions provenant de l'extérieur (le méchant internet) sauf le port 22 qui est redirigé vers la seconde machine (pour ssh). L'ensemble des demandes de connexions non sollicitées venant d'internet est enregistré dans un log.
*La seconde machine (ssh) contient un serveur ssh sur le port 22. Les tentatives de connexions ssh (réussies ou non) sont elles aussi loguées.
Par sécurité,ces machines qui sont faites pour ce test ne contiennent aucunes données et (youpi, vive la virtualisation).
J'ai ensuite configuré ma box pour que les demandes de connexion provenant du méchant internet soient dirigée vers la machine (gw).
Je suis ensuite allé voir un DNS dynamique pour associer mon ip (dynamique) avec un nom de domaine.
Pour résumer
j'ai un nom de domaine associé à mon ip (dynamique) qui pointe vers une machine qui bloque tout (en loguant) sauf le port 22 qui est redirigé vers une autre machine ayant un serveur ssh. Le nom de domaine n'a fait l'objet d'aucunes publications volontaires de ma part sur un site. J'ai pas fait de la pub, j'ai pas dit qu'on pouvait trouver qq choses à cette adresse (d'ailleurs il n'y a rien a trouver ;o) ) etc…
Le lendemain de la mise en route de ce système, je constate que le log est déjà bien rempli.
Le bilan d'une journée de log (le 1 juin de 00:00 à 23:59).
Pendant cette journée, j'ai utilisé mon accès internet pour surfer sur quelques sites (pas des sites avec du contenu sensible), discuter un peu sur irc et échangé qq mails.
Je pense qu'il s'agit d'une utilisation d'internet correspondant à une majorité d'utilisateurs.
J'ai 49 "amis" que je ne connaissais pas qui ont tenté de se connecter sur mon ip.
Ils ont tenté 337 connexions, en essayant 47 ports différents.
Les ports essayés :
*80 ==> 27 fois
*445 ==> 24 fois
*8000 ==> 24 fois
*8080 ==> 16 fois
*1080 ==> 15 fois
*3128 ==> 13 fois
*8090 ==> 13 fois
*73 ==> 12 fois
*2479 ==> 12 fois
*6588 ==> 12 fois
*27977 ==> 11 fois
*1433 ==> 9 fois
*23 ==> 8 fois
*113 ==> 8 fois
*7212 ==> 8 fois
*8118 ==> 8 fois
*9000 ==> 8 fois
*3246 ==> 8 fois
*8008 ==> 8 fois
*9415 ==> 8 fois
*2301 ==> 7 fois
*8085 ==> 7 fois
*8123 ==> 7 fois
*9090 ==> 7 fois
*33434 ==> 6 fois
*808 ==> 5 fois
*8088 ==> 5 fois
*8195 ==> 5 fois
*17466 ==> 5 fois
*26889 ==> 5 fois
*3389 ==> 4 fois
*5390 ==> 3 fois
*25 ==> 2 fois
*53 ==> 2 fois
*210 ==> 2 fois
*4899 ==> 2 fois
*22 ==> 1 fois (une tentative avec un nom d'utilisateur inexistant sur mon système)
*137 ==> 1 fois
*222 ==> 1 fois
*2967 ==> 1 fois
*3306 ==> 1 fois
*5060 ==> 1 fois
*6515 ==> 1 fois
*7080 ==> 1 fois
*12000 ==> 1 fois
*16000 ==> 1 fois
*16001 ==> 1 fois
Mes amis
Je vais respecter mes amis et ne pas lister leur IP, mais j'ai donc découvert que j'avais des amis dans différents pays :
CA (Canada) 1 ami 3 connexions
CN (chine) 13 amis 188 connexions
CZ (république tchèque) 1 ami 1 connexion
DE (allemagne) 2 _amis 56 connexions
ES (espagne) 1 ami 1 connexion
FR (france) 6 amis 32 connexions
IL (israël) 1 ami 4 connexions
IN (Inde) 2 amis 8 connexions
IT (Italie) 1 ami 3 connexions
KR (Corée) 1 ami 1 connexion
LI (Liechtentein) 1 ami 1 connexion
LV (Lettonie) 1 ami 5 connexions
NL (Pays-bas) 1 ami 3 connexions
NO (Norvège) 1 ami 1 connexion
RU (Russie) 3 amis 11 connexions
TW (Taiwan) 1 ami 1 connexion
UA (Ukraine) 1 ami 1 connexion
US (Etats-unis) 9 amis 12 connexions
VN (Vietnam) 1 ami 1 connexion
ZA (Afrique du sud) 1 ami 1 connexion
Je viens de découvrir que j'avais un groupe de fans asiatiques.
conclusion
Je ne vais pas dire que l'ensemble des tentatives de connexions était dangereuse, cependant, le nombre de connexion non-sollicitée est important. Je suis surpris par le nombre de tentative de connexion sachant que j'ai une ip dynamique et que le nom de domaine utilisé pour l'expérience venait d'être créé.
Donc pour conclure, la protection d'un serveur, d'un ordinateur… par un parefeu correctement paramétré est une obligation.
Et si on a besoin d'ouvrir un port pour avoir un service accessible de l'extérieur, il faut le protéger correctement également, même si l'on est un simple utilisateur d'internet qui n'héberge rien d'important.
Cette conclusion n'est pas une surprise, je voulais juste raconter une expérience en indiquant des résultats chiffrés afin de te sensibiliser toi lecteur un peu plus à la sécurité. Il faut y penser avant d'ouvrir un port pour pouvoir accéder en ssh à sa machine, ou avant d'ouvrir un service qui n'est intéressant qu'à titre privé.
Nota : Les machines utilisées pour ce test sont maintenant arrêtées et le nom de domaine utilisé est maintenant supprimé.
# Refais le test
Posté par Florent Fourcot . Évalué à 10.
À mon avis, le DNS est ici strictement inutile. Tu peux refaire le test sans, tu obtiendras les mêmes résultats. Les bots qui scannent l'Internet en permanence, y'en a plein. Tu peux même trouver des projets de recherche là-dedans. Ton IP dynamique d'ailleurs c'est pareil, ils s'en foutent. Ils scannent une range, et que ce soit toi ou pas leur est relativement égal (il est même plus intéressant de scanner des adresses dynamiques, vu que justement les utilisateurs et les ports ouverts changent).
[^] # Re: Refais le test
Posté par Misc (site web personnel) . Évalué à 4.
Bravo, maintenant, il va voir qu'il a pas d'ami en fait.
Ceci dit, j'ai fait une expérience du même genre il y a 4 ans avec twisted. J'ai mis un faux serveur ssh qui accepte tout login/mot de passe, et qui enregistre le couple dans un fichier de log. Et j'ai vu que les bots qui vont tenter de bruteforcer ssh tente des mots de passes bidons ( genre login : test/ mot de passe : test ), et ne font rien ensuite si le mot de passe est correct. ( ou mon faux serveur ssh n'a pas suffit pour que le bot continue à s'installer ). J'ai pas non plus regardé si quelqu'un est revenu plus tard avec.
Donc j'aurais tendance à ne pas m'inquéter plus que ça sur les tentatives de scans.
[^] # Re: Refais le test
Posté par Raoul Volfoni (site web personnel) . Évalué à 3. Dernière modification le 04 juin 2012 à 13:44.
Tout à fait. En plus si on veut utiliser le DNS pour distribuer les empreintes de clé SSHFP RR il est impératif d'utiliser DNSSEC.
Sinon oui l'Internet c'est dangereux:
# Firewall
Posté par Moonz . Évalué à 9.
Je ne vois pas comment tu arrives à cette conclusion. Si tu as aucun service qui écoute sur internet, c’est quoi le danger de pas avoir de firewall ?
[^] # Re: Firewall
Posté par lay . Évalué à 4.
Le risque est un problème dans l'OS et la pile IP, même si aucun port n'est ouvert.
Même un firewall peut laisser passer ça.
Je dirait plutôt qu'un firewall "en amont" de la machine est indispensable.
[^] # Re: Firewall
Posté par fcartegnie . Évalué à 7.
T'es sur de ton raisonnement ? T'es en train de dire que le couche iptables ne peut avoir de failles par rapport à la stack ip.
[^] # Re: Firewall
Posté par lay . Évalué à 2. Dernière modification le 04 juin 2012 à 14:23.
Il peut bien sur y avoir des failles du coté d'iptables/netfilter, mais dans le principe il vaut mieux que ce soit une machine sans données critique qui se prenne les attaques et effectue déjà un filtrage des type de paquets IP en provenance d'internet qui peuvent ensuite transité vers les machines critiques.
C'est déjà arrivé dans le passé qu'un simple PING forgé fasse planté l'OS sans possibilité de rattrapage des données. Rien ne prouve que cela ne puisse plus arriver.
On a aussi vu des backdoors positionnées dans un firmware de carte réseau par un attaquant, des failles dans les logiciels d'analyse réseau en mode promicious. Bref, toute machine auquel on a branché un câble réseau est potentiellement faillible, seul le degré de confiance compte.
Je préfère clairement que ce soit le firewall qui tombe que les machines derrière avec tout les risques que ça engendre.
Après si l'attaquant arrive a avoir un accès sur le firewall, il peut voir tout le trafic qui y transite, mais si il a réussit a pown cette machine, il y a de grandes chances que de toute façon il aurait eu accès à toutes les autres machines plus facilement.
[^] # Re: Firewall
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 5.
Et qui va firewaller le firewall ?
[^] # Re: Firewall
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 0.
Et qui va firewaller le firewall ?
[^] # Re: Firewall
Posté par myou (site web personnel) . Évalué à 3.
Si tu es certain qu'aucun service n'écoute sur internet, peut être que le risque est limité.
Mais es tu certain qu'aucun service ne le fait ? qu'aucun service ne le fera jamais ?
Je voulais surtout mettre en lumière le fait qu'a partir du moment ou une machine est branchée sur le net, des connexions extérieures non-sollicitées vont être tentées.
[^] # Re: Firewall
Posté par Moonz . Évalué à 4.
Je suis un peu admin sur ma machine, donc oui. Je sais ce que j’installe, je sais ce qui se lance sur ma machine, et contrairement à Debian, ma distrib ne démarre aucun service sans que je le lui ai demandé explicitement.
Et si tu as un doute,
netstat -tpl.[^] # Re: Firewall
Posté par Raoul Volfoni (site web personnel) . Évalué à 10.
Avec un bon Rootkit tu n'y verrais que du feu…
[^] # Re: Firewall
Posté par Moonz . Évalué à 4.
Si t’as un rootkit c’est que tu as une machine déjà compromise, faut que tu m’expliques l’intérêt d’un firewall pour protéger la machine dans ce cas (si c’est pour éviter des fuites d’information, il suffit pour le rootkit de passer par HTTP en sortie, pas besoin pour lui d’ouvrir des ports en entrée).
[^] # Re: Firewall
Posté par Anonyme . Évalué à 4.
netstat -lapute# Tu l'a dit bouffi!
Posté par etenil . Évalué à 1.
Tu as raison et tu as bien fait d'insister sur le pare-feu, d'autant que le NAT n'a pas été conçu comme un mécanisme de protection, et qu'avec IPv6 qui arrive, il va falloir qu'un bon nombre d'admins revoient la sécurité de leur réseau.
[^] # Re: Tu l'a dit bouffi!
Posté par gnumdk (site web personnel) . Évalué à 5. Dernière modification le 04 juin 2012 à 12:49.
Euh, je vais peut être de décevoir, mais IPV6, ca risque de ne concerner que les machines publiques, pour l'instant, partout autour de moi, ca parle de routeur en ipv6 mais avec du LAN en ipv4 derriere…
J'avoue que je ne vois pas bien comment ils comptent faire cela non plus… Mais en tout cas, pour l'instant, les seuls projets IPV6 dont j'entend parler, c'est pour les serveurs et les routeurs, pas pour les PCs…
# pourquoi 2?
Posté par case42 (site web personnel) . Évalué à 9.
Pourquoi faire 2 VMs et rediriger le port 22 uniquement? Tu aurais tout a fait pu logger le port 22 depuis la machine "gw" (a moins que ton montage n'ai eu une autre finalité que juste cette petite expérience).
De la mienne, d'expérience, surfer depuis ton ip ne change pas grand chose. Mes serveurs dédies (depuis lesquels personne ne surf) se font autant scanner, voir plus: il y a très régulièrement des attaques en règles d'SSH par dictionnaire.
De manière générale, le seul port que je protège, c'est le port SSH, en limitant le nombre de connexion par seconde, ce qui a pour effet de bien décourager les tentatives de scan.
Les autres services qui tournent sont de toute façon destinées a être accessibles par tous (HTTP, SMTP, XMPP…) et ca n'aurait pas de sens de les filtrer au niveau réseau. Après, il faut bien sur s'assurer qu'on est bien a jour et qu'on ne laisse pas des application Web mal fichu ou dangereuses ouvertes aux 4 vents…
Pour le reste, un port fermé est tout aussi secure qu'un port fermé ET filtré par iptables (voir plus).
[^] # Re: pourquoi 2?
Posté par Frank-N-Furter . Évalué à 3.
Ouaip, c'est juste des bots, en regardant les logs de mes serveurs web je retrouve des user agents aux doux noms qui fleurent bon l'acné. Parfois ça me démange de bloquer les ip provenant d'Asie et d'Europe de l'Est. Contacter les Abuses des ISP ne servant absolument à rien.
Depending on the time of day, the French go either way.
[^] # Re: pourquoi 2?
Posté par Frank-N-Furter . Évalué à 2.
Un exemple: https://pastee.org/3esrn
Depending on the time of day, the French go either way.
[^] # Re: pourquoi 2?
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Je ne sais pas. Peut après avoir mis en place fail2ban chez moi, j'ai noté des tentatives répétées venant d'une même adresse en Pologne. J'ai augmenté la durée de blocage de 30 min à 2 heures, mais j'avais toujours 3 essais toutes les deux heures. J'ai donc envoyé un mail à l'adresse abuse@ISP et peu après les requêtes ont disparu. Hasard ou conséquence ? Je n'ai aucune certitude, mais peut-être que…
[^] # Re: pourquoi 2?
Posté par Frank-N-Furter . Évalué à 4.
Je dois avouer n'avoir essayé qu'à quelques reprises, et n'ayant même pas reçu de réponses automatiques avoir laissé tomber.
Sinon tu es content de fail2ban? Je l’avais sur serveur histoire de voir, et à un moment, il est parti en vrille, me bouffant un max de ram, depuis cet incident, je me contente d’avoir sshd qui écoute sur port alacon.
Depending on the time of day, the French go either way.
[^] # Re: pourquoi 2?
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Je l'utilise depuis de nombreuses années sans aucun problème. Depuis je dors beaucoup mieux la nuit et j'ai plein de filles autour de moi. ;)
L'idéal est d'avoir une bonne config avec knockd pour planquer son sshd. C'est fou le nombre de choses que ce soft permet de faire. Par exemple lorsque je suis en déplacement et que j'oublie la séquence qui m'ouvrira le port et que je me retrouve banni, une autre séquence me permet de faire le ménage dans la chaine iptables concernée et par conséquent de me retirer la balle du pied.
[^] # Re: pourquoi 2?
Posté par Frank-N-Furter . Évalué à 2.
Qu'il enlarge my penis, me suffirait largement. Ou qu'il reduise mon agacement a la lecture de mes logs me suffirait :)
Ça, c'est mon autre légère angoisse, me retrouver comme un con enfermé hors de mon serveur, parce que, une fois de plus je n'ai pas les yeux en face de trous, et je poliote entre les pwd de mes serveurs, et ceux de mes clients…
Mais, je vais tester le couple fail2ban/Knockd, qui semble avoir été conçu pour les Pierre Richard de l'admin sys.
Depending on the time of day, the French go either way.
[^] # Re: pourquoi 2?
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Ça c'est le boulot de logwatch. ;)
Haha, c'est tout moi aussi ça. Surtout après quelques pintes de Guinness…
Alors un conseil: avec knockd tu peux associer une séquence de port/protocole à une action.
En plus d'ouvrir certains ports normalement bloqués par iptables, j'en ai une pour rebooter le serveur et une autre pour vider les chaines iptables.
Mais en théorie on doit pouvoir faire plein d'autres choses marrantes.
[^] # Re: pourquoi 2?
Posté par Olivier Serve (site web personnel) . Évalué à 0.
Je n'ai pas non plus eu de réponse, donc je ne sais vraiment pas si mon mail a été efficace. J'ai juste constaté des tentatives constantes pendant 3 jours et quelques heures après mon mail plus rien.
Sinon, aucun problème constaté pour le moment avec fail2ban.
[^] # Re: pourquoi 2?
Posté par Tonton Benoit . Évalué à 2.
Y'a sshguard qui est plus léger.
Il faut aussi veiller à avoir un fichier de log dédié à l'authentification, si tu donne à bouffer /var/log/messages à fail2ban il va mal le digérer.
[^] # Re: pourquoi 2?
Posté par myou (site web personnel) . Évalué à 2.
Pour les 2 machines je suis oki avec toi , c'était pas nécessaire pour le test.
A la base, le montage était prévu pour autre chose que cette expérience ;o)
Le but est de tester un principe de sécurisation.
en fait sur gw, j'ai un serveur ssh qui écoute seulement coté LAN, et je ne veux pas que ce serveur ssh soit accessible par le NET. D'ou la seconde machine.
Pour accéder à gw par le net, on est déjà redirigé vers la seconde machine (user / mot de passe) puis on peut depuis la console se connecter en ssh sur gw (autre mot de passe).
A partir du moment ou les mots de passe sont différents, on ajoute un niveau de sécurité.
La machine 2 est seulement destinées à recevoir les cnx ssh du net et n'offre rien d'autres.
Cependant, sur une journée, c'est pas un accès ssh qui a été le plus recherché. Bon, une journée c'est court, alors je ne vais pas conclure qu'il ne faut pas protéger ssh plus que ça !! ;o)
Mais comme les ports scannés ne sont pas si nombreux que ça… simplement changer le port d'écoute de ssh doit limiter le nombre de tentative de cnx.
[^] # Re: pourquoi 2?
Posté par Nasga . Évalué à 1.
Perso, j'autorise les connexions ssh/vpn que pour certains domaines/ips.
J'ai déjà assez de logs à lire .
# IP dynamique
Posté par ®om (site web personnel) . Évalué à 9.
Si ton IP est dynamique, il est fort probable qu'avant que tu ne l'utilises, elle était attribuée à quelqu'un d'autre… Si cet autre avait lancé un client P2P, les clients ont dû enregistrer que cette IP avait tel bout de fichiers… et c'est toi qui te reçoit les requêtes.
Juste une hypothèse à ajouter aux robots qui scannent en permanence…
blog.rom1v.com
# Détection de proxy ouverts
Posté par mansuetus (site web personnel) . Évalué à 5.
Souvent, les serveurs/réseaux IRC scannent les clients pour détecter les proxy ouverts.
Ca justifierait une partie de ceci :
*8080 ==> 16 fois
[^] # Re: Détection de proxy ouverts
Posté par myou (site web personnel) . Évalué à 2.
oui exact …
cela explique une partie des 56 requêtes allemandes ( ports 8080 8000 1080 80) qui doivent être liées à mes connexions sur IRC.
[^] # Re: Détection de proxy ouverts
Posté par mazarini . Évalué à 1.
En général, sur le port 80, j'ai de requetes "visant" phpmyadmin. J'ai fini par leur fournir une page html pour avoir moins de message d'erreur.
Autrement je trouve pas mal d'accès visant "c:\winnt" et similaire.
# Fail2Ban
Posté par Benbben . Évalué à 4.
Personnellement, j'ai installé Fail2Ban sur mon serveur ouvert sur le monde.
Et je reçois régulièrement des mail m'informant que telle ou telle adresse ip ont essayées de se connecter au serveur SSH plus de six fois avec de mauvais mot de passe, et sont bloquer pour une durée déterminée.
Fail2Ban peut surveiller aussi le log de apache pour ecrire des règles de filtrage Iptable à la volée.
vous pouvez écrire vos propres systèmes de vérification de log, et de génération de règle iptable.
Bref cela me rassure de me savoir attaqué, j'ai l'impression d'être protéger ;-)
[^] # Re: Fail2Ban
Posté par oinkoink_daotter . Évalué à 5.
_o/* Paf *Attaque sournoise à coups de Bescherelle*
[^] # Re: Fail2Ban
Posté par Frank-N-Furter . Évalué à 2.
Rhaa, mais c'est grandiose! Et il y a l'équivalent pour nginx!
Depending on the time of day, the French go either way.
[^] # Re: Fail2Ban
Posté par Benbben . Évalué à 1.
En tout cas c'est discuté comme sujet d’après mon seul amis google : http://snippets.aktagon.com/snippets/554-How-to-Secure-an-nginx-Server-with-Fail2Ban
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.