mardi 7 octobre 2014

Sauvegarde Rsync over SSH sur QNAP TS-269L

Dans une récente mise à jour du firmware, QNAP a ajouté la possibilité d'utiliser Rsync sur SSH pour les sauvegardes. Voici comment paramétrer une sauvegarde vers un serveur Debian.

Sur le serveur de destination

  • Installer rsync

apt-get install rsync

  • Activer le démarrage dans /etc/default/rsync
RSYNC_ENABLE=true
  • Configurer une section dans /etc/rsyncd.conf
[backup]
path = /home/user/MyQNAP
use chroot = no
read only = no
list = yes
uid = user
gid = user
  • (Re)démarrer rsyncd

service rsync restart



Sur le NAS, dans Backup Station :

  • Créer une réplication Rsync dans le Backup Manager.
  • Mettre n'importe quoi en passwd (mais pas vide)
  • Cocher "enable encryption", port 22
  • Décocher "execute backup immediately"



Se connecter en SSH sur le NAS

  • Copier la clé publique de l'utilisateur "admin" vers le serveur de destination. Attention à ne pas écraser un éventuel fichier existant /!\

scp .ssh/id_rsa.pub user@192.168.1.250:.ssh/authorized_keys

On en profite au passage pour enregistrer la clé du serveur de sauvegarde (TOFU). Note à ce sujet : il semble que sur le NAS, le fichier .ssh/known_hosts est remis à zéro si un échec de connexion survient.


Sur le serveur :

  • Créer /home/user/rsyncd.conf

ln -s /etc/rsyncd.conf /home/user/

  • Arrêter et désactiver le service rsync dans /etc/default/rsync

service rsync stop

RSYNC_ENABLE=false

lundi 10 février 2014

Rsync (avec transport SSH) sur un autre port que le 22

rsync -e 'ssh -p 42'
(Sinon j'oublie !)

mercredi 19 décembre 2012

Configurer l'authentification SSH par clé sous CentOS/Redhat 6.*

Il est généralement utile de configurer une machine pour accepter l'authentification SSH par clé. Ce genre d'authentification est assez simple à mettre en place mais dans le cas des dernières versions de Redhat et CentOS, versions 6 et supérieures, il y a quelques petits pièges qui peuvent vite vous faire péter une pile.

Lire la suite...

lundi 20 août 2012

Cntlm Authentication Proxy

Cntlm est un utilitaire permettant de s'authentifier auprès d'un proxy.

Une fois l'utilitaire installé (téléchargeable ici), il faut modifier le finir cntlm.ini :

Username	identifiant_AD
Domain		nom_domaine
Auth		mode_auth
PassNTLMv2	hash_trouvé
Proxy		ip_proxy:port_proxy
Listen		3128
SOCKS5Proxy	8010

Il est possible de remplir le fichier cntlm.ini avec votre mot de passe de domaine en clair, mais il est préférable de le laisser vide et d'utiliser cntlm pour récupérer la méthode d'authentification de votre AD ainsi que le hash de votre mot de passe. Il suffit d’exécuter la commande suivante dans le dossier de cntlm

cntlm -I -M http://test.com
Config profile  1/11... OK (HTTP code: 200)
Config profile  2/11... OK (HTTP code: 200)
Config profile  3/11... OK (HTTP code: 200)
Config profile  4/11... OK (HTTP code: 200)
Config profile  5/11... OK (HTTP code: 200)
Config profile  6/11... Credentials rejected
Config profile  7/11... Credentials rejected
Config profile  8/11... OK (HTTP code: 200)
Config profile  9/11... OK (HTTP code: 200)
Config profile 10/11... OK (HTTP code: 200)
Config profile 11/11... OK (HTTP code: 200)
----------------------------[ Profile  0 ]------
Auth            NTLMv2
PassNTLMv2      4AC6525378DF8C69CF6B6234532943AC
------------------------------------------------

Il suffit alors de rajouter les 2 lignes dans le fichier cntlm.ini.

On peut ensuite configurer Putty pour utiliser cntlm :
Dans l'onglet Connexion/proxy :
proxy type : SOCKS 5
proxy hostname : 127.0.0.1
port : 8010

samedi 20 août 2011

Kippo - Honeypot SSH

Présentation

Kippo <http://code.google.com/p/kippo/> est un honeypot SSH. Il permet de simuler un serveur SSH qui, suivant l'objectif, peut être facilement accessible lors d'une tentative d'attaque sur le serveur hôte. Il permet, entres autres, de récupérer certaines informations de l'attaquant :

  • les couples logins / mots de passe utilisés pour s'authentifier ;
  • une fois authentifié, les commandes utilisées ;
  • les fichiers envoyés par l'attaquant ;
  • et bien d'autres...
Il est codé en python et nécessite quelques librairies pour fonctionner (en plus du moteur Python bien évidemment) :
  • Twisted 8.0+ (paquet : python-twisted-bin)
  • PyCrypto (paquet : python-crypto)
  • Zope Interface (paquet : python-zope.interface)

Installation

L'installation est vraiment simpliste :

$ wget http://kippo.googlecode.com/files/kippo-0.5.tar.gz
$ tar xzf kippo-0.5.tar.gz && rm kippo-0.5.tar.gz && cd kippo-0.5
$ ./start.sh

et voilà :)

