[OpenSIPS-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?

[Dan Pascu]

On second thought, I think there is a simple way to avoid any fraud 
attempt, without checking anything in the BYE message. If the system can 
be instructed that for every BYE that is received to also generate itself 
a pair of BYEs from the dialog module, then even if the sender did send 
an invalid BYE that attempts to fraud the system, the BYEs generated by 
the dialog module will be correct and end the session or in the worst 
case they will receive a "session does not exist" reply that is ignored 
anyway.

Also if one uses the mediaproxy module on top of the dialog, then even if 
the BYE is not accepted by the gateway, if it is accepted by the proxy 
and ends the dialog it will also close the media session rendering the 
fraud attempt pointless as even though the PSTN gateway didn't close the 
call, there is no media path anymore forcing them to hang-up anyway.
Same is true even if mediaproxy doesn't run on top of the dialog module, 
as long as end_media_session is called on BYEs

On Wednesday 07 January 2009, Dan Pascu wrote:
> There is more than one way to skin a cat as they say and this case is
> no exception. There are multiple ways to send a BYE that will not be
> accepted but still make the proxy end the session (at least in the
> current implementation):
>
> 1. Lower CSEQ number
> 2. Low max forwards value, so the BYE doesn't reach the gateway
> 3. Invalid destination, so it gives timeout after a while
> 4. Wrong call-id, from-tag, to-tag which will make the BYE be rejected
> by the gateway
>
> All these have in common that they will get a negative reply to the
> BYE. So the idea would be not to not the dialog unless a 200 OK for the
> BYE is received.
>
> This can be worked around however too. I can send the BYE with all the
> dialog identification elements and the correct CSEQ number, but to a
> different ruri, pointing back to myself, and I can reply with 200 OK to
> the BYE. To avoid this the proxy would have to check the ruri as well.
>
> But then I can send one with the proper ruri, but a different route set
> that puts me in the front of the gateway, so when I receive the BYE,
> instead of forwarding it to the gateway as the route set requests, I
> reply myself with a 200 OK making it look like it came from the
> gateway.
>
> In the end it means, the proxy will have to verify everything (dialog
> identification elements, cseq, ruri, route set) to avoid fraud and also
> wait for a 200 OK, which makes it look more like a b2bua after all
>
> In the end the simplest solution is to eliminate the incentive for
> users to fraud that system, not to put bigger or more locks on it. This
> can be done by using a flat-fee model, but I agree that lobbying for
> this will fell on deaf ears with the big players that own the gateways.
> Still this is the simplest solution that not only eliminates the
> incentive for fraud, but also simplifies the over complex billing
> system and eliminates the burden the billing puts on a system with
> millions of users that have to be accounted in realtime.
>
> On Wednesday 07 January 2009, Adrian Georgescu wrote:
> > The dialog module could eventually be used to detect out of sync Cseq
> > and take decision to terminate the call. Is this feasible?
> >
> > Adrian
> >
> > On Dec 19, 2008, at 3:59 PM, Victor Pascual Ávila wrote:
> > > On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu
> > >
> > > <bogdan at voice-system.ro> wrote:
> > >> Hi Iñaki,
> > >>
> > >> Have you consider requesting auth for the BYE ? from SIP point of
> > >> view
> > >> is perfectly valid....
> > >
> > > I'm afraid this would only prevent external attackers but does not
> > > protect you from your own customers-- guys who have the credentials
> > > and wanna call for free.
> > >
> > > Cheers,
> > > --
> > > Victor Pascual Ávila
> > > _______________________________________________
> > > Users mailing list
> > > Users at lists.opensips.org
> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
Dan