----- Original Message -----
From: "Guillaume DELANOY" <[EMAIL PROTECTED]>
> Merci � tous ceux qui m'ont r�pondu sur ce sujet, je m'instruis
beaucoup ici
> :)) !
> Il me reste quand m�me 2 ou 3 doutes ... je m'explique :
>
> > FTP comme TELNET comme POP3 et d'autres v�hiculent les login
mot
> > de passe en clair sur le reseau.
> > En gros, c est facile en "ecoutant" de facon illicite le
traffic
> > reseau de recuperer ces infos la
>
> Oui OK, je l'ai d�j� fait avec l'analyseur de trames de NT
Server (eh oui
> j'ai honte, mais il faut bien commencer quelque part ;) ...
mais bon il vaut
> mieux conna�tre l'heure exacte du login pour �couter � ce
moment-l�, sinon
> y' a � boire et � manger pour des semaines en interceptant les
paquets sur +
> de 2 min. !
Il existe des �v�nenements qui indiquent le d�buts des connexion.
Tu fais une recherche dessus et tu trouve tout de suite :
exemple : C = adresse IP du client, S celle du serveur. C fait un
telnet sur S (port TCP 23)
Il suffit de reperer la sequence :
source dest Flags
C:quelconque S:23 SYN
S:23 C:quelconque SYN ACK
C:quelconque S:23 ACK
En effet cette sequence marche l'�tablissement d une session TCP
(TELNET dans ce cas) et g�n�ralement les LOGIN/PASSWORD suivent
rapidement.
> > TCP/IP�est au dessus d'Ethernet (puisqu on parle le MAC
address)
> > et donc les paquets TCP/IP qui sont encapsul�s dans des
trames
> > ETHERNET n'ont aucune info sur les MAC address.
>
> Ah bon ? je pensais que les en-t�tes des paquets IP
mentionnaient au moins
> la MAC-Adress de l'exp�diteur, qu'on aurait pu retrouver en
> filtrant/interpr�trant les en-t�tes avec un script, ou mieux en
recompilant.
> Je pensais aussi que les couches OSI tenaient respectivement
compte des
> pr�c�dentes ( couche 2 pour la MAC Adress, prise en compte dans
les couches
> 3 et 4 pour TCP ) ... bon ben C tout, je suis ben d��u alors .
Non car lors de la constitution d'un paquet de donn�es � envoyer
sur le r�seau, on descend dans la pile et r�seau, on ne monte pas
!!!!
Ca veut dire, en schematisant, mon appli prepare ses donnees
auxquelles on ajoute un header.
Ce paquet est envoy� a la couche TCP par exemple qui rajoute le
HEADER avec port source et port dest.
Lui-meme est envoy� � la couche IP qui ajoute les adresses
sources et destination.
Lui meme est envoy� a la couche ETHERNET qui rajoute les MAC
sources et dest avant d envoyer le paquet sur le r�seau.
Comme on le voit, heureusement que g�n�ralement un protocole ne
s'occupe pas de ce qu'il a en dessous :
- parce que le driver de la carte reseau (ethernet ou autre) meme
la plus exotique (genre ATM) est interoperable avec les couche au
dessus (pas de stack IP sp�cifique)
- on serait oblig� pour tenir compte de ce qu'il y a en dessous
d'implementer dans chaque couche, toutes les possibilit�s de
combinaison de ce qu'on pourrait trouver dessous (mission
impossible).
[...]
> > En tout cas moi ce que j'en dis pour un PC "poste de travail"
a la maison
> c'est
> > de bloquer TOUT services (telnetd, ftpd, fingerd, serveur
pop/IMAP) on en
> a pas
> > besoin pour naviguer sur le net.
>
> Si je choisis de bloquer les ports 21, 23, 25 et 110 par
exemple, ca risque
> de me poser des probl�mes ensuite avec les applis *clientes*
qui utilisent
> ces ports (messagerie, client FTP, telnet ...), non ? Et si je
d�sactive les
> d�mons (services) correspondants, ca pose des probl�mes aussi
pour les m�mes
> applis ?
Les Well-Known Ports (ports bien connus), list�s dans le fichier
/etc/services, sont les ports utilis�s par les serveurs. Pourquoi
? Tout simplement parce que, si j'installe un serveur web sur le
port 90 au lieu de 80, les gens qui connaitront mon nom de
domaine mais par defaut ne trouveront pas le serveur web.. pas
top
C�t� client, rien ne m'oblige � me connecter sur un port donn� d
un serveur depuis le meme port de ma machine !!! J'ajouterai
HEUREUSEMENT pas car si j'installe un serveur sur mon linux
(genre TELNETD sur le port 23) et que je veuille utiliser le
client pour me connecter a un autre serveur (faire un TELNET
depuis mon serveur vers un autre), le syst�me ne pourrait cr�er
la connexion car le port serait d�j� occup�( le port 23 serait
deja occup� par TELNETD). Dans les fait, il est impossible pour
quelqu un d'autre que root d'utiliser sur une machine (binder)
des ports <1024. Donc quand j'utilise un client, le port du cot�
client est >1024 et diff�rent pour 2 connexions cons�cutives.
Donc pas de soucis a bloquer ces ports la !
> >> ET � bien utilis[er] les fichiers /etc/hosts.allow et
/etc/hosts.deny <<
> > Si on utilise host.allow, on a d�j� beaucoup moins besoin de
hosts.deny
> ;-)
>
> Mon truc, C T d'interdire tout dans hosts.deny, puis
d'autoriser seulement
> en fonction des besoins dans hosts.allow ... bien s�r s'il y a
une meilleur
> m�thode, ca m'int�resse,
> mais je m'�tais dit qu'appliquer strictement la d�marche
inverse des gens de
> Seattle ;), c'�tait forc�ment mieux pour la s�curit�, qu'en
pensez-vous ??
Cette d�marche est LA MEILLEURE approche en terme de s�curit� :
Tout ce qui n'est pas EXPLICITEMENT autoris� est INTERDIT.
Dans les faits, c est plus difficile a mettre en oeuvre surtout
avec host.allow et host.deny (ces fichiers sont plutot utilis�s
pour filtrer les acc�s aux serveurs qui sont sur ta machine.
C�t� client, tu peux configurer IPCHAINS pour filtrer le
traffic (voir site LEA de serge T) mais un conseil g�n�ral pour
tout le monde : avant de vouloir vous lancer dans du filtrage de
traffic, il faut avoir des bonnes connaissance des protocoles IP,
TCP, UDP et ICMP parce que sinon, vous risquez de mettre en
oeuvre des regles incompletes voire inefficaces sans compter sur
le debug qui pourrait etre difficile.
> Merci, bonne soir�e et bon week-end � tous,
de rien
----------------------------------------------------------
Frederic PLE
email: [EMAIL PROTECTED] Yahoo! Messenger: gvfred
----------------------------------------------------------
Get free certificates and use digital signature for emails :
http://www.thawte.com/certs/personal/contents.html
Make money to surf :
https://www.alladvantage.com/home.asp?refid=IIU-338
http://www.mediabarre.com/cgi-bin/mba.cgi?004761
