Au feu, tournez à gauche

Tags: , , , ,
2 Comments »

Pour des raisons évidentes, j’ai décidé de rendre un peu moins aisée (i.e. pas immédiate) la découverte de mon IP. Plus précisemment, pour certains protocoles et pour certaines machines, je veux que l’IP vue par mon/mes peers ne soit pas directement l’IP que mon fournisseur d’accès m’affecte.

J’ajoute, mais cela n’a evidemment aucun rapport avec cet article, que certains pays intellectuellement plus développés ont recemment confirmé que le partage de fichiers sur le réseau n’était pas illégal sur leur sol.

Le postulat est donc le suivant: seules certaines machines de mon réseau privé devront “sortir” sur une passerelle differente, et uniquement pour certains ports et protocoles.

Pour réaliser cette petite tambouille, j’ai à ma disposition :

  • Un serveur dédié ou virtuel hébergé “ailleurs”, possédant une interface sur une DMZ
  • Le serveur en question fonctionne sous GNU/Linux, on gère donc le NAT et le firewalling grâce à iptables
  • Une passerelle qui me relie à l’Internet par le biais de mon fournisseur d’accès
  • Cette passerelle fonctionne sous NetBSD 5.0.2, on gère le NAT et le firewalling grâce à pf (notez qu’ipf ne permettrait pas, à ma connaissance, d’utiliser les fonctions qui nous seront nécessaires)

La première étape consiste à établir un lien VPN entre la passerelle et le serveur dédié. J’ai utilisé OpenVPN, solution de choix de par sa simplicité, sa souplesse et sa grande stabilité. Étant donné qu’il existe un nombre incalculable de documentations sur cet outil, je colle ici mes configurations client et serveur sans plus de détails :

Sur le serveur :

tls-server

port 4444
dev tun
proto udp
local mon.serveur.dedie

cd /home/imil/etc/openvpn
ca keys/ca.crt
cert keys/dedie.crt
key keys/dedie.key
dh keys/dh1024.pem

client-config-dir ccd

server 10.20.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

client-to-client
route 192.168.1.0 255.255.255.0

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

status openvpn-status.log

verb 3

Sur le client :

tls-client

proto udp
dev tun0

remote mon.serveur.dedie 4444

nobind

cd /usr/pkg/etc/openvpn/dedie-keys
ca ca.crt
cert monhost.crt
key monhost.key

comp-lzo

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

pull

verb 3
log /var/log/openvpn.log

Une fois OpenVPN démarré sur chaque point, une interface tun0 monte, avec coté serveur une IP du type 10.20.0.1 et côté client, 10.20.0.6.
Notez que, coté serveur dédié, on verra arriver une machine depuis la passerelle avec son IP réelle sur le réseau domestique, soit ici 192.168.1.0/24. Ainsi, c’est ce sous-réseau que nous devons NATer sur le dédié GNU/Linux.

Une particularité de mon montage est que je ne souhaite pas utiliser l’IP publique principale de mon serveur public car celle-ci possède un reverse sur mon domaine et est facilement identifiable. Par chance, mon hébergeur me donne la possibilité d’ajouter des alias IP routés sur l’interface publique. En l’occurence, c’est précisemment sur cet alias que j’effectue un source NAT plutot que du MASQUERADING :

### règles INPUT
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # j'autorise en entrée les connexions établies et connexes
# iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT # j'autorise l'echo-request
# iptables -A INPUT -p udp -m udp --dport 4444 -j ACCEPT # j'autorise la connexion vers OpenVPN
# iptables -A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable # et je rejette tout le reste sur l'interface eth0
### règles de NAT
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source mon.alias.ip.public

Désormais, si sur ma passerelle je plaçais une route par defaut sur 10.20.0.1 (le boût du tunnel sur le serveur dédié), les machines de mon réseau 192.168.1.0/24 apparaîtraient avec l’IP mon.alias.ip.public.
Cependant, seulement certaines machines, et surtout certains protocoles devront être soumis à cette politique, et c’est grâce à pf, et en particulier la directive route-to, que nous allons mettre en place ce routage conditionnel. Voici les lignes corresponsantes du fichier pf.conf de notre passerelle NetBSD :