Par défaut, le serveur SSH sera lancé sur le port 2222. Ce port peut être modifié dans le fichier de configuration kippo.cfg:

15|    ssh_port = 2222

Attention néanmoins, Kippo refusera de se lancer avec des droits root, ce qui est très compréhensible, donc il ne sera pas possible de désigner un port inférieur à 1024 (il faudra alors privilégier le port-forwarding afin que le service soit à l'écoute sur le port 22).

Informations et modifications

Plusieurs dossiers sont intéressants

  • honeyfs : il contient l'arborescence des fichiers du serveur SSH. Il est ainsi possible de configurer un /proc/meminfo comme désirer par exemple ;
  • txtcmds : il contient le retour de plusieurs commandes, encore une fois pour personnaliser l'environnement de l'attaquant ;
  • log : il contient le fichier de log du serveur, qui enregistre en particulier les couples logins/passwords et les commandes tapées ;
  • dl : il va contenir tous les fichiers envoyés par l'attaquant.

Récupération des logins et mots de passe

Notre objectif maintenant serait de récupérer dynamiquement, et séparément les logins et mots de passe utilisés (par exemple pour pouvoir se confectionner un petit dictionnaire).
Plusieurs solutions sont possibles :

1 - L'extraction à partir du fichier de logs

Ca ne sera pas du tout dynamique ni probant, mais voici un petit script rapidement écrit pour extraire les IP, les logins et les mots de passe :

#!/bin/bash
#
for ll in $(egrep -o "([[:digit:]]{1,3})(.)([[:digit:]]{1,3})(.)([[:digit:]]{1,3})(.)([[:digit:]]{1,3})(.)(\])( login attempt )(\[)([[:print:]]+)(/)([[:print:]]+)(\])" kippo.log | cut -d' ' -f1,4 -s --output-delimiter=)
do
        IP=$(echo $ll | cut -s -d']' -f1)
        LOGIN_PASS=$(echo $ll | cut -s -d'[' -f2 | cut -s -d']' -f1)
        LOGIN=$(echo $LOGIN_PASS | cut -s -d'/' -f1)
        PASS=$(echo $LOGIN_PASS | cut -s -d'/' -f2)

        ## Logs
        echo $IP >> tempIPs
        echo $LOGIN >> tempLOGINs
        echo $PASS >> tempPASSWORDs

        echo "IP: $IP -- Login: $LOGIN -- Password: $PASS"
done

## Logs globaux
for name in IPs LOGINs PASSWORDs
do
        uniq "temp$name" >> $name
        rm "temp$name"
done


2 - L'enregistrement automatique

Autre solution un peu plus propre est de modifier directement le code source de Kippo afin que, à chaque tentative de connexion, le couple login/mot de passe soit enregistré dans un fichier :

Modification du fichier kippo/core/honeypot.py

## Ouverture du flux vers les deux fichiers
19 > logsLogins = open('log/logins.log', 'a');
19 > logsPasswd = open('log/passwd.log', 'a');

## Ne pas vérifier le login à l'authentification
## Sinon, le fichier log/logins.log ne contiendrait que 'root' :s
## Je laisse quand même la vérification pas mot de passe, ce dernier, modifié, étant très complexe, afin de me laisser une porte au besoin
440 < if username == 'root' and password == cfg.get('honeypot', 'password'):
440 > if password == cfg.get('honeypot', 'password'):

442 < elif username == 'root' and password in passdb:
442 > elif password in passdb:

445 > logsLogins.write(username)

445 > logsPasswd.write(password)
445 > logsLogins.flush()
445 > logsLogins.flush()


(fichier d'exemple joint à ce billet)

Le résultat après une tentative / attaque :
  • Concernant les commandes

$ cat log/kippo.log
[...]
2011-08-19 23:05:43+0200 ... ,89.158.96.199] channel open
2011-08-19 23:05:43+0200 ... ,89.158.96.199] pty request: xterm (24, 80, 0, 0)
2011-08-19 23:05:43+0200 ... ,89.158.96.199] Terminal size: 24 80
2011-08-19 23:05:43+0200 ... ,89.158.96.199] getting shell
2011-08-19 23:05:43+0200 ... ,89.158.96.199] Opening TTY log: log/tty/20110819-230543-4519.log
2011-08-19 23:06:19+0200 ... ,89.158.96.199] CMD: cat /proc/cpuinfo
2011-08-19 23:06:19+0200 ... ,89.158.96.199] Command found: cat /proc/cpuinfo
2011-08-19 23:06:19+0200 ... ,89.158.96.199] Updating realfile to honeyfs//proc/cpuinfo
2011-08-19 23:09:06+0200 ... ,89.158.96.199] CMD: ifcondif
2011-08-19 23:09:06+0200 ... ,89.158.96.199] Command not found: ifcondif
2011-08-19 23:09:10+0200 ... ,89.158.96.199] CMD: ifconfig
2011-08-19 23:09:10+0200 ... ,89.158.96.199] Command found: ifconfig
2011-08-19 23:09:10+0200 ... ,89.158.96.199] Reading txtcmd from "/tmp/kippo-0.5/txtcmds/sbin/ifconfig"
2011-08-19 23:10:26+0200 ... ,89.158.96.199] CMD: cat /proc/meminfo
2011-08-19 23:10:26+0200 ... ,89.158.96.199] Command found: cat /proc/meminfo
2011-08-19 23:11:19+0200 ... ,89.158.96.199] CMD: ifconfig
2011-08-19 23:11:19+0200 ... ,89.158.96.199] Command found: ifconfig
2011-08-19 23:11:19+0200 ... ,89.158.96.199] Reading txtcmd from "/tmp/kippo-0.5/txtcmds/sbin/ifconfig"
2011-08-19 23:11:32+0200 ... ,89.158.96.199] CMD: ifconfig
[...]

