Log-in web portal for your wifi network

This project is a "captive portal". A captive portal forces anyone who
connects to a network for the first time to a specific web page. There
they can find out who is providing this access and typically
acknowledge the rules of access.

All of the captive portal installations I know of (NoCatAuth, m0n0wall,
etc...) require a dedicated computer to run on 24/7 as well as a
computer geek tu install and mantain the animal.

In view of this I decided to develope a captive portal system that does
not requires any software or hardware installation (other than the
router and internet connection, obviously).

I will share the sources with anyone interested in the project, at
present in a beta stage. It is based exclusively on the DNS protocol
and all it requires in order to run is a simple configuration of the
router.

If you want to try it you must configure your router as follows:

- enable DHCP

- set DHCP parameter "DNS" to 82.161.30.183

then reset your wifi card, open your favorite browser and try it, login
with password "test" without the quotes.

There's a form for comments on the portal's entry page. Collaborators
are welcome.

elrapido (at) mixmail (dot) com

In article <(E-Mail Removed). com>,
(E-Mail Removed) wrote:

>This project is a "captive portal". A captive portal forces anyone who
>connects to a network for the first time to a specific web page. There
>they can find out who is providing this access and typically
>acknowledge the rules of access.

OK - nothing new about that. The common name for the technique is
DNS Spoofing, where you redirect any name query to your address.
This does nothing for the case where someone uses the IP address
of the remote site instead of the name. That includes when they have
the hostname in the /etc/hosts file, or the windoze equivalent
(c:\windows\hosts or c:\windows\system32\drivers\hosts or similar).
You would also have to block outbound UDP to port 53, for those of
us who know specific name servers to use (I use the "work" name
server because they know the internal names, not resolvable by the
"normal" name servers).

>All of the captive portal installations I know of (NoCatAuth, m0n0wall,
>etc...) require a dedicated computer to run on 24/7 as well as a
>computer geek tu install and mantain the animal.

Well, there still has to be a a box running the name server. When I
tried it at about 21:50 UTC, using ordinary name server query tools
(host, dig, and nslookup), and watching the signals over the network,
I saw nothing unusual. The packets looked exactly normal.

Thinking later that perhaps you needed the system to look for
www.<mumble>.com, I tried again at roughly 23:13 UTC. Now, no matter
what hostname I asked about, I got back the same "<mumble> is at
82.161.30.183". However, when I asked about IP addresses, I got
normal results (the "real" name of the host for a given IP address).
So, all you are doing there is using a wild card A record in the
DNS server.

>If you want to try it you must configure your router as follows:
>
>- enable DHCP
>
>- set DHCP parameter "DNS" to 82.161.30.183
>
>then reset your wifi card, open your favorite browser and try it, login
>with password "test" without the quotes.

OK, so you are substituting your DNS server for whatever is normal.
Where this is going to be a problem is if I'm not using a web browser.
If I decide to check my mail, or what-ever (even assuming I have the
system configured to accept DNS addreesses), I'm using a tunneling
mechanism, and it doesn't use a browser - nor does it care about
port 80 (or 443, or what-ever). This means I'm not going to see your
web page - and will instead be quite unhappy with the klown who is
running the connection service. Given that the "staff" at the connection
service is unlikely to be technical, the result will be an unhappy
customer.

Ole guy

"Moe Trin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <(E-Mail Removed). com>,
> (E-Mail Removed) wrote:
>
> >This project is a "captive portal". A captive portal forces anyone who
> >connects to a network for the first time to a specific web page. There
> >they can find out who is providing this access and typically
> >acknowledge the rules of access.
>
> OK - nothing new about that. The common name for the technique is

<snip>

It's also the phishing tool of choice for all of the hackers and bot
controllers out there.
Not a good idea for any of my projects, then YMMV I guess.... ;-)

Scotty

>>this is going to be a problem is if I'm not using a web browser.

well you stated the obvious in your posts, tings that are
"state-of-the-art" and everybody knows... however, my implementation is
a little more inventive than simply redirecting everything throug a
tunnel...(duh) which has the obvous problem that you're going to use MY
bandwidth instead of your own.

Actually AFTER logging in with your browser, you are using your own ISP
not mine, my DNS server returns the TRUE IP addresses until your time
is out, and you can access any IP with any protocol on any port.

What can I say other than GIVE IT A TRY. It is for free, then let's
talk about your experience, OK?

>>It's also the phishing tool of choice for all of the hackers and bot
controllers out there. >>

Sorry pal but that DNS is under my exclusive control, it is not open to
be used by any hackers "out there", so it all boils down to a contract
between you and I, and then we're on the same level as any other
service where you regularly delegate your connections without worries,
like any free web mail provider, for example, that could fish whatever
info you send through its service.

It all boils down to trust, and if you have none then refrain from
sending any ensitive information.

In article <DJOne.15934$qJ3.1332@trnddc05>, Scott Nelson - Wash DC wrote:
>
>"Moe Trin" <(E-Mail Removed)> wrote
>> OK - nothing new about that. The common name for the technique is

>It's also the phishing tool of choice for all of the hackers and bot
>controllers out there.

It is a significant concern - you have to trust the service providers
between you and what ever you are connecting to. I'm a networking
type, so I know how easy it is to sniff packets - heck, I do this all
the time at work, and used it while testing this 'captive portal' thing.

Most people aren't really aware of how the internet works. Unless you are
using an encrypted tunnel, everything you read or write across the network
can be sniffed. Will it be sniffed? Maybe, maybe not. But the solution
for that is simple - expect that it will, and don't do things that you
wouldn't want everyone in the world knowing you did. That way, if it
is sniffed, you would be in trouble, and if it isn't, you still won't
be.

Old guy

In article <(E-Mail Removed) .com>,
(E-Mail Removed) wrote:

>well you stated the obvious in your posts, tings that are
>"state-of-the-art" and everybody knows... however, my implementation is
>a little more inventive than simply redirecting everything throug a
>tunnel...(duh) which has the obvous problem that you're going to use MY
>bandwidth instead of your own.

I'm afraid I can't follow your implementation.

>Actually AFTER logging in with your browser, you are using your own ISP
>not mine, my DNS server returns the TRUE IP addresses until your time
>is out, and you can access any IP with any protocol on any port.

Well, sorta - but I'm also using the bandwidth of the hotspot provider, and
using a bit of your bandwidth if I'm using your server for DNS.

OK, here's the deal - at 2215 UTC, I set up /etc/resolv.conf to point
to your 82.161.30.183. I then fired up a packet sniffer, and told it to
snarf the packets, and started a browser, and told it to go to
http://www.pobah.baz - an obviously false address. Your name server
returned 82.161.30.183 as being the address, and the browser tried to
connect. There was a connection, and the browser exited saying it
could not open the page. Your web server was the one that shut down the
connection, not my client. I retried two additional times at 2218 UTC
and 2219 UTC - same results - name resolved, can't open page.

>What can I say other than GIVE IT A TRY. It is for free, then let's
>talk about your experience, OK?

Other than getting a name resolution, NOTHING WORKED! No login page, NADA!

What was I supposed to see?

Repeating, normally, I won't be using a provider's name servers, because
I use "internal" company name servers - the public servers can not resolve
the hosts I'd be connecting to. Secondly, some people have hosts entries
in files, or use IP addresses directly (I'm not unusual, but I know the
IP addresses of about two dozen hosts that I'd normally connect to). In
my specific case, your name server can not provide correct answers, because
the public servers listed as authoritative for the domain will not provide
internal host information to external hosts - and I don't use the published
servers for that reason. I use internal servers, but you can't ask them,
because you don't know anything about them. Can you say "Security"?

What happens if I'm not using a browser. What happens if I'm using one
that only accepts HTTP/1.0 or 1.1 compliant code - that means no Java,
Javashit, or ActiveX. (For what it's worth, I don't allow scripting in
a web page - period.) I used two different text only browsers in my
test (lynx and links).

Another thought - what do you do if the client expects DNS authentication
in the concept of RFC2536, RFC2845, RFC2930, RFC3645. RFC3845, and RFC4033
through 4035?

Old guy

"Moe Trin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <(E-Mail Removed) .com>,
> (E-Mail Removed) wrote:
>
> >well you stated the obvious in your posts, tings that are

<snip>

> Another thought - what do you do if the client expects DNS authentication
> in the concept of RFC2536, RFC2845, RFC2930, RFC3645. RFC3845, and RFC4033
> through 4035?
>
> Old guy

-->I wish I could find more hotspots like this.
All I need to do is setup a VPN tunnel to my place and I get access to my
own DNS servers via the setting that get pushed down to my VPN client.

A good portion of SMTP bots don't need DNS servers either so security of the
AP/Hot Spot would be weak as well.
Only way to block users is to open and close protocols ( tcp/udp/icmp/etc )
& ports until they authenticate.
Peer to Peer software can find ways I never thought of. Hotspots and p-to-p
don't work good for the hot spot operator.

web capture, S/Key auth via telnet or http, 802.1x with or without VLAN
assignment, or an ACL blocking all ports/protocols except for VPN to my VPN
server are the only ways I have found to effectively control user access.
The first two I don't use anymore as roaming is a big issue with these so
the VPN option is the one I use now.
If I only had one AP though, web capture would probably be my choice though.
If the DNS thing works for someone, kewl. I can't think of a situation where
I could suggest it to one of my clients though. Too many holes and ways to
circumvent it.

YMMV and my .02 worth...... ;-)

Scotty

Moe Trin wrote:
>
> I'm afraid I can't follow your implementation.
>

I'm not going to fully disclose it anyway

