[ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

jmbif · Le 16/02/2014, à 10:23

Salut Pascal34,...

Selon moi, le filtrage par adresse mac est un plus,....il n'est pas suffisant à lui seul .....et, oui, je suis au courant des possibilités d'usurper
une adresse mac.

Mais, d'ailleurs, tu as dis toi même que c'était un bon moyen dans le post 35.

La sécurité informatique restera toujours un ensemble de régles qui doivent être "des automatismes" de la part de l'utilisateur et
malheureusement, beaucoup ne se basent que sur leur seules protections logicielles en se croyant à l'abri.
Un comportement "responsable" est nécessaire lorsque l'on utilise l'outil informatique.

Dernière modification par jmbif (Le 16/02/2014, à 10:23)

tiramiseb · Le 16/02/2014, à 10:37

bruno a écrit :

Les ports ne sont pas « fermés », ils sont « masqués ».

Disons que pour rester simple, pour ma part j'ai évité de parler de la différence fermé/masqué
J'imagine que nam1962 a fait pareil

pires57 a écrit :

UFW [...] n'offre pas la totalité des fonctionnalités que peut m'offrir Iptables.

Oui, c'est sûr que Uncomplicated FireWall est moins complet qu'iptables.
Mais il permet tout ce qui est nécessaire dans la majorité des cas (serveur seul, poste de travail, etc).

Et si tu as besoin d'aller au-delà, plutôt que de te tourner vers un truc bas niveau comme iptables, pourquoi ne pas plutôt rester en haut niveau et utiliser un bon logiciel complet de gestion de pare-feu ? Je pense bien sûr à Shorewall...

SangokuSS · Le 16/02/2014, à 10:39

jmbif a écrit :

Salut Pascal34,...
Selon moi, le filtrage par adresse mac est un plus,....il n'est pas suffisant à lui seul .....et, oui, je suis au courant des possibilités d'usurper
une adresse mac.
Mais, d'ailleurs, tu as dis toi même que c'était un bon moyen dans le post 35.
La sécurité informatique restera toujours un ensemble de régles qui doivent être "des automatismes" de la part de l'utilisateur et
malheureusement, beaucoup ne se basent que sur leur seules protections logicielles en se croyant à l'abri.
Un comportement "responsable" est nécessaire lorsque l'on utilise l'outil informatique.

Tout à fait d'accord, le filtrage des adresses mac est un plus, mais il n'est pas suffisant : il faut l'associer à une clé bien complexe, à de l'ip fixe (ou au moins de la réservation d'adresse...)... etc

Là où je trouve que la discussion devient intéressante (et fait le lien avec les échanges précédent sur iptables...etc) c'est lorsqu'on considère qu'une intrusion sur le réseau domestique (donc derrière la sacro sainte « box ») devient possible... Car dans ce cas, mieux vaut avoir configuré correctement ses machines persos ! (sous-entendu, mieux vaut qu'elles soient bien "fermées" !)
Bref, personnellement, je maintiens qu'il est préférable, lorsqu'on met en place un réseau domestique, d'envisager les dégâts possibles d'une intrusion (même si celle-ci paraît "improbable" pour certains).Autrement dit, on durcit au maximum, et on ouvre en fonction des besoins.

Par contre, je reconnais bien volontier qu'agir ainsi n'est pas des plus confortable pour ceux qui partagent votre réseau, pour la vigilance que cela demande... etc

Dernière modification par SangokuSS (Le 16/02/2014, à 10:42)

nam1962 · Le 16/02/2014, à 11:03

tiramiseb a écrit :

bruno a écrit :
Les ports ne sont pas « fermés », ils sont « masqués ».
Disons que pour rester simple, pour ma part j'ai évité de parler de la différence fermé/masqué
J'imagine que nam1962 a fait pareil
(...).

Quand j'utilise Qbittorrent, pendant un deux jours à suivre, je trouve des trucs comme çà dans mon dmesg

 [   72.667160] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=213.136.120.39 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=112 ID=7193 PROTO=UDP SPT=26080 DPT=55554 LEN=38 
[   75.924154] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=41.82.150.196 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=114 ID=29614 PROTO=UDP SPT=52954 DPT=55554 LEN=38 
[   78.855283] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=213.136.120.39 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=112 ID=7624 PROTO=UDP SPT=26080 DPT=55554 LEN=38 
[   79.378038] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=41.82.150.196 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=114 ID=29617 PROTO=UDP SPT=52954 DPT=55554 LEN=38 
[   80.774034] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=80.28.227.222 DST=192.168.0.19 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=7026 PROTO=UDP SPT=14199 DPT=55554 LEN=28 
[   83.404156] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=80.28.227.222 DST=192.168.0.19 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=7306 PROTO=UDP SPT=14199 DPT=55554 LEN=28 
[   85.430898] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=41.82.150.196 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=114 ID=29619 PROTO=UDP SPT=52954 DPT=55554 LEN=38 
[   86.364905] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=80.28.227.222 DST=192.168.0.19 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=7639 PROTO=UDP SPT=14199 DPT=55554 LEN=28 
[   88.626531] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=84.10.198.160 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=110 ID=21551 PROTO=UDP SPT=42918 DPT=55554 LEN=38 
[  103.358044] [UFW BLOCK] IN=wlan0 OUT= MAC=f8:d1:11:0c:e3:11:00:24:d4:ab:8f:19:08:00 SRC=80.11.56.9 DST=192.168.0.19 LEN=58 TOS=0x00 PREC=0x00 TTL=116 ID=29031 PROTO=UDP SPT=30900 DPT=55554 LEN=38

C'est du masquage ou du bloquage ?

Dernière modification par nam1962 (Le 16/02/2014, à 11:03)

tiramiseb · Le 16/02/2014, à 11:13

C'est du masquage ou du bloquage ?

Attention, on n'oppose pas "masquage" et "blocage", on oppose "masqué" et "fermé".

Un port dit masqué, c'est un port en DROP : la requête ne reçoit aucune réponse, l'ordinateur distant est confronté à un timeout.
Un port dit fermé, c'est un port en REJECT : le pare-feu répond en ICMP à l'ordinateur distant que le port demandé est fermé.

La politique de "blocage" d'UFW, c'est du DROP, donc du "masquage".

Dernière modification par tiramiseb (Le 16/02/2014, à 11:15)

pires57 · Le 16/02/2014, à 11:22

J'ai effectivement tester Shorewall (enfin si on peut dire tester, j'ai du passer une 15 aine d'heure dessus) mais j'ai pas trop adhéré bien que ce soit effectivement bien plus simple qu'Iptables au niveau de la configuration

Dernière modification par pires57 (Le 16/02/2014, à 11:23)

tiramiseb · Le 16/02/2014, à 11:29

j'ai pas trop adhéré

C'est bien c'que j'dis : 'spèce de vieux barbu !

Pour ma part je l'ai utilisé à grande échelle (enfin.. allez... disons moyenne, l'échelle, plutôt) pendant plusieurs années... Et c'est d'la bombe bébé !

