SYN, SYN-ACK, ACK …

Steal This Blog

Archives Posts

VMware Server et Virtual Router Redundany Protocol (VRRP)

mars 3rd, 2009 by Corbier

Selon Wikipédia :

Virtual Router Redundancy Protocol (protocole de redondance de routeur virtuel, VRRP) est un protocole non propriétaire redondant décrit dans la RFC 3768 dont le but est d’augmenter la disponibilité de la passerelle par défaut servant les hôtes d’un même sous-réseau.

Le fonctionnement de VRRP est le suivant :

Chaque Routeur Virtuel utilise une adresse mac de l’IANA ces adresses mac sont réversées et vont de 00:00:5e:00:01:00 à 00:00:5e:00:01:ff (on peut donc avoir 256 routeurs virtuels par segment Ethernet)

Les routeurs communiquent entre eux via l’adresse multicast réservée 224.0.0.18 associé à la mac réservé 00:00:5e:00:01:02

Comme l’indique le paquet capturé suivant :

Frame 6 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_02 (00:00:5e:00:01:02), Dst: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Internet Protocol, Src: 192.168.130.160 (192.168.130.160), Dst: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol

Afin d’utiliser une IP virtuelle associés a plusieurs routeurs nous utilisons le Common Address Redundancy Protocol ou CARP.

Selon wikipédia :

Common Address Redundancy Protocol ou CARP est un protocole permettant à un groupe d’hôtes sur un même segment réseau de partager une adresse IP.

Dans le cadre de préparation de labs, j’ai voulu émulé l’ensemble de via une solution freebsd (Pfsense) sous VMware Server. Cependant l’adresse virtuel CARP ne pouvait pas être utilisé. Les réponses ARP était bien présente mais le ping et tout les autres services était indisponible.

Le module kernel vmnet drop tout les paquets ethernet que ne sont pas à destination :

  • d’elle même
  • d’une addresse de broadcast FF:FF:FF:FF:FF:FF
  • d’une addresse de multicast

Cependant le bloc de IANA est manquant !!!Les packets sont donc droppés.

Afin de valider et corriger le module noyau, il faut éditer le driver.c contenu dans /usr/lib/vmware/modules/source

Le fichier qui nous intéresse est dans l’archive vmnet.tar. Il faut extraire cette archive.

tar xvf vmnet.tar

cd vmnet-only

Ensuite nous devons localiser la fonction VNetPacketMatch qui est responsable du matching de paquet.

*
*———————————————————————-
*
* VNetPacketMatch –
*
*      Determines whether the packet should be given to the interface.
*
* Results:
*      TRUE if the pasket is OK for this interface, FALSE otherwise.
*
* Side effects:
*      None.
*
*———————————————————————-
*/

Bool
VNetPacketMatch(const uint8   *destAddr, // IN: destination MAC
const uint8   *ifAddr,   // IN: MAC of interface
const uint8   *ladrf,    // IN: multicast filter
uint32   flags)          // IN: filter flags
{
/*
* Return TRUE if promiscuous requested, or unicast destined
* for interface, or broadcast (and broadcast requested), or
* if multicast (and all multicast, or this specific
* multicast MAC, was requested).
*/

return ((flags & IFF_PROMISC) || MAC_EQ(destAddr, ifAddr) ||
((flags & IFF_BROADCAST) && MAC_EQ(destAddr, broadcast)) ||
((destAddr[0] & 0×1) && (flags & IFF_ALLMULTI ||
(flags & IFF_MULTICAST &&
VNetMulticastFilter(destAddr, ladrf)))));
}

Il faut ajouter les lignes suivantes ajoutant le support des paquets de IANA :

((destAddr[0] == 0) && (destAddr[1] == 0) &&
(destAddr[2] == 0x5e) && (destAddr[3] == 0) &&
(destAddr[4] == 1))

Ce qui nous donne la fonction suivante :

return ((flags & IFF_PROMISC) || MAC_EQ(destAddr, ifAddr) ||
((flags & IFF_BROADCAST) && MAC_EQ(destAddr, broadcast)) ||
((destAddr[0] == 0) && (destAddr[1] == 0) &&
(destAddr[2] == 0x5e) && (destAddr[3] == 0) &&
(destAddr[4] == 1)) ||
((destAddr[0] & 0×1) && (flags & IFF_ALLMULTI ||
(flags & IFF_MULTICAST &&
VNetMulticastFilter(destAddr, ladrf)))));

