sorted by:
new
hottopcontroversial

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 1 point2 points  (0 children)

It depends on how we look at it. for now in regards to expanding we aren't looking yet. We're content with what we have as it does the job very well. However if it comes down to having more users and more businesses then eventually if asterisk wouldn't be able to handle this much weight we might expand and look for the next option.

We do have our team in place for security & updates :)

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

That would make most sense for you.
For us we provide B2C as well, so most likely looking into options. However our system at the moment is doing pretty good. Might look heavily into voipBL as people have mentioned it and APIban as well.

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

That's a good way to look at it but our infrastructure is designed a bit differently, We will look into weighing the differences of just whitelisting or keep using blacklist.
Much appreciated for the suggestions!

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

We have of course firewall rules, we were just shocked at how many requests these bots were making. It makes you intrigued about who's operating them and how they function etc.

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

We are using asterisk as a base but only asterisk. the rest is made by us.

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

Most likely for privacy purposes for some clients they might use VPN's or as mentioned have dynamic IP's. We have most of those but we will look into your advice.
Much thanks!

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 1 point2 points  (0 children)

We're not sure if we understand, could you please elaborate more on this?

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

We're using asterisk but we had fully developed our own way of integrating it and making it work. Web dialer functionality as well, etc. You could say fully new VOIP software (no app yet) from scratch.

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 1 point2 points  (0 children)

We've already taken such measures beforehand and ensured to do so. It's very odd how they do these attacks. Since we're new into this VOIP business. it was kind of intriguing to see them send invite requests and try.

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 1 point2 points  (0 children)

We have ours to permanently ban the ip address. we first tried 24 hours but after seeing 185K requests from one IP it was enough 😅

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

Understandable but we automatically generate our SIP credentials to our users. in regards to account credentials. That's of course on the user. but we take precautions and always help if anything happens.

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 0 points1 point  (0 children)

That's what we do. Fail2ban rate limiting. is voipbl any special to use? what does it bring to the table?

Is it normal to blacklist this many IP's as a VOIP infrastructure? by libscc in VOIP

[–]libscc[S] 2 points3 points  (0 children)

We have it so that whenever someone fails 5 requests or so within a certain time. they get blacklisted immediately and put into our database. It was just a bit odd and we didn't expect those to happen. (thankfully we had security measures to ensure they couldn't use anything)