PHP Soapclient et connexion HTTPS via un proxy

Rédigé par gorki - - Aucun commentaire

Le problème :

En passant via mon proxy entreprise ou local (SQUID) mes requêtes SOAP recevaient les erreurs :

  • Parsing WSDL: Couldn't load from 'https://host/service?wsdl' : failed to load external entity 'https://host/service?wsdl'
  • Could not connect to host

Solution :

Trouver l'origine du problème, activer les traces :

$client = new SoapClient("http://www.webservicex.net/ConverPower.asmx?WSDL", array('trace' => 1));
echo "====== REQUEST HEADERS =====" . PHP_EOL;
var_dump($client->__getLastRequestHeaders());
echo "========= REQUEST ==========" . PHP_EOL;
var_dump($client->__getLastRequest());
echo "========= RESPONSE =========" . PHP_EOL;
var_dump($response);
array
(
    'trace' => 1
    'proxy_host' => 127.0.0.1
    'proxy_port' => 3128
)
// Attention ! vérifier que ces directives sont bien appelées (par exemple pas dans un fichier classe... sifflotements...)
ini_set('soap.wsdl_cache_enabled',0);
ini_set('soap.wsdl_cache_ttl',0)
$context = stream_context_create(array(
    'ssl' => array(
        'verify_peer' => false,
        'verify_peer_name' => false,
        'allow_self_signed' => true
    )
));

$client  = new SoapClient(null, array( 
    'location' => 'https://...',
    'uri' => '...', 
    'stream_context' => $context
));

 

 

Configuration OpenDKIM en multi-domaines

Rédigé par gorki - - Aucun commentaire

Le problème :

En complément à cet article http://hoab.fr/postfix-et-10-10-aux-tests-antispam

Solution :

C'est tout simple, c'est pour tracer.

Par rapport aux tutoriels référencés dans l'article précédent, la configuration /etc/opendkim.conf :

#Domain & Selector & KeyFile ignore avec Keytable

#Domain			origames.fr
#Selector		mail
#KeyFile		/etc/dkim/mail.private

KeyTable		/etc/dkim/KeyTable
InternalHosts		/etc/dkim/TrustedHosts
SigningTable		/etc/dkim/SigningTable

On demande à opendkim d'aller chercher les clés dans un fichier plutôt que d'avoir une clé unique.

  1. ajout de la ligne du domaine dans : /etc/dkim/SigningTable
<domaine.com> mail._domainkey.<domaine.com>
  1. ajout de la ligne du domaine dans : /etc/dkim/TrustedHosts
<domaine.com>
  1. ajout de la ligne du domaine dans : /etc/dkim/KeyTable
mail._domainkey.<domaine.com> <domine.com>:mail:/etc/dkim/keys/<domaine.com>/mail.private
  1. générer la clé DKIM
cd /etc/dkim/keys/<domaine.com>/
opendkim-genkey -t -s mail -d <domaine.com>

Et voilà, ça roule.

 

DNS et propagation lente

Rédigé par gorki - - Aucun commentaire

Le problème :

Avec un serveur dédié chez OVH, il arrive que l'on veuille gérer son DNS directement.

Donc le DNS primaire est votre serveur, OVH propose des DNS secondaires qui se synchronise avec vous. En général ces DNS secondaires sont plus utilisés par le reste du WEB que le votre.

Le serveur secondaire de chez OVH ne propagait pas mes modifications

Solution :

Bête comme choux, mais encore faut-il ne pas l'oublier, les enregistrements DNS ont un timestamp.

Il faut l'incrémenter à chaque fois, c'est sur ce critère que le DNS secondaire se remet à jour.

(On aurait aussi pu utiliser des outils tout fait, qui, eux, n'oublie pas ça !)

Sinon, éditer : /etc/bind/pri/mondomaine.fr et incrémenter la date (2015010107)

mondomaine.fr.	IN	SOA	mondomaine.fr. postmaster.mondomaine.fr. (
			2015010107
			21600
			3600
			604800
			86400 )
                IN      NS      ns1234.ovh.net.
                IN      NS      sdns2.ovh.net.
                IN      MX      10 mail.mondomaine.fr.
                IN      A       1.1.1.1

Ensuite

/etc/init.d/name reload
# ou tout autre commande suivant la version de votre système

 

 

Postfix et 10/10 aux tests antispam

Rédigé par gorki - - Aucun commentaire

Le problème :

Après avoir installé un serveur de mail. Gmail refusait les mails envoyés depuis ce serveur.

"Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1  https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information"

Et là, il faut suivre les conseils vagues de Google, heureusement d'autres sites sont de meilleurs aides, exemple :  https://www.mail-tester.com/

Le contexte :

- un serveur de mail + un nom de domaine (MONDOMAINE)

- un deuxième serveur de mail qui envoie des mails sur ce même domaine

Solution :

Suivre les recommendations du site mail-tester :)

Cela m'a conduit à :

Déclarer des enregistrements DNS sur MONDOMAINE pour autoriser mon deuxième serveur à envoyer des mails :

