Early actions for “child” virtual machines

Defending the system

In theory, protective defenses should be put in place before enabling access to network communications that may be hostile. In practice, updating anti-malware definitions may be easiest to do by downloading from the Internet. One factor, which could affect just how easy this will be, may be which defensive software (such as an anti-malware scanner) is in use. Different software has had different methods of being able to apply an update, so this might be easier with some defensive solutions, compared to others.

For now, this guide does not contain details about how to get these updates applied without Internet access. Simply transferring files might be helpful.

  • (This guide currently does not have details about this process.)
  • Information about this topic may be added at a later time.

Also, follow these steps:

Check the time

If necessary, set the clock.

DST support

With OpenBSD, the task of setting the time may include adjusting the kernel to support Daylight Savings Time. Actually, there is probably no need to worry about getting the kernel to use the desired offset, so clock may be set to local time, because this should have been taken care of by the “parent image”. Still, that may be worth checking:

Checking NTP configuration

For most systems, there is probably no need to worry about the time, if the parent image has a working NTP configuration:

ls -l /etc/ntpd.conf*
cat /etc/ntpd.conf.local
If the configuration looks good

If that points to operational server(s), then there may be no need to manually configure things. Simply check that the time is currently accurate...


... and that the ntpd software is, indeed, running (so that the time remains accurate).

ps -auxww | grep -i ntpd | grep -v grep
ntpctl -s all
If the specified private servers don't exist
  • Don't just blindly apply these next steps. Only do this if the specified NTP servers, listed in /etc/ntpd.conf file, don't exist.

Remember, the /etc/ntpd.conf.local file may just be a symlink. (That is the case if this guide has been followed.) If that is the case, then that filesystem object isn't extremely difficult to re-create.

ls -l /etc/ntpd.conf*
sudo ln -f -s /etc/ntpd.conf.pubsvr /etc/ntpd.conf.local
ls -l /etc/ntpd.conf*
sudo ntpd -nf /etc/ntpd.conf.local
sudo pkill ntpd
Handling firewall

The following would open up communications to any NTP server. This may be (temporarily) useful if this particular machine is going to be reaching out to public NTP servers.

cpytobak /etc/pf.conf
echo | sudo -n tee -a /etc/pf.conf
echo \# Enable NTP with public servers| sudo -n tee -a /etc/pf.conf
echo pass out on \$ext_if proto udp to any port ntp keep state| sudo -n tee -a /etc/pf.conf
echo pass in on \$ext_if proto udp to self port ntp keep state| sudo -n tee -a /etc/pf.conf
echo ${VISUAL}
sudoedit /etc/pf.conf

That could be locked down by only passing traffic to known hosts. However, if the network address of a pool is being used, then the actual hosts may not be known ahead of time. (Running ntpd followed by ntpctl, obtaining the addresses, and then interacting with pfctl, to insert dynamic rules, is more complicated than what this guide intends to demonstrate.)

sudo pfctl -nf /etc/pf.conf
echo ${?}
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf

(The first command in this next segment might take a while, perhaps about 48 seconds, to run.)

sudo time ntpd -svf /etc/ntpd.conf.local
echo ${?}
echo ${PAGER}
ntpctl -s all | ${PAGER}

Ideally, you'll eventually see lots of valid peers and a synchronized clock. In practice, you'll probably start out without a synchronized clock, and may even see that zero of the peers are valid. Try checking back in a short while (perhaps about 20 seconds), and you may find you start to get some valid peers. Getting the clock sync'ed may take more time (perhaps around five minutes), and so it is recommended that you don't bother just waiting for that.

Update anti-malware definitions

Now that network access is fully functional, there is probably little reason to delay updates to defenses (if the updates haven't been applied already).

Different software has had different methods of being able to apply an update, so this might be easier with some defensive solutions, compared to others.

(This guide currently does not have details about this process.) (If you want to explore this topic anyway, protective software may have some related information.)

Perform other fixes

Sometimes, an issue with a “parent” image exists. That may be due to a mistake that was made, or changing requirements.

When that occurs, there may be a couple of approaches. One is to create a new parent image. (The previous “parent image” should not be deleted as long as there are any existing “child” images that depend on it.) There are a number of steps, and this is basically backtracking, so this is generally not recommended if unnecessary, but is documented at base image adjusting.

Another option may be to document issues, and then to check that documentation when new machines get created.

  • Check any documentation about issues related to a specific parent image.
Optional: Update the file integrity checking database
Rationale: why now?

This may be a point to update the “file integrity checker” database. That way, subsequent reports can easily separate newer actions (which may be rather customized for an individual system) from earlier actions (which may be routinely done on every new system).

For instance, is it really necessary to have a later report note that the system's name was changed?

  • /etc/myname

For instance: if a new user account was created, that may have added several files (which are essentially copies of what is found under the /etc/skel/ directory). If user creation is a standard practice, there may not be a need to have a later report reminding people of the facts that:

  • A user was created (modifying /etc/passwd and /etc/group and maybe other files)
    • Standard files got copied (likely some ~newuser/.* files, many of which are simply copies of files from the /etc/skel/ directory)
    • In OpenBSD: /etc/master.passwd and /etc/pwd.db and /etc/spwd.db and /etc/group.bak and maybe other files)
    • In OpenBSD: /var/backups/ may have some items. (Some of these might be related to usernames... This hasn't been fully sorted out, at the moment of this writing...)
      • /var/backups/etc_group.backup
      • /var/backups/etc_group.current
      • /var/backups/etc_hostname.em0.backup.sha256
      • /var/backups/etc_hostname.em0.current.sha256
      • /var/backups/etc_myname.backup
      • /var/backups/etc_myname.current
      • /var/backups/etc_passwd.backup
      • /var/backups/etc_passwd.current
      • /var/backups/etc_pwd.db.backup.sha256
      • /var/backups/etc_pwd.db.current.sha256
      • /var/backups/etc_rc.conf.local.current
      • /var/backups/etc_resolv.conf.backup
      • /var/backups/etc_resolv.conf.current
      • /var/backups/etc_spwd.db.backup.sha256
      • /var/backups/etc_spwd.db.current.sha256
      • /var/backups/etc_master.passwd.backup
      • /var/backups/etc_master.passwd.current
  • ~newuser/authorized_keys may have received some updates

By updating the “file integrity checker” database now, that may effectively acknowledge such changes, so that a later report can focus on some of the other changes that haven't been made yet. This way, the later report can be smaller, because it doesn't need to include details about some of the routine, authorized changes that just occurred.

If you take the time to do that now, it can make later reports smaller.

Newer method
aidedbup earlyKidSetup-$(hostname -s)
aidedbup earlyKidSetup-$(hostname -s)
Older approach
Check for a sync'ed clock

If you're using NTP, and if the clock wasn't synchronized before, but then you did perform the “file integrity checker” database update, then chances are the “file integrity checker” database update may have taken long enough for the NTP to synchronize. You can check that out, if you like.

echo ${PAGER}
ntpctl -s all | ${PAGER}