01 octobre 2014

mod_perl startup

Une fois que l'on a un couple {Apache2 + mod_perl2} adapté il faut faire une peu de configuration. Voici comment mettre en place mod_perl2  et verifier que tout marche.

Rappel: il faut au minimum mod_perl 2.0.9 pour Apache 2.4.x

1) Configurer Apache normalement pour qu'il affiche le fichier index.html de votre répertoire htdocs. Ceci est toujours utile de pouvoir servir des pages statiques sans faire appel à Perl.
NB: Inutile de configurer la partie cgi-bin, ou php ;-)


2) Quand l’étape #1 fonctionne ajouter cette simple ligne à la fin du fichier de configuration principale de apache (httpd.conf)

    Include conf/mod_perl2.conf

Ainsi on ne touchera plus au fichier de configuration principal, on travaillera sur mod_perl2.conf, dont voici le contenu de départ :

LoadModule perl_module modules/mod_perl.so

# la ligne suivante n'est utile que si on a installé le module
# Apache2::Request qui utilise APR::Request qui utilise libapreq2
#   yum install libapreq2
#   cpanm       APR::Request
#   cpanm       Apache2::Request
# (le but étant de ne plus utiliser CGI.pm)
LoadModule apreq_module modules/mod_apreq2.so

PerlPostConfigRequire /path/to/myCode/startup.pl
PerlOptions -SetupEnv
 

<Location /hello>
   SetHandler perl-script
   PerlResponseHandler Hello
   PerlOptions +ParseHeaders

</Location>

a) On charge le module mod_perl (c'est lui qui importe Perl dans Apache)
b) On désigne un script Perl à exécuter au démarrage de Perl (voir plus bas)
c) On désactive l'importation de l'environnement dans le contexte de chaque requête (plus sûr et plus rapide)
d) On annonce que l'url /hello sera traitée par le module Perl Hello.pm
Ce module gèrera lui-même les headers et il sera exécuté en tant que "perl-script" (bien que ce soit forcement un module)


3) Le module Hello.pm est très simple à écrire et à comprendre :

package Hello;
use strict;
use warnings;

sub handler {  # Le nom de la fonction est imposé
    print "Content-type: text/plain\n\n";
    print "Hello at : ". localtime . "\n";
    return Apache2::Const::OK;
}
1;


On le stocke dans /path/to/myCode/Hello.pm



4) Le script startup.pl ressemble à ceci

use lib qw(/path/to/myCode);   # voir "Attention #2" plus bas

use ModPerl::Util ();
use ModPerl::Registry ();
 
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::ServerRec ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();

use Apache2::Const -compile => ':common';

use APR::Table ();
use APR::Const -compile => ':common';

1;


Le plus important dans ce fichier est la première ligne car elle indique où seront vos modules Perl chargés de réponde aux requêtes. Les autres "use" préchargent des modules d'usage courant ce qui evitera de répéter ces "use" dans chaque module Perl.


Si vous devez ouvrir un accès à une base de donnée ce sera aussi dans ce script en utilisant Apache::DBI Exemple pour Postgresql

use Apache::DBI;
Apache::DBI->connect_on_init("dbi:Pg:dbname=myDB", 

  "myUSR", 
  "myPASS",
  {AutoCommit => 1, RaiseError => 1, PrintError => 1} 

);
Apache::DBI->setPingTimeOut("dbi:Pg:dbname=myDB", 30);


ATTENTION #1: Pour accéder à la base de donnée dans un module (handler) il faudra utiliser le classique $dbh = DBI->connect(...) Mais il faudra que tous les paramètres de connect() soit exactement les mêmes que ceux passé à connect_on_init();


ATTENTION #2: Dans le contexte de mod_perl2 "use FindBin;" ne marche pas comme espéré.
En effet $FindBin::Bin donne le point de démarrage du serveur Apache, pas celui de startup.pl.

A la place il faudra faire ce genre de gymnastique:

use File::Basename;
our $PERLBASE;
BEGIN {
  $PERLBASE = dirname( __FILE__ );
}
use lib $PERLBASE;



Dans tous les modules (handlers) vous pourrez accéder simplement à $::PERLBASE



25 septembre 2014

proxy ssh

Il arrive souvent que les machines d’un réseau de développement  ne soit pas accessibles depuis l’extérieur à l’exception d’une machine jouant le rôle de porte d’entrée (frontdoor.mydomain.com).

