Iptables "-m time" option doesn't update when the clock changes

Iptables "-m time" option doesn't update when the clock changes

[Sebastian Arcus]

I'm using the following line in my iptables firewall to block internet 
access for one of the machines on the network for one hour a day:

Code:

iptables -A FORWARD -p ALL -o $INET_IFACE -m mac --mac-source 
$BLOCKED_MAC1 -m time --timestart $BLOCKED_TIMESTART1 --timestop 
$BLOCKED_TIMESTOP1 -j DROP


Everything works fine - except that when the clocks change from winter 
time to summer time (in UK) - the rule keeps on working on the old time. 
The clock of this server (checked with "date") updates correctly. If I 
restart the server - the rule finally starts working on the correct 
time. Last year when this happened, I posted here and I was advised to 
change the hardware clock to UTC (from local time) - which I did. 
However, now that the clock just changed again from winter time to 
summer time - the user is complaining again that their Internet access 
slot is off by an hour.

Does anybody know why is this happening?

Re: Iptables "-m time" option doesn't update when the clock changes

[Jan Engelhardt]

On Thursday 2012-03-29 11:10, Sebastian Arcus wrote:

> I'm using the following line in my iptables firewall to block internet access
> for one of the machines on the network for one hour a day:
>
> Code:
>
> iptables -A FORWARD -p ALL -o $INET_IFACE -m mac --mac-source $BLOCKED_MAC1 -m
> time --timestart $BLOCKED_TIMESTART1 --timestop $BLOCKED_TIMESTOP1 -j DROP
>
>
> Everything works fine - except that when the clocks change from winter time to
> summer time (in UK) - the rule keeps on working on the old time.

This is documented behavior, see manpage (preferably that of a recent 
release).

Re: Iptables "-m time" option doesn't update when the clock changes

[Sebastian Arcus]

Hi,

On 29/03/12 10:12, Jan Engelhardt wrote:
> On Thursday 2012-03-29 11:10, Sebastian Arcus wrote:
>
>> I'm using the following line in my iptables firewall to block internet access
>> for one of the machines on the network for one hour a day:
>>
>> Code:
>>
>> iptables -A FORWARD -p ALL -o $INET_IFACE -m mac --mac-source $BLOCKED_MAC1 -m
>> time --timestart $BLOCKED_TIMESTART1 --timestop $BLOCKED_TIMESTOP1 -j DROP
>>
>>
>> Everything works fine - except that when the clocks change from winter time to
>> summer time (in UK) - the rule keeps on working on the old time.
>
> This is documented behavior, see manpage (preferably that of a recent
> release).

Thank you for that. According to my manpage:

"--localtz
    Interpret the times given for --datestart, --datestop,  --timestart 
and --timestop to be local kernel time. (Default)"

It sounds like the rule above should be using the local time (default). 
It still doesn't explain why it is stuck on the time before the clock 
change though?

Re: Iptables "-m time" option doesn't update when the clock changes

[Jan Engelhardt]

On Thursday 2012-03-29 11:30, Sebastian Arcus wrote:
>>>
>>>Everything works fine - except that when the clocks change from
>>>winter time to summer time (in UK) - the rule keeps on working on
>>>the old time.
>>
>>This is documented behavior, see manpage (preferably that of a recent
>>release).
>
>Thank you for that. According to my manpage:
>
> "--localtz
>   Interpret the times given for --datestart, --datestop,  --timestart and
> --timestop to be local kernel time. (Default)"
>
>It sounds like the rule above should be using the local time (default). It
>still doesn't explain why it is stuck on the time before the clock change
>though?

As it says in a *recent* version:

  --kerneltz
         Use  the  kernel  timezone instead of UTC to determine whether a
         packet meets the time regulations.

[= note that the default is UTC]

 About kernel timezones: Linux keeps the system time in UTC, and  always
 does  so.   On boot, system time is initialized from a referential time
 source. Where this time source has no timezone information, such as the
 x86 CMOS RTC, UTC will be assumed. If the time source is however not in
 UTC, userspace should provide the correct system time and  timezone  to
 the kernel once it has the information.

 Local  time  is  a  feature on top of the (timezone independent) system
 time. Each process has its own idea of local time, specified via the TZ
 environment variable. The kernel also has its own timezone offset vari-
 able. The TZ userspace environment variable specifies how the UTC-based
 system time is displayed, e.g. when you run date(1), or what you see on
 your desktop clock.  The TZ string may resolve to different offsets  at
 different  dates,  which  is what enables the automatic time-jumping in
 userspace. when DST changes. The kernel's timezone offset  variable  is
 used  when  it  has  to  convert  between  non-UTC sources, such as FAT
 filesystems, to UTC (since the latter is what the rest  of  the  system
 uses).

 The  caveat  with  the  kernel timezone is that Linux distributions may
 ignore to set the kernel timezone, and  instead  only  set  the  system
 time.  Even if a particular distribution does set the timezone at boot,
 it is usually does not keep the kernel timezone offset - which is  what
 changes  on DST - up to date.  ntpd will not touch the kernel timezone,
 so running it will not resolve the issue. As such, one may encounter  a
 timezone that is always +0000, or one that is wrong half of the time of
 the year. As such, using --kerneltz is highly discouraged.

Re: Iptables "-m time" option doesn't update when the clock changes

[Sebastian Arcus]

Hi Jan

On 29/03/12 11:00, Jan Engelhardt wrote:
>
</snip>
>
>   The  caveat  with  the  kernel timezone is that Linux distributions may
>   ignore to set the kernel timezone, and  instead  only  set  the  system
>   time.  Even if a particular distribution does set the timezone at boot,
>   it is usually does not keep the kernel timezone offset - which is  what
>   changes  on DST - up to date.  ntpd will not touch the kernel timezone,
>   so running it will not resolve the issue. As such, one may encounter  a
>   timezone that is always +0000, or one that is wrong half of the time of
>   the year. As such, using --kerneltz is highly discouraged.
>
Thanks for taking the time to give a detailed reply. Just to make sure I 
understand correctly - would this mean that there is no reliable way to 
run time based iptables rules and have them keep up with DST changes 
correctly and automatically - without restarting the machine when the 
DST kicks in or out?

Sebastian

Re: Iptables "-m time" option doesn't update when the clock changes

[Jan Engelhardt]

On Thursday 2012-03-29 12:21, Sebastian Arcus wrote:

> Hi Jan
>
> On 29/03/12 11:00, Jan Engelhardt wrote:
>>
> </snip>
>>
>>  The  caveat  with  the  kernel timezone is that Linux distributions may
>>  ignore to set the kernel timezone, and  instead  only  set  the  system
>>  time.  Even if a particular distribution does set the timezone at boot,
>>  it is usually does not keep the kernel timezone offset - which is  what
>>  changes  on DST - up to date.  ntpd will not touch the kernel timezone,
>>  so running it will not resolve the issue. As such, one may encounter  a
>>  timezone that is always +0000, or one that is wrong half of the time of
>>  the year. As such, using --kerneltz is highly discouraged.
>>
> Thanks for taking the time to give a detailed reply. Just to make sure I
> understand correctly - would this mean that there is no reliable way to run
> time based iptables rules and have them keep up with DST changes correctly and
> automatically - without restarting the machine when the DST kicks in or out?

UTC is reliable, no? :)

If you can reliably update the kernel TZ [that is, whenever a DST switch 
occurs], you can reliably match on non-UTC. This is possible from 
userspace (anything else would be surprising, since the kernel does 
not read arbitrary files).

Re: Iptables "-m time" option doesn't update when the clock changes

[/dev/rob0]

On Thu, Mar 29, 2012 at 11:21:55AM +0100, Sebastian Arcus wrote:
> On 29/03/12 11:00, Jan Engelhardt wrote:
> </snip>
> >  The  caveat  with  the  kernel timezone is that Linux distributions may
> >  ignore to set the kernel timezone, and  instead  only  set  the  system
> >  time.  Even if a particular distribution does set the timezone at boot,
> >  it is usually does not keep the kernel timezone offset - which is  what
> >  changes  on DST - up to date.  ntpd will not touch the kernel timezone,
> >  so running it will not resolve the issue. As such, one may encounter  a
> >  timezone that is always +0000, or one that is wrong half of the time of
> >  the year. As such, using --kerneltz is highly discouraged.
> >
> Thanks for taking the time to give a detailed reply. Just to make 
> sure I understand correctly - would this mean that there is no 
> reliable way to run time based iptables rules and have them keep up 
> with DST changes correctly and automatically - without restarting 
> the machine when the DST kicks in or out?

