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

ShelLuser

Son of Beastie

Reaction score: 2,091
Messages: 3,782

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.
 

Trihexagonal

Son of Beastie

Reaction score: 2,296
Messages: 2,866

I would assume, that UDP is stateless, which makes it harder to kill, if it was kept running in some internal allow cache.
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.


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:
OP
micski

micski

Active Member

Reaction score: 3
Messages: 130

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.
 
OP
micski

micski

Active Member

Reaction score: 3
Messages: 130

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.
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.
 

Trihexagonal

Son of Beastie

Reaction score: 2,296
Messages: 2,866

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.
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.
 

bastadigital

New Member

Reaction score: 1
Messages: 1

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 11,970
Messages: 38,420

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.
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.

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.
I don't think anyone here is claiming otherwise.
 

wolffnx

Aspiring Daemon

Reaction score: 230
Messages: 675

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.
you can do pfctl -F all , but I think that it cuts the existings conecction
 

wolffnx

Aspiring Daemon

Reaction score: 230
Messages: 675

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?

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
 

Trihexagonal

Son of Beastie

Reaction score: 2,296
Messages: 2,866

The domain name is being abused in this way and neither us, nor our hosting or registrator can stop these.
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.
 

jollis

New Member


Messages: 1

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"
 
Top