Heu attention quand même. Outre le chiffrage (chiffrement?), SSL/TLS (et donc HTTPS) permet l'autentification. Si tu ne vérifie pas le certificat, il est possible de spoofer les réponses DNS pour se faire passer pour le site a atteindre et après suffit que le "méchant" ait installé un serveur web qui gère HTTPS avec une page qui ressemble à la page original sur le serveur pour que tu n'y vois que du feu. Bon si le certificat est auto signé et que tu l'as déjà eu avant je pense que tu peux remarquer le problème mais si tu clic "oui" sans regarder c'est mal barré.
Et spoofer une réponse DNS est bien moins difficile que de prendre le contrôle d'un routeur internet sans se faire repérer (bon c'est pas forcément facile non plus). Sinon j'ai lu un article [0] comme quoi avec certaines connexions câble, il est possible de sniffer le traffic internet de ses voisins mais ça date un peu donc ça a peut-être changé depuis.
Sinon pour détecter les sniffers sur son réseau local j'ai écrit un petit script [1] qui utilise arping(8) et qui marche bien. Et pour ceux qui veulent comprendre comment spoofer/sniffer (et donc comment se protéger de ce genre d'attaque) sur un réseau local, il y a cet excellent article [2] qui est passé dans MISC.
Pour une connexion de "mauvaise qualité" ça change probablement rien mais il y existe un patch SSH pour le rendre plus rapide pour les gros transferts.
Ben c'est le lien qui a été donné plus haut. Suffit de faire un "Arrays.sort(foobar)" et ton tableau est trié. Apparement l'implémentation c'est du quicksort "tuné". L'avantage c'est que c'est déjà écrit, donc ça fait du travail en moins, et on peut être raisonnablement assuré que c'est rapide et sans bug. Si le langage propose déjà des solutions toutes faites, autant les utiliser.
D'un autre côté si le but est de comprendre et implémenter des algorithmes de tri, ça n'a bien sûr aucun intérêt.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pour trouver des algorithmes généraux sur le web, deux ressources intéressantes sont Wikipédia et le Dictionary of Algorithms and Data Structures. Evidemment en Java, le mieux c'est probablement d'utiliser Arrays.sort().
Je pense plutôt que c'est les messages du noyau qui sont affichés sur la console courante. Il doit y avoir moyen de régler ça en bidouillant les options du noyau (quelque part dans /proc mais je sais plus exactement où).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si on attend assez longtemps, la terre aura ralenti au point de faire des journées de 28h. Evidemment faut un peu de patience (genre qq centaines de milliers?millions? d'années).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Une explication de comment rendre les ACK prioritaires pour accélerer le download sur une ligne assymétrique. C'est pour PF (*BSD) mais ça m'étonnerait qu'il n'y ait pas moyen de faire la même chose "simplement" (pas port par port) sous Linux.
Ca serait quand même une bonne idée de réinstaller tout parce que rien ne garanti qu'une faille locale n'a pas été utilisée pour rootkiter la machine avec un truc qui n'est pas détecté par chkrootkit et compagnie.
Un moyen relativement sûr de faire la réinstallation à distance serait de commencer par compiler CryptCat ainsi que les binaires de base (BusyBox est ton ami) statiquement sur une machine sûre et les uploader sur la machine compromise. S'arranger pour ne plus utiliser que ces programmes. Notamment ne plus utiliser le sshd original qui peut avoir été compromis aussi. Tu devrais pouvoir obtenir un shell par cryptcat avec un truc genre "# cryptcat -e /safe/bin/sh -l -p 1234 -k mekmitasdigoat" et "$ cryptcat -k mekmitasdigoat example.org 1234". De la tu peux faire un chroot qui te forcerait à utiliser, les nouveaux binaires, dans ce cas, ne pas oublier de faire les mknod qui vont bien avant de passer à la suite.
Debootstraper un système Debian de base sur une machine sûre, le mettre sur un système de fichiers qui va bien, uploader la "partition" sur la machine compromise à traver CryptCat, genre "# cryptcat -k mekmitasdigoat -l -p 4321 -q0 > /safe/dev/hda2" et "$ cryptcat -k mekmitasdigoat example.org 4321 < debian-base.ext3" avec hda2 une partition "libre" que tu as démontée préalablement (genre n'importe quoi sauf /, éventuellement la partition de swap si elle est assez grosse, pas oublier de faire un swapoff avant). Maintenant tu peux monter la partition, chrooter vers le nouveau système et installer le bootloader. Ensuite yapluka rebooter et prier.
Si tu réussis, tu peux être raisonnablement sûr que tu as un système de bases propre. Si tu es paranoïaque, tu peux imaginer que le rootkit est au niveau du noyau et qu'il sait réinfecter un nouveau système que tu installes à partir de programmes non compromis ou que le sshd sait infecter les programmes qu'il voir passer de manière à ce qu'ils infectent à leur tour les fichiers qu'ils manipulent ou qu'il y a un daemon caché qui injecte du code malsain dans tous les nouveaux processes qu'il voit apparaitre ou qu'il y a quelqu'un connecté par une backdoor qui surveille ou bien... mais alors ya plus grand chose à faire à part réinstaller vraiment "from scratch".
A l'avenir pour diminuer les risques de compromission complète du système quand un daemon se fait exploiter tu peux mettre un maximum de truc dans des "jails chroot" ou mieux: des machines virtuelles en utilisant User-Mode-Linux par exemple. Par ailleurs le manuel de sécurisation Debian contient plein de trucs intéressants et faire tourner Sarge sur un serveur disponible depuis internet n'est peut-être pas une très bonne idée (oui je sais Woody est pas à jour mais au moins il y a des màj de sécurité et apt-get peut être mis dans un cron sans risque).
Bon amusement :/
Bien entendu je ne saurais être tenu pour résponsable des dégats éventuels causés par l'applications de ce que j'ai décrit plus haut.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
pourquoi n'y a t-il pas OBLIGATOIREMENT une trace indélébile de ce qui s'est passé. Si le logiciel était un logiciel open source, on pourrait vérifier que tout est normal
Si le logiciel était Open Source ça ne changerait rien: tu peux toujours modifier le logiciel pour pouvoir effacer sans trace (devrait même y avoir moyen d'effacer les traces sans modifier le logiciel) et dire que tu utilises bien la version publiée qui n'a pas cette fonctionnalité. La seule solution que je vois à ce problème ça serait que la base de données des enchères soit publique mais ça pose des problèmes évidents.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Heu je sais pas trop d'où tu sors ton pkg-config mais à mon avis ya des chances que c'est plutôt un truc genre "./configure --with-libmachin=/usr/local/libmachin/" qu'il te faut (suivi du make && make install).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Encore un détail: si tu mets les permissions qui vont bien à /usr/local, ya moyen de pas passer root du tout pour installer. Evidemment le faire avec ton compte d'utilisateur normal n'est peut être pas une bonne idée non plus mais tu peux créer un compte spécial rien que pour /usr/local et tu fais tes installations à coups de "./configure --prefix=/usr/local/ && make && sudo -u installeur make install".
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Le "./configure --prefix=/usr" pour écraser l'installation existante c'est fort bourrin et potentiellement dangereux. Mieux vaut installer dans /usr/local et régler son PATH correctement pour avoir /usr/local/bin avant /usr/bin.
S'il te faut vraiment un truc dans /usr parce qu'un programme mal foutu en a besoin, tu peux installer dans /usr/local, éventuellement renommer le truc existant dans /usr (genre "mv brol brol.old") et faire un lien symbolique vers le truc qui va bien dans /usr/local ("ln -s /usr/local/brol /usr/brol").
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Le ./configure, il prépare juste à la compilation, il faut ensuite compiler et enfin installer. En général suffit donc de faire ensuite un "make && make install". Pour les paquets que tu installes toi même depuis les sources, il est généralement préférable de les installer dans /usr/local/ (ou /opt ?) histoire de pas avoir trop d'interférence avec urpmi/apt/... En général ça ce fait au configure ("./configure --prefix=/usr/local/"). Pour la désinstallation c'est un peu la foire. Le plus simple c'est probablement d'utiliser stow.
C'est aussi souvent une bonne idée de lire la documentation (ya souvent un fichier INSTALL qui traine) avant de commencer à compiler quoi que ce soit.
Tout à fait. Mon mot de passe, c'est tout simplement le nom de mon
chien. Mon chien, il s'appelle 23;{zk7W?p et il change de nom toutes
les semaines.
-- Uvoguine
Je m'en doute mais quel est l'intérêt de ce préfixe ? Surtout s'il faut refaire la même chose pour Konqueror. Ensuite c'est IE, Opera et les autres qui vont s'y mettre et pour avoir des bords arrondis sur un maximum de browsers va falloir mettre les 50 attributs qui ne différent que par leurs premières lettres ? Je comprend pas l'intérêt d'utiliser une extension spécifique alors qu'il y a une draft du W3C qui fait la même chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Comment programmer un de ces touches pour arrêter mozilla directement ?
Si tes touches sont supportées par le noyau (dans le cas contraire tu peux toujours utiliser une combinaison genre ctrl+k+m) tu dois pouvoir faire ça avec xbindkeys.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# PF & XORP
Posté par Krunch (site web personnel) . En réponse à la dépêche OSPF débarque chez OpenBSD. Évalué à 3.
Par ailleurs pour ce qui est de remplacer les Catalyst (enfin plutôt les routeurs), c'est plutôt le travail de XORP.
http://www.xorp.org/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ca dépend ;-)
Posté par Krunch (site web personnel) . En réponse au message HTTP vs HTTPS. Évalué à 2.
Et spoofer une réponse DNS est bien moins difficile que de prendre le contrôle d'un routeur internet sans se faire repérer (bon c'est pas forcément facile non plus). Sinon j'ai lu un article [0] comme quoi avec certaines connexions câble, il est possible de sniffer le traffic internet de ses voisins mais ça date un peu donc ça a peut-être changé depuis.
Sinon pour détecter les sniffers sur son réseau local j'ai écrit un petit script [1] qui utilise arping(8) et qui marche bien. Et pour ceux qui veulent comprendre comment spoofer/sniffer (et donc comment se protéger de ce genre d'attaque) sur un réseau local, il y a cet excellent article [2] qui est passé dans MISC.
[0] http://www.securityfocus.com/news/7977(...)
[1] http://krunch.servebeer.com/~krunch/vrac/sw/qua/promiscan.sh(...)
[2] http://www.arp-sk.org/article/arp.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ssh + http ou https
Posté par Krunch (site web personnel) . En réponse au message Reprise de téléchargement distant et crypté ?. Évalué à 2.
http://www.psc.edu/networking/projects/hpn-ssh/(...)
J'ai aussi fait un paquet pour Debian Sarge (pas testé): http://users.skynet.be/bs244610/ssh_3.8.1p1-8.sarge.3.dynwin.1_i386(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dormir plus !
Posté par Krunch (site web personnel) . En réponse au journal Sommeil polyphasique. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: algorithmes
Posté par Krunch (site web personnel) . En réponse au message comment trier des nombres?. Évalué à 3.
D'un autre côté si le but est de comprendre et implémenter des algorithmes de tri, ça n'a bien sûr aucun intérêt.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# algorithmes
Posté par Krunch (site web personnel) . En réponse au message comment trier des nombres?. Évalué à 5.
http://fr.wikipedia.org/wiki/Algorithme_de_tri(...)
http://www.nist.gov/dads/HTML/sort.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# dyndns, no-ip
Posté par Krunch (site web personnel) . En réponse au message Utilsation de ssh avec une ip inconnu. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# c'est quoi un trackback ?
Posté par Krunch (site web personnel) . En réponse au journal Raz le c*l de ces spammeurs !. Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: messages kernel
Posté par Krunch (site web personnel) . En réponse au message Redirection des messages de la console. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# messages kernel
Posté par Krunch (site web personnel) . En réponse au message Redirection des messages de la console. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dormir plus !
Posté par Krunch (site web personnel) . En réponse au journal Sommeil polyphasique. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# d4x
Posté par Krunch (site web personnel) . En réponse au journal gwget, un utilitaire bien sympatique. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pf
Posté par Krunch (site web personnel) . En réponse au message limiter l'upload adsl. Évalué à 3.
http://www.benzedrine.cx/ackpri.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hum ...
Posté par Krunch (site web personnel) . En réponse au message et merde... un script kiddie !. Évalué à 5.
Un moyen relativement sûr de faire la réinstallation à distance serait de commencer par compiler CryptCat ainsi que les binaires de base (BusyBox est ton ami) statiquement sur une machine sûre et les uploader sur la machine compromise. S'arranger pour ne plus utiliser que ces programmes. Notamment ne plus utiliser le sshd original qui peut avoir été compromis aussi. Tu devrais pouvoir obtenir un shell par cryptcat avec un truc genre "# cryptcat -e /safe/bin/sh -l -p 1234 -k mekmitasdigoat" et "$ cryptcat -k mekmitasdigoat example.org 1234". De la tu peux faire un chroot qui te forcerait à utiliser, les nouveaux binaires, dans ce cas, ne pas oublier de faire les mknod qui vont bien avant de passer à la suite.
Debootstraper un système Debian de base sur une machine sûre, le mettre sur un système de fichiers qui va bien, uploader la "partition" sur la machine compromise à traver CryptCat, genre "# cryptcat -k mekmitasdigoat -l -p 4321 -q0 > /safe/dev/hda2" et "$ cryptcat -k mekmitasdigoat example.org 4321 < debian-base.ext3" avec hda2 une partition "libre" que tu as démontée préalablement (genre n'importe quoi sauf /, éventuellement la partition de swap si elle est assez grosse, pas oublier de faire un swapoff avant). Maintenant tu peux monter la partition, chrooter vers le nouveau système et installer le bootloader. Ensuite yapluka rebooter et prier.
Si tu réussis, tu peux être raisonnablement sûr que tu as un système de bases propre. Si tu es paranoïaque, tu peux imaginer que le rootkit est au niveau du noyau et qu'il sait réinfecter un nouveau système que tu installes à partir de programmes non compromis ou que le sshd sait infecter les programmes qu'il voir passer de manière à ce qu'ils infectent à leur tour les fichiers qu'ils manipulent ou qu'il y a un daemon caché qui injecte du code malsain dans tous les nouveaux processes qu'il voit apparaitre ou qu'il y a quelqu'un connecté par une backdoor qui surveille ou bien... mais alors ya plus grand chose à faire à part réinstaller vraiment "from scratch".
A l'avenir pour diminuer les risques de compromission complète du système quand un daemon se fait exploiter tu peux mettre un maximum de truc dans des "jails chroot" ou mieux: des machines virtuelles en utilisant User-Mode-Linux par exemple. Par ailleurs le manuel de sécurisation Debian contient plein de trucs intéressants et faire tourner Sarge sur un serveur disponible depuis internet n'est peut-être pas une très bonne idée (oui je sais Woody est pas à jour mais au moins il y a des màj de sécurité et apt-get peut être mis dans un cron sans risque).
Bon amusement :/
Bien entendu je ne saurais être tenu pour résponsable des dégats éventuels causés par l'applications de ce que j'ai décrit plus haut.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: fritalk est down.
Posté par Krunch (site web personnel) . En réponse au journal fritalk est down.. Évalué à 3.
Ou du RAID1 (mirroring de disques).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Open Source, rien à voir
Posté par Krunch (site web personnel) . En réponse au journal Problémes avec le système d'enchère Ebay ?. Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# mes bookmarks
Posté par Krunch (site web personnel) . En réponse au message alternative à DLFP. Évalué à 2.
http://undeadly.org/(...) (en anglais)
http://00f.net/(...) (en anglais)
Mais ça remplace pas DLFP, c'est juste un complément :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ./configure && make && make install
Posté par Krunch (site web personnel) . En réponse au message Installer des sources. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Cooker
Posté par Krunch (site web personnel) . En réponse au message Installer des sources. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Cooker
Posté par Krunch (site web personnel) . En réponse au message Installer des sources. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Cooker
Posté par Krunch (site web personnel) . En réponse au message Installer des sources. Évalué à 2.
S'il te faut vraiment un truc dans /usr parce qu'un programme mal foutu en a besoin, tu peux installer dans /usr/local, éventuellement renommer le truc existant dans /usr (genre "mv brol brol.old") et faire un lien symbolique vers le truc qui va bien dans /usr/local ("ln -s /usr/local/brol /usr/brol").
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# ./configure && make && make install
Posté par Krunch (site web personnel) . En réponse au message Installer des sources. Évalué à 2.
C'est aussi souvent une bonne idée de lire la documentation (ya souvent un fichier INSTALL qui traine) avant de commencer à compiler quoi que ce soit.
http://www.gnu.org/software/stow/stow.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: bof
Posté par Krunch (site web personnel) . En réponse au journal worm MySQL. Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: -moz-border-radius
Posté par Krunch (site web personnel) . En réponse au message css et formes. Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# xbindkeys
Posté par Krunch (site web personnel) . En réponse au message Limiter mozilla. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.