Olivier: I agree that there is nothing PF can do about a malicious user with access to FR ... thats a nightmare situation!
I know FR supports encrypted auth, I wonder how hard it would be to extent PF to send CHAP or PAP requests instead of clear text ... perhaps this is a chance to flex my fledgling Perl skills ... hmmmm : ) But by far the best solution for us was to enable the auto-registration, that has saved us untold amounts of time! THANK YOU SO MUCH FOR PUTTING IN THAT FEATURE! BTW: BIG thanks to Inverse, we are almost ready to deploy or PF setup into production. Inverse has saved us a lot of time and money! Jake Sallee Godfather of Bandwidth Network Engineer University of Mary Hardin-Baylor 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________________ From: Olivier Bilodeau [[email protected]] Sent: Wednesday, February 02, 2011 3:01 PM To: [email protected] Subject: Re: [Packetfence-users] What's the status with Captive portal RADIUS Authentication ? Hi Jake, > My more immediate concern is that anyone looking at the debug output > of the FR server will be able to watch user names and passwords > scroll by in completely clear text, again in a complex environment > where the same people may not manage the FR server and the PF server > that may be an issue. Not to mention the regulatory concerns, I am > speaking of regulations like Sarbanes-Oxley, HIPA, FIRPA, etc. BTW: > even if your FR server is the same as your PF server, this still > applies. I think there is nothing we can do within PF to mitigate that. What you can do: - Couldn't you use another mean to authenticate your users that isn't plaintext inside RADIUS? I'm thinking about CHAP or PAP. Never tried it though - or simply use SQL, LDAP or AD auth instead - better yet: if someone authenticates successfully using a secure means (802.1X) automatically register them (now possible with pf 2.0). This way they never reach the captive portal and don't need to authenticate using insecure means Then other mitigating factors: - I would suggest to wrap the RADIUS dialog into an stunnel if you are sending the traffic over an untrusted network - If a malicious user has access to run FreeRADIUS in debug mode you have other problems See Alan DeKok's (aka the FreeRADIUS guy) reply on the topic of not showing passwords in debug mode: http://www.mail-archive.com/[email protected]/msg61877.html If you find anything interesting let us know and we'll share it in our admin guide. Cheers! -- Olivier Bilodeau [email protected] :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