Sauvegardez et recompilez le module :

make vmnet.ko

Il nous reste à copié le nouveau module au bon endroit

cp vmnet.ko  /lib/modules/`uname -r`/misc/vmnet.ko

/etc/init.d/vmware restart

Nous avons désormais un VMware Server fonctionnelle.

Archives Posts

IP-FailOver Ovh Vmware Server

janvier 23rd, 2009 by Corbier

Lorsque l’on a un serveur dédié on peut être tenté de faire de la virtualisation sur son serveur. Plus OS, facilité des backups etc… Cependant, pour éviter que ce soit trop le bazar sur leur réseau, Ovh a limiter les mac adresse par rapport au port des commutateurs.

Il est donc impossible de communiquer avec un machine qui serait bridger sur l’interface de la machine hôte. Pour pallier à ça il est possible de mettre ses machines virtuelles en mode HostOnly. Il suffit ensuite d’activer le routage et le snat sur le linux .

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Mais cela pose problème si l’on souhaite utiliser des ip public. Il faut donc feinter.

Tout d’abord ovh propose d’utiliser des IpFailOver afin de faire « pointer » plusieurs ip public sur le même serveur. Comme les mac adresses sont bloquées par port, il faut utiliser le proxy_arp de linux afin de réussir cette configuration.

L’idée est donc d’utiliser des ips public que l’on a acheter à ovh pour des machines virtuelles. Il faut donc configurer une interface réseau vmware en hostonly. Dans ma configuration c’est vmnet1. Activons maintenant le proxy_arp sur l’interface vmware.

echo 1 > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp

Je vous laisse consulter la page suivante pour avoir plus d’information sur le fonctionnement d’un proxy arp.

Ensuite il faut ajouter une route à destination de ip_suplémentaire pour que la machine hote puisse savoir à quel interface envoyer le paquet.

route add ip_supplémentaire dev vmnet1

Il ne vous reste plus qu’a configurer votre machine virtuelle avec l’adresse suplémentaire. Avec un masque de sous réseau 255.255.255.255 pour pouvoir communiquer avec les machines de votre subnet.

Cependant attention le trafic à destination de votre machine virtuel passe par la table filter-forward d’iptables il vous faut évidement configurer les protocoles que vous souhaiter router.

Filed under Non classé having No Comments »

Archives Posts

Mirroring de traffic via iptables [Debian Etch]

juin 5th, 2008 by Corbier

This option adds a `ROUTE’ target, which enables you to setup unusual

routes. For example, the ROUTE lets you route a received packet through

an interface or towards a host, even if the regular destination of the

packet is the router itself. The ROUTE target is also able to change the

incoming interface of a packet.

To copy (duplicate) all traffic from and to a local ECHO server to a second box (nonfinal target)

iptables -A PREROUTING -t mangle -p tcp –dport 7 -j ROUTE –gw 1.2.3.4 –tee

iptables -A POSTROUTING -t mangle -p tcp –sport 7 -j ROUTE –gw 1.2.3.4 –tee

Afin d’activer la cible route pour iptables il est nécéssaire de recompiler l’ensemble « noyau + iptables »

Nous allons donc préparer notre environnement de travail.

apt-get install linux-source-2.6.18 gcc make ncurses-dev
cd /usr/src
tar -xvjf linux-source-2.6.18.tar.bz2
ln -s linux-source-2.6.18 linux

On télécharge les sources d’iptables et on les décompresses

wget http://www.netfilter.org/projects/iptables/files/iptables-1.3.6.tar.bz2

tar -xjpf iptables-1.3.6.tar.bz2

On peut maintenant télécharger le patch-o-matic :

wget http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070728.tar.bz2

tar xvjf patch-o-matic-ng-20070728.tar.bz2

cd patch-o-matic-ng-20070728

Nous devons spécifié le dossier des sources d’iptables

IPTABLES_DIR=/usr/src/iptables-1.3.6 ./runme ROUTE

Hey! KERNEL_DIR is not set.

Where is your kernel source directory? [/usr/src/linux]

Loading patchlet definitions…………….. done

Welcome to Patch-o-matic ($Revision: 6736 $)!

Kernel: 2.6.18, /usr/src/linux

Iptables: 1.3.6, /usr/src/iptables-1.3.6

Each patch is a new feature: many have minimal impact, some do not.

Almost every one has bugs, so don’t apply what you don’t need!

——————————————————-

Already applied:

Testing ROUTE… not applied

The ROUTE patch:

Author: Cédric de Launois <delaunois@info.ucl.ac.be>

Status: Experimental

This option adds a `ROUTE’ target, which enables you to setup unusual