> Well, sorta - but I'm also using the bandwidth of the hotspot provider, and
> using a bit of your bandwidth if I'm using your server for DNS.
>

I think you're scratching the bottom of the barrell as a devil's
advocate here

> OK, here's the deal - at 2215 UTC, I set up /etc/resolv.conf to point
> to your 82.161.30.183. I then fired up a packet sniffer, and told it to
> snarf the packets, and started a browser, and told it to go to
> http://www.pobah.baz - an obviously false address. Your name server
> returned 82.161.30.183 as being the address, and the browser tried to
> connect. There was a connection, and the browser exited saying it
> could not open the page. Your web server was the one that shut down the
> connection, not my client. I retried two additional times at 2218 UTC
> and 2219 UTC - same results - name resolved, can't open page.
>

You have a funny installation, this is not how the majority of a
Hotspot visitor's laptops work. You probably did something wrong
because the Log in page pops up in every browser with every laptop
running Internet Explorer, Mozilla or Forefox in both WinXP and Linux.
No exception. I suppose your packet sniffer (something the average user
lacks) messed up the works, it probably didn't return the IP to the DNS
Resolver, therefore the browser's complaint.

>
> Another thought - what do you do if the client expects DNS authentication
> in the concept of RFC2536, RFC2845, RFC2930, RFC3645. RFC3845, and RFC4033
> through 4035?

I'll think about those as soon as those RFC's are widely implemented,
that niche of the market is not what I'm targetting.

In article <jEaoe.777$yS2.327@trnddc07>, Scott Nelson - Wash DC wrote:

>-->I wish I could find more hotspots like this.

Like what?

>All I need to do is setup a VPN tunnel to my place and I get access to my
>own DNS servers via the setting that get pushed down to my VPN client.

What's preventing you from doing so? I sit down, turn on the box, and
send a test packet to a TCP port number at a specific IP address. If I
don't get through, I'm not connected. If I do, I run a command line
application that opens a tunnel to the company. If I want to check
google, or ibiblio or some such, I fire up a browser or application
that uses the tunnel (rather than the existing IP network) to connect
to the bastion host at the company. That host forwards my packets to
where-ever they're going - web server, DNS server, what-ever. The
local hotspot can see my packets going from here to some IP
address that doesn't have a PTR record on a port reserved for some
uncommon service (just because a port is "reserved" for service FOO
doesn't mean that all traffic to that port must be for service FOO.
or BAR or BAZ) - and the funny thing is, the packets are all IP, and
that's all you can say about it. BFHD.

>A good portion of SMTP bots don't need DNS servers either so security of the
>AP/Hot Spot would be weak as well.

Most of the bots want to know what the domain is that they are connecting
to - what good is it trying to send mail to the mailserver at ISP.1.com
that is addressed to '(E-Mail Removed)'. But the basic worms are just grabbing
random IP addresses within a range and trying to connect to them.

>Only way to block users is to open and close protocols ( tcp/udp/icmp/etc )
>& ports until they authenticate.

http://www.iana.org/assignments/protocol-numbers

There are 137 different IP protocols. In general, the Internet doesn't
care what is inside an IP packet - it could be TCP, Banyan Vines, MIT
Remote Virtual Disk Protocol, or anything else. All the routers care is
that it has an IP address for a destination, a TTL >1, and needs to be
passed on to $NEXT_HOP.

>web capture, S/Key auth via telnet or http, 802.1x with or without VLAN
>assignment, or an ACL blocking all ports/protocols except for VPN to my VPN
>server are the only ways I have found to effectively control user access.
>The first two I don't use anymore as roaming is a big issue with these so
>the VPN option is the one I use now.

If operating in a 'common carrier' mode - meaning you don't care what's
in the packets, and you'll "carry" them upon payment of fee, then some
kind of local authentication is enough to unlock the router. If you
want to control what's inside the packets - you have a slightly harder
task, but do-able. If you don't know what the packet is, you don't
pass it. Might make customers like me unhappy because ALL of my traffic
"outside" is encrypted, but that's tough. I can (and will) go elsewhere.

>If I only had one AP though, web capture would probably be my choice though.

Well, that's great if all you have is web traffic - but I use the web much
less than 1 percent of the time. The 'web' is not the Internet, and HTTP is
but one of 4385 registered TCP services. Beyond VOIP, I have seen video
conferencing over IP - sure wasn't HDTV, but it worked. Thst was between a
hotspot at KLAX and a user in Johannesburg, ZA.

>If the DNS thing works for someone, kewl. I can't think of a situation where
>I could suggest it to one of my clients though. Too many holes and ways to
>circumvent it.

It would work with users like Joe Sixpack, whose total concept of hostnames
is that they all begin with 'www' and end with '.com' and whose total use
of the Internet is to download pr0n and order blue pills. The more
sophisticated (or paranoid) user is going to run into problems.

Old guy