Gradew

LDAP integration is generally easily done. There is however a configuration step that is often left aside on forums or tutorials.Here’s what should be done:

1. Add “ldap” to /etc/nsswitch.conf in the passwd, shadow and group sections
2. Configure /etc/ldap.conf to match your LDAP configuration; it mainly consists of IP and root DN(dc=thingy,dc=com)
3. (often-forgotten-step right here): you need to add the following line to /etc/pam.d/system-auth so that users may authenticate against the LDAP directory:

auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass

Depuis plusieurs mois, on peut observer sur énormément de réseaux IRC un phénomène assez amusant; des bots répondant aux doux noms de paula35, gigi31 ou encore clochette et mbulleg se connectent au réseau, semblent ne rien faire pendant 2/3 minutes, puis quittent le réseau.

Pris d’un désir d’en finir avec eux, j’ai dégainé mon fidèle PuTTY:

nohup tcpdump -vv -s 0 -w cmon-stupid-fecking-bots.pcap 'tcp[2:2]=6667' &

afin de voir de quoi il en retourne. En moins de 24h, premiers résultats, et concluants avec ça: ils font bien quelque chose, mais c’est au niveau de la couche TCP que ça se passe. La conversation suivant le protocole IRC se résume en effet à un NICK, USER puis un QUIT, mais c’est ce qui se passe avant le QUIT qui est intéressant. J’ai pu en effet observer une totalité de 1342 erreurs de protocole TCP: Bad checksum, SYN, FIN, RST, bad checksum (plus de 30 fois), et re-belote.

On va appeler ça une pitoyable tentative de DoS, car c’est pas avec sa petite bande passante qu’il fera paniquer un serveur. Mais ça mérite quand même un DROP sur les firewalls.

Admins IRC, sus à 212.198.248.33 [212-198-248-33.rev.numericable.fr] et 90.25.50.57 [ANantes-257-1-35-57.w90-25.abo.wanadoo.fr].

Edit: Comme me l’a suggéré Sendell de l’équipe d’EpiKnet, il peut être utile d’avoir recours à des services de blacklist, comme bopm, qui commencent à recenser ces IP devenant visiblement de plus en plus nombreuses, du moins suffisamment pour qu’on commence à s’en soucier.

Depuis peu, et afin de permettre d’éliminer tous ces Spams que l’ont recoit chaque jour, Microsoft a décidé de lancer un nouveau concept génialissime en adhérant au programme Sender Score.

Ayant décidé que le Sender ID ne suffirait plus (ce dernier empêchant déjà tous les hébergements mutualisés d’envoyer des mails vers MSN/Hotmail), Microsoft a donc recours à ce fameux Sender Score. Quel en est le principe? Très simple: Allez donc faire un tour sur http://www.senderscorecertified.com/ pour vous rendre compte qu’il vous faut donc désormais une certification “Sender Score” qui est bien sûr payante, afin d’être reconnu comme expéditeur légitime.

Pour ceux qui ne sont pas “Sender Score Certified”, il faut juste espérer que les mails d’inscriptions aux forums, etc.. passent au travers des mailles du filet.

Pour finir, deux extraits de la conversation que j’ai eue avec eux par e-mail:

“While using the SNDS tool, enrollment in the JMRP or having your IPs registered with Sender ID will not allow emails from your mail servers to bypass our filters, these are in place to help legitimate companies deliver their emails to Hotmail Customers.”

“The troubleshooting steps in this email are recommendations only. Microsoft makes no guarantees that following these steps will guarantee deliverability to MSN, Hotmail, or Live.com customers.”

En résumé: Microsoft ne GARANTIT PLUS l’acheminement correct des e-mails vers leurs serveurs .

On n’en finit plus, cette fois c’est un nouveau serveur IRC qui vient de voir le jour.

