Interesante información sobre los requerimientos detallados a considerar durante la instalación en producción de un sistema de telefonía basado en Asterisk.

Considerando desde tarjetas, cpus, motherboars, redes, cableado, electricidad, etc.,

Puede verse desde la siguiene URL:

http://ofps.oreilly.com/titles/9780596517342/asterisk-InstallationPlanning.html

Escribo esto ya que hace unos días intenté adquirir unas diademas USB Logitech a través de internet en la página de ServComp("Empresa que innova en tecnología de cómputo"), pues todo pintaba bien, supongo que usan un sistema de venta en línea como oscommerce, zencart o algo así, me registro, le doy realizar pedido, veo que tienen un sistema de pagos a través de DineroMail (aunque prefiero PayPal) proceso el pago a través de la página de DineroMail -lo que me parece bien pues en teoría así no le tengo que dar mi información de Tarjeta de Crédito a un tercero-, me registro, hago el pago y listo me informan que el pedido está realizado, me llega un correo notificándome el pedido y el número de autorización bancaria.


Viacrucis.


Le envío una copia del correo que me envió dinero mail a la gente de ServComp, les llamo por teléfono para ver cuándo tienen las diademas disponibles y si puedo pasar a recogerlas a su sucursal de Polanco.


Me contestan que si, que el día de mañana las envían para allá y que por motivo de la compra tengo que enviarles llenado un formato a mano, por lo que tengo que imprimirlo, llenarlo a mano, y también enviarles copia de mi credencial de elector, así como datos de la tarjeta de crédito(Numero, Vigencia, PIN de Seguridad) y enviarle digitalizada de ambos lados, por lo que le digo a la Srita que eso es imposible que por ello se hizo la transferencia usando un tercero en este caso dinero mail y es por ello que se usa esta modalidad para no darle mis datos directamente a empresas las cuáles en México -podría ser que alguna hiciera mal uso de la información-.


Por lo que le comento que en su caso solo podría enviarle la cara frontal de la tarjeta mostrando solo los últimos 4 dígitos de la tarjeta, pero no parte trasera de la tarjeta donde viene el PIN, esto ya que el pago ya se realizó y dando estos datos se permite que se haga un segundo cobro, así que no acepto.


Ellos alegando en su justo derecho que hacen esto para respaldarse ante posibles fraudes de sus clientes, pero les comento que tienen razón pero no tengo porqué enviarles la parte dónde viene el PIN de la tarjeta, aparte si les envío la información quien me garantiza que tienen un sistema de seguridad avanzado para proteger sus datos, esto ya que mediante hacking o ingeniería social podrían obtener el password de sus cuentas de ventas y fácilmente tener el listado de las tarjetas de sus clientes, esto ya que no tienen un mecanismo de seguridad para almacenamiento de información.

Así que me niego a dar la información, pues este requisito burocrático me llevaría más de 10 minutos, en lo que imprimes, prendes la impresora, pones hojas, rellenas, el documento, digitalizas la credencial y la tarjeta, vuelves a digitalizar el formato, lo envías por correo, vaya mejor voy a plaza de la computación que me queda a 10 mins y hago el proceso de venta y recolección en 20 mins(ida y vuelta).


Desafortunadamente este proceso burocrático de las empresas .Com, se debe a la falta de atención de parte de los bancos para poder ofrecer un mecanismo seguro de compra por internet a sus clientes, si es fácil clonar tarjetas, hacer phishing y obtener datos, o ingeniería social a quienes ya tienen los datos y de ahí que al hacer comprar online los proveedores estén indefensos ante un posible fraude de identidad y de ahí que estás decisiones, pero por otra parte a los clientes nos complican más la existencia.

