Ok,
This is not bad at all, but only works with WiFi.....I'm on ethernet in
the lab and I was sitting here beating my head like an idiot wondering
why it didn't work. Just something to keep in mind. This is probably
what I'll end up doing though. I appreciate the tip.
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
