[Chilli] MAC blacklist and other security measures

[David Bird]

Hi Felipe,

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. 

David

On Fri, 2010-05-21 at 16:35 -0300, Felipe Augusto van de Wiel wrote:
> -----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-----