Re: [Serusers] rtpproxy address filling

To answer my own question, I just set up a lab test to verify this. After the session is up and the address has been 'pre-filled', if rtpproxy receives a packet on the same UDP port as one of the call legs but from a different IP, it changes the address to which it forwards the stream. It immediately jumped into my mind that this could be a security vulnerability since a remote attacker could effectively bring down all sessions on an rtpproxy just by doing a UDP scan. I wanted to see if this was possible so I setup a new test with 32 concurrent calls on an rtpproxy server. The calls were setup and all streams were being forwarded correctly. I then used 'nmap' to scan all UDP ports used by rtpproxy. Initially nothing happened, but then I tried it again with a regular data_length and it effectively destroyed all sessions by pointing them to the nmap PC. The rtpproxy console confirms the address change with 32 messages like these: callee's address filled in: 192.168.2.6:40318 (RTP) {this is the nmap PC} caller's address filled in: 192.168.2.6:40318 (RTP) {this is the nmap PC} What do you think? Is this too far fecthed to worry about? Maxim, can you provide a fix that ignores IP Address changes and just acts on Port changes or does something critical break here? I can't think of a reason other than a bouncing DSL line that would require the rtpproxy server to worry about an IP Address change or a complicated NAT/Routing setup with multiple public IP Addresses. Thanks, Andres Andres wrote: