momo Posté(e) le 16 janvier 2008 Partager Posté(e) le 16 janvier 2008 salut,si comme moi vous en avez marre d'etre scanné sur le port 22 et de trouver dans les logs ceci ... Jan 16 02:52:49 sshd[32335]: Failed password for invalid user joseph from 218.155.21.107 port 37597 ssh2 alors il suffit de mettre dans le fichier hosts.deny l'entrée sshd : ALL et les entrées correspondant à vos @IP securisés dans le fichier hosts.allow du type sshd : XXX.XXX.XXX.XXX. Cela marche aussi pour le ftp. Et vous voilà en partie protégé des intrusions par ssh ou ftp. Lien vers le commentaire Partager sur d’autres sites More sharing options...
ikeke Posté(e) le 16 janvier 2008 Partager Posté(e) le 16 janvier 2008 Information très intéressante ! Merci ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
ASFI Posté(e) le 16 janvier 2008 Partager Posté(e) le 16 janvier 2008 Information très intéressante ! Merci ! Bonjour, C'est possible d'avoir une explication plus simple, un exemple avec plein de petites images Lien vers le commentaire Partager sur d’autres sites More sharing options...
ikeke Posté(e) le 16 janvier 2008 Partager Posté(e) le 16 janvier 2008 Bonjour, C'est possible d'avoir une explication plus simple, un exemple avec plein de petites images Je vais laisser notre ami détailler car je n'ai pas l'acces telnet sur mon nas depuis le boulot et comme je ne connais pas les chemins d'acces aux fichiers par coeur..... Lien vers le commentaire Partager sur d’autres sites More sharing options...
momo Posté(e) le 17 janvier 2008 Auteur Partager Posté(e) le 17 janvier 2008 salut, dans le répertoire /etc, il y a deux fichiers: hosts.allow hosts.deny j'en avais marre d'etre scanné ou "brute forcé" sur le ftp et j'ai résolu ce problème de cette façon. dans le fichier hosts.deny, tu ajoutes : ftpd : ALL : deny sshd : ALL : deny dans le fichier hosts.allow, tu ajoutes les @IP avec lesquelles tu te connectes à ton NAS: ftpd : XXX.XXX.XXX.XXX : allow ftpd : XXX.XXX.XXX.XXX : allow ftpd : 192.168.1.0/255.255.255.0 : allow sshd : XXX.XXX.XXX.XXX : allow sshd : 192.168.1.0/255.255.255.0 : allow sshd : XXX.XXX.XXX.XXX : allow et maintenant, dans le /var/log/messages, j'ai des entrées du type : Jan 17 13:39:17 ftpd[969]: ftpd.c (1091) FTP refused connection from XXX me voilà un peu plus tranquille ... Lien vers le commentaire Partager sur d’autres sites More sharing options...
ikeke Posté(e) le 17 janvier 2008 Partager Posté(e) le 17 janvier 2008 Autant pour le SSH je trouve ca très bien, autant pour le FTP je trouve ca trop restrictif. Du moins c'est ingérable quand tu as un ftp à disposition d'amis et que tu ne peux donc pas forcément prévoir de quelle ip ils vont se connecter... Tout dépend donc de l'utilisation qu'on en fait En tout cas merci pour l'info qui sera super utile ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
momo Posté(e) le 17 janvier 2008 Auteur Partager Posté(e) le 17 janvier 2008 Autant pour le SSH je trouve ca très bien, autant pour le FTP je trouve ca trop restrictif. Du moins c'est ingérable quand tu as un ftp à disposition d'amis et que tu ne peux donc pas forcément prévoir de quelle ip ils vont se connecter... Tout dépend donc de l'utilisation qu'on en fait En tout cas merci pour l'info qui sera super utile ! pour le FTP, je le conçois ... sauf si IP fixe ... sinon, tu peux remplacer l'@IP par le nom de domaine (genre chez Free *.proxad.net). mais c'est déjà mieux que d'avoir les chinois et les coréens qui essaient durant des heures de rentrer. Lien vers le commentaire Partager sur d’autres sites More sharing options...
ASFI Posté(e) le 17 janvier 2008 Partager Posté(e) le 17 janvier 2008 salut, dans le répertoire /etc, il y a deux fichiers: hosts.allow hosts.deny j'en avais marre d'etre scanné ou "brute forcé" sur le ftp et j'ai résolu ce problème de cette façon. dans le fichier hosts.deny, tu ajoutes : ftpd : ALL : deny sshd : ALL : deny dans le fichier hosts.allow, tu ajoutes les @IP avec lesquelles tu te connectes à ton NAS: ftpd : XXX.XXX.XXX.XXX : allow ftpd : XXX.XXX.XXX.XXX : allow ftpd : 192.168.1.0/255.255.255.0 : allow sshd : XXX.XXX.XXX.XXX : allow sshd : 192.168.1.0/255.255.255.0 : allow sshd : XXX.XXX.XXX.XXX : allow et maintenant, dans le /var/log/messages, j'ai des entrées du type : Jan 17 13:39:17 ftpd[969]: ftpd.c (1091) FTP refused connection from XXX me voilà un peu plus tranquille ... Bonjour, Merci momo pour cette explication Lien vers le commentaire Partager sur d’autres sites More sharing options...
ikeke Posté(e) le 17 janvier 2008 Partager Posté(e) le 17 janvier 2008 pour le FTP, je le conçois ... sauf si IP fixe ... sinon, tu peux remplacer l'@IP par le nom de domaine (genre chez Free *.proxad.net). mais c'est déjà mieux que d'avoir les chinois et les coréens qui essaient durant des heures de rentrer. oui mais je ne veux pas restreindre mes utilisateurs a ne pouvoir se connecter par ftp que de chez eux. Même pour moi c'est trop de contrainte, j'accéde facilement à mes données par ftp depuis chez des amis, le boulot, ... donc trop galère à gérer Par ailleurs, j'avoue que je n'ai pas trop de probleme de scan du port ftp... en 6 mois d'utilisation sur le port 21, j'ai du avoir maximum 15 adresses bloquées. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Echo1 Posté(e) le 2 mars 2008 Partager Posté(e) le 2 mars 2008 Bonjour, si vous avez des problèmes avec nos amis chinois et autres petit H@ck3rs en herbe étrangé, vous pouvez mettre dans vos fichiers autorisé hosts.allow fr.proxad 62.147/16 81.56/15 82.64/14 82.224/11 212.27.32/19 213.228/18 fr.ldcomnet 62.39/16 62.62.128/17 62.106.128/17 .118/15 81.185/16 84.96/13 86.64/12 194.242.160/19 195.3.0/18 195.146.192/19 212.30.96/19 212.94.160/19 213.203.64/18 fr.telecom 62.160/16 62.161/16 .8/13 81.48/13 81.80/16 81.248/13 82.120/13 83.112/14 83.192/12 86.192/10 193.248/14 193.252/15 194.2/16 194.3/16 194.51/18 194.51.64/18 194.51.128/17 194.206/16 194.250/16 195.6/16 195.25/16 195.101/16 212.234/16 213.56/16 217.108/15 217.128/16 217.167/16 Alors pour les explications (qu'est-ce que c'est que çà ) Se sont les ranges acheté par les FAI Française. vérifié vos adresse de sorti sur le NET et vous verrez Donc sauf entreprise ayant acheté un lien chez COLT ou autre fournisseur non francophone, n'oublié pas votre range local 192.168.?.? Ceci vous permetra de couvrir 97% des adresses IP française et vraisemblablement 100% des adresses de vos potes en france. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Damien Posté(e) le 25 avril 2008 Partager Posté(e) le 25 avril 2008 Bonjour, Je crois qu'il y a une erreur sur le message pour les ip Ce smiley est censé remplacer quoi ? >>> Lien vers le commentaire Partager sur d’autres sites More sharing options...
on4hu Posté(e) le 25 avril 2008 Partager Posté(e) le 25 avril 2008 quatrevingt quand tu ecrit 8O tu as ... c'est un bug de ce forum ... solution pour écrire port80 tu le colle sinon port le bug a le dessus! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Damien Posté(e) le 26 avril 2008 Partager Posté(e) le 26 avril 2008 Merci Une solution intermédiaire à ce "bug" serait de changer le raccourci du smiley genre $ mais bon Lien vers le commentaire Partager sur d’autres sites More sharing options...
Aiolizator Posté(e) le 5 juin 2008 Partager Posté(e) le 5 juin 2008 Pour moi, la base pour éviter les scans répétés et tentatives de cassage de mot de passe par force brute, c'est de ne pas utiliser les numéros de ports standard (21 pour FTP, 22 pour SSH) mais 43518 ou 2345 par exemple. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Frederic Posté(e) le 3 juillet 2008 Partager Posté(e) le 3 juillet 2008 salut,si comme moi vous en avez marre d'etre scanné sur le port 22 et de trouver dans les logs ceci ... Jan 16 02:52:49 sshd[32335]: Failed password for invalid user joseph from 218.155.21.107 port 37597 ssh2 alors il suffit de mettre dans le fichier hosts.deny l'entrée sshd : ALL et les entrées correspondant à vos @IP securisés dans le fichier hosts.allow du type sshd : XXX.XXX.XXX.XXX. Cela marche aussi pour le ftp. Et vous voilà en partie protégé des intrusions par ssh ou ftp. Bonjour, J'ai essayé avec sshd:deny et ALL:ALL:deny dans hosts.deny et le hosts.allow est vide et personne n'est bloqué pour se connecter avec SSH alors que la ligne du hosts.deny devrait être la seule ligne active. J'ai essayé d'installer TCPWrappers via ipkg, mais il ne semble pas qu'il soit compilé pour le syno car j'ai les messages suivants: DiskStation> tcpdchk -v warning: /dev/null: world writable warning: REAL_DAEMON_DIR /dev/null is not a directory warning: /etc/inetd.conf, line 1: /dev/null/telnetd: file lookup: Not a director et je n'arrive à bloquer personne. tcpdmatch m'affiche que tout le monde est autorisé à se connecter ce que je peux constater d'ailleurs. Bref, as-tu installé TCPWrappers (via ipkg ou autre) et quelle configuration as-tu mis en place pour que ça fonctionne ? Cordialement Frédéric Lien vers le commentaire Partager sur d’autres sites More sharing options...
Frederic Posté(e) le 7 juillet 2008 Partager Posté(e) le 7 juillet 2008 pour bloquer l'accès extérieur ALL:ALL dans le fichier hosts.deny et non ALL:ALL:DENY et ALL:LOCAL dans le hosts.allow pour que tout le monde puisse se connecter a travers le réseau local sur tout les protocoles HTTP: ALL pour l'accès au serveur HTTP depuis l'extérieur du reseau Bonjour, J'ai essayé les deux formules, aucune ne fonctionne. Quelle version de TCPWrapper utilisez-vous ? Les commandes tcpdchk et tcpdmatch vous permettent-elles de valider votre configuration hosts.deny et hosts.allow ? Cordialement Frédéric Lien vers le commentaire Partager sur d’autres sites More sharing options...
branqueira Posté(e) le 8 octobre 2008 Partager Posté(e) le 8 octobre 2008 cela ne fonctionne pas avec sshd. pour que le hosts.allow et hosts.deny soit pris en compte par sshd. il faut que sshd soit compiler avec la librairie tcpwrappers. pour ceux qui sont motivés, j'ai trouvé le lien expliquant la manipulation : http://www.ssh.com/support/documentation/o...rs_Support.html si quelqu'un a deja essayé, je voudrais bien savoir si ca fonctionne bien Lien vers le commentaire Partager sur d’autres sites More sharing options...
-Fred- Posté(e) le 19 novembre 2008 Partager Posté(e) le 19 novembre 2008 Je viens à peine d'ouvrir le port 22 sur mon routeur que je viens d'avoir une attaque de ce genre (avec en prime mon syno qui a planté). Donc pour le moment, je le referme. Autoriser des IP qu'on connait c'est bien mais quand on veux se connecter à distance depuis n'importe où depuis une machine que n'a pas d'IP fixe, c'est un peu plus dur à gérer. Il n'est pas du tout possible de d'autoriser un nombre limité de tentative de connections comme pour le service ftp? --- Fred --- Lien vers le commentaire Partager sur d’autres sites More sharing options...
WahJam Posté(e) le 19 novembre 2008 Partager Posté(e) le 19 novembre 2008 Je viens à peine d'ouvrir le port 22 sur mon routeur que je viens d'avoir une attaque de ce genre (avec en prime mon syno qui a planté). Donc pour le moment, je le referme. Tu peux peut être choisir un autre port que le 22, qui sera moins scanné, en créant sur ton routeur une redirection de ce port en ip externe vers le port 22 de l'ip du syno sur le réseau local. Pascal Lien vers le commentaire Partager sur d’autres sites More sharing options...
-Fred- Posté(e) le 20 novembre 2008 Partager Posté(e) le 20 novembre 2008 Merci, je vais regarder si c'est faisable avec mon modem/routeur (netgear dg834g). --- Fred --- Lien vers le commentaire Partager sur d’autres sites More sharing options...
PatrickH Posté(e) le 20 novembre 2008 Partager Posté(e) le 20 novembre 2008 Merci, je vais regarder si c'est faisable avec mon modem/routeur (netgear dg834g). --- Fred --- A ma connaissance le DG834G ne permet pas de faire un "re-mapping" entre n° de ports différents ! Patrick Lien vers le commentaire Partager sur d’autres sites More sharing options...
-Fred- Posté(e) le 20 novembre 2008 Partager Posté(e) le 20 novembre 2008 Effectivement je ne trouve pas d'infos concernant les redirections de ports. --- Fred --- Lien vers le commentaire Partager sur d’autres sites More sharing options...
Invité Posté(e) le 20 novembre 2008 Partager Posté(e) le 20 novembre 2008 Effectivement je ne trouve pas d'infos concernant les redirections de ports. --- Fred --- possible avec un routeur dlink655, ainsi qu'un ipfiltering (par port) Lien vers le commentaire Partager sur d’autres sites More sharing options...
catimimi Posté(e) le 20 novembre 2008 Partager Posté(e) le 20 novembre 2008 A ma connaissance le DG834G ne permet pas de faire un "re-mapping" entre n° de ports différents ! Patrick Bonjour, Non, il ne le permet pas, c'est une des raisons pour lesquelles je suis passé au couple "Livebox Inventel" qui le permet + routeur Netgear, et je n'ai aucune attaque de ce genre. Cordialement. Michel Lien vers le commentaire Partager sur d’autres sites More sharing options...
MS_Totor Posté(e) le 20 novembre 2008 Partager Posté(e) le 20 novembre 2008 salut à tous une solution qui marche très bien pour linux en général c'est FAIL2BAN, c'est TOP pour limiter les scans et brutes forces sur pas mal de services ssh, ftp, smtp, .htaccess web etc.... la liste est longue, celà controle les logs, et permet des reglages assez poussés un exemple de reglage si de 3 tentatives de login erronées sur le port ssh (22), en n secondes ou minutes, bannissement de l'IP pendant n secondes ou n jour ssh est très bien protégé si tu change le port d'ecoute 22 en autre chose....xx022 par exemple, couplé avec une interdiction de login en root, si tu implémente en plus un échange de clés partagés bien longue, alors c'est tranquille le fichier de configuration de ssh est sshd.conf pour les curieux au résultat tu limite la possibilité à un vilain garcon de tenter de trouver le login, même si il passe par un proxy, par contre sur synology, je ne sais pas à base de quoi l'OS est fait, debian like ??? je ne sais pas si il y a un portage pour ce paquet, étant futur utilisateur de synology, ca m'intéressera si il y a une réponse oui Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.