Le Mon, 26 Aug 2013 16:40:06 +0200
alain vanranst a écrit:Quels seraient les logiciels à mettre en place pour surveiller tous les
accès à ce serveur?
Est-il indispensable de passer par quelque chose comme backtrack5 ?
Y-a-t-il des mesures de surveillance plus "accessibles".
Tu as des outils permettant de vérifier l'intégrité de ton système.
Tu peux utiliser debsums pour comparer les md5sums de tes fichiers par rapport
à ceux des paquets. J'ai fait un petit logiciel (paquet surveillance sur
deb http://boisson.homeip.net/depot wheezy divers (remplace wheezy par ce que
tu veux)) qui vérifie tts les heures les md5sums des fichiers.
Tu as des
outils de recherche de processus cachés (j'en avais fait un assez basique avec
l'aide de cette liste à l'époque qui s'est révélé efficace, cf paquet
cacheproc).
Le Mon, 26 Aug 2013 16:40:06 +0200
alain vanranst <alainvanranst@gmail.com> a écrit:
Quels seraient les logiciels à mettre en place pour surveiller tous les
accès à ce serveur?
Est-il indispensable de passer par quelque chose comme backtrack5 ?
Y-a-t-il des mesures de surveillance plus "accessibles".
Tu as des outils permettant de vérifier l'intégrité de ton système.
Tu peux utiliser debsums pour comparer les md5sums de tes fichiers par rapport
à ceux des paquets. J'ai fait un petit logiciel (paquet surveillance sur
deb http://boisson.homeip.net/depot wheezy divers (remplace wheezy par ce que
tu veux)) qui vérifie tts les heures les md5sums des fichiers.
Tu as des
outils de recherche de processus cachés (j'en avais fait un assez basique avec
l'aide de cette liste à l'époque qui s'est révélé efficace, cf paquet
cacheproc).
Le Mon, 26 Aug 2013 16:40:06 +0200
alain vanranst a écrit:Quels seraient les logiciels à mettre en place pour surveiller tous les
accès à ce serveur?
Est-il indispensable de passer par quelque chose comme backtrack5 ?
Y-a-t-il des mesures de surveillance plus "accessibles".
Tu as des outils permettant de vérifier l'intégrité de ton système.
Tu peux utiliser debsums pour comparer les md5sums de tes fichiers par rapport
à ceux des paquets. J'ai fait un petit logiciel (paquet surveillance sur
deb http://boisson.homeip.net/depot wheezy divers (remplace wheezy par ce que
tu veux)) qui vérifie tts les heures les md5sums des fichiers.
Tu as des
outils de recherche de processus cachés (j'en avais fait un assez basique avec
l'aide de cette liste à l'époque qui s'est révélé efficace, cf paquet
cacheproc).
heu ce n'est pas ce que fait tripwire ? je vais tester, j'apprécie le
principe. Merci
> Tu as des
> outils de recherche de processus cachés (j'en avais fait un assez basique
> avec l'aide de cette liste à l'époque qui s'est révélé efficace, cf paquet
> cacheproc).
intéressant merci aussi !
heu ce n'est pas ce que fait tripwire ? je vais tester, j'apprécie le
principe. Merci
> Tu as des
> outils de recherche de processus cachés (j'en avais fait un assez basique
> avec l'aide de cette liste à l'époque qui s'est révélé efficace, cf paquet
> cacheproc).
intéressant merci aussi !
heu ce n'est pas ce que fait tripwire ? je vais tester, j'apprécie le
principe. Merci
> Tu as des
> outils de recherche de processus cachés (j'en avais fait un assez basique
> avec l'aide de cette liste à l'époque qui s'est révélé efficace, cf paquet
> cacheproc).
intéressant merci aussi !
Le 08/26/2013 05:42 PM, Bzzz a écrit :On Mon, 26 Aug 2013 17:12:47 +0200
Harang Jean-Marc wrote:Et la détection de rootkit (Tripwire, ossec, rkhunter et autres ?)
à mettre en place avant une éventuelle intrusion, bien évidemment,
est-ce que ça reste intéressant ou pas ?
Les détecteurs de rootkit génèrent trop de faux positifs;
à la rigueur tripwire permettra de savoir exactement ce
qui a été touché; si tant est qu'il soit systématiquement
MàJ lors de chaque intervention et d'une façon sécurisée,
ET que ses binaires ne résident PAS sur les HDz du svr.
Je suis ok avec Tripwire en revanche on part du principe qu'une
detection maligne de Tripwire implique une intrusion à un plus haut
niveau... dans notre cas la première barrière à mettre en place est un
couple firewall/ids/ips
Le 08/26/2013 05:42 PM, Bzzz a écrit :
On Mon, 26 Aug 2013 17:12:47 +0200
Harang Jean-Marc <jean-marc.harang@c-s.fr> wrote:
Et la détection de rootkit (Tripwire, ossec, rkhunter et autres ?)
à mettre en place avant une éventuelle intrusion, bien évidemment,
est-ce que ça reste intéressant ou pas ?
Les détecteurs de rootkit génèrent trop de faux positifs;
à la rigueur tripwire permettra de savoir exactement ce
qui a été touché; si tant est qu'il soit systématiquement
MàJ lors de chaque intervention et d'une façon sécurisée,
ET que ses binaires ne résident PAS sur les HDz du svr.
Je suis ok avec Tripwire en revanche on part du principe qu'une
detection maligne de Tripwire implique une intrusion à un plus haut
niveau... dans notre cas la première barrière à mettre en place est un
couple firewall/ids/ips
Le 08/26/2013 05:42 PM, Bzzz a écrit :On Mon, 26 Aug 2013 17:12:47 +0200
Harang Jean-Marc wrote:Et la détection de rootkit (Tripwire, ossec, rkhunter et autres ?)
à mettre en place avant une éventuelle intrusion, bien évidemment,
est-ce que ça reste intéressant ou pas ?
Les détecteurs de rootkit génèrent trop de faux positifs;
à la rigueur tripwire permettra de savoir exactement ce
qui a été touché; si tant est qu'il soit systématiquement
MàJ lors de chaque intervention et d'une façon sécurisée,
ET que ses binaires ne résident PAS sur les HDz du svr.
Je suis ok avec Tripwire en revanche on part du principe qu'une
detection maligne de Tripwire implique une intrusion à un plus haut
niveau... dans notre cas la première barrière à mettre en place est un
couple firewall/ids/ips
Bonjour la liste,
Sinon, est-ce que quelqu'un dans la liste à un bon lien, type
tutoriel, pour sécuriser son auto-hébergement (servcices utilisés :
ssh, apache2, wordpress, owncloud, dokuwiki). Car mon tuto est
"basique".
Bonjour la liste,
Sinon, est-ce que quelqu'un dans la liste à un bon lien, type
tutoriel, pour sécuriser son auto-hébergement (servcices utilisés :
ssh, apache2, wordpress, owncloud, dokuwiki). Car mon tuto est
"basique".
Bonjour la liste,
Sinon, est-ce que quelqu'un dans la liste à un bon lien, type
tutoriel, pour sécuriser son auto-hébergement (servcices utilisés :
ssh, apache2, wordpress, owncloud, dokuwiki). Car mon tuto est
"basique".
Bonjour la liste,
DC > Pas besoin de se poser de question sur la solidité du pass
(sinon celui de la clé) ni de savoir
DC > si fail2ban ou le portknocking est efficace (ils me paraissent
sans aucun intérêt avec
DC > "PasswordAuthentication no") .
Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
a matraquage sur le port ssh, le fait de mettre l'ip dans la jail
permet de moins solliciter ton service ssh. C'est déjà un plus.
DC > Et pas besoin non plus de changer le port ssh (cacher la porte
ne la rend pas mieux blindée,
DC > c'est de l'illusion de sécurité).
Le fait de le mettre sur un port supérieur à 10 000, permet déjà
d'éviter les "boots" basiques qui traînent sur la toile. Après "oui"
si quelqu'un s'intéresse à ton serveur, il trouvera la faille.
Sinon, est-ce que quelqu'un dans la liste à un bon lien, type
tutoriel, pour sécuriser son auto-hébergement (servcices utilisés :
ssh, apache2, wordpress, owncloud, dokuwiki). Car mon tuto est
"basique".
Bonjour la liste,
DC > Pas besoin de se poser de question sur la solidité du pass
(sinon celui de la clé) ni de savoir
DC > si fail2ban ou le portknocking est efficace (ils me paraissent
sans aucun intérêt avec
DC > "PasswordAuthentication no") .
Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
a matraquage sur le port ssh, le fait de mettre l'ip dans la jail
permet de moins solliciter ton service ssh. C'est déjà un plus.
DC > Et pas besoin non plus de changer le port ssh (cacher la porte
ne la rend pas mieux blindée,
DC > c'est de l'illusion de sécurité).
Le fait de le mettre sur un port supérieur à 10 000, permet déjà
d'éviter les "boots" basiques qui traînent sur la toile. Après "oui"
si quelqu'un s'intéresse à ton serveur, il trouvera la faille.
Sinon, est-ce que quelqu'un dans la liste à un bon lien, type
tutoriel, pour sécuriser son auto-hébergement (servcices utilisés :
ssh, apache2, wordpress, owncloud, dokuwiki). Car mon tuto est
"basique".
Bonjour la liste,
DC > Pas besoin de se poser de question sur la solidité du pass
(sinon celui de la clé) ni de savoir
DC > si fail2ban ou le portknocking est efficace (ils me paraissent
sans aucun intérêt avec
DC > "PasswordAuthentication no") .
Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
a matraquage sur le port ssh, le fait de mettre l'ip dans la jail
permet de moins solliciter ton service ssh. C'est déjà un plus.
DC > Et pas besoin non plus de changer le port ssh (cacher la porte
ne la rend pas mieux blindée,
DC > c'est de l'illusion de sécurité).
Le fait de le mettre sur un port supérieur à 10 000, permet déjà
d'éviter les "boots" basiques qui traînent sur la toile. Après "oui"
si quelqu'un s'intéresse à ton serveur, il trouvera la faille.
Sinon, est-ce que quelqu'un dans la liste à un bon lien, type
tutoriel, pour sécuriser son auto-hébergement (servcices utilisés :
ssh, apache2, wordpress, owncloud, dokuwiki). Car mon tuto est
"basique".
Le 27/08/13 à 12:32, julien a écrit :
J> > Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
J> > a matraquage sur le port ssh, le fait de mettre l'ip dans la jail
J> > permet de moins solliciter ton service ssh. C'est déjà un plus.
J>
J> Oui et ça permet surtout d'économiser la bande passante
C'est pas négligeable devant les ressources consommées par fail2ban ?
Le 27/08/13 à 12:32, julien <julien@nura.eu> a écrit :
J> > Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
J> > a matraquage sur le port ssh, le fait de mettre l'ip dans la jail
J> > permet de moins solliciter ton service ssh. C'est déjà un plus.
J>
J> Oui et ça permet surtout d'économiser la bande passante
C'est pas négligeable devant les ressources consommées par fail2ban ?
Le 27/08/13 à 12:32, julien a écrit :
J> > Je ne suis pas expert sur Fail2ban, mais je suppose que si il y
J> > a matraquage sur le port ssh, le fait de mettre l'ip dans la jail
J> > permet de moins solliciter ton service ssh. C'est déjà un plus.
J>
J> Oui et ça permet surtout d'économiser la bande passante
C'est pas négligeable devant les ressources consommées par fail2ban ?