Questions sur la sécurité (ports ouverts)

Support Debian
#4

Ok pour le portmap, merci.

Avanttcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 6710/portmap

[quote=“fran.b”]Fichier /etc/default/portmap
OPTIONS="-i 127.0.0.1"[/quote]
Aprèstcp 0 0 127.0.0.1:111 0.0.0.0:* LISTEN 9584/portmap

C’est toujours ça de fermé…

Mais j’ai encore des ports qui écoutent sur l’interface branchée à Internet :

tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN 9676/rpc.nfsd tcp 0 0 0.0.0.0:950 0.0.0.0:* LISTEN 9678/rpc.mountd tcp 0 0 0.0.0.0:54427 0.0.0.0:* LISTEN 6722/rpc.statd tcp 0 0 0.0.0.0:15007 0.0.0.0:* LISTEN 8949/python tcp6 0 0 ::1:139 :::* LISTEN 7649/smbd tcp6 0 0 fe80::20e:2eff:fef2:139 :::* LISTEN 7649/smbd tcp6 0 0 :::113 :::* LISTEN 7694/xinetd tcp6 0 0 ::1:445 :::* LISTEN 7649/smbd tcp6 0 0 fe80::20e:2eff:fef2:445 :::* LISTEN 7649/smbd tcp6 0 0 :::15007 :::* LISTEN 8949/python udp 0 0 0.0.0.0:2049 0.0.0.0:* 9676/rpc.nfsd udp 0 0 0.0.0.0:54018 0.0.0.0:* 8949/python udp 0 0 0.0.0.0:137 0.0.0.0:* 7647/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 7647/nmbd udp 0 0 0.0.0.0:59549 0.0.0.0:* 9174/(squid) udp 0 0 0.0.0.0:15007 0.0.0.0:* 8949/python udp 0 0 0.0.0.0:42403 0.0.0.0:* 6722/rpc.statd udp 0 0 0.0.0.0:58544 0.0.0.0:* 6901/avahi-daemon: udp 0 0 0.0.0.0:949 0.0.0.0:* 9678/rpc.mountd udp 0 0 0.0.0.0:3130 0.0.0.0:* 9174/(squid) udp 0 0 0.0.0.0:962 0.0.0.0:* 6722/rpc.statd udp 0 0 0.0.0.0:67 0.0.0.0:* 7838/dhcpd3 udp 0 0 0.0.0.0:4827 0.0.0.0:* 9174/(squid) udp 0 0 0.0.0.0:5353 0.0.0.0:* 6901/avahi-daemon: udp 0 0 0.0.0.0:631 0.0.0.0:* 7515/cupsd udp 0 0 0.0.0.0:123 0.0.0.0:* 7699/ntpd udp6 0 0 :::15007 :::* 8949/python udp6 0 0 :::5353 :::* 6901/avahi-daemon: udp6 0 0 :::38250 :::* 6901/avahi-daemon: udp6 0 0 fe80::20e:2eff:fef2:123 :::* 7699/ntpd udp6 0 0 ::1:123 :::* 7699/ntpd udp6 0 0 :::123 :::* 7699/ntpd

C’est NFS ? (rpc.). Un port par défaut (2049) et deux ports aléatoires, c’est ça ?
Comment empêcher que les services rpc. écoutent sur cette interface ?

Pourquoi est-ce que j’ai des programmes qui “LISTEN” sur des adresses IPV6 ?

Pour SAMBA, j’ai bien précisé dans /etc/samba/smb.conf[global] interfaces = lo eth1 Mais il a l’air d’écouter quand même (en IPV6) sur 0.0.0.0 ?

Pour les udp et udp6 ils “n’écoutent” pas donc pas de soucis, c’est bien ça ?

#5

Les rpc sont les «remote procédure call». En gros, si un client veut faire appel à une procédure, il s’adresse au «portmap» qui lui fournit le port de la procédure appelée.

Sinon, la plupart des rpc utilise les fichiers /etc/hosts.allow, etc pour la sécurité…

#6

[quote=“fran.b”]Les rpc sont les «remote procédure call». En gros, si un client veut faire appel à une procédure, il s’adresse au «portmap» qui lui fournit le port de la procédure appelée.

Sinon, la plupart des rpc utilise les fichiers /etc/hosts.allow, etc pour la sécurité…[/quote]

Merci pour cette réponse rapide.
Donc, avec un /etc/hosts.allow comme ceci[code]# permanent whitelist addresses - these should always be allowed access

ALL: 127.0.0.1 : allow
ALL: 192.168.1. : allow

/etc/hosts.allow