Dernière modification par tiramiseb (Le 16/02/2014, à 11:29)

bruno · Le 16/02/2014, à 11:29

Je vais donc préciser, mais il est préférable de lire les docs officielles qui seront bien plus fiables et plus justes que moi

Si le règle est DROP, la machine ne répond pas à une tentative de connexion sur un port xxx. La machine qui a tenté de se connecter reçoit un 'time out'. Le port apparaît comme 'masqué' (ou stealth) de l'extérieur (ce qui est exactement la même chose en l’absence de pare-feu et de service en écoute sur le port xxx).

Si la règle est REJECT, la machine répond à une tentative de connexion sur un port xxx par un message d’erreur. Le port apparaît comme 'fermé' (CLOSED) de l'extérieur. Sauf dans de rares cas il est préférable de ne pas se servir de REJECT.

J'en profite pour dire qu'AMHA, un pare-feu est totalement inutile sur une machine dont on maîtrise l’administration et qui ne fait tourner aucun service accessible depuis l’extérieur.
Le pare-feu est utile lorsque l'on a des services en écoute auxquels on veut restreindre l'accès. Par exemple, restreindre un accès SSH à certaines IP.
Il est utile lorsque l'on veut protéger un réseau local où l'on a peu de confiance concernant les systèmes utilisés (Windows ) et les utilisateurs (il faut dans ce cas filtrer les connexions entrantes et sortantes)

UFW me paraît assez léger pour ce genre d'usage (et totalement inutile dès que cela se complique un peu : plusieurs interfaces réseau par exemple) et comme tiramiseb je préfère nettement shorewall si on ne veut pas s'attaquer directement aux règles iptable.

Et enfin, avant de se lancer dans la configuration d'un pare-feu, il est souhaitable d'aller dé-commenter quelques directives dans le fichier /etc/sysctl.conf.

tiramiseb · Le 16/02/2014, à 11:31

J'en profite pour dire qu'AMHA, un pare-feu est totalement inutile sur une machine dont on maîtrise l’administration et qui ne fait tourner aucun service accessible depuis l’extérieur.

Toutafé, toutafé !

Le pare-feu est utile lorsque l'on a des services en écoute auxquels on veut restreindre l'accès. Par exemple, restreindre un accès SSH à certaines IP.

