[Chilli] MAC blacklist and other security measures

Felipe Augusto van de Wiel felipe.wiel at hpp.org.br
Fri May 21 02:14:12 UTC 2010

Hash: SHA512


	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.


	Using the scenario where you reply with
Access-Accept as a DEFAULT entry has a side effect,
traffic is allowed on all other ports (if you do a
full NAT) without needing to authenticate on the
captive portal.

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

	In this new scenario, it would be great to
have a way to "drop" clients that got a Access-Reject
from RADIUS.

>> - You always return Access-Accept (plus attribute
>>   Chillispot-Config = 'splash') for non-blocked
>>   users.
>> - You can return an Access-Reject for blocked users.
>>   When used with --macauthdeny, it means these
>>   devices will be ignored.
> 	The proper way to achieve that would be to
> use a DEFAULT user in RADIUS? Here is the relevant
> part of my FreeRADIUS' users file:

	I changed it, now I add multiple entries but
I check Calling-Station-Id, that gives the MAC and
it is sufficient to make a blacklist.

> <...>
> | AA-BB-CC-DD-EE-FF  Auth-Type := Reject
> |                    Reply-Message = "MAC address administratively blocked."
> |
> | 11-22-33-44-55-66  Auth-Type := Reject
> |                    Reply-Message = "MAC address administratively blocked."
> |
> | DEFAULT            Auth-Type := Accept
> |                    Chillispot-config = 'splash',
> |                    Fall-Through = Yes
> |
> | "user"             Cleartext-Password := "pass"
> |                    Reply-Message = "Hello, %{User-Name}"
> <...>

	Instead of the above, I now use:

| "user"	Calling-Station-Id == AA-BB-CC-DD-EE-FF, Auth-Type := Reject
|		Reply-Message = "MAC address administratively blocked."
| "user"	Calling-Station-Id == 11-22-33-44-55-66, Auth-Type := Reject
|		Reply-Message = "MAC address administratively blocked."
| "user"	Cleartext-Password := "pass"
|		Reply-Message = "Welcome to our network!"

	Of course, I had to disable the macauth and as
this renders macauthdeny not very useful, I also turned
it off.

> 	Of course, that only worked after I added an
> include line inside /etc/freeradius/dictionary:
> $INCLUDE        /etc/freeradius/dictionary.chillispot
> 	Now, the MAC addresses listed on the users
> file gets a 'drop' state when chilli starts, the rest
> gets a 'splash' state and addresses in the ethers file
> stays as 'dnat'. Once the user authenticates thru the
> splash screen they change to 'pass' as expected.

	It then goes back to the behavior where everybody
is 'dnat' until authenticated and changed to 'pass'.

	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?

	The idea is that MAC addresses block can't
even navigate on the authorized pages like search
engines or map sites.

	Once again, I do hope it help others looking for
a blacklist implementation. :)

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