Instalar Cron en Centos

Hola a todos
Hoy me tope con un sorpresa al darme cuenta que un servidor no tenia cron (Centos Minimal).

Buscando en internet encontré las siguientes instrucciones para tener nuestro Cron operativo.

sudo yum install vixie-cron crontabs
sudo /sbin/chkconfig crond on
sudo /sbin/service crond start

Saludos

Script Fail2ban para Logwatch

Buscando en internet encontré el script para incluir en el reporte de Logwatch los baneos de Fail2Ban, este lo pueden descargar desde el siguiente link y solo deben copiar los archivos dentro de los directorios especificados en /etc/logwatch/... .

El reporte a mostrar sera del tipo:

--------------------- fail2ban-messages Begin ------------------------


 **Unmatched Entries**
 2011-05-24 04:02:02,189 fail2ban.filter : INFO   Log rotation detected for /var/log/asterisk/full
 2011-05-24 07:34:05,700 fail2ban.actions: WARNING [asterisk-iptables] Ban 37.58.89.213

 ---------------------- fail2ban-messages End -------------------------



Saludos.

Logwatch y Zimbra en Ubuntu.

Los siguientes son los pasos para la implementacion de logwatch en un servidor Ubuntu con servidor de correo Zimbra en su interior.

Como root:

apt-get install logwatch
update-rc.d -f postfix remove
mv /usr/sbin/sendmail /usr/sbin/sendmailbackup
ln -s /opt/zimbra/postfix/sbin/sendmail /usr/sbin/sendmail

vi /etc/cron.daily/00logwatch

Modificar la linea: /usr/sbin/logwatch --mailto

Y dejar asi: /usr/sbin/logwatch --detail 2 --output html --hostname yourservername --logdir /opt/zimbra/log --mailto tu@mail.cl

Para continuar con la configuración de logwatch pueden también ayudarse con el siguiente articulo: Cómo instalar Logwatch en ubuntu

Entendiendo el CDR

En el Blog  http://asteriskhelp.blogspot.com encontre la siguiente informacion de utilidad, espero que los Amigos no se enojen por hacerles Copy Paste :P.

-------------------------------------------------------------------------------------------------------------------------------

El Call Detail Record (Registro Detallado de Llamadas) es una aplicación que se encarga de almacenar el Log de llamadas que son cursadas a través de una PBX. En el presente artículo intentaré explicar su instalación, configuración y entendimiento de los registros para poder identificar los distintos tipos de llamadas.

Instalación:

Antes de comenzar con la instalación, es importante aclarar que, para realizar este artículo se utilizó Asterisk 1.4.37 y Addons 1.4.7, que son las versiones que mejores resultados me trajeron, hasta ahora.

Luego de descargar, descomprimir y entrar al menú de selección de la instalación de Asterisk(utilizando: make menuconfig), podemos acceder a la opción "Call Detail Recording", donde está la lista de módulos que permiten que el CDR almacene los logs en el formato / aplicación que necesitemos.

La siguiente tabla muestra las opciones que nos permite utilizar el CDR, para almacenar los registros de las llamadas, y las dependencias que necesita para que las mismas funcionen.

Applicación	Descripción	Dependencia
cdr_csv	Comma Separated Values CDR Backend	N/A
cdr_custom	Customizable Comma Separated Values CDR Backend	N/A
cdr_manager	Asterisk Manager Interface CDR Backend	N/A
cdr_odbc	ODBC CDR Backend	unixodbc, ltdl
cdr_pgsql	PostgreSQL CDR Backend	pgsql
cdr_radius	RADIUS CDR Backend	radius
cdr_sqlite	SQLite CDR Backend	sqlite
cdr_tds	MSSQL CDR Backend	freetds

Nótese que en la lista no se encuentra el soporte para mysql, no hay que preocuparse, porque este se encuentra en el paquete addons.

Finalizada la selección de las características para el CDR y de la instalación de Asterisk, pasaremos a instalar el paquete Addons, para poder incorporar el soporte para MySQL.

