Not So Frequently Asked Questions

Tu has configurat l’autenticació en el correu sortint (SMTP-AUTH) en el teu servidor de correu (Postfix en el nostre cas) i funciona perfectament. Però de sobte quan el poses en producció els usuaris es queixen que no poden enviar correus.

Qué fas? Doncs intentes seguir pas a pas per comprovar el funcionament. És a dir, fas un telnet al port 25 i segueixes pas a pas l’autenticació. La conversa va més o menys així (les línies que comencen per “->” són les que escric jo, sense la part de “->”):

[email protected]:~$ telnet smtp.example.com 25
Trying 1.2.3.4...
Connected to smtp.example.com.
Escape character is '^]'.
220 smtp.example.com ESMTP server ready
-> EHLO example.com
250-smtp.example.com
250 AUTH CRAM-MD5 DIGEST-MD5
-> AUTH FOOBAR
504 Unrecognized authentication type.
-> AUTH CRAM-MD5
334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
-> ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
235 Authentication successful.


Doncs tot funciona… Aleshores li dius al client que faci el mateix, però et diu que no veu la línia “220 smtp.example.com ESMTP server ready”, que només veu una tira d’asteriscs. Ho proves tu mateix, i efectivament és així. I a més a més, no reconeix la comanda AUTH!!


[email protected]:~$ telnet smtp.example.com 25
Trying 1.2.3.4...
Connected to smtp.example.com.
Escape character is '^]'.
220*******************************************************0*2******0***********************
2002*******2***0*00
-> EHLO example.com
250-smtp.example.com
250 AUTH CRAM-MD5 DIGEST-MD5
-> AUTH FOOBAR
500 5.5.2 Error: bad syntax
-> AUTH CRAM-MD5
500 5.5.2 Error: bad syntax


Què passa? Per què aquesta diferència? Doncs sembla que la resposta és senzilla…

Cisco Systems posa a tots els seus routers PIX un protocol per evitar atacs i afegir seguretat. Aquests protocols intercepten totes les comandes que s’envien cap el servidor i les tradueixen, fent de proxy. Aquest protocol es diu MailGuard, i només accepta les comandes bàsiques de SMTP, no pas les exteses ESMTP , fent-lo incompatible amb SMTP-AUTH. Així que la unica manera d’aconseguir fer servir SMTP-AUTH es deshabilitar-ho.

Fer-ho és facil, perquè la comanda és així de senzilla, connectats per telnet al PIX:

no fixup protocol smtp 25
write mem


El més complicat es adonar-se que algú pel mig esta modificant les comunicacions amb el servidor… Pero un cop descobert, problema solucionat!

Ara ja fa un any vam comentar com fer servir Kubuntu 8.10 des d’un USB. Ara, un any després, em trobava amb el mateix problema, amb la Kubuntu 9.10. Peró des d’aleshores hem fet alguns avenços.

La pròpia Ubuntu porta un programa per fer que un USB arrenqui amb ella mateixa. Al menu hi ha l’aplicació “K-> Aplicacions -> Sistema -> USB Startup Disk Creator” (o també amb la comanda /usr/bin/usb-creator-kde), que es molt senzilla.

Escollim la ISO, escollim el dispositiu USB, i fem click a “Crea un disc d’arrencada”. Esperem una estoneta i ja podem arrencar des d’aquest pendrive.

Peró això nomes serveix per Ubuntu… i la resta de distribucions? Doncs existeix el programa unetbootin, que fa el mateix amb totes les distribucions (bé, com a mínim amb moltes d’elles).

Aqui escollim la distribució, li diem on esta la imatge ISO, a quin dispositiu volem escriure, i s’encarrega de tot.

Evidentment, això només serveix si ho volem fer des de linux. Si voleu fer-ho des de windows, aleshores millor demaneu consell als nostres amics de pendrivelinux

Pot passar que la teva feina faci que no puguis actualitzar el teu blog. Fins i tot arribes a no visitar-lo. Aleshores arriba una horda de spammers rabiosos, amb dèria per inundar el teu blog venent Viagres, Cialis i merda semblant. Aquest ha estat exactament el cas d’aquest blog. Resultat? Més de 350.000 comentaris de publicitat, la base de dades plena, no es podien afegir comentaris des de feia mesos… un desastre.

He esborrat els comentaris per tornar a començar des de 0. Peró cinc minuts després ja tenia 20 comentaris SPAM nous! Evidentment s’ha de fer quelcom perquè no torni a passar…

He implementat el sistema Mollom, que a mes de ser capicua (un palíndrom, que se’n diu), es molt potent: fa un anàlisi del text que s’escriu, i si desperta la mes mínima sospita de ser SPAM, aleshores demana un CAPTCHA. Des d’aleshores no ha aparegut cap comentari de SPAM al blog.