routes. For example, the ROUTE lets you route a received packet through

an interface or towards a host, even if the regular destination of the

packet is the router itself. The ROUTE target is also able to change the

incoming interface of a packet.

The target can be or not a final target. It has to be used inside the

mangle table.

ROUTE target options:

–oif ifname Send the packet out using `ifname’ network interface.

–iif ifname Change the packet’s incoming interface to `ifname’.

–gw ip Route the packet via this gateway.

–continue Route the packet and continue traversing the rules.

–tee Route a copy of the packet, but continue traversing

the rules with the original packet, undisturbed.

Note that –iif, –continue, and –tee, are mutually exclusive.

Examples :

# To force all outgoing icmp packet to go through the eth1 interface

# (final target) :

iptables -A POSTROUTING -t mangle -p icmp -j ROUTE –oif eth1

# To tunnel outgoing http packets and continue traversing the rules :

iptables -A POSTROUTING -t mangle -p tcp –dport 80 -j ROUTE –oif tunl1 –continue

# To forward all ssh packets to gateway w.x.y.z, and continue traversing

# the rules :

iptables -A POSTROUTING -t mangle -p tcp –dport 22 -j ROUTE –gw w.x.y.z –continue

# To change the incoming network interface from eth0 to eth1 for all icmp

# packets (final target) :

iptables -A PREROUTING -t mangle -p icmp -i eth0 -j ROUTE –iif eth1

# To copy (duplicate) all traffic from and to a local ECHO server

# to a second box (nonfinal target)

iptables -A PREROUTING -t mangle -p tcp –dport 7 -j ROUTE –gw 1.2.3.4 –tee

iptables -A POSTROUTING -t mangle -p tcp –sport 7 -j ROUTE –gw 1.2.3.4 –tee

—————————————————————–

Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y

Excellent! Source trees are ready for compilation.

Nous pouvons maintenant compiler le noyau

cd /usr/src/linux

make oldconfig

Quelques librairies sont rapidement indispensable ;o)

apt-get install kernel-package

Et c’est partie pour de la compilation

make-kpkg clean

make-kpkg –initrd kernel_image kernel_headers

make-kpkg –initrd kernel_image

Une fois la compilation effectué il faut installer et booter sur le noyau.

dpkg –i monnoyau.deb

Vérifiez votre /boot/grub/menu.lst afin de voir si votre nouveau noyau apparait.

Ensuite Reboot

Pour monitorer tout le trafic entrant vers une ip (Un IDS par exemple J) utiliser la règle iptables suivante :

iptables -A POSTROUTING -t mangle -p tcp –sport 7 -j ROUTE –gw 1.2.3.4 –tee

Nous verrons dans un prochain billet comment utiliser ce trafic avec un IDS.

Archives Posts

Déploiement Ntop

avril 30th, 2008 by Corbier

Présentation de l’outil Ntop

Ntop est un outil d’analyse réseau permettant de surveiller un parc informatique en temps réel. Toutes les données et statistiques sont représentées via une interface Web.

Quelques fonctionnalités de Ntop :

  • Tableau des hosts connus
  • Utilisation des protocoles réseaux
  • Charge bande passante par host
  • Graphes journaliers, hebdomadaire, mensuels, annuels

Installation Ntop

Ntop s’installe en ligne de commande :

Installation du package

apt-get install ntop

Vérification de la version

apt-cache policy ntop

Ntop est maintenant installé.

Renseigner le mot de passe Admin permettant de gérer l’interface Web Admin :

ntop -A

