[possibly solved] siproxd: How to better avoid bruteforce attempts?

ghm

[update]
Restricted siproxd to known users now and to user auth. Apparently it is otherwise pretty easy to just send a sip invite and try passwords. Essentially, someone was trying to hack into asterisk here. Without success but certainly better to close doors…
[/update]

Hi,

I see many of these in the syslog:

Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: passwsx@78.34.249.53 -> passwsx@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: 164@78.34.249.53 -> 164@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: 163@78.34.249.53 -> 163@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: passqaz@78.34.249.53 -> passqaz@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: passzxc@78.34.249.53 -> passzxc@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: 162@78.34.249.53 -> 162@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: 161@78.34.249.53 -> 161@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: passasd@78.34.249.53 -> passasd@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: passqwe@78.34.249.53 -> passqwe@78.34.249.53
Nov 18 23:57:19 	siproxd[2198]: plugin_logcall.c:120 INFO:ACK Call: 160@78.34.249.53 -> 160@78.34.249.53

Just an excerpt. Google says the bit before @[IP] comes from a brute force password list. I am aware that siproxd creates NAT rules and passes stuff to my phones - is there a way to block this stuff?

Thanks!

jimp

Why do you have siproxd exposed to the world?

It's usual use case is for outgoing SIP, not incoming.

ghm

@jimp:

Why do you have siproxd exposed to the world?

It's usual use case is for outgoing SIP, not incoming.

Good point actually. Because my sip provider support told me to open that when I had an issue with incoming calls not getting through. And I simply believed that was no problem…

Just disabled those 2 rules (one SIP, one RTP) and had the same issue again - but fiddled more as I now know these rules were evil and:

I now get incoming calls if I set my clients to "renew port forward every [30s]" - 1min would already be too long though and I then first need to do an outbound call to then get inbound again (can see that the inbound packages get caught in the firewall). 30s seems to work fine without the rules.

And even better: These baddies may have tried to use the proxy but could at least not use my account, my invoices are unspectacular. So apparently siproxd paid attention to the fact that they came through WAN and that is only defined as outbound interface.

Seems to be a bit shaky though: If I go to the siproxd config page, don't change anything and then just go e.g. to the dashboard, all incoming calls will get caught in the firewall until I restart the siproxd service.

ghm

@ghm:

I now get incoming calls if I set my clients to "renew port forward every [30s]" … 30s seems to work fine without the rules.

Or so I thought. However, after a reboot (cleaning all states etc) I can't get any incoming calls without the rules. Maybe one just after I do an outbound call but not dependably after idling times. It's just my FW log that fills up if I get a call but don't have the rule, see below…

My siproxd setup is pretty standard, just as recommended here: http://forum.pfsense.org/index.php/topic,10084.0.html

If you say "it's usual case is for outgoing, not incoming" - I need to receive incoming as I only have a SIP provider, no proper landline voice. If siproxd is not for incoming calls, I could only NAT these ports to my clients but then I would have to decide which one... which to avoid I use siproxd in the first place.

Jee, I actually thought my userconfig plus userauth had done the trick :)

capt.png_thumb

marcelloc

If your provider really need these rules, restrict it to provider's ip.

ghm

@marcelloc:

If your provider really need these rules, restrict it to provider's ip.

True, will do.

joako

You might be able to not use sip proxy and just set an outbound NAT rule for the SIP and RTP traffic with static port = yes. If you maintain a registration you shouldn't need a rule on the WAN side. If the provider calls your IP without a registration they should provide the exact IPs that will be used and you can use that information to create more secure firewall rules. Otherwise you might be able to catch the bad traffic with SNORT, there are some SIP-related rules available.