8 Feb
2008
8 Feb
'08
5:17 p.m.
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(a)in.ilimit.es
8 Feb
8 Feb
5:24 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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(a)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(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5:28 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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(a)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(a)in.ilimit.es <mailto:ibc@in.ilimit.es>
_______________________________________________
Users mailing list
Users(a)lists.openser.org <mailto:Users@lists.openser.org>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5:36 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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(a)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(a)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(a)in.ilimit.es <mailto:ibc@in.ilimit.es>
_______________________________________________
Users mailing list
Users(a)lists.openser.org <mailto:Users@lists.openser.org>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5:51 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:50 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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(a)in.ilimit.es
6:25 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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:
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
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(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
6:30 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6:40 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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
9 Feb
9 Feb
2:59 a.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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 ;)
--
Iñaki Baz Castillo
8 Feb
8 Feb
6:34 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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:
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(a)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.
Sorry, I don't understand what you mean, could you explain it please?
Thanks a
lot.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
6:44 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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 :)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
7:16 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:49 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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 !!!!
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:54 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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(a)in.ilimit.es
6:18 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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(a)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(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
6:27 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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).
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6:28 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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
9:15 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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
9:56 p.m.
New subject: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
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.
5936
days inactive
5937
days old
19 comments
7 participants
participants (7)
-
Dan-Cristian Bogos -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
Norman Brandinger -
Patrick Miccio -
Sri Rao