- This topic has 8 replies, 2 voices, and was last updated 5 years, 10 months ago by
.
-
Posts
-
- Total Post: 19
- Regular Joe
- ★★
Hi,
I am new to Wyse ThinOS deployments. We are tsting out the Dell Wyse 5060 with ThinOS 8.5_12. I was wondering if there is a way to REALLY lock down a WTOS device so that nobody else can use it.
Right now, my wnos.ini file has these settings (among others):
Privilege=None LockDown=Yes
AdminMode=Yes enc-username=<encrypted_username> enc-password=<encrypted_password>
That work’s fine an dandy, as long as the device uses the same DHCP and file server. However, one can easily get around this by hooking it up to another DHCP server that points to a different file server. I can literally direct connect a Windows Server with DHCP and ftp installed, to make it use another wnos.ini that has Privilge=High and AdminMode=No, and viola! I can access the WTOS device.
Am I missing something? Is there a real way to lock these devices down?
Thanks,
bigboss77
- Total Post: 19
- Regular Joe
- ★★
Hi Confgen,
Thanks but I am unclear how that would help. Couldn’t someone still be able to simply hook up the device to their network, use DHCP Option 161 to point to their file server (whether it be ftp, https or http) and use whatever settings in their wnos.ini that they wanted to?
Thanks,
bigboss77With Privilege=none you restrict access to the device. So no one can factory reset the client.
With switching to https and disabling unsecure protocols like ftp the device cannot access any other unsecure fileserver.
If you are using a self created certificate and delete all others, I do not see a way how this device should be used in any other network.CG
- Total Post: 19
- Regular Joe
- ★★
Is disabling unsecured protocols accomplished with this line?
SecurityPolicy=full SecuredNetworkProtocol=yes
“If you are using a self created certificate and delete all others, I do not see a way how this device should be used in any other network. ”
– Do the certs have to be self-signed? They cannot be issued by a CA?
thanks!
By self-signed I mean issued by your own CA and not an official, commercial one
Parameter looks good.
CG
- Total Post: 19
- Regular Joe
- ★★
Confgen,
Thank you for your suggesting. When I used the settings you described and disallowed USB storage (to prevent loading certs via USB), it worked like a champ!
The only bad thing came when upgrading the firmware. It was originally at 8.3.105 and the file server had 8.4.009. So here is what happened:
– Device was at ThinOS 8.3.105 (fresh out-the-box no config), booted up with DHCP and received config from file server, where it: loaded certs, set securitypolicy to full, disabled unsecured protocols, disallowed usb storage, lastly it found there was a new firmware (8.4.009)
– ThinOS 8.4.009 firmware loaded to device, then rebooted
– Certs were wiped out but other elements of the config were persistent, such as securitypolicy=full and disallowed usb storage
– Since certs were wiped after the upgrade, it would not communicate with the file server anymore, thus it could not pull down the very same config that instructed it to load certificates in the first place
So you see, I was stuck with a machine who did not have certs loaded (wiped from firmware upgrade), required secured communications (securednetworkprotocol=yes) and did not prompt for unverified certificates (securitypolicy=full).
The only way I got the device to work again was to re-image with the Merlin client.
Was there any other way around this? Or should I have locked it down differently?
It would have been best if the firmware upgrade simply wiped out EVERYTHING, including the configuration and certs, then upon reboot it would come up plain out-the-box no config. That way, it would easily reconfigure like new.
Add
FactoryDefault=yes
to your wnos.ini.This will reset a client after a firmware change.
CG
- Total Post: 19
- Regular Joe
- ★★
Ahhhh yes! Thank you!
- You must be logged in to reply to this topic.