int_if="xennet0"

[...]

pass in on $int_if route-to (tun0 10.20.0.1) proto tcp from 192.168.1.10 \
        to any port 80
pass in on $int_if route-to (tun0 10.20.0.1) proto udp from 192.168.1.10 \
        to any port > 10000

Décodage: Concernant le traffic qui arrive sur l’interface interne $int_if, toute demande en provenance de l’IP 192.168.1.10 à destination du protocole HTTP devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.
toute demande en provenance de l’IP 192.168.1.10 à destination de ports UDP supérieurs à 10000 devra être routée vers l’interface tun0 en utilisant l’adresse de passerelle 10.20.0.1.

J’utilise ce routage depuis hier soir, l’overhead du lien VPN est minimal et l’ensemble se comporte correctement. Je ne prétend pas, avec ce système, bénéficier d’un anonymat hors du commun, mais il me permet au moins de ne pas exposer mon IP publique.

Crassshhhh

Tags: , , , , ,
No Comments »

C’est remarquable cette propension des petits lutins bleus de la nuit à aller bousiller les seules machines qui ne sont pas backupées, ils savent tout, ils voient tout, et ce sont de sacrés petits pervers de merde.

Hier matin, alors que je m’apprétais à faire le tour de mes mails avant de partir au boulot, je constate avec effroi que “je ne sors plus”. Comportement plus qu’étrange, ma passerelle récupère bien l’IP publique Free via DHCP, le ping passe quelques secondes, puis s’arrête, plus rien. Inévitablement, je commence à blâmer Free -bien qu’objectivement, je n’ai pas recontré de problèmes majeurs depuis des mois-, puis par acquis de conscience, teste le lien sur une machine differente. Ça passe.

Mon ancienne passerelle était un peu bancale, il faut l’avouer; il s’agissait d’une Sun Netra X1 gracieusement léguée par monsieur ange pendant Solutions Linux 2008, qui faisait tourner un OpenBSD 4.1 qui paniquait environ tous les trois mois.

Il ne m’en fallait pas plus pour plancher sur une nouvelle gateway, sous NetBSD cette fois. M’est alors apparu l’idée de faire fonctionner cette passerelle dans un domU, après tout, en bridgeant l’interface qui reçoit le réseau Free à une interface Xen, et de la même manière, en bridgeant l’interface raccordée à mon LAN, cela devrait fonctionner sans accroc: et bien c’est le cas.

Voici les fichiers impliqués dans ce mic-mac:

Sur le dom0, je déclare mes interfaces comme suit :

$ cat /etc/ifconfig.fxp0 # LAN
inet 192.168.0.10 netmask 255.255.255.0
$ cat /etc/ifconfig.fxp1 # Free
up

Puis je déclare des bridges sur ces interfaces :

$ cat /etc/ifconfig.bridge0 # LAN
create
!brconfig $int add fxp0 up
$ cat /etc/ifconfig.bridge1 # Free
create
!brconfig $int add fxp1 up

Ce qui nous donne, dans la configuration du domU :

$ cat /usr/pkg/etc/xen/exar
#kernel = "/home/imil/xen/netbsd-5.0.2-INSTALL_XEN3_DOMU.gz"
kernel = "/home/imil/xen/netbsd-5.0.2-XEN3_DOMU-pf.gz"
memory = 256
name = "exar"
vcpus = 1
disk = [ 'file:/home/imil/xen/exar.img,0x03,w' ]
disk += [ 'file:/home/imil/iso/amd64cd-5.0.2.iso,0x04,r' ]
vif = [ 'bridge=bridge0' ]
vif += [ 'bridge=bridge1' ]
bootdev = "/dev/xbd0a"