SERVEUR2.MONDOMAINE IN    A   IP-SERVEUR-2
MONDOMAINE.	IN	TXT	"v=spf1 ip4:IP-SERVEUR-2 include:mx.ovh.com"
MONDOMAINE.	IN	SPF	"v=spf1 ip4:IP-SERVEUR-2 include:mx.ovh.com"

Vérifier que le postfix de mon 2eme serveur est identifié avec SERVEUR2.MONDOMAINE

  • maintenant les serveurs SMTP reçevant nos mails savent que le deuxième serveur est autorisé à les envoyé.
  • que le nom de domaine SERVEUR2.MONDOMAINE est cohérent avec qui est déclaré dans postfix
  • ne pas avoir configurer postfix en openrelay, mais ça il faut l'avoir fait exprès

Il faut aussi installer des signatures DKIM en sortant :

mail._domainkey.MONDOMAINE.	IN TXT    ( "v=DKIM1;t=s;k=rsa; p=clepublic" )
  • on aurait pu avoir glustork à la place comme selecteur ! C'est aussi le principe d'avoir X domaines et X sélecteur pour avoir des clés de chiffrement différentes
glustork._domainkey.MONDOMAINE.	IN TXT    ( "v=DKIM1;t=s;k=rsa; p=clepublic" )
  • des outis pour vérifier les DNS existent sur le Web (ici, , ...)
  • mais un petit DIG suffit aussi :
dig mail._domainkey.<domaine>.fr TXT @dnsserver.com

 

ELK - parsing des logs Apache

Rédigé par gorki - - Aucun commentaire

Le problème :

Analyser les logs Apache (entre autre) avec un système de requêtage.

Alors il y a bien l'outil fait à la main, ça marche toujours :) mais je voulais tenter une stack ELK (Elasticsearch Logstash Kibana)

Solution :

Tout d'abord l'installation :

- je suis parti du docker qnib/elk (https://hub.docker.com/r/qnib/elk/).

- auquel j'ajoute le plugin elasticsearch-head pour la visulation des données

- création du docker initial (commité depuis avec le plugin elasticsearch) :

. envir.sh

sudo docker run -t -i --rm -h elk --name sgl-elk --privileged \
    ${DNS_STUFF} ${DEV_MOUNTS} ${LINK} \
    ${HTTP_PORT} ${LS_CONF} ${AP_LOG} \
    -e HTUSER=${HTUSER} -e HTPASSWD=${HTPASSWD} \
    ${ES_PERSIST} qnib/elk:latest bash

- fichier d'environnement (envir.sh) :

# To get all the /dev/* devices needed for sshd and alike:
export DEV_MOUNTS="-v /dev/null:/dev/null -v /dev/urandom:/dev/urandom -v /dev/random:/dev/random"
export DEV_MOUNTS="${DEV_MOUNTS} -v /dev/full:/dev/full -v /dev/zero:/dev/zero"
### OPTIONAL -> if you want to store Elasticsearchs data outside 
export ES_PERSIST="-v ${HOME}/elk/elasticsearch:/data/"
### OPTIONAL -> To use a mapped in configuration directory
# if not used, the default will be used within the container
export LS_CONF="-v ${HOME}/elk/logstash.d/:/etc/logstash/conf.d/"
### OPTIONAL -> map apache2 config into container
export AP_LOG="-v ${HOME}/elk/var/log/apache2/:/var/log/apache2"
### OPTIONAL -> set the external port to something else then 80
export HTTP_PORT="-e HTTPPORT=8080 -p 8080:80 -p 9200:9200 -p 5601:5601"
### OPTIONAL -> To secure kibana and elasticsearch user/passwd could be set
# if a user is set and no passwd, the user will be set as password
export HTUSER=kibana
export HTPASSWD=kibana

 

Utilisation en oneshot :

- je fais du parsing à la demande plutôt que d'utiliser la stack en monitoring de log continu :

bin/logstash -f /etc/logstash/conf.d/10_apache.conf

- un exemple de fichier configuration logstash pour Apache :

input {
  file {
    path => "/var/log/apache2/test.log"
    start_position => "beginning"
    type => "apache"
  }
}

filter {
    if [type] == "apache" {
        grok {
            match => [ "message", "%{COMBINEDAPACHELOG}" ]
            add_tag => ["apachelog"]
        }
        if "apachelog" in [tags]  {
	    date {
    		match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
  	    }
            geoip {
              source => "clientip"
              target => "geoip"
              add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
              add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}"  ]
            }
            mutate {
              convert => [ "[geoip][coordinates]", "float" ]
            }
        }
    }
}

output {
    if [type] == "apache" {
        stdout { codec => rubydebug }
        elasticsearch {
            protocol => "http"
            cluster => "logstash"
        }
    }
}

- ensuite je me connecte sur elasticsearch pour vérifier que les données ont bien été insérées :

http://localhost:9200/_plugin/head/

- puis sur Kibana pour exploiter les logs :

http://localhost:8080 (kibana3)

http://localhost:5601 (kibana4)

 

Edit :

- Utilsation de grok : https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html

- les patterns grok d'ELK : https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patterns

Fil RSS des articles