vosinformations.com

Configuration du serveur proxy dante

vince — 2009-04-09T12:30:00Z

Il permet d'encapsuler tout type de trafic, indépendamment du protocole employé.
Dante est présent dans les dépôts officiels

Dante utilise un fichier de configuration /etc/ sockd.conf subdivisé en deux parties :

les paramètres généraux,
les règles du service.

 logoutput: /var/log/sockd/sockd
 internal: eth0 port = 1080
 external: eth1
 
 method: none username pam
 clientmethod: none
 
 user.libwrap: libwrap
 #user.privileged: sockd
 user.notprivileged: sockd
 
 connecttimeout: 30

logoutput pour loguer tous les évènements à /var/log/sockd/sockd

internal and external adresses/interfaces d'écoute et de sortie du serveur.
L'adresse ip ou la dénomination de l'interface peuvent y être renseignées.

method and clientmethod définit la méthode d'authentification du proxy.

user.notprivileged : l'utilisateur et le groupe sockd sont créés à l'installation du programme.

connecttimeout définit le timeout du proxy, au terme duquel la connexion est perdue.

La seconde partie du fichier de configuration détaille principalement les règles d'authentification, dont voici les principales :

# Autoriser les connexions provenant du LAN
 client pass {
 from: 192.168.0.0/24 port 1-65535 to: 0.0.0.0/0
 log: connect disconnect
 }
 
 # Bloquer le reste
 client block {
 from: 0.0.0.0/0 to: 0.0.0.0/0
 log: connect error
 }
 
 # Bloquer les connexions vers lo
 block {
 from: 0.0.0.0/0 to: 127.0.0.0/8
 log: connect error
 }
 
 # Bloquer le réseau 172.16.0.0/32
 block {
 from: 0.0.0.0/0 to: 172.16.0.0/12
 log: connect error
 }
 
 
 # Autoriser les requêtes bind et udp
 pass {
 from: 0.0.0.0/0 to: 192.168.0.0/24
 command: bindreply udpreply
 log: connect error
 }
 
 # Autoriser les connexion tcp et udp en provenance du LAN vers n'importe quelle destination.
 pass {
 from: 192.168.0.0/24 to: 0.0.0.0/0
 protocol: tcp udp
 log: error
 }
 
 # Bloquer et loguer tout le reste
 block {
 from: 0.0.0.0/0 to: 0.0.0.0/0
 log: connect error
 }

Présentation de SOCKS

vince — 2009-02-06T10:32:00Z

SOCKSv5 est un protocole proxy générique pour les applications communicantes TCP/IP, qui fait l'objet d'un standard IETF (Internet Engineering Task Force) : RFC 1928. Le protocole SOCKS fournit une architecture flexible pour développer des communications sûres en intégrant facilement d'autres technologies de sécurité.

La société NEC USA a bénéficié du leadership technologique dans la mise au point de ce standard depuis 1992.
En 2001, sa filiale Permeo Technologies Inc. a été créée pour le développement et la commercialisation de la suite e-Border reposant sur SOCKS.
Le Directeur Technique de Permeo Technologies, le Dr. Wei Lu, est présentement le "Chairman" du groupe de travail SOCKS auprès de l'IETF.

SOCKS repose sur deux composants,

le serveur SOCKS et,
le client SOCKS.

Le serveur SOCKS est mis en oeuvre au niveau de la couche application, tandis que le client SOCKS est mis en oeuvre entre les couches application et transport.
L'objectif principal du protocole est de permettre à des systèmes situés d'un côté d'un serveur SOCKS d'accéder à des systèmes situés de l'autre côté d'un serveur SOCKS, sans avoir besoin de connexion IP directe.

Lorsqu'une application cliente a besoin de se connecter à un serveur d'application, le client se connecte à un serveur proxy SOCKS.
Le serveur proxy se connecte au serveur d'application au nom du client, et relaie les données entre le client et le serveur d'application.
Pour le serveur d'application, le serveur proxy est le client.

Deux versions du protocole SOCKS existent :

Le protocole SOCKSv4 remplit trois fonctions :

il génère des requêtes de connection,
établit des circuits proxy,
relaie les données applicatives.

Le protocole SOCKSv5 rajoute l'authentification.

