[Chilli] MAC blacklist and other security measures
david at coova.com
Sat May 22 05:06:30 UTC 2010
With regard to the 'splash' getting into local.conf bug, it's because of
the use of DEFAULT. You are also returning the 'splash' attribute to the
'administrative-user' login. Try setting --admuser="" to disable that.
On Fri, 2010-05-21 at 16:35 -0300, Felipe Augusto van de Wiel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
More information about the Chilli