lainchan / sec

(untitled)

Otto Normalverbraucher · 2017-09-21 03:11
So I'm moving into a new apartment in a month. It'll be my first time living not with roommates, so I have more flexibility than before on how to run my network. What do you guys recommend regarding /sec/? WAN-facing I've always run pfsense (as a router, DHCP server, recursive DNS, firewall, and probably a bunch of other stuff I'm forgetting) on an old PC with dual NICs. Should I invest in some hardware and run an IDS (Snort?), or will nothing interesting come of this? Regarding WLAN, is WPA2 + long passphrase sufficient security? Is running a hidden SSID helpful or just placebo? Is there an IDS-like solution for wireless situations? Noticing when some skid in the building starts pumping out deauths would be interesting. Before you ask about my threat model: This is mostly about people within wireless range (interesting stuff happens when you pack in a few hundred people into a building) and the usual Chinese scanning residential ranges for open ports. But mostly cause I find this stuff interesting.
Technician · 2017-09-21 18:57
>>2762 >It'll be my first time living not with roommates, You'll have a lot more /sec/ fun *with* housemates. Especially if you don't like them. >WAN-facing I've always run pfsense... Sounds like you have that covered. >is WPA2 + long passphrase sufficient security Hashcat is a popular tool for cracking WPA. Look up some recent benchmarks to figure out how long you need to make the password. https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 >Is running a hidden SSID helpful or just placebo I think that all it does is send a message that you are concerned about security and you are probably not low hanging fruit. I think that opportunistic attackers (those not targeting you specifically) are more likely to leave you alone because if the SSID is hidden then you probably also have a non-default password and no WPS. It won't make a difference to someone who is out to get you though. >Noticing when some skid in the building starts pumping out deauths would be interesting. You'll notice by virtue of your WiFi not working lol. Sorry, you probably mean finding attacks on other networks. That's an interesting question, I don't know if there are any tools like that.
Eldon Tyrell · 2017-09-22 16:36
>Should I invest in some hardware and run an IDS (Snort?) PfSense has a Snort package available for download in their repository.
Marly Krushkhova · 2017-09-22 19:13
Hidden SSID is indeed placebo. The access point reports blank name, but it is still there. Whole WiFi "security" is done through obscurity. For real security, I'd suggest you changing long passphrase every day and have some sort of client-router tunnel like ipsec. Another problem: Google and other companies try to map all wifi access points around the globe, with their google street cars and smartphone malware. When average smartphone connects to wifi point, it estimates it's coordinates from GPS and sends them to Google. Worst thing is that anyone can access their databases and just by knowing your home wifi BSSID get your position pretty accurately. Think of all browser exploits that won't help you even if you have a tunnel running on your pfsence box. So, here is the tip: randomize the MAC address of your access point too. IDS is not needed when you don't now what you are doing, and if you are owned, you are owned. Honeypots for research purpose on the other hand, are sometimes useful, but I doubt you will be spending time trying to convince Chinese scanners that you have a smart bulb with open telnet port on your network in order to reverse-engineer their malware. Also, close all ports if you don't plan on accessing your system from outside, set a certificate-based ssh or vpn access with fail2ban otherwise.
Netrunner · 2017-09-28 04:16
>is WPA2 + long passphrase sufficient security A 6-word diceware passphrase is still secure (80-bit of security + WPA key derivation overhead) today, here's some more points to note. WPS The so-called Wi-Fi Protected Setup uses a 8-digit number to "protect" your Wi-Fi access point by default. You need to kill WPS altogether, though this days it is unsupported by default. SSID Name Fun fact, WPA uses your SSID as a salt of the hash function, append some random characters to your SSID can frustrate rainbow table attacks, but doesn't really matter if you use a secure passphrase. No PFS The real problem of personal Wi-Fi is the lack of perfect forward secrecy. WPA does use a session key and periodically rekeys, but all the key exchanges are protected by the single PSK passphrase, epic fail. If a passive attacker can wiretap (wirelesstap?) all your key exchanges, and managed to gain access to your passphrase later, all communications can be decrypted. Considering the single PSK is used on multiple devices, especially smartphones if you use one, it is relatively easy for a 3rd party to steal the passphrase. Depending on your threat model, this may or may not be a problem. Ironically, the insecure WPS does use Diffie-Hellman to provide perfect forward secrecy. The standard defense is using WPA Enterprise in a EAP mode (https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol) protected by TLS. But it is basically a disaster, extremely complicated to set up, incorporating all the best practices is even harder. For example, even if you configured everything, CA certificate is still not verified by default on some platforms. Actually It is not supposed to be hard at all. If we use TLS with ECDHE-PSK cipher to protect the Wi-Fi, we can get all the security TLS provides and use shared passphrase to authenticate as usual, but it is not supported by major platforms although we have a RFC. Hence I recommend to use a non-standard but much easier solution here: installing a secure VPN on your gateway, and always connected to your VPN. IPsec for your network is also a good option but harder to configure. DEAUTH attack This is probably the biggest threat and we don't actually have a solution... There's a type of packet, "deauth", defined by 802.11. It is used to indicate the client has already been deauthenticated by the access point for some reason. Unfortunately, this packet is unauthenticated and anyone can craft one. It is used to force you to start a fresh encrypted handshake to allow the attacker to capture and crack it later, or simply launching Denial-of-Service attack to render your Internet connection useless. 802.11w was meant to add authenticate for these packets. But AFAIK, because of the proprietary Wi-Fi drivers and firmware, it is not possible for the developers to support it at all. It only works best on Linux kernel with ath9k driver. If your access point do use Linux and ath9k (you probably want two of them for your AP and laptop), you can turn it on and set it as optional, thus supported devices can make use of it. If somebody decides to kick you out and you don't have a chance to use 802.11w, turning off WPA encryption completely and use your VPN exclusively (+ drops non-VPN packets) can be a solution, or simply plug in the wire.
Switch · 2017-09-28 04:24
In addition, if you use WPA/WPA2, don't forget to disable TKIP and enforce CCMP-only (AES) encryption. TKIP is RC4, TKIP is vulnerable. All Your Biases Belong to Us: Breaking RC4 in WPA-TKIP and TLS https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/vanhoef
Switch · 2017-09-29 18:09
>>2774 >>2782 >>2852 All good feedback, thanks guys, much appreciated. I'll update if I end up building anything interesting.
Masami Eiri · 2017-10-03 00:55
>>2762 Fun fact, having a hidden SSID for a router has unintended consequences. Say you have a router and a cell phone. With a broadcasting SSID, your phone simply looks for the name when examining the networks around it. With a hidden SSID, your router no longer broadcasts the name, so now your phone broadcasts out a specific packet including the SSID name of the router its looking for until pinged back.
Undisclosed · 2017-10-03 17:47
>>2874 Clients send probe requests regardless of whether the Access Point is broadcasting the SSID or not. This is an established method of finding hidden SSIDs though.