Grâce à sa simplicité et flexibilité, SOCKS est utilisé comme pare-feu réseau, proxy applicatif générique, dans des Réseaux Privés Virtuels (RPV ou VPN), et pour des applications extranet.

Les applications basées sur SOCKSv5 offrent de nombreux avantages reposant sur son architecture protocolaire robuste et cependant flexible :

accès réseau transparent au travers de multiples serveurs proxies,
déploiement simple de méthodes d'authentification et d'encryptage,
déploiement rapide de nouvelles applications réseau,
gestion simple des politiques de sécurité.

Les caractéristiques uniques et les avantages de SOCKS SOCKS présente des caractéristiques uniques, ainsi que de nombreux avantages : un protocole de communication unique authentifie les utilisateurs et établit les canaux de communications
Pour chaque canal de communication TCP ou UDP que le protocole SOCKS établit, il

transfert les informations utilisateurs du client SOCKS au serveur SOCKS pour l'authentification des utilisateurs,
authentifie l'utilisateur et le canal,
garantit l'intégrité des canaux TCP et UDP.

La plupart des protocoles de tunneling sépare le processus d'authentification de l'établissement du canal de communication, rendant plus difficile la garantie de l'intégrité des canaux vis-à-vis des utilisateurs authentifiés après que plusieurs canaux aient été établis.

En tant que proxy générique, le protocole SOCKS établit des canaux de communication, gère et protège un canal pour n'importe quelle application.
Lorsque de nouvelles applications apparaissent sur le marché, SOCKS peut ainsi les protéger sans nécessiter de développement supplémentaire.

Les proxies Stateful Inspection de la couche IP requièrent un nouveau script pour l'inspection protocolaire et les proxies de la couche applicative nécessitent un nouveau proxy logiciel pour chaque nouvelle application.
Une protection souple au travers d'une variété de politiques de contrôle d'accès.
Les routeurs IP délivrent des paquets IP en les routant au niveau de la couche IP.
Etant donné que SOCKS délivre des connexions TCP et UDP au travers d'un mécanisme proxy au niveau de la couche TCP/UDP, il fonctionne avec n'importe quelle application, et virtuellement avec toutes les technologies de la couche IP, comme les pare-feu, les équipements NAT et les adresses IP privées.
SOCKS permet la flexibilité dans la gestion du réseau au travers de politiques de contrôle d'accès basées sur les utilisateurs, les applications, en plus des adresses source et destination.

SOCKS offre un support de proxy bi-directionnel.
La plupart des mécanismes proxies basés sur la couche IP, comme la translation d'adresses (NAT), ne supporte que le proxy unidirectionnel, depuis le réseau interne (adresses IP privées) vers le réseau externe (Internet).
Le proxy établit le canal de communication en manipulant les adresses IP, ce qui implique que les adresses IP soient routables sur l'Internet.
Les mécanismes proxy empêchent les applications d'établir les canaux de communication retour nécessaires (depuis l'Internet vers l'Intranet).
De plus, les mécanismes de proxy reposant sur la couche IP ont besoin de logiciels supplémentaires pour chaque application qui utilise des canaux de communication multiples.

SOCKS identifie les cibles de communication au travers de noms de domaine, palliant les restrictions des adresses IP privées.
SOCKS peut également utiliser les noms de domaine pour établir une communication entre des LANs séparés avec des adresses IP redondantes.

Un proxy SOCKS fait office de proxy pour sockets, il ignore le protocole utilisé au dessus (HTTP, FTP, ... un simple flux TCP), un proxy traditionnel ne supporte que certains protocoles définis (typiquement et habituellement : HTTP et FTP).

SOCKS Version 4

vince — 2009-02-06T10:32:00Z

Le protocole SOCKSv4 définit un format de message et des conventions pour permettre à des utilisateurs d'applications TCP un accès transparent au travers d'un pare-feu.
Pendant l'établissement de la connexion proxy, le serveur SOCKS accorde l'accès en se basant sur les informations d'entête de TCP, y compris les adresses IP, et les numéros de ports des hôtes source et destination.
Le serveur SOCKS autorise également les utilisateurs sur la base des informations d'identification (rfc1413).

