[Gutl-l] itables
saludos una ves mas jodiendo Gracias a ustedes ya tengo el server pincando bien unque me faltan detalles que lo voy corrigiendo poco a poco necesito una configuracion de iptables que enga dos targetas de red __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] itables
Creo que debes ser más explícito en para que quieres eso. Debes habilitar ip forwarding para que se pase el tráfico entre ambas interfaces. Te voy a mandar uno que está bastante completo al privado con políticas de denegación por defecto. El 02/03/16 07:25, yunie...@espguayabal.transnet.cu escribió: saludos una ves mas jodiendo Gracias a ustedes ya tengo el server pincando bien unque me faltan detalles que lo voy corrigiendo poco a poco necesito una configuracion de iptables que enga dos targetas de red __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix y SASL
El Martes, 1 de marzo de 2016 16:55:53 Arian Molina Aguilera escribió:
> El 01/03/16 a las 16:49, Manuel Mely escribió:
> > On 03/01/2016 02:28 PM, Rommel Rodriguez Toirac wrote:
> >> No me llegó nada :-( Directamente no puedo recibir ni enviar correos
> >> a dominios que no sean .cu y no pueden pasar de 1Mb de tamaño Nada
> >> que nosotros todavía estamos en otra época.
> >
> > De todos modos si pueden seguir el hilo o al menos postear la solucion
> > al problema por aqui mejor. Y si es posible acortar un poco el cuerpo
> > del mensaje (como acabo de hacer en este mensaje)
> > Sobre la solucion... te dejo en buenas manos :)
> >
> >
> > __
> > Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
> > Gutl-l@jovenclub.cu
> > https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
>
> De la propia wiki de Centos Postfix SASL + Dovecot
>
> Configuring SASL in postfix
>
> To configure SASL in postfix, we need to make the following additions to
> /etc/postfix/main.cf:
>
>
> smtpd_sasl_auth_enable = yes
> broken_sasl_auth_clients = yes
> smtpd_sasl_type = dovecot
> smtpd_sasl_path = private/auth
> smtpd_sasl_security_options = noanonymous
> and add permit_sasl_authenticated to our smtpd_recipient_restrictions
> section of /etc/postfix/main.cf (if you don't have a
> smtpd_recipient_restrictions section, then the following example will
> work fine):
>
>
> smtpd_recipient_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination
> Next we need to configure auth default in the authentication processes
> section of /etc/dovecot.conf. Uncomment and/or add the following lines
> as necessary (be careful as this section is heavily commented, some
> entries already exist, others are commented out and need uncommenting
> such as socket listen):
>
>
> auth default {
> mechanisms = plain login
> passdb pam {
> }
> userdb passwd {
> }
> user = root
> socket listen {
>client {
> path = /var/spool/postfix/private/auth
> mode = 0660
> user = postfix
> group = postfix
>}
> }
> }
> Restart dovecot and reload postfix configuration setting:
>
>
> service dovecot restart
> postfix reload
>
> De la wiki de debian
>
> PostfixAndSASL
>
> Translation(s): none
>
> Simple Authentication and Security Layer (SASL) with Postfix SMTP
>
>
> Tabla de Contenidos
> SASL authentication in the Postfix SMTP server
> Implementation using Cyrus SASL
> Using saslauthd with PAM
> Using auxprop with sasldb
> Troubleshooting tip
> Implementation using Dovecot SASL
> SASL authentication in the Postfix SMTP client
> Postfix and sbcglobal/yahoo/att
> SASL authentication in the Postfix SMTP server
>
>
> Implementation using Cyrus SASL
>
> Using saslauthd with PAM
> Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM
> in a chroot() environment.
>
> Note: The following steps have been carried out and verified on a Debian
> 7.1 system (Jan. 2015).
> Note: SASL2 (saslauthd) creates a socket in its working directory.
> Postfix (smtpd) needs access to this socket. If smtpd is running
> chroot()ed (what is standard on Debian) saslauthd must run within this
> chroot() environment also (though not being chrooted itself). While this
> is fine for smtpd there are other services (Cyrus imapd for example)
> which expect saslauthd 's socket at its "regular" location
> (/var/run/saslauthd).
> The recommended way to solve this is to run separate saslauthd processes
> for Postfix and for others. Debian is prepared for this. Alternatively a
> symlink-trick can be used. See below. Or you can disable chroot()ing by
> editing the chroot columns in /etc/postfix/master.cf.
>
> Install libsasl2-modules, postfix, sasl2-bin
> Create a file /etc/postfix/sasl/smtpd.conf:
> pwcheck_method: saslauthd
> mech_list: PLAIN LOGIN
> Setup a separate saslauthd process to be used from Postfix:
> Create a copy of saslauthd's config file
> ~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix
> and edit it
> START=yes
> DESC="SASL Auth. Daemon for Postfix"
> NAME="saslauthd-postf" # max. 15 char.
> # Option -m sets working dir for saslauthd (contains socket)
> OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"#
> postfix/smtp in chroot()
> (See /usr/share/doc/sasl2-bin/README.Debian.gz)
> Alternatively you can replace the directory /run/saslauthd with a
> symlink to /var/spool/postfix/var/run/saslauthd
> ~# rm -rf /run/saslauthd
> ~# ln -s /var/spool/postfix/var/run/saslauthd /run/saslauthd
> This is a quick-and-dirty hack, useful only for testing purposes. After
> the next reboot the contents of /run will be reset.
> Create required subdirectories in postfix chroot directory:
> dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
> Add the user "postfix" to the group "sasl":
> adduse
Re: [Gutl-l] itables
Crea un script, con las cosas de iptables, o empieza tu mismo a testearlo en iptables como tal, y si funciona bien lo implementas con iptables-persist(creo). Preguntale a lazaro cual es el ftp q tiene el tutorial de iptables, con eso hice mi script, y lo ejecuto cada cierto tiempo con cron El 02/03/16 a las 07:25, yunie...@espguayabal.transnet.cu escribió: saludos una ves mas jodiendo Gracias a ustedes ya tengo el server pincando bien unque me faltan detalles que lo voy corrigiendo poco a poco necesito una configuracion de iptables que enga dos targetas de red __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] sobre inicio en un servidor
Thread name: "Re: [Gutl-l] sobre inicio en un servidor" Mail number: 4 Date: Tue, Mar 01, 2016 In reply to: Arian Molina Aguilera > > El 01/03/16 a las 19:07, låzaro escribió: > >Thread name: "Re: [Gutl-l] sobre inicio en un servidor" > >Mail number: 4 > >Date: Tue, Mar 01, 2016 > >In reply to: Arian Molina Aguilera > >>lazaro brother no se tu, pero yo estoy muy contengo con debian 8, ahora > >>mismo 8.3, todos mis server corren debian, y con proxmox 4.1 basado igual en > >>la misma, todo va como anillo al dedo, claro esta todo el mundo no tiene la > >>misma experiencias y conocimientos, pero hasta ahora a mi debian 8 y systemd > >>no me ha dado ninguna molestia, las actualizaciones de seguridad van bien, > >>es verdad debian busca más la estabilidad y el software más probado no > >>siempre tiene lo ultimo, pero es no es problema para los servers, para > >>estación de trabajo, como es sabido aquí uso KaOS desde el 2014, y me va muy > >>bien desde sus inicios con systemd y es rollings. Preferiria otros > >>argumentos para pensarlo mejor si algún día abandonaría debian en los > >>servers. También logré migrar algunos server de lenny a jessie sin muchas > >>complicaciones. Todo esta en la experiencias y conocimientos que tenga cada > >>cual del sistema que más domine. Como siempre he dicho, debian es una de las > >>distros más veteranas y que más se usa en el mundo en servidores. Salu2. > >BELLO! Hasta que viene un Chino y toma el control de tu servidor, > >explotando una vulnerabilidad que debian no ha parcheado, o hasta que > >tienes que instalar algo novedoso, por ejemplo, el ruby (o el nodejs) > >de debian, demasiada obsolescencia para mi gusto > > > >para un servidorsucho en la red de salud, está genial, pero para un > >servidor de cara a una ip pública... suerte con eso > > > Que bien, pero no conozco a ningún chino de eso, hasta ahora no he sufrido > esas predicciones pesimistas tuyas. ni necesito el ultimo ruby ni tampoco > nodejs. Suerte la tuya. Salu2. quizás lo tienes y no te has dado por enterado -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Fw: Skype para GNU/Linux se rompe y Microsoft no reacciona [MuyLinux]
- Forwarded message from Salcocho Noticioso - Date: Tue, 01 Mar 2016 23:02:28 -0500 From: Salcocho Noticioso To: laz...@hcg.sld.cu Subject: Skype para GNU/Linux se rompe y Microsoft no reacciona [MuyLinux] X-Mailer: feedblaster.rb - ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] Skype para GNU/Linux se rompe y Microsoft no reacciona Skype para GNU/Linux se rompe y Microsoft no reacciona Cuando Microsoft compró Skype los usuarios de GNU/Linux nos temimos lo peor, y es que por entonces la visión que se tenía de nuestro sistema desde el gigante de Redmond era muy diferente a la de ahora, con un CEO que llegó a llamar cáncer a Linux. Hay que reconocerlo, Skype continuó ahí y funcionando, aunque un tanto limitado comparado con las versiones de OS X y Windows, siendo un poco más feo y sin soporte para 64 bits desde que Ubuntu y Debian añadieron el soporte multiarquitectura. Nada de lo malo que muchos pensamos entonces ocurrió, sino todo lo contrario. Bajo Microsoft el soporte de Skype para GNU/Linux aparentemente mejoró, y se le dio un pequeño lavado de cara en algunas facetas, aunque sin nada de 64 bits en el horizonte y las limitaciones con respecto las versiones de Windows y OS X seguían. Pese a todo la cosa fue funcionando de forma más o menos correcta hasta hace poco, cuando desde el pasado 22 de febrero los usuarios de Skype sobre GNU/Linux dejaron de poder unirse a las llamadas a través del servicio de VoIP. Lo peor de esta situación es que Microsoft pasa de dar respuesta a las quejas de los usuarios, provocando un gran enfado entre la comunidad y los usuarios de GNU/Linux. ¿Veremos Skype enderezado para nuestro sistema o bien estamos ante algún tipo de boicot? Lo peor es que Skype es software privativo y no tiene ninguna API pública, volviendo su implementación en GNU/Linux imposible si no es a través de una aplicación oficial, dejando como única alternativa la utilización de Wine y PlayOnLinux. Sinceramente, me parece un movimiento muy torpe por parte de Microsoft, que solo sirve para resucitar fantasmas que se creían enterrados. Por otro lado no viene mal recordar mi opinión sobre el software que nos merecemos, porque Skype para GNU/Linux se ajusta a la perfección a lo que expuse ahí. Artículos relacionados • Disponible FFmpeg 3.0 con soporte de aceleración por hardware para VP9 • Kodi 16 ‘Jarvis’ ya está disponible • LÖVE, un sencillo framework Open Source para crear videojuegos 2D • Debian podría volver a incorporar Firefox en los repositorios • Decidle adiós a Chrome en los 32-bit [rc] [rc] [rc] [a2]** - End forwarded message - -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
y entonces, los usuarios de debian - Forwarded message from Salcocho Noticioso - Date: Tue, 01 Mar 2016 23:00:09 -0500 From: Salcocho Noticioso To: laz...@hcg.sld.cu Subject: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia] X-Mailer: feedblaster.rb - ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] OpenSSL soluciona ocho vulnerabilidades El proyecto OpenSSL ha anunciado la publicación de nuevas versiones de OpenSSL destinadas a corregir ocho vulnerabilidades, dos calificadas de impacto alto, una de gravedad media y otras cinco de importancia baja. [DROWN] Logo DROWN El primero y más destacado de los problemas reside en una vulnerabilidad, de gravedad alta, que puede permitir descifrar sesiones TLS mediante el uso de un servidor que soporte SSLv2 y suites de cifrado de categoría EXPORT. Una vulnerabilidad de esas que llevan nombre, logo y hasta página web, bautizada como DROWN (Decrypting RSA with Obsolete and Weakened eNcryption). DROWN (con identificador CVE-2016-0800) es una nueva forma de protocolo cruzado Bleichenbacher padding oracle attack, que permite a un atacante descifrar conexiones TLS interceptadas mediante conexiones específicamente creadas a un servidor SSLv2 que use la misma clave privada. Por otra parte, dos vulnerabilidades, una de gravedad alta y otra moderada (con CVE-2016-0703 y CVE-2016-0704), que solo afectan a versiones de OpenSSL anteriores a marzo de 2015, momento en el cual el código fue rediseñado para hacer frente a la vulnerabilidad CVE-2015-0293. Estas vulnerabilidades afectan a OpenSSL versiones 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze y anteriores. Fueron corregidas en OpenSSL 1.0.2a, 1.0.1m, 1.0.0r y 0.9.8zf. [openssl-logo] La importancia de señalar estos problemas en la actualidad reside en que cualquiera de los dos pueden permitir versiones más eficientes de DROWN, incluso eficaces contra conjuntos de cifrado que no sean de exportación, y sin necesidad de requerir un cálculo significativo. De gravedad baja, una vulnerabilidad de denegación de servicio por una dobre liberación cuando OpenSSL trata claves DSA privadas mal construidas (CVE-2016-0705), una fuga de memoria en búsquedas SRP (CVE-2016-0798), referencia a puntero nulo y corrupción de heap en funciones BN_hex2bn y BN_dec2bn (CVE-2016-0797) y problemas de memoria en funciones BIO_*printf (CVE-2016-0799). OpenSSL ha publicado las versiones 1.0.2g y 1.0.1s disponibles desde http://openssl.org/source/ También se recuerda por parte de OpenSSL que las versiones 1.0.1 acaban su soporte a finales de año. Más información: OpenSSL Security Advisory [1st March 2016] https://www.openssl.org/news/secadv/20160301.txt The DROWN Attack https://drownattack.com/ una-al-dia (20/03/2015) OpenSSL soluciona 13 vulnerabilidades http://unaaldia.hispasec.com/2015/03/openssl-soluciona-13-vulnerabilidades.html Antonio Ropero anton...@hispasec.com Twitter: @aropero * - End forwarded message - -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Fw: Decidle adiós a Chrome en los 32-bit [MuyLinux]
- Forwarded message from Salcocho Noticioso - Date: Tue, 01 Mar 2016 23:02:28 -0500 From: Salcocho Noticioso To: laz...@hcg.sld.cu Subject: Decidle adiós a Chrome en los 32-bit [MuyLinux] X-Mailer: feedblaster.rb - ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] Decidle adiós a Chrome en los 32-bit chrome He aquí un breve recordatorio para todos los usuarios de Chrome en Linux, muy especialmente para quienes lo usan en distribuciones de 32-bit, en Ubuntu 12.04 o Debian 7: el navegador web de Google retirará el soporte a las plataformas señaladas este mes, cumpliendo con lo anunciado a finales del año pasado. Lo repetimos por si acaso: si usas Chrome en una distro de 32-bit podrás seguir haciéndolo todo el tiempo que estimes oportuno, pero a partir de marzo dejará de recibir actualizaciones, por lo que el propio sentido común indica que cambies de navegador cuando llegue el momento si no quieres que te crujan. Y lo mismo si usas Ubuntu 12.04 o Debian 7, ya sea la versión de 32 o 64 bits, porque en ambos casos Google les retira igualmente el soporte. Conviene tener presente que el navegador web es una pieza crítica en la seguridad del sistema -por no hablar de la información personal que maneja- y debe estar siempre actualizado a su última versión estable para no exponerse a las vicisitudes de Internet. Dicho lo cual, alternativas de calidad no faltan: ahí están Firefox, Opera o Vivaldi además de Chromium, que en este sentido es la alternativa natural. Google mantendrá los componentes necesarios para compilar Chromium para 32-bit y anima a dar el salto. Chromium, siendo casi lo mismo que Chrome y totalmente compatible con este, peca en ciertos detalles menores de no estar a la altura de su versión comercial -se nota en el arranque, por ejemplo-, pero se va puliendo y en las últimas fechas hemos visto cómo en soporte multimedia, una de las brechas tradicionales, ya está muy parejo. ¿Y qué hay de los 32-bit? Evolucionar o morir, ¿no? De hecho cada vez más distribuciones se animan a abandonar la vieja arquitectura: la más reciente de entre las grandes, openSUSE Leap; la próxima, quizás, Ubuntu. Artículos relacionados • Disponible FFmpeg 3.0 con soporte de aceleración por hardware para VP9 • Kodi 16 ‘Jarvis’ ya está disponible • LÖVE, un sencillo framework Open Source para crear videojuegos 2D • Debian podría volver a incorporar Firefox en los repositorios • Skype para GNU/Linux se rompe y Microsoft no reacciona [rc] [rc] [rc] [a2]** - End forwarded message - -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix y SASL
El 02/03/16 a las 08:59, Rommel Rodriguez Toirac escribió:
El Martes, 1 de marzo de 2016 16:55:53 Arian Molina Aguilera escribió:
El 01/03/16 a las 16:49, Manuel Mely escribió:
On 03/01/2016 02:28 PM, Rommel Rodriguez Toirac wrote:
No me llegó nada :-( Directamente no puedo recibir ni enviar correos
a dominios que no sean .cu y no pueden pasar de 1Mb de tamaño Nada
que nosotros todavía estamos en otra época.
De todos modos si pueden seguir el hilo o al menos postear la solucion
al problema por aqui mejor. Y si es posible acortar un poco el cuerpo
del mensaje (como acabo de hacer en este mensaje)
Sobre la solucion... te dejo en buenas manos :)
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
De la propia wiki de Centos Postfix SASL + Dovecot
Configuring SASL in postfix
To configure SASL in postfix, we need to make the following additions to
/etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
and add permit_sasl_authenticated to our smtpd_recipient_restrictions
section of /etc/postfix/main.cf (if you don't have a
smtpd_recipient_restrictions section, then the following example will
work fine):
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
Next we need to configure auth default in the authentication processes
section of /etc/dovecot.conf. Uncomment and/or add the following lines
as necessary (be careful as this section is heavily commented, some
entries already exist, others are commented out and need uncommenting
such as socket listen):
auth default {
mechanisms = plain login
passdb pam {
}
userdb passwd {
}
user = root
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Restart dovecot and reload postfix configuration setting:
service dovecot restart
postfix reload
De la wiki de debian
PostfixAndSASL
Translation(s): none
Simple Authentication and Security Layer (SASL) with Postfix SMTP
Tabla de Contenidos
SASL authentication in the Postfix SMTP server
Implementation using Cyrus SASL
Using saslauthd with PAM
Using auxprop with sasldb
Troubleshooting tip
Implementation using Dovecot SASL
SASL authentication in the Postfix SMTP client
Postfix and sbcglobal/yahoo/att
SASL authentication in the Postfix SMTP server
Implementation using Cyrus SASL
Using saslauthd with PAM
Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM
in a chroot() environment.
Note: The following steps have been carried out and verified on a Debian
7.1 system (Jan. 2015).
Note: SASL2 (saslauthd) creates a socket in its working directory.
Postfix (smtpd) needs access to this socket. If smtpd is running
chroot()ed (what is standard on Debian) saslauthd must run within this
chroot() environment also (though not being chrooted itself). While this
is fine for smtpd there are other services (Cyrus imapd for example)
which expect saslauthd 's socket at its "regular" location
(/var/run/saslauthd).
The recommended way to solve this is to run separate saslauthd processes
for Postfix and for others. Debian is prepared for this. Alternatively a
symlink-trick can be used. See below. Or you can disable chroot()ing by
editing the chroot columns in /etc/postfix/master.cf.
Install libsasl2-modules, postfix, sasl2-bin
Create a file /etc/postfix/sasl/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Setup a separate saslauthd process to be used from Postfix:
Create a copy of saslauthd's config file
~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix
and edit it
START=yes
DESC="SASL Auth. Daemon for Postfix"
NAME="saslauthd-postf" # max. 15 char.
# Option -m sets working dir for saslauthd (contains socket)
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"#
postfix/smtp in chroot()
(See /usr/share/doc/sasl2-bin/README.Debian.gz)
Alternatively you can replace the directory /run/saslauthd with a
symlink to /var/spool/postfix/var/run/saslauthd
~# rm -rf /run/saslauthd
~# ln -s /var/spool/postfix/var/run/saslauthd /run/saslauthd
This is a quick-and-dirty hack, useful only for testing purposes. After
the next reboot the contents of /run will be reset.
Create required subdirectories in postfix chroot directory:
dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
Add the user "postfix" to the group "sasl":
adduser postfix sasl
Restart saslauthd:
~# service saslauthd restart
[ ok ] Stopping SASL Auth. Daemon: saslauthd.
[ ok ] Stopping SASL Auth. Daemon for Postfix: saslauthd-postf.
[ ok ] Starting SASL Auth. Daemon: saslauthd.
[
Re: [Gutl-l] sobre inicio en un servidor
El 02/03/16 a las 10:50, låzaro escribió: Thread name: "Re: [Gutl-l] sobre inicio en un servidor" Mail number: 4 Date: Tue, Mar 01, 2016 In reply to: Arian Molina Aguilera El 01/03/16 a las 19:07, låzaro escribió: Thread name: "Re: [Gutl-l] sobre inicio en un servidor" Mail number: 4 Date: Tue, Mar 01, 2016 In reply to: Arian Molina Aguilera lazaro brother no se tu, pero yo estoy muy contengo con debian 8, ahora mismo 8.3, todos mis server corren debian, y con proxmox 4.1 basado igual en la misma, todo va como anillo al dedo, claro esta todo el mundo no tiene la misma experiencias y conocimientos, pero hasta ahora a mi debian 8 y systemd no me ha dado ninguna molestia, las actualizaciones de seguridad van bien, es verdad debian busca más la estabilidad y el software más probado no siempre tiene lo ultimo, pero es no es problema para los servers, para estación de trabajo, como es sabido aquí uso KaOS desde el 2014, y me va muy bien desde sus inicios con systemd y es rollings. Preferiria otros argumentos para pensarlo mejor si algún día abandonaría debian en los servers. También logré migrar algunos server de lenny a jessie sin muchas complicaciones. Todo esta en la experiencias y conocimientos que tenga cada cual del sistema que más domine. Como siempre he dicho, debian es una de las distros más veteranas y que más se usa en el mundo en servidores. Salu2. BELLO! Hasta que viene un Chino y toma el control de tu servidor, explotando una vulnerabilidad que debian no ha parcheado, o hasta que tienes que instalar algo novedoso, por ejemplo, el ruby (o el nodejs) de debian, demasiada obsolescencia para mi gusto para un servidorsucho en la red de salud, está genial, pero para un servidor de cara a una ip pública... suerte con eso Que bien, pero no conozco a ningún chino de eso, hasta ahora no he sufrido esas predicciones pesimistas tuyas. ni necesito el ultimo ruby ni tampoco nodejs. Suerte la tuya. Salu2. quizás lo tienes y no te has dado por enterado Para algo existen los firewall, uso pfsense, por delante de todo y tampoco expongo servicios directamente a internet todo queda detrás del firewall, hay un modulo muy interesante pfBlockerNG que te permite bloquear incluso bloques de países completos. Salu2. pfBlockerNG is the Next Generation of pfBlocker. Manage IPv4/v6 List Sources into 'Deny, Permit or Match' formats. Country Blocking Database by MaxMind Inc. (GeoLite Free version). De-Duplication, Suppression, and Reputation enhancements. Provision to download from diverse List formats. Advanced Integration for Proofpoint ET IQRisk IP Reputation Threat Sources. Domain Name (DNSBL) blocking via Unbound DNS Resolver. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
El 02/03/16 a las 10:51, låzaro escribió: y entonces, los usuarios de debian - Forwarded message from Salcocho Noticioso - Date: Tue, 01 Mar 2016 23:00:09 -0500 From: Salcocho Noticioso To: laz...@hcg.sld.cu Subject: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia] X-Mailer: feedblaster.rb - ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] OpenSSL soluciona ocho vulnerabilidades El proyecto OpenSSL ha anunciado la publicación de nuevas versiones de OpenSSL destinadas a corregir ocho vulnerabilidades, dos calificadas de impacto alto, una de gravedad media y otras cinco de importancia baja. [DROWN] Logo DROWN El primero y más destacado de los problemas reside en una vulnerabilidad, de gravedad alta, que puede permitir descifrar sesiones TLS mediante el uso de un servidor que soporte SSLv2 y suites de cifrado de categoría EXPORT. Una vulnerabilidad de esas que llevan nombre, logo y hasta página web, bautizada como DROWN (Decrypting RSA with Obsolete and Weakened eNcryption). DROWN (con identificador CVE-2016-0800) es una nueva forma de protocolo cruzado Bleichenbacher padding oracle attack, que permite a un atacante descifrar conexiones TLS interceptadas mediante conexiones específicamente creadas a un servidor SSLv2 que use la misma clave privada. Por otra parte, dos vulnerabilidades, una de gravedad alta y otra moderada (con CVE-2016-0703 y CVE-2016-0704), que solo afectan a versiones de OpenSSL anteriores a marzo de 2015, momento en el cual el código fue rediseñado para hacer frente a la vulnerabilidad CVE-2015-0293. Estas vulnerabilidades afectan a OpenSSL versiones 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze y anteriores. Fueron corregidas en OpenSSL 1.0.2a, 1.0.1m, 1.0.0r y 0.9.8zf. [openssl-logo] La importancia de señalar estos problemas en la actualidad reside en que cualquiera de los dos pueden permitir versiones más eficientes de DROWN, incluso eficaces contra conjuntos de cifrado que no sean de exportación, y sin necesidad de requerir un cálculo significativo. De gravedad baja, una vulnerabilidad de denegación de servicio por una dobre liberación cuando OpenSSL trata claves DSA privadas mal construidas (CVE-2016-0705), una fuga de memoria en búsquedas SRP (CVE-2016-0798), referencia a puntero nulo y corrupción de heap en funciones BN_hex2bn y BN_dec2bn (CVE-2016-0797) y problemas de memoria en funciones BIO_*printf (CVE-2016-0799). OpenSSL ha publicado las versiones 1.0.2g y 1.0.1s disponibles desde http://openssl.org/source/ También se recuerda por parte de OpenSSL que las versiones 1.0.1 acaban su soporte a finales de año. Más información: OpenSSL Security Advisory [1st March 2016] https://www.openssl.org/news/secadv/20160301.txt The DROWN Attack https://drownattack.com/ una-al-dia (20/03/2015) OpenSSL soluciona 13 vulnerabilidades http://unaaldia.hispasec.com/2015/03/openssl-soluciona-13-vulnerabilidades.html Antonio Ropero anton...@hispasec.com Twitter: @aropero * - End forwarded message - aptitude update Current status: 6 updates [+6], 42551 new [+1]. root@openfire:~# aptitude upgrade The following packages will be upgraded: libssl1.0.0 openssl perl perl-base perl-modules python-pil The following packages are RECOMMENDED but will NOT be installed: libarchive-extract-perl libcgi-pm-perl libmodule-build-perl libmodule-pluggable-perl libpackage-constants-perl libpod-latex-perl libterm-ui-perl libtext-soundex-perl rename 6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 8,429 kB of archives. After unpacking 5,120 B will be used. Do you want to continue? [Y/n/?] -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
El 02/03/16 a las 10:51, låzaro escribió: y entonces, los usuarios de debian - Forwarded message from Salcocho Noticioso - Date: Tue, 01 Mar 2016 23:00:09 -0500 From: Salcocho Noticioso To: laz...@hcg.sld.cu Subject: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia] X-Mailer: feedblaster.rb - ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] OpenSSL soluciona ocho vulnerabilidades El proyecto OpenSSL ha anunciado la publicación de nuevas versiones de OpenSSL destinadas a corregir ocho vulnerabilidades, dos calificadas de impacto alto, una de gravedad media y otras cinco de importancia baja. [DROWN] Logo DROWN El primero y más destacado de los problemas reside en una vulnerabilidad, de gravedad alta, que puede permitir descifrar sesiones TLS mediante el uso de un servidor que soporte SSLv2 y suites de cifrado de categoría EXPORT. Una vulnerabilidad de esas que llevan nombre, logo y hasta página web, bautizada como DROWN (Decrypting RSA with Obsolete and Weakened eNcryption). DROWN (con identificador CVE-2016-0800) es una nueva forma de protocolo cruzado Bleichenbacher padding oracle attack, que permite a un atacante descifrar conexiones TLS interceptadas mediante conexiones específicamente creadas a un servidor SSLv2 que use la misma clave privada. Por otra parte, dos vulnerabilidades, una de gravedad alta y otra moderada (con CVE-2016-0703 y CVE-2016-0704), que solo afectan a versiones de OpenSSL anteriores a marzo de 2015, momento en el cual el código fue rediseñado para hacer frente a la vulnerabilidad CVE-2015-0293. Estas vulnerabilidades afectan a OpenSSL versiones 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze y anteriores. Fueron corregidas en OpenSSL 1.0.2a, 1.0.1m, 1.0.0r y 0.9.8zf. [openssl-logo] La importancia de señalar estos problemas en la actualidad reside en que cualquiera de los dos pueden permitir versiones más eficientes de DROWN, incluso eficaces contra conjuntos de cifrado que no sean de exportación, y sin necesidad de requerir un cálculo significativo. De gravedad baja, una vulnerabilidad de denegación de servicio por una dobre liberación cuando OpenSSL trata claves DSA privadas mal construidas (CVE-2016-0705), una fuga de memoria en búsquedas SRP (CVE-2016-0798), referencia a puntero nulo y corrupción de heap en funciones BN_hex2bn y BN_dec2bn (CVE-2016-0797) y problemas de memoria en funciones BIO_*printf (CVE-2016-0799). OpenSSL ha publicado las versiones 1.0.2g y 1.0.1s disponibles desde http://openssl.org/source/ También se recuerda por parte de OpenSSL que las versiones 1.0.1 acaban su soporte a finales de año. Más información: OpenSSL Security Advisory [1st March 2016] https://www.openssl.org/news/secadv/20160301.txt The DROWN Attack https://drownattack.com/ una-al-dia (20/03/2015) OpenSSL soluciona 13 vulnerabilidades http://unaaldia.hispasec.com/2015/03/openssl-soluciona-13-vulnerabilidades.html Antonio Ropero anton...@hispasec.com Twitter: @aropero * - End forwarded message - a actualizar como todo el mundo. Salu2. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] sobre inicio en un servidor
> Para algo existen los firewall jejejeje, con ese criterio, te estás quemando y no lo sabes a ver, te explico lo básico, tienes N servicio, el cual tienes que tener público, digamos un servidor web, con una aplicación escrita en php y ni siquiera sabes que es una vulnerabilidad, viene un chino y te la explota. Por ejemplo, recién me explotaron una vulnerabilidad en un roundcube, de una entidad que necesariamente tenía que brindar un webmail de cara a una pública. Si aveces un servidor web supuestamente seguro, te lo follan, dime tú en uno desactualizado... > uso pfsense, por delante de todo y tampoco expongo servicios > directamente a internet todo queda detrás del firewall, hay un > modulo muy interesante pfBlockerNG que te permite bloquear incluso > bloques de países completos. Salu2. Suerte con eso. Los bloques de ip de países no siempre son de países. Los ISP se cambian las IP. Mira a Fumero por ejemplo, le llega tráfico de RAW socket a su ip que supuestamente es solo nacional. > > pfBlockerNG is the Next Generation of pfBlocker. Manage IPv4/v6 > List Sources into 'Deny, Permit or Match' formats. Country Blocking > Database by MaxMind Inc. (GeoLite Free version). De-Duplication, > Suppression, and Reputation enhancements. Provision to download > from diverse List formats. Advanced Integration for Proofpoint ET > IQRisk IP Reputation Threat Sources. Domain Name (DNSBL) blocking > via Unbound DNS Resolver. > -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix y SASL
El 02/03/2016 a las 08:59 a.m., Rommel Rodriguez Toirac escribió:
El Martes, 1 de marzo de 2016 16:55:53 Arian Molina Aguilera escribió:
El 01/03/16 a las 16:49, Manuel Mely escribió:
On 03/01/2016 02:28 PM, Rommel Rodriguez Toirac wrote:
No me llegó nada :-( Directamente no puedo recibir ni enviar correos
a dominios que no sean .cu y no pueden pasar de 1Mb de tamaño Nada
que nosotros todavía estamos en otra época.
De todos modos si pueden seguir el hilo o al menos postear la solucion
al problema por aqui mejor. Y si es posible acortar un poco el cuerpo
del mensaje (como acabo de hacer en este mensaje)
Sobre la solucion... te dejo en buenas manos :)
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
De la propia wiki de Centos Postfix SASL + Dovecot
Configuring SASL in postfix
To configure SASL in postfix, we need to make the following additions to
/etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
and add permit_sasl_authenticated to our smtpd_recipient_restrictions
section of /etc/postfix/main.cf (if you don't have a
smtpd_recipient_restrictions section, then the following example will
work fine):
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
Next we need to configure auth default in the authentication processes
section of /etc/dovecot.conf. Uncomment and/or add the following lines
as necessary (be careful as this section is heavily commented, some
entries already exist, others are commented out and need uncommenting
such as socket listen):
auth default {
mechanisms = plain login
passdb pam {
}
userdb passwd {
}
user = root
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Restart dovecot and reload postfix configuration setting:
service dovecot restart
postfix reload
De la wiki de debian
PostfixAndSASL
Translation(s): none
Simple Authentication and Security Layer (SASL) with Postfix SMTP
Tabla de Contenidos
SASL authentication in the Postfix SMTP server
Implementation using Cyrus SASL
Using saslauthd with PAM
Using auxprop with sasldb
Troubleshooting tip
Implementation using Dovecot SASL
SASL authentication in the Postfix SMTP client
Postfix and sbcglobal/yahoo/att
SASL authentication in the Postfix SMTP server
Implementation using Cyrus SASL
Using saslauthd with PAM
Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM
in a chroot() environment.
Note: The following steps have been carried out and verified on a Debian
7.1 system (Jan. 2015).
Note: SASL2 (saslauthd) creates a socket in its working directory.
Postfix (smtpd) needs access to this socket. If smtpd is running
chroot()ed (what is standard on Debian) saslauthd must run within this
chroot() environment also (though not being chrooted itself). While this
is fine for smtpd there are other services (Cyrus imapd for example)
which expect saslauthd 's socket at its "regular" location
(/var/run/saslauthd).
The recommended way to solve this is to run separate saslauthd processes
for Postfix and for others. Debian is prepared for this. Alternatively a
symlink-trick can be used. See below. Or you can disable chroot()ing by
editing the chroot columns in /etc/postfix/master.cf.
Install libsasl2-modules, postfix, sasl2-bin
Create a file /etc/postfix/sasl/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Setup a separate saslauthd process to be used from Postfix:
Create a copy of saslauthd's config file
~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix
and edit it
START=yes
DESC="SASL Auth. Daemon for Postfix"
NAME="saslauthd-postf" # max. 15 char.
# Option -m sets working dir for saslauthd (contains socket)
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"#
postfix/smtp in chroot()
(See /usr/share/doc/sasl2-bin/README.Debian.gz)
Alternatively you can replace the directory /run/saslauthd with a
symlink to /var/spool/postfix/var/run/saslauthd
~# rm -rf /run/saslauthd
~# ln -s /var/spool/postfix/var/run/saslauthd /run/saslauthd
This is a quick-and-dirty hack, useful only for testing purposes. After
the next reboot the contents of /run will be reset.
Create required subdirectories in postfix chroot directory:
dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
Add the user "postfix" to the group "sasl":
adduser postfix sasl
Restart saslauthd:
~# service saslauthd restart
[ ok ] Stopping SASL Auth. Daemon: saslauthd.
[ ok ] Stopping SASL Auth. Daemon for Postfix: saslauthd-postf.
[ ok ] Starting SASL Auth. Daemon: saslau
Re: [Gutl-l] itables
se mas especifico para poderte ayudar socio . estamos en la mejor disposicion de ayudarte pero que tienes en esas dos tarjetas de red y mas o menos como quieres que funcione tu iptables El 02/03/16 a las 07:25, yunie...@espguayabal.transnet.cu escribió: saludos una ves mas jodiendo Gracias a ustedes ya tengo el server pincando bien unque me faltan detalles que lo voy corrigiendo poco a poco necesito una configuracion de iptables que enga dos targetas de red __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l -- Hanoi Calvo Fernández Administrador Redes Dir Mcpal Finanzas y Precios Isla de la Juventud linux user 720924 lider Proyecto SCNET-GUTL http://scnetisla.cubava.cu __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
> aptitude update > > Current status: 6 updates [+6], 42551 new [+1]. > root@openfire:~# aptitude upgrade > The following packages will be upgraded: > libssl1.0.0 openssl perl perl-base perl-modules python-pil > The following packages are RECOMMENDED but will NOT be installed: > libarchive-extract-perl libcgi-pm-perl libmodule-build-perl > libmodule-pluggable-perl libpackage-constants-perl libpod-latex-perl > libterm-ui-perl > libtext-soundex-perl rename > 6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > Need to get 8,429 kB of archives. After unpacking 5,120 B will be used. > Do you want to continue? [Y/n/?] Genial!!! :D Yo no hablo mal de debian, aunque hable fuerte; como comenté anteriormente. Pero no solo de actualizaciones de seguridad se vive. No entiendo, si actualizan las de seguridad, porque no actualizan las versiones también. Que cada empaquetador pruebe su estabilidad y la actualize. Arch tiene una rama estable y una testing, porque debian no puede tener lo mismo y ser roll-release también, si tiene uno de los mejores manipulador de paquetes -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] sobre inicio en un servidor
El 02/03/16 a las 12:18, låzaro escribió: Para algo existen los firewall jejejeje, con ese criterio, te estás quemando y no lo sabes a ver, te explico lo básico, tienes N servicio, el cual tienes que tener público, digamos un servidor web, con una aplicación escrita en php y ni siquiera sabes que es una vulnerabilidad, viene un chino y te la explota. Por ejemplo, recién me explotaron una vulnerabilidad en un roundcube, de una entidad que necesariamente tenía que brindar un webmail de cara a una pública. Si aveces un servidor web supuestamente seguro, te lo follan, dime tú en uno desactualizado... uso pfsense, por delante de todo y tampoco expongo servicios directamente a internet todo queda detrás del firewall, hay un modulo muy interesante pfBlockerNG que te permite bloquear incluso bloques de países completos. Salu2. Suerte con eso. Los bloques de ip de países no siempre son de países. Los ISP se cambian las IP. Mira a Fumero por ejemplo, le llega tráfico de RAW socket a su ip que supuestamente es solo nacional. pfBlockerNG is the Next Generation of pfBlocker. Manage IPv4/v6 List Sources into 'Deny, Permit or Match' formats. Country Blocking Database by MaxMind Inc. (GeoLite Free version). De-Duplication, Suppression, and Reputation enhancements. Provision to download from diverse List formats. Advanced Integration for Proofpoint ET IQRisk IP Reputation Threat Sources. Domain Name (DNSBL) blocking via Unbound DNS Resolver. Lo que no te entiendo es porque te empeñas a decir que es un servidor y sistema desactualizado, constantemente estoy actualizando mi debian, la mayorías de las actualizaciones son de security, y otra cosa son las aplicaciones desactualizadas, como fue el caso de tu roundcube o cualquier CMS del momento, hay que estar al día con eso también, muchos CMS están implementando actualizaciones de seguridad automáticas y también firewall por software. En definitiva la seguridad es un nicho muy grande, constantemente están apareciendo vulnerabilidades. Que supuestamente no se conocen por la mayoría de los usuarios y puede ser que un blackhacker si lo conozca y este explotándolo hasta el día que lo descubran en definitiva puedo decirte que he corrido con mucha suerte entonces, en los 10 años ya que llevo en la administración de redes y sistemas telemáticos. En fin como dice Taladrí saquen ustedes sus propias conclusiones. Salu2. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
El 02/03/16 a las 13:16, låzaro escribió: aptitude update Current status: 6 updates [+6], 42551 new [+1]. root@openfire:~# aptitude upgrade The following packages will be upgraded: libssl1.0.0 openssl perl perl-base perl-modules python-pil The following packages are RECOMMENDED but will NOT be installed: libarchive-extract-perl libcgi-pm-perl libmodule-build-perl libmodule-pluggable-perl libpackage-constants-perl libpod-latex-perl libterm-ui-perl libtext-soundex-perl rename 6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 8,429 kB of archives. After unpacking 5,120 B will be used. Do you want to continue? [Y/n/?] Genial!!! :D Yo no hablo mal de debian, aunque hable fuerte; como comenté anteriormente. Pero no solo de actualizaciones de seguridad se vive. No entiendo, si actualizan las de seguridad, porque no actualizan las versiones también. Que cada empaquetador pruebe su estabilidad y la actualize. Arch tiene una rama estable y una testing, porque debian no puede tener lo mismo y ser roll-release también, si tiene uno de los mejores manipulador de paquetes brother cuando entenderás ningún server que se respete ninguna de las distros más reconocidas. Redhat7, Suse 12, Ubuntu Server 14.04, Etc, tienen lo ultimo de la paquetería. Se busca seguridad y estabilidad por encima de todo. Si quieres tener lo ultimo y sacrificar la seguridad y la estabilidad comprobada, no te recomiendo que lo uses en producción, si es tu maquina de trabajo y desarrollo pues bien que tengas lo ultimo, pero en los servers en producción no. Cuando se ha visto por ahí un server en un cloud de amazon o azure corriendo archlinux, nunca verdad. Entonces analiza mejor para que veas, socio y debian tienes más bien tres ramas, no solo dos, tienen la estable que es la actual debian 8.3. segura y garantizada, tiene la rama testing, que cuando este estable y segura pasará a ser la debian estable 9, y tiene la rama Sid, donde tienes lo ultimo y que contentamente se le actualizan y agregan cosas nuevas, por lo tanto no es la más estable ni la más segura, porque no todo esta probado al 99%. Quieres tener lo más actual y novedoso y seguir usando debian, pues instalas la rama sid y listo. Salu2. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] sobre inicio en un servidor
Thread name: "Re: [Gutl-l] sobre inicio en un servidor" Mail number: 4 Date: Wed, Mar 02, 2016 In reply to: Arian Molina Aguilera > > El 02/03/16 a las 12:18, låzaro escribió: > >>Para algo existen los firewall > > > >jejejeje, con ese criterio, te estás quemando y no lo sabes > > > > > >a ver, te explico lo básico, tienes N servicio, el cual tienes que > >tener público, digamos un servidor web, con una aplicación escrita en > >php y ni siquiera sabes que es una vulnerabilidad, viene un chino y te > >la explota. > > > >Por ejemplo, recién me explotaron una vulnerabilidad en un roundcube, > >de una entidad que necesariamente tenía que brindar un webmail de cara > >a una pública. > > > >Si aveces un servidor web supuestamente seguro, te lo follan, dime tú > >en uno desactualizado... > > > > > > > >>uso pfsense, por delante de todo y tampoco expongo servicios > >>directamente a internet todo queda detrás del firewall, hay un > >>modulo muy interesante pfBlockerNG que te permite bloquear incluso > >>bloques de países completos. Salu2. > >Suerte con eso. Los bloques de ip de países no siempre son de países. > >Los ISP se cambian las IP. Mira a Fumero por ejemplo, le llega tráfico > >de RAW socket a su ip que supuestamente es solo nacional. > > > > > >>pfBlockerNG is the Next Generation of pfBlocker. Manage IPv4/v6 > >>List Sources into 'Deny, Permit or Match' formats. Country Blocking > >>Database by MaxMind Inc. (GeoLite Free version). De-Duplication, > >>Suppression, and Reputation enhancements. Provision to download > >>from diverse List formats. Advanced Integration for Proofpoint ET > >>IQRisk IP Reputation Threat Sources. Domain Name (DNSBL) blocking > >>via Unbound DNS Resolver. > >> > > > > > > > Lo que no te entiendo es porque te empeñas a decir que es un servidor y > sistema desactualizado, constantemente estoy actualizando mi debian, la > mayorías de las actualizaciones son de security, y otra cosa son las > aplicaciones desactualizadas, como fue el caso de tu roundcube o cualquier > CMS del momento, hay que estar al día con eso también, muchos CMS están > implementando actualizaciones de seguridad automáticas y también firewall > por software. En definitiva la seguridad es un nicho muy grande, > constantemente están apareciendo vulnerabilidades. Que supuestamente no se > conocen por la mayoría de los usuarios y puede ser que un blackhacker si lo > conozca y este explotándolo hasta el día que lo descubran en definitiva > puedo decirte que he corrido con mucha suerte entonces, en los 10 años ya > que llevo en la administración de redes y sistemas telemáticos. En fin como > dice Taladrí saquen ustedes sus propias conclusiones. Salu2. > Bueno, no quiero entrar en una discusión polémica que no conlleva a nada y no dejas de tener razón. Aunque tengo mil razones, no me gusta tirarle a debian y cogí bastante cuerda. Por tanto, dejémoslo como empate rígido y a los lectores con el privilegio de la duda -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix y SASL
El Miércoles, 2 de marzo de 2016 13:01:34 Juan Carlos escribió:
> El 02/03/2016 a las 08:59 a.m., Rommel Rodriguez Toirac escribió:
> > El Martes, 1 de marzo de 2016 16:55:53 Arian Molina Aguilera escribió:
> >> El 01/03/16 a las 16:49, Manuel Mely escribió:
> >>> On 03/01/2016 02:28 PM, Rommel Rodriguez Toirac wrote:
> No me llegó nada :-( Directamente no puedo recibir ni enviar correos
> a dominios que no sean .cu y no pueden pasar de 1Mb de tamaño Nada
> que nosotros todavía estamos en otra época.
> >>>
> >>> De todos modos si pueden seguir el hilo o al menos postear la solucion
> >>> al problema por aqui mejor. Y si es posible acortar un poco el cuerpo
> >>> del mensaje (como acabo de hacer en este mensaje)
> >>> Sobre la solucion... te dejo en buenas manos :)
> >>>
> >>>
> >>> __
> >>> Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
> >>> Gutl-l@jovenclub.cu
> >>> https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
> >>
> >> De la propia wiki de Centos Postfix SASL + Dovecot
> >>
> >> Configuring SASL in postfix
> >>
> >> To configure SASL in postfix, we need to make the following additions to
> >> /etc/postfix/main.cf:
> >>
> >>
> >> smtpd_sasl_auth_enable = yes
> >> broken_sasl_auth_clients = yes
> >> smtpd_sasl_type = dovecot
> >> smtpd_sasl_path = private/auth
> >> smtpd_sasl_security_options = noanonymous
> >> and add permit_sasl_authenticated to our smtpd_recipient_restrictions
> >> section of /etc/postfix/main.cf (if you don't have a
> >> smtpd_recipient_restrictions section, then the following example will
> >> work fine):
> >>
> >>
> >> smtpd_recipient_restrictions =
> >>
> >> permit_mynetworks,
> >> permit_sasl_authenticated,
> >> reject_unauth_destination
> >>
> >> Next we need to configure auth default in the authentication processes
> >> section of /etc/dovecot.conf. Uncomment and/or add the following lines
> >> as necessary (be careful as this section is heavily commented, some
> >> entries already exist, others are commented out and need uncommenting
> >> such as socket listen):
> >>
> >>
> >> auth default {
> >>
> >> mechanisms = plain login
> >> passdb pam {
> >> }
> >> userdb passwd {
> >> }
> >> user = root
> >> socket listen {
> >>
> >> client {
> >>
> >> path = /var/spool/postfix/private/auth
> >> mode = 0660
> >> user = postfix
> >> group = postfix
> >>
> >> }
> >>
> >> }
> >>
> >> }
> >> Restart dovecot and reload postfix configuration setting:
> >>
> >>
> >> service dovecot restart
> >> postfix reload
> >>
> >> De la wiki de debian
> >>
> >> PostfixAndSASL
> >>
> >> Translation(s): none
> >>
> >> Simple Authentication and Security Layer (SASL) with Postfix SMTP
> >>
> >>
> >> Tabla de Contenidos
> >> SASL authentication in the Postfix SMTP server
> >> Implementation using Cyrus SASL
> >> Using saslauthd with PAM
> >> Using auxprop with sasldb
> >> Troubleshooting tip
> >> Implementation using Dovecot SASL
> >> SASL authentication in the Postfix SMTP client
> >> Postfix and sbcglobal/yahoo/att
> >> SASL authentication in the Postfix SMTP server
> >>
> >>
> >> Implementation using Cyrus SASL
> >>
> >> Using saslauthd with PAM
> >> Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM
> >> in a chroot() environment.
> >>
> >> Note: The following steps have been carried out and verified on a Debian
> >> 7.1 system (Jan. 2015).
> >> Note: SASL2 (saslauthd) creates a socket in its working directory.
> >> Postfix (smtpd) needs access to this socket. If smtpd is running
> >> chroot()ed (what is standard on Debian) saslauthd must run within this
> >> chroot() environment also (though not being chrooted itself). While this
> >> is fine for smtpd there are other services (Cyrus imapd for example)
> >> which expect saslauthd 's socket at its "regular" location
> >> (/var/run/saslauthd).
> >> The recommended way to solve this is to run separate saslauthd processes
> >> for Postfix and for others. Debian is prepared for this. Alternatively a
> >> symlink-trick can be used. See below. Or you can disable chroot()ing by
> >> editing the chroot columns in /etc/postfix/master.cf.
> >>
> >> Install libsasl2-modules, postfix, sasl2-bin
> >> Create a file /etc/postfix/sasl/smtpd.conf:
> >> pwcheck_method: saslauthd
> >> mech_list: PLAIN LOGIN
> >> Setup a separate saslauthd process to be used from Postfix:
> >> Create a copy of saslauthd's config file
> >> ~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix
> >> and edit it
> >> START=yes
> >> DESC="SASL Auth. Daemon for Postfix"
> >> NAME="saslauthd-postf" # max. 15 char.
> >> # Option -m sets working dir for saslauthd (contains socket)
> >> OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"#
> >> postfix/smtp in chro
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
Thread name: "Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]" Mail number: 2 Date: Wed, Mar 02, 2016 In reply to: Arian Molina Aguilera > > El 02/03/16 a las 13:16, låzaro escribió: > >>aptitude update > >> > >>Current status: 6 updates [+6], 42551 new [+1]. > >>root@openfire:~# aptitude upgrade > >>The following packages will be upgraded: > >> libssl1.0.0 openssl perl perl-base perl-modules python-pil > >>The following packages are RECOMMENDED but will NOT be installed: > >> libarchive-extract-perl libcgi-pm-perl libmodule-build-perl > >>libmodule-pluggable-perl libpackage-constants-perl libpod-latex-perl > >>libterm-ui-perl > >> libtext-soundex-perl rename > >>6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > >>Need to get 8,429 kB of archives. After unpacking 5,120 B will be used. > >>Do you want to continue? [Y/n/?] > > > >Genial!!! :D > > > >Yo no hablo mal de debian, aunque hable fuerte; como comenté > >anteriormente. Pero no solo de actualizaciones de seguridad se vive. > > > >No entiendo, si actualizan las de seguridad, porque no actualizan las > >versiones también. Que cada empaquetador pruebe su estabilidad y la > >actualize. Arch tiene una rama estable y una testing, porque debian no > >puede tener lo mismo y ser roll-release también, si tiene uno de los > >mejores manipulador de paquetes > > > > > > > brother cuando entenderás ningún server que se respete ninguna de las > distros más reconocidas. Redhat7, Suse 12, Ubuntu Server 14.04, Etc, tienen > lo ultimo de la paquetería. Se busca seguridad y estabilidad por encima de > todo. Si quieres tener lo ultimo y sacrificar la seguridad y la estabilidad > comprobada, no te recomiendo que lo uses en producción, si es tu maquina de > trabajo y desarrollo pues bien que tengas lo ultimo, pero en los servers en > producción no. Cuando se ha visto por ahí un server en un cloud de amazon o > azure corriendo archlinux, nunca verdad. Entonces analiza mejor para que > veas, socio y debian tienes más bien tres ramas, no solo dos, tienen la > estable que es la actual debian 8.3. segura y garantizada, tiene la rama > testing, que cuando este estable y segura pasará a ser la debian estable 9, > y tiene la rama Sid, donde tienes lo ultimo y que contentamente se le > actualizan y agregan cosas nuevas, por lo tanto no es la más estable ni la > más segura, porque no todo esta probado al 99%. Quieres tener lo más actual > y novedoso y seguir usando debian, pues instalas la rama sid y listo. Salu2. > Por eso me mudo pa Fedora server -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
El 02/03/16 a las 14:29, låzaro escribió: Thread name: "Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]" Mail number: 2 Date: Wed, Mar 02, 2016 In reply to: Arian Molina Aguilera El 02/03/16 a las 13:16, låzaro escribió: aptitude update Current status: 6 updates [+6], 42551 new [+1]. root@openfire:~# aptitude upgrade The following packages will be upgraded: libssl1.0.0 openssl perl perl-base perl-modules python-pil The following packages are RECOMMENDED but will NOT be installed: libarchive-extract-perl libcgi-pm-perl libmodule-build-perl libmodule-pluggable-perl libpackage-constants-perl libpod-latex-perl libterm-ui-perl libtext-soundex-perl rename 6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 8,429 kB of archives. After unpacking 5,120 B will be used. Do you want to continue? [Y/n/?] Genial!!! :D Yo no hablo mal de debian, aunque hable fuerte; como comenté anteriormente. Pero no solo de actualizaciones de seguridad se vive. No entiendo, si actualizan las de seguridad, porque no actualizan las versiones también. Que cada empaquetador pruebe su estabilidad y la actualize. Arch tiene una rama estable y una testing, porque debian no puede tener lo mismo y ser roll-release también, si tiene uno de los mejores manipulador de paquetes brother cuando entenderás ningún server que se respete ninguna de las distros más reconocidas. Redhat7, Suse 12, Ubuntu Server 14.04, Etc, tienen lo ultimo de la paquetería. Se busca seguridad y estabilidad por encima de todo. Si quieres tener lo ultimo y sacrificar la seguridad y la estabilidad comprobada, no te recomiendo que lo uses en producción, si es tu maquina de trabajo y desarrollo pues bien que tengas lo ultimo, pero en los servers en producción no. Cuando se ha visto por ahí un server en un cloud de amazon o azure corriendo archlinux, nunca verdad. Entonces analiza mejor para que veas, socio y debian tienes más bien tres ramas, no solo dos, tienen la estable que es la actual debian 8.3. segura y garantizada, tiene la rama testing, que cuando este estable y segura pasará a ser la debian estable 9, y tiene la rama Sid, donde tienes lo ultimo y que contentamente se le actualizan y agregan cosas nuevas, por lo tanto no es la más estable ni la más segura, porque no todo esta probado al 99%. Quieres tener lo más actual y novedoso y seguir usando debian, pues instalas la rama sid y listo. Salu2. Por eso me mudo pa Fedora server tampoco es lo mismo socio, fedora server es la testing de redhat, para eso mejor me voy a centos 7 que es la versión pro de redhat 7 pero comunity, y como apoyo de la propia redhat, por cierto ya viste ovirt. wiki.ovirt.org Salu2. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] sobre inicio en un servidor
El 02/03/16 a las 14:14, låzaro escribió: Thread name: "Re: [Gutl-l] sobre inicio en un servidor" Mail number: 4 Date: Wed, Mar 02, 2016 In reply to: Arian Molina Aguilera El 02/03/16 a las 12:18, låzaro escribió: Para algo existen los firewall jejejeje, con ese criterio, te estás quemando y no lo sabes a ver, te explico lo básico, tienes N servicio, el cual tienes que tener público, digamos un servidor web, con una aplicación escrita en php y ni siquiera sabes que es una vulnerabilidad, viene un chino y te la explota. Por ejemplo, recién me explotaron una vulnerabilidad en un roundcube, de una entidad que necesariamente tenía que brindar un webmail de cara a una pública. Si aveces un servidor web supuestamente seguro, te lo follan, dime tú en uno desactualizado... uso pfsense, por delante de todo y tampoco expongo servicios directamente a internet todo queda detrás del firewall, hay un modulo muy interesante pfBlockerNG que te permite bloquear incluso bloques de países completos. Salu2. Suerte con eso. Los bloques de ip de países no siempre son de países. Los ISP se cambian las IP. Mira a Fumero por ejemplo, le llega tráfico de RAW socket a su ip que supuestamente es solo nacional. pfBlockerNG is the Next Generation of pfBlocker. Manage IPv4/v6 List Sources into 'Deny, Permit or Match' formats. Country Blocking Database by MaxMind Inc. (GeoLite Free version). De-Duplication, Suppression, and Reputation enhancements. Provision to download >from diverse List formats. Advanced Integration for Proofpoint ET IQRisk IP Reputation Threat Sources. Domain Name (DNSBL) blocking via Unbound DNS Resolver. Lo que no te entiendo es porque te empeñas a decir que es un servidor y sistema desactualizado, constantemente estoy actualizando mi debian, la mayorías de las actualizaciones son de security, y otra cosa son las aplicaciones desactualizadas, como fue el caso de tu roundcube o cualquier CMS del momento, hay que estar al día con eso también, muchos CMS están implementando actualizaciones de seguridad automáticas y también firewall por software. En definitiva la seguridad es un nicho muy grande, constantemente están apareciendo vulnerabilidades. Que supuestamente no se conocen por la mayoría de los usuarios y puede ser que un blackhacker si lo conozca y este explotándolo hasta el día que lo descubran en definitiva puedo decirte que he corrido con mucha suerte entonces, en los 10 años ya que llevo en la administración de redes y sistemas telemáticos. En fin como dice Taladrí saquen ustedes sus propias conclusiones. Salu2. Bueno, no quiero entrar en una discusión polémica que no conlleva a nada y no dejas de tener razón. Aunque tengo mil razones, no me gusta tirarle a debian y cogí bastante cuerda. Por tanto, dejémoslo como empate rígido y a los lectores con el privilegio de la duda ok un abrazo y salu2. -- Arian Molina Aguilera Administrador de Redes y Servicios Telemáticos Linux Usuario Registrado #392892 Telfs: +53(7)696-7510 ext 236 jabber: linuxc...@openmailbox.org Brascuba Cigarrillos S.A. La Habana. Cuba. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber. Albert Einstein” __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix y SASL
El 02/03/16 a las 14:19, Rommel Rodriguez Toirac escribió:
El Miércoles, 2 de marzo de 2016 13:01:34 Juan Carlos escribió:
El 02/03/2016 a las 08:59 a.m., Rommel Rodriguez Toirac escribió:
El Martes, 1 de marzo de 2016 16:55:53 Arian Molina Aguilera escribió:
El 01/03/16 a las 16:49, Manuel Mely escribió:
On 03/01/2016 02:28 PM, Rommel Rodriguez Toirac wrote:
No me llegó nada :-( Directamente no puedo recibir ni enviar correos
a dominios que no sean .cu y no pueden pasar de 1Mb de tamaño Nada
que nosotros todavía estamos en otra época.
De todos modos si pueden seguir el hilo o al menos postear la solucion
al problema por aqui mejor. Y si es posible acortar un poco el cuerpo
del mensaje (como acabo de hacer en este mensaje)
Sobre la solucion... te dejo en buenas manos :)
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
De la propia wiki de Centos Postfix SASL + Dovecot
Configuring SASL in postfix
To configure SASL in postfix, we need to make the following additions to
/etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
and add permit_sasl_authenticated to our smtpd_recipient_restrictions
section of /etc/postfix/main.cf (if you don't have a
smtpd_recipient_restrictions section, then the following example will
work fine):
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
Next we need to configure auth default in the authentication processes
section of /etc/dovecot.conf. Uncomment and/or add the following lines
as necessary (be careful as this section is heavily commented, some
entries already exist, others are commented out and need uncommenting
such as socket listen):
auth default {
mechanisms = plain login
passdb pam {
}
userdb passwd {
}
user = root
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Restart dovecot and reload postfix configuration setting:
service dovecot restart
postfix reload
De la wiki de debian
PostfixAndSASL
Translation(s): none
Simple Authentication and Security Layer (SASL) with Postfix SMTP
Tabla de Contenidos
SASL authentication in the Postfix SMTP server
Implementation using Cyrus SASL
Using saslauthd with PAM
Using auxprop with sasldb
Troubleshooting tip
Implementation using Dovecot SASL
SASL authentication in the Postfix SMTP client
Postfix and sbcglobal/yahoo/att
SASL authentication in the Postfix SMTP server
Implementation using Cyrus SASL
Using saslauthd with PAM
Setup Postfix with SMTP-AUTH over SASL2 with authentication against PAM
in a chroot() environment.
Note: The following steps have been carried out and verified on a Debian
7.1 system (Jan. 2015).
Note: SASL2 (saslauthd) creates a socket in its working directory.
Postfix (smtpd) needs access to this socket. If smtpd is running
chroot()ed (what is standard on Debian) saslauthd must run within this
chroot() environment also (though not being chrooted itself). While this
is fine for smtpd there are other services (Cyrus imapd for example)
which expect saslauthd 's socket at its "regular" location
(/var/run/saslauthd).
The recommended way to solve this is to run separate saslauthd processes
for Postfix and for others. Debian is prepared for this. Alternatively a
symlink-trick can be used. See below. Or you can disable chroot()ing by
editing the chroot columns in /etc/postfix/master.cf.
Install libsasl2-modules, postfix, sasl2-bin
Create a file /etc/postfix/sasl/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Setup a separate saslauthd process to be used from Postfix:
Create a copy of saslauthd's config file
~# cp /etc/default/saslauthd /etc/default/saslauthd-postfix
and edit it
START=yes
DESC="SASL Auth. Daemon for Postfix"
NAME="saslauthd-postf" # max. 15 char.
# Option -m sets working dir for saslauthd (contains socket)
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"#
postfix/smtp in chroot()
(See /usr/share/doc/sasl2-bin/README.Debian.gz)
Alternatively you can replace the directory /run/saslauthd with a
symlink to /var/spool/postfix/var/run/saslauthd
~# rm -rf /run/saslauthd
~# ln -s /var/spool/postfix/var/run/saslauthd /run/saslauthd
This is a quick-and-dirty hack, useful only for testing purposes. After
the next reboot the contents of /run will be reset.
Create required subdirectories in postfix chroot directory:
dpkg-statoverride --add root sasl 710
/var/spool/postfix/var/run/saslauthd
Add the user "postfix" to the group "sasl":
adduser postfix sasl
Restart saslauth
Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]
Thread name: "Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades [Hispasec @unaaldia]" Mail number: 3 Date: Wed, Mar 02, 2016 In reply to: Arian Molina Aguilera > > El 02/03/16 a las 14:29, låzaro escribió: > >Thread name: "Re: [Gutl-l] Fw: OpenSSL soluciona ocho vulnerabilidades > >[Hispasec @unaaldia]" > >Mail number: 2 > >Date: Wed, Mar 02, 2016 > >In reply to: Arian Molina Aguilera > >>El 02/03/16 a las 13:16, låzaro escribió: > aptitude update > > Current status: 6 updates [+6], 42551 new [+1]. > root@openfire:~# aptitude upgrade > The following packages will be upgraded: > libssl1.0.0 openssl perl perl-base perl-modules python-pil > The following packages are RECOMMENDED but will NOT be installed: > libarchive-extract-perl libcgi-pm-perl libmodule-build-perl > libmodule-pluggable-perl libpackage-constants-perl libpod-latex-perl > libterm-ui-perl > libtext-soundex-perl rename > 6 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > Need to get 8,429 kB of archives. After unpacking 5,120 B will be used. > Do you want to continue? [Y/n/?] > >>>Genial!!! :D > >>> > >>>Yo no hablo mal de debian, aunque hable fuerte; como comenté > >>>anteriormente. Pero no solo de actualizaciones de seguridad se vive. > >>> > >>>No entiendo, si actualizan las de seguridad, porque no actualizan las > >>>versiones también. Que cada empaquetador pruebe su estabilidad y la > >>>actualize. Arch tiene una rama estable y una testing, porque debian no > >>>puede tener lo mismo y ser roll-release también, si tiene uno de los > >>>mejores manipulador de paquetes > >>> > >>> > >>> > >>brother cuando entenderás ningún server que se respete ninguna de las > >>distros más reconocidas. Redhat7, Suse 12, Ubuntu Server 14.04, Etc, tienen > >>lo ultimo de la paquetería. Se busca seguridad y estabilidad por encima de > >>todo. Si quieres tener lo ultimo y sacrificar la seguridad y la estabilidad > >>comprobada, no te recomiendo que lo uses en producción, si es tu maquina de > >>trabajo y desarrollo pues bien que tengas lo ultimo, pero en los servers en > >>producción no. Cuando se ha visto por ahí un server en un cloud de amazon o > >>azure corriendo archlinux, nunca verdad. Entonces analiza mejor para que > >>veas, socio y debian tienes más bien tres ramas, no solo dos, tienen la > >>estable que es la actual debian 8.3. segura y garantizada, tiene la rama > >>testing, que cuando este estable y segura pasará a ser la debian estable 9, > >>y tiene la rama Sid, donde tienes lo ultimo y que contentamente se le > >>actualizan y agregan cosas nuevas, por lo tanto no es la más estable ni la > >>más segura, porque no todo esta probado al 99%. Quieres tener lo más actual > >>y novedoso y seguir usando debian, pues instalas la rama sid y listo. Salu2. > >> > >Por eso me mudo pa Fedora server > > > > > > > tampoco es lo mismo socio, fedora server es la testing de redhat, para eso > mejor me voy a centos 7 que es la versión pro de redhat 7 pero comunity, y > como apoyo de la propia redhat, por cierto ya viste ovirt. wiki.ovirt.org > Salu2. > parece una variante iteresante -- Warning! 100'000 pelos de escoba fueron introducidos satisfactoriamente en su puerto USB. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
