Breaking the internet (hotels, guestnet style)

Tue Dec 8 01:24:04 UTC 2009

Disclaimer: /I work for a company that provides these services./

IMHO there is no need for any sort of DNS redirection after user 
authentication has taken place.

We of course redirect UDP/TCP 53 to one of our servers along with 80 
(http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any 
authentication has occurred, but once this is completed the only reason 
any guest would use the local DNS server is if they were assigned a DHCP 
address.

As far as our Routerboard/Mikrotik setup works, it'll masquerade for any 
non standard IP addresses that appear on the network (guests with static 
ip's assigned, corporate laptops etc) but once again after the 
authentication stage anything is allowed to pass unhindered.

The only redirection that is used after authentication is for port 25 as 
90% of user trying to send mail out via port 25 have no idea how to 
change their mail server, let alone why they might need to.
It can be an issue as some systems use authentication on port 25.

I would be interested to hear what people have to say about this, as the 
only other option I could think of would involve checking the incoming 
connection to see if the end user was trying to authenticate to a mail 
server before determining where to forward the connection onto (Layer 7 
stuff, gets a bit tricky)

Regards,
Andrew Cox
AccessPlus Head Network Administrator

Jared Mauch wrote:
> On Dec 7, 2009, at 5:29 PM, John Levine wrote:
>
>   
>>> Will be interesting to see if ISPs respond to a large scale thing like
>>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25
>>> (albeit for other reasons). Therein lies the problem with some of the
>>> "net neturality" arguments .. there's a big difference between "doing it
>>> because it causes a problem for others", and "doing it because it robs
>>> me of revenue opportunities".
>>>       
>> I do hear of ISPs blocking requests to random offsite DNS servers.
>> For most consumer PCs, that's more likely to be a zombie doing DNS
>> hijacking than anything legitimate.  If they happen also to block
>> 8.8.8.8 that's just an incidental side benefit.
>>     
>
> I've found more and more hotel/edge networks blocking/capturing this traffic.
>
> The biggest problem is they tend to break things horribly and fail things like the
> oarc entropy test.
>
> They will often also return REFUSED (randomly) to valid well formed DNS queries.
>
> While I support the capturing of malware compromised machines until they are
> repaired, I do think more intelligence needs to be applied when directing these systems.
>
> Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80,
> TCP/443.
>
> The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks
> IMAP over SSL.  Attempts to get them to correct this have fallen on deaf ears.  I can't even
> VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios.
>
> Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip).
>
> - Jared
>   