Hacemos los mismos pasos que antes, descargar, descomprimir y entrar al menú de selección y finalmente accedemos a la opción "Call Detail Recording", donde nos muestra: cdr_addon_mysql (En caso que no esté instalada la dependencia: mysqlclient, aparecerá con XXX al principio, por lo tanto debemos salir del menú e instalar dicha dependencia para luego volver a este paso.)

Configuración:

Una vez finalizado el proceso de instalación, haremos un recorrido por todos los archivos de configuración del CDR y finalmente nos centraremos en la configuración de la integración con MySQL.

La siguiente tabla muestra, la lista de archivos que permiten configurar las diferentes prestaciones del CDR:

Archivo	Descripción
cdr.conf	Configuración general del CDR
cdr_manager.conf	Acceso al CDR a través del AMI
cdr_pgsql.conf	Configuración para PostgresSQL
cdr_custom.conf	Configuración de Log Personalizado
cdr_mysql.conf	Configuración para MySQL
cdr_odbc.conf	Conector ODBC (Para cualquier base de datos)
cdr_tds.conf	Configuración para FreeTDS

cdr.conf

En este archivo vamos a cargar todas las configuraciones que son a nivel general, las cuales afectarían a todos los módulos que anteriormente mencionamos, ahora vamos a ver sus parámetros.

[general]

Parámetro	Valores	Descripción
enable	yes/no	Activa o desactiva la utilización del CDR.
unanswered	yes/no	Registrar las llamadas no atendidas
batch	yes/no	Permite almacenar los datos de las llamadas en un buffer, para luego enviarlos a donde quisiéramos almacenar. OJO! que activando esta opción, si bien se liberaría un poco de procesamiento a Asterisk, puede ocasionar posibles perdidas de datos, en caso que Asterisk se detenga.
size	Número entero	En caso que se active la opción de Batch, se define la cantidad de registros de CDR que se acumularán en el buffer, antes de ser enviados al medio de almacenamiento.
time	Número entero	En caso que se active la opción de Batch, se define la cantidad de tiempo máximo que deberán estar los registros almacenados en el buffer.
time	Número entero	En caso que se active la opción de Batch, se define la cantidad de tiempo máximo que deberán estar los registros almacenados en el buffer.
scheduleronly	yes/no	Asterisk utiliza un "scheduler" interno, para determinar en que momentos se envían los registros al medio de almacenamiento. Dicho envío se puede hacer en el mismo "thread" donde está el "scheduler" o bien crear un nuevo "thread" para realizar esta tarea. En caso que se configure un proceso Batch con pocos registros, el envío puede estar en el "thread" del "scheduler" (Configurar este parámetro en "yes"). Ahora si se configuró un Batch de mayor tamaño, por ejemplo size=10, es recomendable realizar esta tarea en un nuevo "thread" (Configurar este parámetro en "no").
safeshutdown	yes/no	Si hacemos un "stop now" en Asterisk y justo en ese momento se están enviando registros de CDR, al configurar este parámetro en "yes", se bloquea el apagado de Asterisk hasta que terminen de enviarse los registros.
endbeforehexten	yes/no	Generalmente el CDR no se cierra hasta que todos los internos finalicen su ejecución. Al habilitar esta opción el CDR se cerrará antes que se ejecute el hangup, lo que causaría que se pierdan algunos datos.

cdr_manager.conf

Permite acceder al CDR a través del AMI, para ello cuenta con una sola opción a configurar, que la vemos a continuación:

[General]

enabled = yes / no

cdr_pgsql.conf

Para activar el almacenamiento del CDR en PostgresSQL, se tendrá que ingresar los siguientes parámetros, que corresponden a los datos de acceso al servidor de Base de datos.

[global]

hostname=localhost

port=5432

dbname=asterisk

password=password

user=postgres

table=cdr

cdr_custom.conf

Aquí podremos personalizar en el formato, del archivo de texto plano, que queremos que se almacenen los registros de las llamadas. Estos serán guardados en el siguiente path: /var/log/asterisk/cdr-custom/Master.csv