Debería haber un mecanismo a traves de un PIN adicional que no esté en la impresión de la tarjeta más que solo en la "memoria del usuario" y aparte de los datos de siempre también se pida ese PIN Personal que solo lo conocería el usuario dueño de la tarjeta -algo así como un token- obvio ahí si cada usuario es responsable de verificar de no dar este dato tan fácil en sitios de phishing comprobando el certificado de seguridad de cada sitio.

También DineroMail debería realizar antes de cualquier operación una validación de cuenta de usuario como lo hace PayPal, haciendo un cargo de 10 Pesos y reintroduciendo el número de autorización de la transacción, así se da luz verde para poder efectuar pagos bancarios sin necesidad de que nos tenga que validar también el proveedor para su salvaguarde.

Hace unas semanas intenté acceder al blog para subir algunos post pero al intentar dar mi login y password en el admin de este blog simplemente no pude acceder, por lo que pensé que igual se me había olvidado la contraseña, así que entré vía SSH al servidor, me validé en la base de datos y cambié el password usando md5 en la tabla de usuarios e intenté otra vez acceder al administrador del blog pero igual no me validaba.

Lo que pude ver es que si introducía un login o password erróneo si me lo indicaba, pero si daba los datos correctos, entonces tardaba unos segundos como intentando hacer algo pero regresaba a la página de validación, como si hubiera un error en la sessión.

Revisé que alguien no hubiera alterado el código del jaws, así como vi los logs para ver si algo raro ocurría con el servidor web o si estaba comprometido, pero nada, por lo que como tenía cosas que hacer lo dejé por semanas, hasta hoy en la madrugada que me dije hoy si quiero bloguear aunque tenga que cambiar la versión de jaws.

Por lo que respaldé la base de datos, pero al hacer el dumping, vi que me marcaba error en las tablas de ipvisitor, session y captcha, por lo que solo reparé las tablas con el siguiente comando:

mysqlcheck -u root -pPASSWORDROOT --auto-repair JAWSDB jam_session
mysqlcheck -u root -pPASSWORDROOT --auto-repair JAWSDB jam_ipvisitor
mysqlcheck -u root -pPASSWORDROOT --auto-repair JAWSDB jam_captcha_math

Y voilá también pude acceder al admin por lo que ahora aquí posteando la nota

Hace unos días en OaxRom nos contactó un cliente el cuál me comentó que tenía un servidor Asterisk que se lo habían implementado pero que últimamente tenía algunos problemas en su funcionamiento, esto ya que al parecer por unas fallas de energía había afectado su operación.

Por lo que la propuesta fue implementarle un servidor Asterisk reutilizando sus teléfonos IP y Tarjetas E1 ya que tiene una troncal digital de 30 canales con Axtel con señalización R2, en este caso dispone de una tarjeta OpenVox D115E.

El detalle es que esta tarjeta no está del todo soportada por el driver de Dahdi, por lo que hay que descargar unos drivers adicionales de OpenVox, instalarlos y parchar DAHDI para que se integre dentro de la plataforma de DAHDI & Asterisk, para esto lo primero que se descargó fueron los drivers de la siguiente página:

Aquí se omiten algunos pasos de instalación de Asterisk y solo se enfoca a la parte de OpenVox, en este blog ya tengo algunos tutoriales de como instalar Asterisk form Scratch en Debian & Ubuntu Server y se pueden complementar con este How to.


Instalar OSLEC como cancelador de eco por software, si no se tiene una tarjeta con módulo de eco por hardware se recomienda OSLEC, previamente hay que compilar OSLEC.






Con lo anterior ya podemos instalar la tarjeta y tenerlo soportado en DAHDI, así como instalar Asterisk y tener soporte de R2.


Para la parte de la configuración del E1 es el mismo procedimiento que con una Tarjeta Sangoma A102 o una Digium.
Por ejemplo para un R2 de 30 canales quedaría así /etc/dahdi/system.conf




/etc/asterisk/chan_dahdi.conf




