That is a great workaround. However, I see this as an inherent SIP RFC issue and an improvement similar to this on the RFC will probably stop having to find these sort of workarounds all together.
For example, you can set your SIP server to respond to first SIP packet only if the first request comes with a valid username. Current RFC asks to respond to it with tokens and handshake for further negotiation which is weak. The SIP server should drop the first packet the moment it sees the invalid username in the packet. Dropping it, some argue will lead to remuneration of extension numbers or usernames. However, you can easily mitigate that by having a random long alphanumeric username and your second line of defense will be the password which will be exchanged while encrypted. So, this creates a two level authentication (what is becoming popular these days). This still doesn't answer true DDoS attacks as others mentioned but all these minor things help along the way in cost savings which is the goal. - Bruce On Thu, Jul 30, 2015 at 12:57 PM, Liviu Toma <liviu.t...@gmail.com> wrote: > Hi, > > There's another interesting approach to filtering SIP scanners that I > found on the DSLReports VoIP forum: > http://www.dslreports.com/forum/r29375858-SIP-Scanners > Basically allow known IP addresses in your iptables rules, and for the > rest of the world, allow only clients that use a specific host name to > reach you (obviously, make sure your reverse DNS doesn't reveal that > host name). > For everyone else, your PBX will be completely opaque. > > Liviu > > On Thu, Jul 30, 2015 at 12:28 PM, Bruce N <brucev...@gmail.com> wrote: > > John, > > > > I think Reza's main concern is really true DDoS directed at telephony > > servers for the purposes of gaining access to routes (i.e. call North > Korea > > and the operator will share profits with you). > > > > By blocking IPs as they come in, you are still indicating you are a SIP > > server and you are worried and want to block access so there comes more > > tries from different IP sources which is what DDoS is at core. What Reza > is > > suggesting, let them think they got access and let them dial so they > think > > they are making money while they are not. This will stop DDoS *probably* > > because they will think they got access so their DDoS will be directed > > somewhere else. I think this work because those who run scripts run them > > without secondary checks and there are easier targets to move onto than > to > > come back to Reza's servers and figure out why they failed. They will > > recognize it as a sip server with no international routes maybe...hence > > banning IPs is the opposite of what he suggests to do. > > > > -Bruce > > > > > > On Thu, Jul 30, 2015 at 12:18 PM, John Lange <j...@johnlange.ca> wrote: > > > >> I also found that approach very interesting. It's the opposite of what > you > >> would intuitively do, ie let everyone in, vs. block everyone who's > unknown. > >> > >> As others have mentioned, the one concern I have is the load caused by > >> playback of tt-monkeys (though I'm amused). Wouldn't it work equally > well > >> to simply do an Answer(), then Wait(100) without playback? > >> > >> And doesn't it also make sense to combine the above with a Fail2Ban > keyed > >> on the log of "BUFFOONS IP ADDRESS"? > >> > >> Regards, > >> > >> John > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: asterisk-unsubscr...@uc.org > For additional commands, e-mail: asterisk-h...@uc.org > >
