[Linux-bruxelles] OVH & faille de securite DNS ?

[Laurent Léonard]

Le jeudi 31 juillet 2008 à 02:42, Didier Misson a écrit :
> Laurent Léonard a écrit :
> > Le mercredi 30 juillet 2008 à 23:38, Didier Misson a écrit :
> >> Il me reste ceci :
> >>
> >> Not shown: 1706 closed ports
> >> PORT     STATE    SERVICE
> >> 22/tcp   open     ssh
> >> 25/tcp   open     smtp
> >> 80/tcp   open     http
> >> 443/tcp  open     https
> >> 445/tcp  filtered microsoft-ds
> >> 873/tcp  open     rsync
> >> 993/tcp  open     imaps
> >> 6667/tcp filtered irc
> >>
> >> Mais la commande que tu donnes ne me montre pas qui utilise les ports
> >> 445 et 6667.
> >>
> >> Filtered... ça veut dire ?
> >
> > Que les paquets que nmap a tenté d'envoyer sur ces ports ont été droppés
> > par un firewall.
> >
> >> ça peut être OVH qui bloque lui-même ?
> >
> > Par un firewall local à la machine (mais j'imagine que tu n'en as pas ou
> > que tu l'as arrêté pour le test), par OVH ou par ton FAI... Voici les
> > résultats d'un nmap sur un de mes serveurs chez OVH une fois le firewall
> > local arrêté (un Superplan 2008) depuis EDPnet :
> > PORT      STATE    SERVICE
> > 21/tcp    open     ftp
> > 25/tcp    open     smtp
> > 53/tcp    open     domain
> > 80/tcp    open     http
> > 110/tcp   open     pop3
> > 111/tcp   open     rpcbind
> > 143/tcp   open     imap
> > 443/tcp   open     https
> > 993/tcp   open     imaps
> > 995/tcp   open     pop3s
> > 1720/tcp  filtered H.323/Q.931
> > 2000/tcp  open     callbook
> > 6667/tcp  filtered irc
> > 10000/tcp open     snet-sensor-mgmt
> >
> > Depuis Telenet :
> > PORT      STATE    SERVICE
> > 21/tcp    open     ftp
> > 25/tcp    open     smtp
> > 53/tcp    open     domain
> > 80/tcp    open     http
> > 110/tcp   open     pop3
> > 111/tcp   open     rpcbind
> > 135/tcp   filtered msrpc
> > 137/tcp   filtered netbios-ns
> > 138/tcp   filtered netbios-dgm
> > 139/tcp   filtered netbios-ssn
> > 143/tcp   open     imap
> > 443/tcp   open     https
> > 445/tcp   filtered microsoft-ds
> > 993/tcp   open     imaps
> > 995/tcp   open     pop3s
> > 2000/tcp  open     callbook
> > 4444/tcp  filtered krb524
> > 6667/tcp  filtered irc
> > 10000/tcp open     snet-sensor-mgmt
> > 12345/tcp filtered NetBus
> > 12346/tcp filtered NetBus
> > 27374/tcp filtered subseven
> > 31337/tcp filtered Elite
>
> tu as plein de services dont je n'ai même jamais entendu parler !
> ;-)

Vu que j'ai désactivé le firewall local pour faire les scans, les ports 
filtered sont en fait bloqués par le provider, on peut clairement voir que 
Telenet est vachement plus restrictif que EDPnet... Même avec un abonnement 
pro à plus de 100€ HT par mois et IP fixe, le port 53 est toujours bloqué en 
entrée... Et quand on leur demande des explications, ils conseillent de 
passer en offre fibre... Enfin soit je m'écarte du sujet ! :)

Au passage ça me rappelle que je peux virer portmap (111 - rpcbind) vu que je 
n'utilise plus NFS, hopla... Sinon à part le port 2000 utilisé par Asterisk, 
les autre sont assez communs ! ;-)

>
> > Par simple déduction on peut donc dire que le port 445 est bloqué par ton
> > FAI, pour le 6667 par contre c'est soit ton FAI soit OVH...
> >
> >> car je pense qu'ils bloquent l' IRC justement.
> >
> > Probable donc.
> >
> >> Et j'ai vu dans le forum qu'ils allaient aussi bloquer certains ports
> >> Windows car ça posait trop de problèmes...
> >
> > On ne va pas s'en plaindre, avec tous les broadcasts de machines Windows
> > qu'on se ramasse dans les logs... De toute façon même si on est assez
> > débile que pour faire du partage de fichiers Windows au travers
> > d'Internet sans VPN,
>
> ah ? on fait pas ça ?
> c'est mal ? ou c'est dangereux ?
>
> :p
>
> lol
>
> > la
> > majorité des fournisseurs d'accès bloquent déjà ces ports...
>
> ok, merci pour les expli.
>
> Le port IRC, je suis sûr que c'est OVH qui le bloque (et qui peut le
> débloquer sur demande ou via le manager, mais par défaut il est fermé)

Bon à savoir. 

-- 
Laurent Léonard
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 197 octets
Desc: This is a digitally signed message part.
URL: </pipermail/linux-bruxelles/attachments/20080731/6cefbb93/attachment-0001.sig>