Pour lancer ntop, plusieurs possibilités de démarrage :

  • -i : défini l’interface de capture (Possibilité de mettre plusieurs interfaces séparés d’une virgule)

  • -w : permet de spécifier l’adresse IP du serveur ntop suivi du port

  • -W : permet de spécifier également une IP mais cette fois-ci en HTTPS

  • -d : permet de démarrer ntop en daemon

  • -u : défini l’utilisateur (par défaut l’utilisateur ntop est créé)

Dans mon exemple, je vais lancer ntop en daemon sur l’interface eth0 et eth1 sur mon serveur 192.168.0.1 en https avec le port 3001 :

ntop -u ntop -d -i eth0,eth1 -W 192.168.0.1:3001

L’utilisateur ntop doit être spécifié dans la commande afin d’avoir les droits nécessaires pour visualiser toutes les stats. Puis, si vous ne lancez pas ntop en daemon, vous devrez arréter le service manuellement (kill) au lieu de le faire via le daemon (/etc/ini.d/ntop stop).

Il est possible maintenant d’attaquer le serveur en https. Ntop intègre son propre serveur Web, il n’y a pas besoin d’installer un serveur Apache à coté.

https://votre_site:3001

Interface Web

Plusieurs onglets sont disponibles sur l’interface :

  • About : tous les informations sur Ntop, comment ça marche, …
  • Summary : récapitule toutes les informations sous forme de stat
  • All protocols : récapitule les informations par host et par protocoles
  • IP : défini l’ensemble du trafic IP
  • Media : utile pour le fibre channel et les sessions SCSI
  • Utils : permet de dumper les données en XML si Ntop a été compilé avec le xml et de voir les logs de ntop
  • Plugins : possibilité de rajouter des plugins à Ntop (NetFlow, RRD, …)
  • Admin : interface pour gérer les options de Ntop et toutes les préférences Admin

Dans le cas où l’on capture avec plusieurs interfaces réseaux, l’interface Web affiche les stats d’une seule interface. Pour switcher, il suffit de cliquer sur l’ongler Admin puis Switch NIC. L’interface Web vous affichera les interfaces disponibles.

Mirroring de port

Ntop permet de sniffer un réseau IP. Si la partie sniffée est un réseau IP avec Hub, il n’y a pas de problème car tous les paquets transitent sur tous les ports. Par contre, la plupart des réseaux utilisent aujour’hui des switchs. Dans ce cas, il faut dupliquer le trafic vert le port où se trouve le serveur Ntop.

Sur un switch Cisco, il faut configurer le SPAN permettant de récupérer le trafic que l’on souhaite vers un port de destination :

Dans mon exemple, j’utilise un switch Cisco Catalyst 2950. Ma sonde se trouve sur le port Fa0/11 et je veux dupliquer le trafic du port Fa0/12 et FA0/14 :

monitor session 1 source interface Fa0/11

monitor session 1 destination Fa0/12

monitor session 1 destination Fa0/14

Afficher votre configuration (sh run) pour voir si les commandes ont bien été appliquées et surveiller si Ntop récupère bien le trafic.

Filed under Linux having 2 Comments »

Archives Posts

Forensic sur log apache avec pyflag

avril 17th, 2008 by Corbier

Contexte

Dans le cadre de mon travail je suis parfois obliger de faire des retours sur incident dans le cadre de dysfonctionement ou d’attaque.

J’ai donc choisi d’utiliser pyflag.

L’installation se fait facilement a coup de ./configure make make install

Récupération des log’s

J’ai donc récupéré les logs httpd sur le serveur du client ainsi que les logs tomcat. Le problême constaté est que le service tomcat tombe régulièrement (genre tous les deux jours).

Une fois pyflag configuré, il nous reste à nous connecter à l’adresse http://127.0.0.1:8000

Afin d’intégrer les log apache, il est nécessaire de créer un log Preset qui contiendra l’ensemble des log à analyser.

Un assistant apparaît pour injecter les logs. Quelques points me semble essentiel.

Sélectionnez Apache Log ;)

Ainsi que le format debian_forensic cliquez sur next et les logs apparaissent sous la forme de tableau

Ensuite il nous reste a nommer notre preset.

Cliquez sur Load a Log file

Sélectionner les logs a injecter dans le base mysql

L’upload est assez rapide.

Je peux donc travailler sur mes log’s

La suite au prochaine épisode :p

« Previous Entries