Installer un serveur SOCKS sous Debian/Ubuntu

Posté par seiyar81 le 8 janvier 2010 | Laisser un commentaire (10)

C’est quoi SOCKS ? Et bien SOCKS est un protocole réseau qui permet à des applications client-serveur d’employer d’une manière transparente les services d’un pare-feu.
Nous allons l’utiliser dans cet article pour créer un serveur proxy qui va nous permettre de passer outre les différentes restrictions mises en places sur le réseau.
Il s’agit souvent de ports ou de sites bloqués dans les réseaux d’entreprises ou d’universités.

Personnellement l’école au sein de laquelle je suis mes études, autorise les port 80 (HTTP), 22 (SSH), 21 (FTP), 443 (SSL), 1863 (MSN) et quelques autres seulement. Impossible donc de jouer à un quelconque jeu en ligne (même si je rappelle que les études sont faites pour étudier !). 
Je m’en sers pour jouer de temps en temps et surtout pour me connecter en SSH à mon serveur qui n’écoute pas sur le port 22 (histoire d’éviter le spam de bots).

J’ai choisi d’utiliser Dante Server car il est plutôt simple à configurer, mais sachez qu’il en existe d’autres tels que WinSocks pour Windows ou bien Nylon pour OpenBSD.

On commence donc par installer le paquet :

 
sudo apt-get install dante-server 

Ensuite on va s’intéresser au fichier de configuration du serveur.

Voici un exemple de contenu pour /etc/danted.conf :

logoutput: syslog stdout /var/log/sockd

internal: ip_du_serveur port = port_proxy
external: eth0

method: username

user.notprivileged: sockd

client pass {
  from: ip_du_serveur/0 port 1-65535 to: 0.0.0.0/0
  log: connect disconnect

}

pass {
  from: ip_du_serveur/0 to: 0.0.0.0/0
  method: username
}

Petite explication du bloc ci-dessus :
logoutput indique où l’on souhaite rediriger la sortie du programme
internal/external définissent l’adresse/l’interface utilisée pour l’écoute et la sortie
Placez-y donc l’IP de votre serveur, le port souhaité et l’interface
method: username indique que l’on souhaite une authentification par login/mot de passe
user.notprivileged : l’utilisateur et le groupe sockd sont créés à l’installation du programme

– les zones client pass et pass définissent le traffic autorisé, ici on autorise tout !

On termine en ajoutant une règle iptables pour autoriser le traffic sur le port choisit
et on démarre le serveur :

iptables -A INPUT -d ip_du_serveur -p tcp --dport port_proxy -j ACCEPT

/etc/init.d/danted start

Et voilà c’est aussi simple que ça ! Vous avez maintenant un serveur proxy complètement fonctionnel.
Ne vous reste plus qu’à configurer vos logiciels clients soit directement dans les propriétés des logiciels qui proposent la connexion par proxy soit en utilisant un logiciel du type Proxifier sous Windows ou bien Dante Client.

Catégorie: Internet, Linux | Laisser un commentaire (10)

Les modules indispensables pour Apache 2/2

Posté par seiyar81 le 5 janvier 2010 | Laisser un commentaire (0)
Apache

Un bon moment que rien n’avait été posté sur Yriase, mais le manque de temps, le temps pris par d’autres projets (professionnels et personnels), le temps pris par les révisions, bref le temps donc !
Je profite donc de ce court répit pour finir cette partie sur les différents modules indispensables pour Apache.

Pour commencer le mod SuPHP, qui permet à Apache de se faire passer pour le propriétaire du fichier. Utile si plusieurs utilisateurs peuvent créer des fichiers sur le serveur, ou les envoyer par FTP, car ainsi nul besoin de donner les droits au groupe Apache sur les dossiers.
Attention toutefois car SuPHP ne fonctionne pas avec le module PHP5, il faut utiliser PHP5 en CGI.
On configure donc d’abord PHP en CGI :

// Télécharge les paquets
apt-get install libapache2-mod-suphp php5-cgi

// Editer la configuration de php
vim /etc/php5/cgi/php.ini

// On modifie le ou les VirtualHost concernés
vim /etc/apache2/sites-enabled/000-default
Options ExecCGI

// On vérifie la configuration du module
nano /etc/apache2/mods-enabled/suphp.conf

<IfModule mod_suphp.c>
        AddHandler x-httpd-php .php .php3 .php4 .php5 .phtml
        suPHP_AddHandler x-httpd-php
        suPHP_Engine on
        # # Use a specific php config file (a dir which contains a php.ini file)
        #       suPHP_ConfigPath /etc/php4/cgi/suphp/
        # # Tells mod_suphp NOT to handle requests with the type mime-type
        #       suPHP_RemoveHandler mime-type
</IfModule>

On configure ensuite le module avec le fichier correspondant : vim /etc/suphp/suphp.conf

[global]
;Path to logfile
logfile=/var/log/suphp/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=www-data

;Path all scripts have to be in
;docroot=/var/www
docroot=/home/sites

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
;umask=0077
umask=0002

; Minimum UID
min_uid=1000

; Minimum GID
min_gid=1000


