Como puedo saber si mi Asterisk tiene alguna redirección
Victor
Un amigo me ha pedido que revise su Asterisk porque cree que cuando le
llegan unas llamadas de determinados países, no las recibe él sino que
se rebotan a algún sitio desconocido.
¿Como podría averiguar si esto es así?
Tengo acceso completo al servidor y estoy investigando los logs de /
etc/logs y la configuración de /etc/asterisk pero si os escribo es
porque no estoy viendo nada.
Tengo entendido (googleando) que para hacer una redirección tengo que
utilizar "exten =>" y he buscado esa cadena, he visto algunos sitios
donde se utiliza y no me dice mucho.
Lo más que he podido ver extraño es esto y no se si es normal:
"#include extensions_additional.conf
[from-pstn-custom]
;exten => _X.,1,Goto(timeconditions,1,1)
;exten => s,n,Goto(timeconditions,1,1)
[voxbone]
;exten => _X.,1,Goto(ext-queues,100,1)
exten => _X.,1,Goto(timeconditions,1,1)
[altecom-5xxxxxxxx]
exten => s,1,Goto(from-pstn,5xxxxxxx,1)
[altecom-5xxxxxxxx]
exten => s,1,Goto(from-pstn,5xxxxxxx,1)
[from-isdn-custom]
exten => s,1,Goto(from-pstn,91xxxxxx,1)
"
Muchas gracias por su ayuda por adelantado,
Víctor.
David Escañuela Alonso
Dtectar donde falla es mas costoso que modificarlo.
Un Saludo.
Ramses II
Mira en el CDR a ver si se están reportando esas llamadas…
Saludos,
Ramses
Williams Cardona
Verifica si hay alguna troncalizacion por SIP, IAX o ZAP que este levantando ese tipo de trafico.
otra es que viendo voxbone podria entrar cualqueir prefijo internacional, o este debe de tener un nivel de registro de troncal en sip.conf o iax.conf, importante es que sin duda alguna el CDR lo debe de estar capturando.
La otra alternativa es que si el conoce su trafico de donde se origina que todo lo que sea distinto a ese origen o prefijo lo envie directamente a un hangup, y antes que de una notificacion que prefijo no valido o algo para que cuando alguien trate de comunicarse con el o sus extensiones le notifique.
en mi experiencia para evitar eso, he puesto la ip de origen ya sea de la filial de mi cliente en los estados unidos, como los prefijos de donde vendra la llamada, en vista que su proveedor principal tiene una extension remota para comunicarse con la empresa directamente.
Saludos
William Cardona
Honduras
Víctor J. González
Víctor J. González
Con este post os contesto a todos pues mas o menos me habéis dicho lo mismo: Modifique dialplan, mire las troncalizaciones, el CDR y alguna cosa más que detallo pues sigo sin encontrar donde están las redirecciones.
1.- He seguido vuestros consejos y no se si he visto troncalización, es decir, según San Google para hacer una troncalización tengo que tocar los archivos sip.conf y extensions.conf
**************************
sip.conf*****************
**************************
[general]
port = 5060 ; Port to bind to (SIP is 5060)
bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine)
disallow=all
allow=ulaw
allow=alaw
context = from-sip-external ; Send unknown SIP callers to this context
callerid = Unknown
tos=0x68
language=es
#include sip_nat.conf
#include sip_custom.conf
#include sip_additional.conf
**************************
sip_additional.conf****
**************************
[1000] centralitas hasta la [2000]
;NO SE CUAL ES LA 6001
[6001]
username=6001
type=friend
secret=xxxxxx
record_out=Adhoc
record_in=Adhoc
qualify=yes
port=5060
nat=yes
mailbox=6001@device
host=dynamic
dtmfmode=rfc2833
context=from-internal
canreinvite=no
callerid=pepe <6001>
[999]
...
...
callerid=no_existe <999>
*********************************
sip_custom.conf**************
*********************************
;Tengo muchas IP's tipo telefónica: 84.x.x.x del mismo rango prácticamente que deduzco deben ser cada vez que el router de mi amigo se ha apagado y se le ha asignado una nueva dirección ip a su ip pública.
[84.x.x.11]
host=84.x.x.x
type=friend
insecure=very
context=voxbone
canreinvite=no
qualify=yes
disallow=all
allow=alaw
allow=ulaw
[84.x.x.22]
...
[84.x.x.33]
...
*********************************
extensions_custom.conf*****
*********************************
[from-pstn-custom]
;exten => _X.,1,Goto(timeconditions,1,1)
;exten => s,n,Goto(timeconditions,1,1)
[voxbone]
;exten => _X.,1,Goto(ext-queues,100,1)
exten => _X.,1,Goto(timeconditions,1,1)
[altecom-555xxxxxxx]
exten => s,1,Goto(from-pstn,555xxxxxx,1)
[altecom-555yyyyyyy]
exten => s,1,Goto(from-pstn,555yyyyyy,1)
[from-isdn-custom]
exten => s,1,Goto(from-pstn,91zzzzzzzz,1)
*********************************
extensions_additional.conf**
*********************************
//ARCHIVO ADJUNTO "extensions_additional.txt" POR SU EXTENSIÓN Y TAMAÑO//*********************************
extensions.conf***************
*********************************
//No he visto nada raro en él de patrones o de números de teléfono (no hay) //
//Si lo estimáis conveniente os lo pego en un futuro post//
********************************
FIN
********************************
**************************
iax.conf*****************
**************************
[general]
bindport = 4569 ; Port to bind to (IAX is 4569)
bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine)
disallow=all
allow=ulaw
allow=alaw
allow=gsm
mailboxdetail=yes
language=es
#include iax_custom.conf
#include iax_additional.conf
*********************************
FIN
*********************************
Pero los otros dos includes tienen:
*********************************
iax_aditional.conf ************
*********************************
[555xxxxxx]
type=friend
host=iaxX.altecom.net
disallow=all
context=altecom-555xxxxxx
allow=gsm
allow=g729
allow=alaw
allow=ulaw
[555yyyyyy]
type=friend
host=iaxX.altecom.net
disallow=all
context=altecom-555yyyyyy
allow=gsm
allow=g729
allow=alaw
allow=ulaw
[6000]
username=6000
type=friend
secret=xxxxxx
record_out=Adhoc
record_in=Adhoc
qualify=yes
port=4569
notransfer=yes
mailbox=6000@device
host=dynamic
context=from-internal
callerid=lumen <6000>
[altecom]
username=555zzzzzz
type=peer
secret=pilotet
qualify=yes
host=iaxX.altecom.net
[altecom-555pppppp]
username=555pppppp
type=peer
secret=pilotet
insecure=very
host=iaxX.altecom.net
fromuser=555pppppp
[altecom-555qqqqqq]
username=555qqqqqq
type=peer
secret=pilotet
insecure=very
host=iaxX.altecom.net
fromuser=555qqqqqq
[voiptalk]
username=rrrrrrrrr
type=peer
secret=rrrrrrr
qualify=yes
host=iaxX.voiptalk.org
auth=plaintext
*********************************
iax_custom.conf**************
*********************************
register=555xxxxxx:fxx...@iaxX.altecom.net
register=555yyyyyy:fxx...@iaxX.altecom.net
register=555zzzzzz:fxx...@iaxX.altecom.net
*********************************
FIN
********************************
¿Estos 555******* son algo extraño o es habitual en la configuración de Asterisk? Yo se que mi amigo depende solo de él, NO TIENE OTRAS CENTRALITAS ASOCIADAS FUERA DE SU OFICINA.
2.- Viendo el CDR observo esto que me mosquea (debido a que tengo entendido que cada vez que se utiliza "DIAL" es porque se está marcando desde dentro (o reenviando la llamada)): NOTA: Las llamadas que le están "cargando" a mi amigo, son llamadas siempre a IP's, no a teléfonos fijos
-- Executing dial("Local/700xxxxxxxxxx@from-internal-0e0f,2", "mISDN/1/0033xxxxxxxxx|120|trw") in new stack
-- Executing dial("Local/1001@from-internal-0eaf,2", "SIP/1001||tr") in new stack
Ejemplo de llamadas a través de SIP
-- Executing dial("SIP/1005-45449xxx", "SIP/1005||tr") in new stack
-- Executing dial("SIP/1007-42649xxx", "IAX2/altemcom/0039xxxxxxxxx|120|trw") in new stack
3.- Voxbone creo que no se está utilizando aunque solo lo he visto escrito una vez en extensions_custom.conf y nada ma´s, se que se está utilizando Asterisk con FreePBX.
Os pido ayuda porque es importante saber a donde y desde donde se han estado haciendo las llamadas y con qué patrón, pues ha habido algún día que se han detectado 40.000 minutos en 10 tristes llamadas nada más.
Un saludo y muchas gracias por toda vuestra ayuda, como véis, intento no molestaros mucho pero le estoy invirtiendo mucho trabajo.
Víctor.
Víctor J. González
-- Executing Queue("SIP/84.x.x.x-44aabbcc"...
-- Executing Goto("SIP/84.x.x.x-44aabbcc"...
-- Executing Executin GotoIfTime("SIP/84.x.x.x-44aabbcc"...
-- Executing Answer("SIP/84.x.x.x-44aabbcc"...
-- Executing Set("SIP/84.x.x.x-44aabbcc"...
Pues creo que 44aabbcc es una dirección ip en hexadecimal de las "indebidas".
Raúl Alexis Betancor Santana
> Hola otra vez,
>
> Con este post os contesto a todos pues mas o menos me habéis dicho lo
> mismo: Modifique dialplan, mire las troncalizaciones, el CDR y alguna cosa
> más que detallo pues sigo sin encontrar donde están las redirecciones.
En el tipo que te ha juankeado ese servidor y te tiene la mano metida por el
culo hasta tocarte la campañilla (perdona la expresión, pero es una forma muy
gráfica de que entiendas de que debes de formatear y volver a instalar ese
servidor desde 0)
> 1.- He seguido vuestros consejos y no se si he visto troncalización,
> es decir, según San Google para hacer una troncalización tengo que tocar
> los archivos sip.conf y extensions.conf
Es que lo de "troncal SIP" es un poco "ambiguo" ... es mas un
concepto "heredado" de la telefonía tradicional que otra cosa, pero bueno ..
> Mi archivo SIP.conf está limpio (pero NO SE si los archivos
> sip_additional.conf y sip_custom.conf están "alterados"):
>
> **************************
> > ;NO SE CUAL ES LA 6001
Pues sino sabes cual es ... preguntale a tu amigo se él ha creado esa
extensión y sino ... ya es una que está sobrando.
> > [999]
> > ...
> > ...
> > callerid=no_existe <999>
Lo mismo de antes.
> >
> > *********************************
> > sip_custom.conf**************
> > *********************************
> > ;Tengo muchas IP's tipo telefónica: 84.x.x.x del mismo rango
> > prácticamente que deduzco deben ser cada vez que el router de mi amigo se
> > ha apagado y se le ha asignado una nueva dirección ip a su ip pública.
Pues no, tiene pinta de ser las IP's del fulano que te la ha metido doblada,
puesto que se crea "sus peers", con su IP para poder hacer llamadas gratis a
través de tu central.
> > extensions.conf***************
> > *********************************
> > //No he visto nada raro en él de patrones o de números de teléfono (no
> > hay) //
> > //Si lo estimáis conveniente os lo pego en un futuro post//
Teniendo en cuenta que usas FreePBX no creo que veas patrones ninguno ... creo
recordar que tira de un agi super-genérico llamado dialparties.agi
> ¿Estos 555******* son algo extraño o es habitual en la configuración de
>
> > Asterisk? Yo se que mi amigo depende solo de él, NO TIENE OTRAS
> > CENTRALITAS ASOCIADAS FUERA DE SU OFICINA.
Eso es una configuración que "alguien" ha hecho para engancharse por IAX
contra cuentas del operador altecom.
> 2.- Viendo el CDR observo esto que me mosquea (debido a que tengo
> entendido que cada vez que se utiliza "DIAL" es porque se está marcando
> desde dentro (o reenviando la llamada)): NOTA: Las llamadas que le están
> "cargando" a mi amigo, son llamadas siempre a IP's, no a teléfonos fijos
Dial se usa para "llamar", ya sea internamente o externamente, eso dependerá
del dialplan y del uso que le des.
> Ejemplo de llamadas ¿locales?
>
> -- Executing dial("Local/700xxxxxxxxxx@from-internal-0e0f,2",
No te confundas ... "Local/" no significa que sean llamadas "locales", Local/
es un tipo de canal en Asterisk, como SIP/, IAX/, DAHDI/, ZAP/, etc.
> > "mISDN/1/0033xxxxxxxxx|120|trw") in new stack
Creo que a tu amigo le va a venir una facturita del operador de la RDSI que lo
va a flipar ...., llamadas a Inglaterra ... XDD
> Ejemplo de llamadas a través de SIP
>
> -- Executing dial("SIP/1005-45449xxx", "SIP/1005||tr") in new stack
El sip-peer 1005 llamandose a si misma ... X)
> > -- Executing dial("SIP/1007-42649xxx",
> > "IAX2/altemcom/0039xxxxxxxxx|120|trw") in new stack
El sip-peer llamando a Alemania mediante el enlace IAX con Altecom
> 3.- Voxbone creo que no se está utilizando aunque solo lo he visto
> escrito una vez en extensions_custom.conf y nada ma´s, se que se está
> utilizando Asterisk con FreePBX.
VoxBone es un proveedor de DID's
> Os pido ayuda porque es importante saber a donde y desde donde se han
> estado haciendo las llamadas y con qué patrón, pues ha habido algún día que
> se han detectado 40.000 minutos en 10 tristes llamadas nada más.
Yo empezaría por apagar ese servidor, luego lo formateaba y lo reinstalaba.
Por supuesto, esta vez que te lo instale alguien que sepa lo que está
haciendo.
> Un saludo y muchas gracias por toda vuestra ayuda, como véis, intento no
> molestaros mucho pero le estoy invirtiendo mucho trabajo.
> Víctor.
Sin ánimo de ofender, deberías de invertir tu tiempo en aprender lo básico,
porque te veo muy perdido.
Saludos
--
Raúl Alexis Betancor Santana
Dimensión Virtual
Raúl Alexis Betancor Santana
> También he detectado como extraño esto en el CDR:
>
> -- Executing Queue("SIP/84.x.x.x-44aabbcc"...
> -- Executing Goto("SIP/84.x.x.x-44aabbcc"...
> -- Executing Executin GotoIfTime("SIP/84.x.x.x-44aabbcc"...
> -- Executing Answer("SIP/84.x.x.x-44aabbcc"...
> -- Executing Set("SIP/84.x.x.x-44aabbcc"...
>
> Pues creo que 44aabbcc es una dirección ip en hexadecimal de las
> "indebidas".
No, 44aabbcc es simplemente parte del identificador del canal
Víctor J. González
Muchas gracias Raúl,
Además del "salero" con el que me has ido contestando, me ha gustado la profundidad de tus explicaciones. Cosa por lo que te estoy muy agradecido.
Se de antemano que no tengo mucha idea de Asterisk y telefonía VoIP pues mi sector dentro de la informática es otro bien distinto (si yo tengo poquita idea con este programa, imagínate mi amigo). Pero después de leerme manuales (que van siempre a configuración genérica, no empiezan con ideas abstractas y menos temas de Debugging que ya he buscado) y de intentar entender el registro CDR con más de 100 millones de registros a capón (algo muy duro, ni Nostradamus podría haberlo vaticinado en sus peores presagios), me he puesto en manos vuestras que lleváis tiempo pegándoos con el Asterisk y que sencillo lo que se dice sencillo no es.
Entonces y como necesito averiguar quien ha hecho qué, necesito comprender con vuestra ayuda una cosa; yo se que a mi amigo aunque creo que lleva un par de meses solo con el problema, todavía le han llamado a través de su centralita pero sin facturar por teléfono para que no se diera cuenta. Pero en esas llamadas a Alemania, Inglaterra etc... aparece el prefijo y el número de teléfono. ¿Como es posible que no le facturaran? es decir, ¿me gustaría saber cual es la centralita que recoge esas llamadas? --> pues entiendo yo que es una rellamada a través de internet y no de Red de Telefonía Básica (RTB).
Y sobre tu comentario:
No, 44aabbcc es simplemente parte del identificador del canal
¿Pero eso no es una IP? Pues está el CDR lleno de esos numeritos que haciendo la conversión, son siempre exáctamente octetos en hexadecimal que forman 0-255.0-255.0-255.0-255
> -- Executing dial("SIP/1005-45449xxx", "SIP/1005||tr") in new stack
El sip-peer 1005 llamandose a si misma ... X)
Raúl Alexis Betancor Santana
> Muchas gracias Raúl,
> Además del "salero" con el que me has ido contestando, me ha gustado la
> profundidad de tus explicaciones. Cosa por lo que te estoy muy agradecido.
De nada.
> Se de antemano que no tengo mucha idea de Asterisk y telefonía VoIP pues mi
> sector dentro de la informática es otro bien distinto (si yo tengo poquita
> idea con este programa, imagínate mi amigo). Pero después de leerme
> manuales (que van siempre a configuración genérica, no empiezan con ideas
> abstractas y menos temas de Debugging que ya he buscado) y de intentar
> entender el registro CDR con más de 100 millones de registros a capón (algo
> muy duro, ni Nostradamus podría haberlo vaticinado en sus peores
> presagios), me he puesto en manos vuestras que lleváis tiempo pegándoos con
> el Asterisk y que sencillo lo que se dice sencillo no es.
Una PBX con 100 millones de registros de CDR, no es algo "casero". Por lo que
mantengo la recomendación de que tu amigo llame a alguien que domine el tema,
con todos mis respetos hacia tí. Porque no es una cuestión baladí, ni que se
vaya a resolver con cuatro emails en la lista.
> Entonces y como necesito averiguar quien ha hecho qué, necesito comprender
> con vuestra ayuda una cosa; yo se que a mi amigo aunque creo que lleva un
> par de meses solo con el problema,
Con una sola hora con el problema tendría suficiente para que le arruinaran
(económicamente hablando).
> todavía le han llamado a través de su
> centralita pero sin facturar por teléfono para que no se diera cuenta.
Te das cuenta igual, porque ves registros en el CDR que no deberían de estar,
si el tipo ha tenido acceso al servidor por ssh o cualquier otro medio que le
permita modificar los ficheros de configuración y el dialplan, podría
configurar la centralita para hacer llamadas que JAMAS verías, a no ser por
la casualidad de que estés conectado al CLI cuando las hace.
> Pero
> en esas llamadas a Alemania, Inglaterra etc... aparece el prefijo y el
> número de teléfono. ¿Como es posible que no le facturaran? es decir, ¿me
> gustaría saber cual es la centralita que recoge esas llamadas?
La de tu amigo, ¿cual va a ser? ... alguien se está conectado a su centralita
y enviandole llamadas para que las enrute.
> --> pues
> entiendo yo que es una rellamada a través de internet y no de Red de
> Telefonía Básica (RTB).
Es que eso de "rellamada" es un concepto que tienes erroneamente asumido.
Rellamar es cuando has llamado primero, no te contestan y lo vuelves a
intentar.
Lo que le está pasando a tu amigo, es que alguien está mandando llamadas a su
centralita, que esta está rutando hacia otros sitios (lo cual es su trabajo,
dicho sea de paso).
> Asique, como puedo conocer sus destinos (que sospecho siempre eran los
> mismos).
Mirando el valor de "dst" en el CDR
> Y sobre tu comentario:
> > No, 44aabbcc es simplemente parte del identificador del canal
>
> ¿Pero eso no es una IP? Pues está el CDR lleno de esos numeritos que
> haciendo la conversión, son siempre exáctamente octetos en hexadecimal que
> forman 0-255.0-255.0-255.0-255
NO, es un identificador de canal, Asterisk usa como identificador de canal una
string tipo "TECH/peer-numejeroaleatorio", eso es simplemente el
identificador de ese canal mientras esté abierto y procesandose en el
dialplan.
> > > ;Tengo muchas IP's tipo telefónica: 84.x.x.x
>
> Sobre las IP's del fulano, yo creo más bien que son las de mi colega, pues
> los tres primeros números son los mismos, el último es el único que cambia
> levemente, como si fuera un router con IP dinámica de la misma compañía.
> ¿Podría ser?
No, tu colega, si es SU PROPIA central, no tiene que poner SU IP como peer en
el sip.conf ... los registros de sip.conf para los peers no se "generan
automáticamente", se meten por un operador HUMANO, en este caso, el juanker
de turno. Que ha demostrado que tampoco es muy listo ... porque hay formas
mucho más sibilinas de "robar" ese tráfico.
> Sobre las cuentas del operador "Altelcom" 555******, ¿el 555 indica alguna
> localización geográfica? ¿Como se puede seguir el rastro?
Son cuentas, que alguien ha configurado, no tiene porque tener ningún tipo de
asociación con nada más que el operador Altecom.
¿Seguir el rastro de qué? ... de una cuenta ¿? ...
> > > -- Executing dial("SIP/1005-45449xxx", "SIP/1005||tr") in new stack
> >
> > El sip-peer 1005 llamandose a si misma ... X)
>
> No he entendido el énfasis tuyo, entiendo que 1005 es una extensión de la
> centralita utilizando el protocolo SIP, y 45449xxx es una numeración en HEX
> que asocio con IP de alguien. y de nuevo SIP/1005 con la opción tr.
NOOOOOOOOOOOO, lo que significa ese linea del verbose del CLI es EXACTAMENTE:
- El dialplan me ha dicho que ejecute la aplicación Dial para el identificador
de canal SIP/1005-45449xxx con los parámetros para Dial SIP/1005|vacio|tr
Que dé la casualidad de que el identifcador del canal te permite identificar
el SIP peer (el 1005 en este caso) que está haciendo esa llamada, es pura
casualidad de como Asterisk construye los identificadores de canal.
El "énfasis" o cachondeo más bien ... viene por el tema de que si es el
sip-peer 1005 el que está haciendo esa llamada (cosa que se deduce del
identificador de canal), es un poco "tonto" cuanto menos ... que se esté
llamando a si mismo ... puesto que le está diciendo a Dial que llame a
SIP/1005 y active las opciones de "faked-ring" y "transferencia"
> PD: Me pondría a hacer un traceroute o whois si entendiese donde está el
> origen o donde está el destino o donde tengo que buscarlo (por eso he
> seleccionado lo que os he ido pegando).
Toda la información que necesitas está en el CDR, proque solo has de mirar los
campos dst para sabe a donde se han hecho las llamadas, el disposition para
saber si las contestaron o nó y el src para saber quien hizo esa llamada.
> He leído sobre el Asterisk que su
> sintáxis internamente es comando(argumento1, argumento2 y argumento3). En
> donde uno es el parámetro de entrada, la prioridad y opción.
Eso es la sintaxis del dialplan, que es
exten => <patrón de match ó match exacto>,<prioridad>,<aplicación> (<parámetro
1>,...,<parámetro n>)
La aplicación puede ser cualquiera de las que estén disponibles en el dialplan
en función de los módulos que estén cargados, como Set, Dial, GotoIf, DB,
etc. Y los parámetros ... pues evidentemente depende de cada aplicación lo
que admita
Saludos
Víctor J. González
Sigo con lo mío, por eso no había vuelto a escribir en el hilo hasta ahora que he observado que justo cuando mi conocido advirtió la serie de anomalías en su Asterisk que os he comentado, apareció esto en el log:
| DEBUG[2662] chan_sip.c: build_route: Contact hop: <sip:al...@64.x.x.x:4211> |
| VERBOSE[6115] logger.c: -- Executing NoOp("SIP/64.x.x.x-98a9xxxx", "Received incoming SIP connection from unknown peer to {teléfono DID}") in new stack |
| DEBUG[6115] pbx.c: Expression result is '0' |
| DEBUG[6115] pbx.c: Function result is '{teléfono DID}' |
| VERBOSE[6115] logger.c: -- Executing Set("SIP/64.x.x.x-98a9xxxx", "DID={teléfono DID}") in new stack |
| VERBOSE[6115] logger.c: -- Executing Goto("SIP/64.x.x.x-98a9xxxx", "s|1") in new stack |
| VERBOSE[6115] logger.c: -- Goto (from-sip-external,s,1) |
Y a partir de eso, ¿me podría alguien explicar si el código que voy a poner a continuación? (sin fechas por evitar "morralla") ¿puede ser una llamada redirigida?, es decir, ¿una llamada no atendida en el Asterisk del que estoy sacando ese log?, necesito poder tener la certeza que eso significa que le han hecho una redirección hacia el DID (Número Virtual de otro país según San Google) aunque supongo que nunca aparecerá los números de teléfono entrantes, debido a que solo hay números hexadecimales y direcciones IP en el log:
VERBOSE[6115] logger.c: == Spawn extension (from-sip-external, s, 6) exited non-zero on 'SIP/64.x.x.x-98a9xxxx'
VERBOSE[6115] logger.c: -- Executing NoOp("SIP/64.x.x.x-98a9xxxx", "Received incoming SIP connection from unknown peer to T") in new stack
DEBUG[6115] pbx.c: Expression result is '1'
DEBUG[6115] pbx.c: Function result is 's'
VERBOSE[6115] logger.c: -- Executing Set("SIP/64.x.x.x-98a9xxxx", "DID=s") in new stack
VERBOSE[6115] logger.c: -- Executing Goto("SIP/64.x.x.x-98a9xxxx", "s|1") in new stack
VERBOSE[6115] logger.c: -- Goto (from-sip-external,s,1)
DEBUG[6115] pbx.c: Expression result is '0'
VERBOSE[6115] logger.c: -- Executing GotoIf("SIP/64.x.x.x-98a9xxxx", "0?from-trunk|s|1") in new stack
DEBUG[6115] pbx.c: Not taking any branch
VERBOSE[6115] logger.c: -- Executing Set("SIP/64.x.x.x-98a9xxxx", "TIMEOUT(absolute)=15") in new stack
VERBOSE[6115] logger.c: -- Channel will hangup at 2009-01-01 01:01:01 UTC.
VERBOSE[6115] logger.c: -- Executing Answer("SIP/64.x.x.x-98a9xxxx", "") in new stack
VERBOSE[6115] logger.c: -- Executing Wait("SIP/64.x.x.x-98a9xxxx", "2") in new stack
DEBUG[2662] chan_sip.c: Stopping retransmission on '3c56756376f-0adfaskdfghfggsfdhj@snom320' of Request 345: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on '3c87967877-ghd88sghfghggg@snom320' of Request 348: Match Found
VERBOSE[6115] logger.c: -- Executing Playback("SIP/64.x.x.x-98a9xxxx", "ss-noservice") in new stack
VERBOSE[6115] logger.c: -- Playing 'ss-noservice' (language 'en')
DEBUG[2662] chan_sip.c: Stopping retransmission on '3cxxxxxxxxxxx-exxxxxxxxxxxxx@snom320' of Request 333: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on '3dxxxxxxxxxxx-exxxxxxxxxxxxx@snom320' of Request 333: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on '4cxxxxxxxxxxx-fxxxxxxxxxxxxxx@snom320' of Request 348: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on 'fdxxxxxxxxxxxx-axxxxxxxxxxxxx@snom320' of Request 345: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on 'fdxxxxxxxxxxxx...@172.168.0.2' of Request 102: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on 'fdxxxxxxxxxxxx...@172.168.0.2' of Request 102: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on 'fdxxxxxxxxxxxx...@172.168.0.2' of Request 102: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on 'fdxxxxxxxxxxxx...@172.168.0.2' of Request 102: Match Found
VERBOSE[6115] logger.c: -- Executing Congestion("SIP/64.x.x.x-98a9xxxx", "") in new stack
DEBUG[6115] channel.c: Driver for channel 'SIP/64.x.x.x-98a9xxxx' does not support indication 8, emulating it
DEBUG[2662] chan_sip.c: Stopping retransmission on '3sdf54g65g46a5g4...@172.168.0.2' of Request 102: Match Found
DEBUG[2662] chan_sip.c: Stopping retransmission on '4fd54gf54gdf5gfdg6...@172.168.0.2' of Request 102: Match Found
VERBOSE[6115] logger.c: == Spawn extension (from-sip-external, s, 6) exited non-zero on 'SIP/64.x.x.x-98a9xxxx'
Ya que ese patron (sin saber muy bien si empieza con el ==spawn o en otra línea, y donde acaba, pero ¡ese patrón!) se repite durante muchas veces en el tiempo en el que mi conocido cree que ha tenido redirecciones.
Todo parece que conlcuye con esto, días mas tarde:
VERBOSE[2655] logger.c: -- Remote UNIX connection
VERBOSE[1134] logger.c: Beginning asterisk restart....
DEBUG[17898] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
DEBUG[17898] cdr_addon_mysql.c: cdr_mysql: SQL command as follows: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode) VALUES ('2009-02-01 01:01:01
DEBUG[17898] chan_sip.c: update_call_counter() - decrement call limit counter
VERBOSE[1134] logger.c: Executing last minute cleanups
VERBOSE[1134] logger.c: == Destroying musiconhold processes
VERBOSE[1134] logger.c: Asterisk cleanly ending (0).
VERBOSE[1134] logger.c: Preparing for Asterisk restart...
VERBOSE[1134] logger.c: Restarting Asterisk NOW...
VERBOSE[2642] logger.c: Asterisk Event Logger Started /var/log/asterisk/event_log
VERBOSE[2635] logger.c: -- Registered extension context 'app-cf-busy-off'
VERBOSE[2635] logger.c: -- Including context 'app-cf-busy-off-custom' in context 'app-cf-busy-off'
VERBOSE[2635] logger.c: -- Added extension '*91' priority 1 to app-cf-busy-off
(He quitado línes muy similares, pero a grosso modo os he puesto el inicio, acciones, y el final)
Necesito sobretodo, si está demostrado que ha ocurrido una redirección "por abajo" de llamadas hacia otros lugares.
y ...Muchas gracias!
Raúl Alexis Betancor Santana
> Muy buenos días otra vez,
>
> Sigo con lo mío, por eso no había vuelto a escribir en el hilo hasta ahora
> que he observado que justo cuando mi conocido advirtió la serie de
> anomalías en su Asterisk que os he comentado, apareció esto en el log:
Sigues empeñado en no reinstalar ... tu mismo.
> Y a partir de eso, ¿me podría alguien explicar si el código que voy a poner
> a continuación? (sin fechas por evitar "morralla") ¿puede ser una llamada
> redirigida?, es decir, ¿una llamada no atendida en el Asterisk del que
> estoy sacando ese log?, necesito poder tener la certeza que eso significa
> que le han hecho una redirección hacia el DID (Número Virtual de otro país
> según San Google) aunque supongo que nunca aparecerá los números de
> teléfono entrantes, debido a que solo hay números hexadecimales y
> direcciones IP en el log:
Para resumir todo lo que pegas por debajo ....
- Fulano X (64.XXXXX) está intentando colarte llamadas
- Tu asterisk contesta la llamada
- Tu asterisk como no le cuadra que sea ningún trunk SIP ni un SIP-peer
autorizado ... le suelta la locución de ss-noservice
- El fulano reintenta
- Vuelve al paso 2
- El fulano reintenta
- Vuelve al paso 2
- Ad infinitum
- La entrada en el CDR es solo de la llamada entrante, nada más, por lo que se
ve ahi, no están "redirigiendo" nada, simplemente están intentando reventarle
el ojete a tu conocido.
Consejo: Como antes o después conseguirán abrirle el ojete y metersela doblada
(porque ni él ni tú, tenéis ni idea de seguridad en SIP, hay bugs gordos que
aparecen con frecuencia en chan_sip y compañia, que sino estás actualizado, te
la juegas ...), reinstalad y una de dos, o aprended desde 0 o contratad a
alguien que sepa.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Richard Alvarez
Hay buenos manuales de Asterisk ... busca en google.
Víctor J. González
No se si has leído todos los post del hilo, pero no me tiro casi un mes buscando información y preguntando las cosas lo menos posible y lo más escueto que puedo si antes no me pego por google, en google sobre asterisk hay infinidad de información, pero de información básica para crearte tu propio asterisk y configurarlo desde cero, para depuración (debugging) de asterisk hay lo que se dice poco y cosas muy concretas.
Personalmente no soy capaz de sacar más jugo a los manuales que ya me he bajado.
Sobre lo del laboratorio en casa, si, puedo averiguar una o dos formas de hacer una redirección, pero eso a efectos prácticos no me ayuda mucho, porque lo que tengo que analizar son los logs reales, no ficticios, ya que los archivos de configuración han sido "desmanipulados" casi con toda certeza, pues como he puesto también aquí mismo, se ven accesos remotos a través de consolas unix que han configurado a su antojo, pero te puedo asegurar una cosa, logs hay para parar un tren y es lo que estoy leyendo y no paro.
Por eso os pongo hasta donde llego, en vuestras manos,
Un saludo.
Richard Alvarez
Víctor J. González
Ya lo se, y es lo mismo que me ha recomendado Raúl, y de hecho el reinstalado ya está en proceso.
El problema es que estoy analizando la copia del ordenador para intentar averiguar, que, quien y por qué (si lo hay)...
Sobre lo de reinstalar, ya digo que está acabándose. Asique es algo menos a hacer :-)
Un saludo y gracias,
Víctor.
Ramses II
Cuando se dice reinstalar, si se te han colado por SSH con root, hablamos de empezar la reinstalación formateando el HD, no sabes qué regalo te han podido dejar…
Saludos,
Ramses
De:
aster...@googlegroups.com [mailto:aster...@googlegroups.com] En nombre de Víctor J. González
Enviado el: miércoles, 02 de
diciembre de 2009 10:22
Para: aster...@googlegroups.com
Asunto: [Asterisk-ES] Re: Como
puedo saber si mi Asterisk tiene alguna redirección
Buenos días Richard,
Iñaki Baz Castillo
<ramses....@gmail.com> escribió:
> Cuando se dice reinstalar, si se te han colado por SSH con root, hablamos de
> empezar la reinstalación formateando el HD, no sabes qué regalo te han
> podido dejar…
Cierto. Te pueden haber colado claves SSH (o sea, NO vale con cambiar
el password de root, hay que eliminar claves de
/root/.ssh/authorized_keys), te han podido manipular el
/etc/ssh/sshd_config para permitir a saber qué tipo de acceso...
Te ha podido crear una tarea "at" que dentro de dos semanas cree un
usuario o quite el firewall o tueste la máquina o...
Víctor J. González
No tiene iptables configurado (es decir, no tiene cortafuegos) pero solo hay desde el router, los puertos necesarios conectados DESDE el exterior hacia el servidor.
Y me parece saber lo que han podido hacer, tengo mis sospechas que generando cíclicamente cada minuto cuatro llamadas desde "uknown" que tienen como resultado un no-service y congestión, ha sido un ataque de denegación de servicios, ¿que pensáis?
Creo que eso es lo que le han hecho a mi conocido.
Siempre coinciden los segundos de cada minuto en los que se inicia una nueva llamada entrante, con lo cual es posible que no haya redirección hacia fuera sino un Ataque DoS. (O VoS de Voz-IP+DoS jeje).
¿Qué pensáis?
¡Gracias!
Saludos,
Víctor.
Iñaki Baz Castillo
<vict...@gmail.com> escribió:
> Muy interesante, lo he revisado y no hay "puertas traseras" aparentes (me
> falta echar un vistazo al cron, pero no creo).
¿Has mirado también las tareas programadas del demonio atd? ¿Has
revisado concienzudamente si la configuración del demonio SSH ha sido
alterada? ¿Has mirado el cron de todos los usuarios más los cron de
sistema (/etc/crontab, /etc/cron.*/*)?
Me parece muy osado pretender no reinstalar desde cero (formateando)
en vista de que aún no sabes ni cómo se ha producido la
vulnerabilidad.
Saludos.
Jose Luis Villalon
Has pasado herramientas para detectar rootkits? has comprobado los binarios mediante su hash con respecto a los originales? existen multitud de puntos donde podrian poner un backdoor; yo me pensaria seriamente reinstalar desde cero.
Un saludo
Iñaki Baz Castillo
<jose...@algarra.org> escribió:
> Buenas
>
> Has pasado herramientas para detectar rootkits? has comprobado los binarios
> mediante su hash con respecto a los originales? existen multitud de puntos
> donde podrian poner un backdoor; yo me pensaria seriamente reinstalar desde
> cero.
Yo creo que ya se lo hemos recomendado 3 ó 4 personas. Si él insiste
en que "ha revisado todo" y que "no hace falta reinstalar" allá él.
Personalmente creo que a mí me llevaría largos días comprobar todas
las posibles trampas creadas por el atacante, y ni de broma sabría
revisarlo todo.
Odicha
Es simple: copia forense para si quieres pasar el rato y reinstalación.
(yo las tengo programadas aunque no detecte nada ... =>modo paranoia)
TelecoSilvia
de correo. A parte de todo lo ya comentado yo miraría el .bash_history
de root, porque lo que le hicieron a él fue modificar las
instrucciones básicas como ls, grep, vim, etc... con lo que no había
ni rastro de ningún ataque ni modificación en los archivos
habituales.
Odicha
Odicha
>> Tengo un cliente que se le colaron hace poco en unos de sus servidores
>> de correo. A parte de todo lo ya comentado yo miraría el .bash_history
>> de root, porque lo que le hicieron a él fue modificar las
>> instrucciones básicas como ls, grep, vim, etc... con lo que no había
>> ni rastro de ningún ataque ni modificación en los archivos
>> habituales.
>>
Sobran las palabras de lo que hay que hacer.
TelecoSilvia
servidores, pero mi pequeño asterisk sobrevivió. Con lo que se me
subió un poco el ego, sobre si las cuatro cosas sobre seguridad que
aplico sirven o no sirven.
Ramses II
;-)
Siempre se aprende algo nuevo... :-)
Saludos,
Ramses
-----Mensaje original-----
nombre de TelecoSilvia
Enviado el: miércoles, 02 de diciembre de 2009 17:52
Para: asterisk-es
redirección
Víctor J. González
Ramses II
Poca llamada veo yo ahí para un DoS…
Saludos,
Ramses
De: aster...@googlegroups.com [mailto:aster...@googlegroups.com] En nombre de Víctor J. González
Enviado el: jueves, 03 de
diciembre de 2009 10:36
Para: aster...@googlegroups.com
Asunto: [Asterisk-ES] Re: Como
puedo saber si mi Asterisk tiene alguna redirección
Agradezco todas vuestras respuestas, pero reitero en que el sistema ya está reinstalado. Tengo una copia de todo el sistema para advertirle de lo que le hayan podido hacer.