Ou alors lorsqu'on utilise des services qui, malheureusement, ne permettent pas de restreindre les adresses en écoute...
C'est là qu'UFW est assez pratique.
(d'ailleurs c'est dans ce cadre-là que je l'utilise sur mon serveur pro)

Et enfin, avant de se lancer dans la configuration d'un pare-feu, il est souhaitable d'aller dé-commenter quelques directives dans le fichier /etc/sysctl.conf.

Ah bon ? J'vois pas...

bruno · Le 16/02/2014, à 11:40

Pour le fichier /etc/sysctl.conf c'est auto-documenté, donc assez facile à comprendre. Je copie pour information : (par défaut dans Ubuntu toutes ces lignes sont commentées)

###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

Dernière modification par bruno (Le 16/02/2014, à 11:41)

nam1962 · Le 16/02/2014, à 11:41

Quand je lis : [UFW BLOCK] (...) SRC=84.10.198.160 DST=192.168.0.19 ça veut bien dire que UFW a bloqué une tentative connection de l'ip 84.10.198.160 vers ma machine 192.168.0.19 (qui se trouve derrière ma freebox), non ? (accessoirement l'ip en question est un charmant polonais... que je ne connais ni d'Eve ni d'Adam).
Ça ne parle pas de masquage, mais de bloquage là, ou je me gourre ?

Dernière modification par nam1962 (Le 16/02/2014, à 11:43)

tiramiseb · Le 16/02/2014, à 11:54

Pour le fichier /etc/sysctl.conf c'est auto-documenté, donc assez facile à comprendre.

Je ne demande pas de la documentation sur sysctl, c'est bon je connais, ça fait 15 ans que je pratique... mais je ne vois pas pourquoi il serait crucial de décommenter ces lignes avant d'utiliser un pare-feu...

Ça ne parle pas de masquage, mais de bloquage là, ou je me gourre ?

Oui, et ?
Je répète la dernière phrase de mon message #55 : La politique de "blocage" d'UFW, c'est du DROP, donc du "masquage".

Que le vocabulaire soit un peu différent ça te gêne ? D'ailleurs utiliser le verbe "bloquer" (to block) pour un port masqué, ça me semble assez cohérent : il y a une tentative d'accès sur un port masqué, la tentative est bloquée et aucune réponse n'est donnée...
Je ne sais pas ce que met UFW dans les logs quand un paquet est confronté à un "REJECT" au lieu d'un "DROP".

(ajoutons aussi que, dans la syntaxe de la commande ufw, on utilise "deny" pour le masquage/drop et "reject" pour la fermeture/reject...)

Dernière modification par tiramiseb (Le 16/02/2014, à 11:55)

SangokuSS · Le 16/02/2014, à 12:06

bruno a écrit :

J'en profite pour dire qu'AMHA, un pare-feu est totalement inutile sur une machine dont on maîtrise l’administration et qui ne fait tourner aucun service accessible depuis l’extérieur.
Le pare-feu est utile lorsque l'on a des services en écoute auxquels on veut restreindre l'accès. Par exemple, restreindre un accès SSH à certaines IP.
Il est utile lorsque l'on veut protéger un réseau local où l'on a peu de confiance concernant les systèmes utilisés (Windows ) et les utilisateurs (il faut dans ce cas filtrer les connexions entrantes et sortantes)

200% d'accord avec toi !
Et justement, la question se pose réellement dans le cadre d'un réseau domestique. Prenons l'exemple d'une famille avec plusieurs enfants, dont certains en âge de bidouiller... etc, qui configurent des trucs, machins, bidules pour jouer, partager, échanger... etc (quelques soient les appareils connectés : pc M$, smartphones...), qui refusent de ne pas être "admin" de leurs machines... etc
Peut-on considérer un tel réseau comme fiable ? Selon moi, non.

La question serait différente si nous étions sûr d'avoir des utilisateurs "de confiance" (bref, si nous étions seuls ! ).

Dernière modification par SangokuSS (Le 16/02/2014, à 12:08)

bruno · Le 16/02/2014, à 12:19

tiramiseb a écrit :

Pour le fichier /etc/sysctl.conf c'est auto-documenté, donc assez facile à comprendre.
Je ne demande pas de la documentation sur sysctl, c'est bon je connais, ça fait 15 ans que je pratique... mais je ne vois pas pourquoi il serait crucial de décommenter ces lignes avant d'utiliser un pare-feu...

Merci de ne pas déformer mes propos. J'ai dit que c'était souhaitable, pas crucial. Puisque tu pratiques depuis 15 ans tu sais qu'il y a de nombreuses options simples dans ce fichier qui permettent de bloquer (ou du moins limiter) certaines attaques (IPspoofing, SYN flood, etc.). Ce sont des mesures de protection de base à établir avant de chercher à configurer un pare-feu.

nam1962 · Le 16/02/2014, à 12:21

