bonsoir,
depuis hier soir sur mon serveur FTP j'ai des tentative de connections
(1567 tentatives) en provenance d'une unique IP (61.129.72.174). Les
tentative de connections se font avec comme loggin 'Administrator' et
des mots de passe qui semble choisi dans un dictionnaire.
*****
OrgName: Asia Pacific Network Information Centre
OrgID: APNIC
Address: PO Box 2131
City: Milton
StateProv: QLD
PostalCode: 4064
Country: AU
ReferralServer: whois://whois.apnic.net
NetRange: 61.0.0.0 - 61.255.255.255
CIDR: 61.0.0.0/8
NetName: APNIC3
NetHandle: NET-61-0-0-0-1
Parent:
NetType: Allocated to APNIC
NameServer: NS1.APNIC.NET
NameServer: NS3.APNIC.NET
NameServer: NS4.APNIC.NET
NameServer: NS-SEC.RIPE.NET
NameServer: TINNIE.ARIN.NET
Comment: This IP address range is not registered in the ARIN
database.
Comment: For details, refer to the APNIC Whois Database via
Comment: WHOIS.APNIC.NET or http://www.apnic.net/apnic-bin/whois2.pl
Comment: ** IMPORTANT NOTE: APNIC is the Regional Internet Registry
Comment: for the Asia Pacific region. APNIC does not operate networks
Comment: using this IP address range and is not able to investigate
Comment: spam or abuse reports relating to these addresses. For more
Comment: help, refer to http://www.apnic.net/info/faq/abuse
Comment:
RegDate: 1997-04-25
Updated: 2005-05-20
"Cedric Blancher" a écrit dans le message de news:
J'ai bloqué l'acces à toute la plage IP 61.*.*.*,
Bourrin, et surtout pas franchement utile à mon sens, dans la mesure où ces scans sont souvent le fait d'un bot ou autre script de ce genre qui peut se retrouver lancé d'ailleurs.
je n'aurai pas dit mieux moi même c'est exactement ce que je voulai faire comprendre...
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme SSH par exemple, soit avec scp, soit avec sftp. En outre, ça évite de se poser des questions sur les éventuels problèmes de NAT. Pas mal de client FTP arrivent maintenant avec le support SFTP, comme Gozilla par exemple. Sinon, on a aussi winscp. En outre, SSH permet des authentification par clés publiques RSA ou DSA, ce qui évacue de facto les attaques sur les login/passwd.
Utiliser des mots de passe solides peut être également envisagé.
c'est présicément le mieux à faire, je procède ainsi moi même :)
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message
de news: pan.2006.07.23.09.03.17.697646@cartel-securite.fr...
J'ai bloqué l'acces à toute la plage IP 61.*.*.*,
Bourrin, et surtout pas franchement utile à mon sens, dans la mesure
où
ces scans sont souvent le fait d'un bot ou autre script de ce genre
qui
peut se retrouver lancé d'ailleurs.
je n'aurai pas dit mieux moi même c'est exactement ce que je voulai
faire comprendre...
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme
SSH par exemple, soit avec scp, soit avec sftp. En outre, ça évite de
se poser des questions sur les éventuels problèmes de NAT. Pas mal de
client FTP arrivent maintenant avec le support SFTP, comme Gozilla par
exemple. Sinon, on a aussi winscp. En outre, SSH permet des
authentification par clés publiques RSA ou DSA, ce qui évacue de facto
les attaques sur les login/passwd.
Utiliser des mots de passe solides peut être également envisagé.
c'est présicément le mieux à faire, je procède ainsi moi même :)
"Cedric Blancher" a écrit dans le message de news:
J'ai bloqué l'acces à toute la plage IP 61.*.*.*,
Bourrin, et surtout pas franchement utile à mon sens, dans la mesure où ces scans sont souvent le fait d'un bot ou autre script de ce genre qui peut se retrouver lancé d'ailleurs.
je n'aurai pas dit mieux moi même c'est exactement ce que je voulai faire comprendre...
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme SSH par exemple, soit avec scp, soit avec sftp. En outre, ça évite de se poser des questions sur les éventuels problèmes de NAT. Pas mal de client FTP arrivent maintenant avec le support SFTP, comme Gozilla par exemple. Sinon, on a aussi winscp. En outre, SSH permet des authentification par clés publiques RSA ou DSA, ce qui évacue de facto les attaques sur les login/passwd.
Utiliser des mots de passe solides peut être également envisagé.
c'est présicément le mieux à faire, je procède ainsi moi même :)
Eric Razny
Le Sun, 23 Jul 2006 11:33:08 +0000, Cedric Blancher a écrit :
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme SSH par exemple, soit avec scp, soit avec sftp.
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi accès à l'arborescence complète du système [1]
J'ai eu le soucis pas plus tard qu'il y a 15 jours, avec un intervenant qui préfèrait du ftp parce que son serveur ftp fait du chroot "facilement". Pour moi ce n'était pas jouable car le flux passe sur un lan potentiellement hostile.
Je lui ai envoyé quelques liens et maintenant je finis dans un environnement chrooté mais ce serait cool qu'openssh intègre un jour cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser que les packages de sa distrib, mais heureusement il était ouvert aux questions de sécu)
Eric.
[1] il faudrait mieux ne pas être vulnérable dans ce cas aussi, chroot n'est pas une protection absolue mais ceinture et bretelles, toussa...
[2] au moins pour scp. Pour ssh il faut de toute manière un chroot classique par construction.
Le Sun, 23 Jul 2006 11:33:08 +0000, Cedric Blancher a écrit :
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme
SSH par exemple, soit avec scp, soit avec sftp.
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi
accès à l'arborescence complète du système [1]
J'ai eu le soucis pas plus tard qu'il y a 15 jours, avec un intervenant
qui préfèrait du ftp parce que son serveur ftp fait du chroot
"facilement". Pour moi ce n'était pas jouable car le flux passe sur un
lan potentiellement hostile.
Je lui ai envoyé quelques liens et maintenant je finis dans un
environnement chrooté mais ce serait cool qu'openssh intègre un jour
cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser
que les packages de sa distrib, mais heureusement il était ouvert aux
questions de sécu)
Eric.
[1] il faudrait mieux ne pas être vulnérable dans ce cas aussi, chroot
n'est pas une protection absolue mais ceinture et bretelles, toussa...
[2] au moins pour scp. Pour ssh il faut de toute manière un chroot
classique par construction.
Le Sun, 23 Jul 2006 11:33:08 +0000, Cedric Blancher a écrit :
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme SSH par exemple, soit avec scp, soit avec sftp.
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi accès à l'arborescence complète du système [1]
J'ai eu le soucis pas plus tard qu'il y a 15 jours, avec un intervenant qui préfèrait du ftp parce que son serveur ftp fait du chroot "facilement". Pour moi ce n'était pas jouable car le flux passe sur un lan potentiellement hostile.
Je lui ai envoyé quelques liens et maintenant je finis dans un environnement chrooté mais ce serait cool qu'openssh intègre un jour cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser que les packages de sa distrib, mais heureusement il était ouvert aux questions de sécu)
Eric.
[1] il faudrait mieux ne pas être vulnérable dans ce cas aussi, chroot n'est pas une protection absolue mais ceinture et bretelles, toussa...
[2] au moins pour scp. Pour ssh il faut de toute manière un chroot classique par construction.
Vincent Bernat
OoO Lors de la soirée naissante du dimanche 23 juillet 2006, vers 17:00, Eric Razny disait:
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi accès à l'arborescence complète du système [1]
Il y a un truc qui s'appelle rssh et qui permet de facilement faire du chroot avec scp, sftp, rsync over ssh, cvs over ssh. -- #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT 2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
OoO Lors de la soirée naissante du dimanche 23 juillet 2006, vers
17:00, Eric Razny <news_01@razny.net> disait:
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi
accès à l'arborescence complète du système [1]
Il y a un truc qui s'appelle rssh et qui permet de facilement faire du
chroot avec scp, sftp, rsync over ssh, cvs over ssh.
--
#ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
OoO Lors de la soirée naissante du dimanche 23 juillet 2006, vers 17:00, Eric Razny disait:
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi accès à l'arborescence complète du système [1]
Il y a un truc qui s'appelle rssh et qui permet de facilement faire du chroot avec scp, sftp, rsync over ssh, cvs over ssh. -- #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT 2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
Eric Razny
Le Sun, 23 Jul 2006 15:00:24 +0000, ALBATOR a écrit :
Que vous indiquiez simplement quelque chose comme "dans un environnement avec un nombre restreint d'intervenant -ce qui limite les nuisances- j'ai choisi un port non standard pour limiter les logs d'attaque par dictionnaire", c'est une chose.
je réponds précisément aux besoins de celui qui à posté son problème ici,
C'est la que je ne suis pas d'accord avec vous. Vous avez résolu ce type de problème dans un environnement non standard (où vous semblez sur que les clients peuvent passer avec vos paramètrages). Mon post précédent indique pourquoi, dans le cas général, c'est une mauvaise idée de changer le port command du serveur ftp.
Amha Cedric répond, lui, précisement à la demande de l'OP, en présentant deux solutions, une radicale (la meilleure quand on en a la possibilité), passer à sftp ou scp, l'autre avoir une bonne politique des passwords.
La seconde est, malheureusement parfois nécessaire car certains utilisateurs remontent les infos via un client ftp intégré dans leur appli et il ne voudront pas en changer ou faire une partie du boulot à la main. Par parenthèse c'est encore une raison de plus de ne pas employer dans le cas général votre "solution" qui, amha, est vraiment une source d'emmerdes sans fin pour celui qui a à la subir.
A noter que la politique du bon password se heurte aux communications en clair...
Quand aux logs je pense que Frédéric va devoir faire avec :-/ Il me semble utile d'en profiter pour commencer à analyser plus finement les logs pour isoler ce qui pourrait être une attaque au milieu du bruit ambient (et ça c'est un sacré boulot aussi)
je n'ai jamais prétendu que mon conseil pouvais faire face à du 0-day je l'ai d'ailleurs précisé mais nombre de pseudo spécialistes font tout le nécéssaire pour faire monter une mayonnaise que je n'ai aucune envie de suivre du fait du HS par rapport au post initial.
C'est vous qui encouragez les lecteurs à l'attaque de votre serveur, pas moi. Je suis bien trop mauvais pour pouvoir prendre ce genre de risque.
Quand vous écrivez : "à l'origine celui qui se trouve avec un soucis de sécurité n'est pas un admin qui gère des milliers de clients, il faut adapter ses résolutions en fonction des besoins, hors dans le cas présent mon conseil est le mieux, alors la polémique des pseudo expert je m'en cogne." vous commettez à mon avis deux erreurs :
- qu'on gère 2000 client ou 1 seul il y a un risque de sécu qui doit être pris en compte. Le changement de port ne règle aucun problème de sécu, il limite simplement la quantité de logs générés, en générant une source d'emmerdements potentiels qui risque d'être bien plus gênante que quelques logs.
- adapter son conseil à l'interlocuteur en face c'est parfait. Je ne l'ai vu nulle part suggérer qu'il maitrisait l'environnement des clients. Je persiste donc a dire que votre solution n'est certainement pas la meilleure.
Enfin avec un "mon conseil est le mieux" sans même argumenter (ce qu'un autre posteur vous a demandé) est une stupidité sans nom au niveau de la sécurité. Quand un inconnu vient me voir avec un superbe "j'ai la solution" mon premier réflexe est la méfiance. S'il me donne par contre des arguments que je juge probants alors je peux intelligement décider s'il est interressant ou non d'appliquer ses conseils.
Ca ne veut pas dire que je ne fais jamais confiance (il y a quelques personnes ici que -si elle me disent fait ça ou ça, je t'explique après, lors d'une d'une urgence- je suis prêt à suivre sans vérification[1]) mais un "ça fait 10 ans que... j'ai raison..." m'incite surtout à passer mon chemin.
Je vous laisse donc avec vos certitudes.
Cordialement,
Eric
[1] Sachant que sauf cas extrèmement particulier ces personnes, compétantes en sécurité, prendront de toute façon le temps d'expliquer le pourquoi du comment.
Le Sun, 23 Jul 2006 15:00:24 +0000, ALBATOR a écrit :
Que vous indiquiez simplement quelque chose comme "dans un
environnement avec un nombre restreint d'intervenant -ce qui limite les
nuisances- j'ai
choisi un port non standard pour limiter les logs d'attaque par
dictionnaire", c'est une chose.
je réponds précisément aux besoins de celui qui à posté son
problème ici,
C'est la que je ne suis pas d'accord avec vous. Vous avez résolu ce type
de problème dans un environnement non standard (où vous semblez sur que
les clients peuvent passer avec vos paramètrages). Mon post précédent
indique pourquoi, dans le cas général, c'est une mauvaise idée de
changer le port command du serveur ftp.
Amha Cedric répond, lui, précisement à la demande de l'OP, en
présentant deux solutions, une radicale (la meilleure quand on en a la
possibilité), passer à sftp ou scp, l'autre avoir une bonne politique
des passwords.
La seconde est, malheureusement parfois nécessaire car certains
utilisateurs remontent les infos via un client ftp intégré dans leur
appli et il ne voudront pas en changer ou faire une partie du boulot à la
main. Par parenthèse c'est encore une raison de plus de ne pas employer
dans le cas général votre "solution" qui, amha, est vraiment une source
d'emmerdes sans fin pour celui qui a à la subir.
A noter que la politique du bon password se heurte aux communications en
clair...
Quand aux logs je pense que Frédéric va devoir faire avec :-/ Il me
semble utile d'en profiter pour commencer à analyser plus finement les
logs pour isoler ce qui pourrait être une attaque au milieu du bruit
ambient (et ça c'est un sacré boulot aussi)
je n'ai jamais prétendu que mon conseil pouvais faire face à du
0-day je l'ai d'ailleurs précisé mais nombre de pseudo spécialistes
font tout le nécéssaire pour faire monter une mayonnaise que je n'ai
aucune envie de suivre du fait du HS par rapport au post initial.
C'est vous qui encouragez les lecteurs à l'attaque de votre serveur, pas
moi. Je suis bien trop mauvais pour pouvoir prendre ce genre de risque.
Quand vous écrivez : "à l'origine celui qui se trouve avec un soucis de
sécurité n'est pas un admin qui gère des milliers de clients, il faut
adapter ses résolutions en fonction des besoins, hors dans le cas
présent mon conseil est le mieux, alors la polémique des pseudo expert
je m'en cogne." vous commettez à mon avis deux erreurs :
- qu'on gère 2000 client ou 1 seul il y a un risque de sécu qui doit
être pris en compte. Le changement de port ne règle aucun problème de
sécu, il limite simplement la quantité de logs générés, en générant
une source d'emmerdements potentiels qui risque d'être bien plus gênante
que quelques logs.
- adapter son conseil à l'interlocuteur en face c'est parfait. Je ne l'ai
vu nulle part suggérer qu'il maitrisait l'environnement des clients. Je
persiste donc a dire que votre solution n'est certainement pas la
meilleure.
Enfin avec un "mon conseil est le mieux" sans même argumenter (ce qu'un
autre posteur vous a demandé) est une stupidité sans nom au niveau de la
sécurité. Quand un inconnu vient me voir avec un superbe "j'ai la
solution" mon premier réflexe est la méfiance. S'il me donne par contre
des arguments que je juge probants alors je peux intelligement décider
s'il est interressant ou non d'appliquer ses conseils.
Ca ne veut pas dire que je ne fais jamais confiance (il y a quelques
personnes ici que -si elle me disent fait ça ou ça, je t'explique
après, lors d'une d'une urgence- je suis prêt à suivre sans
vérification[1]) mais un "ça fait 10 ans que... j'ai raison..." m'incite
surtout à passer mon chemin.
Je vous laisse donc avec vos certitudes.
Cordialement,
Eric
[1] Sachant que sauf cas extrèmement particulier ces personnes,
compétantes en sécurité, prendront de toute façon le temps d'expliquer
le pourquoi du comment.
Le Sun, 23 Jul 2006 15:00:24 +0000, ALBATOR a écrit :
Que vous indiquiez simplement quelque chose comme "dans un environnement avec un nombre restreint d'intervenant -ce qui limite les nuisances- j'ai choisi un port non standard pour limiter les logs d'attaque par dictionnaire", c'est une chose.
je réponds précisément aux besoins de celui qui à posté son problème ici,
C'est la que je ne suis pas d'accord avec vous. Vous avez résolu ce type de problème dans un environnement non standard (où vous semblez sur que les clients peuvent passer avec vos paramètrages). Mon post précédent indique pourquoi, dans le cas général, c'est une mauvaise idée de changer le port command du serveur ftp.
Amha Cedric répond, lui, précisement à la demande de l'OP, en présentant deux solutions, une radicale (la meilleure quand on en a la possibilité), passer à sftp ou scp, l'autre avoir une bonne politique des passwords.
La seconde est, malheureusement parfois nécessaire car certains utilisateurs remontent les infos via un client ftp intégré dans leur appli et il ne voudront pas en changer ou faire une partie du boulot à la main. Par parenthèse c'est encore une raison de plus de ne pas employer dans le cas général votre "solution" qui, amha, est vraiment une source d'emmerdes sans fin pour celui qui a à la subir.
A noter que la politique du bon password se heurte aux communications en clair...
Quand aux logs je pense que Frédéric va devoir faire avec :-/ Il me semble utile d'en profiter pour commencer à analyser plus finement les logs pour isoler ce qui pourrait être une attaque au milieu du bruit ambient (et ça c'est un sacré boulot aussi)
je n'ai jamais prétendu que mon conseil pouvais faire face à du 0-day je l'ai d'ailleurs précisé mais nombre de pseudo spécialistes font tout le nécéssaire pour faire monter une mayonnaise que je n'ai aucune envie de suivre du fait du HS par rapport au post initial.
C'est vous qui encouragez les lecteurs à l'attaque de votre serveur, pas moi. Je suis bien trop mauvais pour pouvoir prendre ce genre de risque.
Quand vous écrivez : "à l'origine celui qui se trouve avec un soucis de sécurité n'est pas un admin qui gère des milliers de clients, il faut adapter ses résolutions en fonction des besoins, hors dans le cas présent mon conseil est le mieux, alors la polémique des pseudo expert je m'en cogne." vous commettez à mon avis deux erreurs :
- qu'on gère 2000 client ou 1 seul il y a un risque de sécu qui doit être pris en compte. Le changement de port ne règle aucun problème de sécu, il limite simplement la quantité de logs générés, en générant une source d'emmerdements potentiels qui risque d'être bien plus gênante que quelques logs.
- adapter son conseil à l'interlocuteur en face c'est parfait. Je ne l'ai vu nulle part suggérer qu'il maitrisait l'environnement des clients. Je persiste donc a dire que votre solution n'est certainement pas la meilleure.
Enfin avec un "mon conseil est le mieux" sans même argumenter (ce qu'un autre posteur vous a demandé) est une stupidité sans nom au niveau de la sécurité. Quand un inconnu vient me voir avec un superbe "j'ai la solution" mon premier réflexe est la méfiance. S'il me donne par contre des arguments que je juge probants alors je peux intelligement décider s'il est interressant ou non d'appliquer ses conseils.
Ca ne veut pas dire que je ne fais jamais confiance (il y a quelques personnes ici que -si elle me disent fait ça ou ça, je t'explique après, lors d'une d'une urgence- je suis prêt à suivre sans vérification[1]) mais un "ça fait 10 ans que... j'ai raison..." m'incite surtout à passer mon chemin.
Je vous laisse donc avec vos certitudes.
Cordialement,
Eric
[1] Sachant que sauf cas extrèmement particulier ces personnes, compétantes en sécurité, prendront de toute façon le temps d'expliquer le pourquoi du comment.
FAb
Eric Razny writes:
Le Sun, 23 Jul 2006 11:33:08 +0000, Cedric Blancher a écrit :
Je lui ai envoyé quelques liens et maintenant je finis dans un environnement chrooté mais ce serait cool qu'openssh intègre un jour cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser que les packages de sa distrib, mais heureusement il était ouvert aux questions de sécu)
Il peut pas chroot-er le compte destination ? Ou jouer avec les options ssh du fichier authorized_keys ? Genre authoriser que la commande tar et tu pousses avec (cd src; tar cvf - rep1 rep2... repN)|(ssh "(tar xvf -)")
Ouais ça fait un bricolage, j'avoue.
FAb
Eric Razny <news_01@razny.net> writes:
Le Sun, 23 Jul 2006 11:33:08 +0000, Cedric Blancher a écrit :
Je lui ai envoyé quelques liens et maintenant je finis dans un
environnement chrooté mais ce serait cool qu'openssh intègre un jour
cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser
que les packages de sa distrib, mais heureusement il était ouvert aux
questions de sécu)
Il peut pas chroot-er le compte destination ?
Ou jouer avec les options ssh du fichier authorized_keys ? Genre authoriser que
la commande tar et tu pousses avec
(cd src; tar cvf - rep1 rep2... repN)|(ssh bidule@server "(tar xvf -)")
Le Sun, 23 Jul 2006 11:33:08 +0000, Cedric Blancher a écrit :
Je lui ai envoyé quelques liens et maintenant je finis dans un environnement chrooté mais ce serait cool qu'openssh intègre un jour cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser que les packages de sa distrib, mais heureusement il était ouvert aux questions de sécu)
Il peut pas chroot-er le compte destination ? Ou jouer avec les options ssh du fichier authorized_keys ? Genre authoriser que la commande tar et tu pousses avec (cd src; tar cvf - rep1 rep2... repN)|(ssh "(tar xvf -)")
Ouais ça fait un bricolage, j'avoue.
FAb
Kevin Denis
Le 23-07-2006, Eric Razny a écrit :
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme SSH par exemple, soit avec scp, soit avec sftp.
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi accès à l'arborescence complète du système [1]
et avec scponly?
Pour une facilite de configuration, ca semble bon.
-- Kevin
Le 23-07-2006, Eric Razny <news_01@razny.net> a écrit :
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme
SSH par exemple, soit avec scp, soit avec sftp.
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi
accès à l'arborescence complète du système [1]
et avec scponly?
Pour une facilite de configuration, ca semble bon.
mais y a t'il d'autres choses à faire ou à mettre en place ?
Utiliser un protocole de transfert de fichiers plus sûr que FTP, comme SSH par exemple, soit avec scp, soit avec sftp.
Le seul pseudo obstacle est que par défaut avec scp ou sftp on a aussi accès à l'arborescence complète du système [1]
et avec scponly?
Pour une facilite de configuration, ca semble bon.
-- Kevin
Eric Razny
Le Mon, 24 Jul 2006 15:46:32 +0000, FAb a écrit :
Je lui ai envoyé quelques liens et maintenant je finis dans un environnement chrooté mais ce serait cool qu'openssh intègre un jour cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser que les packages de sa distrib, mais heureusement il était ouvert aux questions de sécu)
Il peut pas chroot-er le compte destination ?
C'est ce que je lui ai fait faire ("maintenant je finis dans un environnement chrooté"). En fait il n'avait simplement jamais fait ça et je suppose qu'il supposait que ce serait plus dur qu'en réalité. Il a aussi (est c'est son choix souverain) la volonté de ne pas avoir trop de "spécialisation" à faire quand il réinstalle sa distrib (brrr, une fedora, que j'assimile à un debian sid en production mais bon :) ).
Ou jouer avec les options ssh du fichier authorized_keys ? authorized_keys2 déjà en place et possibilités minimales de faire mumuse
dans la cage :)
Ouais ça fait un bricolage, j'avoue.
Ah bon? :)
C'est pour ça que je dis que ce serait cool un scp ou sftp avec en natif la possibilité de chroot.
Le Mon, 24 Jul 2006 15:46:32 +0000, FAb a écrit :
Je lui ai envoyé quelques liens et maintenant je finis dans un
environnement chrooté mais ce serait cool qu'openssh intègre un jour
cette fonctionnalité nativement[2] (mon intervenant préférait
n'utiliser que les packages de sa distrib, mais heureusement il était
ouvert aux questions de sécu)
Il peut pas chroot-er le compte destination ?
C'est ce que je lui ai fait faire ("maintenant je finis dans un
environnement chrooté"). En fait il n'avait simplement jamais fait ça et
je suppose qu'il supposait que ce serait plus dur qu'en réalité. Il a
aussi (est c'est son choix souverain) la volonté de ne pas avoir trop de
"spécialisation" à faire quand il réinstalle sa distrib (brrr, une
fedora, que j'assimile à un debian sid en production mais bon :) ).
Ou jouer avec les options ssh du fichier authorized_keys ?
authorized_keys2 déjà en place et possibilités minimales de faire mumuse
dans la cage :)
Ouais ça fait un bricolage, j'avoue.
Ah bon? :)
C'est pour ça que je dis que ce serait cool un scp ou sftp avec en natif
la possibilité de chroot.
Je lui ai envoyé quelques liens et maintenant je finis dans un environnement chrooté mais ce serait cool qu'openssh intègre un jour cette fonctionnalité nativement[2] (mon intervenant préférait n'utiliser que les packages de sa distrib, mais heureusement il était ouvert aux questions de sécu)
Il peut pas chroot-er le compte destination ?
C'est ce que je lui ai fait faire ("maintenant je finis dans un environnement chrooté"). En fait il n'avait simplement jamais fait ça et je suppose qu'il supposait que ce serait plus dur qu'en réalité. Il a aussi (est c'est son choix souverain) la volonté de ne pas avoir trop de "spécialisation" à faire quand il réinstalle sa distrib (brrr, une fedora, que j'assimile à un debian sid en production mais bon :) ).
Ou jouer avec les options ssh du fichier authorized_keys ? authorized_keys2 déjà en place et possibilités minimales de faire mumuse
dans la cage :)
Ouais ça fait un bricolage, j'avoue.
Ah bon? :)
C'est pour ça que je dis que ce serait cool un scp ou sftp avec en natif la possibilité de chroot.
Gael Mauleon
Bon, j'avoue j'ai abandonné la discussion en cours... :)
Sinon pour au moins limiter le problème des scans et les tentatives de brute force sur ton FTP, tu peux jouer avec le module ipt_recent pour netfilter
$IPTABLES -A MASUPERCHAINE -p tcp --sport 1024: -m multiport --dports 21 -m state --state NEW -m recent --name ftp_brute --update --hitcount 10 -- seconds 60 -j DROP $IPTABLES -A MASUPERCHAINE -p tcp --sport 1024: -m multiport --dports 21 -m state --state NEW -m recent --name ftp_brute --set -j ACCEPT
Ici ipt_recent memorise les tupmes de connections sur le port 21, et bloque ensuite s'il se produit plus de 10 connexions sur 60s avec le même tuple. Par défaut les tables créés (ici ftp_brute) ont un maximum de 100 connexions suivies.
Ce n'est bien entendu qu'un exemple, voir http://www.snowman.net/projects/ipt_recent/ ou google :)
Bref, en jouant avec le module ipt_recent, eventuellement sur le nombre maximum de tentative de login par connexion dans la configuration de ton FTP et pourquoi pas un module de ban (pour proftpd -> http://www.castaglia.org/proftpd/modules/mod_ban.html) tu auras déjà fais un grand pas...
Gaël.
Bon, j'avoue j'ai abandonné la discussion en cours... :)
Sinon pour au moins limiter le problème des scans et les tentatives
de brute force sur ton FTP, tu peux jouer avec le module ipt_recent
pour netfilter
$IPTABLES -A MASUPERCHAINE -p tcp --sport 1024: -m multiport --dports 21 -m
state --state NEW -m recent --name ftp_brute --update --hitcount 10 --
seconds 60 -j DROP
$IPTABLES -A MASUPERCHAINE -p tcp --sport 1024: -m multiport --dports 21 -m
state --state NEW -m recent --name ftp_brute --set -j ACCEPT
Ici ipt_recent memorise les tupmes de connections sur le port 21, et bloque
ensuite s'il se produit plus de 10 connexions sur 60s avec le même tuple.
Par défaut les tables créés (ici ftp_brute) ont un maximum de 100
connexions suivies.
Ce n'est bien entendu qu'un exemple, voir
http://www.snowman.net/projects/ipt_recent/ ou google :)
Bref, en jouant avec le module ipt_recent, eventuellement sur le nombre
maximum de tentative de login par connexion dans la configuration de ton
FTP et pourquoi pas un module de ban (pour proftpd ->
http://www.castaglia.org/proftpd/modules/mod_ban.html) tu auras déjà fais
un grand pas...
Bon, j'avoue j'ai abandonné la discussion en cours... :)
Sinon pour au moins limiter le problème des scans et les tentatives de brute force sur ton FTP, tu peux jouer avec le module ipt_recent pour netfilter
$IPTABLES -A MASUPERCHAINE -p tcp --sport 1024: -m multiport --dports 21 -m state --state NEW -m recent --name ftp_brute --update --hitcount 10 -- seconds 60 -j DROP $IPTABLES -A MASUPERCHAINE -p tcp --sport 1024: -m multiport --dports 21 -m state --state NEW -m recent --name ftp_brute --set -j ACCEPT
Ici ipt_recent memorise les tupmes de connections sur le port 21, et bloque ensuite s'il se produit plus de 10 connexions sur 60s avec le même tuple. Par défaut les tables créés (ici ftp_brute) ont un maximum de 100 connexions suivies.
Ce n'est bien entendu qu'un exemple, voir http://www.snowman.net/projects/ipt_recent/ ou google :)
Bref, en jouant avec le module ipt_recent, eventuellement sur le nombre maximum de tentative de login par connexion dans la configuration de ton FTP et pourquoi pas un module de ban (pour proftpd -> http://www.castaglia.org/proftpd/modules/mod_ban.html) tu auras déjà fais un grand pas...
Gaël.
Nina Popravka
On 14 Jul 2006 17:17:04 GMT, (Frederic Salach) wrote:
bonsoir, depuis hier soir sur mon serveur FTP j'ai des tentative de connections (1567 tentatives) en provenance d'une unique IP (61.129.72.174). Les tentative de connections se font avec comme loggin 'Administrator' et des mots de passe qui semble choisi dans un dictionnaire.
Oui, moi aussi, à longueur de journée,et il est réglé pour bloquer l'IP au bout de 5 tentatives pour quelques heures le temps que le robot se calme, et ça me traumatise pas. J'utilise Cerberus telle la blairote que je suis, mais je suppose qu'on peut le faire avec la plupart des serveurs FTP. -- Nina
On 14 Jul 2006 17:17:04 GMT, cf_la_signature@email.jetable (Frederic
Salach) wrote:
bonsoir,
depuis hier soir sur mon serveur FTP j'ai des tentative de connections
(1567 tentatives) en provenance d'une unique IP (61.129.72.174). Les
tentative de connections se font avec comme loggin 'Administrator' et
des mots de passe qui semble choisi dans un dictionnaire.
Oui, moi aussi, à longueur de journée,et il est réglé pour bloquer
l'IP au bout de 5 tentatives pour quelques heures le temps que le
robot se calme, et ça me traumatise pas.
J'utilise Cerberus telle la blairote que je suis, mais je suppose
qu'on peut le faire avec la plupart des serveurs FTP.
--
Nina
On 14 Jul 2006 17:17:04 GMT, (Frederic Salach) wrote:
bonsoir, depuis hier soir sur mon serveur FTP j'ai des tentative de connections (1567 tentatives) en provenance d'une unique IP (61.129.72.174). Les tentative de connections se font avec comme loggin 'Administrator' et des mots de passe qui semble choisi dans un dictionnaire.
Oui, moi aussi, à longueur de journée,et il est réglé pour bloquer l'IP au bout de 5 tentatives pour quelques heures le temps que le robot se calme, et ça me traumatise pas. J'utilise Cerberus telle la blairote que je suis, mais je suppose qu'on peut le faire avec la plupart des serveurs FTP. -- Nina
cr0vax
Nina Popravka wrote:
On 14 Jul 2006 17:17:04 GMT, (Frederic Salach) wrote:
J'utilise Cerberus telle la blairote que je suis, mais je suppose qu'on peut le faire avec la plupart des serveurs FTP.
En fait, on peut le faire avec son FireWall, c'est peut-être plus simple de regrouper ensemble ces rêgles du même types sur un même logiciel, plutôt que sur différents services
Nina Popravka wrote:
On 14 Jul 2006 17:17:04 GMT, cf_la_signature@email.jetable (Frederic
Salach) wrote:
J'utilise Cerberus telle la blairote que je suis, mais je suppose
qu'on peut le faire avec la plupart des serveurs FTP.
En fait, on peut le faire avec son FireWall, c'est peut-être plus
simple de regrouper ensemble ces rêgles du même types sur un même
logiciel, plutôt que sur différents services
On 14 Jul 2006 17:17:04 GMT, (Frederic Salach) wrote:
J'utilise Cerberus telle la blairote que je suis, mais je suppose qu'on peut le faire avec la plupart des serveurs FTP.
En fait, on peut le faire avec son FireWall, c'est peut-être plus simple de regrouper ensemble ces rêgles du même types sur un même logiciel, plutôt que sur différents services