[mappings]

Master.csv => ${CSV_QUOTE(${CDR(clid)})},${CSV_QUOTE(${CDR(src)})},${CSV_QUOTE(${CDR(dst)})},${CSV_QUOTE(${CDR(dcontext)})},${CSV_QUOTE(${CDR(channel)})},${CSV_QUOTE(${CDR(dstchannel)})},${CSV_QUOTE(${CDR(lastapp)})},${CSV_QUOTE(${CDR(lastdata)})},${CSV_QUOTE(${CDR(start)})},${CSV_QUOTE(${CDR(answer)})},${CSV_QUOTE(${CDR(end)})},${CSV_QUOTE(${CDR(duration)})},${CSV_QUOTE(${CDR(billsec)})},${CSV_QUOTE(${CDR(disposition)})},${CSV_QUOTE(${CDR(amaflags)})},${CSV_QUOTE(${CDR(accountcode)})},${CSV_QUOTE(${CDR(uniqueid)})},${CSV_QUOTE(${CDR(userfield)})}

En la línea anterior podemos cambiar el nombre del archivo, elegir que datos guardar y que separador utilizar.

cdr_mysql.conf

Al igual que con PostgresSQL, debemos configurar los datos de acceso al Servidor.

[global]

hostname = localhost

dbname=asteriskcdrdb

password = amp109

user = asteriskuser

userfield=1

port=3306

cdr_odbc.conf

Igual que los anteriores, excepto que aquí se configura el DSN que contiene los datos del servidor de base de datos al cual queremos almacenar los datos.

[global]

dsn=MySQL-test

username=username

password=password

loguniqueid=yes

dispositionstring=yes

table=cdr

usegmtime=no

Tabla de registro del CDR para SQL

En caso que utilicemos un servidor de base de datos, cualquier de los que soporta Asterisk, vamos a necesitar crear la tabla donde se almacenaran los datos. Para ello, presento a continuación el código SQL para crear la tabla:

CREATE TABLE `cdr` (

`calldate` datetime NOT NULL default '0000-00-00 00:00:00',

`clid` varchar(80) NOT NULL default '',

`src` varchar(80) NOT NULL default '',

`dst` varchar(80) NOT NULL default '',

`dcontext` varchar(80) NOT NULL default '',

`channel` varchar(80) NOT NULL default '',

`dstchannel` varchar(80) NOT NULL default '',

`lastapp` varchar(80) NOT NULL default '',

`lastdata` varchar(80) NOT NULL default '',

`duration` int(11) NOT NULL default '0',

`billsec` int(11) NOT NULL default '0',

`disposition` varchar(45) NOT NULL default '',

`amaflags` int(11) NOT NULL default '0',

`accountcode` varchar(20) NOT NULL default '',

`userfield` varchar(255) NOT NULL default '',

`uniqueid` VARCHAR(32) NOT NULL default ''

);

Ahora bien, para que las consultas sobre la tabla del CDR sean un poco más rápidas, lo que haremos es crear unos índices sobre las columnas que seguramente más utilizaremos:

ALTER TABLE `cdr` ADD INDEX ( `calldate` );

ALTER TABLE `cdr` ADD INDEX ( `dst` );

ALTER TABLE `cdr` ADD INDEX ( `uniqueid` );

Algunas consultas SQL

Bien, como frutilla del postre a continuación pondré algunos Queryes que tal vez sirvan para obtener distintos tipos de reportes, sobre el CDR. Obviamente estos dependen de la configuración de cada PBX.

- Cantidad de llamadas atendidas por día:

select date_format(calldate, "%Y-%m-%d"), count(*) from cdr where dcontext = 'from-pstn' group by 1;

- Cantidad de llamadas exitosas realizadas por día:

select date_format(calldate, "%Y-%m-%d"), count(*)  from cdr where dstchannel like 'DAHDI%' and disposition = 'ANSWERED' group by 1;

- Cantidad de llamadas fallidas por día:

select date_format(calldate, "%Y-%m-%d"), count(*)  from cdr where dstchannel like 'DAHDI%' and disposition = 'FAILED' group by 1;

- Cantidad de llamadas realizadas por un interno:

select * from cdr where dstchannel like 'DAHDI%' and disposition = 'ANSWERED' and calldate >= 'YYYY-MM-DD 00:00:00' and calldate <= 'YYYY-MM-DD 23;59;59' and src = NUMERO_INTERNO;

reemplazar YY-MM-DD por el día que deseamos consultar y NUMERO_INTERNO por la extensión.

Salto de restricciones en sudo

Se ha descubierto una vulnerabilidad en sudo que podría permitir a un atacante local eludir determinadas restricciones de seguridad. El fallo afecta a casi todas las distribuciones basadas en el kernel Linux.

Sudo es una herramienta de administración utilizada en muchas de las distribuciones basadas en el kernel Linux. Permite a los usuarios ejecutar comandos con los privilegios de otro, comúnmente de root, de forma controlada y segura. Sudo permite además ejecutar comandos en hosts remotos especificados en el fichero 'sudoers' mediante su nombre de máquina, IP, grupo de red, o dirección de red (IP y máscara de red).

Jan Lieskovsky ha descubierto esta vulnerabilidad identificada como CVE-2012-2337. Se debe a un error en la manera en que se concede el acceso a un determinado host, cuando existen múltiples máscaras de red en la parte de configuración de 'host' y 'host_list' del archivo 'sudoers'.

El fallo se introdujo cuando se agregó el soporte para IPv6 a sudo (hace aproximadamente 5 años), y podría producir una coincidencia en direcciones de red IPv4 cuando no debe. Esto podía permitir a usuarios autorizados en el archivo 'sudoers' realizar un salto de restricciones. De esta forma podrían ejecutar comandos sudo en cualquier host, independientemente de la configuración 'host_list', e incluso si la configuración para esa máscara de red impide la ejecución de dichos comandos.

Si en el archivo 'sudoers' no se incluyen redes IP para especificar el host, la vulnerabilidad no tiene ningún efecto. Por tanto este problema, aunque importante, no alcanza la gravedad del reciente fallo descubierto a finales de enero que permitía a cualquier atacante local convertirse en root.

Se encuentran afectadas por esta vulnerabilidad las versiones de sudo de la 1.6.9p3 hasta la 1.8.4p4. Desde la página oficial se pueden descargar las versiones de sudo 1.8.4p5 y 1.7.9p1 que corrigen este fallo. Muchas distribuciones han comenzado a distribuir paquetes propios que la solucionan.

Más información:

IP addresses in sudoers with netmask may match additional hosts

http://www.sudo.ws/sudo/alerts/netmask.html

Elevación de privilegios en sudo (en multitud de distribuciones)

http://unaaldia.hispasec.com/2012/01/elevacion-de-privilegios-en-sudo-en.html

FUente: http://unaaldia.hispasec.com/2012/05/salto-de-restricciones-en-sudo-en.html

Reflexiones de Seguridad en VoIP

Buscando en Internet me tope con una presentación sobre Telefonia IP en el margen de LACNIC XVII, esta es muy interesante y vale la pena leerla.



La presentación esta en el siguiente link

Fuente : Reflexiones de Seguridad en VoIP – LACSEC 2012

Cómo crear Pools en Citrix XenServer

Un Pool se define como dos o más maquinas Citrix XenServer que componen una misma entidad, de modo que pueden compartir recursos como máquinas virtuales, almacenamiento, etc. de forma centralizada.

Cuando se usa un Pool con almacenamiento compartido las máquinas virtuales se pueden mover en caliente (XenMotions) entre los hosts que componen el Pool, compartir templates, repositorios de ISOS, SR’s… Aporta también una agregación de recursos ya que si un Host ya no puede asumir más carga de maquinas virtuales, la  siguiente máquina virtual, será levantada en otro Host.

