Archives pour la catégorie ‘BSD’

NetBSD : configuration RAID1 avec RAIDframe

Je vais vous guider dans la configuration d’un RAID1 logiciel avec RAIDFrame sous NetBSD. Cette procédure fonctionne également sous OpenBSD (votre noyau devant intégrer le support RAIDframe) ou encore FreeBSD 4/5. Le RAID peut être créé à chaud sans LiveCD et à distance, mais il est recommandé d’avoir un accès au BIOS setup. Si vous ne faites pas d’erreur de calcul ou de frappe, tout se passera bien sinon pensez d’emblée à faire une backup !

La procédure consiste à créer le RAID1 initialement sur le second disque, à y recopier le système et les données « live » du premier disque. Suite à cela, un redémarrage activera le RAID du second disque, auquel le premier disque sera ajouté.

Etape 1 : installation du système

Je débute par l’installation d’un système NetBSD 5.0.1/amd64. Le système est installé sur le premier disque dur SCSI (/dev/sd0) d’une capacité de 8 Go (l’exemple est ici réalisé sous VMware), dont l’ensemble est affecté au slice de NetBSD (partition DOS 0). Au niveau des partitions BSD, je crée le strict minimum par souci de simplification du présent guide : /, swap et  /home.

netbsd# grep sd0 dmesg.boot
sd0 at scsibus0 target 0 lun 0: <VMware,, VMware Virtual S, 1.0>
 disk fixed
sd0: 8192 MB, 1044 cyl, 255 head, 63 sec, 512 bytes/sect x 16777216
 sectors
netbsd# grep sd1 dmesg.boot
sd1 at scsibus0 target 1 lun 0: <VMware,, VMware Virtual S, 1.0>
 disk fixed
sd1: 8192 MB, 1044 cyl, 255 head, 63 sec, 512 bytes/sect x 16777216
 sectors

netbsd# fdisk /dev/sd0
Partition table:
0: NetBSD (sysid 169)
 start 63, size 16777153 (8192 MB, Cyls 0-1044/85/1), Active

netbsd# disklabel -r sd0
# /dev/rsd0d:
total sectors: 16777216

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   8401995        63     4.2BSD   2048 16384     0
 b:    273105   8402058       swap
 c:  16777153        63     unused      0     0
 d:  16777216         0     unused      0     0
 e:   8102053   8675163     4.2BSD   2048 16384     0

La partition d est reservée et correspond au disque dur (la taille de 16777153 correspond bien à la taille du slice NetBSD). La partition c est aussi réservée et correspond au slice NetBSD, englobant toutes les partitions définies par l’utilisateur : a (point de montage /), b (swap) et e (/home). Comme j’utilise tout l’espace disque, la taille de c correspond à celle du disque moins les 63 blocs réservés par l’ID de slice. Ceci se matérialise au niveau de l’offset de c par rapport à d et également de a, qui débute fatalement au  63ème bloc.

A retenir :

  • total sectors = size d
  • size c = size d – 63
  • offset c = offset a = 63

Etape 2 : partitionnement du 2ème disque dur (/dev/sd1)

Le slice NetBSD doit être reproduit à l’identique sur le second disque. Si  les disques ont des tailles différentes, il faut jouer avec fdisk pour créer un slice de la taille de celui du premier disque. Parfois, il est utile d’effacer la table des slices, si le disque a déjà été partitionné :

netbsd# dd if=/dev/zero of=/dev/rsd1d bs=8k count=1

netbsd# fdisk -0ua /dev/rsd1d
Partition table:
0: NetBSD (sysid 169)
 start 63, size 16777153 (8192 MB, Cyls 0-1044/85/1), Active
 PBR is not bootable: All bytes are identical (0x00)

Au niveau des partitions, c’est différent : une unique partition dédiée au RAID est créée. Cette partition va devenir le pseudo-périphérique disque RAID. C’est sur celui-ci que nos partitions /, swap et /home seront créées. RAIDframe impose cette limitation de ne fonctionner que sur une seule partition par disque.