$ cat log/passwd.log
[...]
00ad82
00AL09
00al74
00B430
00bd
00beaba
00beca
00bn23
00bob
00C737
00chr2
[...]

jeudi 10 mars 2011

Ajaxterm : un client SSH en web

Petite présentation

J'ai enfin trouvé un client web qui me permette de prendre la main sur mes serveurs quand je n'ai pas de client SSH accessible ou que les ports (généralement le 22) sont bloqués. Son nom : Ajaxterm.
Le site de l'âme charitable qui nous le met à disposition : http://antony.lesuisse.org/software/ajaxterm/

Installation

L'installation sous Debian est très simple, Ajaxterm étant disponible dans les dépôts. On commence donc par un classique "apt-get install ajaxterm" pour installer Ajaxterm et les dépendances qui vont bien, en particulier Apache. Attention toutefois, ceci installe la version 0.7. La dernière version lors de l'écriture de ce billet est la 0.11.

Configuration

Le serveur Ajaxterm est écrit en Python et écoute sur le port 8022 en local. Vous pouvez d'ores et déjà vérifier son fonctionnement en lançant un w3m (ou n'importe quel navigateur) à l'adresse http://localhost:8022/. Si besoin, le port peut être modifié dans /etc/default/ajaxterm.

Pour activer un accès depuis une autre machine, on peut ajouter un vhost à Apache qui se contentera de rediriger les requêtes vers Ajaxterm, par le biais du module mod_proxy. Évidemment, ce vhost devra être accessible en HTTPS si on veut conserver l'avantage du chiffrement SSL/TLS.

Cette fonctionnalité nécessite d'activer les modes mod_proxy, mod_proxy_http et mod_ssl :
a2enmod ssl
a2enmod proxy
a2enmod proxy_http

Génération d'un certificat auto-signé

Pour avoir un accès en SSL on peut utiliser un certificat existant ou générer un certificat auto-signé :
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/ajaxterm.crt
Bien évidemment, ce certificat auto-signé lèvera une erreur dans le navigateur. Il est préférable de le signer avec un certificat racine approuvé par le navigateur.

Ajout d'un vhost Apache

On crée donc un /etc/apache2/sites-available/ajaxterm que l'on paramètre pour rediriger les requêtes de /ajaxterm/ vers le port 8022 :

<VirtualHost *:443>

ServerName localhost
SSLEngine On
SSLCertificateFile /etc/ssl/ajaxterm.crt
ProxyRequests Off

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass /ajaxterm/ http://localhost:8022/
ProxyPassReverse /ajaxterm/ http://localhost:8022/

</VirtualHost>

Et on l'active :
a2ensite ajaxterm
Et là youpi ! En pointant un navigateur vers https://IP_du_serveur/ajaxterm/ on peut ouvrir une session SSH sur le serveur.

Augmentation du timeout de la session

Par défaut, votre session SSH se terminera après deux minutes d'inactivité. Je n'ai pas vraiment compris pourquoi mais ce temps peut être augmenté sans problème. Éditons le fichier /usr/share/ajaxterm/ajaxterm.py. À la ligne 395, on remplace modifie la valeur de INACTIVE_PROCESS_TIMEOUT pour le mettre par exemple à 300 secondes (5 minutes). Après un petit redémarrage d'Ajaxterm (/etc/init.d/ajaxterm restart) le nouveau timeout d'inactivité est pris en compte.

Conclusion

Les avantages :

  • Passe les proxy.
  • Simplicité d'installation ;

Les inconvénients :

  • Pas de session SSH vers un autre serveur, uniquement en local ;
  • Pas avec compatible IE7 (ok avec IE8) EDIT 11/03/2011 : en fait si, aujourd'hui ça fonctionne ;
  • Reset de la connexion au bout de 2 minutes d'inactivité (modifiable) ;
  • Nécessite un reverse proxy pour l'atteindre depuis une autre machine. Le paquet ajaxterm dépend d'Apache.