[Chilli] MAC blacklist and other security measures

[Felipe Augusto van de Wiel]

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

Hi,

	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
addresses.


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

iQIcBAEBCgAGBQJL9exwAAoJECCPPxLgxLxPlWUQAI+aMtcWDZDExxSqYQY4yAqS
jqfwLrV3p5b9wiGIT6WLGLlDLyy5kqwrbVECGoO4zUUzzE3NjegpCuTAG15FEuYZ
uAxPOxBeNcwbG9nhuM/u8gbIcgJRUyeK+xOGOqPizsWJxCr2CATTRE1BM+dIIulm
87czEa6JJ7a0fCZbw1zDajGQCCSvjwLhlUVVpHIEP/slp/uyw+DoJfKMLa1CizYH
bt9/SvfEhCj4HidSFPfIH/Ez8tQbIoYIAG2GiQWYb+6FjCcS7jVS4HS8KJagskWG
ktLPm5BrPSWKbbyXQkuWId4xQfayI84ixsGE/mG+Kh75cSnm8UJpDO+D/r/HrC87
WFm7JaVh57BPcZwul70qt56uyTQN4MSVZolo9Sxe61mPP3WxeyTncBM7K2XdSSzF
9hgwM8GVDF8PYW+2grMU+TaYpAPQhrdgGI6B7sgvOvwzaTfRug0KJ/pjw+z1QVH0
pznlVRgLdM6ptcGLolzumRuxNTlSxWPgzPkFGT4wI8CZtqsIXCfGES0gDkaEFzN8
b8QtTF00PuJS0aSR/XeIiPVjc7W9gPE856hf22kmdEPtFdcVpVrohV9+Wj0ILvOJ
F4yjgROMqyNK2Inu12jaLefMKZww0k1ydT0Jb+49CyUbA/dSofAYm6o04fj0GeEK
SyOqkjtpFs2w2wsBfekN
=91MV
-----END PGP SIGNATURE-----