Sur /dev/sd1, on édite la table des partitions et on créé la partition a avec comme type RAID, de taille égale à l’espace disque total moins les 63 blocs d’identification. Pour faire simple, il suffit de dupliquer la ligne de la partition c pour le slice a et y changer le type.

netbsd# disklabel -r -e -I sd1
total sectors: 16777216

4 partitions:
#        size    offset%C

OpenLDAP : reconstruction d'une base suite à une mise à jour

En cas de mise à jour d’une version majeure d’OpenLDAP, voici la procédure à respecter pour reconstruire votre base LDAP.

Etape 1 : export de votre base LDAP :

# /etc/init.d/slurpd stop
# /etc/init.d/slapd stop
# slapcat -l /root/ldapdump.raw
# egrep -v '^entryCSN:' < /root/ldapdump.raw > /root/ldapdump
# mv /var/lib/openldap-data/ /root/openldap-data-backup/

Etape 2 : mise à jour et configuration de la nouvelle version d’OpenLDAP.

Etape 3 : import du dump :

# slapadd -l /root/ldapdump
# chown <ldap_user>:<ldap_user> /var/lib/openldap-data/*
# /etc/init.d/slapd start

FreeBSD 7 : identificateurs d'objets SNMP

Les identificateurs d’objects OID SNMP sous FreeBSD 7 ont changé.

Voici la liste des plus utilisés :

CPU / User : .1.3.6.1.4.1.2021.11.50.0
CPU / Nice : .1.3.6.1.4.1.2021.11.51.0
CPU / System : .1.3.6.1.4.1.2021.11.52.0
Load / 1 min : .1.3.6.1.4.1.2021.10.1.3.1
Load / 5 min : .1.3.6.1.4.1.2021.10.1.3.2
Load / 15 min : .1.3.6.1.4.1.2021.10.1.3.3
Memory / Buffers : .1.3.6.1.4.1.2021.4.14.0
Memory / Cache : .1.3.6.1.4.1.2021.4.15.0
Memory / Free : .1.3.6.1.4.1.2021.4.6.0
Network / All : .1.3.6.1.2.1.31.1.1.1

FreeBSD : mise à jour en 7.2-STABLE

Suite à la sortie de la version stable 7.2 de FreeBSD, j’ai mis à jour mon système 7.1-STABLE depuis les sources. A des fins de mémorisation, je résume ici l’ensemble des commandes saisies.

# cp /usr/share/example/cvsup/stable-supfile /usr/local/etc/cvsup/supfile
# ee /usr/local/etc/cvsup/supfile
# cd /usr/src
# csup -g -L 2 /usr/local/etc/cvsup/supfile
# make -j4 buildworld
# make buildkernel
# make installkernel
# cd /boot
# mv kernel kernel.test
# mkdir kernel
# cp kernel.old/* kernel/
# nextboot -k kernel.test
# reboot
# cd /boot
# mv /boot/kernel /boot/kernel.old
# mv /boot/kernel.test /boot/kernel
# cd /usr/src
# mergemaster -p
# make installworld
# mergemaster
# pwd_mkdb /etc/master.passwd
# reboot

Un peu d’explication tout de même : je télécharge les sources depuis un dépôt CVSUP, compile le nouveau monde, compile et installe un noyau GENERIC issu du nouveau monde. Je fais en sorte de ne booter qu’une fois sur le nouveau noyau, afin de pouvoir rebooter sur le noyau précédent en cas de pépin. Si tout est OK, je remplace le noyau par défaut par le nouveau. J’installe ensuite le nouveau monde. Pour finir, je mets à jour les fichiers de configuration, regénère la base des identifiants et je reboote sur un FreeBSD 7.2 tout propre.

# uname -a
FreeBSD freebsd.mydomain.lu 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed May  6 01:26:03 CEST 2009
   bhuisgen@freebsd.mydomain.lu:/usr/obj/usr/src/sys/GENERIC  i386

