Hi. Can i disable write and rewright access with external programmer to main SPI flash of my Zyxel gs1900-8? What will be the consequences? Can openwrt work in this configuration?
I want to store system logs on external USB flash drive.
The short answer is 'no'.
--
The long answer involves, 'it depends' - on your development/ hardware abilities, as well as what exactly you want to end up with, other than a brick.
I want to protect the configured openwrt configuration from unauthorized modification
Whatever you do, with a 1-dollar usb2serial adapter/ spi reader, a Philips head screw driver and a paperclip I will have full access, regardless of what you do (other than employing physical security, like casting it in concrete or putting it behind solid steel bars).
dreaming is not bad
You could remount the overlay read-only, I guess, through /etc/rc.local e.g. That would effectively protect the configuration, until someone can get their hands on the device and get it into failsafe mode. Then all bets are off again.
1 Like
It all depends on what you would like to protect it from - accidental modifications? Unauthorized access from the network? Unauthorized physical access?
A sane VLAN configuration should protect you from most unauthorized access situations of your users, a good backup strategy from accidental modifications.
And physical security is yet another topic - maybe a good lock? 
1 Like
I want to protect it from unauthorized access from the network and physical access
You can implement a radius server and 802.1x authentication.
A well secured room and/or physical enclosure is the way to do this.
1 Like
I would isolate all management interfaces in their own VLAN and do not give regular users access to this VLAN. This way, they cannot connect to the switch in the first place. As an additional layer of security, the web and ssh interfaces are password protected.
2 Likes
I'm planning to do it and give SSH and WEB access only to one port. But i start reading about U-boot and found many vulnerabilities that can change configuration of OpenWRT. I don't have enough knowledge to set up and compile U-boot. Therefore, I decided to try to limit access to SPI flash memory.
U-Boot is a boot loader. Once the system has booted, it is not active anymore.
Restricting access to U-Boot is IMHO physical security and it is much easier to accomplish with a locked enclosure than with a modification of U-Boot.
1 Like
This will be work only for first "bad" boot and i don't think so that you want always unconnect your rj45 when booting.
loader can be paused
and can give shell to flash SPI
Please correct me if I'm wrong, but as far as I remember, the GS1900 series does not enable network during U-Boot. And even if it does, TFTP and/or shell access is not available over the network.
I'm do not known
At this step i need to know - will openwrt work without write access?
It might, it might not. But if it doesn't you've got a really good chance with ending up with a brick. Is it really worth the risk for something which will have absolutely zero real world impact on security?
I risk more when I install the outdated 2015 bootloader on my device.
What do you think the risk is here? You would need physical access to the device to do anything malicious through the bootloader. And if it gets to that point there's plenty of other ways a malicious actor could interfere with/access your network.
1 Like
No, it's not. If the light turns off or an interference or power surge arrives at the power supply, the power supply will go into protection and the device will reboot. And I think the bootloader can be manipulated through rj45.
For example - https://www.cvedetails.com/vulnerability-list/vendor_id-18843/product_id-48033/Denx-U-boot.html
U can see it in "Remote" colum
Write disable via external programmer is a neat solution to protect u-boot and firmware
If you've got an attacker who has enough knowledge of the power status of your device to know when it's rebooting, and is ready to go with an attack, then you have bigger problems already...
You might think that, but you'd be wrong. Perhaps, before running a decent risk of bricking your device, why not do some testing to see if there is any network functionality prior to the point you can interrupt the bootloader? Or network access after you've interrupted, but not run any commands to enable the network?
1 Like