KrISS feed 8.7 - Un simple et superbe (ou stupide) lecteur de flux. Par Tontof
  • Friday 01 June 2018 - 11:36

    Plus d’un an sans article, oui je sais c’est long mais sinon je ne suis toujours pas mort 🙂 Aujourd’hui un rapide billet expliquant comment configurer un proxy socks5 sous Debian. Après avoir suivi ce rapide mémo vous aurez un configurer un proxy socks5 avec deux types d’identification : user/mot de passe et liste blanche d’ip.

     

    Configurer un proxy socks5 sous Debian : Introduction

    Ici nous utiliserons Dante dans sa version 1.4.x disponible de base sous Debian 9. Si vous êtes toujours sous Jessie vous pouvez essayer cette configuration sous 1.3.x (aucune idée si cela fonctionnera), tenter d’installer Dante via les backports ou alors le compiler vous même.

    J’ai choisi de configurer un proxy avec deux types d’identification car Chrome ne supporte pas l’identification user/mot de passe…(oui oui j’utilise Chrome, je sais c’est le mal).

     

     

    Configurer un proxy socks5 sous Debian : Installation de Dante

    Ici le plus simple, connectez vous en SSH à votre serveur puis lancer la commande suivante

    sudo apt-get install dante-server

     

    L’installation est rapidement effectué et le service devrait essayé de se lancer pour lamentablement foiré. Ne vous inquiétez pas c’est tout à fait normal.

    invoke-rc.d: initscript danted, action "start" failed.
    ● danted.service - SOCKS (v4 and v5) proxy daemon (danted)
    Loaded: loaded (/lib/systemd/system/danted.service; disabled; vendor preset: enabled)
    Active: failed (Result: exit-code) since Fri 2018-06-01 11:45:50 CEST; 20ms ago
    Docs: man:danted(8)
    man:danted.conf(5)
    Process: 24475 ExecStart=/usr/sbin/danted -D (code=exited, status=1/FAILURE)

     

     

    Configurer un proxy socks5 sous Debian : Configuration de dante

    Nous allons maintenant éditer la configuration de dante.

    sudo nano /etc/danted.conf

     

    Modifiez votre configuration (attention certaines lignes sont à commenter pour éviter les redites) afin qu’elle ressemble à celle ci-dessous. N’oubliez pas de remplacer :

    1. eth0 si votre interface réseau est nommée différemment
    2. AAA.AAA.AAA.AAA par l’ip que vous souhaitez autoriser à se connecter.
    3. le port (ici 50000)
    internal: 0.0.0.0 port=50000
    external : eth0
    socksmethod: username none
    user.privileged: root
    user.unprivileged: nobody
    user.libwrap: nobody
    
    # allow everyone from everywhere so long as they auth, log errors
    
    client pass {
        from: AAA.AAA.AAA.AAA/24 port 1-65535 to: 0.0.0.0/0
        log: error # connect disconnect iooperation
        socksmethod: none username
    }
    
    client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: error # connect disconnect iooperation
        socksmethod: username
    }
    
    # allow everyone from everywhere so long as they auth, log errors
    
    socks pass {
        from: AAA.AAA.AAA.AAA/24 port 1-65335 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
        socksmethod: none username
    }
    
    socks pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        command: bind connect udpassociate
        log: error # connect disconnect iooperation
        socksmethod: username
    }

     

    Vous pouvez maintenant relancer dante

    sudo service danted restart

     

    Pour tester votre proxy depuis un autre serveur, utilisez la commande suivante

    curl -v -x socks5://user:mdp@IP.DU.SERVEUR.PROXY:port https://www.noobunbox.net

     

    Si tout se passe bien vous devriez voir ceci

    * TCP_NODELAY set
    * SOCKS5 communication to www.noobunbox.net:443
    * SOCKS5 connect to IPv4 IP.DU.SERVEUR.PROXY (locally resolved)
    * SOCKS5 request granted.
    * Connected to (nil) (IP.DU.SERVEUR.PROXY) port (#0)

     

    Voilà 😉 Amusez vous bien

     

     

    Cet article Configurer un proxy socks5 sous Debian est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Monday 22 May 2017 - 10:31

    Slack est une une plate-forme de communication collaborative assez chouette à utiliser. J’essaye donc d’y intégrer plusieurs outils et donc je me suis demandé comment je pouvais configurer des notifications SSH Slack. Comme vous pouvez vous en douter la réponse se trouve ci-dessous 🙂

     

    Configurer des notifications SSH Slack : Setup Slack

    Avant de « travailler » coté serveur(s), vous allez devoir créer un Wek Hook sur Slack.

    https://votre-domaine.slack.com/apps/manage/custom-integrations

     

    Une fois la manipulation effectuée, récupérez l’URL du Web Hook et conservez la

     

    Configurer des notifications SSH Slack : Configuration serveur(s)

    Maintenant il s’agira de se connecter à toutes les machines qui devront envoyer des notifications, et de créer un script

    sudo nano /etc/ssh/notify.sh

     

    Ajoutez le code suivant en remplacant YOUR_SLACK_WEBHOOK_URL par l’URL récupérée sur Slack

    #!/bin/sh
    if [ "$PAM_TYPE" != "close_session" ]; then 
     url="YOUR_SLACK_WEBHOOK_URL"
     channel="#ssh-logins"
     host="`hostname`"
     content="\"attachments\": [ { \"mrkdwn_in\": [\"text\", \"fallback\"], \"fallback\": \"SSH login: $PAM_USER connected to \`$host\`\", \"text\": \"SSH login to \`$host\`\", \"fields\": [ { \"title\": \"User\", \"value\": \"$PAM_USER\", \"short\": true }, { \"title\": \"IP Address\", \"value\": \"$PAM_RHOST\", \"short\": true } ], \"color\": \"#F35A00\" } ]"
     curl -X POST --data-urlencode "payload={\"channel\": \"$channel\", \"mrkdwn\": true, \"username\": \"ssh-bot\", $content, \"icon_emoji\": \":computer:\"}" $url &
    fi

     

    Rendez le script exécutable avec la commande suivante

    sudo chmod +x /etc/ssh/notify.sh

     

    Puis modifier le fichier /etc/pam.d/sshd en y ajoutant le code suivant (en fin de fichier convient parfaitement)

    session optional pam_exec.so seteuid /etc/ssh/notify.sh

     

    Vous pouvez maintenant recharger la configuration du serveur SSH et effectuer un test en vous connectant

    sudo service ssh reload

     

    Voici le type de notification que vous devriez recevoir

    Configurer des notifications SSH Slack

     

     

    Source

     

    Cet article Configurer des notifications SSH Slack est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Tuesday 25 April 2017 - 21:56

    Aujourd’hui via Touitteur j’ai vu que la nouvelle version Mainline de NGINX, c’est à dire la 1.13.0, introduisait le support natif de TLS 1.3. Je me suis dit que c’était l’occasion de mettre tout ça en pratique. Vous pouvez vous amusez à mettre ça en prod sur vos blogs si ça vous chante.

    Pour ce billet, je vais m’appuyer sur l’excellent script de mon coupaing Nicolas Simond

     

     

    NGINX tls 1.3 : Pré-requis

    Nous allons donc commencer par installer les paquets qui nous permettront de compiler NGINX

    apt-get install libgeoip-dev libxslt-dev libpcre3 libpcre3-dev build-essential zlib1g-dev libbz2-dev libssl-dev tar unzip curl git -y

     

    Ensuite, naviguons vers le repertoire dans lequel nous compilerons notre programme

    cd /usr/src

     

    Téléchargeons la dernière version de NGINX et décompressons là

    wget https://nginx.org/download/nginx-1.13.0.tar.gz
    tar -xaf nginx-1.13.0.tar.gz
    mv nginx-1.13.0 nginx

     

    Nous allons récupérer une version dev d’OpenSSL supportant TLS 1.3 (Le draft 18)

    git clone https://github.com/openssl/openssl.git
    cd openssl
    git checkout tls1.3-draft-18

     

     

    NGINX tls 1.3 : Compilation et installation

    Avant de lancer la compilation de NGINX, nous allons appliquer le patch Dynamic TLS Records

    cd /usr/src/nginx
    wget https://raw.githubusercontent.com/cujanovic/nginx-dynamic-tls-records-patch/master/nginx__dynamic_tls_records_1.11.5%2B.patch
    patch -p1 < nginx__dynamic_tls_records_1.11.5*.patch

     

    Passons maintenant à la premiere étape de la compilation : configure. Ici j’attire votre attention sur le fait que les développeurs de nginx ou d’OpenSSL sont des trolls…si si…. Parce que vous avez beau utilisé des versions de NGINX et d’OpenSSL supportant nativement tls 1.3, il frauda quand meme spécifier que vous souhaitez l’activer.
    troll over 9000

     

    ./configure \
    --http-client-body-temp-path=/usr/local/etc/nginx/body \
    --http-fastcgi-temp-path=/usr/local/etc/nginx/fastcgi \
    --http-proxy-temp-path=/usr/local/etc/nginx/proxy \
    --http-scgi-temp-path=/usr/local/etc/nginx/scgi \
    --http-uwsgi-temp-path=/usr/local/etc/nginx/uwsgi \
    --user=www-data \
    --group=www-data \
    --prefix=/etc/nginx \
    --error-log-path=/var/log/nginx/error.log \
    --http-log-path=/var/log/nginx/access.log \
    --sbin-path=/usr/sbin/nginx \
    --conf-path=/etc/nginx/nginx.conf \
    --with-pcre-jit \
    --with-http_v2_module \
    --with-debug \
    --with-http_stub_status_module \
    --with-http_realip_module \
    --with-http_addition_module \
    --with-http_dav_module \
    --with-http_gzip_static_module \
    --with-http_sub_module \
    --with-http_xslt_module \
    --with-file-aio \
    --with-threads \
    --with-http_ssl_module \
    --with-http_geoip_module \
    --with-ld-opt=-lrt \
    --with-openssl=/usr/src/openssl \
    --with-openssl-opt=enable-tls1_3

     

    Nous pouvons lancer la phase de compilation et l’installation

    make -j $(nproc)
    make install

     

    Si tout se déroule comme prévu voici ce qu’un…

    nginx -V

     

    …devrait vous retourner

    root@noobunbox:/usr/src/openssl$ nginx -V
    nginx version: nginx/1.13.0
    built with OpenSSL 1.1.1-dev xx XXX xxxx
    TLS SNI support enabled
    configure arguments: --http-client-body-temp-path=/usr/local/etc/nginx/body --http-fastcgi-temp-path=/usr/local/etc/n ginx/fastcgi --http-proxy-temp-path=/usr/local/etc/nginx/proxy --http-scgi-temp-path=/usr/local/etc/nginx/scgi --http -uwsgi-temp-path=/usr/local/etc/nginx/uwsgi --user=www-data --group=www-data --prefix=/etc/nginx --error-log-path=/va r/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/ng inx.conf --with-pcre-jit --with-http_v2_module --with-debug --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_dav_module --with-http_gzip_static_module --with-http_sub_module --with-http_ xslt_module --with-file-aio --with-threads --with-http_ssl_module --with-http_geoip_module --with-openssl=/usr/src/op enssl --with-openssl-opt=enable-tls1_3 --with-ld-opt=-lrt

     

     

    NGINX tls 1.3 : Configuration des vhosts

    Nous pouvons enfin passer à l’étape finale, la configuration de vos sites. Il vous suffira de modifier la configuration des protocoles ssl en y ajoutant TLSv1.3 comme ci-dessous

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    

     

    Et d’ajouter les ciphers suivants à votre variable ssl_ciphers

    TLS13-AES-128-GCM-SHA256 TLS13-AES-256-GCM-SHA384 TLS13-CHACHA20-POLY1305-SHA256

     

    Ce qui dans mon cas me donne

    ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-D:ECDHE-RSA-CHACHA20-POLY1305-D:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384';

     

    Il ne vous reste plus qu’à recharger la configuration NGINX

    sudo service nginx reload

     

    Nginx tls 1.3

     

    It’s aliiiiive

     

     

    Cet article Compiler NGINX avec le support de TLS 1.3 est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Tuesday 18 April 2017 - 16:29

    Toujours dans la série de billets concernant la création d’une seedbox, nous allons aborder la création et la configuration d’un bot Telegram Rtorrent. À chaque téléchargement terminé vous recevrez une notification.

     

    Créer et configurer un bot Telegram Rtorrent : Création d’un bot

    Dans un premier temps nous allons créer notre bot, récupérer son token d’identification et récupérer notre ID telegram. Il vous suffit de contacter @botfather.

    Créer et configurer un bot Telegram Rtorrent

     

    Dès l’ouverture de la « conversation » BotFather nous indique la liste des commandes disponibles, dans notre cas c’est la commande « /newbot » qui nous intéresse. Une fois cette dernière rentrée, choisissez un nom pour votre bot.

    Créer et configurer un bot Telegram Rtorrent

     

    Maintenant donnons un nom d’utilisateur à notre bot, ici nbx-rtorrent-test-bot. Vous obtiendrez alors le token d’identification nécessaire, dans cet exemple : 376966659:AAHLmxwmSIs24n12V7URPhkMHmyfnKO2QTE

    Créer et configurer un bot Telegram Rtorrent

     

    Une fois le token de votre bot en votre possession, ouvrez une conversation avec @myidbot, puis rentrez la commande /getid. Via cette dernière vous obtiendrez, comme vous vous en doutez surement, votre ID telegram.

    Créer et configurer un bot Telegram Rtorrent

     

    Notre bot est pret, il ne nous reste qu’à configurer rtorrent.

     

     

    Créer et configurer un bot Telegram Rtorrent : Configuration de rtorrent

    Commençons par créer le script qui utilisera l’api telegram pour vous envoyer les notifications.

    nano ~/.rtorrent-telegram.sh

     

    Copiez et collez le texte suivant en prenant soin de remplacer les variables DESTINATAIRE et TOKEN par votre chat id et le token d’identification de votre bot

    #!/bin/bash
    
    # Remplacer VOTRE_CHAT_ID par votre identifiant Telegram obtenu depuis @myidbot
    # Remplacer XXXXXXXXX:yyyyyyyyyyyyyyyyyyyyy avec le Token de votre Bot créé depuis @BotFather
    
    DESTINATAIRE="VOTRE_CHAT_ID"
    TOKEN="XXXXXXXXX:yyyyyyyyyyyyyyyyyyyyy"
    
    curl -s --data chat_id=$DESTINATAIRE --data-urlencode text="$1 a été téléchargé avec succès !" "https://api.telegram.org/bot$TOKEN/sendMessage" > /dev/null

     

    Modifiez les droits du fichiers afin qu’il puisse être exécuté

    chmod +x ~/.rtorrent-telegram.sh

     

    Maintenant modifiez le fichier de configuration de rtorrent

    nano ~/.rtorrent.rc

     

    Puis ajoutez la ligne de configuration suivante. (Veillez à bien remplacer utilisateur par le nom d’utilisateur concerné)

    system.method.set_key = event.download.finished,botgram,"execute=/home/votre-utilisateur/.rtorrent-telegram.sh,$d.get_name="

     

    Enfin, redémarrez rtorrent via la commande suivante

    sudo service utilisateur-rtorrent restart

     

    Si tout a été configuré correctement, vous devriez recevoir des notifications une fois le téléchargement d’un torrent terminé

    Créer et configurer un bot Telegram Rtorrent

     

     

    Source

     

    Cet article Créer et configurer un bot Telegram Rtorrent est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Monday 17 April 2017 - 17:49

    Oui je sais que je n’ai pas posté de billet depuis quelques mois, mais le site n’est pas mort pour autant ce billet en étant la preuve. Aujourd’hui je vais vous parler d’UptimeRobot qui comme vous le savez déjà vous permet de surveiller la disponibilité de vos sites. Depuis octobre 2016, il est possible via UptimeRobot public status page de créer une page, publique ou privée, de reporting. Comme les développeurs d’UptimeRobot font bien leur travail ils ont incorporé la possibilité d’accéder de configurer l’accès à cette page via un sous-domaine. Ainsi il vous faudra créer un enregistrement CNAME pour le sous-domaine de votre choix et le faire pointer sur stats.uptimerobot.com. Nous allons donc ici voir comment faire cohabiter HTTPS et UptimeRobot public status page.

    Tout d’abord sachez que depuis Février 2017, si vous utilisez une URL personnalisé pour votre page de statut UptimeRobot générera un certificat via Let’s Encrypt. Nous allons commencer par un petit rappel vous expliquant comment configurer une page de statut sur un sous-domaine via Cloudflare (fonctionne aussi avec n’importe quel autre registrar), puis une autre méthode qui vous permettra d’utiliser des mécanismes de sécurité additionnels tel que HPKP ou juste simplement de conserver une configuration HTTPS des plus sécurisées.

     

    HTTPS et UptimeRobot public status page via Cloudflare ou autre

    Si vous utilisez Cloudflare, il vous suffira de créer un enregistrement CNAME, de le faire pointer vers stats.uptimerobot.com.

    HTTPS et UptimeRobot public status page

     

    Si vous choisissez de faire passer le traffic via les serveurs de Cloudflare assurez-vous aussi que votre politique de sécurité concernant les certificats ne soit pas réglée sur Flexible.

    HTTPS et UptimeRobot public status page

     

    Vous devriez maintenant pouvoir accéder sans aucun soucis à votre page de statut en HTTPS

     

     

    HTTPS et UptimeRobot public status page via votre DNS

    Si comme moi vous souhaitez garder la configuration la plus sécurisée qui soit il est tout à fait possible d’utiliser HTTPS et UptimeRobot public status à condition de se servir de NGinx. Il va falloir commencer par créer un enregistrement CNAME chez votre registrar, cependant dans cette configuration faites bien attention à le faire pointer vers votre serveur.HTTPS et UptimeRobot public status page

     

    Créez un virtual host et installez votre certificat TLS, dans cet exemple j’utilise Let’s Encrypt. Maintenant modifions la configuration de notre site

    sudo nano /etc/nginx/sites-enabled/status.noobunbox.net

     

    Dans le bloc server ajoutez les lignes de configuration suivante

     location / {
     proxy_set_header Host $host;
     proxy_pass https://stats.uptimerobot.com;
     }

     

    Maintenant vous pouvez recharger la configuration de votre serveur NGinx

    sudo service nginx reload

     

    Vous pouvez enfin accéder à votre site et voir que tout fonctionne correctement.

    HTTPS et UptimeRobot public status page

     

    Tout en gardant une configuration HTTPS correcte

    HTTPS et UptimeRobot public status page

     

     

    Cet article HTTPS et UptimeRobot public status page est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 09 December 2016 - 21:47

    PHP 7.1 est disponible depuis peu, cette nouvelle version apporte son lot de nouveautés et semble être plus performante. Ci dessous un petit guide vous permettant d’Installer PHP 7.1 sous Debian et Ubuntu.

     

    Attention certains plugins ou certains thèmes avec des frameworks particuliers peuvent ne pas fonctionner correctement sous WordPress avec cette nouvelle version. (je sais de quoi je parle je viens d’en faire les frais…)

     

    Désinstaller PHP 7.0

    Vous pouvez commencer par désinstaller PHP 7.0 en utilisant la commande suivante

    apt-get purge 'php7*'
    

     

     

    Installer PHP 7.1 sous Debian 8 : Configuration du dépot

    Ondřej Surý met à disposition un dépôt permettant de télécharger et d’installer facilement cette nouvelle version de php. Pour cela il vous suffit de rentrer les commandes suivantes

    apt-get install apt-transport-https lsb-release ca-certificates
    wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
    echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list
    apt-get update
    

     

     

    Installer PHP 7.1 sous Ubuntu 14.04 – 16.10 : Configuration du dépot

    Ondřej Surý a aussi crée un dépôt PPA pour les utilisateurs d’Ubuntu, ci dessous les commandes nécessaires

    sudo add-apt-repository ppa:ondrej/php
    sudo apt-get update
    

     

     

    Installer PHP 7.1

    NGinx

    Ci dessous une commande pour installer PHP 7.1 ainsi que quelques dépendances qui pourraient vous être utiles

    apt install --no-install-recommends php7.1 php7.1-fpm php7.1-mysql php7.1-curl php7.1-json php7.1-gd php7.1-mcrypt php7.1-msgpack php7.1-memcached php7.1-intl php7.1-sqlite3 php7.1-gmp php7.1-geoip php7.1-mbstring php7.1-redis php7.1-xml php7.1-zip

     

    N’oubliez pas de modifier la configuration de vos sites afin de mettre à jour le socket d’écoute de PHP-FPM

    /run/php/php7.1-fpm.sock

     

    Apache

    apt install --no-install-recommends php7.1 libapache2-mod-php7.1 php7.1-mysql php7.1-curl php7.1-json php7.1-gd php7.1-mcrypt php7.1-msgpack php7.1-memcached php7.1-intl php7.1-sqlite3 php7.1-gmp php7.1-geoip php7.1-mbstring php7.1-redis php7.1-xml php7.1-zip

     

    Source

     

    Cet article Installer PHP 7.1 sous Debian et Ubuntu est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Sunday 02 October 2016 - 14:19

    Installer Nextcloud correctement n’est pas forcément aussi simple que l’on pourrait le croire. Nous allons donc ici détailler l’installation et la configuration d’un serveur Nextcloud avec chiffrement, authentification double facteur ainsi qu’une mise en cache avec redis.

     

     

    Installer Nextcloud : Pré-requis

    Afin de pouvoir installer et configurer correctement Nextcloud doivent être installés sur votre serveur :

    • Un serveur MySQL : ici MariaDB
    • Un serveur web : ici NGinx
    • php : ici php7
    • Redis : si vous souhaitez profiter du cache

     

     

    Installer Nextcloud : Configuration du serveur MySQL

    Nous allons devoir modifier la configuration de notre serveur MySQL sans quoi il serait impossible d’installer Nextcloud. MySQL conserve un journal des transactions en écritures effectuées (insert et update) et cette journalisation peut s’effectuer selon différents modes :

    1. mode statement : les données sont journalisées sous forme de requêtes (par défaut)
    2. mode row : les données sont journalisées sous forme de lignes
    3. mode mixed : MySQL détermine en fonction du contexte si la journalisation doit se faire en mode statement ou row

    Or Nextcloud requiert que le mode mixte soit activé, modifions alors le fichier de configuration MySQL

    sudo nano /etc/mysql/my.cnf

     

    Dans le bloc [mysqld] ajoutons

    binlog-format=mixed

     

    Redémarrons maintenant MariaDB

    sudo systemctl restart mariadb

     

     

    Installer Nextcloud : Création de la base de données

    Nous allons créer une base de données et un utilisateur MySQL dédiés à l’utilisation de Nextcloud. Dans cette exemple nous utiliserons nextcloud_db comme bdd, nextcloud_user comme utilisateur et nextcloud_password comme mot de passe.

    mysql -u root -p
    <mysql root password>
    mysql> CREATE DATABASE nextcloud_db;
    mysql> GRANT ALL PRIVILEGES ON nextcloud_db.* TO 'nextcloud_user'@'localhost'
     -> IDENTIFIED BY 'nextcloud_password';
    mysql> FLUSH PRIVILEGES;

     

     

    Installer Nextcloud : Configuration du serveur web

    Passons maintenant à la configuration de NGinx. Commencons par ajouter un vhost

    sudo nano /etc/nginx/sites-enabled/cloud.mondomaine.tld
    

     

    Copions puis collons la configuration suivante dans notre nouveau vhost. N’oubliez pas de la modifier en fonction de vos besoins et de votre version de NGinx.

    #------------------------------------------------------------------------
    # REDIRECTION HTTPS
    #
    
    server {
     listen 80;
     server_name cloud.mondomaine.tld;
     return 301 https://cloud.mondomaine.tld$request_uri;
    
     location '/.well-known/acme-challenge' {
     root /var/www/html/www.mondomaine.tld/;
     allow all;
     try_files $uri /$1;}
    
     }
    
    #------------------------------------------------------------------------
    # BLOCK SERVEUR HTTPS
    #
    server {
    
     listen 443 ssl http2;
     server_name cloud.mondomaine.tld;
     root /var/www/html/cloud.mondomaine.tld;
     index index.php index.html index.htm;
    
    
    #------------------------------------------------------------------------
    # SSL
    #
    
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_ecdh_curve secp384r1;
     ssl_session_timeout 1d;
     ssl_session_cache shared:SSL:50m;
     ssl_session_tickets off;
     ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-D:ECDHE-RSA-CHACHA20-POLY1305-D:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384';
     ssl_prefer_server_ciphers on;
     ssl_certificate /etc/nginx/ssl/cloud.mondomaine.tld/privatekey.key;
     ssl_certificate_key /etc/nginx/ssl/cloud.mondomaine.tld/chain.pem;
     ssl_trusted_certificate /etc/nginx/ssl/cloud.mondomaine.tld/chain.pem;
    
     ssl_stapling on;
     ssl_stapling_verify on;
     resolver 8.8.4.4 8.8.8.8 valid=300s;
     resolver_timeout 5s;
    
     add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload";
     add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" always;
     add_header X-Content-Type-Options nosniff always;
     add_header X-Xss-Protection "1; mode=block" always;
     add_header X-Robots-Tag none;
     add_header X-Download-Options noopen;
     add_header X-Permitted-Cross-Domain-Policies none;
    
    #------------------------------------------------------------------------
    # PHP
    #
     location = /robots.txt {
     allow all;
     log_not_found off;
     access_log off;
     }
    
     # The following 2 rules are only needed for the user_webfinger app.
     # Uncomment it if you're planning to use this app.
     #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
     #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
     # last;
    
     location = /.well-known/carddav {
     return 301 $scheme://$host/remote.php/dav;
     }
     location = /.well-known/caldav {
     return 301 $scheme://$host/remote.php/dav;
     }
    
     # set max upload size
     client_max_body_size 512M;
    
    
     # Disable gzip to avoid the removal of the ETag header
     gzip off;
    
     # Uncomment if your server is build with the ngx_pagespeed module
     # This module is currently not supported.
     #pagespeed off;
    
     error_page 403 /core/templates/403.php;
     error_page 404 /core/templates/404.php;
    
     location / {
     rewrite ^ /index.php$uri;
     }
    
     location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
     deny all;
     }
     location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
     deny all;
     }
    
     location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
     include fastcgi_params;
     fastcgi_split_path_info ^(.+\.php)(/.*)$;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     fastcgi_param PATH_INFO $fastcgi_path_info;
     fastcgi_param HTTPS on;
     #Avoid sending the security headers twice
     fastcgi_param modHeadersAvailable true;
     fastcgi_param front_controller_active true;
     fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
     fastcgi_intercept_errors on;
     fastcgi_request_buffering off;
     }
    
     location ~ ^/(?:updater|ocs-provider)(?:$|/) {
     try_files $uri/ =404;
     index index.php;
     }
    
     location ~* \.(?:css|js)$ {
     try_files $uri /index.php$uri$is_args$args;
     add_header Cache-Control "public, max-age=7200";
     access_log off;
     }
    
     location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
     try_files $uri /index.php$uri$is_args$args;
     # Optional: Don't log access to other assets
     access_log off;
     }
    
    #------------------------------------------------------------------------
    # LETSENCRYPT
    #
    
     location '/.well-known/acme-challenge' {
     root /var/www/html/www.mondomaine.tld/;
     allow all;
     try_files $uri /$1;}
    }
    

     

     

    Installer Nextcloud : Téléchargement de Nextcloud

    Téléchargeons et décompressons Nextcloud à la racine de notre serveur web puis renommons le dossier Nextcloud en fonction de nos besoins.

    cd /var/www/html/
    sudo wget https://download.nextcloud.com/server/releases/nextcloud-10.0.1.zip
    sudo unzip nextcloud-10.0.1.zip
    sudo mv nextcloud cloud.mondomaine.tld

     

    Accordons les droits à notre serveur web sur ce dossier

    sudo chown -R www-data.www-data /var/www/html/cloud.mondomaine.tld

     

     

    Installer Nextcloud : Installation de Nextcloud

    Connectons nous sur notre domaine Nextcloud tel que configuré sur notre vhost NGinx. Choisissons un nom d’utilisateur et un mot de passe pour l’administrateur du serveur puis indiquons les paramètres de connexion à notre base de données

    installer nextcloud

     

     

    Installer Nextcloud : Optimiser Nextcloud avec Redis

    Nous allons à présent configurer redis comme serveur de cache pour Nextcloud, nous devons donc modifier la configuration de notre serveur Nextcloud

    sudo nano /var/www/html/cloud.loktby.me/config/config.php

     

    A la fin de ce fichier ajoutons avant la dernière ligne ); le code suivant

    'memcache.local' => '\\OC\\Memcache\\Redis',
    'filelocking.enabled' => 'true',
    'memcache.distributed' => '\\OC\\Memcache\\Redis',
    'memcache.locking' => '\\OC\\Memcache\\Redis',
    'redis' =>
    array (
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0,
    'dbindex' => 0,
    ),

     

    Enfin vérifiez que tout fonctionne correctement via l’interface cli de redis

    sudo redis-cli monitor

     

    En parallèle connectez vous à votre instance de NextCloud. Si tout fonctionne correctement vous devriez voir en temps réel votre serveur redis répondre a des requêtes depuis le cache.

    root@noobunbox:~$ redis-cli monitor
    OK
    1475405848.235951 [0 127.0.0.1:47048] "GET" "xxxxxxxxxxxxxxxxx/AutoloaderOC_User"
    1475405848.241654 [0 127.0.0.1:47048] "GET" "xxxxxxxxxxxxxxxxx/AutoloaderOC_Hook"
    1475405848.246273 [0 127.0.0.1:47048] "GET" "xxxxxxxxxxxxxxxxx/AutoloaderOC_Helper"
    1475405848.247115 [0 127.0.0.1:47048] "GET" "xxxxxxxxxxxxxxxxx/AutoloaderOC_Response"
    1475405848.248164 [0 127.0.0.1:47048] "GET" "xxxxxxxxxxxxxxxxx/AutoloaderOC_Defaults"

     

     

    Installer Nextcloud : Mise en place du chiffrement

    Nextcloud nous permet de chiffrer les données, coté serveur seulement. Afin de configurer le chiffrement ajoutons une application.

    installer nextcloud

     

    Naviguons vers l’onglet Désactivées et activons l’extension Default encryption module

    Installer Nextcloud

     

    Une fois l’extension activée rendons nous dans le panel d’administration puis naviguons vers l’onglet Encryption. Enfin cochons la case Activer le chiffrement côté serveur.

    Installer Nextcloud

     

    Déconnectons et reconnectons nous afin d’initialiser nos clefs. A noter qu’une fois reconnecté vous pouvez si vous le souhaitez configurer une clé de récupération, c’est à dire une clé supplémentaire utilisée pour chiffrer les fichiers. Elle permet de récupérer les fichiers des utilisateurs s’ils oublient leur mot de passe (si et seulement ils activent l’option Activer la récupération du mot de passe sur leur compte).

     

     

    Installer Nextcloud : Mise en place de l’authentification double facteur

    Afin de mieux sécuriser notre installation nous allons mettre en place une authentification double facteur sur notre serveur Nextcloud. Commençons donc par ajouter une nouvelle application. Puis naviguons vers l’onglet Tool et activons l’extension TOTP TwoFactor (Google Authenticator)

    installer nextcloud

     

    Désormais chaque utilisateur utiliser la double authentification après l’avoir activée dans les options de son compte

    installer nextcloud

     

    Cet article Installer Nextcloud avec chiffrement, 2FA et cache Redis est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 22 September 2016 - 17:33

    Nous allons ici optimiser WordPress avec redis, un outil open source permettant de maintenir des bases de données en mémoire (NoSQL) et de mettre des objets en cache. Son principal avantage est sa rapidité.

     

     

    Optimiser WordPress avec Redis : Installation de Redis

    Afin de pouvoir utiliser redis pour la mise en cache d’objets avec WordPress nous allons installer deux paquets : le serveur redis ainsi qu’une extension php7.0 permettant de à des applications php de communiquer avec redis.

    sudo apt-get install redis-server php7.0-redis
    

     

     

    Optimiser WordPress avec Redis : Configurer la mise en cache

    Le serveur redis installé nous allons le configurer pour mettre en place un cache. Commencez par modifier la configuration de redis

    sudo nano /etc/redis/redis.conf
    

     

    Ajoutez ces deux lignes de configuration.

    maxmemory 256mb # Mémoire maximum utilisée par redis à modifier selon les capacités de votre serveur
    maxmemory-policy allkeys-lru # Redis remplacera les clés les moins récentes afin de garder en mémoires les données les plus récemment utilisées
    

     

     

    Optimiser WordPress avec Redis : Installation du script de mise en cache

    Si vous préférez utiliser un plugin WordPress vous pouvez utiliser Redis Object Cache (merci à Thomas)

    Téléchargez le script

    wget https://github.com/ericmann/Redis-Object-Cache/raw/master/object-cache.php

     

    Déplacez le script vers le répertoire ou est installé wordpress

    sudo mv object-cache.php /var/www/html/repertoire-wordpress/wp-content/

     

     

    Optimiser WordPress avec Redis : Configuration de WordPress

    Éditez le fichier de configuration de WordPress

    sudo nano /var/www/html/repertoire-wordpress/wp-config.php

     

    Si vous souhaitez profiter des fonctions de mise en cache de wordpress en plus de la mise en cache d’objets assurez vous que la configuration suivante soit présente

    define('WP_CACHE', true);

     

    La constante WP_CACHE_KEY_SALT doit obligatoirement être configurée afin d’ajouter un préfixe à toutes les clés du cache utilisée par le plugin. Ainsi si vous hébergez plusieurs instances de WordPress assurez vous que chacune d’entre elles ait un sel unique.

    define('WP_CACHE_KEY_SALT', 'mondomain.tld');

     

     

    Optimiser WordPress avec Redis : Fin de l’installation

    Vous pouvez maintenant redémarrer tous les services impactées par cette nouvelle configuration

    sudo service redis-server restart
    sudo service nginx restart ou sudo service apache2 restart
    sudo service php7.0-fpm

     

    Maintenant vérifiez que tout fonctionne correctement via l’interface cli de redis

    sudo redis-cli monitor

     

    En parallèle visitez quelques pages de votre blog. Si tout fonctionne correctement vous devriez voir en temps réel votre serveur redis répondre a des requêtes depuis le cache.

    OK
    1474557797.503200 "monitor"
    1474557797.503288 [0 127.0.0.1:55601] "GET" "wp_:options:alloptions"
    1474557797.503438 [0 127.0.0.1:55601] "EXISTS" "wp_:options:notoptions"
    1474557797.503491 [0 127.0.0.1:55601] "GET" "wp_:options:notoptions"
    1474557797.503544 [0 127.0.0.1:55601] "EXISTS" "wp_:options:alloptions"
    1474557797.503595 [0 127.0.0.1:55601] "GET" "wp_:options:alloptions"
    1474557797.503837 [0 127.0.0.1:55601] "EXISTS" "wp_user_meta:4874"
    1474557797.503893 [0 127.0.0.1:55601] "GET" "wp_user_meta:4874"
    

     

    Sources

     

    Cet article Optimiser WordPress avec Redis est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Tuesday 20 September 2016 - 03:56

    Je viens de mettre en place un Résolveur DNSCrypt public. Celui-ci est accessible en IPv4 seulement pour le moment. L’IPv6 arrivera plus tard. Vous pouvez aussi si vous le souhaitez vous servir de ce résolveur comme d’un simple serveur DNS (connexion sur le port 53).

     

    Résolveur DNSCrypt public : Késséssé ?

    Lorsque vous vous connectez à un domaine votre ordinateur envoi une requête à un serveur DNS, requête contenant le FDQN que vous souhaitez consulter, qui lui renvoie l’adresse IP correspondante. La demande et la réponse sont transmises en clair ce qui signifie donc qu’un attaquant peut non seulement conserver un historique de tous les sites que vous avez consulté mais aussi modifier les réponses faites par le serveur DNS (DNS Spoofing). Plutôt flippant n’est-ce pas ?

    Heureusement DNSCrypt vous permet de remédier à cela en chiffrant vos requêtes DNS.  Des clients DNSCrypt sont disponibles sur tous les systèmes d’exploitation et dans certains directement depuis votre routeur.

     

     

    Résolveur DNSCrypt public : Informations de connexion

    Nom : dns.noobunbox.net
    IPv4 : 163.172.170.36:4434
    IPv6 : [2001:bc8:4400:2100::20:415]:4434 (DNSCrypt indisponible pour le moment)

    Provider name : 2.dnscrypt-cert.dns.noobunbox.net
    Clé publique : 70B3:ECC0:EF16:48D2:7F65:BEC2:25A2:0201:2F36:D777:E054:9BF3:F4B3:DF95:B960:4B4D

     

     

    Résolveur DNSCRYPT public : Fonctionnalités

    • Résolveur DNS basé en France
    • Entièrement neutre
    • Validation DNSSEC
    • Aucun log
    • Statistiques sur l’utilisation bientôt disponibles

     

    Résolveur DNSCRYPT public : Transparence

    Dans un soucis de transparence vous trouverez ci-dessous la configuration du serveur DNS (unbound)

    server:
     interface: 0.0.0.0
     interface: ::0
     access-control: 0.0.0.0/0 allow
     access-control: ::/0 allow
     auto-trust-anchor-file: "/var/lib/unbound/root.key"
     root-hints: "/etc/unbound/root.hints"
     verbosity: 0
     qname-minimisation: yes
    
     statistics-interval: 0
     extended-statistics: yes
     statistics-cumulative: yes
    
     num-threads: 2 
     msg-cache-slabs: 4
     rrset-cache-slabs: 4
     infra-cache-slabs: 4 
     key-cache-slabs: 4 
     rrset-cache-size: 100m
     msg-cache-size: 50m
     outgoing-range: 465
     so-rcvbuf: 4m
     so-sndbuf: 4m
     port: 53
     do-ip4: yes
     do-ip6: yes
     do-udp: yes
     do-tcp: yes
     do-daemonize: yes
     hide-identity: yes
     hide-version: yes
     harden-glue: yes
     harden-dnssec-stripped: yes

     

    La configuration unbound, telle que ci-dessous, permet seulement d’effectuer des statistiques sur l’utilisation du serveur DNS. Ces statistiques sont totalement anonymes et seront bientôt disponibles en ligne.

     statistics-interval: 0
     extended-statistics: yes
     statistics-cumulative: yes

     

    Si vous souhaitez participer et me permettre de mettre en place de nouveaux serveurs vous pouvez soutenir ce projet via la plateforme Liberapay

    Faire un don
     

     

    Cet article Résolveur DNSCrypt disponible pour tous est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Tuesday 13 September 2016 - 12:29

    Comme je l’ai déjà répété à de nombreuses reprises l’authentification forte (2FA) c’est la vie et je vous recommande fortement de la mettre en place dès lors que cette option vous est proposée. Nous allons donc aujourd’hui voir comment mettre en place une authentification double facteur avec une Yubikey sur un serveur SSH.

     

     

    Authentification forte (2FA) Yubikey SSH : Vous avez dit Yubikey ?

    Une Yubikey est un dispositif d’authentification USB vous permettant d’utiliser différentes méthodes d’authentification : FIDO U2F, Yubico-OTP, OATH-OTP, OATH-HOTP, OATH-TOTP, OpenPGP, et PIV. Lorsqu’elle est connectée à votre ordinateur la Yubikey simule un clavier USB. Deux méthodes d’authentification sont paramétrables via ses deux slots de configuration, elle pourra réagir à une stimulation physique (pression du bouton) ou automatiquement (via des logiciels). Si vous souhaitez en savoir plus sur le fonctionnement des Yubikeys je vous conseille cet article rédigé par Aeris et le wiki de Maxime de Roucy.

     

     

    Authentification forte (2FA) Yubikey SSH : Clé API

    Avant de pouvoir commencer nous allons devoir récupérer une clé d’API Yubico. Ouvrez cette page, renseignez votre email, générez un code OTP en appuyant sur le bouton de votre Yubikey et validez.

    Sauvegardez les identifiants qui s’affichent.

     

     

    Authentification forte (2FA) Yubikey SSH : Installation et configuration

    Commençons par nous connecter à notre serveur puis récupérons la librairie requise en lançant la commande

    sudo apt-get install libpam-yubico
    

     

    Maintenant ouvrez le fichier /etc/pam.d/sshd

    sudo nano /etc/pam.d/sshd

     

    Recherchez  @include common-auth puis juste en-dessous ajoutez

    auth required pam_yubico.so id=mon-id key=ma-cle url=https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s

     

     

    Authentification forte (2FA) Yubikey SSH : Lien Yubikey / Utilisateur

    Maintenant que tout est en place nous allons devoir faire le lien entre chaque Yubikey et chaque utilisateur. Ce lien fonctionne sous le même modèle que pour les clés SSH cependant les informations doivent etre stockées dans ~/.yubico/authorized_yubikeys au format suivant utilisateur:yubikeyid1:yubikeyid2.

    Pour récupérer votre yubikeyid lancez la commande suivante, puis appuyez sur le bouton de votre Yubikey

    read -p "Enter a YubiKey OTP: " s && echo 'The key id is' ${s:0:12}

     

    Exemple :

    root@noobunbox:~# read -p "Enter a YubiKey OTP: " s && echo 'The key id is' ${s :0:12}
    Enter a YubiKey OTP: vvukdhrutoplhftvrucnhgnvjnjjkfbeeeibbhejckie
    The key id is vvukdhrutopl

     

    Maintenant créons le fichier nécessaire, ici pour l’utilisateur root

    mkdir ~/.yubico
    nano ~/.yubico/authorized_yubikeys

     

    Nous pouvons maintenant faire le lien entre notre utilisateur, root, et notre yubikeyid, vvukdhrutopl, en insérant dans ce fichier

    root:vvukdhrutopl

     

    Relancez la configuration du serveur SSH

    sudo service sshd reload

     

    Une fois les modifications effectuées ne fermez pas votre connexion SSH, ouvrez en une seconde et vérifiez que tout fonctionne.

     

     

    Authentification forte (2FA) Yubikey SSH : Gestion authentification par utilisateur

    Maintenant quelques problèmes peuvent se poser :

    • Que faisons-nous si nous avons avez d’autres users SSH se connectant au serveur n’ayant pas ou ne pouvant pas utiliser de Yubikey (rsync par exemple) ?
    • Je suis un fou, je veux m’authentifier avec mot de passe + yubikey + clé SSH, je fais comment ?

     

    Hé bien c’est assez simple puisqu’il suffit de modifier la configuration du serveur SSH.

    sudo nano /etc/ssh/sshd_config

     

    Pour un utilisateur scripts nous souhaitons utiliser seulement une authentification par clé, il nous suffira d’ajouter les lignes de configuration suivante

    Match User scripts
    AuthenticationMethods publickey

     

    Pour l’utilisateur root nous souhaitons utiliser une authentification mot de passe + yubikey et par clé

    Match User root
    AuthenticationMethods publickey,keyboard-interactive

     

     

    Authentification forte (2FA) Yubikey SSH : Démo

    Ci-dessous une petite démo d’une authentification sur un serveur avec publickey + mot de passe / yubikey
     
     

    Sources

     

    Cet article Authentification forte (2FA) Yubikey SSH est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 19 August 2016 - 12:12

    J’avais déjà publié il y a quelques temps un billet assez détaillé vous expliquant comment mieux sécuriser votre installation WordPress et depuis je me suis dit que l’on pouvait encore faire mieux. Nous allons donc nous attacher à améliorer la sécurité des mots de passe WordPress.

    Tout d’abord permettez moi de faire le gros lourd mais commencez par n’utiliser qu’un seul mot de passe par site, ensuite générez des mots de passe complexes et enfin mettez en place une double authentification dès que vous en avez la possibilité.

     

    Comment les mots de passe WordPress sont-ils chiffrés ?

    Avant d’être stocké dans votre base de donnée votre mot de passe est haché.Ce hash est obtenu par l’intermédiaire d’un framework appelé phpass.

    phpass utilise 3 éléments pour hacher votre mot de passe :

    • Une fonction de hachage : blowfish, DES ou MD5,
    • Un sel (une donnée supplémentaire générée aléatoirement et propre à chaque mot de passe)
    • Un nombre d’itérations (la fonction de hachage sera répétée X fois)

    WordPress utilise par défaut MD5 comme fonction de hachage (répétée 8192 fois) pour la simple et unique raison qu’elle est supportée par toutes les versions de PHP (depuis PHP 3.0).

     

     

    Pourquoi faut-il améliorer le chiffrement des mots de passe WordPress ?

    Maintenant pour vous donner un ordre d’idée dites vous un GPU Nvidia GTX 1080 Founders Edition est capable de tester:

    • 24809,8 MH/s (24809,8 millions de mots de passe par seconde) pour du MD5
    • 6857.6 kH/s (6857.6 milliers mots de passe par seconde) pour du phpassMD5Wordpress
    • 55195 H/s (55195 mots de passe par seconde) pour du SHA512Crypt (Drupal7)

     

     

    Comment améliorer le chiffrement des mots de passe WordPress ?

    On peut remplacer le chiffrement utilisé par défaut sous WordPress par bcrypt via l’installation d’un plugin. Ce qui implique d’avoir  :

    • Premièrement un WordPress à jour : bcrypt n’est supporté que depuis la version 4.4. Ce qui est loin d’être grave puisque nous en sommes à la 4.6
    • Deuxièmement une version de PHP >= 5.5.0

     

     

    Quel plugin me permet d’utiliser bcrypt pour chiffrer les mots de passe WordPress ?

    J’utilise depuis peu un plugin développé par Roots.io.

    Pour l’installer rien de plus simple il vous suffit de récupérer ce fichier ce fichier puis de l’uploder dans le dossier wp-content/mu-plugins/.Pourquoi dans mu-plugins et pas comme un plugin « normal » ? Simplement parce que les mu-plugins (must-use plugin) ne sont pas désactivables dans l’interface d’administration de WordPress ce qui vous évite de les désactiver accidentellement.

    Une fois installé, le chiffrement de votre mot de passe sera mis à jour après que vous vous soyez reconnecter sur WordPress. Enfin sachez que si pour une raison X ou Y (mauvaise en tout cas) vous décidiez de supprimer ce plugin, le chiffrement de votre mot de passe ne sera PAS modifié et vous ne rencontrerez aucun problème pour vous identifier.

     

    Sources :

     

    Cet article Améliorer la sécurité des mots de passe WordPress est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 19 August 2016 - 03:37

    Vous vous souvenez de mon article concernant HubicFuse ? Hé bien sachez mesdames et messieurs qu’il existe un outil encore plus intéressant nommé Rclone. Nous allons donc mettre en place une sauvegarde sur Hubic avec Rclone.

     

    Sauvegarde sur Hubic avec Rclone : Rclone c’est quoi ?

    Rclone c’est tout d’abord le Rsync du cloud, donc un outil, en ligne de commande, vous permettant de synchroniser vos fichiers sur :

    • Google Drive
    • Amazon S3
    • Openstack Swift / Rackspace cloud files / Memset Memstore
    • Dropbox
    • Google Cloud Storage
    • Amazon Drive
    • Microsoft One Drive
    • Hubic
    • Backblaze B2
    • Yandex Disk
    • The local filesystem

    Pas mal non ? Mais comme indiqué dans le titre de l’article nous allons nous concentrer sur Hubic

     

     

    Sauvegarde sur Hubic avec Rclone : Installation d’Rclone

    Commencez donc par télécharger la dernière version du programme

    wget http://downloads.rclone.org/rclone-current-linux-amd64.zip

     

    Nous allons maintenant extraire les fichiers puis installer Rclone

    unzip rclone-current-linux-amd64.zip
    cd rclone-v1.32-linux-amd64
    sudo cp rclone /usr/sbin/
    sudo chown root:root /usr/sbin/rclone
    sudo chmod 755 /usr/sbin/rclone

     

    Installons le man page (l’aide)

    sudo mkdir -p /usr/local/share/man/man1
    sudo cp rclone.1 /usr/local/share/man/man1/
    sudo mandb

     

     

    Sauvegarde sur Hubic avec Rclone : Tunnel SSH et Proxy

    Pour récupérer son jeton d’authentification Rclone va momentanément lancer un serveur web et nous devrons nous connecter à l’adresse suivante : http://127.0.0.1:53682/. Nous allons donc configurer un tunnel SSH afin de pouvoir atteindre cette page.

     

    Sauvegarde sur Hubic avec Rclone : Configuration du tunnel SSH

    Ouvrez votre client SSH préféré (ici Putty), chargez la configuration de votre serveur. Puis naviguez vers SSH > Tunnels

    tunnel_ssh-01

     

    Indiquons un numéro de port source, dans cet exemple 5050, et choisissons une destination Dynamic puis cliquez sur Add

    tunnel_ssh-02

     

    Une fois la connexion correctement configurée cliquons sur Open et identifions nous sur notre serveur.

     

    Sauvegarde sur Hubic avec Rclone : Configuration de votre navigateur

    Afin de pouvoir profiter de ce tunnel SSH nous allons devoir configurer notre navigateur, dans notre cas Firefox.

    Rendez vous dans les options du navigateur, puis naviguez vers l’onglet Avancé > Réseau.

    Cliques sur Paramètres afin de configurer la façon dont Firefox se connecte à Internet.

    Configurons notre proxy SOCKS de comme ci-dessousproxy-socks

     

     

    Sauvegarde sur Hubic avec Rclone : Configuration Hubic

    Rclone étant installé, le tunnel SSH configuré, nous allons maintenant configurer l’accès à notre compte Hubic.

    Commencons la configuration en indiquant à Rclone que nous souhaitons ajouter une nouvelle connexion

    sudo rclone config

     

    Rclone vous propose alors différentes options, ici choisissons « New Remote »

    No remotes found - make a new one
    n) New remote
    s) Set configuration password
    q) Quit config
    n/s/q> n

     

    Donnons maintenant un nom à notre connexion, dans mon cas noobunbox-hubic

    name> noobunbox-hubic

     

    Rclone vous affiche maintenant la liste de tous les type de cloud avec il est compatible, ici nous souhaitons ajoutez un compte Hubic, c’est donc le numéro 7

    Type of storage to configure.
    Choose a number from below, or type in your own value
    [..]
     7 / Hubic
     \ "hubic"
    [..]
    Storage> 7

     

    Lors des deux prochaines options de configuration, n’indiquons rien comme demandé.

    Hubic Client Id - leave blank normally.
    client_id>
    Hubic Client Secret - leave blank normally.
    client_secret>

     

    Attention ici c’est l’étape piège. Il est impératif de choisir le mode auto config sans quoi nous ne pourrions pas obtenir de jeton d’authentification via notre tunnel SSH. Nous répondons donc Yes

    Remote config
    Use auto config?
     * Say Y if not sure
     * Say N if you are working on a remote or headless machine
    y) Yes
    n) No
    y/n>y

     

    Rclone va maintenant nous demander de nous connecter à l’adresse http://127.0.0.1:53682/auth afin de pouvoir avoir accès à notre compte Hubic

    If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth
    Log in and authorize rclone for access
    Waiting for code...

     

    Ouvrons donc cette page dans Firefox.

    rclone-hubic-01

     

     

    Connectons-nous vos identifiants de connexion Hubic. Et si tout fonctionne bien, voici ce que vous devriez voir dans notre navigateur

     

    rclone-hubic-02

     

    Maintenant dans notre terminal, Rclone nous informe que la connexion a été effectuée et nous demande de confirmer. Validons

    [noobunbox-hubic]
    client_id =
    client_secret =
    token = {"votre jeton d'identification"}
    y) Yes this is OK
    e) Edit this remote
    d) Delete this remote
    y/e/d> Y

     

    Rclone vous donne maintenant la liste des connexions configurées. Nous pouvons quitter.

    Name                   Type
    ====                   ====
    noobunbox-hubic        hubic
    
    e) Edit existing remote
    n) New remote
    d) Delete remote
    s) Set configuration password
    q) Quit config
    e/n/d/s/q>q

     

     

    Sauvegarde sur Hubic avec Rclone : Synchronisation des fichiers

    Rclone étant configuré, nous allons pouvoir passer à la synchronisation de nos fichiers.

    Pour synchroniser un répertoire sur Hubic, utilisez la commande suivante

    rclone sync repertoire-local connexion-hubic:default/repertoire-hubic

     

    Dans mon cas, le répertoire local contenant mes sauvegardes est hubic, le nom de la connexion est noobunbox-hubic et je souhaite que mon dossier de sauvegarde sur Hubic se nomme sauvegarde-noobunbox. Je lance donc la commande suivante

    sudo rclone sync hubic noobunbox-hubic:default/sauvegarde-noobunbox

     

    Rclone synchronise nos fichiers

    root@noobunbox:~$ rclone sync hubic noobunbox-hubic:default/sauvegarde-noobunbox
    2016/08/19 03:15:02 Hubic Swift container default path sauvegarde-noobunbox/: Waiting for checks to finish
    2016/08/19 03:15:02 Hubic Swift container default path sauvegarde-noobunbox/: Waiting for transfers to finish
    2016/08/19 03:15:08 Waiting for deletions to finish
    2016/08/19 03:15:08
    Transferred: 48 Bytes (7 Bytes/s)
    Errors: 0
    Checks: 0
    Transferred: 3
    Elapsed time: 6.3s

     

    Vérifions que nos fichiers soient bien présents sur Hubic

    rclone-hubic-03

     

    Voilà tout fonctionne donc comme prévu. Dans un prochain billet j’aborderais la mise en place d’une sauvegarde chiffrée sur Hubic avec Rclone

     

    Source

     

    Cet article Sauvegarde sur Hubic avec Rclone est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 29 July 2016 - 15:59

    Avant de plonger dans le vif du sujet, c’est à dire sécuriser SSH avec SSHFP, quelques explications sont nécessaires.

    Tout d’abord parlons du système SSH, celui-ci utilise un système d’empreinte de clé pour vérifier l’authenticité du serveur lorsque le client se connecte. Lors des futures connexions, l’empreinte de la clé sauvegardé est vérifiée. Le client SSH vous avertira si l’empreinte stockée localement diffère de l’empreinte reçue lors de futures tentatives de connexion. (documentation freebsd)

    Pour faire court : le client vérifie que le serveur auquel vous vous connectez soit le bon. Génial, non ? Hé bien non puisqu’en pratique presque personne ne le fait.

    SSHFP permet donc à un administrateur de déclarer dans son DNS (qu’il faudra avoir protégé par DNSSEC sinon cette protection sera moins efficace) l’empreinte de ses serveurs SSH.

     

     

    Composition de l’enregistrement

    Un enregistrement SSHFP se compose de 3 éléments :

    1. L’algorithme : dépend du type de clés SSH : RSA (1), DSA (2), ECDSA (3), ED25519 (4)
    2. Le type d’empreinte : SHA-1 (1) ou SHA-256 (2)
    3. L’empreinte (hexadécimale) du serveur SSH

     

     

    Générer des enregistrements SSHFP

    Pour générer vos enregistrements SSHFP rien de plus simple, il vous suffit d’utiliser la commande suivante

    ssh-keygen -r subdomain.domain.tld

     

    N’acceptant que des authentifications par clé Ed25519 sur mon serveur j’ai choisi d’utiliser l’enregistrement suivant

    root@noobunbox.net:~$ ssh-keygen -r www.noobunbox.net
    www.noobunbox.net IN SSHFP 4 1 33f75f87a4dc9e1084d0aeb91e92e8fbb3a3f676
    

     

     

    Test et configuration du client

    Une fois les modifications au niveau du DNS effectuées et propagées, connectez vous à votre serveur SSH via la commande suivante

    ssh -o "VerifyHostKeyDNS yes" subdomain.domain.tld -v

     

    Si DNSSEC et SSHFP sont correctement configurés sur votre domaine vous devriez voir les lignes suivantes

    debug1: found 2 secure fingerprints in DNS
    debug1: matching host key fingerprint found in DNS

     

    Si vous voyez l’erreur No matching host key fingerprint found in DNS cela peut signifier que vos enregistrements SSHFP sont incorrects ou non propagés
    Si vous voyez l’erreur DNS lookup error: data does not exist ainsi que The authenticity of host 'subdomain.domain.tld (XXX.XXX.XXX.XXX)' can't be established., cela signifie que votre resolveur DNS ne prend pas en charge DNSSEC ou que DNSSEC est mal configuré ou non configuré.

     

    Afin de ne pas avoir à utiliser l’option « VerifyHostKeyDNS yes » à chaque connexion, modifiez le fichier de configuration du client ssh

    sudo nano /etc/ssh/ssh_config

     

    Afin d’y ajouter

    VerifyHostKeyDNS yes

     

    Puis relancez le service SSH

    /etc/init.d/ssh reload

     

     

    Source

     

    Cet article Sécuriser SSH avec un enregistrement SSHFP est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 28 April 2016 - 22:19

    Il est tout à fait possible de créer des templates de vm sous Virtualbox. L’opération est meme plus simple que sous VMware Workstation.

     

     

    Créer des templates de VM sous Virtualbox : Création du template

    Commençons par modifier les paramètres de la machine qui nous servira de template.

    Créer des templates de VM sous Virtualbox

     

    Dans l’onglet Stockage, assurez vous qu’aucun fichier iso ne soit monté

    Créer des templates de VM sous Virtualbox

     

    Dans l’onglet Son, désactivez le pilote son puis validez en cliquant sur OK

    Créer des templates de VM sous Virtualbox

     

    Maintenant faites un nouveau clic droit sur votre machine virtuelle puis cliquez sur Exporter un appareil virtuel

    Créer des templates de VM sous Virtualbox

     

    Passez en mode Expert, remplissez les champs comme bon vous semble, puis choisissez un dossier et nom de sauvegarde. Lorsque vous êtes prêt cliquez sur Exporter.

    Créer des templates de VM sous Virtualbox

     

    Attendez maintenant la fin de l’opération

    Créer des templates de VM sous Virtualbox

     

     

     

    Créer des templates de VM sous Virtualbox : Déploiement de template

    Pour déployer un template existant, cliquez sur Fichier > Importer un appareil virtuel

    Créer des templates de VM sous Virtualbox

     

    Passez en mode expert puis sélectionnez le template que vous souhaitez déployer

    Créer des templates de VM sous Virtualbox

     

    Editer le nom de votre future machine virtuelle en modifiant le champ Nom, modifiez la configuration de votre VM si vous le souhaites, puis lorsque vous êtes prêt cliquez sur Importer

    Créer des templates de VM sous Virtualbox

     

    Attendez que l’opération se termine

    Créer des templates de VM sous Virtualbox

     

    Voilà vous venez de déployer votre template

    Créer des templates de VM sous Virtualbox

     

    Cet article Créer des templates de VM sous Virtualbox est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 28 April 2016 - 15:46

    Un nouveau mémo assez rapide expliquant comment installer les Additions Invités Virtualbox.

     

     

    Installer les Additions Invités Virtualbox

    Commencez par charger le cdrom contenant les Additions Invités dans votre machine virtuelle

    Installer les Additions Invités

     

    Ensuite via la console virtualbox ou via une connexion ssh installez les paquets requis

    sudo apt-get install gcc make build-essential linux-headers-$(uname -r)

     

    Maintenant montez le cdrom sur votre VM

    sudo mount /media/cdrom

     

    Créez un dossier dans lequel nous allons copier le contenu du cdrom

    sudo mkdir /tmp/virtualbox
    sudo cp -r /media/cdrom/* /tmp/virtualbox/

     

    Vous pouvez lancer l’installation

    sudo /tmp/virtualbox/VboxLinuxAdditions.run

     

    Une fois l’installation terminé redémarrez votre machine virtuelle

    sudo reboot

     

    Cet article Installer les Additions Invités Virtualbox est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 28 April 2016 - 15:14

    Quand on installe souvent des machines virtuelles. on peut utiliser des templates pour se faciliter la vie, par contre il reste toujours un truc chiant : trouver l’IP d’une machine virtuelle. C’est pas forcément très pratique de devoir ouvrir la console de votre VM et de balancer un ipconfig ou ifconfig afin de récupérer son IP.

     

     

    Trouver l’IP d’une machine virtuelle

    Trouver l’IP d’une machine virtuelle : Sous Virtualbox

    Il vous faudra avoir installé les Additions invité VirtualBox pour que cette manipulation fonctionne.

    VirtualBox devra etre lancé avec les droits administrateurs et votre machine virtuelle doit avoir été démarrée.

    Il vous suffit ensuite d’ouvrir une invite de commande Windows dans le répertoire de VirtualBox et d’exécuter la commande suivante. (A noter que sous Linux la commande est exactement la même)

    VBoxManage guestproperty get Nom-VM "/VirtualBox/GuestInfo/Net/0/V4/IP"

     

    Dans mon cas je cherche à obtenir l’IP de la seconde interface configurée

    VBoxManage guestproperty get Debian "/VirtualBox/GuestInfo/Net/1/V4/IP"

     

    Ce qui me renvoie

    Trouver l'IP d'une machine virtuelle

     

     

     

    Trouver l’IP d’une machine virtuelle : Sous VMware Workstation

    Sous VMware Workstation, vous devrez installer les vmware-tools ou le paquet open-vm-tools.

    Pour trouver l’IP d’une machine virtuelle, il vous faudra commencer par connaitre son adresse mac.

    Faites un clic droit sur votre machine virtuelle, puis cliquez sur Settings

    Trouver l'IP d'une machine virtuelle

     

    Choisissez Network Adapter puis cliquez sur Advanced

    Trouver l'IP d'une machine virtuelle

     

    Copiez cette adresse mac

    Trouver l'IP d'une machine virtuelle

     

    Ouvrez maintenant une invite de commande puis lancez la commande suivante. À noter que les caractères de l’adresse mac doivent être en minuscules et les « deux points » doivent être remplacés par des tirets

    arp -a | findstr "votre-adresse-mac"

     

    Sous Linux, utilisez la commande suivante (ici pas besoin de minuscules ni de remplacer les deux points par tirets)

    arp -a | grep "votre-adresse-mac"

     

    Ce qui dans mon cas me donne le résultat suivant

    Trouver l'IP d'une machine virtuelle

     

    Cet article Trouver l’IP d’une machine virtuelle est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 28 April 2016 - 10:54

    Si vous êtes comme moi et que vous passez votre temps à tester pas mal de distributions ou paquets, vous devez souvent jouer avec VMware Workstation d’où l’utilité de créer des templates de VM.

    Dans ce mémo nous allons créer un template de debian 8. L’opération reste la même pour les autres systèmes d’exploitation.

     

     

    Créer des templates de VM : Préparation

    Commencez donc par ouvrir VMware Workstation et créez une première machine virtuelle qui servira de template.

    VMware Workstation - Créer des templates de VM

     

    Maintenant, faites un clic droit sur votre machine virtuelle, puis naviguez vers Snapshot > Take Snapshot

    VMware Workstation - Créer des templates de VM

     

    Nommez votre snapshot et validez

    VMware Workstation - Créer des templates de VM

     

    Une fois l’opération terminée, faites à nouveau un clic droit sur votre machine virtuelle et cliquez sur Settings

    VMware Workstation - Créer des templates de VM

     

    Dans l’onglet Options, cliquez sur Advanced puis cochez Enable Template mode puis validez

    VMware Workstation - Créer des templates de VM

     

    Voilà votre template est maintenant prêt à être déployé

     

     

    Créer des templates de VM : Déploiement de template

    Pour déployer un template, il suffit de le cloner.

    Encore une fois faites un clic droit sur votre template et naviguez vers Manage > Clone

    VMware Workstation - Créer des templates de VM

     

    Cliquez sur Suivant

    VMware Workstation - Créer des templates de VM

     

    Assurez vous que votre template soit bien sélectionné

    VMware Workstation - Créer des templates de VM

     

    Créez un clone complet

    VMware Workstation - Créer des templates de VM

     

    Donnez un nom à votre nouvelle machine virtuelle

    VMware Workstation - Créer des templates de VM

     

    Attendez que le clonage se termine.

    VMware Workstation - Créer des templates de VM

     

     

    Tout devrait se dérouler sans encombre

    VMware Workstation - Créer des templates de VM

     

    Voila vous avez déployé votre première machine virtuelle à partir d’un template

    VMware Workstation - Créer des templates de VM

     

    Source

     

    Cet article Créer des templates de VM sous VMware Workstation est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 28 April 2016 - 03:27

    Je viens de faire la découverte d’un thème Material Design ruTorrent. Voici à quoi il ressemble

     

    Thème Material Design ruTorrent

     

    Donc si cela vous dit je vous propose de l’installer.

     

    Thème Material Design ruTorrent

    Commencez par vous rendre dans le dossier contenant les thèmes rutorrent

    cd /var/www/rutorrent/plugins/theme/themes

     

    Maintenant téléchargez le thème depuis github

    git clone git://github.com/phlooo/ruTorrent-MaterialDesign.git materialdesign

     

    Il ne vous reste plus qu’à changer le propriétaire des fichiers

    chown -R www-data:www-data /var/www/rutorrent/plugins/theme/themes/materialdesign

     

    Source

     

    Cet article Thème Material Design ruTorrent est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Wednesday 27 April 2016 - 15:29

    Je souhaitais installer, configurer et sécuriser un serveur FTP : voilà donc un nouveau mémo détaillant cette manipulation avec proftpd. Notre serveur FTP devra autoriser la connexion d’utilisateurs virtuels enfermés (chroot) dans un dossier. Le serveur FTP devra aussi leur permettre d’accéder à des ressources présentes sur d’autres disques.

     

     

    Configurer et sécuriser un serveur FTP : installation de proftpd

    Commençons donc par installer le logiciel proftpd

    sudo apt-get install proftpd-basic

     

    Lors du processus d’installation, vous allez devoir choisir entre un serveur inetd ou standalone. Si vous choisissez inetd, le serveur ne se lancera que si une connexion FTP est initiée, si vous choisissez standalone le daemon tournera en permanence. Vu la puissance actuelle des machines, on peut tranquillement choisir le mode standalone

    Configurer et sécuriser un serveur FTP

     

     

    Configurer et sécuriser un serveur FTP : Ajout d’un utilisateur virtuel

    Pas question d’ajouter un utilisateur système pour chaque personne ayant besoin d’accèder à ce serveur FTP, il faut donc créer des utilisateurs virtuels. Accessoirement nous souhaitons que ces utilisateurs n’aient accès à aucun shell. Nous allons créer configurer un « faux shell » nommé /bin/false

    Commençons par lister les shells disponibles sur notre serveur via la commande suivante

    cat /etc/shell

     

    Dans mon cas voici le résultat

    root@noobunbox:~$ cat /etc/shells
    # /etc/shells: valid login shells
    /bin/sh
    /bin/dash
    /bin/bash
    /bin/rbash

     

    Le shell /bin/false n’étant pas disponible, nous allons l’ajouter, il suffit d’editer le fichier /etc/shells

    sudo nano /etc/shells

     

    pour y ajouter l’entrée suivante

    /bin/false

     

    Cette étape terminée nous allons pouvoir configurer notre utilisateur virtuel via la commande ftpasswd. Quelques explications sur les options que nous allons utilisés

    • sha512 : nous permet d’utiliser l’algorithme sha512 à la place de md5
    • uid & gid : il faut spécifier un user identifier et groupe identifier pour chaque utilisateur virtuel
    • file : le fichier contenant les données utilisateurs
    • home : le répertoire dans lequel notre utilisateur virtuel se connectera
    • shell: le shell que notre utilisateur peut utiliser
    ftpasswd --passwd --name=mon-utilisateur --sha512 --uid=800 --gid=800 --file=/etc/proftpd/ftpd.passwd --home=/srv/ftp/ --shell=/bin/false

     

     

    Configurer et sécuriser un serveur FTP : Génération d’un certificat SSL

    Créons le dossier qui contiendra notre certificat ainsi que la clé privée

    sudo mkdir /etc/proftpd/ssl
    sudo chmod 600 /etc/proftpd/ssl/ && cd /etc/proftpd/ssl

     

    Générons une clé privée un CSR et signons notre certificat

    sudo openssl ecparam -genkey -name secp384r1 > ftp-key-p384.pem
    sudo openssl req -new -key ftp-key-p384.pem -out csr.pem
    sudo openssl req -x509 -days 3650 -key ftp-key-p384.pem -in csr.pem -out certificate.pem

     

    Maintenant protégeons ces fichiers

    sudo chmod 400 ftp-key-p384.pem csr.pem
    sudo chmod 600 certificate.pem

     

     

    Configurer et sécuriser un serveur FTP : configuration générale de protftpd

    Nous pouvons maintenant modifier la configuration générale de proftpd,

    sudo nano /etc/proftpd/proftpd.conf

     

    De nombreuses options y sont définies. Voici celle que vous devez modifier / configurer :

    • ServerIdent off – pas la peine que des petits malins puissent identifier la version de proftpd que vous utilisez
    • Servername « Votre Serveur » – donnez un nom à votre serveur
    • AuthUserFile /etc/proftpd/ftpd.passwd – Indispensable pour que votre serveur puisse accepter les connexions de vos utilisateurs virtuels
    • DefaultRoot ~ – Indispensable pour que les utilisateurs ne puissent pas se balader partout sur votre serveur
    • Port 21 – Je vous conseille de modifier le port d’écoute par défaut
    • PassivePorts 1234 1234 – Indiquer un range de ports (ex 30100 30200) utilisé pour le mode PASV. Pour plus d’infos sur le mode passif, cliquez ici
    • Include /etc/proftpd/tls.conf – indispensable puisque nous allons configurer et sécuriser le protocole FTPS

     

    Assurez vous donc que les entrées suivantes soient présentes dans votre fichier de configuration, tout en les modifiant à votre convenance :

    ServerIdent off
    ServerName "noobunbox.net"
    
    AuthUserFile /etc/proftpd/ftpd.passwd
    
    DefaultRoot ~
    
    Port 34555
    PassivePorts 30100 30200
    
    Include /etc/proftpd/tls.conf

     

     

    Configurer et sécuriser un serveur FTP : configuration SSL

    Nous n’allons pas seulement configurer proftpd pour qu’il utilise le certificat que nous avons généré précédemment, nous allons aussi configurer correctement le protocole FTPS c’est à dire :

    • N’autoriser que les connexions sécurisées
    • N’autoriser que les connexions via le protocole TLS 1.2
    • Utiliser des ciphers sécurisés
    • Utiliser le chiffrement implicite

     

    Petite parenthèse avant de continuer : vous avez surement remarquer que lorsque vous configuriez une connexion FTPS dans votre client préféré vous aviez le choix entre le chiffrement explicite et implicite.  Le chiffrement implicite permet de n’autoriser que les connexions chiffrées dès l’établissement de la connexion.

     

    Modifions le fichier contenant la configuration du protocole FTPS

    sudo nano /etc/proftpd/tls.conf

     

    Que nous configurons de la manière suivante

    <IfModule mod_tls.c>
    TLSEngine on
    TLSLog /var/log/proftpd/tls.log
    TLSProtocol TLSv1.2
    TLSCipherSuite EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES;
    TLSOptions UseImplicitSSL
    TLSRSACertificateFile /etc/proftpd/ssl/certificate.pem
    TLSRSACertificateKeyFile /etc/proftpd/ssl/ftp-key-p384.pem
    TLSVerifyClient off
    TLSRequired on
    </IfModule>

     

    Vous pouvez maintenant redémarrer le service proftpd et vous connectez avec votre utilisateur.

    Voici comment il faudrait configurer la connexion avec le client FileZilla

    Configurer et sécuriser un serveur FTP

     

     

    Configurer et sécuriser un serveur FTP : partage de dossiers

    Lorsque j’ai voulu partager des dossiers avec mes utilisateurs virtuels je dois dire que j’ai eu un peu de mal. Je souhaitais que ces utilisateurs aient assez à des ressources stockées sur plusieurs disques et partages réseaux.

    Par exemple vous souhaiteriez partager :

    • vos images stockées dans /home/utilisateur/images
    • des vidéos stockées sur un disque /media/disk01/videos
    • des fichiers stockés sur un nas monté dans /media/synology/docs

     

    Si vous créez des liens symboliques dans le home de vos utilisateurs (ici /srv/ftp) cela ne fonctionnera pas. Les liens symbolique seront visibles, mais lorsque vos utilisateurs tenteront de naviguer dans des sous dossiers ou télécharger des fichiers l’erreur 550 s’affichera.

    Il faudra donc monter ces dossiers dans /srv/ftp via la commande

    mount --bind
    

     

    Dans notre exemple voici ce que cela donnerait :

    Commençons par créer les dossiers dans lesquels nous monterons nos dossiers partagés

    cd /srv/ftp
    sudo mkdir docs images videos

     

    Montons maintenant nos dossiers

    mount --bind /home/utilisateur/images images
    mount --bind /media/disk01/videos videos
    mount --bind /media/synology/docs

     

    Pour que ces partages soient permanents il vous faudra ajouter les entrées suivantes au fichier /etc/fstab

    A noter qu’il faudra ajouter l’option _netdev pour chaque mount bind d’une ressource réseau.

    ## Partage FTP
    /home/utilisateur/images images   none bind 0 0  
    /media/disk01/videos     videos   none bind 0 0
    /media/synology/docs     docs     none _netdev,bind 0 0

     

    Cet article Configurer et sécuriser un serveur FTP est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 22 April 2016 - 18:48

    Vous avez compilé votre Kernel, vous l’avez installé mais voilà comment effectuer une mise à jour kernel sans reboot ? C’est très simple, il vous suffit d’utiliser kexec.

     

    Mise à jour Kernel sans reboot

    Kexec vous permet de bypasser la phase d’amorçage du système, il charge directement le nouveau Kernel en mémoire et l’exécute.

     

    Pour installer kexec lancez la commande suivante :

    sudo apt-get install kexec-tools

     

    Maintenant pour lancer la mise à jour Kernel sans reboot, exécutons la commande suivante

    sudo systemctl kexec

     

    Votre session SSH va couper, re-lancez la et vérfiez la version du Kernel via la commande

    uname -r

     

    Pour effectuer un reboot « normal » il faudra désormais utiliser la commande

    coldreboot

     

     

    Cet article Mise à jour Kernel sans reboot est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Monday 18 April 2016 - 14:13

    J’ai enfin pensé à continuer ma série de mémo expliquant comment installer une seedbox. Mieux vaut tard que jamais 😀

    Un petit lien vers les deux premiers billets que j’avais rédigé, ils datent un peu mais sont toujours valables :

     

     

    Installer une seedbox  : Pré-requis

    Ici je pars du principe que vous avez déjà installé un système d’exploitation sur votre serveur. Ici nous utilisons Debian 8

     

    Installer une seedbox : Configuration des dépôts

    Avant tout il va falloir commencer par configurer nos dépôts, les sources depuis lesquelles nous téléchargeons nos paquets, commençons donc par modifier les dépôts de base de notre distribution.

    nano /etc/apt/sources.list

     

    Par défaut il est configuré de la manière suivante

    deb http://mirror.mephi.ru/debian/ jessie main 
    deb-src http://mirror.mephi.ru/debian/ jessie main 
    
    deb http://security.debian.org/ jessie/updates main 
    deb-src http://security.debian.org/ jessie/updates main 
    
    # jessie-updates, previously known as 'volatile'
    deb http://mirror.mephi.ru/debian/ jessie-updates main 
    deb-src http://mirror.mephi.ru/debian/ jessie-updates main

     

    Ajoutons donc les dépôts contrib et non-free

    deb http://mirror.mephi.ru/debian/ jessie main contrib non-free
    deb-src http://mirror.mephi.ru/debian/ jessie main contrib non-free
    
    deb http://security.debian.org/ jessie/updates main contrib non-free
    deb-src http://security.debian.org/ jessie/updates main contrib non-free
    
    # jessie-updates, previously known as 'volatile'
    deb http://mirror.mephi.ru/debian/ jessie-updates main contrib non-free
    deb-src http://mirror.mephi.ru/debian/ jessie-updates main contrib non-free

     

    Maintenant nous pouvons ajouter de nouveaux dépôts, mais pour le faire nous aurons besoin de leur clé afin de pouvoir authentifier les paquets disponibles

    wget --no-check-certificate https://www.dotdeb.org/dotdeb.gpg && apt-key add dotdeb.gpg
    wget http://www.deb-multimedia.org/pool/main/d/deb-multimedia-keyring/deb-multimedia-keyring_2016.3.7_all.deb && dpkg -i deb-multimedia-keyring_2016.3.7_all.deb
    

     

    Créons un fichier de configuration pour le dépot dotdeb

    echo "#Dotdeb
    deb http://packages.dotdeb.org jessie all
    deb-src http://packages.dotdeb.org jessie all" >> /etc/apt/sources.list.d/dotdeb.list

     

    Meme chose pour le dépôt multimédia

    echo "#Deb-Multimedia
    deb http://www.deb-multimedia.org jessie main non-free" >> /etc/apt/sources.list.d/deb-multimedia.list

     

    Maintenant vous pouvez mettre la lise de vos paquets à jour

    apt-get update
    

     

     

    Installer une seedbox : Installation des dépendances

    Ici rien de bien compliqué, nous allons installer pas mal de paquets qui seront nécessaires pour compiler rtorrent et faire tourner notre seedbox

    apt-get install automake libcppunit-dev libtool build-essential pkg-config libssl-dev libcurl4-openssl-dev libsigc++-2.0-dev libncurses5-dev screen subversion apache2-utils curl php7.0 php7.0-fpm php7.0-cli php7.0-curl php7.0-geoip git unzip unrar rar zip ffmpeg buildtorrent mediainfo

     

     

    Installer une seedbox : Compilation de rTorrent

    Sous Debian, rTorrent est déjà disponible depuis les dépôts officiel, il est fourni avec l’interface XML-RPC nécessaire pour fonctionner avec rutorrent. Vous n’êtes donc en rien obligé de suivre les étapes de compilation sauf si comme moi vous préférez utiliser une version mise à jour de rTorrent

    Pour utiliser rTorrent via une interface web, rutorrent, nous avons besoin d’utiliser XMLRPC

    cd /tmp
    svn checkout http://svn.code.sf.net/p/xmlrpc-c/code/stable xmlrpc-c
    cd xmlrpc-c/
    ./configure
    make -j $(nproc)
    make install

     

    Occupons nous maintenant de libtorrent (dernière version stable 0.13.6)

    cd /tmp
    git clone https://github.com/rakshasa/libtorrent.git
    cd libtorrent
    git checkout `git tag | tail -1`
    ./autogen.sh
    ./configure
    make -j $(nproc)
    make install

     

    Et enfin de rTorrent (dernière version stable 0.9.6)

    cd /tmp
    git clone https://github.com/rakshasa/rtorrent.git
    cd rtorrent
    git checkout `git tag | tail -1`
    ./autogen.sh
    ./configure --with-xmlrpc-c
    make -j $(nproc)
    make install

     

    N’oubliez pas de générer des liens symboliques pour les librairies récemment installées

    ldconfig

     

     

    Installer une seedbox : Installation et configuration de rutorrent

    rutorrent c’est l’interface web qui nous permettra de controler rTorrent, commençons donc par le télécharger

    mkdir -p /var/www/html
    cd /var/www/html
    git clone https://github.com/Novik/ruTorrent.git rutorrent

     

    Pour rendre ruTorrent utilisable avec un mobile ou une tablette, installons un plugin

    cd /var/www/html/rutorrent/plugins/
    git clone https://github.com/xombiemp/rutorrentMobile.git mobile
    chown -R www-data:www-data /var/www/html/rutorrent
    

     

    Configurons maintenant le rutorrent pour qu’il utilise le paquet buildtorrent lors de la création d’un fichier torrent

    nano /var/www/html/rutorrent/plugins/create/conf.php

     

    Que nous configurons de la manière suivante

    $useExternal = 'buildtorrent';
    $pathToCreatetorrent = '/usr/bin/buildtorrent';

     

     

    Installer une seedbox : Configuration de PHP

    Ouvrons la configuration de PHP7

    nano /etc/php/7.0/fpm/php.ini

     

    Dans ce fichier, vérifiez que les variables suivantes soient configurées correctement

    expose_php = Off 
    file_uploads = On
    post_max_size = 15M
    upload_max_filesize = 15M
    ; En fonction de votre location
    date.timezone = Europe/Paris

     

    Maintenant redémarrons le service php7.0-fpm afin d’appliquer les modifications

    service php7.0-fpm restart

     

     

    Installer une seedbox : Installation et configuration du serveur WEB

    Vous vous en doutez, une seedbox nécessite l’utilisation d’un serveur WEB – NGinx ou Apache2

     

    Installer une seedbox : Installation et configuration de NGinx

    Installer une seedbox : installation de NGinx

    Ici nous allons installer la dernière version de NGinx (mainline). Commencons donc par ajouter la clé de signature des paquets

    wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key && rm nginx_signing.key
    

     

    Maintenant configurons le dépot

    echo "#NGinx Mainline
    deb http://nginx.org/packages/debian/ jessie nginx
    deb-src http://nginx.org/packages/debian/ jessie nginx" >> /etc/apt/sources.list.d/nginx-mainline.list

     

    Puis installons le paquet

    apt-get update && apt-get install nginx
    

     

    Installer une seedbox : Configuration de NGinx

    Optimisons maintenant un peu la configuration de NGinx

    mkdir /etc/nginx/auth
    rm /etc/nginx/nginx.conf && nano /etc/nginx/nginx.conf

     

    Voici la configuration que je vous conseille

    user www-data;
    worker_processes auto;
    pid /run/nginx.pid;
    
    events {
     worker_connections 1024;
     multi_accept on;
     use epoll;
    }
    
    http {
    
     charset UTF-8;
    
     ##
     # Basic Settings
     ##
     server_names_hash_bucket_size 64;
     sendfile on;
     tcp_nopush on;
     tcp_nodelay on;
     keepalive_timeout 65;
     types_hash_max_size 2048;
     server_tokens off;
    
     # server_names_hash_bucket_size 64;
     # server_name_in_redirect off;
    
     include /etc/nginx/mime.types;
     default_type application/octet-stream;
    
     
     ##
     # Logging Settings
     ##
    
     access_log /var/log/nginx/access.log;
     error_log /var/log/nginx/error.log;
    
     ##
     # Gzip Settings
     ##
    
     gzip on;
     gzip_disable "msie6";
     
     gzip_vary on;
     gzip_proxied any;
     gzip_comp_level 6;
     gzip_buffers 16 8k;
     gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    
     ##
     # Virtual Host Configs
     ##
    
     include /etc/nginx/conf.d/*.conf;
     include /etc/nginx/sites-enabled/*;
    }

     

    Installer une seedbox : Configuration du virtualhost

    Supprimons la configuration du virtualhost par défaut et créons un virtual host pour rutorrent

    rm /etc/nginx/conf.d/*.conf && mkdir /etc/nginx/sites-enabled
    nano /etc/nginx/sites-enabled/seedbox

     

    Avec la configuration suivante :

    • nous n’utilisons pas de domaine, vous pouvez très bien le faire en modifiant la variable server_name
    • nous redigeons les requêtes http vers https
    • dans cet exemple nous utilisons un certificat ssl auto-signé, si vous disposez de votre propre domaine, vous pouvez obtenir un certificat via let’s encrypt
    • Pour se connecter à rutorrent chaque utilisateur devra utiliser un login et un mot de passe
    server {
     listen 80;
     listen [::]:80;
     # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
     return 301 https://$host$request_uri;
    }
    
    #------------------------------------------------------------------------
    # BLOCK SERVEUR HTTPS
    #
    server {
    
     listen 443 ssl http2;
     server_name seedbox; 
     root /var/www/html/rutorrent;
     index index.php index.html index.htm;
    
    #------------------------------------------------------------------------
    # SSL
    #
     ssl_certificate /etc/nginx/ssl/seedbox.crt;
     ssl_certificate_key /etc/nginx/ssl/seedbox.key;
    
     ssl_protocols TLSv1.2;
     ssl_ciphers EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES; 
     ssl_ecdh_curve secp384r1;
     ssl_prefer_server_ciphers on;
    
     # ssl optimizations
     ssl_session_timeout 5m;
     ssl_session_cache shared:SSL:20m;
     ssl_session_tickets on;
    
    
    #------------------------------------------------------------------------
    # SECURITY
    
     add_header X-XSS-Protection "1; mode=block";
     auth_basic "Restricted Area";
     auth_basic_user_file "/etc/nginx/auth/seedbox_auth";
      
    #------------------------------------------------------------------------
    # PHP
    # 
     location / {
     index index.php index.html index.htm; 
     try_files $uri $uri/ /index.php?$args;
     }
    
     location ~ \.php$ {
     try_files $uri =404;
     fastcgi_split_path_info ^(.+\.php)(/.+)$;
     fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
     fastcgi_index index.php;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     include fastcgi_params; }
    
     location ^~ /conf/ {
     deny all;
     }
    
     location ^~ /share/ {
     deny all;
     }
    }
    
    

     

    Installer une seedbox  : Configuration SSL

    Créons un répertoire qui contiendra notre certificat auto-signé

    mkdir /etc/nginx/ssl

     

    Dans ce répertoire, générons un certificat auto-signé

    cd /etc/nginx/ssl
    openssl ecparam -genkey -name secp384r1 -out seedbox.key
    openssl req -new -key seedbox.key -sha256 -out seedbox.csr
    openssl req -x509 -days 3650 -sha256 -key seedbox.key -in seedbox.csr -out seedbox.crt

     

    Modifions les droits des fichiers

    chmod 644 /etc/nginx/ssl/*.crt
    chmod 640 /etc/nginx/ssl/*.key

     

     

    Installer une seedbox : Installation et configuration d’Apache2

    Installation d’Apache2

    Installons apache2 ainsi que les modules nécessaires

    apt-get install apache2 libapache2-mod-php7.0 libapache2-mod-scgi

     

    Activons les modules nécessaires

    a2enmod auth_digest ssl scgi

     

    Configuration d’Apache2

    Créons les répertoires nécessaires et désactivons la configuration par défaut

    mkdir /etc/apache2/auth && a2dissite 000-default
    

     

    Configurons notre virtualhost

    nano /etc/apache2/sites-available/seedbox.conf

     

    Comme pour NGinx nous

    • nous n’utilisons pas de domaine, vous pouvez très bien le faire en modifiant la variable ServerName
    • nous redigeons les requêtes http vers https
    • dans cet exemple nous utilisons un certificat ssl auto-signé, si vous disposez de votre propre domaine, vous pouvez obtenir un certificat via let’s encrypt
    • Pour se connecter à rutorrent chaque utilisateur devra utiliser un login et un mot de passe
    NameVirtualHost *:80
    <VirtualHost *:80>
     ServerAdmin votre-email
     ServerName IP.DU.SERVEUR
     redirect / https://IP.DU.SERVEUR
    
    </VirtualHost>
    <IfModule mod_ssl.c>
    <VirtualHost *:443>
     ServerAdmin votre-email
     ServerName IP.DU.SERVEUR
     DocumentRoot /var/www/html/rutorrent
     
     SSLEngine On
     SSLCipherSuite EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES
     SSLHonorCipherOrder on
     SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
     SSLCompression off
     SSLCertificateFile /etc/apache2/ssl/seedbox.crt
     SSLCertificateKeyFile /etc/apache2/ssl/seedbox.key
     
     
     <Directory />
     Options FollowSymLinks
     AllowOverride None
     </Directory>
     <Directory /var/www/html/rutorrent>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Order allow,deny
     allow from all
     </Directory>
     
     ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
     <Directory "/usr/lib/cgi-bin">
     AllowOverride None
     Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
     Order allow,deny
     Allow from all
     </Directory>
     
     ErrorLog ${APACHE_LOG_DIR}/rutorrent-error.log
     
     # Possible values include: debug, info, notice, warn, error, crit,
     # alert, emerg.
     LogLevel warn
     
     CustomLog ${APACHE_LOG_DIR}/rutorrent-access.log combined
     
     
     <Location />
     AuthType Digest
     AuthName "seedbox"
     AuthDigestDomain /var/www/html/rutorrent/
     
     AuthDigestProvider file
     AuthUserFile /etc/apache2/auth/seedbox_auth
     Require valid-user
     SetEnv R_ENV "/var/www/html/rutorrent"
     </Location>
     
    </VirtualHost>
    </IfModule>

     

    Activez ce vhost via la commande

    a2ensite seedbox

     

    Installer une seedbox  : Configuration SSL

    Créons un répertoire qui contiendra notre certificat auto-signé

    mkdir /etc/apache2/ssl

     

    Dans ce répertoire, générons un certificat auto-signé

    cd /etc/apache2/ssl
    openssl ecparam -genkey -name secp384r1 -out seedbox.key
    openssl req -new -key seedbox.key -sha256 -out seedbox.csr
    openssl req -x509 -days 3650 -sha256 -key seedbox.key -in seedbox.csr -out seedbox.crt

     

    Modifions les droits des fichiers

    chmod 644 /etc/apache2/ssl/*.crt
    chmod 640 /etc/apache2/ssl/*.key

     

     

    Installer une seedbox : Ajout d’un utilisateur

    Faites bien attention. Lorsque le nom d’utilisateur noobunbox est écrit en majuscules, vous devez faire de même

    Ici nous allons ajoutez l’utilisateur : noobunbox

    useradd --shell /bin/bash --create-home noobunbox
    passwd noobunbox

     

    Maintenant créons pour cet utilisateur les répertoires nécessaires au fonctionnement de rtorrent

    mkdir -p /home/noobunbox/{torrents,watch,.session}

     

    Créons un fichier de configuration rtorrent pour noobunbox

    nano /home/noobunbox/.rtorrent.rc

     

    Collez la configuration suivante

    scgi_port = 127.0.0.1:5001
    encoding_list = UTF-8
    port_range = 45000-65000
    port_random = no
    check_hash = no
    directory = /home/noobunbox/torrents
    session = /home/noobunbox/.session
    encryption = allow_incoming, try_outgoing, enable_retry
    schedule = watch_directory,1,1,"load_start=/home/noobunbox/watch/*.torrent"
    schedule = untied_directory,5,5,"stop_untied=/home/noobunbox/watch/*.torrent"
    use_udp_trackers = yes
    dht = off
    peer_exchange = no
    min_peers = 40
    max_peers = 100
    min_peers_seed = 10
    max_peers_seed = 50
    max_uploads = 15
    execute = {sh,-c,/usr/bin/php /var/www/html/rutorrent/php/initplugins.php noobunbox &}
    schedule = espace_disque_insuffisant,1,30,close_low_diskspace=500M

     

    Puisque je suppose que vous n’avez pas crée d’utilisateur nommé noobunbox, voici une petite commande pour remplacer mon nom d’utilisateur par le votre (ici votre-utilisateur)

    sed -i -e 's/noobunbox/votre-utilisateur/g' /home/votre-utilisateur/.rtorrent.rc

     

    Maintenant appliquons les permissions nécessaires

    chown --recursive noobunbox:noobunbox /home/noobunbox
    chown root:root /home/noobunbox
    chmod 755 /home/noobunbox

     

    L’etape suivante dépend du programme utilisé comme serveur web, NGinx ou apache2. Vous trouverez ci-dessous les manipulations à effectuer

     

    Sous NGinx

    nano /etc/nginx/sites-enabled/seedbox

     

    Et ajoutez le bloc suivant (le port de la variable scgi_pass pour l’utilisateur doit être le même que celui indiqué dans le fichier .rtorrent.rc)

     location /NOOBUNBOX 
    {
     include scgi_params;
     scgi_pass 127.0.0.1:5001;
     auth_basic "Restricted Area"; 
     auth_basic_user_file "/etc/nginx/auth/seedbox_auth noobunbox";
     }

     

    Puisque nous avons configuré NGinx pour demander un mot de passe lors de l’accès a rutorrent pour l’utilisateur noobunbox, configurons un mot de passe pour cet utilisateur.

    htpasswd -c -B /etc/nginx/auth/seedbox_auth noobunbox

     

    Protégeons un minimum ce fichier

    chmod 600 /etc/nginx/auth/seedbox_auth
    chown www-data:www-data /etc/nginx/auth/*

     

    Créons maintenant un fichier de configuration rutorrent pour l’utilisateur noobunbox

    mkdir /var/www/html/rutorrent/conf/users/noobunbox
    nano /var/www/html/rutorrent/conf/users/noobunbox/config.php

     

    Que nous configurons comme ci-dessous (encore une fois, le port scgi doit être le même que celui indiqué dans le fichier .rtorrent.rc et dans la configuration du vhost NGinx)

    <?php
    
    $pathToExternals['curl'] = '/usr/bin/curl';
    $topDirectory = '/home/noobunbox';
    $scgi_port = 5001;
    $scgi_host = '127.0.0.1';
    $XMLRPCMountPoint = '/NOOBUNBOX';

     

    Corrigeons les permissions et redémarrons NGinx

    chown -R www-data:www-data /var/www/html
    service nginx restart

     

     

    Sous Apache2

    Commençons par éditer le fichier principal de la configuration d’apache2

    nano /etc/apache2/apache2.conf

     

    Ajoutez à la fin du fichier la configuration suivante (le port SCGIMount doit correspondre à celui de votre utilisateur)

    ServerName localhost
    SCGIMount /RPC1 127.0.0.1:5001

     

    Puisque nous avons configuré Apache2 pour demander un mot de passe lors de l’accès a rutorrent, configurons un mot de passe pour notre utilisateur noobunbox. (seedbox correspond à la variable AuthName utilisé dans notre virtualhost)

    htdigest -c /etc/apache2/auth/seedbox_auth seedbox noobunbox

     

    Créons maintenant un fichier de configuration rutorrent pour l’utilisateur noobunbox

    mkdir /var/www/html/rutorrent/conf/users/noobunbox
    nano /var/www/html/rutorrent/conf/users/noobunbox/config.php

     

    Que nous configurons comme ci-dessous (encore une fois, le port scgi doit être le même que celui indiqué dans le fichier .rtorrent.rc et dans la configuration générale d’Apache2)

    <?php
    
    $pathToExternals['curl'] = '/usr/bin/curl';
    $topDirectory = '/home/noobunbox';
    $scgi_port = 5001;
    $scgi_host = '127.0.0.1';
    $XMLRPCMountPoint = '/RPC1';

     

    Corrigeons les permissions et redémarrons Apache2

    chown -R www-data:www-data /var/www/html
    service apache2 restart

     

     

    Installer une seedbox : Configuration du Service rTorrent

    Nous allons maintenant créer et configurer un script afin que rtorrent soit lancé par cet utilisateur

    cd /etc/init.d/
    touch noobunbox-rtorrent
    chmod +x noobunbox-rtorrent

     

    Configurons le script

    nano noobunbox-rtorrent

     

    Remplacez noobunbox par votre nom d’utilisateur

    #!/usr/bin/env bash
    
    # Dépendance : screen, killall et rtorrent
    ### BEGIN INIT INFO
    # Provides: <username>-rtorrent
    # Required-Start: $syslog $network
    # Required-Stop: $syslog $network
    # Default-Start: 2 3 4 5
    # Default-Stop: 0 1 6
    # Short-Description: Start daemon at boot time
    # Description: Start-Stop rtorrent user session
    ### END INIT INFO
    
    ## Début configuration ##
    user="noobunbox"
    ## Fin configuration ##
    
    rt_start() {
     su --command="screen -dmS ${user}-rtorrent rtorrent" "${user}"
    }
    
    rt_stop() {
     killall --user "${user}" screen
    }
    
    case "$1" in
    start) echo "Starting rtorrent..."; rt_start
     ;;
    stop) echo "Stopping rtorrent..."; rt_stop
     ;;
    restart) echo "Restart rtorrent..."; rt_stop; sleep 1; rt_start
     ;;
    *) echo "Usage: $0 {start|stop|restart}"; exit 1
     ;;
    esac
    exit 0

     

    Nous souhaitons que ce script soit exécuté au démarrage du serveur

    update-rc.d noobunbox-rtorrent defaults

     

    La configuration de votre premier utilisateur est terminée. Si vous souhaitez ajouter un second utilisateur vous devrez répéter cette manipulation. N’oubliez pas que chaque utilisateur doit avoir un port scgi différent !

    Il ne vous reste plus qu’à lancer votre seedbox via la commande suivante

    service noobunbox-rtorrent start

     

    Maintenant connectez-vous sur l’ip de votre seedbox (en HTTPS). Tout devrait fonctionner.

     

    Merci à Francois pour la relecture 🙂

     

    Source

    Cet article Installer une seedbox avec rTorrent et rutorrent est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Sunday 17 April 2016 - 22:36

    Vous allez rapidement comprendre pourquoi mon dernier billet expliquait comment compiler et installer un Kernel Linux. J’avais déjà dans l’idée de vous expliquer comment il est possible de sécuriser un Kernel avec grsecurity, je voulais simplement faire correctement les choses.

     

     

    Sécuriser un Kernel avec grsecurity : grsecurity Késséssé ?

    grsecurity est un patch permettant d’augmenter la sécurité d’un noyau Linux en renforcant le controle d’accès local et le confinement des applications. De plus il inclut PAX, un ensemble de correctifs rendant votre système plus résistant à l’exploitation de vulnérabilités.

     

     

    Sécuriser un Kernel avec grsecurity : Pré-requis

    Je radote, tu radotes, il radote, etc.

    Comme dans mon précédent mémo, je vous conseille fortement d’effectuer une sauvegarde de votre système avant d’installer un nouveau Kernel. Puisque j’adore me répéter, je vous rappelle que compiler un noyau prend du temps et beaucoup d’espace disque.

     

    Installation des dépendances

    La compilation d’un noyau avec le module grsecurity requiert plus de dépendances. Il vous faudra commencer par récupérer la version de gcc installée sur votre système.

    gcc -v

     

    Qui dans ici nous donne

    root@noobunbox:~$ gcc -v
    Using built-in specs.
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper

     

    Maintenant installons les dépendances requises, n’oubliez pas de remplacer 4.9 par votre version de gcc

    sudo apt-get install git fakeroot build-essential ncurses-dev xz-utils libssl-dev bc kernel-package gcc-4.9-plugin-dev

     

     

    Sécuriser un Kernel avec grsecurity : C’est parti

    Ici aussi nous allons créer un nouveau répertoire, parce que l’on est un peu psycho-rigide et que l’on aime travailler proprement

    mkdir ~/kernel-grsecurity && cd ~/kernel-grsecurity

     

    grsecurity n’est pas compatible avec les derniers Kernels, à l’heure ou j’écris ce mémo, la dernière version du noyau Linux avec laquelle est compatible grsecurity est la version 4.4.7. Téléchargeons là

     wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.7.tar.xz
     wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.4.7.tar.sign

     

    Vérifions la signature de l’archive

    unxz linux-4.4.7.tar.xz
    gpg --verify linux-4.4.7.tar.sign

     

    Si tout va bien, voici ce que vous devriez obtenir

    root@noobunbox:~/kernel-grsecurity$ gpg --verify linux-4.4.7.tar.sign
    gpg: les données signées sont supposées être dans « linux-4.4.7.tar »
    gpg: Signature faite le mar. 12 avril 2016 19:09:46 MSK avec la clef RSA d'identifiant 6092693E
    gpg: Bonne signature de « Greg Kroah-Hartman (Linux kernel stable release signing key) <greg[at]kroah.com> »
    gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
    gpg: Rien n'indique que la signature appartient à son propriétaire.
    Empreinte de clef principale : 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

     

    Nous pouvons donc extraire l’archive

    tar xvf linux-4.4.7.tar

     

     

    Sécuriser un Kernel avec grsecurity : Patch du Kernel

    Commençons donc par nous déplacer dans le répertoire contenant les sources du noyau 4.4.7

    ~/kernel-grsecurity/linux-4.4.7

     

    Téléchargeons le dernier patch grsecurity disponible (201604152208) ainsi que sa signature

    wget https://grsecurity.net/test/grsecurity-3.1-4.4.7-201604152208.patch
    wget https://grsecurity.net/test/grsecurity-3.1-4.4.7-201604152208.patch.sig

     

    Vérifions que le patch soit correctement signé

    root@noobunbox:~/kernel-grsecurity/linux-4.4.7$ gpg --verify grsecurity-3.1-4.4.7-201604152208.patch.sig
    gpg: les données signées sont supposées être dans « grsecurity-3.1-4.4.7-201604152208.patch »
    gpg: Signature faite le sam. 16 avril 2016 05:09:53 MSK avec la clef RSA d'identifiant 2525FE49
    gpg: Bonne signature de « Bradley Spengler (spender) <spender[at]grsecurity.net> »
    gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
    gpg: Rien n'indique que la signature appartient à son propriétaire.
    Empreinte de clef principale : DE94 52CE 46F4 2094 907F 108B 44D1 C0F8 2525 FE49

     

    Tout semble normal, nous pouvons donc appliquer le patch aux sources du Kernel, pour cela rien de plus simple, lançons la commande suivante

    patch -p1 < grsecurity-3.1-4.4.7-201604152208.patch

     

    La liste des fichiers patchés apparaît dans votre terminal

    [...]
    patching file tools/gcc/gen-random-seed.sh
    patching file tools/gcc/initify_plugin.c
    patching file tools/gcc/kallocstat_plugin.c
    patching file tools/gcc/kernexec_plugin.c
    patching file tools/gcc/latent_entropy_plugin.c
    patching file tools/gcc/randomize_layout_plugin.c
    patching file tools/gcc/size_overflow_plugin/.gitignore
    patching file tools/gcc/size_overflow_plugin/Makefile
    [...]

     

     

    Sécuriser un Kernel avec grsecurity : Configuration du Kernel

    Copiez le fichier de configuration de votre Kernel, histoire de ne pas risquer de tout casser en touchant a tout ?

     cp /boot/config-$(uname -r) .config

    Maintenant ouvrons le menu de configuration du Kernel (étape obligatoire)

    make menuconfig

     

    Dans ce menu naviguez vers « Security Options »

    Sécuriser un Kernel avec grsecurity

     

    Puis vers Grsecurity

    Sécuriser un Kernel avec grsecurity

     

     

    Utilisez la barre espace de votre clavier pour modifier la configuration du module Grsecurity

    Sécuriser un Kernel avec grsecurity

     

    Naviguez vers Configuration Method

    Sécuriser un Kernel avec grsecurity

     

    Sélectionnez Automatic

    Sécuriser un Kernel avec grsecurity

     

    Attention IPtables peut ne pas fonctionner par défaut. Pour s’assurer de son fonctionnement suivez les recommandations ci-dessous
    Networking Support -> Networking options -> Network packet filtering framework (Netfilter) -> IP:Netfilter Configuration -> Enable: IPv4 masquerade support + iptables support
    Networking Support -> Networking options -> Network packet filtering framework (Netfilter) -> IPV6:Netfilter Configuration -> ip6tables NAT support -> Enable: masquerade support

     

    Vous pouvez maintenant sauvegarder votre configuration et quitter.

     

     

    Sécuriser un Kernel avec grsecurity : Compilation du Kernel

    Ici aussi on met un peu d’ordre dans nos fichiers

    make-kpkg clean

     

    Maintenant récupérez le nombre de coeur CPU disponibles sur votre machines

    nproc

     

    Dans mon cas, cette commande me retourne le chiffre 12. Je peux donc affecter jusqu’à 12 cores à la compilation du Kernel

    Nous pouvons maintenant lancer la compilation du Kernel (modifiez l’option -j 12 en fonction du nombre de cores que vous souhaitez affecter à cette opération)

    fakeroot make-kpkg --initrd --revision=1.0.noobunbox kernel_image kernel_headers -j 12

     

     

    Sécuriser un Kernel avec grsecurity : Installation du Kernel

    La compilation est terminée, deux fichiers devraient avoir été générés, vérifions

    root@noobunbox:~/kernel-grsecurity/linux-4.4.7$ ls ../*.deb
    ../linux-headers-4.4.7-grsec_1.0.noobunbox_amd64.deb
    ../linux-image-4.4.7-grsec_1.0.noobunbox_amd64.deb

     

    Je vais me répéter mais ce n’est pas grave 🙂 je vous conseille de transférer ces deux paquets sur une machine virtuelle afin de les tester. Connectez vous donc sur votre MACHINE VIRTUELLE via SSH.

     

    Avant de pouvoir installer notre Kernel grsecurity, nous allons devoir installer deux paquets

    apt-get install paxctl paxtest

     

    Maintenant installez les deux paquets précédemment transférés

    sudo dpkg -i linux-headers-4.4.7-grsec_1.0.noobunbox_amd64.deb
    sudo dpkg -i linux-image-4.4.7-grsec_1.0.noobunbox_amd64.deb

     

    L’installation terminée, redémarrez votre machine virtuelle. Une fois le redémarrage terminé, vérifiez la version du Kernel installé via la commande

    root@noobunbox:~$ uname -a
    Linux debian 4.4.7-grsec #1 SMP Sun Apr 17 23:04:15 MSK 2016 x86_64 GNU/Linux

     

     

    Sécuriser un Kernel avec grsecurity : Test du module grsecurity

    Afin de vérifier que grsecurity fonctionne correctement nous allons utiliser la commande suivante

    root@noobunbox:~$ paxtest blackhat
    

     

    Cette commande permet de simuler l’exploit de vulnérabilités. Si tout va bien voici ce que vous devriez obtenir

    root@noobunbox:~# paxtest blackhat
    PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter[at]adamantix.org>
    Released under the GNU Public Licence version 2 or later
    
    Writing output to /root/paxtest.log
    It may take a while for the tests to complete
    Test results:
    PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter[at]adamantix.org>
    Released under the GNU Public Licence version 2 or later
    
    Mode: Blackhat
    Linux noobunbox 4.4.7-grsec #1 SMP Sun Apr 17 23:04:15 MSK 2016 x86_64 GNU/Linux
    
    Executable anonymous mapping : Killed
    Executable bss : Killed
    Executable data : Killed
    Executable heap : Killed
    Executable stack : Killed
    Executable shared library bss : Killed
    Executable shared library data : Killed
    Executable anonymous mapping (mprotect) : Killed
    Executable bss (mprotect) : Killed
    Executable data (mprotect) : Killed
    Executable heap (mprotect) : Killed
    Executable stack (mprotect) : Killed
    Executable shared library bss (mprotect) : Killed
    Executable shared library data (mprotect): Killed
    Writable text segments : Killed
    Anonymous mapping randomisation test : 28 bits (guessed)
    Heap randomisation test (ET_EXEC) : 23 bits (guessed)
    Heap randomisation test (PIE) : 35 bits (guessed)
    Main executable randomisation (ET_EXEC) : 28 bits (guessed)
    Main executable randomisation (PIE) : 28 bits (guessed)
    Shared library randomisation test : 28 bits (guessed)
    Stack randomisation test (SEGMEXEC) : 35 bits (guessed)
    Stack randomisation test (PAGEEXEC) : 35 bits (guessed)
    Arg/env randomisation test (SEGMEXEC) : 39 bits (guessed)
    Arg/env randomisation test (PAGEEXEC) : 39 bits (guessed)
    Randomization under memory exhaustion @~0: 28 bits (guessed)
    Randomization under memory exhaustion @0 : 28 bits (guessed)
    Return to function (strcpy) : paxtest: return address contains a NU LL byte.
    Return to function (memcpy) : Killed
    Return to function (strcpy, PIE) : paxtest: return address contains a NU LL byte.
    Return to function (memcpy, PIE) : Killed

     

    Pour comparaison voici ce que l’on obtient avec un Kernel ne comprenant pas le module grsecurity

    root@noobunbox:~$ paxtest blackhat
    PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
    Released under the GNU Public Licence version 2 or later
    
    Writing output to /root/paxtest.log
    It may take a while for the tests to complete
    Test results:
    PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
    Released under the GNU Public Licence version 2 or later
    
    Mode: Blackhat
    Linux noobunbox 4.5.1 #1 SMP Sun Apr 17 16:04:50 MSK 2016 x86_64 GNU/Linux
    
    Executable anonymous mapping : Killed
    Executable bss : Killed
    Executable data : Killed
    Executable heap : Killed
    Executable stack : Killed
    Executable shared library bss : Killed
    Executable shared library data : Killed
    Executable anonymous mapping (mprotect) : Vulnerable
    Executable bss (mprotect) : Vulnerable
    Executable data (mprotect) : Vulnerable
    Executable heap (mprotect) : Vulnerable
    Executable stack (mprotect) : Vulnerable
    Executable shared library bss (mprotect) : Vulnerable
    Executable shared library data (mprotect): Vulnerable
    Writable text segments : Vulnerable
    Anonymous mapping randomisation test : 29 bits (guessed)
    Heap randomisation test (ET_EXEC) : 14 bits (guessed)
    Heap randomisation test (PIE) : 30 bits (guessed)
    Main executable randomisation (ET_EXEC) : 29 bits (guessed)
    Main executable randomisation (PIE) : 28 bits (guessed)
    Shared library randomisation test : 29 bits (guessed)
    Stack randomisation test (SEGMEXEC) : 30 bits (guessed)
    Stack randomisation test (PAGEEXEC) : 30 bits (guessed)
    Arg/env randomisation test (SEGMEXEC) : 22 bits (guessed)
    Arg/env randomisation test (PAGEEXEC) : 22 bits (guessed)
    Randomization under memory exhaustion @~0: 28 bits (guessed)
    Randomization under memory exhaustion @0 : 28 bits (guessed)
    Return to function (strcpy) : paxtest: return address contains a NULL byte.
    Return to function (memcpy) : Killed
    Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
    Return to function (memcpy, PIE) : Killed

     

    Source

     

    Cet article Sécuriser un Kernel avec Grsecurity est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Sunday 17 April 2016 - 17:41

    Compiler et installer un Kernel peut faire peur en effet même si la manipulation est assez simple elle n’est pas sans risque. Faites donc extrêmement attention à ce que vous faites.

     

     

    Compiler et installer un Kernel : Kernel Késséssé ?

    Le Kernel (noyau en français) est le coeur de votre distribution. Il assure la communication entre les logiciels et le matériel, la gestion des tâches d’une machine et la gestion du matériel. (Wikipédia pour plus d’informations)

     

     

    Compiler et installer un Kernel : Mais pourquoi ?

    Compiler et installer le dernier Kernel présente certains avantages :

    • support de nouveaux matériels
    • patchs de sécurité
    • ajout(s) de fonctionnalités
    • se la péter devant les copains

     

     

    Compiler et installer un Kernel : Pré-requis

    Je sauvegarde, tu sauvegarde, il sauvegarde, etc.

    Avant de commencer cette manipulation, je vous encourage fortement à effectuer des sauvegardes de vos données (documents, fichiers de configuration). Vous pouvez aussi choisir d’installer ce nouveau Kernel dans une machine virtuelle avant de toucher à vos ordinateurs.

     

    Du temps et de la place

    Compiler un Kernel est une manipulation qui prend du temps et de la place. Le temps nécessaire pour compiler un noyau dépend de votre configuration : avec un i7 12 cores et 12Go de RAM la compilation s’effectue en 10 minutes. Je vous recommande d’avoir au moins 10 Go d’espace libre sur votre disque.

     

    Installation des dépendances

    Si vous êtes prêts à compiler et installer un Kernel il vous faudra commencer par installer quelques paquets

    sudo apt-get install git fakeroot build-essential ncurses-dev xz-utils libssl-dev bc kernel-package

     

     

    Compiler et installer un Kernel : Au boulot

    Les dépendances étant installés nous sommes prêts à aller au charbon. Commençons donc par créer un dossier ou nous téléchargerons les sources du derniers Kernel

    mkdir ~/kernel && cd ~/kernel

     

    Téléchargeons donc les sources du dernier Kernel (4.5.1 à l’heure ou je rédige ce mémo) ainsi que leur signature.

     wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.5.1.tar.xz
     wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.5.1.tar.sign

     

    Maintenant vérifions la signature de l’archive

    unxz linux-4.5.1.tar.xz
    gpg --verify linux-4.5.1.tar.sign

     

    Une erreur devrait s’afficher, la voici

    gpg: assuming signed data in `linux-4.5.tar'
    gpg: Signature made Mon 14 Mar 2016 04:35:48 AM UTC using RSA key ID 6092693E
    gpg: Can't check signature: public key not found

     

    Récupérons donc la clé publique ayant pour ID 6092693E

    gpg --keyserver hkp://keys.gnupg.net --recv-keys 6092693E

     

    Maintenant répétons l’opération.

    gpg --verify linux-4.5.1.tar.sign

     

    Ce qui désormais nous indique que l’archive est correctement signé

    root@noobunbox:~/kernel$ gpg --verify linux-4.5.1.tar.sign
    gpg: les données signées sont supposées être dans « linux-4.5.1.tar »
    gpg: Signature faite le mar. 12 avril 2016 19:04:24 MSK avec la clef RSA d'identifiant 6092693E
    gpg: Bonne signature de « Greg Kroah-Hartman (Linux kernel stable release signing key) <greg[at]kroah.com> »
    gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
    gpg: Rien n'indique que la signature appartient à son propriétaire.
    Empreinte de clef principale : 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

     

    Si le résultat de la précédente commande devez vous afficher une erreur « Mauvaise signature » ne poursuivez pas cette manipulation

    Puisque tout va bien, poursuivons en extrayant l’archive

    tar xvf linux-4.5.1.tar && cd linux-4.5.1

     

     

    Compiler et installer un Kernel : Configuration du Kernel

    Copiez le fichier de configuration de votre Kernel, histoire de ne pas risquer de tout casser en touchant a tout 🙂

    cp /boot/config-$(uname -r) .config

     

    Maintenant ouvrons le menu de configuration du Kernel (étape obligatoire)

    make menuconfig

     

    Vous pouvez par l’intermédiaire de ce menu personnaliser votre Kernel. À moins que vous ne sachiez parfaitement ce que vous faites, je vous déconseille de supprimer le support de drivers.

    L’ajout de nouveaux modules fera l’objet d’un autre post.

    Compiler et installer un kernel

     

    Attention IPtables peut ne pas fonctionner par défaut. Pour s’assurer de son fonctionnement suivez les recommandations ci-dessous
    Networking Support -> Networking options -> Network packet filtering framework (Netfilter) -> IP:Netfilter Configuration -> Enable: IPv4 masquerade support + iptables support
    Networking Support -> Networking options -> Network packet filtering framework (Netfilter) -> IPV6:Netfilter Configuration -> ip6tables NAT support -> Enable: masquerade support

     

    Sauvegardez le fichier puis quittez.

     

     

    Compiler et installer un Kernel : Compilation du Kernel

    Nous allons commencer par mettre de l’ordre via la commande suivante

    make-kpkg clean

     

    Maintenant récupérez le nombre de coeur CPU disponibles sur votre machines

    nproc

     

    Dans mon cas, cette commande me retourne le chiffre 12. Je peux donc affecter jusqu’à 12 cores à la compilation du Kernel

     

    Nous pouvons maintenant lancer la compilation du Kernel (modifiez l’option -j 12 en fonction du nombre de cores que vous souhaitez affecter à cette opération)

    fakeroot make-kpkg --initrd --revision=1.0.noobunbox kernel_image kernel_headers -j 12

     

     

    Compiler et installer un Kernel : Installation du Kernel

    La compilation est terminée, deux fichiers devraient avoir été générés, vérifions

    root@noobunbox:~/kernel/linux-4.5.1$ ls ../*.deb
    ../linux-headers-4.5.1_1.0.noobunbox_amd64.deb ../linux-image-4.5.1_1.0.noobunbox_amd64.deb

     

    Je vais me répéter mais ce n’est pas grave 🙂 je vous conseille de transférer ces deux paquets sur une machine virtuelle afin de les tester.

    Une fois ces paquets transférés sur votre machine virtuelle, installons-les

    sudo dpkg -i linux-headers-4.5.1_1.0.noobunbox_amd64.deb
    sudo dpkg -i linux-image-4.5.1_1.0.noobunbox_amd64.deb

     

    L’installation terminée, redémarrez votre machine virtuelle. Une fois le redémarrage terminé, vérifiez la version du Kernel installé via la commande

    uname -r

     

    Elle devrait vous retourner le résultat suivant

    root@noobunbox:~$ uname -a
    Linux noobunbox 4.5.1 #1 SMP Sun Apr 17 16:04:50 MSK 2016 x86_64 GNU/Linux

     

    Source

    Merci aussi à Angristan, qui grace à ses péripéties sur Twitter m’a inspiré pour ce billet

     

    Cet article Compiler et installer un Kernel est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Friday 15 April 2016 - 00:14

    Let’s encrypt offre depuis un petit moment déjà la possibilité de générer des certificats ECDSA. Comme je suis un peu feignant je me suis demander comment je pouvais renouveler automatiquement un certificat ECDSA Let’s Encrypt, j’en profite donc pour rédiger un petit mémo.

     

     

    Générer un certificat ECDSA avec Let’s Encrypt

    Si ce n’est pas déjà fait, téléchargez Let’s Encrypt

    git clone https://github.com/letsencrypt/letsencrypt
    mv letsencrypt /opt/

     

    Afin que l’authentification fonctionne correctement ajoutez les lignes suivantes dans la configuration de votre domaine principal et de tous les sous-domaines que vous souhaitez certifier.

     

    NGinx

    # webroot authentification lets encrypt 
    location '/.well-known/acme-challenge' {
    root /var/www/www.votre-domaine.tld/;
    try_files $uri /$1;
    }

     

    Apache2

    # webroot authentification lets encrypt 
    Alias /.well-known/acme-challenge  "/var/www/www.votre-domaine.tld/.well-known/acme-challenge"

     

    Après avoir effectué ces modifications relancez la configuration de votre serveur Web

    Maintenant créez les dossiers nécessaires

    mkdir -p /etc/letsencrypt/live-ecdsa/votre-domaine.tld/letmp

     

    Déplacez vous dans le dossier qui contiendra votre certificat et générez une clé privée

    cd /etc/letsencrypt/live-ecdsa/votre-domaine.tld/
    openssl ecparam -genkey -name secp384r1 > privkey-p384.pem

     

    Maintenant vous allez devoir générer un CSR, appuyez vous sur l’exemple ci-dessous (ici nous générerons un CSR pour un domaine (votre-domaine.tld) et un sous-domaine (www.votre-domaine.tld). Libre à vous de rajouter d’autres sous-domaines

    openssl req -new -sha256 -key privkey-p384.pem -subj "/CN=votre-domaine.tld" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:votre-domaine.tld,DNS:www.votre-domaine.tld")) -outform der -out csr-p384.der

     

    Vous disposez maintenant de votre clé privée privkey-p384.pem et de votre CSR csr-p384.der. Nous allons maintenant pouvoir générer un certificat ECDSA via Let’s Encrypt

    cd letmp
    /etc/letsencrypt/letsencrypt-auto certonly -a webroot --email emain@votre-domaine.tld --webroot-path /var/www/www.votre-domaine.tld/ --csr /etc/letsencrypt/live-ecdsa/votre-domaine.td/csr-p384.der --renew-by-default --agree-tos
    cat 0001* > /etc/letsencrypt/live-ecdsa/votre-domaine/chain.pem

     

     

    Mettez à jour la configuration de votre serveur WEB :

    • Comme certificat indiquez /etc/letsencrypt/live-ecdsa/votre-domaine/chain.pem
    • Comme clé privée indiquez /etc/letsencrypt/live-ecdsa/votre-domaine/privkey-p384.pem

     

     

    Renouveler automatiquement un certificat ECDSA Let’s Encrypt

    Si tout fonctionne correctement, vous pouvez passer à la suite. Créez un fichier qui contiendra notre script.

    cd /usr/local/etc/
    sudo nano votre-domaine.tld-renew.sh

     

    Maintenant collez le code suivant

    #!/bin/bash
    
    ## Change this
    MAINDOMAIN="votre-domaine.tld" #Domaine a renouveler
    EMAIL="email@votre-domaine.tld" #Votre email
    WEBROOT="/var/www/www.votre-domaine.tld" # Racine du domaine
    WEB_SERVICE="nginx" #NGinx ou Apache2 
    LE_PATH="/opt/letsencrypt" #Path du client Let's Encrypt
    EXP_LIMIT=40; #Date limite renouvellement cert
    
    
    if [ ! -f /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/chain.pem ]; then
     echo "[ERROR] certificate file not found for domain $MAINDOMAIN."
    fi
    
    if [ ! -f /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/csr-p384.der ]; then
     echo "[ERROR] CSR file for domain $MAINDOMAIN missing. Exiting"
     exit 1
    fi
    
    ## Expiration limit check
    echo "Checking expiration date for $MAINDOMAIN..."
    if openssl x509 -in /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/chain.pem -noout -checkend $(( EXP_LIMIT*24*3600 )) ; then
    echo "The certificate is up to date, no need for renewal."
    exit 0;
    else
    echo "The certificate for $MAINDOMAIN is about to expire soon. Starting webroot renewal script..."
    
    ## Saving previous certs
    if [ ! -e /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp.save/ ]; then
     mkdir /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp.save/
    fi
    
    mv -f /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp/*.pem /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp.save/
    
    
    ## Certificate generation
    cp /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/chain.pem /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/chain.pem.save
    cd /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp/
    $LE_PATH/letsencrypt-auto certonly --text --agree-tos --email $EMAIL --webroot --webroot-path $WEBROOT --csr /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/csr-p384.der --renew-by-default
    
    
    ## We won't replace the current cert if let's encrypt could not issue a new cert
    if [ ! -f /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp/0001*.pem ] ; then
    cp -f /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp.save/*.pem /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/letmp/
    echo "[ERROR] No certificate issued by Let's Encrypt. Your previous certificate will not be modified"
     exit 0;
    fi
    
    cat 0001* > /etc/letsencrypt/live-ecdsa/$MAINDOMAIN/chain.pem
    
     echo "Reloading $WEB_SERVICE"
     /usr/sbin/service $WEB_SERVICE reload
     echo "Renewal process finished for domain $MAINDOMAIN"
     exit 1;
    fi
    
    

     

    Sachez que le script sauvegarde le certificat actuel avant tout renouvellement. La sauvegarde s’effectue dans le fichier /etc/letsencrypt/live-ecdsa/votre-domaine.tld/chaine.pem.save. Une seconde sauvegarde est effectuée : les certificats présents dans /etc/letsencrypt/live-ecdsa/votre-domaine/letmp/ sont sauvegardés automatiquement dans le dossier letmp.save (Un grand merci à Cloug & à Thierry)

    J’ai aussi ajouté une seconde sécurité. Si la génération du certificat via le client Let’s Encrypt échoue. Le certificat actuel ne sera pas remplacé

     

    Après avoir modifié les variables du script, accordez lui les droits nécessaires

    chmod +x votre-domaine.tld-renew.sh

     

    Vous pouvez lancer le script en exécutant la commande suivante

    ./votre-domaine.tld-renew.sh

     

    Voilà vous savez maintenant comment renouveler automatiquement un certificat ECDSA Let’s Encrypt

     

     

    Quelle configuration pour un certificat ECDSA ?

    Ci-dessous un exemple de configuration pour NGinx. Elle reste assez générale, si vous souhaitez encore mieux sécuriser HTTPS consultez ce mémo (à partir de la section Sécuriser HTTPS : HSTS)

    server {
    
    #------------------------------------------------------------------------
    # GENERAL
    #
     listen 443 ssl http2;
     server_name votre-domaine.tld;
     root /var/www/www.votre-domaine.tld;
     index index.php index.html index.htm;
    
    #------------------------------------------------------------------------
    # SSL
    #
     ssl_certificate /etc/letsencrypt/live-ecdsa/votre-domaine.tld/chain.pem;
     ssl_certificate_key /etc/letsencrypt/live-ecdsa/votre-domaine.tld/privkey-p384.pem;
     ssl_trusted_certificate /etc/letsencrypt/live-ecdsa/votre-domaine.tld/chain.pem;
    
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #Vous pouvez supprimer TLSv1 et TLSv1.1 si vous le souhaitez
     ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384';
     ssl_ecdh_curve secp384r1;
     ssl_prefer_server_ciphers on;
    
     # ssl optimizations
     ssl_session_timeout 5m;
     ssl_session_cache shared:SSL:20m;
     ssl_session_tickets off;
     ssl_stapling on;
     ssl_stapling_verify on;
     resolver 8.8.8.8 8.8.4.4 valid=300s;
     resolver_timeout 15s;
    
    }

     

    Merci à Cloug et Thierry pour leurs corrections

     

    Source

     

    Cet article Renouveler automatiquement un certificat ECDSA Let’s Encrypt est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.

  • Thursday 14 April 2016 - 15:37

    Configurer Gitlab sur un sous-domaine sans se retrouver avec du mixed content est assez chiant pour être franc. J’ai pas mal tâtonné, soit je me retrouvais avec une erreur 502 Bad Gateway soit Gravatar passait par le protocole HTTP. J’ai fini par trouver la solution et je souhaitais la partager dans un mémo.

    Dans ce billet je pars du principe que :

     

    Configurer Gitlab sur un sous-domaine NGinx

    Configuration de Gitlab

    Commencez par éditer la configuration de Gitlab

    sudo nano /etc/gitlab/gitlab.rb

     

    Ajoutez et/ou modifiez les lignes suivantes

    external_url 'https://git.votre-domaine.tld' # A remplacer par le sous-domaine que vous souhaitez utiliser
    nginx['listen_addresses'] = ['192.168.1.2'] # IP du serveur GitLab
    nginx['listen_port'] = 8888 # port de votre choix
    nginx['listen_https'] = false # Vous lisez bien, https false

     

    Appliquez les changements de configuration

    sudo gitlab-ctl restart

     

     

    Configuration de NGinx

    Vous allez maintenant devoir créer un virtual host pour votre sous-domaine

    sudo nano /etc/nginx/sites-enabled/git.votre-domaine.tld

     

    Collez la configuration suivante mais surtout n’oubliez pas de l’éditer selon vos besoins

    upstream gitlab {
     server 192.168.1.2:8888;
    }
    
    
    server {
     listen 80;
     server_name git.votre-domaine.tld;
     return 301 https://git.votre-domaine.tld$request_uri;
     }
    
    
    server {
     listen 443 ssl http2; 
     server_name git.votre-domaine.tld
     root /dev/null;
    
     ssl_certificate /etc/letsencrypt/live/votre-domaine.tld/fullchain.pem;
     ssl_certificate_key /etc/letsencrypt/live/votre-domaine.tld/privkey.pem;
     ssl_protocols TLSv1.2;
     ssl_dhparam /etc/nginx/ssl/dh4096.pem;
     ssl_prefer_server_ciphers on;
     ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256";
     ssl_ecdh_curve secp384r1;
    
     add_header X-Content-Type-Options nosniff;
     add_header X-XSS-Protection "1; mode=block";
    
     # A modifier en fonction de la taille des fichiers que vous uploadez
     client_max_body_size 20m;
     
     location / {
     proxy_read_timeout 300;
     proxy_connect_timeout 300;
     proxy_redirect off;
     
     proxy_set_header X-Forwarded-Proto $scheme;
     proxy_set_header Host $http_host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-Ssl on;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header X-Frame-Options SAMEORIGIN;
     
     proxy_pass http://gitlab;} 
    
    }

     

    Vous pouvez maintenant tester votre configuration et si aucune erreur n’apparaît rechargez la configuration NGinx

    sudo service nginx reload

     

    Voilà vous avez terminé de configurer GitLab sur un sous-domaine et vous devriez maintenant pouvoir y accéder via git.votre-domaine.tld

     

    Cet article Configurer GitLab sur un sous-domaine NGinx est apparu en premier sur Noobunbox - Blog : NAS, Serveur, Sécurité, Virtualisation.