9

For many years I've been careful on Wifi. I haven't know how to secure it properly, so it stayed on an isolated NIC of a good router with normal WPA2-PSK and full WAN access but no LAN access at all, and all was safe.

I'm moving to allow some WiFi, at least, into the LAN. I'll be using decent enterprise equipment (nothing that's left un-updated long), and the basic scheme is OpenWRT AP -> managed switch -> pfSense as router/security device (running RADIUS). AAA will include 802.1X + certs, and probably some use of VLANs (to be decided - the AP, switch and router all handle dynamic+private VLANs and the switch handles full IP/port/protocol ACLs as well). The exact config isn't yet decided, nor are the exact auth methods (cert + PW/other 2F?) or EAP method, but something along those lines.

I'm aware from general reading, of some of the more common warnings that apply to these security methods - validate certificates, don't allow VLAN tags to escape to client devices, generate and keep any self-signed root CA on an airgapped device and use intermediate CA+revocation lists for day to day use...

In theory it should be safe (I'm not at all comfortable with WPA-PSK2 alone as the guardian to my LAN), or certainly a lot safer than most other alternatives, but I like to test my work, not just assume it's done okay, and I'm aware that I'm not a security pro or a WiFi pro. I doubt I could learn enough in less than 5 - 10 years to provide any kind of reassurance by self-testing my WiFi security, though I'd certainly like to be able to do so.

What I would like to ask is - is there a good (automated) way to test if the WiFi is secure or "leaking"? Good security is hard, WiFi harder than most, and I'm not entirely sure I trust myself to test for or spot a weakness, if I hadn't done it right.

So I'd like to have some kind of basic or moderate penetration/vulnerability test approach I can use as a partial make-do.

It won't be the "full thing" because that needs human knowhow, but is there something (anything?) that covers the basics applicable to my scenario, and doesn't need much knowledge or is automated / "follow a recipe" to use it, and which will let me gain at least some level of reassurance over common WiFi/AAA vulnerabilities.

Update: criteria and definitions

As commented, the question needs a more specific defintion or criteria for "security". Some broad areas are easy to define:

  • Security aspects: I'm looking at one aspect - the perimeter security, as seen by a WLAN-based user. Not having implemented 802.1X or used VLANs in the context of infrastructure security before, it's easy to get something wrong. I might create a setup/config where I think it's all okay, but to someone with a little knowledge or a standard penetration testing toolkit, it's quickly clear that there's a weakness in the setup that suggests there could be an AAA bypass.

  • Risk exclusions: I can exclude several broad areas of attack for the purposes of this question, although they are crucially important in the bigger picture and make up some of the most exploited system vulnerabilities in practice. For example:

    I can exclude most endpoint issues (individual system+software vulnerabilities of the endpoint PCs and servers on the LAN, including PCs/laptops with their own Wifi cards on board), because those need securing/updating as it stands already, and are kept up to date. They are a "known" and unchanged by the proposed network alterations. I can exclude malicious piggybacking via attacks on user's wireless phones/laptops that are subsequently attached (correctly) to the LAN via Wifi. The endpoints already need to be kept up to date and protected as it is, and that's a different issue which I'm familiar with and already do what I can with. Those are important but at least I'm already clear what I need to do and can accomplish on them. I can exclude IOT wifi control issues. I don't have any IOT or wireless possessions other than phones/laptop and if I did, they wouldn't be allowed on the WiFi or LAN other than at most, totally isolated from the LAN at the router via dedicated NIC to reach the WAN only, which I'm comfortable doing. I can exclude egress traffic, monitoring of activity within the LAN interior itself. If they're already inside it's already too late and safeguarding has failed. I can exclude physical access issues (including non-consented connections to wired LAN ports). This is an attacker who has no physical access to the devices themselves, or to existing wired infrastructure. They are not in the house (or even if in the house do not have access to my infrastructure devices/cabling). Wired LAN ports in rooms where guests might visit have to be addressed anyway so this is a "known", and in any case LAN port misuse is a social issue (managing visitors) as much as anything. I'm also not looking at an attacker who has other knowledge beyond what can be gained from a "cold start". For example, the hypothetical attacker has not used social media or social engineering to gain useful knowledge about the system or to build a list of possible passwords, and is not someone previously invited into the house and granted some LAN access, who has an old password or certificate to hand.

  • Documented weaknesses/vuls affecting wireless/wired infrastructure, access points and AAA (including Wifi APs, LAN networking, FreeRADIUS, and/or other common AAA infrastructure). For example, checking if WPA2-PSK is used and the wifi vulnerable to KRACK, or (hypothetically) suppose that there was a well known weakness in some switches, that caused packets, including those that are superficially AAA related, not to be correctly routed onto the expected VLANs. CSV is included but I'm more concerned about what might be called setup/design/implementation weaknesses than CSV since CSV can mostly be handled by update management as far as anyone can manage it.

  • Implementation flaws/weaknesses, including "well known" infrastructural/design issues/flaws and common config flaws/weaknesses/oversights are very definitely included. This includes issues caused by common misconfiguration/exploitable configuration weaknesses - what one might broadly call implementation issues/weaknesses. (Without narrowing it down, examples off the top of my head might include, the user has forgotten to configure AAA to validate certs, or has accidentally connected their VLANs in a way that one seems to be able to reach IPs that don't seem to be the correct AAA devices, and might be endpoints or unintended interfaces rather than the correct AAA systems, or is using known-weak algorithm choices.) To an extent, this is almost the primary issue

  • Hypothetical attacker's motive + skillset: My hypothetical attacker is not a hardened targeting attacker (NSA or someone determined to break into this specific system with a high level of skill/resources), but isn't a flyby or clueless "road warrior/botnet script kiddie" either. They have some moderate but non-InfoSec-professional-level skill (vague I know!) and some interest in penetrating this system, but will leave off fairly readily if it's clearly not going anywhere and there's no obvious way in, after a while of trying. They are comfortable throwing quite a range of usual/automated probes/toolkits/scripts/sniffers at the system, to see if RADIUS authentication can be bypassed or fooled, the trusted vs. untrusted VLANs jumped across, ACLs accidentally allow connection to localhost or other IPs they shouldn't, an SSID/BSID has been left incompletely or unsafely configured, the certificates can somehow be leveraged, some kind of chink left which allows them ingress, or whether there's a classical misconfiguration or failure to do something that would be a green light to a penetration tester, and which signals that there's good reason to believe the perimeter can be breached with a bit of work.

Put another way, the hypothetical attacker will throw a fairly broad or decent subset of decent automated penetration testing toolkits at the wifi from a nearby house or car, and sniff the airwaves for network traffic, and see if any of this pops up a "you have a vulnerability" message that might signal a way in past AAA and make it worth further attention. (They have the basic knowhow to do this, but not the knowhow or motivation to spend weeks crafting a targeted attack or putting endless resources into this one system.)

They might also try exploring whatever aspects of the LAN AAA setup are exposed by the wifi or its clients, to see what information can be gathered and see if any of that suggests it's weak. If a weakness arises then the wifi gets more attention, if after a while of trying, still nothing obvious is evident, then they will finally move on.

What I'm looking for, then, is almost the flip side of this:

As a non-professional without specialist experience in InfoSec tools and lacking a lot of the experience people might take for granted on *nix platforms, there will be a natural limit to what I can accomplish in the way of self-assurance. I'd expect to be good at interpreting output, but I might not know enough to use the in-depth tools and CLI approaches a pro would use. A toolkit (or more than one) would help.

Essentially it's the same difference as using CLI and knowing what packets to craft, or probing using Kali, vs. using nmap, if probing a network and its ports. For a security non-pro, nmap's automated scans and their options offer a fairly comprehensive starting point for a range of useful device scanning, and will covers a lot of ground in depth (exposures and what they might reveal of the device) which they wouldn't really be able to obtain without it. Whereas Kali would not be a good choice - it's much more powerful but requires much more in-depth knowledge, as a professional's tool of choice.

I imagine that when a professional does a non-physical penetration test, the starting point is a bunch of tools used to gather information about the LAN and its Wifi, how AAA is set up, any SSID names/IPs/package info/other information that is straightforward to gather, port scans, known CVE issues detectable/exploitable from outside, and so on. I imagine that the toolkits available can test for a wide range of information and known weaknesses, and a pen tester will use these as a time saving starting point for their work (their time is valuable). An attacker using these might see there is nothing obvious, or see something reported that suggests there is benefit in attacking further.

So the flip side is, what tools, toolkits, or combination of toolkits, could I as a non-pro use, to essentially probe my own WLAN and get a useful and moderately comprehensive sense of whether its wifi boundary and AAA setup (including those parts of the LAN which provide AAA services or carry/route untrusted pre-auth traffic if any) has such vulnerabilities, and (if so) what they are? Are there tools/toolkits designed for penetration testing, that I might find accessible and which will tell me if a pro would find a suggestive evidence from automated tools, that indicates an AAA/WLAN weakness?

I'm fairly sure I could interpret tool output - that shouldn't be a problem - and I'm comfortable learning enough to run a range of tools, but some tools may require a depth of knowledge and interpretation to use in the first place, to such a point that they aren't really usable other than by security pros (I might not get the appropriate information from them becaue I didn't really understand how to configure the tool for use or they needed considerable human input to guide their use), compared to others that might be quite capable and comprehensive but not need quite the same depth of knowhow to be operated.

If more is needed, let me know.

Stilez
  • 1,664
  • 8
  • 13
  • When it comes to a number of things, including networking, the important part of calling something "secure" is really about the definition. If you want a perfectly secure PC, disconnect it from everything, put it in a lead box, encase the box in 10' of concrete and bury it 100' underground. That PC won't be hacked, can't be exploited and won't leak any information. But it also won't be usable, and usability and security are typically at odds with each other. The issue with asking "if the WiFi is secure" is that we don't know your definition of secure. Your secure may not be my secure. – YLearn Dec 12 '17 at 20:52
  • 1
    @YLearn He does say against any common wifi/aaa vulnerability. Could be defined as any wifi exploit that has a CVE entry. – cybernard Dec 13 '17 at 00:25
  • @cybernard, could be. Could also be defined under any other set of requirements. The point is without the OP telling us what the security requirements are for the environment, there is no way someone can provide an answer that answers the OP's specific question. – YLearn Dec 13 '17 at 00:32
  • See update above, and thank you both for the helpful comments and positive approach. I've tried to be specific. Let me know if more is needed. – Stilez Dec 13 '17 at 09:29
  • When it comes down to it, a bunch of radio waves whizzing back and forth don't have a vulnerability. It's the endpoints that have the vulnerabilities. – Simon B Dec 13 '17 at 10:59
  • By "endpoints" I'm meaning the end-user devices (PCs, file servers) as opposed to the infrastructure (AP, router, USM, switches), if that helps. Its the wifi+AAA infrastructure I'd be adding, rather than users' own devices, file servers, IOT and physical network/device access, that I'm considering for risks, and the risks I'm looking at are those accessible to a WLAN-using opponent. If that's unhelpful terminology please say - I'll edit the Q. – Stilez Dec 13 '17 at 11:11
  • https://security.stackexchange.com/questions/20219/preventing-deauthentication-attacks#20226 This answer is pretty comprehensive (and contains further links), but it doesn't include a note about preventing de-auth attacks via router firmware. Cisco Meraki, for example, have a facility to detect deauthentication attacks, and ignore those packets. Other manufacturers also. –  Mar 22 '18 at 08:37

1 Answers1

2

Based on your question, and the thoroughness of it, I'd say you're actually pretty safe.

You seem to already be doing everything you should be, and most drive-by hackers will see Enterprise Level WPA2, and move on to your neighbor who doesn't have that.

That being said, if you want to see what they see, I'd boot into a Live CD of Kali Linux, and follow some WiFi hacking guides to see if YOU can hack your own WiFi. I know you mentioned Kali as being beyond what you're comfortable with, but based on your question, and what you've already done, I think that you'll be OK. And there are may guides that have step-by-step instructions.

You can also check your neighbors' WiFi to see if they would end up being a better target for would be hackers, (I shouldn't have to say this, but don't hack them.) low hanging fruit that is not you, is a very good deterrent.

You can also monitor your logs (for example, you could find a guide to setup an automatic email when someone connects to your WiFi. You are using pfSense after all), and if a WiFi level breach does happen, you can probably shut it down before they breach your firewall. (If they're even interested in that once they get internet access.)

Again, I wouldn't worry too much. You seem to have a better grasp of security than the average person, and you're doing all the right things.