Discouraging DNS tunnelling
-
How did you setup your client DNS on that segment?
Are they getting their DNS from pfSense, or from a public DNS server? Did you add any IP overrides for DNS servers?
Last I knew, DNS tunneling didn't work if the clients were running their DNS queries through the pfSense DNS forwarder. But that may have just been one type of DNS tunneling (iodine maybe?)
-
Block outgoing DNS so that clients are forced to use pfSense as the DNS forwarder? Iodine uses the DNS protocol but requires direct access to an external Iodine server.
-
Client DNS is provided by the pfsense DNS forwarder, with OpenDNS being the ultimate provider. DNS traffic to IPs other than the pfsense boxes is blocked, so users can't override this.
Perhaps this defeats Iodine, but not other setups. I'm not sure why it would defeat tunnelling, as the technique uses seemingly valid requests, and though I could block certain sites I'd never get them all - that's why I'm looking at traffic shaping as a means of inconveniencing the tunnellers.
At the moment I'm relying on the guys who did the penetration testing - I'm currently without my own broadband so it's tricky for me to set up a test system at home.
-
You can't tell a DNS forwarder to forward requests to a particular remote server. I think the most that can be done is to register a real domain name with timeouts of zero on everything so that requests will keep going back to the authoritative name server (which would be the malicious tunnel server). Then craft packets to that domain. However something along the line is going to cache something and break it unless the tunnelling protocol is extremely resilient.
-
It looks like people do in fact use a malicious authoritative name server:
http://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152I guess the only way is for the local DNS forwarder to only allow basic A record lookups until the client has been authenticated.
In any case a captive portal is only security through obscurity since it's trivial to bypass. You should only allow access through a properly encrypted PPPoE connection to pfSense and use the captive portal landing page just to display connection instructions.
-
This is only a guest network, and not one that's charged for, so overall security isn't a huge concern.
I don't think there's a way to make firewall rules conditional on whether a client is logged into Captive Portal or not.
Anyway, I've just tested using traffic shaper and it seems to work (for slowing tunnellers, not stopping them). Later this week I'll implement the change on a system which typically has 80 or so users connected - I'll soon get feedback from them if there are any issues.
Here's what I've done:
firewall > traffic shaper > limiter > create new > enable > bandwidth: 1Kbit > advanced > delay: 1000ms
firewall > rules > LAN > pass, LAN, TCP/UDP, dest:LAN address, dest ports: DNS > advanced > In/out: limiter/none
firewall > rules > LAN > block, LAN, TCP/UDP, dest:any, dest ports: DNS
-
You'll severely handicap modern websites that heavily rely on AJAX.
-
Instead of a captive portal, why don't you use 802.1x authentication for your WiFi. Everyone gets their own LDAP based user name and password and uses that to connect to WiFi.
-
I already have 802.1x on other networks for staff. This network is specifically for guests and uses Captive Portal.
I'll see what feedback I get from users, and adjust the limiter parameters accordingly, if they prove to be too restrictive.
-
Any sort of delay destroys UI performance in modern websites. The whole resason they use CDNs for AJAX scripts and Javascript libraries is so that requests resolve as fast as possible and dynamic content loads quickly.
It's best if you only limit the bandwidth to 1 or 2 KiB/s for DNS, but not the latency.
-
Noted, thanks. I've been away for a while so haven't implemented this - I'll report back when I've had it in place for a week or so.
-
A quick update…
I've had this enabled for a few weeks now, with a couple of hundred users a day, over a dozen sites - no complaints received so far.
Final parameters used were 1Kbit/s source address, 50ms delay.
I'll stress again though - this will not prevent DNS tunnelling, it will only slow it, hopefully to the point where abusers will move on and find another target.