La communauté des utilisateurs SOCKS a proposé et mis en œuvre une extension protocolaire à SOCKSv4 qui permet de se passer de la contrainte qu'ont les clients SOCKSv4 à résoudre les noms de domaine internes et externes.
En ajoutant les noms de domaine non résolus aux requêtes du client SOCKSv4, les serveurs SOCKSv4 peuvent tenter de résoudre les noms de domaine.

Grâce à sa simplicité, SOCKSv4 est très utilisé comme pare-feu réseau.
Cependant deux faiblesses majeures existent dans le protocole SOCKSv4 :

le manque d'authentification forte, et
la contrainte de recompilation des applications avec la librairie cliente SOCKSv4.

Un groupe de travail de l'IETF (Internet Engineering Task Force) a produit et approuvé une nouvelle version de SOCKS, SOCKSv5.
Le groupe de travail a complété trois standards liés à SOCKSv5 : les rfc1928, rfc1929 et rfc1961.

Networking Systems Laboratory (NWSL), anciennement C&C Software Technology Center (CSTC) de NEC USA Inc., a développé la mise en oeuvre publique la plus populaire.
Elle inclut le serveur SOCKSv4 et des versions "socksifiées" de finger, whois, ftp et telnet.

SOCKS Version 5

vince — 2009-02-06T10:32:00Z

