2011/12/28 Juha Heinanen <[email protected]> > > > An ugly client sends us a request with a malformed P-Asserted-Identity > > as follows: > > > > P-Asserted-Identity([email protected] > > > > Note that it's an *invalid* header. But Kamailio "allows" it and the > > request arrives to the GW. But the GW drops the request due to the > > malformed header so it sends NO reply at all. Then timeout occurs in > > the client transaction and failure_route block is called in which I > > call to defunct_gw(). > > check the headers you are forwarding to your gws.
There is no way to detect a header like I meant: P-Asserted-Identity([email protected] Kamailio parser does not detect such header as "P-Asserted-Identity". Also, it's unfeasible that a proxy checks the syntax of all the headers. Typically a proxy just cares about some few headers. > also, you can count > the number of failures yourself by using htable, for example, and not > defunct your gw based on the first failure. So the attacker should just send 5 malformed requests rather than one. > further, you could define a > timed route, and based on the htable, ping your gws. Right, but is failure_route executed for those locally sent requests? I must check it. > > Conclusion: an attacker could dissable my gws just by sending a simple > > malformed request. I strongly miss the monitorization feature in the > > old LCR module. > > my conclusion is as it was before: keep lcr module simple and do > monitoring separately. it might be possible to include a mi command to > manage defunct time of a gw, but i'm not sure about it, because > currently the tables may not include enough info to pinpoint a > particular gw. IMHO that's due to the design of the tables in LCR module. IMHO there should be a table just with gws definition (without containing the lcr_id field). It would make easier the management for cases like the present (just my opinion). Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