Pour accéder depuis l’extérieur aux machines internes on établit depuis son poste externe une première connexion ssh avec  frontdoor.mydomain.com puis, de là, on établit une seconde connexion ssh vers la machine interne sur laquelle on veut travailler. Donc une opération en deux temps.

On peut simplifier ceci en établissant des ‘tunnels’ entre le frontdoor et les machines internes qui vont faire en sorte qu’une connexion sur le port 8001 du frontdoor donne directement accès à dev1, qu’une connexion sur le port 8002 du frontdoor donne directement accès à dev2 etc…

On établit donc un tunnel entre le port 8001 du frontdoor et le port 22 de dev,
puis un tunnel entre le port 8002 du frontdoor et le port 22 de dev2 etc…

Pour cela on se connecte sur le frontdoor et on exécute par exemple ces 2  commandes pour établir deux tunnels :

ssh -N -f -L 8001:localhost:22 devusr1@dev1.mydomain.com

ssh -N -f -L 8002:localhost:22 devusr2@dev2.mydomain.com

Chaque commande va  demander le mot passe pour se connecter  avec le user voulu à la machine interne qui sera l’extrémité ‘22’ du tunnel. Si la clé publique du user de frontdoor  est acceptée par le devusr coté machine de développement aucun mot de passe n’est demandé.  (Cette possibilité est très utilise si on veut automatiser l’établissement et la supervision de ces tunnels)

Ceci fait on peut fermer la session avec le frontdoor, les tunnels resteront actifs.

Maintenant, pour se connecter sur dev1 depuis l’extérieur on tape
    ssh –p 8001 usr@frontdoor.mydomaine.com
et bien sur la commande suivante vous loguera sur dev2
    ssh –p 8002 usr@frontdoor.mydomaine.com
La demande de mot de passe sera pour l'utilisateur 'usr' sur frontdoor. Là aussi on peut aussi utiliser un système de clés.

NOTE
Du point de vue de la machine interne (dev1 ou dev2) vous êtes un utilisateur connecté depuis 127.0.0.1 pas depuis frontdoor. Facile à vérifier avec la commande ‘who ‘

Il y a plein d'autre utilisations de cette technique du 'Local Port Forwarding'. Mais attention au firewall qui peut se trouver devant le frontdoor et qui pourrait bloquer l’accès aux ports d'entré du tunnel (8001, 8002 dans notre exemple)

Il y aussi des variantes de cette technique :
- Remote port forwarding (on établit le tunnel dans l'autre sens en utilisant ssh -R à la place de ssh -L)
- Dynamic port forwarding (plus complexe et nécessite la configuration SOCKS)


18 septembre 2014

pg_hba.conf (part2)

(Dans la première partie on a vu comment configurer l'accès local à un serveur Postgresql)

Sachant que pour se connecter à distance (via le réseaux) à un serveur Postgresql il faut utiliser la commande
    psql -h host  database  username

On va essayer d’accéder à notre nouvelle installation de Postgresql se situant sur le serveur avec l'ip 192.168.0.3

> psql -h 192.168.0.3  postgres  postgres
psql: n'a pas pu se connecter au serveur : Connection refused
      Le serveur est-il actif sur l'hôte « 192.168.0.3 » 
      et accepte-t-il les connexions TCP/IP sur le port 5432 ?

Effectivement la première chose à faire est d’autoriser les connections venant du réseau.
Pour cela il faut éditer le fichier /var/lib/pgsql/data/postgresql.conf et y ajouter la ligne
    listen_addresses = '*'

puis redémarrer le serveur Postgresql
    systemctl restart postgresql

On ré-essaye :
    psql  -h 192.168.0.3  postgres  postgres
    psql: FATAL:  no pg_hba.conf entry for host "192.168.0.59",

    user "postgres", database "postgres", SSL off

Maintenant il faut autoriser les connections sur la base du triplet : (data-base, user, ip-client)

Pour faire simple on va ajouter cette ligne à pg_hba.conf
    host   all   all   all   md5
Ce qui signifie que s'il connait le password n'importe quel utilisateur de Postgresql peut se connecter à n'importe quelle base de données depuis n'importe où sur internet. C'est un peut trop ouvert !

En utilisant cette ligne
    host   all   all   samenet   md5
les clients devront être sur des machines du même réseau local que le serveur Postgresql.

En utilisant cette ligne
    host   sameuser   all   samenet   md5
Un user ne pourra se connecter qu'a la base de données qui porte son nom et seulement depuis une machine du réseau local. (config typique d'un environnement de développement dédié. Ne pas utilisé si le réseau local est trop ouvert, ni dans un environnement cloud)

En utilisant ces deux lignes en même temps
    host   webapp    webapp  w.x.y.z/32  md5
    host   sameuser  all     a.b.c.0/24  md5

Le serveur web situé à l'adresse w.x.y.z pourra se connecter à la base webapp avec le user webapp
et les développeurs du sous réseau a.b.c.0/24 pourront utiliser la base qui à le même nom que d'utilisateur.
Par exemple : postgres/postgres, webapp/webapp, webbackup/webbackup  jean/jean


Si vous avez pigez cela vous pigerez la petite doc qui se trouve au début du fichier pg_hba.conf


RAPPEL: Pour que les changements dans le fichier pg_hba.conf prennent effet il faut redémarrer le serveur Postgresl.

Info sur le codage md5 des mots de passe dans la table pg_shadow de Postgresql;
http://code18.blogspot.fr/2010/01/cracker-un-md5-de-postgresql.html




 

17 septembre 2014

pg_hba.conf (part1)

Dans cette première partie on va voir comment sécuriser Postgresql  juste après son installation.


1) Vous venez donc d'installer Posgresql 9.x et voulez vous connectez en tapant psql.

> psql
psql: FATAL:  role "bidule" does not exist


En fait, en absence d'information, psql utilise le nom de l'utilisateur coté Unix et essaye de s'en servir pour se connecter à la base de données du même nom.

En fait, pour l'utilisateur 'bidule'
    > psql
est équivalant de
    > psql bidule bidule

Le premier 'bidule' est le nom de la base de données et le second le nom de l'utilisateur coté postgresql.


2) Dans toute installation par défaut de Postgresql il y a une base de données nommée postgres et un utilisateur nommé postgres. Donc ceci doit marcher :

> psql postgres postgres
psql (9.2.7)
Type "help" for help.

postgres=# _


Effectivement, on a bien le prompt du serveur Posgresql.


3) QUOI ?! Pas besoin de mot de passe !!!
Incroyable : Sur la machine où s’exécute le serveur Postgresql aucun utilisateur local n'a besoin de mot de passe pour y accéder. Ceci est dû à cette ligne dans le fichier pg_hba.conf

    local   all   all  trust

Elle signifie qu'en 'local', toutes  les bases de données (premier 'all') sont accessibles par tous les utilisateurs (deuxième 'all') à qui l'OS a déjà fait confiance ('trust') en acceptant qu'ils se connectent sur la machine.

Bien sur ceci est un véritable problème sur une machine multi-utilisateurs.

Notez que cette méthode très libérale pose exactement les mêmes problèmes que le mot de passe par défaut connu de tout le monde ou que l'utilisateur par défaut sans mot de passe.


4) Les trois premières choses à faire sont, dans cet ordre :
- attribuer un password au user 'postgres'  (coté Postgresql, pas coté Unix)
- changer la ligne de pg_hba en: "local   all   all  md5"
- mettre en commentaire toute les autres lignes utilisant la méthode 'trust'

En remplaçant la méthode 'trust' par la méthode 'md5' on force tout utilisateur local à donner le mot de passe de l'utilisateur coté base de données. Encore faut-il qu'il en ait un...

4.1) Donc on se connecte à Posgresql avec:

    > psql postgres postgres

puis on tape ces deux commandes pour attribuer un mot de passe à l'utilisateur postgres :

    ALTER USER postgres WITH PASSWORD 'Secr3tPassW0rd';
    \q



4.2) Dans le fichier pg_hba on remplace sur la ligne local la methode 'trust' par 'md5'
et on met en commentaire les deux lignes host utilisant aussi trust
# host    all  all  127.0.0.1/32   trust
# host    all  all  ::1/128        trust
On sauve, puis on redémarre le serveur Postgresql :

    systemctl restart postgresql


4.3) Maintenant si on utilise la commande  psql on doit taper le mot de passe

    > psql postgres postgres
    Password for user postgres: xxxxxxxxxxxx
    psql (9.2.7)
    Type "help" for help.
   
    postgres=# _


Ouf !

Notez qu'en remettant la méthode d'authentification pour 'local' à 'trust' pour pourrez vous connecter à nouveau (en local) sans mot de passe, ce qui est bien pratique si vous l'avez oublié.

Ce qui signifie que le 'root' Unix a tous pouvoirs sur le serveur Postgresql puisque il peut outre passer l’authentification en modifiant le fichier pg_hba.conf

Passons à l’accès via le réseaux ...