Restarting the machine? Blasphemy!

Why not simply reload the firewall rules?

A simple at(1) job on the DST-to-standard and standard-to-DST dates 
to reload the rules, either using your distro's firewall management 
tools, or pipe iptables-save to iptables-restore (substituting for
the changed times), ought to do the job just fine.

If you don't want to go to the trouble of looking up the DST change 
dates, you can brute force it with a cron job running every Sunday 
morning. (Either way involves some effort, pick that which you find 
less of a burden.)

rob0@harrier:~$ date
Thu Mar 29 13:43:59 UTC 2012
rob0@harrier:~$ TZ=Europe/London date
Thu Mar 29 14:44:10 BST 2012
rob0@harrier:~$ TZ=Europe/London date -d 'now - 1 month'
Wed Feb 29 13:44:19 GMT 2012

# bash-specific code:
Now=($(date))
[[ ${Now[4]} = BST ]] && load_BST_rules
[[ ${Now[4]} = GMT ]] && load_GMT_rules
# leaving it to you to write the load_*_rules functions
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Iptables "-m time" option doesn't update when the clock changes

[Sebastian Arcus]

On 29/03/12 14:45, /dev/rob0 wrote:
> On Thu, Mar 29, 2012 at 11:21:55AM +0100, Sebastian Arcus wrote:
>> On 29/03/12 11:00, Jan Engelhardt wrote:
>> </snip>
>>>   The  caveat  with  the  kernel timezone is that Linux distributions may
>>>   ignore to set the kernel timezone, and  instead  only  set  the  system
>>>   time.  Even if a particular distribution does set the timezone at boot,
>>>   it is usually does not keep the kernel timezone offset - which is  what
>>>   changes  on DST - up to date.  ntpd will not touch the kernel timezone,
>>>   so running it will not resolve the issue. As such, one may encounter  a
>>>   timezone that is always +0000, or one that is wrong half of the time of
>>>   the year. As such, using --kerneltz is highly discouraged.
>>>
>> Thanks for taking the time to give a detailed reply. Just to make
>> sure I understand correctly - would this mean that there is no
>> reliable way to run time based iptables rules and have them keep up
>> with DST changes correctly and automatically - without restarting
>> the machine when the DST kicks in or out?
>
> Restarting the machine? Blasphemy!
>
> Why not simply reload the firewall rules?
>
> A simple at(1) job on the DST-to-standard and standard-to-DST dates
> to reload the rules, either using your distro's firewall management
> tools, or pipe iptables-save to iptables-restore (substituting for
> the changed times), ought to do the job just fine.
>

Thanks for the suggestion. However, restarting the firewall (which 
flushes and re-writes the rules) makes absolutely no difference. I have 
to actually restart the machine for the rules to behave according to the 
correct time. Maybe there is something wrong with the way Slackware 
updates the kernel TZ - as per Jan's post. I've posted to the Slackware 
list on linuxquestions.org to see if anybody knows more.

Sebastian

PS I agree with your position on restarting servers :-) but I don't seem 
to get any choice in this matter

Re: Iptables "-m time" option doesn't update when the clock changes

[/dev/rob0]

