pour une telle configuration, tu as tout intérêt à utiliser une distrib un peu ancienne, moins gourmande en mémoire (principalement pour l'interface graphique).
Sinon, tu peux utiliser une distribution récente, à condition de faire un peu attention à ce que tu installes dessus (limiter le nombre de services qui se lancent au démarrage par exemple).
Enfin, je te conseille d'utiliser les environnements de bureaux légers : IceWM ou Windowmaker par exemple
D'après Mr Ballmer, il ne faut pas "acheter des logiciels dont les auteurs sont hors la loi". Certes, mais sous Windows, aucun logiciel payant ne violent un brevet logiciel ?
Diantre, et Internet Explorer alors ? Il est payant (puisque acheté avec Windows), et pourtant il violent bien le brevet sur les pluggins, non ? http://linuxfr.org/2003/09/02/13811.html(...) Ah, mais le brevet a été invalidé, où doit l'être ? Sauvé alors ?
Et tout les autres softs qui tournent sous Windows, du type DVDShrink , DivX5, etc... Cela ne viole aucun brevet ?
Enfin, plutôt que de voir le mal de l'autre coté de la barrière, Mr Ballmer ferait mieux de regarder devant sa fenêtre (*)
Ta question n'est pas très clair, aussi je ne suis pas sûr que ma réponse y soit adapté :
- avec "--to-source", netfilter modifie les paquets arrivant d'internet et qui rentrent dans ton réseau; L'adresse IP SOURCE est remplacée par celle de "--to-source", qui est généralement celle de l'interface réseau INTERNE de ton firewall Linux. Ainsi, la machine qui va recevoir ces paquets pensera qu'il arrivent depuis le firewall, et non plus d'Internet. lorsque la machine répondra, elle répondra directement au firewall, qui renverra l'information à la machine se trouvant sur Internet. L'intérêt de cette technique est qu'il n'est pas nécessaire de definir une route par défaut pour la machine cliente de ton réseau interne. Ainsi, un intrus qui prend le contrôle de cette machine ne pourra pas sortir de ton reseau Interne, il sera donc piégé sur cette machine.
- avec "-j masquerade", les adresses IP SOURCE des paquets arrivant d'internet NE sont PAS modifiés. Donc si la machine cliente doit répondre, elle DEVRA connaître la route par défaut permettant d'acceder à internet. Et donc tout autre programme tournant sur cette machine pourra accéder à internet, ce qui n'est pas forcément une nécessité.
Personnellement, je ne me sens pas très touché par la pub. Par contre, lorsque j'utilise un naviagteur web sur une autre machine que la mienne, je suis très surpris de la quantité de pubs qui inonde les navigateurs, et spécialement IE.
Mes armes ?
- Privoxy http://www.privoxy.org/(...) , qui est un "proxy filtrant" que l'on installe en localhost. Je trouve qu'il est plus puissant que adblock, car son moteur de filtrage peut utiliser des expressions régulières. Il fitre aussi les cookies, et les codes javascript qui affichent les popup. Enfin, on peut configurer des sites dans une "whitelist", ce qui permet de naviger sans filtrage sur certains sites (par exemple, j'autorise LinuxFR a poser un cookie sur mon navigateur).
- Le filtrage des cookies par firefox : Privoxy laisse passer les cookies posés par Javascript (je l'ai configuré comme cela), donc certains sites peuvent toujours me poser des cookies. De temps en temps, je fais le tri. Les cookies que je trouve trop intrusif, comme ceux de Google par exemple, sont mis dans la "blacklist" de firefox, et ils ne pourrons plus me poser de cookies
- Effacement automatique des cookies. J'ai écris un petit programme en Perl qui efface tout les cookies de firefox, exceptés ceux d'une "whitelist" (comme ceux de LinuxFR). Le script est lancé dès que je click sur l'icone de firefox
Avec ces 3 outils, les sites web qui veulent me tracer en bave pas mal, et je n'ai aucune pub. De plus, même si un site stocke les pub sur son serveur (au lieu de passer par un prestataire), je peux filter l'url de ses pubs via Privoxy (ce que ne peux pas faire adBlock)
Ceux qui sont interessés par mon script en Perl d'effacement de cookies, ou par mes fichiers de configuration de Privoxy, peuvent me contacter en privé.
Comment vont faire les enquêteurs pour les identifier avec ce procédé d'identification ? Ils ne peuvent pas.
Pas sûr. Il suffit que le driver de la dite imprimante se connecte une seul fois à Internet, et envoie au fabriquant :
- les numéros de série de l'imprimante et de la cartouche (il suffit de dialoger avec l'imprimante pour les avoir)
- l'identifiant unique de Windows, plus les eventuelles adresses MAC de carte réseau, carte mère, etc...
- eventuellement les adresse emails stocké sur la machine
Encore faut il que la machine se connecte à Internet. J'imagine qu'un faussaire ne fera pas ce genre de bourde...
Pour tes chroot, sans un systeme de jail à la GRsecurity, c'est vraiment utile ?
Comme toujours, tout dépend du niveau de sécurité attendu. Un simple chroot permet de limiter les dégats, et bloquera un script kiddy qui ne pourra pas lancer son "wget" pour installer un rootkit. Par contre, cela ne tiendra pas contre un intrus expérimenté, qui veut vraiment rentré dans la machine.
C'est pourquoi la sécurité n'une machine ne se concoit que de façon globale, en accumulant les méchanismes de sécurité, afin de ralentir un maximum l'intrus.
Je rajouterai à l'explication ci-dessus quelques petites choses :
- en terme de charge mémoire pour des processus peu utiliser (sshd par exemple), xinetd est plus intéressant. En effet, xinetd est present en mémoire, mais tant qu'aucune connexion n'est lancé sur le port en question (22 pour sshd), le demon (sshd) lui n'est pas executé.
- xinetd propose tout un tas d'options intéressantes, et qui ne sont pas forcement développés par les mainteneurs des démons : restriction d'interface et d'adresse IP, log centralisés, restriction des connexions à certaines dates/heures, etc...
- certaines fonctionnalités comme "echo", "discard", "chargen", sont parfoit très pratiques pour tester un réseau, mais sont en général très peu souvant utilisées. Et bien ce type de service est fournit par défaut par xinetd, sans avoir besoin de charger plus la mémoire de la machine.
- enfin, un truc assez pratique: Lorsque l'on modifie une option de configuration d'un démon (sshd, proftpd, ...), il n'y a pas besoin de rédemarrer le démon en question, ni même redémarrer xinetd. Il suffit de refaire une connexion sur le service (22, 21, ...), pour qu'un nouveau demon démarre, avec la nouvelle configuration. Cela n'a l'air de rien, mais lorsque l'on configure un nouveau démon, il est souvant utile de faire des tests de différentes configurations, et ne par avoir à faire de "service demon restart", cela fait gagner du temps !
sécuriser une machine ne s'explique pas en 5 minutes. Cependant, voici quelques pistes pouvant t'y aider :
- j'ai écrit une documentation http://olivieraj.free.fr/fr/linux/information/firewall/(...) sur le sujet, et je t'y invite à la lire. La partie II parle de la sécurisation des démon (http, ftp, etc...), et la partie III explique comment configurer netfilter/iptables.
- pour ce qui est des démons, la première chose à faire est de limiter au strict minimum ceux qui vont écouter sur les interfaces réseaux sensibles. Par exemple, si tu mets à jour ton serveur avec Samba/NFS via ton réseau local, pas la peine que Samba/NFS écoute aussi sur l'interface réseau Internet. "xinetd" ( http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) ) fait très bien cela, avec ses options "only_from" et "bind". Mais chaque démon a généralement des options permettant de le faire (comme l'indique http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) ).
- tu peux mettre aussi en place des "chroot" ( http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-04.htm(...) ). Personnellement, sur mon réseau local avec mon serveur DNS ("named"), j'ai créé ce type de chroot car "named" est un démon qui était à l'époque "souvant" sujet à des découvertes de buffer overflow. Cela n'est pas forcément trivial de créer un tel chroot, et cela n'apporte pas une sécurité absolue. Mais c'est un bon début.
- dans une approche plus globale de la sécurité, tu peux aussi changer les droits des éxectutables situés sur ta machine. Par exemple, sur une machine serveur ou passerelle, les commandes "wget" ou "ftp" ne sont pas toujours strictement nécéssaires à tout les utilisateurs. Pourtant, si par exemple un intrus réussi à faire executer une commande shell par ton serveur apache, celui-ci pourra alors faire un "wget" sur un autre serveur qu'il contrôle, afin de uploader sur ta machine un rootkit. La solution pour éviter ceci : supprimer "wget", ou plus simplement, changer les droits d'accès à wget ("chown o-rwx wget"), pour que personne hormis le root (et un groupe d'utilisateurs de confiance) ne puisse l'utiliser.
- enfin, il faut faire très très attention à la configuration de tes demons eux-même. Pour cela, il faut lire à fond la doc, et regarder toutes les options. Un exemple simple : "proftpd", un serveur FTP. si tu prends la configuration par défaut, tout utilisateurs de ta machine pourra se connecter à ce serveur. Y compris un intrus utilisant les comptes de type "système" comme "apache", "mail", "nobody", etc... En lisant des doc sur Internet, tu trouveras facilement comment restreindre l'accès à "proftpd" à seulement des comptes de "vrais" utilisateurs. Autre exemple : ssh. Il n'est pas question de laisser un accès ssh à tout le monde. L'option "allowuser" permet de restraindre l'accès qu'à un certain nombre de comptes ("guillaume" par exemple). Et bien entendu, interdiction de se loger directement en ssh sur la machine ("permitrootlogin no"), mais passer passer d'abord par un compte utilisateur ("guillaume"), puis faire un "su".
Ceci n'est qu'un ébauche de réponse à ta question. Je laisse d'autres LinuxFRiens apporter leurs propre experiance.
Si ton réseau local est en 192.168.0.0/255.255.255.0
et que ton linux a pour adresse IP 192.168.0.1 (interface eth0)
alors tu peux configurer la ligne :
LAN[0]="eth0|192.168.0.1|255.255.255.0|192.168.0.255||non_routable"
la je viens de copier 200mo de fichiers en tout genre sur ce serveur et aucun problème.
Tu ne remarqueras des problèmes de perforance que sur des GROS fichiers. Pour des petits fichiers, le mécanisme de cache disque pasquera la 1ère écriture de fichiers entièrement vide
et sinon, ce serveur n'a pas de windows, il est juste sous linux ;)
Quel est l'intérêt d'avoir des partitions FAT32 alors ? Passe les en ext2/3 ou autre type de partition Linux, tu auras moins de problèmes.
Tu es quand même sur un site qui parle de Linux. Alors le minimum aurait été de rechercher le mot 'windows" dans la page (fonction "rechercher" ou "/" dans Mozilla). La 4ème occurence te donne le post http://linuxfr.org/submit/comments,19216,594909,1.html(...) dont le titre est "lien pour télécharger QT/windows"... Difficile de faire plus explicite, non ?
On va donc dire que tu n'as donc vraiment pas prit la peine de chercher. Avant de demander du support, il faudrait faire quand même un minimum d'effort, non ?
renvoie-nous le résultats des commandes (tapées en temps que root) "ifconfig" et "route -n" de chaque machine.
La première commande indiquera si il y a des problèmes de paquets perdus ou des erreurs au niveau de la carte réseau. Auquel cas, c'est presque certainement un problème de cablage mal fait
La 2nd commande permettra de voir si tu ne t'es pas trompé dans la configuration IP de chaque machine
j'ai eu exactement le même problème sur une MDK 9.2 et un kernel 2.4. Ton problème est dû au fait que lorsque Samba recoit l'ordre d'écriture d'un fichier de 700Mo, il va commencer, pour une partition FAT32, à ecrire un fichier vide de 700Mo. Le fichier sera constitué uniquement de "0". Puis, samba va faire une 2nd écriture sur ce fichier "vide" de 700Mo, et écrire les données que le client samba va envoyer. Le temps de la première écriture n'est pas négligeable, et les fortes occupations CPU de "pdflush" sont les écritures sur le DD
2 informations intéressantes :
- Si la partition sur laquelle on écrit ce fichier de 700Mo N'est PAS une FAT32, ce phénomène n'apparaît pas.
- Si le client samba (ton Windows XP) N'est PAS un Windows, ce phénomène n'apparaît pas non plus. Donc si le client est un Linux, il n'y a pas de problème.
J'ai pas mal cherché des infos sur le web, et j'ai analysé (avec un sniffer de trames IP) les différences entre les connexions smb d'un Linux et d'un Windows : Il n'y a pas de solution ou de configuration de ton serveur SAMBA pour résoudre ce problème.
La seule solution est de reformater ta partition FAT32 en ext2/3 reiserfs, ou autre.
Par contre, si ton problème est d'accéder à ces fichiers une fois que tu auras rebooté ton Linux sous Windows (c'est la seul explication plausible au fait que tu ais cette partition FAT32), je te conseille de regarder du coté de http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm(...) ou http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm(...) . Le 2nd est particulièrement intéressant, puisque c'est un driver NT/2K/XP qui permet d'accéder en LECTURE à tes partitions ext2/3.
On peut dès à présent developper sous Windows et QT 3 des applications GPL. Pour cela, il faut utiliser le port win32 de la version GPL de Linux (ouch, c'est compliqué !) : http://kde-cygwin.sourceforge.net/qt3-win32/(...)
C'est 100% natif win32, le seul besoin de l'appli développée est une dll de QT3 de 6Mo.
Je developpe actuellement un soft dans cet environnement là, et cela marche bien. J'utilise "MinGW", le port Win32 de GCC, pour les compilations.
Le but de cette cage de Fadaday est uniquement que ce soit le possesseur de la carte qui contrôle les ondes qui sont émises. Et qui décide du moment où il se soumettra à un contôle d'identité.
Si pour rentrer dans un magasin particulier, la condition obligatoire soit de subir ce contôle, alors le possesseur de la carte pourra la sortir de sa protection, et valider le contôle. Après tout, il est courant dans certains magasins que l'on demande de vérifier le contenu des sacs, à l'entrée ou la sortie (spécialement dans le cadre des plans vigipirate).
Quand aux contôles de police dans la rue, c'est la même chose : Si un policier voudra connaître mon identité, il n'aura qu'à me la demander.
Après tout, il existe déjà des malettes / valises complètement métaliques qui peuvent, peut-être, servir de cage de Faraday. Mettre sa carte d'identitée à l'interieur serait donc une preuve de maveillance ? Faut il supprimer du marché ce type de produits ?
Dois-je rappeler que la carte RFID (donc une puce sans contact c'est-à-dire qu'on peut être contrôlé à son insu)
Ne peut-on pas mettre cette carte dans un étuit isolant aux ondes HF (du papier d'aluminum par exemple, afin de faire une cage de Faraday) ? Cela devrait permettre de ne pas être controlé à son insu, non ?
- commencer par regarder les statistiques d'ipables :
iptables -L -n -v
la colonne de gauche contient les paquets/octets qui sont passés par chacune de tes rêgles. Tu pourras savoir quelle rêgle arrête les paquets
- essaye aussi 'ifconfig eth0" (si "eth0" est ta carte réseau) : En le tapant entre 2 accès à tes serveurs, tu verras si ta machine a reçu / emis des paquets
- installer un sniffer de trame (tcpdump, ou mieux http://www.ethereal.com/(...) qui est graphique) est très utile, afin d'avoir une idée précise de ce qui passe
n'oublions pas qu'il y a qq temps on vait reussi a montrer que M$ envoyait sur ses serveurs la liste des titres joues dans le media player et ceci a l'insu du plein gres de l'utilisateur
Tu as plus d'infos STP ? Je n'utilise pas Windows, mais je le soupconne depuis longtemps d'avoir ce genre de pratiques. Si c'est effectivement prouvé, les utilisateurs de Windows que je connais peuvent être intéressés par cette information.
# Suggestions
Posté par Olivier (site web personnel) . En réponse au message Linux pour un ancien ordinateur. Évalué à 2.
pour une telle configuration, tu as tout intérêt à utiliser une distrib un peu ancienne, moins gourmande en mémoire (principalement pour l'interface graphique).
Sinon, tu peux utiliser une distribution récente, à condition de faire un peu attention à ce que tu installes dessus (limiter le nombre de services qui se lancent au démarrage par exemple).
Enfin, je te conseille d'utiliser les environnements de bureaux légers : IceWM ou Windowmaker par exemple
# Amusant
Posté par Olivier (site web personnel) . En réponse au journal Steve Balmer invité d'honneur chez HP. Évalué à 3.
Diantre, et Internet Explorer alors ? Il est payant (puisque acheté avec Windows), et pourtant il violent bien le brevet sur les pluggins, non ? http://linuxfr.org/2003/09/02/13811.html(...) Ah, mais le brevet a été invalidé, où doit l'être ? Sauvé alors ?
Et tout les autres softs qui tournent sous Windows, du type DVDShrink , DivX5, etc... Cela ne viole aucun brevet ?
Enfin, plutôt que de voir le mal de l'autre coté de la barrière, Mr Ballmer ferait mieux de regarder devant sa fenêtre (*)
(*) Elle était facile celle-la :)
# Pas très clair...
Posté par Olivier (site web personnel) . En réponse au message Une question sur NAT. Évalué à 1.
- avec "--to-source", netfilter modifie les paquets arrivant d'internet et qui rentrent dans ton réseau; L'adresse IP SOURCE est remplacée par celle de "--to-source", qui est généralement celle de l'interface réseau INTERNE de ton firewall Linux. Ainsi, la machine qui va recevoir ces paquets pensera qu'il arrivent depuis le firewall, et non plus d'Internet. lorsque la machine répondra, elle répondra directement au firewall, qui renverra l'information à la machine se trouvant sur Internet. L'intérêt de cette technique est qu'il n'est pas nécessaire de definir une route par défaut pour la machine cliente de ton réseau interne. Ainsi, un intrus qui prend le contrôle de cette machine ne pourra pas sortir de ton reseau Interne, il sera donc piégé sur cette machine.
- avec "-j masquerade", les adresses IP SOURCE des paquets arrivant d'internet NE sont PAS modifiés. Donc si la machine cliente doit répondre, elle DEVRA connaître la route par défaut permettant d'acceder à internet. Et donc tout autre programme tournant sur cette machine pourra accéder à internet, ce qui n'est pas forcément une nécessité.
J'ai expliqué plus en détails ces problèmes sur mon site : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-08.htm(...)
[^] # Re: La grande bataille est lançé
Posté par Olivier (site web personnel) . En réponse à la dépêche Google Talk : messagerie instantanée et voix sur IP basée sur Jabber. Évalué à 6.
Mes armes ?
- Privoxy http://www.privoxy.org/(...) , qui est un "proxy filtrant" que l'on installe en localhost. Je trouve qu'il est plus puissant que adblock, car son moteur de filtrage peut utiliser des expressions régulières. Il fitre aussi les cookies, et les codes javascript qui affichent les popup. Enfin, on peut configurer des sites dans une "whitelist", ce qui permet de naviger sans filtrage sur certains sites (par exemple, j'autorise LinuxFR a poser un cookie sur mon navigateur).
- Le filtrage des cookies par firefox : Privoxy laisse passer les cookies posés par Javascript (je l'ai configuré comme cela), donc certains sites peuvent toujours me poser des cookies. De temps en temps, je fais le tri. Les cookies que je trouve trop intrusif, comme ceux de Google par exemple, sont mis dans la "blacklist" de firefox, et ils ne pourrons plus me poser de cookies
- Effacement automatique des cookies. J'ai écris un petit programme en Perl qui efface tout les cookies de firefox, exceptés ceux d'une "whitelist" (comme ceux de LinuxFR). Le script est lancé dès que je click sur l'icone de firefox
Avec ces 3 outils, les sites web qui veulent me tracer en bave pas mal, et je n'ai aucune pub. De plus, même si un site stocke les pub sur son serveur (au lieu de passer par un prestataire), je peux filter l'url de ses pubs via Privoxy (ce que ne peux pas faire adBlock)
Ceux qui sont interessés par mon script en Perl d'effacement de cookies, ou par mes fichiers de configuration de Privoxy, peuvent me contacter en privé.
# DefaultRoout ~
Posté par Olivier (site web personnel) . En réponse au message Proftpd: afficher uniquement le rep voulu. Évalué à 1.
DefaultRoot ~
Chaque utilisateur sera ainsi "piégé" dans son propre répertoire $HOME, qu'il verra comme étant le "/". On appelle cela un "chroot".
[^] # Re: Hum
Posté par Olivier (site web personnel) . En réponse au sondage La sécurité de mon WLAN. Évalué à 3.
Au bout d'un certain temps (disons, 10 minutes...), tu auras capturé assez de trames pour casser le WEP. Il y a une démo en flash qui montre ceci, basé sur une distribution LiveCD : http://www.hackingdefined.com/movies/whax-aircrack-wep.html(...)
http://100h.org/wlan/videos/whax-aircrack-wep.zip(...)
[^] # Re: Incrustation d'un code d'identification via les Laser Couleur
Posté par Olivier (site web personnel) . En réponse au journal Incrustation d'un code d'identification via les Laser Couleur. Évalué à 2.
Pas sûr. Il suffit que le driver de la dite imprimante se connecte une seul fois à Internet, et envoie au fabriquant :
- les numéros de série de l'imprimante et de la cartouche (il suffit de dialoger avec l'imprimante pour les avoir)
- l'identifiant unique de Windows, plus les eventuelles adresses MAC de carte réseau, carte mère, etc...
- eventuellement les adresse emails stocké sur la machine
Encore faut il que la machine se connecte à Internet. J'imagine qu'un faussaire ne fera pas ce genre de bourde...
[^] # Re: Vaste sujet
Posté par Olivier (site web personnel) . En réponse au journal Linux sécurisé, GRsecurity, RSBAC, PaX, SSP, libsafe, SElinux,.... Évalué à 1.
Comme toujours, tout dépend du niveau de sécurité attendu. Un simple chroot permet de limiter les dégats, et bloquera un script kiddy qui ne pourra pas lancer son "wget" pour installer un rootkit. Par contre, cela ne tiendra pas contre un intrus expérimenté, qui veut vraiment rentré dans la machine.
C'est pourquoi la sécurité n'une machine ne se concoit que de façon globale, en accumulant les méchanismes de sécurité, afin de ralentir un maximum l'intrus.
[^] # Re: Vaste sujet
Posté par Olivier (site web personnel) . En réponse au journal Linux sécurisé, GRsecurity, RSBAC, PaX, SSP, libsafe, SElinux,.... Évalué à 4.
- en terme de charge mémoire pour des processus peu utiliser (sshd par exemple), xinetd est plus intéressant. En effet, xinetd est present en mémoire, mais tant qu'aucune connexion n'est lancé sur le port en question (22 pour sshd), le demon (sshd) lui n'est pas executé.
- xinetd propose tout un tas d'options intéressantes, et qui ne sont pas forcement développés par les mainteneurs des démons : restriction d'interface et d'adresse IP, log centralisés, restriction des connexions à certaines dates/heures, etc...
- certaines fonctionnalités comme "echo", "discard", "chargen", sont parfoit très pratiques pour tester un réseau, mais sont en général très peu souvant utilisées. Et bien ce type de service est fournit par défaut par xinetd, sans avoir besoin de charger plus la mémoire de la machine.
- xinetd propose dans une syntaxe unique de configuration, ce qui permet d'éviter de connaitre toutes sortes de paramètres de configuration de différents démons (voir les différentes syntaxes dans les tableaux de http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) )
- enfin, un truc assez pratique: Lorsque l'on modifie une option de configuration d'un démon (sshd, proftpd, ...), il n'y a pas besoin de rédemarrer le démon en question, ni même redémarrer xinetd. Il suffit de refaire une connexion sur le service (22, 21, ...), pour qu'un nouveau demon démarre, avec la nouvelle configuration. Cela n'a l'air de rien, mais lorsque l'on configure un nouveau démon, il est souvant utile de faire des tests de différentes configurations, et ne par avoir à faire de "service demon restart", cela fait gagner du temps !
# Vaste sujet
Posté par Olivier (site web personnel) . En réponse au journal Linux sécurisé, GRsecurity, RSBAC, PaX, SSP, libsafe, SElinux,.... Évalué à 7.
sécuriser une machine ne s'explique pas en 5 minutes. Cependant, voici quelques pistes pouvant t'y aider :
- j'ai écrit une documentation http://olivieraj.free.fr/fr/linux/information/firewall/(...) sur le sujet, et je t'y invite à la lire. La partie II parle de la sécurisation des démon (http, ftp, etc...), et la partie III explique comment configurer netfilter/iptables.
- pour ce qui est des démons, la première chose à faire est de limiter au strict minimum ceux qui vont écouter sur les interfaces réseaux sensibles. Par exemple, si tu mets à jour ton serveur avec Samba/NFS via ton réseau local, pas la peine que Samba/NFS écoute aussi sur l'interface réseau Internet. "xinetd" ( http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) ) fait très bien cela, avec ses options "only_from" et "bind". Mais chaque démon a généralement des options permettant de le faire (comme l'indique http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.htm(...) ).
- tu peux mettre aussi en place des "chroot" ( http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-04.htm(...) ). Personnellement, sur mon réseau local avec mon serveur DNS ("named"), j'ai créé ce type de chroot car "named" est un démon qui était à l'époque "souvant" sujet à des découvertes de buffer overflow. Cela n'est pas forcément trivial de créer un tel chroot, et cela n'apporte pas une sécurité absolue. Mais c'est un bon début.
- dans une approche plus globale de la sécurité, tu peux aussi changer les droits des éxectutables situés sur ta machine. Par exemple, sur une machine serveur ou passerelle, les commandes "wget" ou "ftp" ne sont pas toujours strictement nécéssaires à tout les utilisateurs. Pourtant, si par exemple un intrus réussi à faire executer une commande shell par ton serveur apache, celui-ci pourra alors faire un "wget" sur un autre serveur qu'il contrôle, afin de uploader sur ta machine un rootkit. La solution pour éviter ceci : supprimer "wget", ou plus simplement, changer les droits d'accès à wget ("chown o-rwx wget"), pour que personne hormis le root (et un groupe d'utilisateurs de confiance) ne puisse l'utiliser.
- enfin, il faut faire très très attention à la configuration de tes demons eux-même. Pour cela, il faut lire à fond la doc, et regarder toutes les options. Un exemple simple : "proftpd", un serveur FTP. si tu prends la configuration par défaut, tout utilisateurs de ta machine pourra se connecter à ce serveur. Y compris un intrus utilisant les comptes de type "système" comme "apache", "mail", "nobody", etc... En lisant des doc sur Internet, tu trouveras facilement comment restreindre l'accès à "proftpd" à seulement des comptes de "vrais" utilisateurs. Autre exemple : ssh. Il n'est pas question de laisser un accès ssh à tout le monde. L'option "allowuser" permet de restraindre l'accès qu'à un certain nombre de comptes ("guillaume" par exemple). Et bien entendu, interdiction de se loger directement en ssh sur la machine ("permitrootlogin no"), mais passer passer d'abord par un compte utilisateur ("guillaume"), puis faire un "su".
Ceci n'est qu'un ébauche de réponse à ta question. Je laisse d'autres LinuxFRiens apporter leurs propre experiance.
# Netfilter_cfg
Posté par Olivier (site web personnel) . En réponse au message shorewall et smb. Évalué à 1.
Si ton réseau local est en 192.168.0.0/255.255.255.0
et que ton linux a pour adresse IP 192.168.0.1 (interface eth0)
alors tu peux configurer la ligne :
LAN[0]="eth0|192.168.0.1|255.255.255.0|192.168.0.255||non_routable"
Et si tu cherches une doc assez complète sur la sécurité et le firewall sous Linux, tu peux regarder ici : http://olivieraj.free.fr/fr/linux/information/firewall/(...)
[^] # Re: FAT32 + SMB = Grosse galère
Posté par Olivier (site web personnel) . En réponse au message Problème de transfert de fichiers windows/linux. Évalué à 1.
Tu ne remarqueras des problèmes de perforance que sur des GROS fichiers. Pour des petits fichiers, le mécanisme de cache disque pasquera la 1ère écriture de fichiers entièrement vide
et sinon, ce serveur n'a pas de windows, il est juste sous linux ;)
Quel est l'intérêt d'avoir des partitions FAT32 alors ? Passe les en ext2/3 ou autre type de partition Linux, tu auras moins de problèmes.
[^] # Re: Lien pour télécharger QT 4.0 pour Win32 ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 4. Évalué à 1.
Tu es quand même sur un site qui parle de Linux. Alors le minimum aurait été de rechercher le mot 'windows" dans la page (fonction "rechercher" ou "/" dans Mozilla). La 4ème occurence te donne le post http://linuxfr.org/submit/comments,19216,594909,1.html(...) dont le titre est "lien pour télécharger QT/windows"... Difficile de faire plus explicite, non ?
On va donc dire que tu n'as donc vraiment pas prit la peine de chercher. Avant de demander du support, il faudrait faire quand même un minimum d'effort, non ?
[^] # Re: Lien pour télécharger QT 4.0 pour Win32 ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 4. Évalué à 1.
# ifconfig
Posté par Olivier (site web personnel) . En réponse au message Pourquoi mon LAN est-il si lent ?. Évalué à 1.
renvoie-nous le résultats des commandes (tapées en temps que root) "ifconfig" et "route -n" de chaque machine.
La première commande indiquera si il y a des problèmes de paquets perdus ou des erreurs au niveau de la carte réseau. Auquel cas, c'est presque certainement un problème de cablage mal fait
La 2nd commande permettra de voir si tu ne t'es pas trompé dans la configuration IP de chaque machine
# FAT32 + SMB = Grosse galère
Posté par Olivier (site web personnel) . En réponse au message Problème de transfert de fichiers windows/linux. Évalué à 1.
j'ai eu exactement le même problème sur une MDK 9.2 et un kernel 2.4. Ton problème est dû au fait que lorsque Samba recoit l'ordre d'écriture d'un fichier de 700Mo, il va commencer, pour une partition FAT32, à ecrire un fichier vide de 700Mo. Le fichier sera constitué uniquement de "0". Puis, samba va faire une 2nd écriture sur ce fichier "vide" de 700Mo, et écrire les données que le client samba va envoyer. Le temps de la première écriture n'est pas négligeable, et les fortes occupations CPU de "pdflush" sont les écritures sur le DD
2 informations intéressantes :
- Si la partition sur laquelle on écrit ce fichier de 700Mo N'est PAS une FAT32, ce phénomène n'apparaît pas.
- Si le client samba (ton Windows XP) N'est PAS un Windows, ce phénomène n'apparaît pas non plus. Donc si le client est un Linux, il n'y a pas de problème.
J'ai pas mal cherché des infos sur le web, et j'ai analysé (avec un sniffer de trames IP) les différences entre les connexions smb d'un Linux et d'un Windows : Il n'y a pas de solution ou de configuration de ton serveur SAMBA pour résoudre ce problème.
La seule solution est de reformater ta partition FAT32 en ext2/3 reiserfs, ou autre.
Par contre, si ton problème est d'accéder à ces fichiers une fois que tu auras rebooté ton Linux sous Windows (c'est la seul explication plausible au fait que tu ais cette partition FAT32), je te conseille de regarder du coté de http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm(...) ou http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm(...) . Le 2nd est particulièrement intéressant, puisque c'est un driver NT/2K/XP qui permet d'accéder en LECTURE à tes partitions ext2/3.
[^] # Re: Lien pour télécharger QT 4.0 pour Win32 ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de Qt 4. Évalué à 4.
Pour le port qt3->qt4, il est indiqué dans la doc de rajouter "QT += qt3support" au fichier "<mon projet>/.pro", et de relancer "qmake" et "make
# Méga cours de C++ (C'est son nom)
Posté par Olivier (site web personnel) . En réponse au message Arriver à C++ en venant de .... Évalué à 2.
[^] # Re: Un peu trop rêveur ?
Posté par Olivier (site web personnel) . En réponse à la dépêche 10x10 - le pari de Jeff Waugh. Évalué à 4.
C'est 100% natif win32, le seul besoin de l'appli développée est une dll de QT3 de 6Mo.
Je developpe actuellement un soft dans cet environnement là, et cela marche bien. J'utilise "MinGW", le port Win32 de GCC, pour les compilations.
[^] # Re: little brother
Posté par Olivier (site web personnel) . En réponse au journal 1984. Évalué à 1.
Si pour rentrer dans un magasin particulier, la condition obligatoire soit de subir ce contôle, alors le possesseur de la carte pourra la sortir de sa protection, et valider le contôle. Après tout, il est courant dans certains magasins que l'on demande de vérifier le contenu des sacs, à l'entrée ou la sortie (spécialement dans le cadre des plans vigipirate).
Quand aux contôles de police dans la rue, c'est la même chose : Si un policier voudra connaître mon identité, il n'aura qu'à me la demander.
Après tout, il existe déjà des malettes / valises complètement métaliques qui peuvent, peut-être, servir de cage de Faraday. Mettre sa carte d'identitée à l'interieur serait donc une preuve de maveillance ? Faut il supprimer du marché ce type de produits ?
[^] # Re: little brother
Posté par Olivier (site web personnel) . En réponse au journal 1984. Évalué à 3.
Ne peut-on pas mettre cette carte dans un étuit isolant aux ondes HF (du papier d'aluminum par exemple, afin de faire une cage de Faraday) ? Cela devrait permettre de ne pas être controlé à son insu, non ?
# Statistiques d'iptables
Posté par Olivier (site web personnel) . En réponse au message Mon faïeurwôle pète un plomb ?. Évalué à 2.
- commencer par regarder les statistiques d'ipables :
iptables -L -n -v
la colonne de gauche contient les paquets/octets qui sont passés par chacune de tes rêgles. Tu pourras savoir quelle rêgle arrête les paquets
- essaye aussi 'ifconfig eth0" (si "eth0" est ta carte réseau) : En le tapant entre 2 accès à tes serveurs, tu verras si ta machine a reçu / emis des paquets
- installer un sniffer de trame (tcpdump, ou mieux http://www.ethereal.com/(...) qui est graphique) est très utile, afin d'avoir une idée précise de ce qui passe
- enfin, si tes connaissances en netfilter sont limitées, je te conseille mon site web http://olivieraj.free.fr/fr/linux/information/firewall/(...)
[^] # Re: hein?
Posté par Olivier (site web personnel) . En réponse au journal Inquiétudes : Carte d'identité électronique. Évalué à 1.
J'avais effectivement eu des informations sur ce sujet, mais rien de très concret.
[^] # Re: hein?
Posté par Olivier (site web personnel) . En réponse au journal Inquiétudes : Carte d'identité électronique. Évalué à 4.
n'oublions pas qu'il y a qq temps on vait reussi a montrer que M$ envoyait sur ses serveurs la liste des titres joues dans le media player et ceci a l'insu du plein gres de l'utilisateur
Tu as plus d'infos STP ? Je n'utilise pas Windows, mais je le soupconne depuis longtemps d'avoir ce genre de pratiques. Si c'est effectivement prouvé, les utilisateurs de Windows que je connais peuvent être intéressés par cette information.
[^] # Re: Version française disponible
Posté par Olivier (site web personnel) . En réponse au journal Mozilla(TM) Firefox(TM) 1.0.4 out. Évalué à 5.
la PrefBar est faite pour toi : http://prefbar.mozdev.org/(...)
Et la captutre d'écran : http://prefbar.mozdev.org/prefbar-demo.png(...)