It seemed it had to do all sites because they were never trying to do a lookup for those test sites - the ones the OS was looking up had to be returned as the captive portal. I agree - once they paid, they really need to reboot their router. I did the same thing - set TTL to 1, but until the router was reboot, it was holding onto it. I decided it was worth it. YMMV.
Jesse DuPont, Owner Celerity Networks LLC Celerity Broadband LLC > On Sep 10, 2019, at 5:52 PM, Adam Moffett <[email protected]> wrote: > > I toyed with mangling DNS, but the issue was after they paid they still have > cached results pointing to the wrong IP. Even when my fake results had a TTL > of 1 minute the client seemed to keep them longer than that. > > Is it sufficient to make DNS entries for the captive portal test sites or do > you really have capture *all* DNS queries? > > > >> On 9/10/2019 7:04 PM, Jesse DuPont wrote: >> Redirecting HTTPS, as you know, doesn't work because of the certificate. >> Even using your own certificate won't work because you can't get a trusted >> certificate issues that is valid for all domain names. >> The only think you can do is redirect them BEFORE they try to do HTTPS by >> triggering the captive portal detection methods in modern OS's - like >> they're in a hotel. >> >> https://success.tanaza.com/s/article/How-Automatic-Detection-of-Captive-Portal-works >> >> As you can see in that doc, all devices try to reach a known URL and expect >> to see a well-known result. If the result is different than what it expects, >> it assume it's behind a capture portal. We exploit this (in a >> non-black-hat-hacker kind-of-way). >> >> Our billing system is tied to our RADIUS server so when a suspended account >> authenticates, RADIUS sends an additional attribute (instead of denying it) >> - basically an address-list entry. We use this additional attribute on >> routers to treat traffic from these people differently. Primarily: >> 1) We DST-NAT all their DNS queries to a fake-master server which issues our >> "you haven't paid" landing page IP for ANY DNS query they do except for our >> website and billing portal, which are right (this is the first part of >> triggering captive portal detection - the IP returned to the OS isn't right). >> 2) We DST-NAT all their HTTP traffic to the proxy configured on the router, >> which triggers the second part of triggering captive portal detection - the >> HTTP server doesn't return the expected response. Also, using the proxy, we >> allow them to be able to reach our walled-garden content (our web page, our >> billing system portal) using the actual URLs, not just the IP. All other >> requests are redirected to our landing page. >> 3) In the firewall, even though we've essentially blocked it in the proxy, >> we only allow traffic from suspended customers to reach our landing page, >> our payment portal and our web site (the walled-garden). >> 4) Once they pay, they reboot their router and it's resolved. >> >> I can share specifics if you want. >> >> Jesse DuPont >> >> Network Architect >> email: [email protected] >> Celerity Networks LLC >> >> Celerity Broadband LLC >> Like us! facebook.com/celeritynetworksllc >> >> <celeritynetworks-GIF.gif> >> Like us! facebook.com/celeritybroadband >> >> >>> On 9/10/19 4:05 PM, Adam Moffett wrote: >>> I already know the answer I think, but if you're redirection non-pay >>> customers to a web page what do you do with (the majority) who have an >>> HTTPS home page? >>> >>> do you >>> A) present your own certificate and expect them to click through the >>> warnings? >>> B) Don't bother and just drop https? >>> C) do something else? >>> >>> I told the boss if there was a way to do this then we should quit the ISP >>> game and make a killing with phishing scams, but he seems to think there's >>> a way to handle it. >>> >>> Thanks, >>> Adam >>> >>> >> >
-- AF mailing list [email protected] http://af.afmug.com/mailman/listinfo/af_af.afmug.com
