Bug #3683
closed
pfSense Not Blocking Pre-Auth Captive Portal DNS Requests
0%
Description
pfSense appears to be susceptible to DNS Tunneling attacks. I've got a neighbor who's dishTV keeps associating with my guest wifi on which I have pfSense handling with a Captive Portal. The neighbor get's an IP, then starts putting through DNS packets that get forwarded to dishaccess.tv. Because Dish has NS records, the packets travel all the way to their authoritative servers and back again. pfSense should be blocking these packets pre-auth.
Things I've tried....
Setting/Unsetting - System --> General --> DNS servers Entries
Setting/Unsetting - System --> General --> Do not use the DNS Forwarder as a DNS server for the Firewall
Setting/Unsetting - Services --> DNS Forwarder, various combos
Setting/Unsetting - Servces --> DHCP Server, various combos for DNS entries
This problem may not only be a Captive Portal issue as I think there may be root DNS packet mishandling issue. Even with an ipv4 tcp/udp block all rule on the guest wifi interface, packets still get through.
I've attached a FULL packet capture to show traffic that gets established. I even had the block all rule in place when it was captured.
Files
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Rejected
It's not getting out to the Internet, the DNS forwarder can though and supplies responses. It's possible to block via properly-configured firewall rules (and deleting the states of the already-active connections if needed). The capture actually shows towards the end that you're blocking DNS (or at least not getting replies).
You have to have DNS resolution pre-auth as otherwise no one would be able to hit the portal unless they browsed somewhere outside the network by IP.
A reasonable feature request might be greater control over what you send via DNS replies to unauthenticated clients, maybe hijack all requests and send the CP interface's IP in reply where users aren't authenticated. This bug report has no validity though.
Updated by Kyle Fergusson almost 10 years ago
Even with the first rule on the interface as "IPv4 TCP/UDP * * * * * none (Block Al)" the client is still getting "established" connections if I view the state table after a couple minutes. They have not authenticated either. I can provide more information if needed. Screenshots, etc.
I believe the DNS Fordwarder should be CP aware so that remote requests are shut down until authentication. But right now, it's broken and a security vulnerability.
Updated by Chris Buechler almost 10 years ago
where you actually have a block all rule, or no pass rules, connections cannot be established.
The pre-auth connection shown is to the portal itself. All the direct connection attempts to the Internet failed as they should. The IP with captive portal is misleading because the connection gets hijacked upon redirection. It's "established" to serve the portal page. Though even that will fail where there are no rules to permit the connection to begin with.