Si quelqu’un connait un outil similaire à nextboot pour Linux je suis preneur.

Documentation de référence FreeBSD :
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
http://svn.freebsd.org/base/releng/7.2/UPDATING

htscanner : patch correctif pour la version 0.9.0

htscanner est une extension PHP permettant de parser les fichiers .htaccess d’Apache, afin d’y récupérer les variables d’exécution fixées par php_flag et php_value. Cette extension est indispensable dans le cadre d’une exécution PHP par CGI car ni le serveur Web ni php-cgi ne peuvent les récupérer.

Ayant déjà soumis un patch pour fixer la récupération des valeurs entre simple/double quotes, en voici un nouveau pour la version 0.9.0 qui n’est toujours pas exempte de problèmes avec son parseur.

patch-htscanner-parser-20090401

- interprétation correcte des retours à la ligne (EOL) quelque soit la plateforme.
- restriction du parsing pour les php_flag, seules les valeurs on/off sont acceptées (cf documentation PHP).

Mise à jour du 2009-04-05 : j’ai intégré ce patch dans la version CVS ; vivement la release 0.9.1 !

suPHP : patch de désactivation du check "directory owner"

suPHP est un programme permettant de limiter l’exécution des scripts PHP à un UID spécifique afin de protéger le serveur d’hébergement de toute attaque de vulnérabilité. L’UID est modifié pour correspondre par exemple à celui du serveur Web, du propriétaire du fichier PHP ou encore un UID spécifique.

suPHP s’intercale entre Apache et PHP par le biais d’un handler spécifique, qui mappe l’extension d’un fichier au binaire suphp chargé de modifier les permissions UID puis d’appeler l’interpréteur CGI déclaré pour ledit fichier. Ce mécanisme permet d’exécuter des scripts PHP 4 / 5 / 6 depuis la même instance Apache, ce qui est fort utile dans le cas d’un serveur mutualisé.

Seul bémol : dans le cas d’un serveur Web de développement, il peut perturber les utilisateurs normaux qui ne peuvent modifier les droits d’accès des scripts PHP. Cela touche en particulier le répertoire parent car suPHP vérifie que son propriétaire correspond bien à l’UID configuré. A moins de pouvoir modifier ces droits, une erreur d’exécution est générée lors de la navigation :

Internal Server Error
Directory /var/www/site.fr/html/test is not owned by apache

Afin de contourner ce problème (plutôt marre d’entendre « je peux pas, j’ai pas les droits Apache »), j’ai donc fait un petit patch ajoutant l’option check_directory_owner à suPHP afin de désactiver ce test. L’option est à fixer dans le fichier de configuration :

; Security options
check_directory_owner=false # par défaut true
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

Le patch est à appliquer sur la version 0.7.1 de suPHP : patch-suphp-checkownerdirectory-20090328.

FreeBSD 64 bits : statistiques réseaux par SNMP

Les statistiques des interfaces réseaux par SNMP (net-mgmt/net-snmp) ne sont pas directement fonctionnels sous FreeBSD 64 bits (aucun problème pour les OS 32 bits) :

# snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.2.1.31.1.1.1
IF-MIB::ifName.1 = STRING: re0
IF-MIB::ifName.2 = STRING: lo0

Seuls les noms d’interfaces sont renvoyés. Les compteurs systèmes étant codés sur 64 bits et n’étant pas supportés par défaut par SNMP, il faut recompiler le port avec l’option WITH_MFD_REWRITES pour y remédier:

# make deinstall && make clean
# make -DWITH_MFD_REWRITES
# make install
# /usr/local/etc/rc.d/snmpd restart

SNMP peut alors reporter l’ensemble des statistiques :

# snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.2.1.31.1.1.1
IF-MIB::ifName.1 = STRING: re0
IF-MIB::ifName.2 = STRING: lo0
IF-MIB::ifInMulticastPkts.1 = Counter32: 368234
IF-MIB::ifInMulticastPkts.2 = Counter32: 0
IF-MIB::ifInBroadcastPkts.1 = Counter32: 0
IF-MIB::ifInBroadcastPkts.2 = Counter32: 0
IF-MIB::ifOutMulticastPkts.1 = Counter32: 0
IF-MIB::ifOutMulticastPkts.2 = Counter32: 0
IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0
IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0
IF-MIB::ifHCInOctets.1 = Counter64: 86439204
IF-MIB::ifHCInOctets.2 = Counter64: 1355164
IF-MIB::ifHCInUcastPkts.1 = Counter64: 549735
IF-MIB::ifHCInUcastPkts.2 = Counter64: 11430
IF-MIB::ifHCInMulticastPkts.1 = Counter64: 368234
IF-MIB::ifHCInMulticastPkts.2 = Counter64: 0
IF-MIB::ifHCInBroadcastPkts.1 = Counter64: 0
IF-MIB::ifHCInBroadcastPkts.2 = Counter64: 0
IF-MIB::ifHCOutOctets.1 = Counter64: 41458007
IF-MIB::ifHCOutOctets.2 = Counter64: 1355164
IF-MIB::ifHCOutUcastPkts.1 = Counter64: 121314
IF-MIB::ifHCOutUcastPkts.2 = Counter64: 11430
IF-MIB::ifHCOutMulticastPkts.1 = Counter64: 0
IF-MIB::ifHCOutMulticastPkts.2 = Counter64: 0
IF-MIB::ifHCOutBroadcastPkts.1 = Counter64: 0
IF-MIB::ifHCOutBroadcastPkts.2 = Counter64: 0
IF-MIB::ifHighSpeed.1 = Gauge32: 1000
IF-MIB::ifHighSpeed.2 = Gauge32: 0
IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2)
IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2)
IF-MIB::ifConnectorPresent.1 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.2 = INTEGER: true(1)
IF-MIB::ifAlias.1 = STRING:
IF-MIB::ifAlias.2 = STRING:
IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00
IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00

Le monitoring réseau par SNMP est alors possible.

Packet Filter : protection d'attaque SSH par brute force

La technique pour éviter les attaques SSH par brute force avec PacketFilter consiste à ajouter les IP fautives dans une table et d’exclure les IP qui y sont contenues pour les connexions SSH ou de façon globale (petit vilain).

Procédure chef :

  1. déclarer la table qui va contenir les IP bannies
  2. bloquer en début de filtrage les connexions entrantes de ces IP.
  3. ajouter les options de collecte des états des connexions sur les règles que l’on souhaite protéger du bruteforce.
  4. vider la table, en tâche cron par exemple.

Exemple d’un parefeu PF rudimentaire, fait main (70% main droite), autorisant le trafic ICMP et les connexions SSH :

#
# pf.conf
#

# macros
ext_if = "re0" # ou mi0, fa0, sol0 çà dépend
myip = "XX.XX.XX.XX" # comme c'est trop secure

# tables
table <bruteforce> persist {}

# options
set block-policy drop
set skip on lo0 # non ce n'est pas la0
set limit { states 20000, frags 5000, src-nodes 2000 }

# normalization
scrub in all fragment reassemble
scrub all reassemble tcp
scrub in all random-id

#
# rules
#

block all
block quick from <bruteforce>
antispoof quick for lo0

pass out inet proto tcp all flags S/SA keep state
pass out inet proto udp all keep state

pass in on $ext_if inet proto icmp from any to any keep state
pass out on $ext_if inet proto icmp from any to any keep state

pass in on $ext_if inet proto tcp from any to any port 22 flags S/SA keep state (source-track rule, max-src-nodes 8, max-src-conn 8, max-src-conn-rate 10/60, overload <bruteforce> flush global)

Dans le cas où un client se  connecte 10 fois par minute, il est banni et bloqué pour toute nouvelle connexion. Il ne reste plus que de lancer la commande permettant de supprimer les adresses IP enregistrées, ici pour le jour précédent :

# /usr/local/sbin/expiretable -t 24h bruteforce
Haut de page