Add a way to set timezone, or instructions on how to set timezone

[GaryTest2014]

Could you add a way to add the timezone to the running instance of ShredOS, or provide instructions on the best way to add the correct timezone to the image file?

The log files show the correct time in UTC, and if I go to a terminal window I see the correct time in UTC, but I would like to be able to set it to my local timezone.

Thank you!

[PartialVolume]

Yes, I'll look into that. It would make sense to be able to edit the kernel command line to set the timezone.

[Firminator]

...or preferably into a config file that we can save on the flash drive. Or alternatively from an internal NTP server which most big corporate network, universities, K12 institutions, and even most consumer WLAN routers have setup. Ideally you set the time correct in the BIOS or UEFI in UTC and then adjust the timezone from within ShredOS.

In other words adding for example automatic timezone adjustment based on GeoIP and querying an internet NTP pool would be counterproductive.

Although the correct date and time is needed on the PDF reports I'll add a few notes from a security perspective:

So far the advantage of ShredOS is/was that is does not need outside or inside network connectivity and was all standalone by default. I think we want to keep it that way and not create a dependancy on external NTP especially because the ShredOS distro doesn't have an update management in place and by nature is vulnerable from a security perspective. I run it airgapped for example in our environment.

Any network vulnerability scanner will scan hosts for exposed ports and try to determine which (outdated) software is running behind that port so it can map CVEs to it and let you know. I haven't checked if the current iteration of ShredOS has open ports although I saw some recent discussion about TFTP and FTP for the transfer of the new PDF feature. So depending how that was implemented with a server for example running on ShredOS this will create an alert... and work (since you have to patch it... well unless it runs airgapped). Even if you run the latest TFTP or FTP server it will still create alerts since both protocols are deprecated and you are encouraged to have everything encrypted which creates a whole other set of challenges for a PartialVolume.

[PartialVolume]

@Firminator It's been a while, hope all's good with you.

Yes, definitely the timezone option would be be going in the config file and as well as a kernel command line.

ShredOS already accesses NTP if it can access the internet so it can sync to UTC. So all we should just need is a timezone setting. You can already manually set the time from within Nwipe via it's config menu if you don't have internet access. This was one of the reasons I added a Organisation/customer/time preview that can be optionally displayed prior to nwipe displaying the drive selection screen, so the operator could check the organisation/customer and date/time details are correct before starting any wipes. So basically the date/time stamps in the certificate and logs are correct.

In other words adding for example automatic timezone adjustment based on GeoIP and querying an internet NTP pool would be counterproductive.

I agree with that. Problem with GeoIP is that it doesn't always relate to the timezone you are in, rather it identifies where the company is that provides your IP which may be in a different timezone.

So far the advantage of ShredOS is/was that is does not need outside or inside network connectivity and was all standalone by default. I think we want to keep it that way and not create a dependancy on external NTP especially because the ShredOS distro doesn't have an update management in place and by nature is vulnerable from a security perspective. I run it airgapped for example in our environment.

Agreed again, although we wouldn't use NTP for determining timezone as it only provides UTC. I can see why local timezone needs to be set because at the moment if ShredOS does have internet access it will try to set the time to UTC overriding any manual entry. So we definitely need a timezone setting.

Although we have TFTP and FTP and soon SFTP support, the server code for these protocols is not installed on ShredOS, only the client code so we can access remote systems, but they can't access us. The only server software installed, as far as I'm aware is the telnet server, which is disabled by default. So you would have to enable it on the kernel command line and if doing so I would expect your LAN to have a hardware firewall.

I've not looked at something like using ufw on buildroot but may look into adding that if it's available and close all ports as default.

Any network vulnerability scanner will scan hosts for exposed ports and try to determine which (outdated) software is running behind that port so it can map CVEs to it and let you know. I haven't checked if the current iteration of ShredOS has open ports although I saw some recent discussion about TFTP and FTP for the transfer of the new PDF feature. So depending how that was implemented with a server for example running on ShredOS this will create an alert... and work (since you have to patch it... well unless it runs airgapped). Even if you run the latest TFTP or FTP server it will still create alerts since both protocols are deprecated and you are encouraged to have everything encrypted which creates a whole other set of challenges for a PartialVolume.

I've been think of removing the current method of tftp/ftp access where the user specifies the commands to be used it opens up too many security issues, so while indeed very flexible I'm going to change it so the user only specifies, remote IP, port, username, password etc and has no control over what files are exported (or imported) into ShredOS. The end result will still be the same that the certificates, logs, dmesg.txt are exported and nwipe.conf and nwipe_customers.csv are imported & exported using either tftp/ftp or sftp.