 So, I'm really glad that you are all here today this morning. What we're going to talk about is packet fans. We've been working there for two years and it's the first time we unveil, we talk about packet fans at such large event. We've mostly done stuff locally in Montreal so I'm really glad to be able to talk to you about it and I hope I'll share my excitement. So, what we'll see today is WETS Network Access Control really briefly. We'll talk about the secret sauce, so how we do stuff and how it works. We'll talk about why open source has been very helpful for us. They're good and bad of the two years as a lead developer and some lessons learned and some ranting. And then the future of packet fans, so a bullet list of stuff we want to look at in the future and some community begging for help and stuff. So, who am I? I'm Olivier Bilodeau, working as a system architect for Inverse since 2001, lead developer of packet fans. I'm also teaching information security to undergraduate students in Montreal. I'm really into open source, I'm also a new father, I brought my baby here at Defcon for the first, she's seven months old so it's been quite something, the airport and all that. I'm also enjoying CTF Salat, so we're with the Amish security team doing CTF. And also the CISSP groupies and we did the Defcon qualification two years in a row with mitigated success. I'm developing TomDroid, which is an Android application too. And so if you want to be interested in what I do and follow me, here are the social stuff links. This talk will implement you drink, me drink protocol. So if I see something stupid, you can interrupt me and force me to have a sip of a good beer. The beer I chosen was, I need to talk about it, was the IPA, California IPA, it's really good, so I hope I'll make some mistakes. And there'll be some beers, I only have these left, but for the debriefing, so people that come to the debriefing after the talk and have good questions, you'll have a beer. All right, so network access control. This is the elevator pitch, let's not focus on that. You guys are smart and you know what most of it means, so we'll go fast. Attentication. Basically, attentication is map username to IP addresses or MAC addresses. So the firewall doesn't discriminate between users and IP addresses where MAC, the core focus is to be able to know this device is owned by this person and it's really the binding of the two that is important for MAC. There's admission. Admission is allow, partially allow or deny users and there's control. So control here is to watch for unauthorized stuff, including outdated antivirus, patch level, someone scanning corporate servers, spreading malware, etc. So network access control has the goal to do all of that. There's the usual sales pitch stuff that you see, which involves a loop between detecting a device, isolating a device, notifying administrators about the states of these devices, and remediation, which is a key point that we'll talk about several times, which is how to help the user to remediate problems, including updating systems and stuff. So basically, it's know who is using your network and making sure they behave. And we're not talking who an IP address, we're talking who a username. So it's really important, an authenticated username. So that's. With time what MAC has become, well, remediation of users, as I just mentioned, guest management, so a lot of people want to handle guests, put them on the internet only, no access to the internal servers. So it started to do that. Asset and inventory management, so it's there, it saw the devices and so it categorized them for you and you see it. And also it simplifies the access layer configuration. So the more technical people come to PacketFence because they are tired of doing per port configuration manually switching VLANs to on ports. And so with an act, the VLAN management is all done in the server and more transparently and it simplifies the access layer configuration. So the secret sauce. The technology, mostly Pearl, some PHP, we're leveraging open source, the asterisk means that I'll be talking about it in the future. I did that a couple of places, so this is the concept. And it's designed with high availability in mind. So everything we do, we always think about, we use active passive clusters. And so it's really a core focus because network access control, if it's down, no one accesses the network, which is really bad. So it's from the ground up thinking in clustering in mind. Key design decision that we've made with PacketFence, we're out of ban. So this is the bioposition to be in line, which means that it's really the infrastructure that takes a decision. We're not in the packet flow out to the network. So if the server fails, it most likely fails in the same state. So it's really bioposition to in line where you see that there's a firewall doing the decisions and the packet goes through the NAC device. So we're out of ban, so no packet is going through the server. We're doing edge enforcement, so this means that the decision for access are done the closest possible to the endpoint, the client computer. So it minimizes the attack surface by a lot. Client who has not been allowed in the network cannot scan servers and do anything. He's like, the switch decided that it couldn't get access, so really the edge kicked him out if you want. We use no agent, so this is a lot of the proprietary NAC are using an agent-based system. And so we decided that it was error-prone and buggy, and in a world where there are several devices coming out all the time, we cannot cope with developing agents for all of these. So we decided let's not do that and focus on a web-based captive portal instead. And so that's what we do. Snipe to everything is also a big thing that we wanted to do, is we see everything that's out there. So we sniff the ARP, we sniff the MAC address when there are security violations done by the switches. When we see IPs, DHCP, we gather all that information all the time. If a user hit the captive portal, we record the user agent, so we're really about identifying everything that's on your network. And a lot of people are amazed when they first plug packet fans, even if it's not doing enforcement, they will see a lot of devices that they weren't aware about. So out of band, how we do the out of band stuff is we rely on SNMP traps. This was the first technique that we developed in 2007, which was the first step that we forked out of the original packet fans project, which was based only on DHCP. So the SNMP traps, we have several implementation. One is for link up, link down events. One is for magnetization event with our, to my knowledge, a Cisco specific trap. And then there's port security, which was at first Cisco specific, but then got picked up by a lot of vendors. The port security, the advantage of port security is that you get the MAC address in the SNMP trap that gets sent to packet fans, which means we don't need to go and spoil a threat going to the port and waiting to see the MAC address show up on the port. So it's really more performant. You have a comment? Oh yeah, that's right. Let's do it. That's good. Okay, so then we got radius based technique that emerged, which is 802.1x or MAC identification. We will talk about these in a sec. So we first implemented wireless MAC authentication because the customer demand was for wireless to manage the wireless and the wired side with the same software, same solution, which has been great for us. Then we implemented wireless 802.1x, which is what most people know as WPA enterprise. And then we implemented lately the wired MAC authentication and 802.1x pieces. So let's go into a little bit more detail. The SNMP trap enforcement works by event on the hardware that generates traps. We react to the trap and then we use SNMP client to connect to the switch and then perform port authorization, so MAC address authorization on the port and change VLAN if it's what is required to do the proper enforcement. So it's an asynchronous process if you want and for most of the vendor it works really well. For some of them we need to rely on Telnet or SSH because their SNMP interface is not good, which we don't really like. So one of the advantages of the authorization and the edge enforcement by SNMP traps is that because of the asynchronous nature of the authentication is if let's say the system would fail, the system would fail in the last state that was established. So the port security trap is sent to packet fans, packet fans saw the trap, saw the MAC address, decided that it should have been in the VLAN 100. It will go and put the user in the VLAN 100. Then there will be no security notification that will be done by the switch because we authorized the MAC address on the port. So as long as another device which has another MAC address which will generate a security violation and then the cycle again, then as long as you don't have new security events, the system will stay in the good state no matter if the packet fan server is up or not, running or not. So it's really a great advantage for this technique. Now digging into the radius-based approach, let's have a few reminder about the protocols related to that. Radius is a key value-based protocol for AAA. AAA stands for Authentication, authorization, thank you. I guess I'll drink again. Authorization and then audit. So it's a very infrastructure type. Accounting or audit. I want to argue you guys are smarter than me twice. So it's an infrastructure protocol. There's nothing like the switch speaks with the server and there's nothing that the client needs to implement. Let's not get into 802.1x so far. So if you look only at this piece, it's really infrastructure-based. Now let's build on top of radius and see 802.1x then. What is it? It's extensible authentication protocol over radius. So EAP and all that nasty peep MSChap V2 and then encapsulation over encapsulation and stuff. So it's adding a lot of new components to the pure radius that we just saw. So the actor in 802.1x are the supplicant, the authenticator and the authentication server. I've never saw any authentication server besides radius but I'm pretty sure you can do it with diameter so it's options. The supplicant is actually the client and you need something on the operating system to support 802.1x so it's not as transparent as MAC authentication is. And the client-side software has been integrated in Windows, in Linux, in OSX for a couple versions now so it's pretty stable. But we'll see problems with that later. And authentication, most people know it as the NAS, so the network access server. All right. The protocol even allows you to send stuff to the client so this is how the WPA enterprise setup is that as part of the authorization and authentication it will send the keys in this encrypted tunnel. This is all, if you see the little diagram, this is all pre-DHCP, so pre-IP and this is why it's called port access control, port-based network access control. MAC authentication is simply taking a step back for 802.1x when the device doesn't support it, we do a simple radius authentication authorization with the MAC as the username of the, in the radius system. So it's really similar to 802.1x but there's no strong authentication, there's no end to end with the client, so it's more of a, the infrastructure is taking care of all the boilerplate if you want. Also in the new quote-unquote techniques related to radius is a radius COA which I'll talk about a bit later, which means change of authorization which is RFC 3560, anyway, you guys saw it. Which is, so the COA answers the problem of doing, because radius is initiated by the switch and the client, the COA takes care of the server says to the switch, please rethink the security posture of this device. And so it's kind of adding a new asynchronous nature to the usually really synchronous nature of radius. Never bring your friends to your talk. All right, so what do we do for the enforcement then? We accept access, sorry, most requests. And then based on that acceptance we return the proper VLAN attribute on clients. When someone is not known to the system or is not authenticated, we return a registration VLAN, so a VLAN where we present a captive portal or if the user should be in isolation stage we return the isolation VLAN. And so that's how the magic does. So we do access, accept most requests, otherwise the user will not have network access which is kind of defeats the purpose. We use free radius to do the radius and dot 1x pieces and it's great. Complicated to configure, but it's great, it works well. Now what we added is a Perl module to the free radius. Free radius has this RLM Perl facility which allow us to use Perl code directly into the free radius. It's very performant and with that we do a SOAP request to the packet fence demon if you want to the Apache of packet fence and the decision is taken server side. So this allows for a nice architecture that I'll talk about later. Now moving on to the captive portal, okay, various authentication mechanisms. So we support LDAP, AD, radius, Kerberos and guests. We use the portal to do the authentication. If a user did 802.1x then the authentication is already went to the AD server so we don't need to present the captive portal. So it's, there's a lot of options there actually if you want to automatically register devices and stuff. What does the captive portal do after someone's authenticated over HTTPS strongly is we redirect them to the internet and we can also provide remediation information which we'll see later. In order to reach the captive portal on the VLANs where we present the captive portal, we provide DHCP and then in DHCP we provide the DNS server and we do a DNS black hole. So any request will get the same answer which is the packet fence server. It's really simple, cheap technique that we do. And then with the first hit on the browser we use a mod rewrite. To rewrite the URL, for example, google.com will be rewritten to pf.initech.com slash captive portal which allow us to have a valid certificate because we have a domain name there. So it's not like other solutions which are doing reverse proxying which then you have SSL problems with that. So it's kind of, I'm kind of glad that we did that. So how do we do our voice over IP now? Our old technique because we're kind of changing this right now is we rely on CDP and the voice VLAN features of the switches which is actually easy to attack if you want. So now what we do is we handle them as regular devices and we try to automatically register them if the user wants that. But so there's still the older technique and CDP is so transparent that a lot of people prefer that even if it's insecure. Over radius we do macadanscation and then your phone doesn't really matter. What matters more is your network device, so the switch in question. And with 802.1x there are some vendor specific attributes in radius to control the behavior of the VoIP stuff. But we've never saw a lot of 802.1x capable phones so it's really a tricky business and we're not, we've done it over wireless and wired but it's not, I think we only got it with Avaya so far and there's not a lot of customer demand for it and because there's not a lot of phone who does 802.1x, so it's getting there. Maybe I'll have another presentation on that. The PC behind the phone, voice over IP, yeah this is exactly what I mean by voice over IP is that if it's only a phone then I don't really care, I am handling it like a normal device. But if there's a PC behind them there are problems with that especially because we provide the HCP, you know I'm seeing the time I'm flying and I really want a question about it in the debriefing and I'll give you all the details. It is tricky business. When it's over radius based technique it's easier and it works better than when it's over SNMP based techniques because of the influence of changing the primary VLAN ID on the port and stuff like that you really need to be careful and tag the proper voice VLAN and stuff so yeah I want to talk about this later. So for the voice over IP, a little note to pen testers, most want auto registration of the phone. The phone doesn't have a browser so you cannot ask your user to go on the phone and register it. So either they have a list of all the MAC addresses and they automatically register them or they do it through several techniques which is MAC vendor prefix. I saw that. I think the three coms which is do that which is really discotable which is a really tricky or I think an insecure technique if you want. Others do it through CDP. We packet fans do it a lot with the HCP fingerprints which are something I talked about yesterday about the finger bank project which is really rarely spoofed so far but as more people will gain awareness that we're doing the HCP fingerprints I'm pretty sure it will get spoofed and then people will get access to the LAN by spoofing the HCP fingerprint of a phone and also the phones that are 802.1X capable are doing MD5 authentication which is a flawed EAP technique for 802.1X so it's not great and so the note is here spoof any of these techniques and you'll get access to the voice VLAN and then from that scan and try to pivot maybe if you can on the media server so pen testers should really look into the voice VLAN stuff. So quarantine is the captive portal sorry feature where we present remediation information to the user. Here's a screenshot of how it's done. Now I made that up it's not a real technique that we have it's written here you have been detected using Windows 95 please install a decent operating system download open BSD that will probably not work on a desktop computer but I don't want to get a flame start. So the triggers we have for quarantine is operating system based on our DHCP fingerprint browser, Mac vendor, Nessus, IDS which is Nord based which I'm going to talk about in the next slides and so the captive portal provides instruction it's really helpful to reduce help desk pressure when you implement NAC and so we we've been really enjoying doing stuff with that and it's the customer who come up with their greatest stuff to do with with the quarantine and we really like that. So the policy checking and monitoring how the Nessus side is a client side scanning upon authentication it's I say somewhat limited because if you don't provide a domain for example domain credential on the Nessus scanner then you can only see the surface exposed on the on the client so you can prevent them from running a web server for instance but you cannot do more but if you do provide domain admin credentials then you can you know hit on the device and then list the patches and stuff like that. It's not free and also more the more tests you have the more the longer it will take to authenticate to authorize a device on the network and it's something that a lot of people what it takes two minutes to do a Nessus scan on a client it's too long so let's forget about that. So it's been mixed love-hate relationship with our Nessus implementation then the snort piece is more most of you guys know snort I'm pretty sure and so it's an interregion detection system you clone your traffic that is going to the internet to the packet fan server you run a local snort instance there and you enable the rules you're interested in too and the devices violating the rules will be isolated it works really really great and we've been doing a lot of bitorrent blocking sky blocking malware detection preventing users from end mapping the servers and stuff like that and it's it's it's great and with the quarantine captive portal we've been we are able to provide a couple of like you can do bitorrent three times after that you are completely locked out of the network so each time we present you with the captive portal but you have a button to re-enable your access to the network so you can do stuff to annoy your users if you want like allow them to re-enable their internet access a hundred time or a thousand time and see how how long they will you know try again and try again and try again to do peer-to-peer before they are getting tired and just calling help desk what's going on no we don't do that and it's probably because we were never asked this come up come up over for a beer so I again being open source we're really and having running a business on open source we're really really tied to what's going on on the here we go oh I'm sorry so yeah we're always interested and the syslog stuff there are new switches that can send syslog events and I've never I saw the features and I never looked into it but it would be something really really interesting we do support that we have a remote mode for snort which we use our own demon we tailed the the alert alert file and then we do a soap request so then you avoid the crashing your whole you know packet fence because there is a gigabit of traffic per second to analyze for snort but snort with his single threaded approach has been quite good because it cannot crush the rest of the system because it's only using one core one thread so it's it's it's it's still interesting and we have a really big big enterprise customer running snort and packet fence on the same server and it's it's doing great so how do we support network access I see that I run out of time I need to move faster so adding a new supported switch for the radius based technique is really really great all we need to do is because all the legwork is done by free radius always we say is we support wire dot 1x and if the the NAS port that is sent by the the switch is the same as the ef index there's nothing else to do and then we implement the attenuation which is again very standardized there is the PAE reattenscate SNMP mid that works in like 99% of the cases and so for us adding new radius based supported devices really easy SNMP is more challenging because it's not standardized as much especially regarding port security a lot of the hardware do it per switch port VLAN and some of them do it per switch port and so because of that they are different tricks that we need to do especially with voice over IP again so it's it's it's a love hate relationship and it's one of the things that brings us customers and you know we work on supporting new hardware and they pay us to do so so it's it's been good for the business but for your mental health it's not that great it's like there's nasty bugs in there I we I'm going to talk about it earlier later a little later but it's mostly read the switch documentation try to configure it figure out that there are mismatch between the documentation how you do actually do configure it and then your SNMP walk and you try to find the the the sexy stuff you're looking for the MAC addresses port security information and then you do your SNMP set and then as when you got it working with SNMP set then you port it into your pearl code and then rinse repeat and you have a switch working with SNMP yes we are but this is a net SNMP library which encapsulates all of that but we've got I don't know if I don't want a name any names but they are implementation of SNMP V3 which are really really buggy and it's not our fault it's the switches fault and so sometimes you know we face problems and we need to pull in other modules and stuff and it's a love hate relationship with SNMP V3 I really prefer when a customer has a management VLAN which is guaranteed to be isolated and so I'm telling them you know what SNMP V2 is fine by me if you're you're sure that no one can sniff on your management VLAN but again it's all arguable so the packet fence then is the zero effort knack which is a VMware appliance which we have version for the desktop suite and also the ESX stuff so it's pre-installed pre-configured and people can really try packet fence quickly with a VM instance so just wanted to let that all he's glad I'm glad that you're glad okay so open source for the win what has been great for doing open source for us is the vendor independence a lot of the network access our competitors if you want they really clue in into the vendor or they do not and then do art poisoning or other inline techniques which are in my opinion less secure and so because of being open source we kind of you know poke at the firmware and try to make it work and when one wanted device implemented we work on it and a lot of the let's say mostly universities they actually develop their own module and they send it to us and then we support new hardware and that's just being great the proprietary pricing is questionable there is per IP per concurrent connection per AP access point per switch license fees so it's really kind of odd and and for a lot of people migrating over to packet fence they tell me like we pay so much for our next solution it just doesn't make any sense and it's because they charge per IP and people are using wireless and every device that you have like five of them on yourself and you just cost them five licenses because they all wanted to hook on the network and so sometimes they really like we need to move away from the proprietary stuff also because we can stay focused and we build on top of Apache bind the HEP net SNMP 3 radius snort IP tables Nessus 70 plus c-pad modules that we pull in when you install packet fans so like we really into reuse I guess we use Linux and it's been really great so this is an also an advantage because the stack is familiar so you guys all know the tools and when you really need to tweak the things you can do it yourself and when you need to troubleshoot it's not dark arcane magic that you cannot understand or can or you need to call support for it's stuff that you actually can see and that you can Google on on Google so so it's great because okay I have this radius problem I Google it and then oh everyone has the similar or twist a different problem and you can help troubleshoot yourself by doing that which is not something we can see of the proprietary offerings and so it's been also good security is not necessarily solely based on security on obscurity sorry so what I mean by that is that this is network access control there are some things that we kind of lift the carpet and put the dust under the carpet because we are doing questionable things because we want you know the customer to be able to deploy easily and you know a knack is better than no knack so we still need to have them it all boils down to user-friendliness versus security and you guys all know about that so other solutions can be all about obscurity but we since it's open source people can look at it and say hey you guys are doing like funky stuff over there and maybe you should not do that and so it's an advantage because you can look at it poke at it and find problems so what I've been learned and what we've been we doing bad and doing good for the last two years so let's go most knacks are easy to bypass this is something I learned by while working at inverse because of network administration friendliness so purport exceptions for printers voice over IP uplinks you find them you can leverage them CDP is being enabled on access port which is in my opinion a problem real DNS is exposed so if your knack solution is based on offering the internet DNS there are a lot of tools to be able to tunnel TCP into DNS so you can tunnel out and because there is no attenuation built-in into layer 2 or layer 3 if you're not doing 802.1x everything can be hacked or spoofed so you can change your IP address you can change your MAC address you can change your your DHCP client to be able to spoof the fingerprints I was talking about earlier you can spoof your user agent and your user agent spoofing has been known to get you out of Cisco's I don't knack profiler anyway they see if it's an ipod or iphone or ipad user agent then they let you through because they don't have any agents for this OS and so because of that again it's because there's no attenuation and and you can spoof this stuff client side and there's the trust which is fake then is easy to bypass and so again coming to MAC address spoofing printers don't have browsers so they will they will often be pre-registered into the knack devices and so printer is so easy to find the MAC address on a printer you go there do your physical pen test you pop the printer on the side you look at the MAC address you put it on your backtrack 5 client and then boom you're out in the printer vlan and you can start scanning the the the print servers which are windows which are not patched so another thing I learned is that you can bypass 802.1x but there's a talk actually right after this which is focused only on that a two-hour talk on how to bypass knack 802.1x but let me still tell you what's the technique so you put a hub between the victim and the switch the goal is to prevent the port from going down see if there is no link down then the stack is not reset because it's a port based network access control and once the access has been granted there is no continuous monitoring of what you have been doing with the access so you wait for the victim to successfully authenticate because you put a hub in between you spoof your MAC address with the victims Mac and then you plug into the hub and bam you bypassed 802.1x completely this was a I discovered this by a kind of a mistake when I was working on 802.1x capable phones and I kind of couldn't believe it and I googled it and then I found on Wikipedia and on Microsoft there is an article from 2005 talking about this problem but now the bad thing is that they're doing appliances like the pony express which is doing 802.1x bypass it's really interesting to see that it's gaining traction after all that time so the attack scenario is you have two things you can do you keep the legitimate client connected which is bad because you'll have duplicated MAC addresses on the same segment but which is good because the client can reattenscate if the switch asks to or you replace the legitimate client which is bad because you won't pass a reattenscation request because you're not able to provide a strong attenuation but what is good about it is that you will not have network problems because there are no duplicated MAC on the segment. It works and see the bridge to far talk by skip which is after this talk in track one and I'm pretty sure that because he's doing bridging he'll be able to circumvent the problem I'm mentioning here the attack scenario because he'll be able to firewall in between let the heap overland go through the client but still intercept the the the good stuff that he's want to do in the middle. Getting into 802.1x is tricky business I'll just keep that it's it's buggy the support varies and stuff another thing the 802.1x wired on macOS X is buggy I haven't tried to reproduce it on in lion but it's it's definitely buggy we open a ticket with Apple and they they said send us a ton of logging and we did and we never hear back from them but we'll revalidate again on 10.7 but still the point is it's just that we're always finding problems in every you know pieces where we need to interact with and it's it's not an easy game to be network access control software what I learned also is a network vendor fragmentation so VLAN assignment to SNMP is done in like I don't know maybe 25 different ways they are port lists they are really straight one assignment so a lot of different weird stuff that you can see port security is named differently implemented differently SNMP access is inconsistent if you go into the radius-based enforcement then wired mac at nscation has many many names I think I have a few here where is it so Cisco calls it mac at nscation bypass or MAB HP calls it Mac based at nscation Nordel calls it NEAP which is not no EAP extreme networks calls it net login Juniper calls it mac radius so there's a lot of different stuff going on in that space and it's it's not making the anything easy for us there are gray areas in that 1x where you don't really have guarantees about what will go with the DHCP on the client and thus the problems probably with the mac osx the radius change of authorization is not supported everywhere which makes it a little bit harder too so really hard but the situation on the wireless side is better I guess they learned form the the wired side of things and they avoided a lot of mistakes so mac at nscation and 802.1x wireless is really great and we've been implementing really more easily the the the APs and the controller usually I don't know like one day to figure out how it works and make it work and another day to document the for our network administration guide and make additional tests to make sure that it will scale and everything so two days and we support a new controller brand so which is pretty good learn network vendors firmware quality so there are so many regressions and we like get client they update an iOS did I say iOS they upgrade a switch firmware and then boom something that used to work before stops working now and so it's really really painful weird coincidences I've saw the same exact bug implemented in like four different brands and I couldn't believe it I was like it's the same bug and it's an obscure bug and and so you see that there is probably a lot of you know of people buying code out of other vendors and stuff and a lot of reuse of the same code which unfortunately I guess is handled very differently because the bugs are fixed in one vendor but not the other one but it's obviously the same bug also something that happened with us is oh I think there's a bug in there and the vendor says oh right it doesn't work using the common line interface but it does work in the web GUI but who manages hundreds of devices using a web GUI aside from controllers which do a pretty good job but for switches come on this is really odd and scale issues I just wanted to to hint on an issue I faced where the people were handling in the SNMP they were handling the MAC addresses saw on the layer 2 in the same table as the MAC addresses secured on ports so when you want to list the secure MAC address on the switch if the layer 2 network is really large then you start to SNMP walk tens of thousands of devices and it makes the whole thing completely slower so we often face problems like that and that we just don't know what to do with that and then we rant on the network vendor and they say hey come on it's not us it's been working fine for most people but then you ask them do you have a MAC implemented with one of the MAC providers and they say no what's MAC so it's a problem I know some people aren't going to agree with this but all vendors hold tight on their issue trackers I'm talking network vendors again most they hold tight on their firmware so we have their customer pays us to implement MAC on their switch and we are having a hard time downloading their firmware this is not normal like we need to escalate and and send a lot of email they some of them even hold tight on their documentation so we got a physical switch that they sent us but we are having a hard time download the PDF to configure the set switch it's really really a problem and can it just stop you know opening your documentation opening your firmware has proven to be a good thing for like let's compare visual basic with PHP in the 95 days PHP all documentation was open so it got picked up by search engines and people who had problems had really really easy way to find solution but with the network control stuff the network vendors you google and you get almost never good answers and you get a lot of open-ended questions that are not answered so please come on they should get wikis and they should do it the open-source way it will make everyone's life easier and right now i think it's it's more penalizing their their customer who paid for their hardware the way they are working right now so i'm a little distressed by that okay um okay again learn nobody does infrastructure authentication which is a big security problem let's skip to that okay the bad thing we do with packet fans first installation step disable s c linux yep that's right we suck at s c linux we tried we just couldn't figure it out if someone wanted help it will be really appreciated we have two short release cycle for a core piece of infrastructure we like released 11 releases in the last year or so maybe and so it's really fast for most people we don't have an end map integration i really i i saw fiodore speak at defcon last year and i really am into end map but we still couldn't get help or time or you know customer mind share to implement end map so we've done not done it and i think it's bad uh external code contribution are scarce we're having a problem creating a good community probably because it's not sexy doing network access control uh it's really you know enterprise the infrastructure stuff which is really really not attracting a lot of developers and we're pretty much sent os uh rail uh for now but we're we want to fix that so what we've done that is good um we improved a lot on the last two years the development process in the infrastructure fully automated smoke tests we're packaging every night uh the the software builds yet there are new packages out and you can hook on a yum repository on the latest software uh our our branches are stable so we have a stable branch everything is public there is no like big code dumps like android where all every commit is public and on the internet so it's it's really a true open source project all that gpl by the way i don't think i i have this anywhere in my slide so it's all gpl uh based the license uh the code is usability plus plus we really work hard on simplifying the installation the upgrades if you've tried packet fans like two years ago give it another try because it really really changed a lot we got enterprise the new features so you can have users right for people using the web admin this way your help desk cannot screw up the whole system we support routed environments out of the box uh so this we inject automatically static routes and do the the dhcp config and all that stuff so we've been uh deploying a lot in campus based the environment where you know you need to route between the buildings and it works really really well and it was a appreciated feature 64 bit support we now have a fancy guest workflow support we've been working on that branch for a year and now we're about to merge it with with the upcoming 3.0 release we're going to do uh we improved performance in several occasions let's keep that technology we support web services to manage hardware we've been doing also web services for the radius access control so people could technically decouple the free radius let's say you keep your free radius on your camp per campus and then you do a soap request so web services request to the packet fan server so you could have technically uh distributed architecture like three-layer architecture but based on radius we also did packet fence in the cloud on ec2 the only thing you need locally is an open vpn and everything is tunneled so this was more as a fun hacking project that we did no one really wants to pay for that we realized uh because it's too scary you know to have network access in the cloud uh making in line and out of band work at the same time on the same server this is really new uh and we're releasing this with 3.0 so we'll be able to support uh old ancient hardware at the same time as uh vlan isolation and strong uh good technique uh this is really uh i think some interesting um feature how long do i have left two minutes okay i need to to bypass that i'm sorry so we did a proxy bypass client side proxy bypass really interesting read the slides if you want to see what i mean uh javascript network access detection we've worked on that too which uh is kind of a hack because i'm trying to avoid uh the cross domain origin policy uh stuff and uh it's it's kind of neat that's why i included here but let's skip that so short term we're going to do inline mode uh to support easier legacy network hardware now in beta so it's uh public uh already we want to do radius accounting bandwidth monitoring with the proper alarms for it so we could be more a hotel style network access control i guess we're looking into nap and statement of health client time checking radius change of authorization which we haven't do yet acl and qos assignment with radius uh a lot of my colleagues have been working on that we're now kind of unsure how we will present the interface to the user but we've got the the basic technology and technique working it's just more of how we will uh we will present the feature to the user we would like to support vpn so then we will be a really covering every access control techniques that we know about uh debian ebon to support of course longer term we we uh kind of hate uh the active passive approach for uh doing high availability we would prefer a simpler active active clustering approach so we'll be we're working on that and map open vs integration and making this stuff click next next next easy to install we're making progress uh with this with the 3.0 beta uh we'll be able to uh for the packet fan zen solution it will be dhcp based neck you plug in uh in the uh trunk port and it will mostly work for most people so we're really making progress uh with that and trying to make it easier all the time uh research topics so if people are really interested into more advanced stuff we want to implement if map uh we're looking at uh doing client side agent but we would like a multi-platform like python base maybe approach and stuff so uh yeah that's pretty much it we beg for help we want everyone to use packet fans if they can uh conclusion i hope i demystify knack for you guys and you should give packet fans a try if you manage the network because i think you'll see value quite uh quickly thank you very much see you in the briefing room