add filter_registrar option #3080
Conversation
|
If UDP is used, nothing can be verified. Also, it would make more sense to use TLS and verify that server's certificate matches. |
The source IP address of the request is still set and we can verify it. I'm not sure what you mean.
Agreed, I'd prefer that too and BareSIP already provides that. However, we still have someone who wants to verify the server by its IP address (they don't use TLS unfortunately). |
Yes, but since in UDP there is no connection setup, sender can put whatever source address in the IP packet. So baresip can check that the source address of the IP packet matches, but cannot verify where it was sent from. |
|
I see, you're right. This of course does not protect against IP address spoofing. We all know that TLS is the solution, but we still have a feature request of a customer who wants to verify IP addresses and maybe other people would like that too. They have to be aware of the limitations of this approach, but I believe it could still be a useful feature for some people. |
|
Add clearly to the documentation that in case of UDP this setting cannot verify that a SIP request originated from the server, but only that source IP address of the request matched. |
|
Another security setting that could be added is "Send all in-dialog requests and replies to the outbound proxy". |
src/reg.c
Outdated
| if (!reg) | ||
| return NULL; | ||
|
|
||
| return sipreg_paddr(reg->sipreg); |
There was a problem hiding this comment.
Probably better to save paddr locally. Then there is no changes to libre needed ...
There was a problem hiding this comment.
You're right, that's much better. Done.
docs/examples/accounts
Outdated
| @@ -43,6 +43,7 @@ | |||
| # ;stunserver=stun:[user:pass]@host[:port] # see RFC 3986: Use of the format "user:password" in the userinfo field is deprecated. | |||
| # ;tcpsrcport=6060 | |||
| # ;inreq_allowed={yes, no} # default: yes | |||
| # ;server_only={yes, no} # default: no | |||
There was a problem hiding this comment.
TCP and TLS already have a connection to the server, which is difficult to spoof.
What happens if you are using SIP outbound with 2 edge proxies and load balancing,
will you accept incoming request from both ?
There was a problem hiding this comment.
You're right, now the peer address is stored in the reg struct in BareSIP and now all of the register clients are checked (i.e. all proxies defined in outbound will be allowed). Done.
|
Commonly outbound proxy or proxies are configured using domain name of the host(s) in the URI(s). Will this PR make DNS query to find their current IP addresses? |
|
Starts to looks to me that baresip account config is not a good way to solve the problem. Better to use firewall configuration in the host. |
5199473 to
dd96db6
Compare
That is something I considered, however I believe it is quite unlikely that the case occurs where we receive a REGISTER response from some IP A, and then receive an incoming request from the same "server" (i.e. URI) with a different IP. If the proxy is a domain name and it resolves to multiple IPs, then the client is likely also behind a NAT and not easily reachable from outside except for the IP that it sent the REGISTER request to. It's not impossible of course, but I think it could be enough to document this limitation if anyone wants to use this feature.
That's a valid point. If the maintainers agree and don't want to see this feature in BareSIP then we will have to accept that. |
|
Grandstream and Snom for example have such a setting:
|
dd96db6 to
ab7e90b
Compare
|
When baresip uses TCP or TLS to connect to outbound proxy/proxies, baresip should accept SIP requests only when they come via those connections. That is, there is no reason why baresip should accept incoming TCP or TLS connections from anywhere. And in case of UDP, source IP address does not prove anything as I have mentioned earlier. |
|
The SIP stack has a TCP server that is listening for incoming TCP/TLS and WS/WSS connections. Reusing naming from other products is nice for people already familiar with Snom products: Example: |
|
Sounds good, thank you for the feedback. I will start working on that. |
This makes sense. As I commented in above, when outbound proxy is used and baresip connects to it over TLS, TCP, or WS/WSS, there is no need for baresip to accept any connections from anywhere and thus not to listed for any incoming connections. |
aeb3355 to
ee2ed97
Compare
ee2ed97 to
d3e755c
Compare
|
This is ready for merge in our opinion. Any further suggestions? |
|
this look good. Please go ahead and merge it. |
|
Is there now the possibility to prevent all incoming connection setups when outbound proxy is defined using a connection oriented transport? |
|
Yes, @juha-h. For example with the following config: No listening ports will be opened and only outgoing TCP/TLS connections will work. The proxy/registrar will have to use the existing TCP/TLS connection. |
Very good. |
(cherry picked from commit a61ffe2)
(cherry picked from commit a61ffe2)
If the new config option
filter_registraris set to some transport (default:""), any incoming request of that transport is verified to have originated from a registered server's IP address (only makes sense for registered accountsregint>0). Further, no listening socket is opened for the connection-oriented transport protocols listed infilter_registrar(i.e. a UDP socket is always opened if UDP is configured). BareSIP's default behavior stays the exact same.Requires: