Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE).
Imagine this scenario:
- A calls B. This produces a "Start" acc action, so a SQL INSERT.
- After 1 minute A crashes (no BYE sent and RTP stop).
- After 20 secs with no RTP MediaProxy sends an "Update" action to radius server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK).
- But now imagine that user B sends a BYE after 2 hours using the same From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!!
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?
Hi Iñaki,
I would blame the ua sending the false BYE. Usually the BYE packets must be authenticated, therefore coming from a trusted source.
DanB
On Feb 8, 2008 5:17 PM, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE).
Imagine this scenario:
A calls B. This produces a "Start" acc action, so a SQL INSERT.
After 1 minute A crashes (no BYE sent and RTP stop).
After 20 secs with no RTP MediaProxy sends an "Update" action to radius
server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK).
- But now imagine that user B sends a BYE after 2 hours using the same
From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!!
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?
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Perhaps modifying the RADIUS update query so that acctstoptime = 0 before an update is allowed would help. Using the alternate update query you could log malicious update attempts.
Norm
Dan-Cristian Bogos wrote:
Hi Iñaki,
I would blame the ua sending the false BYE. Usually the BYE packets must be authenticated, therefore coming from a trusted source.
DanB
On Feb 8, 2008 5:17 PM, Iñaki Baz Castillo <ibc@in.ilimit.es mailto:ibc@in.ilimit.es> wrote:
Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE). Imagine this scenario: - A calls B. This produces a "Start" acc action, so a SQL INSERT. - After 1 minute A crashes (no BYE sent and RTP stop). - After 20 secs with no RTP MediaProxy sends an "Update" action to radius server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK). - But now imagine that user B sends a BYE after 2 hours using the same From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!! 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? -- Iñaki Baz Castillo ibc@in.ilimit.es <mailto:ibc@in.ilimit.es> _______________________________________________ Users mailing list Users@lists.openser.org <mailto:Users@lists.openser.org> http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
IMHO, OpenSER should act on the UPDATE from mediaproxy and kill the dialog by initiating a BYE. But, it is just a proxy and cannot initiate requests, so, the accounting software should watchout for those events and consider only the first "Stop Billing" event and ignore the rest.
Sri.
On Feb 8, 2008 11:28 AM, Norman Brandinger norm@goes.com wrote:
Perhaps modifying the RADIUS update query so that acctstoptime = 0 before an update is allowed would help. Using the alternate update query you could log malicious update attempts.
Norm
Dan-Cristian Bogos wrote:
Hi Iñaki,
I would blame the ua sending the false BYE. Usually the BYE packets must be authenticated, therefore coming from a trusted source.
DanB
On Feb 8, 2008 5:17 PM, Iñaki Baz Castillo <ibc@in.ilimit.es mailto:ibc@in.ilimit.es> wrote:
Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE). Imagine this scenario: - A calls B. This produces a "Start" acc action, so a SQL INSERT. - After 1 minute A crashes (no BYE sent and RTP stop). - After 20 secs with no RTP MediaProxy sends an "Update" action to radius server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK). - But now imagine that user B sends a BYE after 2 hours using the same From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!! 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? -- Iñaki Baz Castillo ibc@in.ilimit.es <mailto:ibc@in.ilimit.es> _______________________________________________ Users mailing list Users@lists.openser.org <mailto:Users@lists.openser.org> http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
On Friday 08 February 2008 17:36:13 Sri Rao wrote:
IMHO, OpenSER should act on the UPDATE from mediaproxy and kill the dialog by initiating a BYE. But, it is just a proxy and cannot initiate requests, so, the accounting software should watchout for those events and consider only the first "Stop Billing" event and ignore the rest.
Even if OpenSer could generate a BYE it doesn't avoid a malicious user sending a malicious BYE after days.
On Friday 08 February 2008 17:28:40 Norman Brandinger wrote:
Perhaps modifying the RADIUS update query so that acctstoptime = 0 before an update is allowed would help.
Sorry, I don't understand what you mean, could you explain it please? Thanks a lot.
I guess he means to set acctstoptime = 0 in the DB, and if that value is changed then to not allow a new update.
-> only allow update if acctstoptime = 0
cheers,
Patrick.
On Friday 08 February 2008 17:28:40 Norman Brandinger wrote:
Perhaps modifying the RADIUS update query so that acctstoptime = 0 before an update is allowed would help.
Sorry, I don't understand what you mean, could you explain it please? Thanks a lot.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
On Friday 08 February 2008 18:25:13 Patrick Miccio wrote:
I guess he means to set acctstoptime = 0 in the DB, and if that value is changed then to not allow a new update.
-> only allow update if acctstoptime = 0
Nice solution !!!
I'm beginning those days with FreeRadius but I think that SQL clausule is easy to implement for STOP action.
BTW... what would occur if an UAC send an INVITE with exactly same From/To/Call-ID parameters than any previous already acounted call? XD
BTW... what would occur if an UAC send an INVITE with exactly same From/To/Call-ID parameters than any previous already acounted call? XD
well I guess you should store start time and end time as well :)
cheers
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
El Viernes, 8 de Febrero de 2008, Iñaki Baz Castillo escribió:
BTW... what would occur if an UAC send an INVITE with exactly same From/To/Call-ID parameters than any previous already acounted call? XD
Opss, forget it... Of course, that is not possible since To_tag is chosen by called ;)
RADIUS:
sql.conf or whatever you call it:
<snip>
WHERE acctsessionid = '%{Acct-Session-Id}' \ AND acctuniqueid = '%{Acct-Unique-Session-Id}' \ AND username = '%{SQL-User-Name}' \ AND nasipaddress = '%{NAS-IP-Address}'" </snip>
AND acctstoptime = 0
Norm
Patrick Miccio wrote:
I guess he means to set acctstoptime = 0 in the DB, and if that value is changed then to not allow a new update.
-> only allow update if acctstoptime = 0
cheers,
Patrick.
On Friday 08 February 2008 17:28:40 Norman Brandinger wrote:
Perhaps modifying the RADIUS update query so that acctstoptime = 0 before an update is allowed would help.
Sorry, I don't understand what you mean, could you explain it please? Thanks a lot.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
On Friday 08 February 2008 18:34:31 Norman Brandinger wrote:
RADIUS:
sql.conf or whatever you call it:
<snip>
WHERE acctsessionid = '%{Acct-Session-Id}' \ AND acctuniqueid = '%{Acct-Unique-Session-Id}' \ AND username = '%{SQL-User-Name}' \ AND nasipaddress = '%{NAS-IP-Address}'"</snip>
AND acctstoptime = 0
Thanks :)
On Friday 08 February 2008 18:34:31 Norman Brandinger wrote:
RADIUS:
sql.conf or whatever you call it:
<snip>
WHERE acctsessionid = '%{Acct-Session-Id}' \ AND acctuniqueid = '%{Acct-Unique-Session-Id}' \ AND username = '%{SQL-User-Name}' \ AND nasipaddress = '%{NAS-IP-Address}'"</snip>
AND acctstoptime = 0
Humm, now I see that OpenSer already does it, but it's not perfect in conjunction with MediaProxy:
When OpenSer receives a BYE it sends a STOP action to radius server which does a SQL query containing:
----------------------------------------------------------- UPDATE radacct SET [...] ConnectInfo_stop = '' WHERE [...] AND ConnectInfo_stop IS NULL -----------------------------------------------------------
So if a new identical BYE is received the SQL query won't have place since "ConnectInfo_stop" now IS NOT NULL (OK).
The problem occurs if the BYE doesn't exist. Then MediaProxy sends an UPDATE action that will perform a SQL query like:
------------------------------------------------------------ UPDATE radacct SET [...] WHERE [...] ------------------------------------------------------------
This SQL doesn't set ConnectInfo_stop = '' so "ConnectInfo_stop" **remains NULL**. So then, the malicious user could send a BYE much later that will generate an STOP action and an effective SQL query.
POSSIBLE SOLUTION: ********************
MediaProxy SQL query (or FreeRadius SQL UPDATE action) does already set: MediaInfo = 'timeout'
The solution then could be setting a new clausule to STOP action:
where MediaInfo != "timeout"
In this way, if a calls ends because RTP timeout (there is not BYE) then a later malicious BYE wouldn't have effect.
On Friday 08 February 2008 17:24:45 Dan-Cristian Bogos wrote:
Hi Iñaki,
I would blame the ua sending the false BYE. Usually the BYE packets must be authenticated, therefore coming from a trusted source.
Do you suggest to ask digest auth for BYE's? what about if I call to an external user?
By using inter-peers relationships (TLS, trusted IP's) is not a solution. Imagine 2 providers (P1 and P2) and 2 users (A user of P1 and B user of P2):
- A user and calls PSTN 1234.
- P1 does a ENUM query that resolves to B@P2.
- The INVITE arrives to P2 which forwards it to B location.
- Call ends.
- After 2 weeks B sends a malicious BYE which will arrive to P1 and UPDATE accounting !!!!
On Friday 08 February 2008 17:17:08 Iñaki Baz Castillo wrote:
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?
Maybe the only solution is using a B2BUA for accounting that only performs an UPDATE action when receiving a BYE if the dialog really exist?
An already ended call will have no matching dialog/transaction existing in P1. So, "malicious" BYEs are treated as non-existent dialog/transactions. I doubt if it even makes it to the proxy core as it would be discared by the transaction layer itself.
On Feb 8, 2008 11:54 AM, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
On Friday 08 February 2008 17:17:08 Iñaki Baz Castillo wrote:
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?
Maybe the only solution is using a B2BUA for accounting that only performs an UPDATE action when receiving a BYE if the dialog really exist?
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
On Friday 08 February 2008 18:18:57 Sri Rao wrote:
An already ended call will have no matching dialog/transaction existing in P1. So, "malicious" BYEs are treated as non-existent dialog/transactions. I doubt if it even makes it to the proxy core as it would be discared by the transaction layer itself.
Your reasoning is incorrect: a BYE is a new transaction and a stateful proxy doesn't store dialog information (even if it stores dialgo info it doesn't match it).
For a stateful proxy there is NO difference between a BYE for a established call and a BYE sent 3 after weeks that call ended. If both SIP messages are identical the proxy can't do NOTHING to allow the first one and reject the second one (maybe very dirty SQL queries).
Maybe the only solution is using a B2BUA for accounting that only performs an UPDATE action when receiving a BYE if the dialog really exist?
in a similar way you could force Re-Invites every xxx seconds and do accounting based on SIP, depending on how much traffic your are going to be working with.
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Iñaki Baz Castillo writes:
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.
-- juha
El Viernes, 8 de Febrero de 2008, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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.
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.
-
Dan-Cristian Bogos -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
Norman Brandinger -
Patrick Miccio -
Sri Rao