298 private links
En soit, l'idée est séduisante, mais j'ai pensé à la même chose que le commentateur nommé LeBret (http://bigbrowser.blog.lemonde.fr/2012/06/26/censure-pour-la-creation-dune-erreur-451-en-hommage-a-ray-bradbury/#comment-103251) :
« Fahrenheit 451 est une critique de la censure d’État.
Actuellement quand un État veut interdire certains sites, il filtre les réponses pour les remplacer par l’erreur 403.
Vous croyez vraiment que ces États vont utiliser une erreur 451 ?
Cela reviendrait de leur part à admettre qu’ils commettent une atteinte aux droits de l’Homme. »
Du coup, même si l'IETF l'accepte, et que c'est implémenté dans les navigateurs web et dans les serveurs web, ça m'étonnerait qu'on le voit.
RFC 2131
Il se peut que vous avez une machine hébergeant un service (prenons le cas simple du service Web), mais derrière un NAPT.
Du coup, vous ne pouvez pas accéder directement à votre service sur cette machine, sans devoir configurer ce NAPT.
Or, vous avez accès à un serveur distant, avec un service sshd.
"Super, ça va être facile", vous dites-vous -- en tout cas, c'est ce que je me suis dit -- car vous connaissez l'option -R, pour remote.
Et c'est là qu'on se rend compte qu'il suffit simplement de (re)lire le man (man 1 ssh) pour voir que déjà, il y a la réponse à nos question :
sous l'option -R [bind_address:]port:host:hostport
(Note : remarquez le contre sens qu'il y a entre la première phrase, et la troisième...) « By default, the listening socket on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)). »
Ainsi, je détaille un peu :
Dans le fichier de configuration du service sshd sur le serveur distant (souvent /etc/ssh/sshd_config), il faut activer l'option GatewayPorts avec la valeur "clientspecified" :
GatewayPorts clientspecified
Et sur la machine qui héberge le service derrière le NAPT, faites donc :
ssh user@server_distant -N -R *:<port_serveur>:localhost:<port_service_web>
serveur_distant représente le nom de domaine ou l'adresse IP du serveur qui n'est pas derrière le NAPT.
'*', c'est pour indiquer sur quel interface et/ou adresse écouter du serveur distant ; on peut donc spécifier 0.0.0.0 pour écouter sur toutes les adresses IPv4, [::] pour uniquement les adresses IPv6, "localhost" pour écouter uniquement sur l'interface "loopback" (contrairement à ce qui est indiqué, ce n'est pas par défaut avec GatewayPorts sur "clientspecified"), ou une adresse IP spécifique. (voire si possible, à une interface spécifique, mais je n'arrive plus à remettre la main sur la RFC en question)
<port_serveur>, c'est donc le port, toujours du serveur distant qui exécute le service sshd, sur lequel vous écouterez les connexions. Ainsi, ce n'est pas forcément le port du service web configuré dans le configuration du service.
<port_service_web>, le port du service derrière le NAPT. (donc, 80 pour un service web par défaut).
Ainsi, depuis votre navigateur web, vous n'aurez plus qu'à entrer l'URL suivante :
http://serveur_distant:port_serveur/
Conclusion :
Même si vous connaissez déjà une option dans un outil (comme -R dans ssh), (re)vérifier le man, il y a sûrement la solution.
PS : Vérifiez aussi dans /etc/ssh/sshd_config que l'option AllowTcpForwarding est sur "yes" (ce qui est par défaut)
Il faudrait que j'étudie ça pendant mon temps libre, ça peut sûrement me plaire. :-)
Si comme moi -- j'étais jeune et insouciant … -- vous ne comprenez pas pourquoi certaines de vos règles iptables ne fonctionnent pas (celles qui n'arrivent pas à bloquer certains maudits botnets qui continuent toujours et encore de vous spammer le port SSH), voici le rappel de la règle d'or d'iptables -- et d'autres outils utilisant les ACL mêmes -- et une commande en bash pour pouvoir ban simplement et facilement une adresse IP :
La règle d'or, c'est celle-ci :
les règles sont lues de haut en bas, et dès qu'une règle correspond à aux informations du paquets, iptables redirige vers la cible. POINT.
Alors, ce n'est pas forcément clair tout de suite, mais on va détailler avec un exemple :
Disons qu'à l'heure actuelle, vous aviez cette configuration :
iptables --list --numeric --verbose (ou -L -nv)
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5771 442K ACCEPT all -- lo 0.0.0.0/0 0.0.0.0/0
771K 99M ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DROP all -- 1.2.3.4 0.0.0.0/0
0 0 DROP all -- 8.8.8.8 0.0.0.0/0
69993 5147K fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
5765 483K ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
2107 118K ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22
432 458K ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:25
51 2604 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:80
0 0 REJECT all -- * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 5 packets, 820 bytes)
pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
pkts bytes target prot opt in out source destination
69914 5142K RETURN all -- 0.0.0.0/0 0.0.0.0/0
Je ne vais pas détailler ici les différentes règles, ce sont celles de base, plus fail2ban pour SSH.
Disons que vous souhaitez bloquer l'adresse IP 16.32.64.128 ; sur le web, on trouve :
iptables -A INPUT -s 16.32.64.128 -j DROP
Pour un résultat :
…
432 458K ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:25
51 2604 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:80
0 0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
0 0 DROP all -- 16.32.64.128 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
…
Or, problème : si la machine derrière l'IP 16.32.64.128 tente de se connecter au service web, sur le port 80, la 9ème règle répondra donc d'abord à la requête avec la 11ème (en dernière place donc), qui, cette dernière, spécifiait de bloquer complètement tout le trafic en provenance.
Conclusion, c'est l'échec.
Pour résoudre ça, il faut donc que notre nouvelle règle se retrouve avant d'autres règles qui joueraient en sa faveur.
Cette solution existe : c'est l'option --insert (-I, --insert chain [rulenum] rule-specification), à la place de --append (-A),
avec [rulenum] qui indique le numéro de la ligne où la nouvelle règle s'écrira avant (man 8 iptables explique bien mieux que moi).
Du coup, oubliez "iptables -A INPUT -s 16.32.64.128 -j DROP", et faites place à "iptables -I INPUT 3 -s 16.32.64.128 -j DROP"
avec "3", la position de la nouvelle règle, donc juste après "771K 99M ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED". (à adapter à vos besoins bien sûr !)
Ainsi, pour se simplifier la tâche, nous pouvons donc créer cette fonction en bash pour ainsi BAN simplement une adresse ip :
function ban() {
mode=${2:-"DROP"}
iptables --table filter --insert INPUT 3 --source $1 --jump $mode
}
et ça fonctionne comme ça :
ban ip_à_ban
Simple, non ?
Bien sûr, ceux qui l'ont remarqué peuvent spécifier une deuxième option (nommée mode), qui par défaut est DROP, comme REJECT, voire ACCEPT même ; ainsi, en spécifiant ACCEPT, vous pouvez de cette façon autoriser complètement une adresse IP, la vôtre par exemple, lorsque sur un serveur distant, vous voulez ne pas être bloqué par votre firewall ;) (tout le contraire de ban ^^')
C'est magique ! :D
Effectivement, ces compteurs électriques dits "intelligents" (c'est vraiment à la mode ce mot) offrent bien des avantages, sur la gestion du réseau électrique, ce qui dans le futur (et dès à présent) est vitale pour une consommation intelligente de l'énergie.
Mais voilà, comme expliqué en détails dans l'article, cet outil peut être un vrai mouchard ; et puis tout ce qui concerne des données transitant par le réseau, il doit y avoir de la sécurité derrière, sinon bonjour les dégâts …
Et un dernier point, je vois mal comment la CNIL peut réellement vérifier les données récoltées par ces boîtiers …
MàJ 2013-09-25: UFC-Que Choisir voit ces nouveaux compteurs d'un mauvais œil. http://links.thican.net/?gtFMNA
Toujours agaçant de rechercher cette information, alors je vais la mettre ici :
NOTE : Avec la version d'iptables 1.4.16.3 (en tout cas, supérieur à 1.4.12), le module "state" (par exemple dans "--match state --state <state>") devient obsolète, et est donc remplacé par le module "conntrack", donc pour équivalent, faites --match conntrack --ctstate <state> (voir iptables-extensions(8)). Ainsi, je mets donc les commandes pour la nouvelle version.
L'interface reliée au net sera notée WAN, et celle qui permet donc de relier les machines qui n'ont pas accès au net, sera appelée LAN.
--table nat --append POSTROUTING --out-interface WAN --jump MASQUERADE
--table filter --append FORWARD --in-interface WAN --out-interface LAN --match conntrack --ctstate RELATED,ESTABLISHED --jump ACCEPT
--table filter --append FORWARD --in-interface LAN --out-interface WAN --jump ACCEPT
Ah oui, et bien sûr, il faut activer le transfert de paquets :
Pour du temporaire, jusqu'au prochain reboot : echo 1 > /proc/sys/net/ipv4/ip_forward
Mais sinon, ça se passe dans /etc/sysctl.conf : net.ipv4.ip_forward = 1
(Remarquez la ressemblance entre la hiérarchie net/ipv4/ip_forward et la variable net.ipv4.ip_forward, cela peut vous donner des idées sur certaines config si vous ne trouvez pas d'infos sur le web ;))
Article de Wikipedia : https://en.wikipedia.org/wiki/Network_Address_and_Port_Translation
Autre source, utilisant les mêmes règles : https://serverfault.com/questions/431593/iptables-forwarding-between-two-interface#431607
Wow ! Je suis impressionné par ce type de graphes.
Merci à Camusensei pour le lien.
Lorsque je l'avais découvert -- un débit d'upload plus rapide que celui de l'ADSL -- c'était une bonne surprise :)
C'est toujours la galère de vouloir partager des fichiers lors d'une LAN en réseau local, surtout entre GNU/Linux, Windows et MacOSX (je n'ai jamais réussi à faire fonctionner un tracker pour bittorent en local)
Et bien grâce à python, juste une ligne :
python -m http.server
(pour python2 : python -m SimpleHTTPServer)
Ceci va ainsi créer un simple server http sur le port 8000 (par défaut) de votre machine. Rajouter simplement un numéro de port à la ligne de commande pour changer.
Python c'est MA-GI-QUE.
Du coup, si vous voulez chercher d'autres fonctionnalités disponibles, regardez donc dans le dossier /usr/lib/python*/ ;)
Merci SebSauvage pour l'astuce :)
Commentaire que j'ai posté, le 30/04/2012 (N°17) :
@De passage... : Et pour ceux comme moi qui VEULENT ouvrir l'accès à internet ?
Après une conférence avec Richard STALLMAN, j'ai compris l'importance d'ouvrir l'accès à internet.
Bien sûr, je ne suis pas sadomaso, je n'ai pas ouvert le wifi de ma box, mais de l'interface wifi de mon ordinateur, et ceci pour plusieurs raisons :
- Je ne laisse passer que les connexions extérieurs avec les port 21 (ftp), 80 (http), 443 (HTTPS) et récemment 21 (ssh, oui, c'est gentil de ma part). le dns, c'est ma machine.
- Et je protège ma famille avec une vraie connexion WPA2 depuis la box.
Pour prévenir, j'ai mis en SSID : "A VOS RISQUES ET PERILS" xD
Voilà, ça ! ça, c'est de l'internet OUVERT ! Pas 100% neutre (à cause des ports fermés), mais transparent, car je ne stocke pas les connexions.
J'ai un moment pensé mettre du WEP2 avec mot de passe dans le ssid, mais bon, je ne veux pas que ma connexion soit pompée.
Au sujet du dns, je leur fait même une fleur : je les protège de tout une liste de sites malveillants.
Offrir un avantage, pendant une courte période, sur les tarifs entre opérateurs, ce n'est pas forcément un parti pris si l'opérateur qui profite de l'offre arrive sur le marché. Et puis à partir de 2014, c'est tout le monde qui revient au même tarif, et moins cher.
Hein ? Britisch Telecom pour gérer le réseau des universités et de l'armée de France ? Sérieux ?
/me va en parler avec l'administrateur système de son école.