Admettons... Mais que serait il arrivé au polonais de mon post #61 si ufw n'avait pas été activé ?
Par ailleurs, comment a t'il trouvé ma machine derrière ma box celui là ?
(Utiliser un logiciel torrent est assez banal dans un foyer par ailleurs, on a accès au net, on en profite )

tiramiseb · Le 16/02/2014, à 13:25

Mais que serait il arrivé au polonais de mon post #61 si ufw n'avait pas été activé ?

Il aurait pu accéder au port UDP 55554 en question.
Si tu as quelque chose en écoute sur le port UDP 55554, alors ce "quelque chose" aurait reçu ses paquets et aurait pu éventuellement lui répondre.
Si tu n'as rien en écoute sur le port UDP 55554, alors il aurait eu un message de "reject" (oui, car un port qui n'est pas en écoute est fermé, donc "reject").

Par ailleurs, comment a t'il trouvé ma machine derrière ma box celui là ?

Il n'a pas "trouvé" ta machine derrière ta box. D'ailleurs il n'a pas connaissance de ton adresse privée. C'est ta box qui a renvoyé ses requêtes vers ta machine.

Tu parles d'« utiliser un logiciel torrent », donc j'imagine que tu as vérifié et que sur le port 55554 c'est « un logiciel torrent ». Ce polonais essayait donc simplement de se connecter sur ton « logiciel torrent ». Manuellement voire automatiquement : le protocole bittorrent étant en pair-à-pair, j'imagine qu'il y a des raisons valables pour qu'un « logiciel torrent » chez ce polonais veuille se connecter chez toi...

Utiliser un logiciel torrent est assez banal dans un foyer

Ah bon ?
On ne doit pas avoir la même définition de la banalité...

nam1962 · Le 16/02/2014, à 13:42

Évidemment j'ai vérifié, c'est moi qui ai renseigné le port dans Qubittorent
Sinon, sur la quarantaine d'ordi que j'ai installés en Xub, 90% venaient du monde W$ et avaient tous une mule ou autre avant que je ne les migre...
Ce sont tous des utilisateurs lambda.
Merci pour tes éclaircissement, grosso c'est comme ça que je visualisais le truc, j'ai simplement remarqué que les ip qui tentaient ces connexions dans les jours suivant mon utilisation avaient toutes des origines repérables (Corée, Taiwan, Chine, Russie, Nigéria, Sénégal, Pologne... Mais jamais vu d'US ou Europe de l'ouest par exemple)

compte supprimé · Le 16/02/2014, à 15:21

jmbif a écrit :

Salut Pascal34,...
Selon moi, le filtrage par adresse mac est un plus,....il n'est pas suffisant à lui seul .....et, oui, je suis au courant des possibilités d'usurper
une adresse mac.
Mais, d'ailleurs, tu as dis toi même que c'était un bon moyen dans le post 35.
La sécurité informatique restera toujours un ensemble de régles qui doivent être "des automatismes" de la part de l'utilisateur et
malheureusement, beaucoup ne se basent que sur leur seules protections logicielles en se croyant à l'abri.
Un comportement "responsable" est nécessaire lorsque l'on utilise l'outil informatique.

Salut jmbif, j'ai effectivement fait allusion à ces bonnes coutumes de filtrage d'adresse mac, mais c'était au post 34, j'ai enlevé mon commentaire à ce sujet après avoir lu toutes les failles que cela pouvait générer, attaque par MAC Spoofing, facilité de trouver les adresses MAC des périphériques réseaux en Wifi etc...

Merci de m'avoir rappelé que j'avais écris clea, j'ai pu rectifier mon erreur sur ce post 34, mais seulement aux vues des dernières infos que j'ai trouvé sur la fiabilité d'utilisation du filtrage par adresse MAC, bonne aprem...

Dernière modification par -pascal34- (Le 16/02/2014, à 16:02)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 16/02/2014, à 10:23

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#52 Le 16/02/2014, à 10:37

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#53 Le 16/02/2014, à 10:39

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#54 Le 16/02/2014, à 11:03

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#55 Le 16/02/2014, à 11:13

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#56 Le 16/02/2014, à 11:22

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#57 Le 16/02/2014, à 11:29

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#58 Le 16/02/2014, à 11:29

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#59 Le 16/02/2014, à 11:31

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#60 Le 16/02/2014, à 11:40

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#61 Le 16/02/2014, à 11:41

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#62 Le 16/02/2014, à 11:54

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#63 Le 16/02/2014, à 12:06

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#64 Le 16/02/2014, à 12:19

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#65 Le 16/02/2014, à 12:21

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#66 Le 16/02/2014, à 13:25

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#67 Le 16/02/2014, à 13:42

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

#68 Le 16/02/2014, à 15:21

Re : [ info ] Qu'a représenté pour vous la sécurité sur Ubuntu en 2013?

Pied de page des forums