Esta Entidad es capaz de gestionar todas las máquinas virtuales en  conjunto indepen-dientemente de donde estén corriendo, es decir que en caso de caída de un host físico, las maquinas virtuales se pueden volver arrancar en otro host, siempre que tengamos almacena-miento compartido.

Veremos más adelante que si el Host caído es el denominado Master del pool, tendremos un problema un poco más serio.

Requisitos para crear un pool

1. Los hosts tienen que ser homogéneos, no se pueden mezclar CPUs AMD con CPUs INTEL.
2. Las CPUs tienen que ser del mismo modelo y soportar los mismos flags. Hay trucos para romper esta regla, pero no es recomendable de ningún modo, excepto en el caso que sea el flag “stepping”.
3. Tener una IP estática.
4. No ser miembro de otro pool, ni tener almacenamiento compartido.
5. Relojes sincronizados por NTP.

Integrando un Host a nuestro Pool por CLI

Entramos en la máquina que queremos añadir al Pool y ejecutamos:

#xe pool-join master-address=IP_Servidor_master master-username=root master-password=password.

Si ejecutamos xe pool-list veremos las propiedades básicas de nuestro pool:

# xe pool-list

• uuid ( RO) :  UUID del Pool
• name-label ( RW): nombre del Pool
• name-description ( RW):  Descripción (si hemos puesto alguna)
• master ( RO): UUID del host que esta designado como Master
• default-SR ( RW): El SR por defecto del Pool

Ahora ya podemos migrar nuestras maquinas entre hosts mediante xe vm-migrate:

#xe vm-migrate vm=Nombre de la VM host=Nombre del Host live=true

Quitando un Host de nuestro Pool

Tal vez nos interese quitar un Host del Pool, para ello podemos utilizar el siguiente comando:

# xe pool-eject host-uuid=UUID del host

Con esto me despido hasta la semana que viene, donde veremos cómo solucionar problemas relacionados con los pools ante caídas de hosts, cómo mover los roles de master y otras opciones para que cada día te sientas mejor usando Citrix XenServer.

Fuente: http://goo.gl/Qorx3

Logwatch: date::manip

Hace unos dias atrás Me percate de que algunos servidores dejaron de enviarme reportes Logwatch via correo. Hoy teniendo un rato libre revise los equipos encontrándome con el siguiente mensaje:


ERROR: Date::Manip unable to determine TimeZone.


Execute the following command in a shell prompt:
        perldoc Date::Manip
The section titled TIMEZONES describes valid TimeZones
and where they can be defined.

La solución es muy simple y consta de ejecutar la siguiente linea de comandos:

GMT -4 Santiago

echo '-0400' > /etc/timezone

Saludos.

Postfix warning: database /etc/postfix/virtual.db is older than source file /etc/postfix/virtual

Trabajando en un tema aparte de mi central Elastix me llamo la atención el mensaje "Postfix warning: database /etc/postfix/virtual.db is older than source file /etc/postfix/virtual".
Buscando en internet encontré la siguiente solución.

Ejecutar en la consola:

postmap /etc/postfix/virtual
postfix reload  

Fuente: http://blog.sft.waw.pl/

Se filtran mas de 55.000 cuentas de Twitter

Hoy un grupo de hackers anónimos filtró más de 55.000 cuentas de twitter username y la contraseña a través Pastebin. Es muy impactante ver como un número masivo de cuentas de Twitter son hackeadas.

"La plataforma de micro blogging esta consciente de este problema y estaba tomando las acciones necesarias para salvar la cuenta de esas personas de la actividad maliciosa" , dijo una información privilegiada Twitter.

Si quieres saber si tu cuenta esta entre las afectada es recomendable revisar los linka pastebin donde estan las cuentas: 1 2 3 4 5

Fuente: fayerwayer.com

Construyendo un sistema firewall/antispam telefónico

Hola. Nuevamente agregando lo ultimo que hay en la red.

Buscando en paginas amigas encontré un curioso sistema para realizar una blacklist personalizada en Asterisk.

El link es el siguiente: Link