Archivo

Archive for the ‘Centos’ Category

Instalación de Cluster de Kubernetes con Vagrant

marzo 4, 2020 Deja un comentario

Como parte de las labores de despliegue de software, la automatizar los procesos de infraestructura como código, es vital, para las actividades de Pentesting / Ethical Hacking tener construir tus entornos y escenarios locales de prueba sirve infinitamente para poder realizar tus P.O.C.

Es así que aquí va el procedimiento para automatizar la instalacion de un Cluster de Kubernetes usando Vagrant en Centos 7, este es el Escenario.

Ubuntu 16.04.6 LTS
Vagrant 2.2.3

Este es Vagantfile

###########################################

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = “2”
##Variables de configuracion ###
INTERFASE_BRIDGE = “wlps01”
DIRECCION_IP_BRIDGE = “192.168.1.151”
MASCARA_RED = “255.255.255.0”
PUERTA_ENLACE = “192.168.1.1”
##Configuracion de la VM master
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = “centos/7”
config.disksize.size = ’50GB’
config.vm.network “public_network”, bridge: INTERFASE_BRIDGE, ip: DIRECCION_IP_BRIDGE, netmask: MASCARA_RED, gateway: PUERTA_ENLACE
config.vm.hostname = “k8s-master”
config.vm.provider “virtualbox” do |v|
v.name = “k8s-master”
v.memory = 2048
v.cpus = 2
end
##Insertar llave SSH
config.ssh.insert_key = false
config.ssh.private_key_path = [‘~/.vagrant.d/insecure_private_key’, ‘~/.ssh/id_rsa’]
config.vm.provision “file”, source: “~/.ssh/id_rsa.pub”, destination: “~/.ssh/authorized_keys”
##Configuracion de SSH, SELINUX, IPTABLES, SWAP, FIREWALLD
config.vm.provision “shell”, inline: <<-EOC
sudo sed -i -e “\\#PasswordAuthentication yes# s#PasswordAuthentication yes#PasswordAuthentication no#g” /etc/ssh/sshd_config
sudo sed -i -e “\\#PermitRootLogin prohibit-password# s#PermitRootLogin prohibit-password#PermitRootLogin yes#g” /etc/ssh/sshd_config
sudo sed -i -e “\\#SELINUX=enforcing# s#SELINUX=enforcing#SELINUX=disabled#g” /etc/selinux/config
sudo systemctl restart sshd.service
sudo setenforce 0
sudo modprobe br_netfilter
sudo echo ‘1’ > /proc/sys/net/bridge/bridge-nf-call-iptables
sudo sed -i ‘/swap/d’ /etc/fstab
sudo swapoff -a
sudo systemctl stop firewalld
sudo systemctl mask firewalld
echo “Instalacion de Docker”
sudo yum -y install vim yum-utils net-tools
sudo yum -y install epel-release
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum-config-manager –add-repo=https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install -y docker-ce
echo “Instalacion de Kubernetes”
sudo yum-config-manager –add-repo=http://www.silcom.com.pe/soft/kubernetes.repo
sudo yum-config-manager –enable Kubernetes
sudo yum install -y kubelet kubeadm kubectl
echo “Fin de Instalacion”
EOC
##Reinicio de la VM
config.vm.provision :reload
##Configuracion e inicio de servicio docker y kunernestes
config.vm.provision “shell”, env: {“VARIP” => “192.168.1.151”}, inline: <<-EOC
sudo sed -i ‘1i $VARIP k8s-master k8s-master’ /etc/hosts
sudo systemctl start docker && systemctl enable docker
sudo systemctl start kubelet && systemctl enable kubelet
sudo sed -i ‘s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g’ /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
sudo systemctl daemon-reload
sudo systemctl restart kubelet
echo “Inicializacion de Cluster”
sudo kubeadm init –apiserver-advertise-address=$VARIP –pod-network-cidr=10.244.0.0/16
sudo mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
echo “Fin de Inicializacion de Cluster”
echo “Desplegar el pod network”
sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
echo “Pod network creado”
echo “FIN”
EOC
#Fin SSH
end

##############################################################3

Finalmente este es el video donde se muestra el despliegue :

Espero les sirva.
Saludos
@jroliva

 

Asterisk Rest Interface (ARI) en Issabel

enero 21, 2019 3 comentarios