Cómo comenté al inicio en este tutorial se omiten detalles sobre la instalación y configuración de Asterisk, pues solo nos enfocamos a la parte de OpenVox que para algún usuario con un poco de experiencia sabrá cómo organizar la información que aquí incluímos.

Espero alguien le sirva este tutorial y cualquier duda pueden postearla para irlas resolviendo.

Actualmente Asterisk se está convirtiendo en el Software Líder de SoftSwitch, siendo el favorito desde pequeñas empresas hasta grandes corporativos, por lo que su amplio uso e implementación en diversos países del mundo lo ha hecho un blanco importante para los "hackers" que desean obtener acceso a estos servidores y poder conseguir llamadas gratuitas.

Instalar un Asterisk es cosa sencilla con múltiples proyectos "All in One" como lo es Elastix por ejemplo, la distro más famosa que ya incluye diversas aplicaciones alrededor de la platforma de Asterisk, por lo que para muchos usuarios nóveles les es muy fácil implementar PBX bajo esta plataforma pero sin conocimientos avanzados que los ayude a proteger sus servidores al estar expuestos en internet, esto ya que muchos les es fácil ponerlos en DMZ para tener un acceso remoto.

Actualmente existen varias herramientas de auditoría SIP que permite detectar vulnerabilidades en servidores Asterisk, herramientas que también son usadas por los crackers para detectar cuentas SIP y explotarlas. Una de estas herramientas es SIP Vicious la cuál permite escanear un sevidor SIP y detectar que cuentas SIP están disponibles, cuáles requieren passwords y cuáles no, así como también pueden llegar a obtener el passwords de cuentas SIP cuánto estos no son complejos.

Una de las formas más rápidas de dar el primer portazo a escaners SIP es mediante una opción que se coloca en SIP.CONF o sip_custom.conf para los usuarios de FreePBX y Elastix.

Esa opción es:

alwaysauthreject=yes


Esta debe ser la primer opción en el proceso de asegurar un Asterisk, posteriormente estaré posteando sobre un Detector de Intrusos para SIP.

Uno de los clásicos problemas al tener una IP Pública Dinámica con telmex o algún otro provedor, es que los correos electrónicos no salen como por ejemplo cuándo envías un mail desde una aplicación PHP, este es rechazado por el servidor destino ya que no estamos autentificados para enviar correos.

Una solución es instalar postfix como un smarthost(relay host) no como Internet Site, esto hará que postfix no envíe el correo al dominio destino, si no más bien use un servidor de correos externo como puente y así los servidores destinos acepten el correo.

En este caso pongo la liga de un tutorial bastante práctico el cuál me sirvió para resolver este detalle en unos minutos y así quitarme el problema que me había acosado por bastante rato.

http://albertomolina.wordpress.com/2009/01/04/configurar-postfix-a-traves-de-un-relay-host-autenticado-gmail/

Hace tiempo instalé untangle como solución para proteger la red interna así como también para bloquear el acceso a todos los sitios web y solo habilitar unos cuántos sitios, aparte que también con untangle se pudo bloquear diversos protocolos y con ello cerrar el acceso a messenger, redes p2p, etc. Solo que semanas después hubo un apagón y me dañó la instalación de untangle, por lo que antes de reinstalar untangle decidí probar otra solución y para ello encontré diversas como smoothwall, ipcop, pfsense, etc., otra cuestión que también me animó a cambiarme de untangle es que las aplicaciones básicas como filtrado y bloqueo de puertos son libres, pero ya la parte de políticas y demás aplicaciones son con costo anual y por número de máquinas por lo que la solución se volvía impagable.

Al final del día me decidí por IPCop la cuál me resultó fácil de instalar y solo al principio me causó problemas la parte de la compatibilidad de las tarjetas pero quedo solucionado con tarjetas PC 10/100 3Com que tenía por ahí.

