"xinetd - extented Internet services daemon - fournit une excellente
sécurité contre les intrusions, et limite certains risques d'attaques
par Deny of Services (DoS)."
Apparement, c'est pas gagné. Si l'outil censé protéger agrave
l'attaque...
En 90 minutes, chaque adresse a été en moyenne scannée sur 2 à 3 ports.
"xinetd - extented Internet services daemon - fournit une excellente
sécurité contre les intrusions, et limite certains risques d'attaques
par Deny of Services (DoS)."
Apparement, c'est pas gagné. Si l'outil censé protéger agrave
l'attaque...
En 90 minutes, chaque adresse a été en moyenne scannée sur 2 à 3 ports.
"xinetd - extented Internet services daemon - fournit une excellente
sécurité contre les intrusions, et limite certains risques d'attaques
par Deny of Services (DoS)."
Apparement, c'est pas gagné. Si l'outil censé protéger agrave
l'attaque...
En 90 minutes, chaque adresse a été en moyenne scannée sur 2 à 3 ports.
xinetd permet effectivement de controler de maniere centralisée les
connexions (autoriser ou interdir l'acces en fonction de l'adresse, de
l'utilisateur, de la plage horaire, ... man xinetd.conf pour les
détails). Mais pour le cas que je mentionnais (sshd lancé par xinetd) ce
n'est pas xinetd lui meme qui est en cause, c'est le fait de gérer sshd
via xinetd. Cette gestion implique que le serveur sshd n'est pas lancé
en permanence, il est lancé à la demande. Au lancement d'sshd ce dernier
génère une clé qui sert à chiffrer les transactions. Ce processus est
assez lourd, et sa répétition rapide peut poser des problèmes de charge.
Compte tenu de ce que tu dis ensuite, ton problème ne vient pas de là,
puisque sshd utilise le port 22, et que ton "attaque" s'est située entre
les ports 1000 et 1999.
De plus, tous les Xserves ne se comportent pas aussi mal. J'en ai vu un
planter systématiquement avec une requete sshd par minute venant d'un
nagios. J'en supervise une 10n actuellement, dont un qui a un load de 20
en permanance, aucun ne plante.
Merci pour le temps de la rédaction de cette réponse très claire.
Il faudrait laisser le pc sur le réseau, et faire un tcpdump de ce qui
en sort, en meme temps il faudrait controler ce qui se passe sur les
XServe (laisser le FW ouvert mais loguer tous les paquets qui rentrent
par exemple)
Certe, mais mon stagiaire part demain et l'idée de rebrancher cette
En 90 minutes, chaque adresse a été en moyenne scannée sur 2 à 3 ports.
ca veut dire que tes Xserves n'ont recu que 2 ou 3 tentatives de
connexion en 90 minutes ??
oui,
xinetd permet effectivement de controler de maniere centralisée les
connexions (autoriser ou interdir l'acces en fonction de l'adresse, de
l'utilisateur, de la plage horaire, ... man xinetd.conf pour les
détails). Mais pour le cas que je mentionnais (sshd lancé par xinetd) ce
n'est pas xinetd lui meme qui est en cause, c'est le fait de gérer sshd
via xinetd. Cette gestion implique que le serveur sshd n'est pas lancé
en permanence, il est lancé à la demande. Au lancement d'sshd ce dernier
génère une clé qui sert à chiffrer les transactions. Ce processus est
assez lourd, et sa répétition rapide peut poser des problèmes de charge.
Compte tenu de ce que tu dis ensuite, ton problème ne vient pas de là,
puisque sshd utilise le port 22, et que ton "attaque" s'est située entre
les ports 1000 et 1999.
De plus, tous les Xserves ne se comportent pas aussi mal. J'en ai vu un
planter systématiquement avec une requete sshd par minute venant d'un
nagios. J'en supervise une 10n actuellement, dont un qui a un load de 20
en permanance, aucun ne plante.
Merci pour le temps de la rédaction de cette réponse très claire.
Il faudrait laisser le pc sur le réseau, et faire un tcpdump de ce qui
en sort, en meme temps il faudrait controler ce qui se passe sur les
XServe (laisser le FW ouvert mais loguer tous les paquets qui rentrent
par exemple)
Certe, mais mon stagiaire part demain et l'idée de rebrancher cette
En 90 minutes, chaque adresse a été en moyenne scannée sur 2 à 3 ports.
ca veut dire que tes Xserves n'ont recu que 2 ou 3 tentatives de
connexion en 90 minutes ??
oui,
xinetd permet effectivement de controler de maniere centralisée les
connexions (autoriser ou interdir l'acces en fonction de l'adresse, de
l'utilisateur, de la plage horaire, ... man xinetd.conf pour les
détails). Mais pour le cas que je mentionnais (sshd lancé par xinetd) ce
n'est pas xinetd lui meme qui est en cause, c'est le fait de gérer sshd
via xinetd. Cette gestion implique que le serveur sshd n'est pas lancé
en permanence, il est lancé à la demande. Au lancement d'sshd ce dernier
génère une clé qui sert à chiffrer les transactions. Ce processus est
assez lourd, et sa répétition rapide peut poser des problèmes de charge.
Compte tenu de ce que tu dis ensuite, ton problème ne vient pas de là,
puisque sshd utilise le port 22, et que ton "attaque" s'est située entre
les ports 1000 et 1999.
De plus, tous les Xserves ne se comportent pas aussi mal. J'en ai vu un
planter systématiquement avec une requete sshd par minute venant d'un
nagios. J'en supervise une 10n actuellement, dont un qui a un load de 20
en permanance, aucun ne plante.
Merci pour le temps de la rédaction de cette réponse très claire.
Il faudrait laisser le pc sur le réseau, et faire un tcpdump de ce qui
en sort, en meme temps il faudrait controler ce qui se passe sur les
XServe (laisser le FW ouvert mais loguer tous les paquets qui rentrent
par exemple)
Certe, mais mon stagiaire part demain et l'idée de rebrancher cette
En 90 minutes, chaque adresse a été en moyenne scannée sur 2 à 3 ports.
ca veut dire que tes Xserves n'ont recu que 2 ou 3 tentatives de
connexion en 90 minutes ??
oui,
Les VLANS (802.11.q ne sont pas faits pour faire joli :-)
C'est simple à mettre en oeuvre, et à firewaller.
XAv
Effectivement, je viens de lire une doc ou deux (dont celle de mon FW),
Les VLANS (802.11.q ne sont pas faits pour faire joli :-)
C'est simple à mettre en oeuvre, et à firewaller.
XAv
Effectivement, je viens de lire une doc ou deux (dont celle de mon FW),
Les VLANS (802.11.q ne sont pas faits pour faire joli :-)
C'est simple à mettre en oeuvre, et à firewaller.
XAv
Effectivement, je viens de lire une doc ou deux (dont celle de mon FW),
In article <1gnth3f.9a4zqh1takc0qN%,
(Nicolas.Michel) wrote:Note bien que c'est pas la mienne, mais celle du spécialiste sécurité de
notre reseau
il veut déléguer son taff aux admin ? ;)))
j'imagine que ça dépend de l'architecture du réseau, mais comme je
disais, le réseau c'est pas mon métier...
Lourd. Et ça protège pas les portables les uns des autres.
ça peut, si tout le trafic est bien fliqué par le firewall
en environnement hétérogène tu fais comment ?
et quand les utilisateurs en changent les réglages ou les coupent
carrément pour essayer de faire du p2p ou du chat personne ne s'en
apperçoit jusqu'a la prochaine attaque virale
et quand il y'a un réglage particulier a faire il faut changer le(s)
fichier(s) de conf, les réinjecter sur les machines ad-hoc, ..., galère.
Note qu'on a déjà activé un fw soft sur les serveurs, avec relativement
peu d'ennuis derrières (quelques réglages parcequ'on avait oublié
certains utilisateurs avec des ip spéciales)
vala, sur les serveurs ca suffit, sur tout le parc c'est la porte
ouverte aux emmerdements.
In article <1gnth3f.9a4zqh1takc0qN%Nicolas.Michel@bonbon.net>,
Nicolas.Michel@bonbon.net (Nicolas.Michel) wrote:
Note bien que c'est pas la mienne, mais celle du spécialiste sécurité de
notre reseau
il veut déléguer son taff aux admin ? ;)))
j'imagine que ça dépend de l'architecture du réseau, mais comme je
disais, le réseau c'est pas mon métier...
Lourd. Et ça protège pas les portables les uns des autres.
ça peut, si tout le trafic est bien fliqué par le firewall
en environnement hétérogène tu fais comment ?
et quand les utilisateurs en changent les réglages ou les coupent
carrément pour essayer de faire du p2p ou du chat personne ne s'en
apperçoit jusqu'a la prochaine attaque virale
et quand il y'a un réglage particulier a faire il faut changer le(s)
fichier(s) de conf, les réinjecter sur les machines ad-hoc, ..., galère.
Note qu'on a déjà activé un fw soft sur les serveurs, avec relativement
peu d'ennuis derrières (quelques réglages parcequ'on avait oublié
certains utilisateurs avec des ip spéciales)
vala, sur les serveurs ca suffit, sur tout le parc c'est la porte
ouverte aux emmerdements.
In article <1gnth3f.9a4zqh1takc0qN%,
(Nicolas.Michel) wrote:Note bien que c'est pas la mienne, mais celle du spécialiste sécurité de
notre reseau
il veut déléguer son taff aux admin ? ;)))
j'imagine que ça dépend de l'architecture du réseau, mais comme je
disais, le réseau c'est pas mon métier...
Lourd. Et ça protège pas les portables les uns des autres.
ça peut, si tout le trafic est bien fliqué par le firewall
en environnement hétérogène tu fais comment ?
et quand les utilisateurs en changent les réglages ou les coupent
carrément pour essayer de faire du p2p ou du chat personne ne s'en
apperçoit jusqu'a la prochaine attaque virale
et quand il y'a un réglage particulier a faire il faut changer le(s)
fichier(s) de conf, les réinjecter sur les machines ad-hoc, ..., galère.
Note qu'on a déjà activé un fw soft sur les serveurs, avec relativement
peu d'ennuis derrières (quelques réglages parcequ'on avait oublié
certains utilisateurs avec des ip spéciales)
vala, sur les serveurs ca suffit, sur tout le parc c'est la porte
ouverte aux emmerdements.
Si j'ai le nom du virus, je
le poste.
Si j'ai le nom du virus, je
le poste.
Si j'ai le nom du virus, je
le poste.