Una de las cosas que me gusta hacer junto con el Ethical Hacking es instalar/programar aplicaciones de Voz para ello hace mucho tiempo que uso Asterisk, evidentemente esto a evolucionado gratamente para los que nos gusta esta área, a partir de Asterisk 12 apareció ARI o “Asterisk REST Interface” API que permite programar cualquier tipo de aplicación y que se ejecute en Asterisk.

Realmente ARI desde mi punto de vista ha cambiado la forma de ver lo que se puede hacer con Asterisk ya que no solo es pensar en una PBX, si no que ahora puedes tomar las librerías de ARI de los lenguajes mas importantes como python, C#, Java, Javascript, para conectarte a la API y empezar a desarrollar usando la aplicación que implementa Asterisk a nivel de dialplan llamada “Statis”.

En esa linea de ideas, debido a que Issabel trae Asterisk 13 podemos usar ARI sin problemas, a continuación veremos como realizar la configuración del mismo y realizar una prueba básica usado la herramienta wscat para conectarnos vía Websocket hacia la API en este caso ARI.

 

1.- Configurar ARI en Issabel

Ingresar al archivo http_custom.conf y activar ARI e indicarle en que puerto va funcionar de la siguiente forma:

Luego ingresar al archivo “ari.conf” el usuario y contraseña con el cual usaremos ARI

2.- Crear el dialplan

Ahora crearemos un dialplan para consumir y/o conectarse hacia ARI , para ello sera necesario declarar una extension 9000 donde invocaremos la aplicacion “Stasis” que es el mecanismo que utiliza Asterisk para entregar el control de un canal desde el plan de marcado hacia ARI.

En el archivo “extensions_custom.conf” incluimos un nuevo contexto llamado “ariwebsoket” de la siguiente forma:

 

Luego agregamos el final del archivo el nuevo conexto:

3.- Pruebas con ARI sobre Issabel.

Vamos a preparar una prueba muy sencilla de como nos podemos conectar mediante una petición de websoket hacia ARI para visualizar un evento en concreto, para ello sera necesario instalar wscat mediante nodejs.

curl -sL https://rpm.nodesource.com/setup_8.x | bash –
yum install -y nodejs
npm install -g wscat

Ahora desde una terminal nos conectamos a Issabel y ejecutamos

wscat -c “ws://localhost:8088/ari/events?api_key=ari:tucontrasena&app=hello-world”

Veremos que estamos conectados hacia ARI, de igual forma en el CLI veremos lo siguiente:

Lo cual nos indica que hay una conexión vía WebSocket hacia la aplicación “Hello-world”

Ahora al llamar a la extensión 9000 sera posible ver los detalles del evento mediante ARI de la siguiente forma

Esto es un test muy sencillo para validar que ARI funciona correctamente en Issabel, en un post nuevo veremos como desarrollar una aplicación con Nodejs haciendo uso de una cliente ARI para controlar Issabel.

Saludos
Juan Oliva.

 

 

SWIFT SWIFTNet Hacking en Redes Bancarias

junio 20, 2018 Deja un comentario

Luego de ver la noticia del hackeo del banco de chile, lean la publicación de la nota de Cesar Farro que lo detalla desde su perspectiva externa, me animé a escribir algo referente a ello, ya que es casi un año que vengo involucrado en realizar análisis de seguridad y vulnerabilidades a redes SWIFT justamente.

Como detrás de este tipos de servicios existen NDA vigentes, voy a ser bastante pragmático al respecto, emitiendo lineamientos que desde mi punto de vista personal, y que tendrían que ser de sentido común para este tipo de redes y al final conclusiones al respecto.

Al grano, normalmente siempre se tiene la perspectiva por fuera y no necesariamente por dentro, ya que como se entenderá son arquitecturas muy cerradas y no en lo tecnológico necesariamente ( si no pregunten el al banco de Chile 😀 ) digo esto por que al final terminamos hablando de los mismos componentes de siempre, como sistema operativos Windows, Unix, estaciones de trabajo, aplicaciones web, bases de datos, es decir nada que en una red empresarial deja de tener, empecemos desmenuzando la idea.

1.- QUE ES SWIFT ?
De pronto lo que uno mas conoce es el famoso código SWIFT para realizar transferencias internacionales, detrás de ello esta la “Society for Woldwide Interbank Financialla cual provee hardware/software que articula mediante programas y regulaciones en general toda esta actividad a la cual están afectas las entidades bancarias.

Dentro de los lineamientos se establecen arquitecturas de uso que pueden tener las entidad bancarias que se detallan a continuación :

