[isf-wifidog] Gateway continues to allow persistent connections after logout

[Samuel Leathers]

This is tricky... With the rule allowing stateful connections, and because
the order is significant for iptables, there isn't anyway to gracefully
disconnect these connections. This means this rule would have to be
removed from the firewall script, and wifidog would have to handle
stateful connections. To enable this feature, at least to my knowledge I
think wifidog would have to take over the entire firewall portion, which
makes it a lot harder for wifidog to work across different types of setups
(some people will want NAT, others won't, some will want static routing,
etc...)

If this is implemented via wifidog, when a client logs in, it could create
a stateful rule specifying the MAC in the rule, and then on logout -D the
rule. I'm not sure how this would affect the communication with the auth
server (haven't looked into what allows that).

Also, a quick note regarding access allowed before logging in, if other
domains are on the same ip as the gateway server, access is allowed to
those domains without logging in. Not sure if this is a big deal or not
for most people just though ya might want to know. Basically, my auth
server is wifidog.gentux.org, and gentux.org, samleathers.com and other
domains are on the same server accessed by the same ip address, I can
easily just put wifidog on a dedicated ip, but that might not be an option
for some people.

Sam
>
> Take a look at the ip_conntrack (IP connection tracker) subframework
> in Netfilter.  I have a hunch it may be the cause of the problem.
>
> Most modern firewalls are "stateful", which means they keep track, in
> memory, of on-going IP conversations.  This is considered more
> advanced and more secure than simple stateless packet inspection.
>
> What I think you'll need to do is tell the connection tracker to
> "forget" ongoing conversations when a user is logged out.  I looked
> into this a long time ago when I was experimenting with captive DNS
> and found no easy way to do it.
>
> It would be also interesting to follow up on your suggestion of
> moving the firewall rule below (state inspector = check the
> connection memory) within one of WiFiDog's chains, but I feel that
> it's too intrusive and may break things, especially if within an
> existing firewall ruleset.
>
> On 26-Jul-06, at 4:03 PM, Tarken Winn wrote:
>
>> Hi Chris,
>>
>> Thanks for the email. I am using cron for cleanup and it works
>> fine. Timeout is set to 30 seconds (I think it was - default).
>>
>> However, I expect the problem I am experiencing is universal. For
>> 'normal' use the system is working great in every respect. User is
>> forced to login before they can access any web services and after
>> logout is forced to login again for any NEW requests (opening
>> another webpage, reloading etc). However, if while logged in a user
>> has started a streaming service - such as www.pandora.com (the
>> specific example I was using when I discovered the bug) - the
>> stream will continue AFTER they have successfully logged out. If
>> you have a node accessible, have a go yourself. I am using a
>> Linksys WRT54GL router, but expect it will happen on other routers
>> also?
>>
>> Samuel pointed me to the line in the default /etc/init.d/
>> S45firewall file that I mentioned and after some naive testing I am
>> somewhat convinced that it is at least related. The firewall allows
>> RELATED,ESTABLISHED packets through before ever hitting the wifidog
>> gateway. At least that is my understanding of it. So a packet comes
>> in from www.mystreamingbandwidthgobbler.com and is judged to be
>> part of an already established connection and is therefore accepted
>> by the firewall and forwarded to the user - whose wifidog status
>> does not matter.
>>
>> I wonder whether we need to get rid of the line
>> iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>> from S45firewall and re-implement this in the wifidog iptables chains?
>>
>> I'd be interested to know whether you and others experience the
>> same? Is it router specific (different firewall/iptables setups on
>> different router types)?
>>
>> Thanks again,
>>
>> Tarken
>> On 7/26/06, Chris Rowson <christopherrowson at gmail.com> wrote:
>> Hi Tarken,
>>
>> Am I right in thinking that your users are able to continue using the
>> connection after they have logged out?
>>
>> If so, have you changed CONF_USE_CRON_FOR_DB_CLEANUP to false in your
>> config.php. That should clean up your database everytime a user query
>> comes in (which solved a similar problem that I was having).
>>
>> Also, have you checked the timeout variables in the wifidog
>> configuration file itself?
>>
>> Chris
>>
>> On 26/07/06, Tarken Winn < tarkenwinn at gmail.com> wrote:
>> >
>> > Hello again everyone,
>> >
>> >  I have spent a fair amount of time investigating the issue I
>> previously described, namely that when a user logs out any
>> established streaming connections will continue as accepted, and
>> have not found a solution.
>> >
>> >  It appears that /etc/init.d/S45firewall allows
>> RELATED,ESTABLISHED packets to be forwarded at the line:
>> >
>> >  iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>> >
>> >  I tried commenting out this line in the hope that it would be
>> covered by the rules in the WiFiDog_WIFI2Internet chain which is
>> checked in the FORWARD chain, but to no avail.
>> >
>> >  I have tried allowing any packets with the auth server as source
>> or destination to be forwarded, which allows a user to login (in
>> the hope that subsequent packets will then be marked in the
>> WiFiDog_WIFI2Internet chain and correctly forwarded) but then does
>> not allow access to any websites other than the auth server even
>> after successful login.
>> >
>> >  I now wonder whether the only way to solve this issue is to
>> modify the wifidog gateway client code? I guess fw_iptables.c is
>> where things would need to happen.
>> >
>> >  Has anyone come up with a solution for this issue? Does anyone
>> knowledgeable on the internal workings of the gateway and its
>> interactions with iptables have any suggestions?
>> >
>> >  Without resolving this issue, limiting and recording the amount
>> of data a node/user can transfer per month seems a little futile. A
>> user could (and no doubt will) just login, start a streaming video
>> feed (or whatever), logout, then kick back and watch the show
>> without being 'counted'.
>> >
>> >  Thanks,
>> >
>> >
>> >  Tarken
>> >
>> > _______________________________________________
>> > WiFiDog mailing list
>> > WiFiDog at listes.ilesansfil.org
>> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>> >
>> >
>> _______________________________________________
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>>
>> _______________________________________________
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog


-- 
Sam Leathers
Sam Leathers Computer Services
814.574.7307
sam at samleathers.com
www.samleathers.com
 -Computer repair services
 -Reliable business consulting
 -Web design and hosting that meets your needs
 -Collection of computers no longer needed
 -Student discounted repair rate
 -Server setups and networking
-------------------------------------