PF DNS query attack: PF unable to block IP addresses from table

Well, I'm giving up on this thread. This is a pure waste of time since the OP obviously doesn't seem interested into actually solving their problem but would rather see that the thread continues on with endless speculations.

At this stage I'm even wondering if there actually was a problem to begin with.
 
micski said:
I would assume, that UDP is stateless, which makes it harder to kill, if it was kept running in some internal allow cache.
Click to expand...
You would assume that but you would be wrong. Because that's what I always thought until enlightened by someone here wiser than myself, kpa.

forums.freebsd.org

PF - Poking a VPN-Sized Hole Through 'pf'

I'm running a server that is using 'pf' as it's firewall. This server also runs a VPN (as a vpn server that client machines on the internet can connect to). I'm trying to open up all the ports I need so I can connect, but it's just not working. The VPN is L2TP over IPSec. Here's what I have...
forums.freebsd.org forums.freebsd.org

My Crystal Ball view of your ruleset is misty and I cannot be sure why your firewall is not blocking UDP port 53 and I'm blocking UDP with mine:

Code: 
### Macro name for external interface
ext_if = "em0"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"

### Block specific ports
block in quick log on $ext_if proto udp from any to any port $netbios_udp

### Keep and modulate state of outbound tcp, udp and icmp traffic
pass out on $ext_if proto { tcp, udp, icmp } from any to any modulate state

From my pfct -s all output:
Code: 
block drop in log quick on em0 proto udp from any to any port = ntp
block drop in log quick on em0 proto udp from any to any port = biff
block drop in log quick on em0 proto udp from any to any port = who
block drop in log quick on em0 proto udp from any to any port = syslog
block drop in log quick on em0 proto udp from any to any port = printer
block drop in log quick on em0 proto udp from any to any port = mdns
block drop in log quick on em0 proto udp from any to any port = x11
block drop in log quick on em0 proto udp from any to any port = x11-ssh
pass out on em0 proto tcp all flags S/SA modulate state
pass out on em0 proto udp all keep state
pass out on em0 proto icmp all keep state
 
Last edited by a moderator:
25: Thanks. Unfortunately, the ISC did not explain, why BIND breaks down and turns into a DNS attack victim, when configured for public-facing authoritative and recursive operation. They only mention, that a problem with one can affect the other.
 
ShelLuser said:
Well, I'm giving up on this thread. This is a pure waste of time since the OP obviously doesn't seem interested into actually solving their problem but would rather see that the thread continues on with endless speculations.

At this stage I'm even wondering if there actually was a problem to begin with.
Click to expand...
I am sorry, if this thread confused you. I have extracted the essense in the paragraph below, so you do not waste more time. I also lost a lot of time, because of this problem, so I had a high interest in learning about it and solving it.

The original problem was, that PF did not block, when a table was updated with a new blacklisted IP address and PF was reloaded. It turned out, as a kind member pointed out, that PF has to flush states before blocking works. Unfortunately, as I understand, then PF does not flush the state, related to the new IP address, if its UDP, because PF only supports limit options for TCP.
 
micski said:
I am sorry, if this thread confused you. I have extracted the essense in the paragraph below, so you do not waste more time. I also lost a lot of time, because of this problem, so I had a high interest in learning about it and solving it.
Click to expand...
I am sorry if our requests confused you. In response to your posts we asked to see your pf ruleset so we could determine if there was a problem in the syntax.

Not you look at it and tell us what you assume to be a fault with pf.

I don't think you know a ruleset from a grocery list or pf from a pdf.

You didn't know about UDP being stateless when it came to Stateful Packet Inspection firewalls and you didn't look at my ruleset closely enough to see it was keeping state with UDP and had a rule to do so. You "ass/u/me" to know what you're talking about, which made an "ass" out of "u" but not "me".

Unless your next post is compliant with our requests (see above) your thread is dead as far as I'm concerned.
 
Hello,

We are aware of the attacks and have been trying to address them with our domain registrator (Godaddy) and hosting provider (Webglobe Yegon) since late 2020 but both have come to the conclusion that we are not the perpetrator but rather a victim here and have no way of influencing these.

These attacks are not actually coming from our servers but other IPs. The domain name is being abused in this way and neither us, nor our hosting or registrator can stop these.

Please see this write up on the issue that may contain a solution: https://www.teaparty.net/technotes/dns-fail2ban.html

Regards.
 
bastadigital said:
We are aware of the attacks and have been trying to address them with our domain registrator (Godaddy) and hosting provider (Webglobe Yegon) since late 2020 but both have come to the conclusion that we are not the perpetrator but rather a victim here and have no way of influencing these.
Click to expand...
Looks to me you became a victim of a DNS amplification attack that just happened to use your registered domains. That's unfortunate but nothing much can be done about it on your end.

bastadigital said:
These attacks are not actually coming from our servers but other IPs. The domain name is being abused in this way and neither us, nor our hosting or registrator can stop these.
Click to expand...
I don't think anyone here is claiming otherwise.
 
micski said:
The flush rule option seems to only apply to rate limiting rules and the kill option has no effect. It confirms, that it killed 0 states and 0 sources. I would assume, that UDP is stateless, which makes it harder to kill, if it was kept running in some internal allow cache.
Click to expand...
you can do pfctl -F all , but I think that it cuts the existings conecction
 
micski said:
A BIND DNS on FreeBSD is under attack from hundreds of hosts, that is sending DNS queries non-stop. Every query is about an unknown domain pizzaseo.com. The DNS has access control lists, that limit recursive queries and cache to known users only, but obviously this attack are able to break through that. Even with recursive funtion set to none (disabled), the attack continues. Millions of queries has been filling the log. Here is an example from the query log.

Code: 
29-Apr-2021 03:02:43.865 queries: info: client @0x804552d60 45.170.252.5#80 (pizzaseo.com): query: pizzaseo.com IN RRSIG + (1.2.3.4)
29-Apr-2021 03:02:43.871 queries: info: client @0x804552d60 45.170.252.5#80 (pizzaseo.com): query: pizzaseo.com IN RRSIG + (1.2.3.4)
29-Apr-2021 03:02:43.883 queries: info: client @0x804552d60 45.170.252.5#80 (pizzaseo.com): query: pizzaseo.com IN RRSIG + (1.2.3.4)
29-Apr-2021 03:02:43.910 queries: info: client @0x804552d60 95.156.213.134#27017 (pizzaseo.com): query: pizzaseo.com IN RRSIG + (1.2.3.4)
29-Apr-2021 03:02:43.977 queries: info: client @0x804552d60 45.170.252.5#80 (pizzaseo.com): query: pizzaseo.com IN RRSIG + (1.2.3.4)

The response rate limit (RRL) option in BIND DNS does not work either on this attack. It just bursts right through. As surprising as that is, I would assume, that PF is better at taking care of this.

I made a script, that catches the IP addresses, that makes these queries, and creates a sorted unique list for PF to read into a table. The script works, the list is created and the table is loaded. Here is an output from PF and the table.

Code: 
# pfctl -t ban -T show
   212.32.207.227
   212.174.190.160
   213.127.79.252
   213.152.121.229
   213.163.87.151

I use a PF rule, that should block traffic from the IP addresses in this table. This rule is documented in the OpenBSD handbook and I use the same rule in other blacklists and those work. See the rule below.

Code: 
block in quick on $wan from <ban> to any

When monitoring the counters, I see, that the rule does get evaluated and does get packets. See check below.

Code: 
pfctl -v -s rules
block drop in quick on vtnet0 from <ban> to any
  [ Evaluations: 6384      Packets: 6067      Bytes: 351886      States: 0     ]
  [ Inserted: uid 0 pid 67018 State Creations: 0     ]

But, as you see from the BIND DNS query log, the DNS query just bursts right through and continues to race through. IP addresses, that are listed in the query log, are also listed in the loaded PF table.

How is this possible?
Click to expand...

maybe the PF users with more experience can tell the diference,but recenty I was under attack on my web sites (I had to have one ssh port open,I dont want it but my boss yes)

in my pf.conf I had

Code: 
block drop in  quick on $ext_if inet from <block-ip> to any
block drop out quick on $ext_if from <bloq-ip> to any

I check with tcpdump with an without rules and the trafffic wont come in with that rules
 
bastadigital said:
The domain name is being abused in this way and neither us, nor our hosting or registrator can stop these.
Click to expand...
I believe the service of Cloudfront is what you need. DDOS something they guard against.

They are like proxy between you and those who would attack you, you see the #IP they assigned to a customer.
 
This is an interesting topic, and looking to the firewall for a solution is a great idea and shouldnt be dismissed, sadly I havnt seen any indication that this can be done purely within any of the included firewalls on freebsd, or any for that matter to say something else is better, but rather a 3rd party integration seems most fitting (eg layer7 rule awareness and blocks or connection limits in and out, fail2ban based on logs or other script, snort (which seems to be picking up a bunch of the abusive IP addresses i saw before turning it on.. or at least the victims so block the outbound traffic), and of course using rate limiting feature in BIND with low rates

Snort detected "ET DOS DNS Amplification Attack Inbound -- 2021-09-15 09:34"
 
You must log in or register to reply here.
Back
Top