Restricting Access by Time of Day

Implementing Time‑Based Service Access

When a server hosts multiple network services, there are times of day when certain services should be shut down or limited. For instance, a development team may want the telnet service to run only during core business hours to reduce the attack surface outside those hours. The operating system can enforce this requirement by controlling the launch of the service at the start of the day and stopping it when the day ends. Two common super‑servers - xinetd and inetd - offer different mechanisms for this.

With xinetd, the process is straightforward. The configuration file contains a simple, human‑readable parameter called access_times. This keyword accepts a list of time ranges in 24‑hour format. For a service that must run from 08:00 to 17:00 each day, the snippet below shows how to set it. Add the block to either the global /etc/xinetd.conf or the service‑specific file in /etc/xinetd.d:

Once the configuration file is saved, restart xinetd with service xinetd restart. The daemon reads the file, enforces the schedule, and rejects connections that arrive outside the defined window. The syntax is forgiving; you can list multiple ranges, separated by commas, or use :::* for unlimited access. The advantage of this approach is that the super‑server itself keeps track of time and does not rely on external cron jobs.

In contrast, traditional inetd lacks built‑in scheduling. The daemon loads its entire service list at boot and stays active until the system shuts down or inetd is reloaded. To emulate time restrictions, you must rebuild the /etc/inetd.conf file at specific moments and signal inetd to reload it. The method described here uses the m4 macro processor to build the file on the fly and a cron job to trigger the rebuild at the desired hours.

First, make a copy of the original /etc/inetd.conf and rename it /etc/inetd.conf.m4. Within the template, wrap any service line that should be toggled with a conditional macro call. The ifelse function in m4 checks a macro value and emits the enclosed text only when the test matches. For example, to enable telnet only during the workday, replace:

with

In this snippet, TIMEOFDAY is a macro that will hold either working or playing. If TIMEOFDAY equals working, the telnet line is inserted into the final configuration; otherwise it is omitted.

Next, create a helper script called /usr/local/sbin/inetd-services that invokes m4 with the chosen parameter and then reloads inetd. The script uses a temporary file so that the configuration is not interrupted during the rewrite:

Make sure the script is executable:

Finally, add two cron entries that fire at the edges of the work period. Each entry calls the script with the appropriate macro definition. For example, to turn the service on at 08:00 and off at 17:00:

When the first cron job runs, m4 expands the template, inserts the telnet service line, writes the result to a temporary file, swaps it into place, and sends a SIGHUP to inetd. The daemon reloads its configuration and starts listening on the telnet port. The second cron job removes the line from the next generated configuration and reloads again, closing the port for the remainder of the day.

Because the reload is quick, there is minimal disruption to clients that are currently connected. Any new connection attempt that arrives after the port has been closed will fail with a refused connection. Clients that are still connected when the reload occurs remain connected until they terminate or attempt to use the service again.

Both methods - access_times in xinetd and the m4 trick with inetd - have their place. If you are already using xinetd or can migrate services to it, the built‑in timing is cleaner and requires no external cron. For legacy systems that run inetd exclusively, the macro approach provides a viable workaround that keeps the service list consistent with the time of day without having to rewrite scripts manually.

Advanced Tactics and Maintenance Tips

When deploying time‑restricted services, you might want to add more flexibility beyond a single on/off schedule. The same techniques described above can be extended to cover multiple periods, weekend rules, or even dynamic user lists.

To manage several windows, simply add more macro definitions to the template and more cron entries. For example, if you need to allow ftp during the normal office hours but restrict it to a subset of users on weekends, create a macro like WEEKEND that expands to a list of allowed users in the ftp service line. In the template you might write:

Then, in cron, pass the appropriate flags at each transition point. This pattern demonstrates how m4 can inject arbitrary configuration snippets based on any set of variables.

Monitoring the reload process is essential. A mis‑typed macro or a broken m4 expression can generate an invalid /etc/inetd.conf, causing inetd to fail to reload. To guard against this, test the output of the macro engine before replacing the active file. You can do this by redirecting to a staging location:

If the test succeeds, swap the test file into place. The -C option checks the configuration for syntax errors without starting the service. If it fails, examine the diff between the template and the output to locate the issue.

Another consideration is the time zone used by the server. Cron and xinetd both rely on the system clock, so ensure the clock is set to the correct time zone or uses UTC to avoid drift. Synchronize the clock with NTP to prevent the service windows from shifting unexpectedly.

When you need to disable a service permanently, you can comment out its line in the m4 template or delete the service altogether. For a temporary experiment, use the kill -HUP trick to reload after commenting. Remember that the reload only re‑reads the file; it does not immediately drop existing connections, so plan for a brief overlap period if a service is critical.

Finally, keep the documentation up to date. Anyone who needs to modify the service schedules should understand where the configuration lives, how the m4 macros are structured, and which cron jobs trigger reloads. A small README in the same directory as /etc/inetd.conf.m4 can outline the workflow and provide a quick reference for the variables.

For more detailed examples and a broader set of security scripts, the Linux Security Cookbook covers a range of real‑world problems, including time‑based access control, encrypted email, firewalling, and key‑based SSH. The book offers ready‑to‑use scripts and configuration files that can be adapted to your environment. murdok.org.