La version 5 du protocole SOCKS, également connue sous le nom de authenticated firewall traversal (AFT, est un standard ouvert de l'Internet (rfc1928) pour produire des proxies réseau au niveau de la couche transport.
Elle résout plusieurs problèmes que la version 4 du protocole SOCKS omettait :

Authentification forte,
Négociation de méthodes d'authentification,
Proxy de résolution d'adresses,
Proxy pour les applications basées sur UDP.

Deux standards supplémentaires liés à SOCKSv5 pour le support des méthodes d'authentification existent :

Authentification Nom d'utilisateur/Mot de passe pour SOCKSv5 (rfc1929)
Authentification GSS-API (Generic Security Service Application Programming Interface) pour SOCKSv5 (rfc1961).

Négociation de méthodes d'authentification

Le client applicatif déclare au serveur SOCKSv5 les méthodes d'authentification qu'il supporte, -# Le serveur SOCKSv5 envoie un message au client pour lui annoncer la méthode que le client devrait utiliser
Le serveur SOCKSv5 détermine la méthode d'authentification sur la base de la politique de sécurité définie dans la configuration du serveur SOCKSv5.
Si la méthode déclarée sur le client échoue à remplir la contrainte de sécurité, le serveur SOCKSv5 clos la communication.

Le proxy résolution d'adresses inclus dans SOCKSv5 simplifie l'administration DNS et facilite le masquage et la translation d'adresse IP.
Les clients SOCKSv5 peuvent passer le nom, au lieu de l'adresse résolue, au serveur SOCKSv5 et le serveur résout l'adresse pour le client. Proxy pour applications UDP
SOCKSv5 supporte les associations UDP.
ne association UDP crée un circuit proxy virtuel pour les données traversantes d'applications UDP.

Il y a deux différences dans les circuits proxies TCP et UDP :

Le circuit proxy UDP est une paire d'adresses pour les extrémités de la communication qui envoie et reçoit des datagrammes,
Les en-têtes proxies UDP encapsulent les données applicatives, y compris l'adresse de destination du datagramme.

enregistrer votre nickname

vince — 2008-12-23T13:20:59Z

Enregistrer le nickname de votre serveur tor, le réserve, afin que personne ne puisse l'emprunter.
De plus, les programmeurs pourront vous contacter en cas de besoin.

Procédure :

Envoyez un mail à tor-ops@freehaven.net avec le sujet '[New Server] <le nickname de votre server>'

Joignez les informations suivantes dans le message :

Le nom du serveur

L'empreinte (fingerprint) de la clé d'identité, qui se présente sour la forme : nickname xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
(nom du serveur + 40 caractères alphanumériques)
Elle se trouve à /var/lib/tor/fingerprint
On peut la trouver également dans les fichiers de logs à chaque démarrage du serveur /var/log/tor/log

Les coordonnées de l'administrateur

Le type du connexion du serveur

Présentation de tor

vince — 2008-12-23T13:19:22Z

Tor repose sur un protocole de routage de type onion routing qui rend pratiquement impossible pour un intrus de déterminer à la fois la provenance et la destination d'un message.

Le réseau est composé de nœuds inter-connectés et sécurisés, à travers lesquels les données sont transportées selon un chemin aléatoire reliant la source à la destination.
Parmi ces nœuds, certains font office de passerelle entre le réseau tor et l'internet global.

L'implantation pratique permet des solutions innovantes, tor construit un véritable réseau virtuel anonyme et crypté sur le réseau physique internet.

Il est donc possible d'y permettre la circulation des sites et services totalement anonyme (hidden services)

Le trafic est encapsulé dans des couches cryptographiques successives (comme la peau d'un oignon) : lors de l'envoi, la source choisit les nœuds (en se connectant à un serveur d'annuaires) par lesquels les données vont transiter et les crypte de manière à ce que chaque intermédiaire ne puisse connaître que le prochain maillon de la chaîne.
Le plus intéressant dans cet algorithme est que le parcours est créé de manière incrémentielle : une fois un nœud atteint, le suivant est sélectionné aléatoirement, ainsi chaque demande sur le web utilise un parcours différent du précédent (par défaut le chemin change toutes les 30s) ?
Aucun nœud ne connaît à lui tout seul le chemin complet emprunté par un paquet de données.

shéma

Ainsi, seul le dernier nœud voit en clair le message et la destination internet du paquet.
De plus, aucun intermédiaire ne peut savoir si un message qu'il reçoit provient directement du nœud précédent ou s'il se contentait uniquement de le router.
Pour les réponses, le chemin de retour est également crypté sur différentes couches de la même manière : le destinataire ne peut donc pas connaître non plus l'origine du message qu'il relaye vers l'internet.

Plusieurs types d'attaques permettent de fragiliser l'anonymat assuré théoriquement par tor, notamment au niveau des protocoles, en utilisant des analyses temporelles.
Cependant, ces attaques ne sont possibles que si l'intrus contrôle un certain nombre de nœuds du réseau.
Par conséquent, la sécurité de chaque serveur tor qui constitue le réseau est relativement déterminante pour la sécurité du tout.

L'unique information sensible d'un serveur tor est sa clé privée, stockée dans /var/lib/tor/keys, qui ne doit être lisible que par l'utilisateur.

Des informations permettant de la compromettre ou de la reconstituer peuvent se retrouver en mémoire, notamment dans la swap.

Minimiser la rétention des données

La mise en place d'une plateforme d'anonymat nécessite d'accorder une attention toute particulière aux logs. Ils pourraient en effet contenir des informations permettant de connaître par recoupement diverses informations nuisibles à l'anonymat des utilisateurs du serveur.
Il faut étudier dans les détails la configuration de votre système de log, afin de ne retenir que le minimum nécessaire au fonctionnement de votre infrastructure.
Il est possible, notamment de configurer la rotation de vos fichiers de log pour qu'ils soient effacés périodiquement.

Tor dans un environnement restreint

Il est conseillé de faire tourner tor dans un environnement restreint, par soucis de cloisonnement, amis aussi pour tout autre service accessible depuis l'extérieur, afin d'éviter qu'une éventuelle faille dans celui-ci ne permette de compromettre tout le système.

Tor dans un chroot

Le chroot est la technique de cloisonnement de base, disponible sur beaucoup de systèmes de type unix.

Coupler squid à privoxy + tor

vince — 2008-12-23T13:18:57Z

L'anonymat fourni par tor s'effectue au détriment de la vitesse et provoque un ralentissement du surf.

Pour y remédier - au moins partiellement - j'exhume les solutions utilisées lors de la période préhistorique (56K) : le cache.
Couplé au couple tor + privoxy, squid retrouve toute son utilité en utilisation haut débit.

Dans le chapitre consacré aux caches, rajouter la ligne :

cache_peer ADRESSE_PRIVOXY parent PORT_PRIVOXY 7 no-query

soit par défaut (privoxy écoutant en 127.0.0.1:8118) :
cache_peer 127.0.0.1 parent 8118 7 no-query

squid proxy anonyme

vince — 2008-12-23T12:10:59Z

Pour éviter que squid ne déclare son utilisation et ne transmettre l'ip réelle, effectuez les deux réglages suivants dans la configuration

via off

forwarded_for off

psybnc.conf

vince — 2008-11-17T08:21:36Z

PSYBNC.SYSTEM.HOST1=*
 PSYBNC.SYSTEM.PORT1=31337

Par défaut, le programme écoute sur toutes les interfaces, sur le port 31337.

On peut rajouter une ou plusieurs interfaces supplémentaires en adaptant la numérotation HOST1, HOST2.....
L'option ssl se déclare en rajoutant =S=

PSYBNC.SYSTEM.HOST1=127.0.0.1
 PSYBNC.SYSTEM.PORT1=31337
 PSYBNC.SYSTEM.HOST2=S=127.0.0.1
 PSYBNC.SYSTEM.PORT2=31338

PSYBNC.SYSTEM.ME=name nom du bouncer.

PsyBNC

vince — 2008-11-16T22:14:13Z

PsyBNC est une passerelle qui permet de se connecter sur un serveur IRC de façon permanente.

Evitez de faire ces manipulations, ainsi que de faire tourner le programme avec les privilèges root. Personnellement je le place directement sous /home/user/.psybnc, dans le répertoire de l'utilisateur

Pas de paquets prêts à l'emploi sur debian/ubuntu, donc compilation.
On télécharge l'archive de la dernière version à partir du site...

wget http://www.psybnc.at/download/beta/psyBNC-2.3.2-7.tar.gz

... qu'on décompresse

tar zxvvf psyBNC-2.3.2-7.tar.gz

on se déplace dans le dossier nouvellement décompressé.

cd psybnc

On peut éditer et renseigner le fichier de configuration ssl psybnc/src/ssl.cnf pour gagner du temps ultérieurement, pendant la compilation.

La commande

make menuconfig

s'emploie pour configurer le programme.
La commande

make

s'utilise pour compiler le programme. (pas de make install).

make clean sert à effacer les compilations antérieures.

Le programme se lance grâce à la commande

./psybnc

lancée dans le répertoire de psybnc.
kill [n° du PID] pour le tuer.

La configuration du bouncer peut s'effectuer :

par modification du fichier psybnc/psybnc.conf (nécessite un redémarrage du programme),
par utilisation de la commande make menuconfig en console (dans le répertoire ./psybnc).
directement par connexion avec un client irc.

Connexion au serveur psyBNC

Connexion :
/server irc.domain.tld port

Mot de passe :
/quote pass

-> Raccourci : connexion + mot de passe
/server irc.domain.tld port

ADDUSER et DELUSER

Voici comment ajouter où supprimer un utilisateur.
Connectez vous sur votre BNC et tapez les commandes suivantes :

Ajouter un utilisateur :
/adduser

Supprimer un utilisateur
/deluser

MADMIN et UNADMIN

Voici comment ajouter où supprimer le flag admin à un utilisateur. _ Connectez vous sur votre Bnc et tapez les commandes suivantes :

Ajouter un admin du bouncer
/madmin

Supprimer un admin du bouncer
/unadmin

ADDSERVER, DELSERVER & LISTSERVERS

Voici comment ajouter, supprimer ou lister les serveurs.
Connectez-vous sur votre BNC et tapez les commandes suivantes :

Ajouter un serveur :
/addserver irc.domain.tld:port

Ajouter un serveur avec un mot de passe :
/addserver irc.domain.tld:port

Lister les serveurs enregistrés :
/listservers

Changer de serveur :
/jump

Supprimer un serveur :
/delserver

Connexion SSL

Ajouter un serveur IRC avec un port SSL
/addserver S=irc.domain.tld:port SSL

ADDNETWORK & DELNETWORK

Se connecter en multiserveur avec psyBNC, c'est-à-dire se connecter simultanément sur plusieurs serveurs IRC.

Ajouter un réseau :
/addnetwork
puis
Ajouter le serveur :
/addserver 'irc.domain.tld:port

Ajouter un salon :
/join '#

Changer de pseudo :
/nick '

Envoyer un message :
/msg '

Supprimer un réseau :
/delnetwork

Password :

Pour changer votre mot de passe :
/password

Pseudo d'away :

/setawaynick

Message d'away :

/setaway

BVhost :

Pour modifier la vHost de psyBNC :

Changer de vHost :
/bvhost
ou
/bvhost
ensuite
relancer le serveur :
/jump