I have mediacom cable at home. Don't know what the delinquency page looks like but they inject a usage banner somehow. And once when I got dmca flagged there was an injected banner and failed ip redirect. As I understood it when I asked around before, functional banner injection is an expensive back end. Banners are probably the wave of the future, captive portal seems hit or miss
On Tue, Sep 10, 2019, 6:53 PM Adam Moffett <dmmoff...@gmail.com> 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: jesse.dup...@celeritycorp.net > Celerity Networks LLC > > Celerity Broadband LLC > Like us! facebook.com/celeritynetworksllc > > 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 > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com >
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