Arquitectura A1 Full Stack
La interfaz de mensajería como la de comunicación están dentro del entorno del usuario. Este tipo de arquitectura también incluye soluciones alojadas donde el usuario tiene las licencias para la interfaz de mensajería y la interfaz de comunicación.

Arquitectura A2 Partial Stack
La interfaz de mensajería está dentro del entorno del usuario, pero un proveedor de servicios (para ejemplo, una agencia de servicios, SWIFT Alliance Remote Gateway o un centro de grupo) es licencia y administra la interfaz de comunicación. Arquitectura A3 – Connector
La aplicación de software (por ejemplo, Alliance Lite2 AutoClient, soluciones de transferencia de archivos) es utilizado en el entorno del usuario para facilitar la comunicación de aplicación a aplicación con una interfaz en un proveedor de servicios. Arquitectura B – No local user footprint
No se utiliza ningún componente de infraestructura específico de SWIFT dentro del entorno del usuario.
Fuente : https://www.accesspay.com/wp-content/uploads/2017/09/SWIFT_Customer_Security_Controls_Framework.pdf

2.- LOS CONTROLES
Dentro de las regulaciones a nivel de gestión de SWIFT solicita y obliga a cumplir los 27 controles ( obligatorios y recomendados) los mismos que están indicados en el “SWIFT Customer Security Controls Framework” al cual se puede acceder públicamente y además los empleados cursos como por ejemplo el “Customer security programme” entre otros.
Un detalle que se puede identificar en este contexto, es que las entidades tienen que  cumplir todos los controles y no solo los obligatorios ya que el común es pensar con eso ya están aprobando, cuando es todo lo contrario.

Sobre el cumplimiento de los controles, desde mi punto de vista, si bien es cierto en general la especificación de los controles es buena, sin embargo también muchos de los controles son muy ambiguos y poco precisos.

Basado en ello, un auditor/empleado que solo conoce la parte de gestión, puede interpretar de manera muy ligera los mismos, por ejemplo hacer cumplir un control determinado con solo con un procedimiento general, por el contrario alguien que maneja de parte de ingeniería/técnica la va interpretar de manera mas puntual, por ejemplo con una captura de pantalla del sistema o componente técnico, donde se muestra que se hace efectivo el control.

Para finalizar este punto indicar que la red SWIFT de la entidad va ser tan antigua como la misma lo permita en funcion a lo de siempre, no actualizar su arquitectura.

3- Evaluaciones de Cyberseguridad
Dentro de los controles de SWIFT se exige que es necesario hacer una evaluación de Ciberseguridad / Ethical Hacking a todos los componentes que involucran la arquitectura SWIFT. Por otro lado también a nivel de regulador bancario en el caso del Perú por ejemplo es la SBC que también lo exige, entonces tienen por lo menos dos servicios que tienen que ejecutar en diferentes ámbitos.

En ese sentido, es clave definir bien los activos a evaluar, sistemas involucrados, las actividades contempladas y horarios de ejecución, es decir es necesario definir bien el alcance, de lo contrario como en otros ámbitos, este punto solo será un puro formalismo a cumplir en el informe como desarrollar un escaneo o un análisis de vulnerabilidades automatizado que pasa a los informes.

4.- CONCLUSIONES Y RECOMENDACIONES

– Contar con la zona segura exclusiva/aislada de todo y textualmente de TODO sin ningún tipo de enlace hacia la red empresarial y hacia internet, esto es fundamental pero es muy difícil sobre todo por temas en primera instancia de flexibilidad, recordar el viejo dicho “mientras mas mas seguro menos flexible” y por otro lado de presupuesto, ya que estamos hablando para comenzar de tener toda la parte de switching, firewall, controladores de dominio y demás dispositivos de la arquitectura, exclusivos para la red SWIFT totalmente separado y con una función única.

