Tiny Core Linux

Tiny Core Extensions => TCE Q&A Forum => Topic started by: nitram on January 20, 2015, 09:51:04 PM

Title: wifi.tcz security concerns...
Post by: nitram on January 20, 2015, 09:51:04 PM
New TC-6 user here. Just installed wifi.tcz, runs well.

- After connecting wifi saves the ESSID and password in a plain text wifi.db file in the home folder. This happens to be my secured home router and i would prefer that this information NOT be stored in plain text on my system. Anyone know how to disable the wifi.db text creation, as i would prefer to re-enter my password manually at boot.

- This query is likely not possible with wifi, but i prefer my wireless router NOT broadcast an ESSID (hidden network). Is there anyway for wifi to pick up a hidden network?

Thanks in advance for any feedback.
Title: Re: wifi.tcz security concerns...
Post by: Juanito on January 20, 2015, 10:06:08 PM
At the moment the wifi extension will not connect to networks that do not broadcast the ssid - if you'd like to propose a change to the script, please feel free  :)
Title: Re: wifi.tcz security concerns...
Post by: coreplayer2 on January 21, 2015, 12:19:54 AM
Is this really a security concern?  Or a matter of comfort?
Anyone who had access to the file system is already inside your local network.  iptables should be enough protection from casual exploits. Anyone smart enough to access you password is most likely not living within reach of your WiFi range. So it appears a moot point?

If it's that important then perhaps a more secure connection manager would be appropriate?  Would be cool to encrypt the password file, though seems to much like overkill for the threat posed..?

Sent from my iPad using Tapatalk HD
Title: Re: wifi.tcz security concerns...
Post by: nitram on January 21, 2015, 12:44:20 AM
Juanito - A script change would be great but i've already bugged bmarkus enough this week and i don't have the necessary skills to figure this stuff out yet.

coreplayer2 - Thanks for the response. Both a matter of comfort but also a bonafide security concern. Of course someone who hacks your wifi already has access to your local network anyway - understood. But having plain text network connection information in a home folder seems like asking for trouble if a laptop is ever lost/stolen and recovered by someone nefarious. Upon realizing the theft i would change the network ID/password asap so maybe you're right, maybe i am making more out of it than necessary.

Guess i'm just used to a more secure system (no network broadcast, encrypted connection information, no sudo, very restrictive root user usage, etc). I can see how TC can be more secure in many use cases (run from RAM, fresh system at every boot, etc) but in some ways maybe less secure. I'm still trying to figure out the system and need to read up on TC security.

Since my wifi.db file is stored in the home folder and is backed up upon exit into mydata.tgz, is there a way to automatically password protect this tgz file to prevent someone from unzipping?

Or...if i'm that paranoid, maybe just manually delete the wifi.db file before exit/backup if i plan to take the laptop out of the house.
Title: Re: wifi.tcz security concerns...
Post by: curaga on January 21, 2015, 01:33:31 AM
Yes, the "protect" bootcode will enable 448-bit Blowfish encryption for your backup file.
Title: Re: wifi.tcz security concerns...
Post by: core-user on January 21, 2015, 02:13:05 AM
Maybe just write a script to delete it after connecting to your wifi(?)
(Run from ram probably easier.)
List it not to be backed up in /opt/.xfiletool.lst(?)
Title: Re: wifi.tcz security concerns...
Post by: Lee on January 21, 2015, 07:01:37 AM
Or...if i'm that paranoid, maybe just manually delete the wifi.db file before exit/backup if i plan to take the laptop out of the house.

To exclude the file from you backup, add it to /opt/.xfiletool.lst

Of course you would then get the worst of both worlds - the passwords would exist as plain text in your home directory (while running) -AND- you'd have to reenter it on every reboot to access your wifi.   But, assuming you're not using persistent home, at least it wouldn't exist on your persistent media.

Title: Re: wifi.tcz security concerns...
Post by: nitram on January 21, 2015, 09:59:46 PM
Thanks everyone for the reponses. I will for sure look at the protect boot code, which addresses my security concern regarding the plain text wifi.db file.  xfiletool.lst is also valuable.

Tried a wifi work-around that failed. I set my router to broadcast, booted TC and connected via wifi.sh. My router's ID and connection password stored in wifi.db as expected. I then reset my router to hidden (no broadcast), rebooted TC with persistence so it could read the wifi.db file and then ran sudo wifi.sh -a, which is supposed to instruct wifi to automatically connect to the first network in wifi.db. Unfortunately it failed:

Code: [Select]
tc@box:~$ sudo wifi.sh -a
Found wifi device eth1
Standby for scan of available networks...
Set to try a few times to obtain a lease.
Attempting auto connection with nitramRouter
Error for wireless request "Set ESSID" (8B1A) :
    too few arguments.
udhcpc (v1.22.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing

If you've got your ears on bmarkus, is there any possibility of enhancing wifi.tcz to connect to a known hidden network? This is a deal breaker for me as i really don't want to run in broadcast mode. This netbook dual boots with Debian and has no difficulty connecting to hidden networks but uses heavy overhead network-manager. I work from a home office and make all reasonable attempts to protect my data.

Unfortunately wicd.tcz in TC-6 is broken. Any other ideas to help me wireless connect to a known hidden router? Maybe some network interfaces tweak or something? I basically just use the same/single connection and the netbook rarely leaves the house - just need to successfully connect to my hidden network.
Title: Re: wifi.tcz security concerns...
Post by: Juanito on January 21, 2015, 10:07:56 PM
you just need a simple script:
Code: [Select]
#!/bin/sh -e
sudo cp /mnt/sdb1/conf/wpa_hiddenssid_configure.conf /etc/wpa_configure.conf
tce-load -i firmware_iwlwifi-7260
tce-load -i wpa_supplicant
sleep 2
sudo wpa_supplicant -B -Dwext -i wlan0 -c/etc/wpa_configure.conf
sudo udhcpc -b -i wlan0 -x hostname:boxdell -p /var/run/udhcpc.wlan0.pid

Code: [Select]
$ cat /etc/wpa_configure.conf

Title: Re: wifi.tcz security concerns...
Post by: Greg Erskine on January 21, 2015, 10:41:01 PM
hi nitram,

I too don't like to have my wireless network passphrase in plain text in any file.

You can just use wpa_supplicant.


It will allow you to use an encrypted passphrase and use a hidden ssid.

# sudo wpa_passphrase ESSID PASSWORD

generates passphrase
EDIT: Took me a while to write...what he said.

Title: Re: wifi.tcz security concerns...
Post by: nitram on January 23, 2015, 06:32:30 PM
Thanks for the responses. I've been reading up on wpa_supplicant, read through the Juanito's sample script and tried to better understand the wifi.sh script. My script and programming abilities are almost nil, so a challenge. Spent some time working on it last night and hope to try again this weekend. Simple for you guys, not for me (says with a jealous grin).

So far i've just been able to make a network contact attempt, but no successful ping. To learn in baby steps, i plan to temporarily disable my router's wireless security and no-broadcast settings, establish a connection manually though wpa_supplicant and build on small successes.

Don't have my netbook available at the moment, but when wifi.sh connects wirelessly it's through eth1 (NOT wlan0)....and no DSL cable is plugged in/just wireless. Is this common for a TC wireless device? Just wondering, wifi connects and works great but that leads me to believe my wpa_supplicant commands/script should be based on eth1 ?
Title: Re: wifi.tcz security concerns...
Post by: Juanito on January 23, 2015, 08:32:17 PM
Some hardware (for example, broadcom) uses eth1 rather than the more usual wlan0.
Title: Re: wifi.tcz security concerns...
Post by: nitram on January 23, 2015, 09:06:27 PM
Juanito - you are a true forum Hero Member - broadcom - you guessed it.

Success! Couple wpa_supplicant related commands via eth1, a simplified config file and i was able to connect to a WPA2 secured but visible/not hidden network. Now just need to test for a hidden network and read up on disconnect commands.

TC is amazing - never forced to work at this level with a computer before. If i have further issues will post back. Thanks all for your help.
Title: Re: wifi.tcz security concerns...
Post by: Juanito on January 23, 2015, 09:22:23 PM
Good  :)

The example wpa_supplicant config file above is for a wap that does not broadcast the ssid.
Title: Re: wifi.tcz security concerns...
Post by: nitram on January 27, 2015, 11:41:20 AM
Got hidden wireless working via wpa_supplicant just the way i like. Tested for a few days to ensure all is good. Just posting my notes, which may help others since wicd.tcz is broken and wifi.tcz does not presently connect to hidden networks.