Destiné dans un premier temps à accueillir les visiteurs du site de mon groupe (Parad1gm.net), il s’est vu remanier ses objectifs (un tant soit peu ambitieux, certes). En effet, la petite équipe constituée en un temps assez court se sent d’attaque pour gérer des utilisateurs de tous horizons (langues officielles parlées: français, anglais et allemand… on a laissé tomber le roumain :p Sisi, je vous l’assure, on a eu un canal officiel pour les Roumains, avant que son responsable ne tente un take-over ridicule… :/).

Bref, ce réseau n’a guère l’audace d’oser vouloir se mesurer à d’autres réseaux tels qu’EpiKnet et Undernet, dont les compétences ne sont plus à prouver. Je suis néanmoins agréablement surpris de voir que nous comptons dans l’équipe un ancien administrateur de tchat d’un FAI comptant pour environ 20% des parts de l’internet familial (mmmh, j’hésite à révéler le nom…:p), ou encore admin/modérateur d’un site de scripting bien connu… Bref, une petite équipe assez déjantée, prête à vous accueillir sur ce micro-réseau… disons-le carrément: sympatoche! (/me sifflotte…)

Si ça vous tente de venir y faire un tour, c’est par là:

irc.crystalirc.net:6667 (ou 6697 pour les connexions sécurisées)

Pour info, il s’agit de la dernière version d’Unreal 3 avec les services Anope (Nickserv, Chanserv, etc.).

Vous avez envie de tuer votre eggdrop parce qu’il fait n’importe quoi? C’est normal .

Le rehash du bot suffit en général à résoudre bien des problèmes, sauf dans certains cas comme le changement d’un flag lié à un canal de discussion (+/-enforcebans, par exemple). Les eggdrops ayant la fâcheuse tendance à mettre en cache leurs flags dans le fichier “.chan”, il est en général préférable d’effacer tout simplement ce fichier avant de demander au bot de redémarrer, afin de le forcer à recharger la configuration correctement. Ainsi:

• à partir de votre shell où se trouve l’eggdrop: rm -f <fichier .chan>
• sur IRC: /msg <nom du bot> rehash <mot de passe>

Je ne croyais pas ça possible, mais finalement…. ben si: il y a encore plus énervant que de recevoir des e-mails “légitimes” dans son dossier Spam. On peut aussi ne rien recevoir du tout, et il est désormais tout à fait possible que l’expéditeur n’en soit même pas averti.

Ce problème (visiblement à ce jour de plus en plus courant) est dû à une mesure de sécurité qui a été adoptée récemment, notamment par America On Line ou encore Hotmail: les e-mails doivent obligatoirement être envoyé de serveurs de messagerie dont la configuration DNS possède un champ SPF correctement configuré, afin de s’assurer que l’expéditeur du mail est bien légitime (cf. article Wikipedia).

Malheureusement, nombreux sont les hébergeurs de messagerie qui n’ont pas correctement rempli leurs fichiers de zone DNS. Pour illustrer mon propos, voici le rapport d’analyse DNS de l’hébergeur La Poste. On constate que le champ SPF n’est pas complété (du tout!). La conséquence? Eh bien… si “toto@laposte.net” veut envoyer un e-mail à “titi@hotmail.com”, ce dernier ne le recevra jamais, en tout cas en l’état actuel des choses. C’est aussi le cas des solutions d’hébergement mutualisé; ils sont étonnament fort peu nombreux à se soucier la configuration de leurs zones DNS.

Pour ceux qui ont la chance d’avoir leur propre serveur dédié, le problème est très simple à résoudre: la syntaxe SPF étant (très!) obscure, Microsoft met à disposition un outil en ligne de génération de champ SPF.

Par exemple: supposons que vous administriez un serveur de messagerie “mail.exemple.com” dont l’adresse IP est 1.2.3.4. Le champ SPF doit impérativement respecter la syntaxe suivante:

v=spf1 a mx ptr ip4:1.2.3.4 mx:mail.exemple.com ~all

Un petit /etc/init.d/bind9 restart, et le tour est joué!!! Votre serveur sera désormais considéré comme “légitime” auprès des hébergeurs effectuant cette vérification.