Log-in web portal for your wifi network

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).

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..com, I tried again at roughly 23:13 UTC. Now, no matter what hostname I asked about, I got back the same " 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.

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

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

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?

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.

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

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

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

- 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.

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

-->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

I'm not going to fully disclose it anyway

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

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.

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.

Like what?

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.

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 ' snipped-for-privacy@ISP2.com'. But the basic worms are just grabbing random IP addresses within a range and trying to connect to them.

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.

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.

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.

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

OK

No banner, no pop-up, nothing. 253 octets received, SYNACK to FIN.

It's 'tcpdump -s 1500 -n -vvv' and it's never been a problem in the ten or more years I've been using it.

A lot depends on the level of paranoia and expertise - I know how easy it is to sniff, hijack, and man-in-the-middle, so I'm going to be a good bit more aware of what's going on. I do use a wireless lapdog on occasion, but rarely for personal (or dumb user) stuff. It's typical that I'll be on the road, get a call from the office, and have to find someplace to connect back to the office. If necessary, I'll use the modem over cellphone - crap though it may be - but it works where ever I'm in coverage. A wifi hotspot is _much_ preferred, but isn't mandatory.

Old guy

hi im trying to setup a captive portal with a paid access on a dsa-3200 hotspot wireless gateway just as simple a i can make it if you have some samples would like them to try them put thanks Ron

------------------------------------- snipped-for-privacy@mixmail.com wrote:

##-----------------------------------------------## Article posted with Cabling-Design.com Newsgroup Archive

read and post WWW interface to your favorite newsgroup - alt.internet.wireless - 13500 messages and counting! ##-----------------------------------------------##