Je fais tourner une Ubuntu 7.04 24h/24 avec apache2, vsftpd et ssh.
Et je viens d'avoir un problème: j'ai éteint le PC pour rebrancher une
nappe dans le PC et quand j'ai relancé la machine, je n'arrivais plus à
me logguer sous KDE, car certains fichiers avaient vu leurs droits
modifiés.
/dev/null était devenu crw------- , ce qui faisait foiré des test dans
mon ~/.bashrc (j'ai remis crw-rw-rw-)
mon répertoire /home/ftp appartenait à saned (UID=116) au lieu de ftp
(UID=117)
Le problème est que je n'ai aucune idée de quoi regarder dans les logs
pour chercher ce qui a été eventuellement fait sur la machine.
J'ai juste ça dans /var/log/auth.log:
8<-----------8<---------8<----------8<----------8<----------8<----------8<----
Jun 5 12:32:30 Deborah sshd[6521]: Invalid user firebird from 69.50.198.12
Jun 5 12:32:32 Deborah sshd[6521]: Failed password for invalid user firebird
from 69.50.198.12 port 33593 ssh2
Jun 5 12:32:37 Deborah sshd[6523]: Failed password for root from 69.50.198.12
port 33824 ssh2
Jun 5 12:32:38 Deborah sshd[6526]: Invalid user user from 69.50.198.12
Jun 5 12:32:40 Deborah sshd[6526]: Failed password for invalid user user from
69.50.198.12 port 34133 ssh2
[...] essai de 'admin', 'guest', 'sales', 'oracle', ftptest' 'mysql',
'usertest', 'administrator'
Jun 5 12:33:17 Deborah sshd[6544]: Failed password for root from 69.50.198.12
port 36554 ssh2
[...] 20 lignes où seul le port change
Jun 5 12:34:39 Deborah sshd[6728]: Failed password for root from 69.50.198.12
port 42052 ssh2
8<-----------8<---------8<----------8<----------8<----------8<----------8<----
Le simple fait que ce log n'ai pas été nettoyé peut-il me laisser penser
que j'ai eu affaire à un inoffensif script-kiddie ?
L'autre problème (sans doute bien plus grave et qui va en faire hurler
certains), c'est que je ne sais pas sécuriser une machine. J'ai quand
même
PermitRootLogin no
PermitEmptyPasswords no
dans /etc/ssh/sshd.config
mais je n'ai jamais rien compris à la syntaxe d'iptables. Et si un
aimable contributeur du ng pouvait me donner une url pour newbie
complet, je lui en serais reconnaissant.
Je ne comprends donc pas ceux qui disent que les sécurités sur la saisie des mdp est dangeureuse à terme.
Parce qu'il suffit d'un truc qui essaye des MdP fantaisistes pour empêcher l'utilisateur légitime de se connecter. Entre une tentative d'infraction et un machin qui peut m'interdire de rentrer chez moi, le choix est vite fait.
Je ne comprends donc pas ceux qui disent que les sécurités sur la
saisie des mdp est dangeureuse à terme.
Parce qu'il suffit d'un truc qui essaye des MdP fantaisistes pour
empêcher l'utilisateur légitime de se connecter. Entre une tentative
d'infraction et un machin qui peut m'interdire de rentrer chez moi, le
choix est vite fait.
Je ne comprends donc pas ceux qui disent que les sécurités sur la saisie des mdp est dangeureuse à terme.
Parce qu'il suffit d'un truc qui essaye des MdP fantaisistes pour empêcher l'utilisateur légitime de se connecter. Entre une tentative d'infraction et un machin qui peut m'interdire de rentrer chez moi, le choix est vite fait.
Stephane Dupille
Tu auras de toute façon une ou des adresses IP à bloquer suite à cette détection.
Si en plus on doit bloquer des IP...
Et le fait de rallonger le temps entre deux tentatives n'empêchera pas l'utilisateur de se connecter (IP attaquante détectée mais l'utilisateur doit patentier un peu).
Ben si : si le temps d'attente devient long, ce n'est pas le robot que ça va gêner, mais l'user. D'autant que le robot est largement plus rapide que l'user pour taper, s'il y a un créneau de libre, c'est le robot qui va avoir beaucoup plus de chance d'en profiter que l'utilisateur légitime.
PS mon AS400 n'acceptait les logins que sur une plage d'adresse IP interne (192.168...)
Est-ce qu'une demande de login venant d'ailleurs entrainait l'augmentation du temps d'attente pour en accepter un autre ? Si la réponse est non, alors dans ce cas, effectivement, ça peut être utile, parce qu'un tentative de login malveillante signifie d'abord et surtout que les machines censées être de confiance ont été compromises.
Le risque de DOS est écarté de facto si les tentatives de login ne peuvent pas aboutir. Dans ce cas, effectivement, il y aurait une utilité, mais de là à le mettre par défaut partout...
était configuré avec un routeur fantaisiste et sa seul connexion avec le monde externe pour la maintenance impliquait qu'il lance lui-même une nouvelle config pour se connecter par SSH sur une machine externe bien précise et la connexion se fermait toute seule si aucune donnée ne passait pendant X minutes.
C'est l'AS400 qui ouvrait la session SSH ? Donc il n'était pas possible de prendre la main en interactif dessus ?
Tu auras de toute façon une ou des adresses IP à bloquer suite à
cette détection.
Si en plus on doit bloquer des IP...
Et le fait de rallonger le temps entre deux tentatives
n'empêchera pas l'utilisateur de se connecter (IP attaquante détectée
mais l'utilisateur doit patentier un peu).
Ben si : si le temps d'attente devient long, ce n'est pas le robot
que ça va gêner, mais l'user. D'autant que le robot est largement plus
rapide que l'user pour taper, s'il y a un créneau de libre, c'est le
robot qui va avoir beaucoup plus de chance d'en profiter que
l'utilisateur légitime.
PS mon AS400 n'acceptait les logins que sur une plage d'adresse IP
interne (192.168...)
Est-ce qu'une demande de login venant d'ailleurs entrainait
l'augmentation du temps d'attente pour en accepter un autre ? Si la
réponse est non, alors dans ce cas, effectivement, ça peut être utile,
parce qu'un tentative de login malveillante signifie d'abord et
surtout que les machines censées être de confiance ont été
compromises.
Le risque de DOS est écarté de facto si les tentatives de login ne
peuvent pas aboutir. Dans ce cas, effectivement, il y aurait une
utilité, mais de là à le mettre par défaut partout...
était configuré avec un routeur fantaisiste et sa
seul connexion avec le monde externe pour la maintenance impliquait
qu'il lance lui-même une nouvelle config pour se connecter par SSH sur
une machine externe bien précise et la connexion se fermait toute seule
si aucune donnée ne passait pendant X minutes.
C'est l'AS400 qui ouvrait la session SSH ? Donc il n'était pas
possible de prendre la main en interactif dessus ?
Tu auras de toute façon une ou des adresses IP à bloquer suite à cette détection.
Si en plus on doit bloquer des IP...
Et le fait de rallonger le temps entre deux tentatives n'empêchera pas l'utilisateur de se connecter (IP attaquante détectée mais l'utilisateur doit patentier un peu).
Ben si : si le temps d'attente devient long, ce n'est pas le robot que ça va gêner, mais l'user. D'autant que le robot est largement plus rapide que l'user pour taper, s'il y a un créneau de libre, c'est le robot qui va avoir beaucoup plus de chance d'en profiter que l'utilisateur légitime.
PS mon AS400 n'acceptait les logins que sur une plage d'adresse IP interne (192.168...)
Est-ce qu'une demande de login venant d'ailleurs entrainait l'augmentation du temps d'attente pour en accepter un autre ? Si la réponse est non, alors dans ce cas, effectivement, ça peut être utile, parce qu'un tentative de login malveillante signifie d'abord et surtout que les machines censées être de confiance ont été compromises.
Le risque de DOS est écarté de facto si les tentatives de login ne peuvent pas aboutir. Dans ce cas, effectivement, il y aurait une utilité, mais de là à le mettre par défaut partout...
était configuré avec un routeur fantaisiste et sa seul connexion avec le monde externe pour la maintenance impliquait qu'il lance lui-même une nouvelle config pour se connecter par SSH sur une machine externe bien précise et la connexion se fermait toute seule si aucune donnée ne passait pendant X minutes.
C'est l'AS400 qui ouvrait la session SSH ? Donc il n'était pas possible de prendre la main en interactif dessus ?
Fabien LE LEZ
On 06 Jun 2007 12:16:45 GMT, Stephane Dupille :
Par contre, bloquer une adresse IP pendant X minutes après N tentatives infructueuses me semble une bonne idée.
C'est la même chose : il suffit de mettre un robot qui va tester le mdp toutes les X minutes pour avoir le même résultat.
Non. L'IP du robot sera bloquée ; l'IP de l'utilisateur légitime continuera à être acceptée.
On 06 Jun 2007 12:16:45 GMT, Stephane Dupille
<sdupille@NOSPAM.fr.eu.org>:
Par contre, bloquer une adresse IP pendant X minutes après N
tentatives infructueuses me semble une bonne idée.
C'est la même chose : il suffit de mettre un robot qui va tester le
mdp toutes les X minutes pour avoir le même résultat.
Non. L'IP du robot sera bloquée ; l'IP de l'utilisateur légitime
continuera à être acceptée.
C'est un principe parfaitement stupide, puisqu'il peut déclencher des DoS très facilement.
On ne met que très rarement un iSeries directement en liaison avec l'extérieur, c'est une machine de backoffice
Ah, OK.
Mais reconnais que pour une machine accessible depuis Internet, c'est une mauvaise méthode.
Fabien LE LEZ
On 06 Jun 2007 12:16:54 GMT, Stephane Dupille :
Parce que le problème n'est pas là. Si le mot de passe est correctement choisi, et si les utilisateurs le gardent secret, il ne sert à rien de mettre un délai pour saisir le mdp : les attaques par dictionnaire ne marcheront pas de toute façon, et l'attaque par force brute metterait trop de temps dans tous les cas, délai ajouté, ou pas.
Faut quand même mettre des limites pour éviter un DoS : si un pirate propose quelques milliers de mots de passe par seconde, la machine ne va pas apprécier.
On 06 Jun 2007 12:16:54 GMT, Stephane Dupille
<sdupille@NOSPAM.fr.eu.org>:
Parce que le problème n'est pas là. Si le mot de passe est
correctement choisi, et si les utilisateurs le gardent secret, il ne
sert à rien de mettre un délai pour saisir le mdp : les attaques par
dictionnaire ne marcheront pas de toute façon, et l'attaque par force
brute metterait trop de temps dans tous les cas, délai ajouté, ou pas.
Faut quand même mettre des limites pour éviter un DoS : si un pirate
propose quelques milliers de mots de passe par seconde, la machine ne
va pas apprécier.
Parce que le problème n'est pas là. Si le mot de passe est correctement choisi, et si les utilisateurs le gardent secret, il ne sert à rien de mettre un délai pour saisir le mdp : les attaques par dictionnaire ne marcheront pas de toute façon, et l'attaque par force brute metterait trop de temps dans tous les cas, délai ajouté, ou pas.
Faut quand même mettre des limites pour éviter un DoS : si un pirate propose quelques milliers de mots de passe par seconde, la machine ne va pas apprécier.
Stephane Dupille
Faut quand même mettre des limites pour éviter un DoS : si un pirate propose quelques milliers de mots de passe par seconde, la machine ne va pas apprécier.
Si le système ne permet de rentrer qu'un MdP par minute, il suffit de faire un robot qui envoit un MdP toutes les secondes pour faire un DoS quasi parfait. Normalement, envoyer une tentative par minute devrait suffir si le robot arrive à se synchroniser.
Faut quand même mettre des limites pour éviter un DoS : si un pirate
propose quelques milliers de mots de passe par seconde, la machine ne
va pas apprécier.
Si le système ne permet de rentrer qu'un MdP par minute, il suffit
de faire un robot qui envoit un MdP toutes les secondes pour faire un
DoS quasi parfait. Normalement, envoyer une tentative par minute
devrait suffir si le robot arrive à se synchroniser.
Faut quand même mettre des limites pour éviter un DoS : si un pirate propose quelques milliers de mots de passe par seconde, la machine ne va pas apprécier.
Si le système ne permet de rentrer qu'un MdP par minute, il suffit de faire un robot qui envoit un MdP toutes les secondes pour faire un DoS quasi parfait. Normalement, envoyer une tentative par minute devrait suffir si le robot arrive à se synchroniser.
Stephane Dupille
C'est la même chose : il suffit de mettre un robot qui va tester le mdp toutes les X minutes pour avoir le même résultat. Non. L'IP du robot sera bloquée ; l'IP de l'utilisateur légitime
continuera à être acceptée.
Je trouve que bloquer les IP est encore plus dangereux que bloquer la tentative de login. Heureusement que le spoof n'est pas une pratique si répandue que cela parce que ça ferait très très mal.
C'est la même chose : il suffit de mettre un robot qui va tester le
mdp toutes les X minutes pour avoir le même résultat.
Non. L'IP du robot sera bloquée ; l'IP de l'utilisateur légitime
continuera à être acceptée.
Je trouve que bloquer les IP est encore plus dangereux que bloquer
la tentative de login. Heureusement que le spoof n'est pas une
pratique si répandue que cela parce que ça ferait très très mal.
C'est la même chose : il suffit de mettre un robot qui va tester le mdp toutes les X minutes pour avoir le même résultat. Non. L'IP du robot sera bloquée ; l'IP de l'utilisateur légitime
continuera à être acceptée.
Je trouve que bloquer les IP est encore plus dangereux que bloquer la tentative de login. Heureusement que le spoof n'est pas une pratique si répandue que cela parce que ça ferait très très mal.
Eric Masson
Fabien LE LEZ writes:
'Lut,
Mais reconnais que pour une machine accessible depuis Internet, c'est une mauvaise méthode.
Bof, cela dépend de ce qui le plus important, la valeur des données sur la machine ou l'accessibilité de celles-ci.
En fonction de la réponse, tu choisis la politique qui convient.
-- MS> A quand une hiérachie alternative en langue française?? SP> Quand vous aurez lancé les messages de contrôle idoines. MS> Je les connais pas ? Peut-tu les publié ici même? -+- MS in GNU : Mon neuneu est un aaaaartiste -+-
Fabien LE LEZ <gramster@gramster.com> writes:
'Lut,
Mais reconnais que pour une machine accessible depuis Internet, c'est
une mauvaise méthode.
Bof, cela dépend de ce qui le plus important, la valeur des données sur
la machine ou l'accessibilité de celles-ci.
En fonction de la réponse, tu choisis la politique qui convient.
--
MS> A quand une hiérachie alternative en langue française??
SP> Quand vous aurez lancé les messages de contrôle idoines.
MS> Je les connais pas ? Peut-tu les publié ici même?
-+- MS in GNU : Mon neuneu est un aaaaartiste -+-
Mais reconnais que pour une machine accessible depuis Internet, c'est une mauvaise méthode.
Bof, cela dépend de ce qui le plus important, la valeur des données sur la machine ou l'accessibilité de celles-ci.
En fonction de la réponse, tu choisis la politique qui convient.
-- MS> A quand une hiérachie alternative en langue française?? SP> Quand vous aurez lancé les messages de contrôle idoines. MS> Je les connais pas ? Peut-tu les publié ici même? -+- MS in GNU : Mon neuneu est un aaaaartiste -+-
Stephane Dupille
C'est l'AS400 qui ouvrait la session SSH ? Donc il n'était pas possible de prendre la main en interactif dessus ? De l'extérieur ?
Non, pas de l'extérieur, mais de la machine à laquelle se connecte l'AS400. En fait, je suis étonné que ce soit la machine elle-même qui ouvre la connexion SSH. Ou alors, par ouvrir la connexion, tu voulais peut-être dire qu'elle ouvrait le port et qu'elle permet ainsi qu'on puisse se connecter en SSH dessus à partir d'une IP connue.
C'est l'AS400 qui ouvrait la session SSH ? Donc il n'était pas
possible de prendre la main en interactif dessus ?
De l'extérieur ?
Non, pas de l'extérieur, mais de la machine à laquelle se connecte
l'AS400. En fait, je suis étonné que ce soit la machine elle-même qui
ouvre la connexion SSH. Ou alors, par ouvrir la connexion, tu voulais
peut-être dire qu'elle ouvrait le port et qu'elle permet ainsi qu'on
puisse se connecter en SSH dessus à partir d'une IP connue.
C'est l'AS400 qui ouvrait la session SSH ? Donc il n'était pas possible de prendre la main en interactif dessus ? De l'extérieur ?
Non, pas de l'extérieur, mais de la machine à laquelle se connecte l'AS400. En fait, je suis étonné que ce soit la machine elle-même qui ouvre la connexion SSH. Ou alors, par ouvrir la connexion, tu voulais peut-être dire qu'elle ouvrait le port et qu'elle permet ainsi qu'on puisse se connecter en SSH dessus à partir d'une IP connue.
Thierry B
On 2007-06-06, Stephane Dupille wrote:
Je trouve que bloquer les IP est encore plus dangereux que bloquer la tentative de login. Heureusement que le spoof n'est pas une pratique si répandue que cela parce que ça ferait très très mal.
Jusqu'à quel point peut-on aller lors d'une ouverture de session ssh avec une ip spoofée ?
-- Si je suis descendu, je ne regretterai absolument rien. La termitière future m'épouvante. Et je hais leurs vertus de robots. Moi, j'étais fait pour être jardinier. -- Antoine de Saint-Exupéry - Ecrits de guerre
On 2007-06-06, Stephane Dupille <sdupille@NOSPAM.fr.eu.org> wrote:
Je trouve que bloquer les IP est encore plus dangereux que bloquer
la tentative de login. Heureusement que le spoof n'est pas une
pratique si répandue que cela parce que ça ferait très très mal.
Jusqu'à quel point peut-on aller lors d'une ouverture de
session ssh avec une ip spoofée ?
--
Si je suis descendu, je ne regretterai absolument rien.
La termitière future m'épouvante. Et je hais leurs vertus de robots.
Moi, j'étais fait pour être jardinier.
-- Antoine de Saint-Exupéry - Ecrits de guerre
Je trouve que bloquer les IP est encore plus dangereux que bloquer la tentative de login. Heureusement que le spoof n'est pas une pratique si répandue que cela parce que ça ferait très très mal.
Jusqu'à quel point peut-on aller lors d'une ouverture de session ssh avec une ip spoofée ?
-- Si je suis descendu, je ne regretterai absolument rien. La termitière future m'épouvante. Et je hais leurs vertus de robots. Moi, j'étais fait pour être jardinier. -- Antoine de Saint-Exupéry - Ecrits de guerre
