Ici je présente une solution de QoS pour un LAN qui se trouve derrière une freebox révolution en mode bridge. En effet, Il faut que tout le traffic sortant passe par notre serveur pour lui appliquer des règles QoS.

Le MTU est par défaut a 1500 pour ethernet. Free utilisant la norme IPoA pour son adsl (dégroupés), pas besoin de descendre le MTU a 1492 comme c’est le cas en PPPoE.

En revanche, pour ce qui est de l’ipv6, étant donné qu’il est encapsulé dans des paquets ipv4, il faut enlever 20 octets d’entete ipv4. (proto 41)

Aussi, le RouterAdvertisement envoyé par la freebox envoie une valeur de MTU égale a 1480.

Mais alors comment positionner un MTU a 1480 spécifiquement pour l’ipv6, tout en gardant 1500 en ipv4 ? # ip -6 route change default via fe80::XXXX mtu 1480 dev eth0

Avec fe80::XXXX étant la gateway, ou l@ipv6 LinkLocal de la freebox.

DKIM

Choisir un "selector", une chaine de caractère, on peut choisir nom-tld mais ce n'est pas obligatoire.

Dans /etc/exim4/exim4.conf.template, juste au dessus de la configuration remote_smtp.

DKIM_DOMAIN = nom.tld DKIM_SELECTOR = nom-tld DKIM_PRIVATE_KEY = CONFDIR/dkim.private.key DKIM_CANON = relaxed

Prendre en compte et restarter exim4.

update-exim4.conf && service exim4 restart

Generer ses clefs priv/pub :

cd /etc/exim4

openssl genrsa -out dkim.private.key 1024

openssl rsa -in dkim.private.key -out dkim.public.key -pubout -outform PEM

chmod 640 dkim.p*

chown root:Debian-exim dkim.p*

Mettre a jour le DNS :

#ici le selector est nom-tld, et la chaine p=... est la clef publique en une ligne

nom-tld._domainkey         IN     TXT   "v=DKIM1; k=rsa ;p=A4GNADCBiQKBgQCzuV+VWaunjs39HIyCP8LMfr1HasOAoefxGSdKgshDFXl6kZ1qHupVsnFK62LeP0JwB" _domainkey         IN     TXT   "t=y; o=~;" _asp._domainkey    IN     TXT   "dkim=all" _adsp._domainkey           IN     TXT   "dkim=all"

Ensuite, tester en envoyant un mail a :

[email protected]

[email protected]

[email protected]

DMARC

Mettre a jour le DNS :

An example for testing if incoming mail is accepted over TLS :

Comment  s'y connecter en port serie : #screen /dev/ttyUSB0 115200

puis faire entrer jusqu'a obtenir le prompt de la ROM.

Booter :

setenv bootcmd_mmc 'mmc init; ext2load mmc 0:1 0x00800000 /uImage; ext2load mmc 0:1 0x01100000 /uInitrd' setenv bootargs console=ttyS0,115200 run bootcmd_mmc; bootm 0x00800000 0x01100000' saveenv

Dovecot est un dameon IMAP et POP3 simple, qui fait le job avec un minimum de complexité.

Voici une configuration IMAP ou les mails sont enregistrés dans les répertoires Maildir des users, et leurs mots de passe sont propes a dovecot (donc différents de celui du système (pam) et de celui du MTA (exim, postfix...))

L'avantage de différencier le mot de passe imap de celui du système, réside dans le fait que les mots de passe imap sont souvent enregistrés en clair dans les clients de messagerie ce qui n'est pas souhaitable pour un mot de passe système.

sur debian wheezy:

#apt-get install dovecot-imapd

Puis dans /etc/dovecot/conf.d/10-mail.conf, renseigner mail_location = maildir:~/Maildir

Puis dans/etc/dovecot/conf.d/10-auth.conf dé-commenter !include auth-passwdfile.conf.ext

Enfin, créer un fichier :

4 -rw-r----- 1 root dovecot 102 févr. 23 13:56 /etc/dovecot/users

qui contient:

monlogin:{CRAM-MD5}665dc81eca19ef0c76d2ba1ae712dbbb4eb0a4a61bfb4cd34aad86015decd1c4:1000:1000::/home/monlogin monlogin2:{CRAM-MD5}a356cbd74651ae712dbbb4eb0a4a61bfb4cd34aad86015dec87326abef653622:1001:1001::/home/monlogin2

le passwd sera généré via cette commande :

#doveadm pw -u monlogin

redémarrer dovecot 

#service dovecot restart

Tip: pour désactiver l'écoute sur le port 143, c'est ici

Config SSL :

Gandi ne propose pas de faire MX secondaire pour ses clients.

Toutefois il propose un service de mails inclus avec le nom de domaine, donc si on héberge soi-même ses mails, on peut l'utiliser comme secours en cas d'indisponibilité du serveur de mail principal.

Il faudra donc au préalable avoir crée un compte mail [email protected] dans son compte dns gandi.

Ici on définit les serveurs de mail de gandi avec une moindre priorité :

# dig -t mx mondnsgandi.fr +short 10 mail.mondnsgandi.fr. 90 fb.mail.gandi.net. 80 spool.mail.gandi.net.

Ensuite il suffit de récupérer les mails ayant atteri chez gandi avec l'outil fetchmail.

Creer un fichier fetchmail.conf contenant:

poll mail.gandi.net protocol imap username [email protected] password monmotdepasse

Puis lancer la commande suivante depuis le serveur de mails principal :

# fetchmail -f fetchmail.conf -S localhost -ak -v

-S pour envoyer a localhost les mails recus par gandi, ils passeront donc par l'antispam du serveur de mails princpal, -a pour recevoir tous les mails, -k pour garder les mails recus coté gandi, -v pour voir que qu'il se passe.

Comment ca marche ? Je recois une connexion de l'adresse ip 178.41.131.179 sur le serveur smtp, que je soupconne d'etre un vilain spammeur.

Avant d'aller plus loin dans la discussion SMTP, je vérifie auprès d'un serveur dnsbl si cette adresse ip est référencée comme sujette a l'envoi de spams.

Un serveur dnsbl est un serveur dns qui répond par un champ NXDOMAIN si l'adresse est "clean" et par une adresse ip 127.0.0.x si l'adresse est "not clean".

Demandons au dnsbl spamhaus (il en existe beacoup d'autres) si l'adresse ip 178.41.131.179 peut etre considérée comme fiable

# dig -t any 179.131.41.178.sbl-xbl.spamhaus.org +short 127.0.0.4 "http://www.spamhaus.org/query/bl?ip=178.41.131.179"

la réponse 127.0.0.4 indisque que cette @ip ne devrait pas envoyer des mails.

La meme chose avec un serveur de gmail:

# dig  43.160.85.209.sbl-xbl.spamhaus.org +short

Pas de réponse, on considère alors que ce serveurs est clean

IPV4

#Purge et comportement par défaut

iptables -F iptables -X iptables -P FORWARD DROP iptables -P INPUT DROP iptables -P OUTPUT DROP #On jette des paquets mal formés iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

#On accepte les connexions existantes iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state INVALID -j DROP #Rzo local et localhost iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT #Block IP particulières #iptables -A INPUT -s 173.242.112.12 -j DROP #iptables -A INPUT -s 213.123.197.232 -j DROP #On ouvre des services comme Jabber/xmpp par exemple iptables -A INPUT -p tcp -m multiport --dports 5222,5269,5000 -j ACCEPT #On jette les paquets n'ayant pu trouver leur bonheur iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset iptables -A INPUT -p udp -j REJECT

#On log ce qui aurait réussi a passer iptables -A INPUT -j LOG --log-prefix '[input]:' #Output iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -s 192.168.0.0/24 -j ACCEPT iptables -A OUTPUT -j LOG --log-prefix '[output]:'

IPV6

L'actualité nous rappelle de toujours chiffrer ses communications autant que possible.

Avec PGP dans pour les e-mails : Plugin Enigmail pour Thunderbird et FireGPG pour Firefox (donc les webmails)

Avec le plugin OTR pour chatter :Plugin OTR pour pidgin

Ça y est, le premier bocage de site web en France pour le compte de ayants droits a lieu. Il y avait déjà certains sites bloqués - comme romecasino.com - mais c'est une première dans ce cas, car pour le compte d’intérêts privés. Plus d'informations sur le site de la quadrature du net.

Vérifions, comment s'opère ce blocage sur une connexion free:

$ dig -t a dpstream.tv @freebox +short 127.0.0.1

La réponse DNS fournie par free ment, et renvoie localhost.

(les autres FAI doivent probablement mentir aussi, c'est une décision de loi qui leur a imposé)

Sur un DNS qui ne ment pas :

$ dig -t a dpstream.tv +short

190.93.243.96 141.101.123.97 190.93.240.97 141.101.112.97 141.101.113.97

Donc pour contourner ce problème, madame michu qui regarde du streaming a longueur de temps peut renseigner d'autres dns que ceux de son FAI francais dans son PC (ou dans la config de sa freebox).

Par exemple, les dns de French Data Network:

IP:  80.67.169.12

IP6: 2001:910:800::12

Pour allonger la durée de vie et les performances des disques SSD, il faut activer le TRIM

Le format de system de fichiers XFS supporte le TRIM via l'option discard, a renseigner dans /etc/fstab.

Cependant, une exception pour le FS /. L'option discard doit etre passée directement au montage inital. (mount -o remount,discard / ne fonctionnera pas).

Il suffira donc de passer le paramètre "discard" pendant la phase de boot, en éditant le fichier /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="rootflags=discard quiet"

puis

$ update-grub

pour prise en compte.

Au redemarrage, on s'assurera que le TRIM est bien pris en compte :

$ mount |grep discard /dev/mapper/corsair-wheezy on / type xfs (rw,relatime,attr2,delaylog,discard,noquota)

Edit:

Il faut intégrer le trim dans toutes les couches inférieures au FileSystem

Pour l'intégrer dans LVM : dans /etc/lvm/lvm.conf mettre l'option 

issue_discards = 1

Pour l'intégrer dans LUKS : /etc/crypttab mettre le paramètre

home /dev/volgrp/homewheezy none luks,discard

Pour prendre en compte les modifications au prochain reboot :

Les logs system affichent parfois la date au format "secondes depuis 1erJanvier 1970..."

[1383840925] unbound[2509:1] info: ::1 1.0.168.192.in-addr.arpa. PTR IN

Pour voir a quelle date correspond 1383840925 :

$ date -d '@1383840925'