Re: [asterisk-users] Can't block intrusion
> I haven't seen the issue today. One thing that I did was to move the > anti spoof line further up. I thought that anti-spoof would block > wherever it was. Could the location be important? Didn't matter. It happened again. I did do something though. I added a bunch of netblocks to my ENEMIES table. In case anyone wants to use them here they are: 45.143.220.0/24 # 1,547,018 attempts 77.247.109.0/24 # 629,717 attempts 185.53.88.0/24 # 302,581 attempts 88.80.148.0/24 # 89,271 attempts 185.36.81.0/24 # 78,886 attempts 37.49.230.0/24 # 69,700 attempts 116.202.203.0/24 # 39,838 attempts 185.4.224.0/24 # 30,I845 attempts 103.145.12.0/24 # 26,746 attempts 103.145.13.0/24 # 19,203 attempts Note that the comments are stripped from the actual file used by pf. The attempts are over a period of just under two weeks. As you can see, the worst offender was the block that included the IP that I showed in my OP. -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:da...@vybenetworks.com VoIP: sip:da...@vybenetworks.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PJSIP Lockup
Paddy, It's pretty easy to spot from the CLI. A voicemail gets called. And the screen basically stops scrolling from there. Eventually you'll get the "Task processors exceeded 500 queued tasks" or something like that. And maybe channels attempting to hangup due to lack of RTP (If you have no-rtp timers configured). Once you find the problem mailbox, You can call it via any method and it'll deadlock every time as soon as it tries to play the mailboxes unavail greeting. I've never had it occur when there is no unavail greeting. Each case deleting the problem recording from the database fixes the issue, And subsequent recordings for the same mailbox have no issue. *Nick Olsen* Network Engineer Office: 321-408-5000 x103 Mobile: 321-794-0763 On Wed, Apr 1, 2020 at 9:04 PM Paddy Grice wrote: > Hi All > > This sounds just like a problem I have had and still investigating having > moved to 16.9 using chan_sip. I am still trying to repeat the problem it > looks from debug that the issue is either voicemail of call transfer but I > cant consistently repeat it. > > Voicemail is using ODBC and I just imported the data from the old system > into the new database. > > Nick - if you have any more info I would be grateful > > TIA > > Paddy > > -- > *From:* asterisk-users [mailto:asterisk-users-boun...@lists.digium.com] *On > Behalf Of *Nick Olsen > *Sent:* 01 April 2020 18:54 > *To:* Asterisk Users Mailing List - Non-Commercial Discussion > *Subject:* Re: [asterisk-users] PJSIP Lockup > > We ultimately found this to be a voicemail issue. The voicemail is held in > MYSQL as well (via ODBC). And we found when attempting to playback a > customers voicemail unavail greeting is when the deadlock would occur > (Immediately, every time. Throwing the same "task processors" errors, And > making pjsip completely unresponsive). We had imported a number of > greetings from a legacy asterisk system and the vast majority of them > worked. When we deleted the row containing the customers unavail greeting > (making asterisk revert to read the mailbox number) all issues went away. > If we re-record the customers unavail greeting it works fine and the > problem doesn't reoccur. This was one out of ~250 voicemails imported. > > Since then we've done a few more migrations and they've all gone smooth > with the exception of the most recent one. ~50% of the imported greetings > have caused asterisk to deadlock. We've been checking them now at time of > migration. > > What I can't figure out is what it doesn't like about the greeting. It was > on a previous asterisk system working fine. The row looks identical to a > working one. The only thing I can guess is something about the blob for the > recording goes wrong. It would be nice if asterisk handled that more > gracefully. > > I post this mostly just for internet history. To hopefully help the next > guy out who has this same issue. > > *Nick Olsen* > Network Engineer > Office: 321-408-5000 x103 > Mobile: 321-794-0763 > > > > On Mon, Mar 2, 2020 at 8:29 PM Joshua C. Colp wrote: > >> On Mon, Mar 2, 2020 at 4:24 PM Nick Olsen < >> n...@floridavirtualsolutions.com> wrote: >> >>> Thanks for the info, Joshua. >>> >>> Does PJSIP handle database access the same way Chan_sip did? We had a >>> number of boxes running chan_sip referencing the same mysql server without >>> issue. >>> >>> We're going to attempt to get a backtrace on the next occurance. We're >>> also going to run a local copy of the database on the same physical >>> asterisk instance and have the system reference it. Just to "throw >>> everything at the wall". >>> >> >> It uses the same underlying API and layer. It can do more frequent >> database access though due to queries and because PJSIP is multithreaded. >> >> -- >> Joshua C. Colp >> Asterisk Technical Lead >> Sangoma Technologies >> Check us out at www.sangoma.com and www.asterisk.org >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> Check out the new Asterisk community forum at: >> https://community.asterisk.org/ >> >> New to Asterisk? Start here: >> https://wiki.asterisk.org/wiki/display/AST/Getting+Started >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >>http://lists.digium.com/mailman/listinfo/asterisk-users > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by
Re: [asterisk-users] Can't block intrusion
On 2020-04-02 08:01, Larry Moore wrote: > I suspect you have a good understanding of pf. Pretty good I think. As with everything I am always willing to learn more. > Have you included in your script running 'pfctl -k ' to kill > any states that may exists after you update your table? I haven't yet because I want to watch the effect of doing it. When I see the problem happening I run that manually and watch to see if it stops the attack in its tracks or if I still have to null-route it. Once I know that it is working I will add it to the script. > In pf, like IP Filter, the last matching rule wins. Subject to the "quick" keyword of course. > What can't be determined from the information provided is whether any > connections that have been established from networks you have listed in > the table , also appear in the table. Absolutely positive. FRIENDS is a static table with exactly eight entries. It is mainly for protection against our office and a few special hosts such as our VoIP provider being locked out. I can guarantee that the IP that I showed in the OP was not a friend. > Removing the 'quick' parameter from the rule for will allow > packets to fall through to the next rules. Alternatively, moving the > 'pass' rule to below your 'block' rules will allow any connections > originating from networks listed in your table and also exists > in the table, will be blocked. It's a safety thing. Even if someone in the office makes a mistake I don't want them blocked. Same for other friends. I haven't seen the issue today. One thing that I did was to move the anti spoof line further up. I thought that anti-spoof would block wherever it was. Could the location be important? -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:da...@vybenetworks.com VoIP: sip:da...@vybenetworks.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Can't block intrusion
On 2/04/2020 6:35 AM, D'Arcy Cain wrote: On 2020-04-01 16:28, Mark Boyce wrote: On 1 Apr 2020, at 22:14, Greg Troxel mailto:g...@lexort.com>> wrote: I think you need to use tcpdump and turn up firewall debugging. sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) block drop in log quick on bge0 from to any block drop out log quick on bge0 from any to Am I misunderstanding pf? I thought that that would block TCP, UDP, ICMP and anything else trying to get through. Since I started looking at this closer I did find that only some connections have this problem. Most get blocked as soon as the IP is passed to the AUTOBLOCK table. I suspect you have a good understanding of pf. Have you included in your script running 'pfctl -k ' to kill any states that may exists after you update your table? In pf, like IP Filter, the last matching rule wins. What can't be determined from the information provided is whether any connections that have been established from networks you have listed in the table , also appear in the table. Removing the 'quick' parameter from the rule for will allow packets to fall through to the next rules. Alternatively, moving the 'pass' rule to below your 'block' rules will allow any connections originating from networks listed in your table and also exists in the table, will be blocked. Larry. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
