Re: Dynamic change of iptables (building Wi-Fi hotspot)

[Vladimir Mosgalin <mosgalin@VM10124.spb.edu>]

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