On Mon, Apr 02, 2012 at 08:57:28PM +0100, Sebastian Arcus wrote:
> On 29/03/12 14:45, /dev/rob0 wrote:
> >On Thu, Mar 29, 2012 at 11:21:55AM +0100, Sebastian Arcus wrote:
> >>On 29/03/12 11:00, Jan Engelhardt wrote:
> >></snip>
> >>>  The  caveat  with  the  kernel timezone is that Linux distributions may
> >>>  ignore to set the kernel timezone, and  instead  only  set  the  system
> >>>  time.  Even if a particular distribution does set the timezone at boot,
> >>>  it is usually does not keep the kernel timezone offset - which is  what
> >>>  changes  on DST - up to date.  ntpd will not touch the kernel timezone,
> >>>  so running it will not resolve the issue. As such, one may encounter  a
> >>>  timezone that is always +0000, or one that is wrong half of the time of
> >>>  the year. As such, using --kerneltz is highly discouraged.
> >>>
> >>Thanks for taking the time to give a detailed reply. Just to
> >>make sure I understand correctly - would this mean that there is
> >>no reliable way to run time based iptables rules and have them
> >>keep up with DST changes correctly and automatically - without 
> >>restarting the machine when the DST kicks in or out?
> >
> >Restarting the machine? Blasphemy!
> >
> >Why not simply reload the firewall rules?
> >
> >A simple at(1) job on the DST-to-standard and standard-to-DST 
> >dates to reload the rules, either using your distro's firewall 
> >management tools, or pipe iptables-save to iptables-restore 
> >(substituting for the changed times), ought to do the job just
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >fine.
> 
> Thanks for the suggestion. However, restarting the firewall (which
> flushes and re-writes the rules) makes absolutely no difference. I

Did you substitute the changed time? I don't see how using different 
times in your rules would make no difference. Indeed, if not changing 
times, reloading the same rules would make no difference.

> have to actually restart the machine for the rules to behave 
> according to the correct time. Maybe there is something wrong with 
> the way Slackware updates the kernel TZ - as per Jan's post. I've 
> posted to the Slackware list on linuxquestions.org to see if 
> anybody knows more.

If we can figure out what needs to be done on the Slackware side, 
this probably will be fixed. I think maybe "hwclock --utc --systz" 
would do it in a weekly cron job. (Of course also reading the value 
set in /etc/hardwareclock and not running for those misguided souls 
who use --localtime for their hwclock.)

I'm not sure that this is the fix, however; hwclock(8) isn't clear 
(to me) about setting the kernel's TZ.

> PS I agree with your position on restarting servers :-) but I don't
> seem to get any choice in this matter
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Iptables "-m time" option doesn't update when the clock changes

[Sebastian Arcus]

On 02/04/12 23:07, /dev/rob0 wrote:
> On Mon, Apr 02, 2012 at 08:57:28PM +0100, Sebastian Arcus wrote:
>> On 29/03/12 14:45, /dev/rob0 wrote:
>>> On Thu, Mar 29, 2012 at 11:21:55AM +0100, Sebastian Arcus wrote:
>>>> On 29/03/12 11:00, Jan Engelhardt wrote:
>>>> </snip>
>>>>>   The  caveat  with  the  kernel timezone is that Linux distributions may
>>>>>   ignore to set the kernel timezone, and  instead  only  set  the  system
>>>>>   time.  Even if a particular distribution does set the timezone at boot,
>>>>>   it is usually does not keep the kernel timezone offset - which is  what
>>>>>   changes  on DST - up to date.  ntpd will not touch the kernel timezone,
>>>>>   so running it will not resolve the issue. As such, one may encounter  a
>>>>>   timezone that is always +0000, or one that is wrong half of the time of
>>>>>   the year. As such, using --kerneltz is highly discouraged.
>>>>>
>>>> Thanks for taking the time to give a detailed reply. Just to
>>>> make sure I understand correctly - would this mean that there is
>>>> no reliable way to run time based iptables rules and have them
>>>> keep up with DST changes correctly and automatically - without
>>>> restarting the machine when the DST kicks in or out?
>>>
>>> Restarting the machine? Blasphemy!
>>>
>>> Why not simply reload the firewall rules?
>>>
>>> A simple at(1) job on the DST-to-standard and standard-to-DST
>>> dates to reload the rules, either using your distro's firewall
>>> management tools, or pipe iptables-save to iptables-restore
>>> (substituting for the changed times), ought to do the job just
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> fine.
>>
>> Thanks for the suggestion. However, restarting the firewall (which
>> flushes and re-writes the rules) makes absolutely no difference. I
>
> Did you substitute the changed time? I don't see how using different
> times in your rules would make no difference. Indeed, if not changing
> times, reloading the same rules would make no difference.

Sorry - you are right - I didn't substitute the times in the firewall 
rules. On the other hand - a script which would restart the machine is 
easier (in this particular case) - than one which would amend the 
firewall rules and reload them.

I'm happy to run any other tests on Slackware if somebody can figure out 
what needs testing.

Re: Iptables "-m time" option doesn't update when the clock changes

