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 <gdt at lexort.com >> <mailto:gdt at 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 <AUTOBLOCK> to any > block drop out log quick on bge0 from any to <AUTOBLOCK> > > 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 <ip_address>' to kill any states that may exists after you update your <AUTOBLOCK> 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 <FRIENDS>, also appear in the <AUTOBLOCK> table. Removing the 'quick' parameter from the rule for <FRIENDS> 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 <FRIENDS> table and also exists in the <AUTOBLOCK> table, will be blocked. Larry.
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 <ip_address>' to kill > any states that may exists after you update your <AUTOBLOCK> 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 <FRIENDS>, also appear in the <AUTOBLOCK> 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 <FRIENDS> 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 <FRIENDS> table and also exists > in the <AUTOBLOCK> 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:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com
> 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:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com