[Chilli] MAC blacklist and other security measures

Fri May 21 19:35:42 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey!

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
firewall/proxy.

	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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJL9uCKAAoJECCPPxLgxLxP3XEP/1FLpkZmMb0GioPlI0evdFn2
JiHrOXwNQz89qHKps5lOfHIYfJ/pvqEnNYxC/0iJ1LegKVt0v9JNIE8brFBUaR1F
zPt7z9zL6Qx+VqWtMLdMWPxAv5izkIS7mzc0ck+IvfP7lmo4zvLHJDAQw1Cn0FMF
i5KbGeJhgptlhhh3xr/r6mwD+qeMgY2STJzvwRbgq7925a/cWzkJAmafTYmKl2Up
5pJZLdcWSCpqi0ijIKKQ5+aZgG6ELYifUvQC4pQFicV+YuSw/1YGOGbS5BysYN/z
2vBW2o6DqX17/t8mVs8+e4cFdKnGCpJl1fqaiUuVkMPgttNBJ8I03Gw1yWGuK5F5
kSgu5KFDutVSnHS4irGZKvOHRUThiSTdOmeZwAPirH7FjR/LU5dcI4puwORIYKbj
7fDFNez7RO16IsnthGqdKp5LFtSFY/MQ0lUtFL9vTzcNNtIerhDQSQ3vcCUv7Qkn
OYNSLceAb371QiKRKnEPYGYlpRguh0GVHdvFBGyGcBHj/VooxrS1In144eYteEw2
0LXt5mCDGKxfI2CJ9XytZz2bZrivyLCSVV5oqyeQzugfoqhsBds2S/tBeMIaWebA
sUOsQ+8T21bBZnGupu+jTSDJUyrv65ldfJCvcwqHqzNIpxs0DM3GL0dV4l99jiPo
VKvdiEkmBP7iYjq86URQ
=I8Vn
-----END PGP SIGNATURE-----