La instal·lació ha estat senzillíssima. Primer ens hem de registrar a la web mollom.com, i donar d’alta un un nou site (Site manager -> Add new site). Escollim “Mollom free” i després escollim les quatre dades que ens demana. Al següent pas ens donarà dues claus que haurem d’afegir al nostre blog mes endavant.

Un cop fet això, ve la part del teu site. S’ha de descarregar el modul del projecte mollom a drupal.org, descomprimir-ho al directori de móduls de Drupal, i activar-ho a “Administer -> Site building -> Modules”. Un cop activat, anem a la part de configuració (Administer -> Site configuration -> Mollom) i allá hi posem les claus que ens han donat abans, i configurem quan volem que s’activi el filtre antispam.

Et voilà! Ja ho tenim activat. Hem acabat amb l’SPAM en 5 minuts.

Sembla que el procediment habitual per renovar un certificat per HTTPS a l’IIS es iniciar una petició de renovació, enviar-la a l’entitat certificadora (Verisign, per exemple), esperar l’arxiu de resposta i importar-ho dintre del teu IIS.

Però, què fer si ens envien la renovacio amb un CSR antic? Reps un email amb un tros del tipus:

-----BEGIN CERTIFICATE-----
AoGBAOv4w3UeEEarsyIXsBL1zdBi67fC7jFiqhbs0f7/tDRuvnQvj5V7NF7Awhah
9K3J9fPkOPMfTBMmQCFVTLAlUxioh1jLEZOWDPvrB8h7msO5gM1MpufOh4NRS79J
LvyOKdDtXGfYdVRj/TNpNTFu10wLO2y9o8HAkRUlkCDb/xS3AgMBAAGjggF6MIIB
djAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDBGBgNVHR8EPzA9MDugOaA3hjVodHRw
Oi8vY3JsLnZlcmlzaWduLmNvbS9DbGFzczNJbnRlcm5hdGlvbmFsU2VydmVyLmNy
f4&dBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz
(...)
-----END CERTIFICATE-----


Com importar això dintre del nostre IIS? S’han de seguir aquestes passes:

Primer exportem el certificat actual. Per fer-ho hem d’anar a les propietats del site, a l’apartat “Directory Security”:

Iniciem l’assistent fent click a “Server Certificate” i anem a la següent pantalla:

Fem click a “Next” i anem a la següent pantalla:

On escollirem “Export the current certificate to a .pfx file”. Despres ens demanara on ho volem guardar:

I una contrassenya per l’export. D’aquesta forma ja tenim el certificat exportat.

Si mirem el contingut de l’arxiu, veurem que es binari. Per convertir-ho al mateix format que el que hem rebut per email, podem fer servir openssl, amb aquesta comanda:

openssl pkcs12 -in cert.pfx -out cert.pem


Ens demanarà la contrassenya que hem posat abans al .pfx, i ens demanarà una contrassenya per posar-li a l’arixu .pem resultant.
Si editem aquest fitxer amb qualsevol editor de text, veurem que conté un “certificate” delimitat per les clausules “BEGIN CERTIFICATE” y “END CERTIFICATE”, exactament igual que el que ens han enviat per correu. Només hem de substituir el text de l’anterior certificat pel nou. Un cop ho tinguem, ho hem de tornar a la forma binaria que “enten” l’IIS. Per fer-ho, un altre cop amb openssl:

openssl pkcs12 -export -in cert.pem -out cert-new.pfx


Ens demanarà la contrassenya que li hem posat al .pem, i una altra per posar-li al .pfx resultant.
Ara per posar-ho a l’IIS, primer hem de treure el que hi havia. A la plana de “Directory Security” d’abans hem d’iniciar l’assistent una altra vegada, però aquesta vegada escollir “Remove the current certificate”:

Seguint “next next” acabarem treien el certificat antic:

I ara hem d’importar el certificat nou. En l’assistent veurem que ens ha aparegut una opció que abans no estava: “Import certificate from a .pfx file”:

Ens demanarà quin fitxer volem importar, i haurem d’escollir el cert-new.pfx. Ens demanarà la contrassenya que hem posat, el port on volem que escolti (normalment deixarem el 443) i finalment haurem importat el certificat

Si mirem les propietats, veurem que ha canviat la data d’expiració. Ja tenim el certificat renovat!

Acabo de descobrir que a partir de debian lenny, i a Ubuntu/KUbuntu (no sé si a la 8.04 hi era, pero a la 8.10 segur que hi és), l’aplicacio winexe, de la que vam parlar aqui i feiem servir, per exemple, en els nostres scripts per matar processos o aconseguir una shell remota, s’instal·la amb el paquet wmi-client. És a dir, que per instal·lar-ho només haurem de fer:

apt-get install wmi-client


I llestos! Suposo que per SuSE i RedHat tambe deu estar empaquetada… algú m’ho pot confirmar?