Notez le nom du noyau qui sert à faire booter cette VM, netbsd-5.0.2-XEN3_DOMU-pf.gz. En effet, un modload /usr/lkm/pf.o fait misérablement crasher le domU, il est donc nécessaire de se fendre d’une recompilation du noyau domU en incluant à la configuration :

pseudo-device   pf                      # PF packet filter
pseudo-device   pflog                   # PF log if

Sur le domU-passerelle, on constate la présence des deux interfaces :

$ ifconfig -a
xennet0: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]
xennet1: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]

Leur configuration est triviale :

exar$ cat /etc/ifconfig.xennet0 # LAN
inet 192.168.0.254 netmask 255.255.255.0
exar$ cat /etc/ifconfig.xennet1 # Free
up
!dhclient $int

Et voila !

On active le NAT gràce à pf :

ext_if="xennet1"
int_if="xennet0"

nat on $ext_if from !($ext_if) -> ($ext_if:0)

Et me voila à nouveau en mesure de raconter ma vie trépidante sur l’Intarwebz.

Welcome home

Tags: , , , ,
6 Comments »

Un des trucs, sinon LE truc que je crevais d’envie de faire dans mon nouvel appart, c’était de monter un vrai hotspot, comme je l’expliquait deux news plus bas. Eh bah ça y est, c’est up. Je sais pas encore bien si j’en ferai un article ou si je donnerai des astuces au coup par coup, mais en attendant, voici à quoi ça ressemble.

Deux OpenWRT configurés en simples bridges permettent aux invités de se raccorder au VLAN dédié au wireless public :

/etc/config/wireless

config wifi-device  wifi0
        option type     atheros
        option disabled 0
        option mode             11b
        option distance         10000
        option diversity        0
        option txantenna        1
        option rxantenna        1
        option channel          6

config wifi-iface
        option device   wifi0
        option ifname   ath0
        option network  lan
        option mode     ap
        option ssid     Empire-Network
        option encryption none
        option txpower 18

/etc/config/network

config interface loopback
        option ifname   lo
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0

config interface lan
        option ifname   eth0 ath0
        option type     bridge
        option proto    static
        option ipaddr   192.168.200.253
        option netmask  255.255.255.0

Où un serveur dhcp leur fournira une IP dans le subnet adéquat. Un simple règle pf redirigera alors toute requète http vers un portail captif qui expliquera à l’invité quelles informations entrer dans son browser afin de pouvoir utiliser HTTP, HTTPS et FTP (notez que pour le moment un seul sur une bonne 30aine a reussi à effectuer cette opération heutement technique…). Quelques règles de QoS m’assurent que l’invité ne crame pas toute ma bande passante :

/etc/pf.conf

int="fxp0"

table <empire_guests> { 192.168.200.0/24, ! 192.168.200.254, ! 192.168.200.253, ! 192.168.200.252 }

altq on $int cbq bandwidth 28Mb queue { empirenet_in, empirenet_out }
queue empirenet_in bandwidth 2Mb priority 1 cbq(default)
queue empirenet_out bandwidth 128Kb priority 7

rdr on $int inet proto tcp from any to <empire_guests> port www -> 127.0.0.1 port 80

pass in on $int from any to <empire_guests> queue empirenet_in
pass out on $int from <empire_guests> to any queue empirenet_out

L’utilisateur passe alors via Squid et son activité est soumise au filtrage de squidGuard dans lequel j’ai interdit les catégories !aggressive !violence !hacking !ads !porn !warez !suspect.
J’applique sur le switch des access-list par port qui n’autorisent que les protocoles HTTP, SSH et DHCP.

[...]
ip access-list extended wifiout
 permit ip any host 192.168.200.254
 permit tcp any any eq http
 permit udp any any eq bootps
 permit tcp any any eq ssh
[...]
interface e 18
 ip access-group wifiout in
[...]

Le tout est graphé par Cacti, notemment grace à l’extension dhcpd-snmp de Net-SNMP et au template cacti associé.

Si vous passez dans le 17eme, cherchez le ssid “Empire-Network” :)

update

Bon bah en fait si, y’aura un article :)

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in