sshd: 127.0.0.0/255.255.255.0
sshd: 192.168.0.0/255.255.255.0
[/code]Je suis bon, et aucune importance que les rpc écoutent sur mon interface connectée à Internet ?

Et sans vouloir abuser… quid de ces lignes ?tcp6 0 0 ::1:139 :::* LISTEN 7649/smbd tcp6 0 0 fe80::20e:2eff:fef2:139 :::* LISTEN 7649/smbd tcp6 0 0 :::113 :::* LISTEN 7694/xinetd tcp6 0 0 ::1:445 :::* LISTEN 7649/smbd tcp6 0 0 fe80::20e:2eff:fef2:445 :::* LISTEN 7649/smbd tcp6 0 0 :::15007 :::* LISTEN 8949/python

#7

RTFM… (Read The F… Manual)

Bon en creusant, j’ai trouvé que ces lignes n’étaient évidemment pas génantes… tcp6 0 0 ::1:139 :::* LISTEN 7649/smbd tcp6 0 0 fe80::20e:2eff:fef2:139 :::* LISTEN 7649/smbd tcp6 0 0 ::1:445 :::* LISTEN 7649/smbd tcp6 0 0 fe80::20e:2eff:fef2:445 :::* LISTEN 7649/smbd Puisqu’elles écoutent sur mes interfaces internes !

Par contre celles-ci plus…

tcp6 0 0 :::113 :::* LISTEN 7694/xinetd tcp6 0 0 :::15007 :::* LISTEN 8949/python
Il me reste donc deux ports ouverts…

15007, c’est moi (P2P) donc c’est ok !
mais pour xinetd et le port 113 ?

#8

Je termine mon monologue…

J’ai compris que xinetd servait à piloter l’accès à un ou plusieurs services réseaux… (comme inetd).

Mais je suis étonné qu’il écoute sur l’interface “externe”, en IPV6 en plus… et non pas en IPV4 ! Cela ne m’est donc à priori d’aucune utilité !
J’ai joué un peu à l’apprenti sorcier… j’ai commenté ces lignes dans /etc/inetd.conf#:INFO: Info services #ident stream tcp wait identd /usr/sbin/identd identdService appelé par xinetd, je ne sais pas à quoi il sert, ni si ce service est indispensable… Mais je n’ai plus d’écoute sur l’interface extérieure, le port 113 est maintenant fermé ! Je verrais bien si j’ai des dis-fonctionnements…

Il me reste beaucoup à comprendre, je reste un peu sur ma faim. Je ne sais pas si mon hosts.allow est suffisant pour me protéger ?

