8 Feb
2008
8 Feb
'08
10:56 p.m.
El Viernes, 8 de Febrero de 2008, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Not necesarialy. With some SQL conditions it's possible to avoid new and
fraudulent UPDATE's:
First BYE -> STOP action -> SQL query:
-----------------------------------------------------------
UPDATE radacct
SET [...] ConnectInfo_stop = ''
WHERE [...] AND ConnectInfo_stop IS NULL
-----------------------------------------------------------
Second BYE -> STOP action -> SQL query
-----------------------------------------------------------
UPDATE radacct
SET [...] ConnectInfo_stop = ''
WHERE [...] AND ConnectInfo_stop IS NULL
-----------------------------------------------------------
The second query has no effect since ConnectInfo_stop is not NULL now.
The above code is already implements in "sql.conf" (at least in CDRTool
proposed configuration). The issue I have reported occurs when there is not
the first BYE (UAC crashes). Then MediaProxy sends an UPDATE that doesn't set
ConnectInfo_stop = ''
(and it shouldn't do it).
So a malicious BYE could arrive much time later and perform succesfully the
SQL STOP action and increase call duration.
But playing a bit with UPDATE action SQL and STOP action SQL it's possible to
avoid this issue (in fact I've sent a patch solving it just now).
Best regards.
--
Iñaki Baz Castillo
How to avoid it? how to avoid anyone sending a
malicious BYE with
From&To tags and Call-ID from any other already ended call?
if you somehow can get hold of that information regarding a call, it is
hard to prevent its misuse. regarding your accounting problem, perhaps
update is not a good idea and it would be better to store stop records
separately from start records.