HI Inaki, well, it could be a way to prevent it. For BYEs, the path is pre-determined (via Route headers), so the dialog module could check if the path from the current BYE is the same as the path stored in dialog module by the INVITE - more or less if the BYE will follow the same path as the INVITE.
Just an idea.... Regards, Bogdan Iñaki Baz Castillo wrote: > El Viernes, 19 de Diciembre de 2008, Bogdan-Andrei Iancu escribió: > >> I guess you are refering to attacks like sending to proxy BYEs with RURI >> or Route info pointing somewhere else than the GW and the proxy will >> record end of call, but the GW does not actually receive a BYE. >> > > Victor just means that a real customer could authenticate his spoofed BYE but > this would be correctly handled with your suggestions in other mail: > > -------------- > You can control this via the "failed_transaction_flag" = > http://www.opensips.org/html/docs/modules/1.4.x/acc.html#id2500684 > > If direction is from GW, set the flag and account BYE disregarding the > reply code; If direction is from client, do not set and acount BYE only > if reply is 200 OK > ---------------- > > But what you mean now is really worse than what I was thinking about XD > For example, a legitime user in a legitime call with the gateway could send a > spoofed BYE with RURI pointing to **himself** (and reply 200 to himself), so > the proxy would account this call as terminated !!! > > There is no way to prevent it!!! > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