Merci pour l’aide en tout cas, et joyeux 14 juillet (j’avais oublié ce matin, mais je suis si loin des flonflons dans mon île ! :smt005

#9

identd est un service permettant de connaitre une personne: Si tu te connectes sur une machine donnée sur IRC ou autre, le identd sur ta machine permet à IRC de récupérer qui tu es au lieu d’afficher ton login et le nom ta machine.

#10

[quote=“http://www.linux-france.org”]Le service ident (anciennement appelé auth, en écoute sur le port 113) est du même genre que le service finger. Il fournit des informations sur les détenteurs de connexions sur le système.
Il convient de le supprimer, s’il n’a aucune utilité.

Sous UNIX, pour désactiver le service ident, ajoutez un dièse (#) pour commenter la ligne concernant ce service dans le fichier /etc/inetd.conf.

:INFO : Info services

#ident stream tcp wait identd /usr/sbin/identd identd

[/quote]Donc j’ai bien fait !

#11

[quote=“lol”]Donc j’ai bien fait ![/quote]si tu n’en as pas besoin, sinon non.

#12

[quote=“fran.b”]si tu n’en as pas besoin, sinon non.[/quote]Je pense ne pas en avoir besoin. Mon serveur n’est pas ouvert sur Internet, il offre principalement un proxy transparent à un réseau local, un webmail interne, un site interne et quelques services…

Je pourrais très bien m’en passer, mais j’adore ça… :smiley: :smiley: :smiley:

#13

Quelques informations supplémentaires…

Concernant IDENT/AUTH, la fiabilité de cette méthode d’identification repose sur la confiance de l’administrateur du service qui fait la requête IDENT envers celui de la machine cliente qui y répond. S’il n’y a aucun lien entre les deux, c’est zéro car le démon IDENT du client peut répondre n’importe quoi.

tcp : port TCP ouvert en IPv4
udp : port UDP ouvert en IPv4
tcp6 : port TCP ouvert en IPv6
udp6 : port UDP ouvert en IPv6

0.0.0.0 = adresse IPv4 indéfinie, n’importe quelle adresse IPv4 locale
:: = adresse IPv6 indéfinie, n’importe quelle adresse IPv6 locale (et par défaut n’importe quelle adresse IPv4 aussi, voir plus bas)
127...* = adresses de loopback IPv4, réservées aux communications IPv4 entre processus locaux
::1 = adresse de loopback IPv6, réservée aux communications IPv6 entre processus locaux
fe80:* = adresse IPv6 “link local” valide seulement sur le lien, ne peut traverser les routeurs

Les sockets IPv6 en écoute sur :: ont une particularité : par défaut, elles acceptent aussi les communications sur n’importe quelle adresse IPv4 locale. C’est donc comme s’il y avait deux sockets sur :: et 0.0.0.0. Comme ce sont quand même des sockets IPv6, les adresses IPv4 sont représentées sous forme IPv6 “mappée” ::ffff:. netstat les montre sous cette forme. Ce comportement a pour but de faciliter la transition IPv4 vers IPv6 : ainsi une application programmée pour IPv6 pourra fonctionner aussi en IPv4. Comme ce comportement peut avoir des inconvénients dans certains cas, il est possible de le désactiver soit par socket avec l’option IPV6_V6ONLY, soit globalement avec le paramètre du noyau net.ipv6.bindv6only.

Il ne faut pas confondre interface et adresse. La nuance est importante car Linux applique le “weak host model” dans lequel n’importe quelle adresse locale est accessible par n’importe quelle interface locale, contrairement au “strong host model” dans lequel une adresse locale n’est accessible que par l’interface sur laquelle elle est configurée. L’exception au “week model” est les adresses de loopback 127.0.0.0/8 et ::1 qui ne sont accessibles que par l’interface de loopback lo. On peut utiliser l’option SO_BINDTODEVICE pour lier une socket non TCP à une interface particulière et dans ce cas la socket ne recevra que les datagrammes reçus par cette interface, mais netstat ne l’indique pas. Dans les autres cas, il faut filtrer avec iptables en IPv4 ou ip6tables en IPv6.

[quote]modifiez /etc/default/portmap', décommentez la ligne suivante :#OPTIONS="-i 127.0.0.1"’ et redémarrez le portmapper.
Mais en faisant ça je n’empêche pas les machines de mon réseau local à se connecter au service “nfs” ?[/quote]
Il y a des chances, car NFS dépend du portmapper RPC.

Ecouter en IPv6 sur 0.0.0.0 qui est une adresse IPv4 ? Aucune chance.

La colonne “Etat” de netstat indique l’état de connexion des sockets. TCP est un protocole orienté connexion qui possède des états (LISTEN, SYN-SENT, ESTABLISHED…), alors qu’UDP est un protocole orienté datagramme qui n’a pas d’état de connexion. L’absence de mention LISTEN pour les ports UDP ne signifie donc pas qu’ils ne sont pas en écoute.

#14

Bonjour Pascal,
Merci pour ces précisions, c’est gentil d’avoir pris le temps de regarder mes errances…

Il va me falloir du temps pour étudier et comprendre tous les points soulevés dans ces quelques messages. Les informations contenues dans ta réponse m’éclairent beaucoup, et faciliterons beaucoup mes recherches. Je sais au moins par ou commencer. j’avais effectivement déjà lu un passage sur le “weak host model”, mais ce n’était pas clair, maintenant ça l’est !

J’ai un peu tout mélangé…
Mais les réponses données m’ont permis de remettre de l’ordre dans mes idées.

Je vous remercie tous les deux pour votre patience ! :wink:

#15

Sympa ce post Pascal.
Si je puis me permettre, j’ai une question

[quote]Ce comportement a pour but de faciliter la transition IPv4 vers IPv6 : ainsi une application programmée pour IPv6 pourra fonctionner aussi en IPv4. Comme ce comportement peut avoir des inconvénients dans certains cas, il est possible de le désactiver soit par socket avec l’option IPV6_V6ONLY, soit globalement avec le paramètre du noyau net.ipv6.bindv6only.
[/quote]
J’ai desactivé tout bonnement le support de l’ipv6 dans mon noyau. Je ne m’en sert pas. J’espere que ma debian entière ne s’en sert pas, cad j’espere que ca ne crée pas d’effet de bord.
Et a partir de ce moment là, certains programmes ont céssés de fonctionner (principalement qbittorrent je crois, que j’ai donc enlevé).
Est-ce que c’est explicable? Je crois que c’etait aussi au niveau du bind que ca posait problème.
Je suis curieux :slightly_smiling:

#16

Il y a deux autres possibilités plus simple (non ?) :
/etc/modprobe.d/blacklist + blacklist ipv6
/etc/modprobe.d/aliases alias net-pf-10 off + alias ipv6 off
Je crois que ça pose aussi des problèmes à mplayer pour lire des flux ?

J’ai cogité cette nuit au sujet de NFS et Samba…
Je me demande si NFS n’est finalement pas plus “vulnérable” que Samba, et si le choix de Samba au lieu de NFS même pour un réseau composé principalement de machines sous Linux n’est pas plus judicieux ?

Question subsidiaire, quelqu’un a-t-il déjà utilisé OpenAFS ?

#17

Salut
Pour info (ça peut servir a d’autre)
Pour iptable j’ai trouvé un (en fait deux)petit script sympa sur le site
http://formation-debian.via.ecp.fr/firewall.html
je ne pense pas que pour toi ce ne soit pas d’un grand intérêt mais pour moi qui est encore un jeune padawan c’est parfait et facile à modifier pour le mettre a ma sauce
le script iptables-start
http://formation-debian.via.ecp.fr/fichiers-config/iptables-start
le script iptables-stop
http://formation-debian.via.ecp.fr/fichiers-config/iptables-stop

pour donner un avis sur samba et nfs , là je suis "out"
mais + 1 pour samba on sais jamais tu aura peut être un client “WIN” un jour, ou temporairement pour X raisons

#18

Salut,

Merci pour les liens, très intéressant !
J’utilise shorewall au dessus d’iptables. A l’époque j’avais trouvé un bon tuto qui me facilitait la vie et qui correspondait exactement à mes besoins, notamment pour le proxy transparent que je n’avais pas été foutu de mettre en place avec iptables… Je suis resté avec cette config depuis ! Mais si je souhaite aller plus loin il va bien falloir que je m’y mette…

Ce que je sais de NFS, c’est qu’il est plus rapide que Samba et simple à utiliser (avis de simple utilisateur). C’est tout… (pas bien lourd hein ? :laughing: ).
NFS me semble trop “ouvert” c’est pourquoi je me pose des questions sur la sécurité… Avec Samba tu peux spécifier une interface à écouter, je n’ai pas trouvé la même chose avec NFS.

Je ne suis pas plus calé que toi…

#19

Il y a deux autres possibilités plus simple (non ?) :
/etc/modprobe.d/blacklist + blacklist ipv6
[/quote]
Merci pour ta réponse. En fait vu que j’ai recompilé moi-meme, c’etait encore plus simple de ne pas l’inclure plutot que d’empecher de le charger.
Et de toutes facons,j’ai aussi desactivé les modules.

#20

Salut,
Pour être franc, j’avais bien vu, mais comme j’ai mis ce sujet dans mes favoris (vu que nous n’avons pas de wiki…) j’ai simplement complété l’info, plus pour moi que pour toi…

Pas fâché ? :wink: :laughing:

#21

[quote=“ignatioza”]J’ai desactivé tout bonnement le support de l’ipv6 dans mon noyau. Je ne m’en sert pas. J’espere que ma debian entière ne s’en sert pas, cad j’espere que ca ne crée pas d’effet de bord.
Et a partir de ce moment là, certains programmes ont céssés de fonctionner (principalement qbittorrent je crois, que j’ai donc enlevé).
Est-ce que c’est explicable? Je crois que c’etait aussi au niveau du bind que ca posait problème.[/quote]
Il y a bien longtemps que je n’ai plus eu d’installation de GNU/Linux sans IPv6. En général les problèmes arrivent plutôt dans l’autre sens, quand la machine a IPv6 activé mais un autre élément de la chaîne réseau (souvent le proxy DNS de certains routeur) n’est pas compatible. Néanmoins si un logiciel a été programmé pour n’utiliser que des sockets IPv6 même pour les comunications en IPv4, il se peut qu’il ne fonctionne pas si IPv6 est désactivé dans le noyau. Tu parles de la fonction bind() pour lier une socket à une adresse locale ou du serveur DNS BIND ? A ma connaissance BIND devrait fonctionner sans IPv6, en supprimant tout ce qui est relatif à IPv6 dans named.conf et ses fichiers inclus.

#22

Merci.
Oui je parlait bien de bind() à la créeation d’une socket en ecoute.
Et initialement oui j’ai enlevé le support ipv6 car j’avais des problèmes avec le DNS record AAAA. En fait j’ai insulté les providers mais le coup du routeur NAT qui gere mal le DNS ipv6, j’avais pas pensé à ca.

/fin de la parenthèse

)

#23

Si le provider est Orange et le routeur une Livebox Sagem avec un firmware dont le proxy DNS est notoirement buggé et pas seulement avec le type AAAA, alors tu es fondé à insulter le FAI. Une alternative à désactiver IPv6 consiste à utiliser directement les DNS du FAI à la place du proxy de la box.