Foxy a écrit 669 commentaires

Cool mon nmap 3.45 (auquel tu as contribué si j'en crois la doc de Fyodor) me donne :

# /usr/local/bin/nmap -P0 -sV -vv -p21 oss.sgi.com
Initiating SYN Stealth Scan against oss.SGI.COM (192.48.159.27) at 00:28
Adding open port 21/tcp
The SYN Stealth Scan took 1 second to scan 1 ports.
Initiating service scan against 1 service on 1 host at 00:28
The service scan took 0 seconds to scan 1 service on 1 host.
Interesting ports on oss.SGI.COM (192.48.159.27):
PORT STATE SERVICE VERSION
21/tcp open ftp Pure-FTPd

Nmap run completed -- 1 IP address (1 host up) scanned in 0.713 seconds

Effectivement, c'est du bon serveur FTP ça ;-)

C'est clair, dans le code C que j'écris pour un projet Gnome, l'utilisation de "g_strdup_printf" simplifie grandement la manipulation des strings et évite de se prendre la tête à tout bout de champ.

Pour des explications techniques sur les buffer overflow et les manières des les éviter avec une bonne pratique du codage en C, voir ces 2 documents PDF en français :

- http://www.k-otik.com/papers/Exploitation_Avancee_BOF.pdf(...)
- http://www.k-otik.com/papers/Bugtraq_Fr_Buffers.pdf(...)

Désolé mais les archives WWW de Bugtraq fonctionnent très bien : http://www.securityfocus.com/archive/1(...)

A l'heure actuelle le dernier message s'intitule "GLSA: openssl (200309-19)" et date du 01/10/2003.

Même problème avec ma carte Banshee.

Vu les autres commentaires, sûrement un problème lié aux cartes 3DFx :-(

Putain, j'avais jamais vu qu'IDefense avait une politique affichée de rémunérations des contributeurs pour les failles et les exploits.

Super dérive : je trouve une faille sur un produit, eh bien je ne préviens pas le développeur du soft mais je vends mon info à IDefense qui préviendra le développeur :-(

Quand je vois des annonces de failles de sécurité venant d'ISS avec un exploit utilisable, je me demande toujours s'ils ne l'ont pas achété à quelque vil black hat ?

Le patch ACPI spécifique pour les portables Toshiba est dispo ici : http://memebeam.org/toys/ToshibaAcpiDriver(...)

Il est maintenant intégré au kernel 2.4 depuis le 2.4.22 (dans le 2.4.22-pre1 pour être exact) : voir le Changelog http://kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.22(...)

Ensuite, il ya une application en cours de développement http://fnfx.sourceforge.net(...) qui permet d'associer les touches spéciales Toshiba à ce driver APCI via /proc

Lorsque tu reprends une session "suspendue", quel est le temps pour retrouver l'état de sa session comme on l'avait laissé (un ordre de grandeur suffira) ?

Est-ce que tu as essayé le patch "laptop_mode" http://lwn.net/Articles/32037/(...) ?

Visiblement, il permet de diminuer l'utilisation d'un disque sur un laptop en temporisant l'écriture. Cela permet d'augmenter la durée de la batterie.

Faut vraiment que je me recompile un kernel "aux petits oignons" pour mon portable :
- kernel 2.4.22 avec ACPI
- patch ACPI pour laptop Toshiba (gestion des touches spéciales via /proc)
- swsusp pour gérer la "suspension"...

L'auteur de la news confond les termes : ce n'est pas du cynisme mais tout simplement du pragmatisme.

Evidemment qu'un patron ou un DSI choisit les LL pour leur coût,leur qualité er leurs performances comparativement à des logiciels propriétaires.

C'est de la naïveté primaire que de croire que le monde l'entreprise se base sur une "philosophie" pour faire ses choix (bien qu'avec des trucs type "fonds éthiques", une "pseudo philospohie" peut entrer dans le monde de l'entreprise, mais surtout initiée par le cynisme du marketing).

Je ne voudrais pas être médisant mais Authpf permet ce genre de chose (filtrage de paquets après authentification utilisateur) depuis longtemps sur OpenBSD.

Pour l'authentification de l'utilisateur, il suffit qu'il se loggue via SSH et que son shell soit /usr/sbin/authpf. Le système de fitrage PF d'OpenBSD adapte alors les règles de filtrage dynamiquement.

Voir la FAQ dédiée à authpf pour plus de détails : http://openbsd.org/faq/pf/authpf.html(...)

Tout à fait, Alain LEFEBVRE est un des dirigeants de la SSII SQLI et cela fait longtemps qu'il milite pour Linux.

Lorsque j'ai passé des entretiens de recrutement chez eux fin 1998, ils faisaient déjà des prestations et de la formation sur Linux. Cela fait donc longtemps qu'Alain Lefebvre a compris l'intêret de Linux au niveau professionnel.

Dernier point, 500k connexions simultanées c'est pas si inhabituel que cela sur de très gros réseaux. Et dire que ça devrait être géré par du hardware ça n'a aucun sens, y'a tjrs un peu de software derrière, pour du routage, du filtrage ou du service.

Oui tout à fait, ce genre de conf se trouve dans certains gros réseaux : c'est pour cela que je teste les produits de ma boite dans ces conditions --> vendre notre produit pour des "grosses" installations.

Evidemment qu'il y a du software pour générer ces connexions sur mon outil de benchs. Ce que je veux dire par génération hardware, c'est que sur mon outil il y a des puces spécialisés chargés de générer le traffic TCP/IP : cela permet d'être sûr des capacités de génération (nb nouvelles cnx/s, throughput...). Pour ceux que ça intéresse, voir l'outil Smartbits de Spirent Telecom.

De toute façon, ça n'arrive pas à la cheville du dernier commit CVS dans le code de PF (Packet Filter, équivalent de Netfilter) sur OpenBSD.

Maintenant on peut écrire des règles de firewalling avec comme cible l'OS client reconnu par passive fingerprinting du paquet SYN.

Ca permet d'ecrire des règles du genre :

block proto tcp from any os SCO
block proto tcp from any os Windows to any port smtp

Voir pour plus de détails :
- http://deadly.org/article.php3?sid=20030821153534(...)
- http://www.w4g.org/fingerprinting.html(...)

Mais faut savoir ce que tu veux : si tu droppes les SYN, effectivement tu bouffes pas de resource sur ton FW.

Si tu utilises TARPIT, tu emmerdes les vers mais tu bouffes aussi des ressources sur ton FW. Je suis bien d'accord avec ça...

Ouais je sais bien qu'on peut faire mieux (ça dépend surtout de la RAM pour gérer une table de connexions actives TCP/IP).

Dans mon cas, c'est mon outil hardware qui me limite à 500000 connexions simultanées : faut qu'on achète une carte génératrice de connexions TCP/IP supplémentaires.

J'ai pas dit que je faisait 500000 à destination du Linux, je fais 500000 connexions "à travers" le Linux donc je peux jouer avec mon outils sur les IP source, destination et les ports comme je veux (l'outil est fait pour ça)

Non c'est pas la même chose, avec ta technique, la connexion TCP du vers attends juste le time-out dû au DROP.

Avec TARPIT, la connexion TCP reste établie et bouffe plus de resources au vers.

* La pile réseau risque d'être stressée par de nombreuses connections (y a-t-il un pb sous linux ?)

Par sur mes machines de tests en tout cas, j'ai déjà fait prendre 500000 connexions TCP simultanées à un noyau Linux et ils les tenaient bien (avec 512 Mo de RAM) et un outil de tests hardware spécifique.

Si c'est tout à fait ça :
- Un-Thesis : développeur originel de xMule veut développer un clone propriétaire , payant (il doit rêver la nuit, lui....)
- les autres développeurs se sont engueulés avec lui et développe de leur côté un xMule 2 : code propre et maintenable

C'est explique sur la page "History of XMule" : http://www.xmule.org/geeklog/staticpages/index.php?page=20030708010(...)

Si mais il y a bien longtemps que plus personne (ou quasiment) n'utilise le client officiel :

- emule sur Win
- xmule/mlDonkey sur Linux

Remplacer toutes les options "M" (compil en module) par "Y" et mettre "Enable loadable module support (CONFIG_MODULES) " à "N" -> ce sera parfait et plus secure.

Perso, j'ai fait pas mal de tests d'outils anti-spam au niveau client (avec filtres procmail) :

- SpamAssassin est "gourmand" en ressource avec toutes ses recherches à base de regexp
- les outils Bayesiens type Bogofilter sont très efficaces avec un bon apprentissage, peu gourmand en ressource mais laissent encore trop de faux négatifs
- le filtrage Bayesien de SpamAssassin est moins performant et consommateur de ressources système

=> ma solution : utiliser les 2
- tous mes mails passent par Bogofilter qui fait un premier tri à base filtre bayesien => élimine la majorité des spams
- les mails qui échappent à bogofilter passent par SpamAssassin

Cela permet de limiter les ressources "consommées" par SpamAssassin puisqu'il n'est pas exécuté pour chacun des messages entrants.

Si ça intéresse quelqu'un, j'ai la conf promail qui va bien.

Non, le troll ultime c'est Linux vs *BSD (Open, Free et Net) : allez faire un tour sur le NG fr.comp.os.bsd, vous m'en direz des nouvelles.

Mais préparer bien vos armes et vos arguments car les trolleurs BSD qui sévissent sur ce NG, sont des experts et vous risquez de repartir la queue basse.

Pas de runlevel sur les systèmes BSD...