[Chilli] MAC blacklist and other security measures

[David Bird]

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

Thanks for your feedback!

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

Yes, giving an access-accept during MAC authentication will have it's
side effects. There are a few options, however, that you can put into
RADIUS replies, more on that below. 

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

> 
> 	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' 

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

> 
> 
> >> - 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?
> 

It might be nice to have a "ChilliSpot-Config = 'blocked'" option that
can be used outside of macauthdeny for this kind of use. 

> 	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. :)