– PC de operador de uso exclusivo, es decir solo para uso de SWIFT, evitar uso de servidores de salto, maquinas virtuales, citrix, escritorios remotos y demás elementos, como sabemos la mayor brecha de seguridad la producen los usuarios finales e inevitablemente se tiene que usar Windows (ojo aquí con las actualizaciones de seguridad), es recomendable primero que las PC de operador que acceden a los aplicativos SWIFT sean de uso exclusivo para ello y estén dentro de la zona segura , evidentemente siguiendo estándares de aseguramiento muy rígidos (Que normalmente no lo aplican no solo a nivel del sistema operativo, si no a nivel físico, ejemplo, contraseña de bios, desactivar USB, no tener software innecesario, no tener salida a internet entre otras.

– Uso de doble factor de autenticación, uso de tokens RSA para no solo autenticar hacia las aplicaciones, si no también a nivel de sistema operativo de los PC operador, reduce la brecha de riesgo.

– Servidores de producción SWIFT , Desde mi punto de vista usar servidores Windows para los servidores de producción y respaldo que exige SWIFT, es un error, cuando es sabido que Solaris/Unix ofrecen una menor brecha de seguridad en cuanto a vulnerabilidades reportadas.

– Software de Mensajería SWIFT y arquitectura general SWIFT va ser tan actualizada o no, como la entidad bancaria lo decida, SWIFT provee actualizaciones bastante constantes por ejemplo para el software de mensajería, mediante boletines y es labor de los responsables estar capacitados para realizar ello.

Finalmente basado en lo que he visto la mayor brecha de seguridad esta en no tener una red segura, usuarios operadores con estaciones Windows multiproposito y el y uso Windows en los servidores de mensajería.

Espero les sirva.
Saludos
Juan Oliva

 

 

 

 

Alta disponibilidad con Issabel PBX

agosto 24, 2017 20 comentarios

En escenarios donde la continuidad del negocio es un factor clave, contar con alta disponibilidad para servicios que se consideran críticos dentro de una organización es clave. En este caso concreto, el presente documento presenta la receta para implementar alta disponibilidad para la plataforma de comunicaciones Issabel PBX.

El software que hemos usado para tener alta disponibilidad se llama Pacemaker así como corosync, los cuales reemplazan al muy conocido heartbeat, el cual se encuentra descontinuado para Centos 7 que es el sistema operativo base de Issabel.

Si bien es cierto la plataforma Issabel, es sumamente estable como para confiar toda la carga a un solo recurso, no es ajena a fallas de otro tipo como factores, eléctricos, climáticos, de hardware, etc. Es por ello en caso de que uno de las plataformas fallase por los factores ya mencionados, dejaría sin comunicaciones a la organización, por lo tanto, es crítico tener el servicio en alta redundancia de forma que si un servidor falla, otro asume el servicio de manera transparente.

Espero les sirva el documento :

Descargar : Paper Alta disponibilidad con Issabel PBX

 

 

BeFree – Evento de Comunicaciones Open Source en Latinoamerica

junio 19, 2017 Deja un comentario

Como algunos saben, durante varios años vengo trabajando en temas de VoIP que es mi segunda pasión profesional luego del #Hacking y la seguridad , En este tiempo he estado involucrado en varias iniciativas como Elastix y FreePBX inclusive, siendo instructor en su momento del primero en su momento.

Si bien es cierto todo en la vida cambia y aveces bastante rápido, siempre he proclamado y seguido la linea del uso del código abierto para soluciones de VoIP – Telefonía IP, ya que esta provee un punto de inflexión para el crecimiento profesional de los individuos que la utilizamos, personalmente he podido modificar, crear, programar nuevas funcionalidades, modificar código para brindar seguridad a mi gusto, lo cual potencia en y un 1000% de una solución de comunicaciones unificadas.

Es así, que he tenido el honor de ser invitado como speaker/conferencista al BeFreeEvento de Comunicaciones Open Source en Latinoamerica, a desarrollarse este 21 de Junio en la ciudad de México, BeFree es un evento que busca fortalecer la comunidad de Comunicaciones Unificadas Open Source y difundir innovación en tecnologías emergentes, en el marco de estas ideas, se difundirá el ecosistema de Issabel (PBX IP basada en Software Libre y de Código Abierto) que busca en pocas palabras, apunta a ser la propuesta a muy largo plazo ante la desaparición de Elastix, la cual por supuesto ha concitado la atención de la prensa en México, como se muestra a continuación.

BeFree, estará compuesto de exposiciones, conferencias, talleres y un hacktaton, este ultimo es un espacio muy interesante desarrolladores, en donde podrán participar de un maratón de creación software o “Addons” para resolver alguna problemática en concreto.

Por otro lado también estarán presentes personalidades del mundo VoIP/Asterisk como Nicolas Gudiño – Creador de Asternic Call Center , David Duffett – Director, Comunidad Mundial de Asterisk en DIGIUM , Alfio Muñoz Experimentado Instructor de Asterisk , Saul Ibarra – Senior Software Developer en Atlassian “Jitsi”

Finalmente, brindaré una charla denominada @IssabelIP una relación segura” en donde mostrare pasos muy prácticos para fortalecer la plataforma y minimizar riesgos de seguridad en una plataforma IP PBX basada en Asterisk.

Es así que si estas en México, no puedes de dejar de asistir el BeFree y si eres lector de este blog, por favor acércate que sera un inmenso gusto poder platicar de los temas que nos interesan.

Nos vemos en el BeFree!!

 

Categorías:Asterisk, Centos, Eventos, Linux Etiquetas: , , , , ,

Kamailio entendiendo lógica de enrutamiento

junio 24, 2016 1 comentario

kamailio_logicaUno de los aspectos mas importantes y a la vez complicados de entender en Kamailio es la lógica de enrutamiento, debido a que tiene mucho que ver con el comportamiento del protocolo SIP.

Luego de mi charla en el ElastixWorld 2015 he tenido varias consulta referente a Kamailio y su comportamiento, un poco de ello lo explique en la charla “Usando el módulo PIKE en Elastix MT”  sin embargo en este post vamos a dar un alcance un poco mayor a este tema.

Primero vemos de manera genera lo que trae el archivo de configuración.

kamailioEsta imagen representa el esquema a nivel de parametrización de un archivo kamailio.cfg

Ahora vamos a ver cada punto:

1.- Definiciones Globales
Variables que vamos a usar a lo largo de la lógica de enrutamiento, las cuales pueden estar referidas a parámetros de log, direcciones IP y puertos que va escuchar el servidor, entre otras.

Tiene la siguiente forma:

Kamailio_globals2.- Sección de Módulos
Es donde definimos o “cargamos” los módulos vamos a user, por ejemplo el modulo de MYSQL  para guardar los registros en base de datos, o el modulo de TLS para cifrado de la señalización.

Tienen las siguiente forma:

kamailio_modules3.- Sección de configuración de módulos
En esta sección de parametrizan o configuran los módulos que hemos cargado en la sección  anterior, es muy importante configurar los módulos adecuadamente, ya que en algunos casos se activan con configuraciones por defecto, lo cuales pueden producir a la larga efectos extraños en el comportamiento.

Tienen la siguiente forma:

kamailio_modules4.- Bloques de rutas o lógica de enrutamiento
Esta es la sección es “clave” en el archivo de configuración ya que va establecer todo el camino que va seguir las peticiones SIP que recibamos, aquí hay que decir que no existe un patrón único, ya que uno puede hacer su lógica tan simple o tan compleja como lo desee, es decir con mas o menos bloques de rutas, sin embargo existen ciertos patrones que uno siempre va respetar o encontrar en otros archivos, estos son bloques de rutas que normalmente vamos a encontrar:

  • Principal (Main ó request_route)
  • Secundarias (REQINIT, WITHINDLG,REGISTRAR)
  • Failure (failure_route)
  • Branch (branch_route)

En esquema que pude realizar para mi autocompasión de un esquema de enrutamiento maso menos complejo:

kamailioComo se puede apreciar todo parte del bloque “Main” o “Request Route” y va ingresando a los demás bloques en donde cada uno tiene un objetivo puntual aplicado a la solicitud SIP entrante.

El bloque “REQINIT” tiene un papel muy importante ya que hace la mayoría de la comprobaciones previas como la evaluación de seguridad entre otras cosas.

Luego los métodos secundarios realizan el registro, localización y reenvío de las solicitudes SIP a otro server, un Asterisk por ejemplo. según sea el caso.

Enlaces:
https://www.kamailio.org/wiki/cookbooks/4.0.x/core
https://www.kamailio.org/wiki/tutorials/getting-started/main

Bueno espero que este post les amplié el panorama respecto al funcionamiento de kamailio, mas adelante desmenuzaremos otros aspectos de este formidable software.

Saludos
Juan Oliva

 

 

 

 

 

 

Instalación de Kamailio en Centos 7

junio 16, 2016 Deja un comentario

kamailioEs indudable que Kamailio es uno de los software mas potentes en el mundo de la VoIP , por los diferentes escenarios que puedes construir relativos a seguridad, escalabilidad, redundancia y todo lo que termina en “dad”

Sin embargo mucha gente que comienza a aprender su funcionamiento se choca con la curva de aprendizaje, que es necesario tener para entender este programa, como lo dije en un tweet “si no te gusta la consola, kamailio no es lo tuyo” sin embargo nada es imposible de aprender por su puesto.

kamailioAntes de comenzar definamos rápidamente un par de cosas, Kamailio no es igual ni parecido a Asterisk, formalmente Asterisk es lo que se llamaría un “back to back user agent” o “B2UA” el cual es utilizado tradicionalmente para ser una PBX IP ya que cuenta con un sin numero de aplicaciones para un PLANTA IP como voicemail, IVR, Colas,etc,etc.

kamailio

En cambio Kamailio es un SIP PROXY en todos los sentidos, como su nombre lo dice, este tipo de software solo conversa SIP y nada mas, el cual puede trabajar como proxy proiamente, location server, registrar server, servidor de presencia, call routing (LCR) los cuales son algunos de los roles en los que puede trabajar.

kamailioAhora la pregunta sería, para los nativos Asterisk, puedo usar Kamailio como lo uso con Asterisk ?
Pues la respuesta sería que no, ya que si bien es cierto ambos trabajar para brindar servicios de SIP VoIP tienen diferentes usos.

Entonces para que uso Kamailio?
Se puede usar para extender funcionalidades que de pronto Asterisk queda limitado, como por ejemplo, escalar usuarios, ya que Kamailio solo trabaja con SIP su consumo de procesamiento es mucho menor al de Asterisk y puede trabajar como servidor de registro, tambien puedo usarlo para balancear carga hacia un conjunto de servidores Asterisk, o para que sea mi servidor de proteccion hacia internet, solo por citar algunos ejemplos.

kamailioEntonces puedo integrar Asterisk con Kamailio ?
Si, puedo integrarlo de muchas maneras en realidad, algunas muy sencillas otras mas complicadas pero si se puede, de hecho hay varios proyectos y/o productos que han integrado con gran exito Kamalio-Asterisk como Elastix MT SIP WISE

Una vez que hemos revisado un poco para que podemos usar Kamailio, vamos a comenzar con este primer post sobre como instalar Kamailio sobre Centos 7 en una instalación mínima.

1.- Configurar el sistema base
Luego de instalar Centos 7 al mínimo es necesario “arreglar” un par de cosas

Instalar editor, ifconfig , EPEL
yum install net-tools vim
yum -y install epel-release

Desactivar SELINUX
vi /etc/selinux/config
SELINUX=disabled

Desactivar Firewall
systemctl disable firewalld
systemctl status firewalld

2.- Instalar Kamailio
Ahora vamos a instalar desde los repositorios.

Agregar un repositorio
vi /etc/yum.repos.d/kamailio.repo

[kamailio]
name=RPMs for Kamailio on CentOS 7
type=rpm-md
baseurl=http://rpm.kamailio.org/stable/CentOS_7/
gpgcheck=1
gpgkey=http://rpm.kamailio.org/stable/CentOS_7/repodata/repomd.xml.key
enabled=1

Instalar Kamailio básico
yum install kamailio kamailio-utils kamailio-debuginfo

3.- Crear un archivo de configuración básico

vim /etc/kamailio/kamailio.cfg

##### Inicio
debug=2
log_stderror=yes
fork=yes
mpath=”/usr/lib64/kamailio/modules”
loadmodule “pv.so”
loadmodule “xlog.so”

route {
xlog(“L_INFO”,”Requerimiento entrante: $rm de $si a $ru \n”);
forward();
}

onreply_route {
xlog(“L_INFO”,”Respuesta entrante: $rm $rr – de $si a $ru \n”);
}
##### Fin

4.- Levantar el servicio y revisar LOG

Levantamos el servicio y si todo está bien veremos esto
kamailio
También es necesario, sobre todo si salen errores verificar los logs

tail -f /var/log/messages
kamailio

Algunos Links que deberías ver si te interesa saber un poco mas de Kamailio :

Kamailio :: A Quick Introduction
http://es.slideshare.net/oej/kamailio-a-quick-introduction

Kamailio – The Story for Asterisk
http://es.slideshare.net/miconda/kamailiothestory

Usando el módulo PIKE en Elastix MT
http://es.slideshare.net/elastixorg/usando-el-mdulo-pike-en-elastix-mt?qid=db7c2bb7-5d61-4190-a76d-89dd0f97565a&v=&b=&from_search=24

 

En otros post veremos un poco mas kamailio y algunas aplicaciones practicas.

 

Espero les sirva.
Saludos
Juan Oliva