* Dynamic change of iptables (building Wi-Fi hotspot)
@ 2004-07-04 16:33 Vladimir Mosgalin
2004-07-04 17:03 ` Antony Stone
2004-07-04 21:26 ` Eric Leblond
0 siblings, 2 replies; 4+ messages in thread
From: Vladimir Mosgalin @ 2004-07-04 16:33 UTC (permalink / raw)
To: netfilter
Hello everybody.
I want to build a Wi-Fi hotspot. The linux box with wireless AP
connected to it which provides internet access to people with Wi-Fi
cards.
When people pay for time or traffic some unique username and password is
given to each. When they try to access any http website, for the first
time each of them gets a login message. After entering name & password,
they continue to work normally.
I see two ways of doing it.
1) Iptables get changed by some script each time when someone registers
or his time runs out. There is a rule
iptables -A FORWARD -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:80
Thus, everyone gets forwarded to localhost.
On localhost, apache has 404 error handler which redirects each to login
page. When they sucessfully enter username and password, script adds
line like this
iptables -I FORWARD 1 -s $ip -j ACCEPT
and now client can do whatever he wants.
When unregistering, another script removes this line.
I see two problems in this approach - I'm not sure whether changing
iptables constantly is good, and I feel a bit anxious about the fact
that several different scripts are running and doing something.
2) All traffic is redirected to tun interface, and some C program
analyzies each packed and decides whether to pass them or block them
and serve as a simple http server, offering login page. The problem is
that I need to write this program in this case, and it can be
complicated a bit, and I'm not very confident because all traffic
will have to pass through this program and it must be written really
good if I don't want to have problems.
Maybe there are other solutions (like very clever netfilter module which
can be controlled from userspace)? Or there is nothing bad in changing
iptables often?
--
Vladimir
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic change of iptables (building Wi-Fi hotspot)
2004-07-04 16:33 Dynamic change of iptables (building Wi-Fi hotspot) Vladimir Mosgalin
@ 2004-07-04 17:03 ` Antony Stone
2004-07-04 18:10 ` Vladimir Mosgalin
2004-07-04 21:26 ` Eric Leblond
1 sibling, 1 reply; 4+ messages in thread
From: Antony Stone @ 2004-07-04 17:03 UTC (permalink / raw)
To: netfilter
On Sunday 04 July 2004 5:33 pm, Vladimir Mosgalin wrote:
> I want to build a Wi-Fi hotspot. The linux box with wireless AP
> connected to it which provides internet access to people with Wi-Fi
> cards.
>
> When people pay for time or traffic some unique username and password is
> given to each. When they try to access any http website, for the first
> time each of them gets a login message. After entering name & password,
> they continue to work normally.
>
> I see two ways of doing it.
> 1) Iptables get changed by some script each time when someone registers
> or his time runs out. There is a rule
> iptables -A FORWARD -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:80
DNAT rules belong in the PREROUTING chain, nat table, not the FORWARD chain,
filter table :)
Also, instead of -j DNAT --to 127.0.0.1, I think you should use -j REDIRECT.
> Thus, everyone gets forwarded to localhost.
> On localhost, apache has 404 error handler which redirects each to login
> page. When they sucessfully enter username and password, script adds
> line like this
> iptables -I FORWARD 1 -s $ip -j ACCEPT
> and now client can do whatever he wants.
>
> When unregistering, another script removes this line.
>
> I see two problems in this approach - I'm not sure whether changing
> iptables constantly is good, and I feel a bit anxious about the fact
> that several different scripts are running and doing something.
>
> Maybe there are other solutions (like very clever netfilter module which
> can be controlled from userspace)? Or there is nothing bad in changing
> iptables often?
I see no reason not to change netfilter rules as often as you like. After
all, adding one rule when a user registers, and removing one rule when they
unregister or time out, is unlikely to be a large quantity of changes.
As for whether the several scripts are a problem - that depends on how good
the scripts are :) I don't see that they need to be at all complicated -
the interesting part is going to be looking up the username / password (PHP /
MySQL would seem an obvious candidate for this?), and then checking at
regular intervals to see whether the time has been exceeded and the user need
disconnecting.
Note, by the way, that if a user has an established connection, then neither
changing the DNAT rule/s, nor removing their FORWARD rule from netfilter will
result in their connection being terminated - you will need to explicitly add
a DROP rule either at the top of the FORWARD chain (before the -m state
--state ESTABLISHED,RELATED rule), or else in one of the mangle tables, in
order to make sure the connection gets cut off.
The other thing I would say is that because you are talking about doing this
over a wireless link, I think you *really* should use HTTPS, not HTTP,
otherwise someone else in the vicinity will simply sniff the traffic, find
out a valid username & password, and use it themselves.
I recommend the Apache 404 error handler redirects to an https: login page and
you accept the username & password there.
Hope this helps,
Regards,
Antony.
--
The lottery is a tax for people who can't do maths.
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic change of iptables (building Wi-Fi hotspot)
2004-07-04 17:03 ` Antony Stone
@ 2004-07-04 18:10 ` Vladimir Mosgalin
0 siblings, 0 replies; 4+ messages in thread
From: Vladimir Mosgalin @ 2004-07-04 18:10 UTC (permalink / raw)
To: netfilter
On Sun, 4 Jul 2004, Antony Stone wrote:
AS>DNAT rules belong in the PREROUTING chain, nat table, not the FORWARD chain,
AS>filter table :)
Ah.. yes. Well, I had an example that used my own chain, and incorrectly
changed it for simplicity before posting.
AS>Also, instead of -j DNAT --to 127.0.0.1, I think you should use -j REDIRECT.
Right. That was a quick&dirty example, I forgot about that.
AS>I see no reason not to change netfilter rules as often as you like.
AS>After all, adding one rule when a user registers, and removing one
AS>rule when they unregister or time out, is unlikely to be a large
AS>quantity of changes.
Yes, but who knows, maybe when changing tables a lot something will
overflow after a month or so, or maybe some packets will be dropped.
And I may need to add or remove two rules (one for ICMP, because ICMP
won't be just dropped or accepted, but filtered though another chain).
AS>As for whether the several scripts are a problem - that depends on
AS>how good the scripts are :) I don't see that they need to be at all
AS>complicated - the interesting part is going to be looking up the
AS>username / password (PHP / MySQL would seem an obvious candidate for
AS>this?), and then checking at regular intervals to see whether the
AS>time has been exceeded and the user need disconnecting.
Yes, php, mysql & perl are the choosen tools, but it would be a bit more
complicated. For example, there should be ULOG rule and one of the
script will have to analyze ulogd's mysql dumps.
AS>Note, by the way, that if a user has an established connection, then
AS>neither changing the DNAT rule/s, nor removing their FORWARD rule
AS>from netfilter will result in their connection being terminated - you
AS>will need to explicitly add a DROP rule either at the top of the
AS>FORWARD chain (before the -m state --state ESTABLISHED,RELATED rule),
AS>or else in one of the mangle tables, in order to make sure the
AS>connection gets cut off.
Thanks, I'll note this.
AS>The other thing I would say is that because you are talking about
AS>doing this over a wireless link, I think you *really* should use
AS>HTTPS, not HTTP, otherwise someone else in the vicinity will simply
AS>sniff the traffic, find out a valid username & password, and use it
AS>themselves.
AS>
AS>I recommend the Apache 404 error handler redirects to an https: login
AS>page and you accept the username & password there.
Actually, that was the reason why 404 redirects to other page, not
displays login page itself ;)
--
Vladimir
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic change of iptables (building Wi-Fi hotspot)
2004-07-04 16:33 Dynamic change of iptables (building Wi-Fi hotspot) Vladimir Mosgalin
2004-07-04 17:03 ` Antony Stone
@ 2004-07-04 21:26 ` Eric Leblond
1 sibling, 0 replies; 4+ messages in thread
From: Eric Leblond @ 2004-07-04 21:26 UTC (permalink / raw)
To: Vladimir Mosgalin; +Cc: netfilter
NuFW can be a solution to that problem (website : http://www.nufw.org).
NuFW is basically a authentication firewall suite : you can filter
access by user and not only by IP.
In your case you can use the following features of NuFW :
1. NuFW users are stored in a ldap tree
2. Users activities can stored in a SQL database (although the
existing syslog can be enough)
3. A mark corresponding to userid can be put on all packet coming
from user.
With 1, you can create users and store all needed information, they can
only goes through your gateway (for selected flows or all flows) if
their account is available.
With 2, you can determine when a user connects, so you're able to
determine their usage time.
With 3, you can account user traffic accuratly even if their IP change.
Some constraints though :
- NuFW requires a software client on user computers. But it is light
ones. UDP traffic is not yet manage by existing nufw client, but it
could if there's a need ;-)
- persistent connections (with long duration) can not directly be
stopped by nufw. Although it should be possible by using some tweaks
(send a paquet every N to nufw system for example).
BR,
> Hello everybody.
>
> I want to build a Wi-Fi hotspot. The linux box with wireless AP
> connected to it which provides internet access to people with Wi-Fi
> cards.
> 2) All traffic is redirected to tun interface, and some C program
> analyzies each packed and decides whether to pass them or block them
...
> will have to pass through this program and it must be written really
> good if I don't want to have problems.
--
Eric Leblond <eric@inl.fr>
INL
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-07-04 21:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-04 16:33 Dynamic change of iptables (building Wi-Fi hotspot) Vladimir Mosgalin
2004-07-04 17:03 ` Antony Stone
2004-07-04 18:10 ` Vladimir Mosgalin
2004-07-04 21:26 ` Eric Leblond
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.