IPCop es un proyecto GNU/GPL. Se trata de un firewall basado en Linux que nos brinda una interesante gama de posibilidades a la hora de conectar una red local a Internet. La última versión es la 1.4.20. Su interfaz de usuario es completamente web (aunque permite también acceso por SSH puerto 222) y esta disponible en múltiples idiomas.

Requiere de un hardware dedicado y permite gestionar el acceso a Internet, la seguridad y la interacción de hasta cuatro redes distintas que, en la jerga del IPCop, se denominan GREEN, BLUE, ORANGE y RED. Las mismas tienen las siguientes características:

Lista de Tarjetas de Red compatibles con IPCop http://www.ipcop.org/index-pn.php?module=pnWikka&tag=IPCopHCLv01&time=2007-04-05+06%3A11%3A44

GREEN: Esta es la interfase de red de nuestra LAN o red de área local. Aquí es donde conectaremos todos nuestros equipos que necesiten mayor protección, como servidores que no tengan que tener presencia en Internet y puestos de trabajo. Los dispositivos que se encuentren conectados a esta interfase tendrán acceso irrestricto a las interfases RED, BLUE y ORANGE, o sea que podrán salir a Internet (y conectarse a los equipos que se encuentren en cualquiera de estas otras tres redes) por cualquier puerto, pero a su vez los equipos de la interfase RED (equipos en Internet) no pueden iniciar conexiones a ningún equipo que se encuentre en las interfases GREEN, BLUE y ORANGE. En otras palabras, estarán protegidos del exterior, en el sentido que no son accesibles desde Internet.

BLUE: Es la interfase que se asigna normalmente para conectar un access point de modo que se puedan conectar dispositivos inalámbricos. De todas maneras sirve para conectar

cualquier otra red que se necesite sea esta inalámbrica o no. Los dispositivos que se encuentren en esta red, no podrán iniciar una conexión a los dispositivos que se encuentren en la interfase GREEN, pero salvo esta excepción, contarán con el mismo nivel de acceso y protección que cuentan los dispositivos conectados a la interfase GREEN. No es necesario activar esta interfase en una instalación de IPCop si no se cuenta con más de una red, o no se va a utilizar un router inalámbrico(*).

ORANGE: Esta es la interfase que se utilizará para montar una DMZ o zona desmilitarizada. Principalmente se utiliza para montar servidores web, de correo, de ftp, etc. que deban tener presencia en Internet; o sea que sean accesibles desde Internet, pero que en el caso que se produzca alguna intrusión a algún equipo de esta red, eso no comprometa la seguridad de nuestra red interna (GREEN). Los equipos que formen parte de la red ORANGE no podrán iniciar conexiones a ninguno de los dispositivos que se encuentren en las interfases GREEN y BLUE. No es necesario activar esta interfase en una instalación de IPCop si no se piensa utilizar una DMZ.

RED: Es la interfase de red que nos conectará directamente a nuestro proveedor de Internet. Puede ser una conexión ADSL, cablemodem, una línea dedicada o hasta inclusive un modem telefónico común. Obviamente que por razones de ancho de banda esta última opción es desaconsejable, pero es perfectamente factible tenerla configurada para una contingencia en la cual nuestro proveedor de Internet tenga inconvenientes para brindarnos nuestro vínculo habitual, pero si este operativo el acceso dialup. Cualquier instalación de IPCop contará con esta interfase habilitada. (Soporta tanto dispositivos ethernet como US Como aclaración cabe destacar que los equipos que están en la misma red, ya sea esta GREEN, BLUE u ORANGE, tienen la posiañlbilidad de iniciar conexiones entre ellos.

(*) En el caso de contar con un router wifi, si bien es conveniente, no es obligatorio que este conectado a la interfase blue, ya que se podrá conectar sin problemas a la interfase GREEN.


Funcionalidades

IPCop brinda una amplia gama de funcionalidades que van más allá de las que ofrecen algunos firewalls comerciales. Sin pretender explicar cada una de ellas y solo a modo de numeración, tenemos: