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

ShelLuser

Son of Beastie

Reaction score: 2,060
Messages: 3,773

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

Daemon

Reaction score: 1,703
Messages: 2,277

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

Daemon

Reaction score: 1,703
Messages: 2,277

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