[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

Puis on active le module et on redémarre le serveur comme d’habitude :

a2enmod suphp
/etc/init.d/apache2 reload

Maintenant voici un autre module tout aussi intéressant et utile, j’ai nommé : Cband. Très pratique, et je dirais même plus indispensable si on possède un site dont ou souhaite maîtriser la bande passante. Cband nous offre la possibilité de choisir le montant de bande passante à allouer à nos VirtualHosts ainsi qu’à chaque utilisateur. Idéal pour un site de partage de vidéos par exemple ou bien si le serveur héberge plusieurs sites. Attention toutefois, Cband ne fonctionne qu’avec Apache 2.x !

On rentre dans le vif du sujet avec le classique : installation/activation du module.

apt-get install libapache2-mod-cband
a2enmod cband

On ajoute ensuite deux petites lignes à la configuration générale d’Apache (/etc/apache2/apache.conf par défaut) qui vont nous permettre d’améliorer les performances générales :

CBandScoreFlushPeriod 1
CBandRandomPulse On

Avant de redémarrer Apache, nous allons maintenant configurer nos VirtualHosts. Deux directives à connaître pour cela, CBandSpeed et CBandRemoteSpeed qui correspondent à la bande passante d’Apache et de chaque utilisateur.
Pour déclarer une règle c’est très simple, on indique d’abord le débit autorisé, ensuite le nombre de requêtes par seconde et enfin le nombre de connexion simultanées.
Imaginons donc que l’on dispose d’une connexion à 100Mbps et qu’on souhaite allouer 70Mbps à Apache avec 350 requêtes/secondes et 25 connexions simultanées :

<VirtualHost *:80>
...
<IfModule mod_cband.c>
    CBandSpeed 70Mbps 350 25 
    CBandRemoteSpeed 4096 20 4
</IfModule>
...
</VirtualHost>

Par défaut l’unité est le kbps, chaque utilsateur disposera donc de 4096 kbps de bande passante dans le cas présent.
Si vous disposez d’un serveur avec un trafic mensuel maximum par exemple sachez que vous pouvez réguler la bande passante ainsi :

<IfModule mod_cband.c>
    CBandLimit 8G                      // 8Gbps
    CBandPeriod 4W                   // 4 semaines soit environ 1 mois
    CBandPeriodSlice 1W            // Période d'une semaine
    CBandSpeed 500kbps 10 30   // Règle pour Apache
    // Règle en cas de dépassement
    CBandExceededSpeed 128kbps 5 15
    // Fichier utilisé par Cband pour enregistrer tout ça
    CBandScoreboard /var/www/dossier/secret/mondomaine.com.scoreboard
</IfModule>

Enfin Cband offre à la manière de server-status une page pour les statistiques à laquelle il est préférable d’autoriser l’accès par IP :

<IfModule mod_cband.c>
      <Location /cband-status>
            SetHandler cband-status
            Order deny,allow
            Deny from all
            allow from xxx.xxx.xxx.xxx
      </Location>
</IfModule>

Pour finir on enregistre le tout et on redémarre Apache !

Vous connaissez tous probablement CGI ! Si non voici la définition de Wikipédia (histoire de pas raconter trop de bêtises^^) :

CGI, est une interface normalisée utilisée par les serveurs HTTP. Ce dernier, au lieu d’envoyer le contenu d’un fichier (page HTML, image…), exécute un programme puis retourne le contenu généré, comme s’il s’agissait d’un contenu de fichier. CGI est le standard industriel qui indique comment transmettre la requête du serveur HTTP au programme et comment récupérer la réponse générée.
CGI est indépendante de tout langage. Même si le langage Perl a historiquement été souvent utilisé pour en écrire, il est possible d’écrire un programme CGI en C, Python, Gambas, PHP, en script shell, en VB ou en tout autre langage de programmation.

Certains d’entre vous ont d’ailleurs sûrement déjà utilisé PHP en mode CGI, oui si vous utilisez SuPHP !
Et bien FastCGI n’est ni plus ni moins que CGI amélioré, ainsi plusieurs processus peuvent être utilisés pour traiter les requêtes contre un seul pour CGI. Le traitement des requêtes est ainsi considérablement accéléré.
De plus FastCGI est disponible pour Apache, IIS, Tomcat, lighttpd, nginx etc…

Nous allons installer la version développée par OpenMarket disponible ici http://www.fastcgi.com/.
Comme d’habitude :

cd /tmp
wget http://www.fastcgi.com/dist/mod_fastcgi-current.tar.gz
tar -xf mod_fastcgi-current.tar.gz
cd mod_fastcgi-2.4.6

// pour Apache 2
cp Makefile.AP2 Makefile
make 
make install

// Si votre dossier d'installation n'est pas /usr/local/apache2 
make top_dir=/chemin/vers/apache2
make top_dir=/chemin/vers/apache2 install

Une fois installé, il faut l’activer dans la configuration d’Apache. Ajoutez donc la ligne suivante au fichier apache2.conf :
LoadModule fastcgi_module /usr/lib/apache2/modules/mod_fastcgi.so

Vous pouvez ensuite vérifier que le module est bien activé :

// On recharge Apache
/etc/init.d/apache2 reload

// Pour voir la liste des modules chargés
apache2ctl -t -D DUMP_MODULES

Pour les différentes options de configuration que je ne maîtrise pas parfaitement vous pouvez vous référer à la documentation.

Voilà c’est tout pour cette deuxième partie, je consacrerais sûrement des articles à des modules vus plus en détails.

Catégorie: Apache | Laisser un commentaire (0)