[Chilli] MAC blacklist and other security measures

Felipe Augusto van de Wiel felipe.wiel at hpp.org.br
Fri May 21 19:35:42 UTC 2010

Hash: SHA512


On 21-05-2010 01:46, David Bird wrote:
>> 	Let me revive this thread in order to add a
>> few comments that would be nice to have and publicly
>> archived, specially because a few things have changed.
> Thanks for your feedback!

	You are very welcome!

	Coova developers and contributors are very nice
and kind with outsiders and sysadmins trying different
things and giving crazy suggestions/ideas. :)

	I always come back because there are always
ideas and different suggestions and Coova is moving to
add features that weeks before we talked on the list.

	So, thank you for always paying attention.

>> On 06-04-2010 12:42, Felipe Augusto van de Wiel wrote:
>>> On 21-03-2010 03:16, David Bird wrote:
>>>> Hm.. one way might be to enable MAC authentication
>>>> such that:
>>> 	That means enable 'macauth', right?  Using
>>> only 'macauthdeny' didn't result in the expected
>>> behavior.
>> 	Although it was not clear before, now it
>> makes a lot of sense that macauthdeny depends on
>> macauth, otherwise you are not authenticating MAC
>> addresses.
> Indeed, macauthdeny is used with macauth. It makes it
> such that an Access-Reject means the user session is
> put in DROP state (where there is no returning from).

	This is exactly what we want and indeed it
work as expected. As I mentioned before, the free
wifi we provide for our clients/customers but
sometimes we have some "corporate" users abusing it,
so we blacklist them to avoid circumventing the

	It was nice to know it worked perfectly.
More and more we are trying to improve our RADIUS
setup, specially around LDAP, so we are looking to
have EAP and a more well organized infrastructure.

>> 	In this new scenario, it would be great to
>> have a way to "drop" clients that got a Access-Reject
>> from RADIUS.
> That is what the macauthdeny option does, really. If
> you don't want all Access-Accepted sessions to have
> full access, then you can try out the feature where
> you also return this in the access-accept:
>   ChilliSpot-Config = 'splash' 

	I did that with the DEFAULT option, it even
raised the "splash" bug that replaces the entire
local.conf file.

	And it worked as expected, traffic on other
ports are allowed and web redirects to captive portal
until authenticated.

	We want to allow our users to use other ports,
otherwise we could change the firewall to block it all.

> which will put the user in a 'splash' state (full Internet
> access, just with portal redirection). You can also try
> 'require-uam-auth' (which requires using option --wpaguests
> even if not using WPA, btw) which will put the user in the
> standard "DNAT" state. In an Access-Reject, you can also
> use ChilliSpot-Config = 'admin-reset' to release the DHCP
> release right away. Using that, you can also enforce a
> "DROP" state where you keep revoking the lease (but will
> also potentially mean you get a LOT of mac auth RADIUS
> requests).

	The standard DNAT state would still allow the
navigation of pages allowed by Coova until client
authenticates in the Captive Portal. And indeed,
'admin-reset' can cause a lot of auth requests.

	As I understood it, right now I can't tell
Coova to change clients to 'drop' unless I use macauth
and macauthdeny. I was planning on investigate more on
the RADIUS side to see if there are something I am
missing, but I realize that probably is Coova that
needs to process the answer.

	Thanks for clarifying that. We can live with
the clients being blocked on the Captive Portal and
all other ports and only being able to navigate to
some of the allowed pages.

	One of the nice points of the macauthdeny is
that the client can't even get an IP or bind to the
AP, which leads the client to believe it is not
working (and achieves the point we are expecting,
preventing corporate users to abuse the free wifi
with corporate computers). :)

>> 	I was wondering if it is possible to have the
>> blocked MAC address to move to a 'drop' state after
>> Access-Reject, is there such possibility in Coova?
> It might be nice to have a "ChilliSpot-Config = 'blocked'"
> option that can be used outside of macauthdeny for this
> kind of use.

	Indeed, that would be very cool! :-)

Kind regards,
- -- 
Felipe Augusto van de Wiel <felipe.wiel at hpp.org.br>
Tecnologia da Informação (TI) - Complexo Pequeno Príncipe
http://www.pequenoprincipe.org.br/    T: +55 41 3310 1747
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Chilli mailing list