Prev: DebianLive
Next: What's the easiest way for a shell script to tell if grub version 1 is installed?
From: Celejar on 2 Jul 2010 13:10
On Fri, 02 Jul 2010 11:27:13 +0200
Merciadri Luca <Luca.Merciadri(a)student.ulg.ac.be> wrote:

> No. That's not at all a proxy. Once you power on the computer, and that
> you want to use Internet, say by Firefox, you are directly redirected to
> a webpage which asks you your university login & your university
> password. Once you have entered this stuff, you are logged on the
> network, and everything is okay. That's a little bit like ADSL where you
> need to type credentials before using the Internet (at the opposite of
> the cable).
>
> :-(

One way to do this is to implement a script that will do the
authentication automatically. Using Perl, you'd whip something
together using something like WWW::Mechanize.

Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100702130216.0eb092b4.celejar(a)gmail.com
From: Merciadri Luca on 2 Jul 2010 13:20
Thanks.

Celejar wrote:
> On Fri, 02 Jul 2010 11:27:13 +0200
> Merciadri Luca <Luca.Merciadri(a)student.ulg.ac.be> wrote:
>
>
>> No. That's not at all a proxy. Once you power on the computer, and that
>> you want to use Internet, say by Firefox, you are directly redirected to
>> a webpage which asks you your university login & your university
>> password. Once you have entered this stuff, you are logged on the
>> network, and everything is okay. That's a little bit like ADSL where you
>> need to type credentials before using the Internet (at the opposite of
>> the cable).
>>
>> :-(
>>
>
> One way to do this is to implement a script that will do the
> authentication automatically. Using Perl, you'd whip something
> together using something like WWW::Mechanize.
>

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.


There is a thin line between love and hate.

From: Rob Owens on 2 Jul 2010 22:10
On Fri, Jul 02, 2010 at 10:39:16AM +0100, Michal wrote:
> On 02/07/2010 10:27, Merciadri Luca wrote:
>> No. That's not at all a proxy. Once you power on the computer, and that
>> you want to use Internet, say by Firefox, you are directly redirected to
>> a webpage which asks you your university login& your university
>> password. Once you have entered this stuff, you are logged on the
>> network, and everything is okay. That's a little bit like ADSL where you
>> need to type credentials before using the Internet (at the opposite of
>> the cable).
>>
>> :-(
>>
>> Thanks.
>
> ...so you can only use a browser then? You can't use other applications?
> This sounds like the sort of system they have a hotels and such
> like...but there are ways to get around these...one way was even put in
> a Linux magazine a few weeks ago. Have a search around
>
I think the solution was to use opendns servers in /etc/resolv.conf.
The reason it works is that, according to the article I read, many of
these captive portal systems work by not giving you a dns server until
you enter your credentials. If you manually specify your own dns
server, you can avoid entering your credentials.

I've never tested it, but I know that the captive portal systems I've seen give you an IP
address before you enter your credentials. In fact, they have to give
you an IP address otherwise you couldn't get to the "credentials"
webpage.

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100703020703.GA15350(a)aurora.owens.net
From: Celejar on 4 Jul 2010 00:40
On Fri, 2 Jul 2010 22:07:03 -0400
Rob Owens <rowens(a)ptd.net> wrote:

....

> I think the solution was to use opendns servers in /etc/resolv.conf.
> The reason it works is that, according to the article I read, many of
> these captive portal systems work by not giving you a dns server until
> you enter your credentials. If you manually specify your own dns
> server, you can avoid entering your credentials.
>
> I've never tested it, but I know that the captive portal systems I've seen give you an IP
> address before you enter your credentials. In fact, they have to give
> you an IP address otherwise you couldn't get to the "credentials"
> webpage.

>From http://en.wikipedia.org/wiki/Captive_portal#Implementation

-----

Implementation

There is more than one way to implement a captive portal.
[edit] Redirection by HTTP

If an unauthenticated client requests a website, DNS is queried by the
browser and the appropriate IP resolved as usual. The browser then
sends an HTTP request to that IP address. This request, however, is
intercepted by a firewall and forwarded to a redirect server. This
redirect server responds with a regular HTTP response which contains
HTTP status code 302 to redirect the client to the Captive Portal. To
the client, this process is totally transparent. The client assumes
that the website actually responded to the initial request and sent the
redirect. [edit] IP Redirect

Client traffic can also be redirected using IP redirect on the layer 3
level. This has the disadvantage that content served to the client does
not match the URL. [edit] Redirection by DNS

When a client requests a website, DNS is queried by the browser. The
firewall will make sure that only the DNS server(s) provided by DHCP
can be used by unauthenticated clients (or, alternatively, it will
forward all DNS requests by unauthenticated clients to that DNS
server). This DNS server will return the IP address of the Captive
Portal page as a result of all DNS lookups.

The DNS poisoning technique used here, when not considering answers
with a TTL of 0, may negatively affect post-authenticated internet use
when the client machine references non-authentic data in its local
resolver cache.

Some naive implementations don't block outgoing DNS requests from
clients, and therefore are very easy to bypass; a user simply needs to
configure their computer to use another, public, DNS server.
Implementing a firewall or ACL that ensures no inside clients can use
an outside DNS server is critical.

-----

Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100704003916.9a4ebd2b.celejar(a)gmail.com
From: Merciadri Luca on 4 Jul 2010 19:00
Celejar wrote:
> On Fri, 2 Jul 2010 22:07:03 -0400
> Rob Owens <rowens(a)ptd.net> wrote:
>
> ...
>
>
>> I think the solution was to use opendns servers in /etc/resolv.conf.
>> The reason it works is that, according to the article I read, many of
>> these captive portal systems work by not giving you a dns server until
>> you enter your credentials. If you manually specify your own dns
>> server, you can avoid entering your credentials.
>>
>> I've never tested it, but I know that the captive portal systems I've seen give you an IP
>> address before you enter your credentials. In fact, they have to give
>> you an IP address otherwise you couldn't get to the "credentials"
>> webpage.
>>
>
> >From http://en.wikipedia.org/wiki/Captive_portal#Implementation
>
> -----
>
> Implementation
>
> There is more than one way to implement a captive portal.
> [edit] Redirection by HTTP
>
> If an unauthenticated client requests a website, DNS is queried by the
> browser and the appropriate IP resolved as usual. The browser then
> sends an HTTP request to that IP address. This request, however, is
> intercepted by a firewall and forwarded to a redirect server. This
> redirect server responds with a regular HTTP response which contains
> HTTP status code 302 to redirect the client to the Captive Portal.
Is the 302 status code standardized? (I'm here dealing with CISCO
routers and network stuff, and do they use 302 too?)
> To the client, this process is totally transparent. The client assumes
> that the website actually responded to the initial request and sent the
> redirect. [edit] IP Redirect
>
> Client traffic can also be redirected using IP redirect on the layer 3
> level. This has the disadvantage that content served to the client does
> not match the URL. [edit] Redirection by DNS
>
/
> When a client requests a website, DNS is queried by the browser. The
> firewall will make sure that only the DNS server(s) provided by DHCP
> can be used by unauthenticated clients (or, alternatively, it will
> forward all DNS requests by unauthenticated clients to that DNS
> server). This DNS server will return the IP address of the Captive
> Portal page as a result of all DNS lookups.
>
> The DNS poisoning technique used here, when not considering answers
> with a TTL of 0, may negatively affect post-authenticated internet use
> when the client machine references non-authentic data in its local
> resolver cache.
>
> Some naive implementations don't block outgoing DNS requests from
> clients, and therefore are very easy to bypass; a user simply needs to
> configure their computer to use another, public, DNS server.
> Implementing a firewall or ACL that ensures no inside clients can use
> an outside DNS server is critical.
>
Thanks for this.

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.


Act today only, tomorrow is too late.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: DebianLive
Next: What's the easiest way for a shell script to tell if grub version 1 is installed?