Here's a primer, which i discovered after the fact. Didn't read through in detail but it looks relevant:

Here's what worked for my hidden WPA2 wireless on an HP Mini 110 netbook running TC-6:
- blacklist at boot via grub2 kernel line: blacklist=b43 blacklist=ssb
- OnBoot install wifi.tcz, which brings in wpa_supplicant
- OnBoot install wl-modules-3.16.6-tinycore.tcz, which also brings in wireless tools
- temporarily disable hidden feature from wireless router and reboot (SSID will no longer be hidden to world)
- via terminal run wpa_passphrase SSID PASSWORD (your router's SSID and connect password), which outputs a configuration
- copy/paste this configuration into a text file and name the file something like wpa_supplicant_hidden.conf
- needed to add a few lines to the config (see below)
- added wpa_supplicant command in /opt/bootlocal.sh to automagically connect to my router at boot
- reboot and test network
- if all good then re-enable hidden network in router, reboot and test again
- in terminal run iwconfig to confirm connection to correct SSID
- in terminal run ping -c5 google.com to test connection
- in my experience a cold boot (full poweroff) is best when re-testing router and networking
- if i want to use public wifi, then just comment out ( # ) the wpa_supplicant command in /opt/bootlocal.sh, reboot and use wifi.sh to connect

Here's my wpa_supplicant_hidden.conf file, which i placed in my home folder for convenience:
Code: [Select]
# reading passphrase from stdin



Here's my /opt/bootlocal.sh file for autostart at boot, which is also set to autostart iptables firewall. Make sure the pathway to the configuration file is accurate.
Code: [Select]
# put other system startup commands here
/usr/local/sbin/basic-firewall noprompt &
wpa_supplicant -Dwext -i eth1 -c/home/tc/wpa_supplicant_hidden.conf

Thanks to all that helped out and pointed me in the right direction. Hopefully i didn't miss any steps.

Title: Re: wifi.tcz security concerns...
Post by: coreplayer2 on January 27, 2015, 03:40:32 PM
nitram  I hope you find this myth debunking article interesting.. 

Hiding your SSID serves no useful purpose. As seen in this thread it only makes the task of connecting more difficult for the legitimate user.  with almost any wifi tool a hidden SSID is always instantly discoverable,  see here
http://www.howtogeek.com/howto/28653/debunking-myths-is-hiding-your-wireless-ssid-really-more-secure/ (http://www.howtogeek.com/howto/28653/debunking-myths-is-hiding-your-wireless-ssid-really-more-secure/)

I'd go so far as to say there is no such thing as a totally secure WiFi,  I think WiFi security falls into two categories,  the easy to access and the more difficult to access.  Ideally we want our WiFi networks to fall into the more difficult category such as with WPA2 + a strong pass-phrase.  No other feature is going to help here.

Title: Re: wifi.tcz security concerns...
Post by: centralware on January 27, 2015, 10:50:19 PM
I have to second with coreplayer2.

Imagine a limo driver at the airport holding a sign with your name on it.  This is SSID-Broadcast.  Take away the broadcast and you have a limo driver (he stands out in his penguin suit) and he's holding a sign...  it's just being held down so you can't see the words on it.  For those out there who are curious, they look to "find" ways to read it.

Your router, access point(s), etc. all communicate on a set number of channels within a set bandwidth (ghz) so it's somewhat easy to tell if there's a limo driver within range just by "listening."  Once you've filtered out all of the communication noise from "known" drivers, all that's left is yours.  If you're using the router while it's being scanned, it makes it that much easier to track down, localize and in many cases, just by "listening" you can determine the channel(s), and if you nab the packets you might even be able to grab the router's identifier (similar to a MAC address.)

I've tried planting decoy routers (broadcasting) to help mask our hidden ones...  nada.  I've tried implementing decoys which were not broadcasting, but just trying to send junk to a non-existent set of machines or to one-another...  they get picked on more than my broadcasting decoys.

The only solid plan we came up with was to dual-firewall and dual-router.

Router #1 is the WAN.  One LAN port on Router #1 connects to one LAN port on Router 2.
Both routers have the ability of IP banning.

On the firewall side, we have a set of baby-sitter scripts for if/when someone breaches a router.  The first thing someone wants to do is scan the network, so we have decoy ports/daemons open who are waiting for connections.  As soon as someone attempts to connect to port X on one of the baby-sitters, the IP is sent to the routers and access is dropped.  (Inside the network and out.)  Mind you, these are Cisco servers which have been revamped to serve this purpose, both having dual GBe network interfaces and wireless cards which support access points.  The "WAN" is an old Cisco router (3600 series, I think) which guards the front door.
     With all that in play, we have drive-by idiots still hitting the front (WAN) and back (WiFi) doors every day.  In my opinion, this is the best wireless protection (and still probably not bullet-proof) but I don't know of any retail side wireless routers which consider those problems, let alone have the ability to ban folks in this fashion.

I haven't tried it yet, but TC might help make this a feasible option!!  Gigabit (GBe) network cards are quite cheap these days.  An old motherboard suited with a pair of network cards (or a dual card like we use here) and a wireless card (with AP mode) could easily replace a physical router, you launch IPtables (mangle) to create a router/forwarder/NAT and add DHCP/DNS (dnsmasq) and you're literally in control of what you're protecting without the weight of a main-stream OS.  Fast...  Small (software)...  Versatile...  even on an older 5x86 machine.

My main workstations don't require firewall software running thanks to this setup (if someone were accessing through the LAN...  they're already inside...  and if they already know the decoy concept, odds are they don't work here anymore! :) )
Title: Re: wifi.tcz security concerns...
Post by: nitram on January 29, 2015, 10:50:27 AM
Thanks for the feedback coreplayer2 and centralware. The article and article comments were informative. You two are way ahead of the curve with wireless security. There's still a part of me that prefers my wireless to remain hidden. My vehicle has a good alarm and anti-theft system but i still prefer to park it out of sight in the garage.

The linked article comments have valid arguments for and against. These comments summarize my thoughts on this:
The fact that someone has to be running specific software within a broadcast range of a client in order to even know that said WiFi exists is a bonus security feature for me. I don't mind a few extra steps when I only have to set it up once. I know it's not literally more secure, however it is relatively more secure.

Guys, hiding your SSID just isn't worth it so the article is quite correct. No bull here. It's as useful as hiding a Sherman tank with a napkin. You are just making life more difficult. People just love doing outdated stuff just cos it makes them feel more 'Tech'.

...and response:
No, it's like hiding a Sherman tank with a cloaking device. You will have to install an infrared scope and search in the right area to realize it exists.

Questions i plan to google, unless someone knows off-hand. Can a hidden wireless signal be sniffed if the wireless router is turned on but all wireless devices are powered off? What about if the router and laptop are both turned on but no data is actively being sent back/forth? My router stats typically show 99% inactive, probably typical for home users that minimize streaming and large downloads.

Closing in on tinfoil hat territory. Hidden or not, i take more precautions than most and probably don't have much to worry about:
- WPA2 security
- strong password
- periodically change password
- confirm SSID connection
- disable network manager auto-connect features
- turn off computers when not in use (no 24/7 type systems)
- turn off router at night and when leaving the house
Title: Re: wifi.tcz security concerns...
Post by: centralware on January 29, 2015, 04:30:50 PM
Router on + wifi devices off -- generally speaking, the broadcast would have been the only real activity.  As long as your router isn't set up with WDS, there shouldn't be enough of anything to focus in on to sniff the router, so the only other way to detect the router would be with a wireless hardware scanner (A physical device which scans the 2.xGhz range looking for devices with antennas - there may not be any bandwidth traffic to sniff, but it WILL show an active radio device.  I imagine with some decent amount of work a computer could be made to do the same job, but that's likely a lot of work.)

Router on + device on, but no "user use" -- Based on the operating system validating its connection every so often AND based on key expiration, there is still going to be use even when not in Network use between the two devices.  You can set the device's wireless power savings to maximum to reduce the validation, and set your key expiration to a high value, but this doesn't mute it - only reduces its frequency.  Reducing validation should be done when screen savers (idle) are launched, otherwise it'll also likely interfere with your active use.  Note also your DEVICES themselves are also "detectable" as their radios are also turned on.
Title: Re: wifi.tcz security concerns...
Post by: nitram on January 29, 2015, 08:07:25 PM
Enlightening -thanks very much for sharing that knowledge centralware.