Comments below denoted by >>
-Antonio -----Original Message----- From: Olivier Bilodeau [mailto:obilod...@inverse.ca] Sent: Monday, February 28, 2011 12:37 PM To: packetfence-devel@lists.sourceforge.net Subject: Re: [Packetfence-devel] SSH Script to Deauthenticate Hi Antonio, On 22/02/11 3:05 PM, Manueco, Antonio wrote: > Considering the fact that Meru might not want to support deauth through SNMP > I'd like to see if we can do something. When you configure a switch to use > ssh (haven't tested telnet but I am guessing it uses the same parameters) > that it spawns a new SSH session with the switch (in our case it's a Meru > Controller) for every time someone registers to deauth the wireless client. > > Considering we have 41,000+ wireless registered devices and about 5k > simultaneous users on the network, this is going to crash the Meru controller > no doubt. > So far, that assumption has been mitigated by the fact that with PacketFence you only do registration once. In other words, your 5k+ users will only be deauth (through SSH) once when they register on the captive portal. That is, unless you de-register them automatically or periodically. On WPA-Enterprise (802.1X) since they provide credentials you can even skip the whole registration phase and send them straight to proper VLAN. >> We have two parts to our setup. Captive Portal and 802.1x. In the Captive >> Portal side we are unregistering users every 8 hours so they hit that >> "Registering/Login in" page every time they get on the network. If there is >> a way to create a captive portal to always show up when a client logs even >> after they've registered please, please let me know :) On the 802.1x it >> works like it's suppose to and you get put in Production VLAN right away. So if you perform no massive de-registration, a gradual roll-out should be enough to cope with the SSH deauth rate. Then, for your next semesters students arrive gradually enough for the controller to be really busy on Monday mornings but not overloaded. >> This would work if we only wanted clients to register once, but as I said, >> since we need them to sign on with those credentials every time they log in >> (not using 802.1X), we are currently using the registering clients as a >> Login portal. Open to suggestions for a login VLAN for these users. The >> issue being that we can't drop our current operation and push everyone to >> 802.1x, we are trying to support both and push everyone to 802.1x gradually. Again, testing is always preferable to making assumptions. Have a look into the t/stress-test/soap-calls-snort[1] script. With some modifications, this multi-threaded Web Services tester could be transformed into a massive SSH deauth testing tool. In the thread loop, spawning a copy of the Meru object with a switchFactory instance and then calling ->deauthenticateMac(..) with fake MACs (or, even better, real ones) should be very educative about Meru's and PF's behaviors. > What I want to do is tweak the process that PF is using to ssh into the > switches and see if it's possible to maintain one session open and feed it > the parameters it needs to deauth clients from the controller. Any input on > how PF is configured to do this and where to look would be awesome, I think > some users might benefit from this. What do you guys think? Any other > suggestions that don't depend on the vendor? > It's a great idea! However, it's a rather intrusive change with foreseeable concurrency issues (the daemon handling SSH disconnects - pfsetvlan - is already multi-threaded..). I would add a new task (thread) to pfmon which would hold the SSH connection open and have IPC between pfsetvlan in the Meru Controller module and pfmon to tell him to perform deauth. pfmon would take care of re-connecting if connectivity has been lost and idle otherwise. When it gets the IPC call it would call the Meru controller module's _deauthMac(..) passing in the Net::Appliance::Session handle. My advice: test if you need it. If you do, try to pressure your Vendor again for RFC3576 support or Web Services calls (it seems Meru's SNMP stack is read-only, reason for no SNMP deauth). If it fails, look into developing your idea. >> We've mentioned to Meru that the SNMP deauth attribute states read/create >> even though you cannot write to it. They're currently looking into it. I'm very surprised that with a wireless network your size you don't have more leverage on your vendor. >> We're trying, trust me :) they are aware of this and we are trying to get >> it changed. Will keep everyone updated in the meantime. Would hate to >> spend countless hours hacking away to modify the SSH procedure when a simple >> Vendor change would fix the issue and help the community >< I hope this helps, Cheers! [1] http://mtn.inverse.ca/revision/file/8575a6a8a246a2e8096a9e58a451f59cfd179fa2/pf/t/stress-test/soap-calls-snort -- Olivier Bilodeau obilod...@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Packetfence-devel mailing list Packetfence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Packetfence-devel mailing list Packetfence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