[John Haxby]

On 03/04/12 12:31, Sebastian Arcus wrote:
>>> Thanks for the suggestion. However, restarting the firewall (which
>>> flushes and re-writes the rules) makes absolutely no difference. I
>>
>> Did you substitute the changed time? I don't see how using different
>> times in your rules would make no difference. Indeed, if not changing
>> times, reloading the same rules would make no difference.
>
> Sorry - you are right - I didn't substitute the times in the firewall
> rules. On the other hand - a script which would restart the machine is
> easier (in this particular case) - than one which would amend the
> firewall rules and reload them. 

Not sure if this is relevant, but getting a local time in UTC in a shell
script isn't hard:

date --utc -d "$(date "+%H:%M:%S +%z" -d 09:00:00)" +%H:%M:%S

In California right now that gives 16:00:00 and in the UK 08:00:00

You could use that to reload your firewall rules on a daily basis (after
the time the clocks change) or just for the date that the clocks change
(last Sunday in March and October respectively in the UK).

jch

Re: Iptables "-m time" option doesn't update when the clock changes

[/dev/rob0]

On Wed, Apr 04, 2012 at 10:35:33AM +0100, John Haxby wrote:
> On 03/04/12 12:31, Sebastian Arcus wrote:
> >>> Thanks for the suggestion. However, restarting the firewall (which
> >>> flushes and re-writes the rules) makes absolutely no difference. I
> >>
> >> Did you substitute the changed time? I don't see how using different
> >> times in your rules would make no difference. Indeed, if not changing
> >> times, reloading the same rules would make no difference.
> >
> > Sorry - you are right - I didn't substitute the times in the firewall
> > rules. On the other hand - a script which would restart the machine is
> > easier (in this particular case) - than one which would amend the
> > firewall rules and reload them. 
> 
> Not sure if this is relevant, but getting a local time in UTC in a 
> shell script isn't hard:

No, it's not hard, and the workaround is not really the point here, 
or at least it should not be. The real issue is how to inform the 
kernel of the timezone.

http://lkml.indiana.edu/hypermail/linux/kernel/0702.2/1182.html :
"setsystz" seems to be one answer. In my limited testing it works 
with -m time rules using --localtz (the default.) When changing the 
kernel's timezone while a --timestart/--timestop was in effect, to 
make the rule no longer applicable, it did stop matching.

The author posted that in early 2007, saying that most/all distros 
get this wrong. Is that still the case?

What I'm still not sure about is the way the distros should handle 
this. The Slackware timeconfig script (which is run during setup) 
asks the user if the hardware clock is in UTC, and based on that 
information, the rc.S script runs either of these:
	/sbin/hwclock $CLOCK_OPT --utc --hctosys
	/sbin/hwclock $CLOCK_OPT --localtime --hctosys
depending on that choice.

Seems like the proper thing to do might be
	/sbin/hwclock $CLOCK_OPT --utc --systz
but I don't know if that should be in addition to, or in place of, 
the --hctosys command. (And I think this only matters for the UTC 
users; having the hwclock in localtime is broken anyway.) I'm also 
unsure if that will handle the DST changes. If not, setsystz looks 
like the best solution, run as a cron or at job.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Iptables "-m time" option doesn't update when the clock changes

[John Haxby]

On 04/04/12 14:14, /dev/rob0 wrote:
> The author posted that in early 2007, saying that most/all distros 
> get this wrong. Is that still the case?

I don't know about "most distros" but anything that calls hwclock
--systz one way or another will get it right.  That include RHEL6 and
its equivalents and current Fedora (I'm not sure how far back in Fedora,
but quite a way).

The critical udev rule is likely to be found in
/lib/udev/rules.d/88-clock.rules:

ACTION=="add", SUBSYSTEM=="rtc", ATTR{hctosys}=="1", RUN+="/sbin/hwclock
--systz --rtc=/dev/%k"

The "ATTR{hctosys}" refers to /sys/devices/*/*/rtc/rtc0/hctosys  (or
similar).   If it contains "1"  then you have CONFIG_RTC_HCTOSYS=y in
the kernel config which means that rtc setting works nicely.   I forget
the details, but it's described  in the corresponding Kconfig file.

jch