Bug 2858 - IPTABLES ignores local date/time
Summary: IPTABLES ignores local date/time
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-28 06:53 CEST by Michael McCarrey
Modified: 2011-10-01 01:49 CEST (History)
2 users (show)

See Also:
Source RPM: iptables-1.4.7-2mnb2.src.rpm
CVE:
Status comment:


Attachments

Description Michael McCarrey 2011-09-28 06:53:39 CEST
Description of problem:IPTABLES seems to ignore the local system date/time and defaults to UTC when building rulesets that use "Time Interval" objects.


Version-Release number of selected component (if applicable): This seems to be restricted to v 1.4.11.4 only.


How reproducible: I used Firewall Builder, v5, to construct the ruleset. I get the same results no matter how I tweak the ruleset.


Steps to Reproduce:
1.Construct a rule as follows:

echo "Rule 5 (global)"
 # 
 # Disallow web traffic except
 # during the specifiec Time Interval.
 $IPTABLES -N Cid4276X22838.0
 for i_eth0 in $i_eth0_list
 do
 test -n "$i_eth0" && $IPTABLES -A INPUT -p tcp -m tcp -m multiport -s $i_eth0 --dports 80,443 -m state --state NEW -j Cid4276X228
38.0 
 done
 $IPTABLES -N RULE_5
 $IPTABLES -A Cid4276X22838.0 -m time --datestart 2011-01-01T18:00:00 --datestop 2020-01-01T21:05:00 --weekdays Mon,Tue,Wed,Thu,Fri -j 
RULE_5
 $IPTABLES -A Cid4276X22838.0 -m time --timestart 08:00 --timestop 11:30 --weekdays Sun,Sat -j RULE_5
 $IPTABLES -N Cid4276X22838.1
 $IPTABLES -A OUTPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid4276X22838.1
 $IPTABLES -A Cid4276X22838.1 -m time --datestart 2011-01-01T18:00:00 --datestop 2020-01-01T21:05:00 --weekdays Mon,Tue,Wed,Thu,Fri -j 
RULE_5
 $IPTABLES -A Cid4276X22838.1 -m time --timestart 08:00 --timestop 11:30 --weekdays Sun,Sat -j RULE_5
 $IPTABLES -A RULE_5 -j LOG --log-level info --log-prefix "RULE 5 -- ACCEPT "
 $IPTABLES -A RULE_5 -j ACCEPT

2. Compile and install the rule using Firewall Builder 5 (or code the rule by hand. It doesn't matter.)

3. Examine the state of the tables as follows: /sbin/iptables -L

4: The output is always like this:

Chain Cid4276X22838.0 (1 references)
target prot opt source destination 
RULE_5 all -- anywhere anywhere TIME on Mon,Tue,Wed,Thu,Fri starting from 2011-01-01 18:00:00 until date 2020-01-01 21:05:00 UTC
RULE_5 all -- anywhere anywhere TIME from 08:00:00 to 11:30:00 on Sat,Sun UTC

Chain Cid4276X22838.1 (1 references)
target prot opt source destination 
RULE_5 all -- anywhere anywhere TIME on Mon,Tue,Wed,Thu,Fri starting from 2011-01-01 18:00:00 until date 2020-01-01 21:05:00 UTC
RULE_5 all -- anywhere anywhere TIME from 08:00:00 to 11:30:00 on Sat,Sun UTC

As you can see, in both rule chains, date and time references are always referenced to UTC. while this is the setting of the hardware clock, IPTABLES should be using the system date/time instead. That is the classic behavior and changing the hardware clock to local time is generally out of the question and while coding rulesets against UTC would work, it's terribly error-prone unless you live along the prime meridian.

5: My workaround was to uninstall v. 1.4.11.1 and it's dependencies and install 1.4.7 and it's dependencies from Mandriva 2010.2. My firewall script functioned properly thereafter, as it did under Mandriva 2010.2. To maintain my sanity, automatic update checks had to be disabled, too.
Comment 1 Chris Denice 2011-09-30 13:43:24 CEST
Hi there,
I am a apprentice and my master asked me to have a look to security issues. So, big apologizes if I am saying trivialities. As far as I can see in the man iptables:

<< This matches if the packet arrival time/date is  within  a  given  range.  All
       options  are optional, but are ANDed when specified. All times are interpreted as UTC by default>>

So, I would say that this is normal?

The man also claims that you can use --kerneltz to switch to local time, but that's highly discouraged.

Cheers,
Chris.

CC: (none) => dirteat

Comment 2 Michael McCarrey 2011-09-30 18:09:25 CEST
Hello Chris,

It's only normal if someone has decided to change the way IPTABLES has operated historically. That's possible. It was done to glib and that hosed-up many programs. Personally, I'm fed-up with "features" like that and similar "improvements".

Regards,
Mike
Comment 3 Thomas Backlund 2011-09-30 22:28:54 CEST
It's an intended change from upstream.
https://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=commitdiff;h=db50b83bc3cd634beb71f38978ad7d035c88ff11

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => INVALID
Severity: major => normal

Comment 4 Michael McCarrey 2011-10-01 01:49:40 CEST
Hi Thomas,

Well now, why doesn't that surprise me? Making everyone use UTC is a bit like trying to make everyone go metric from a few years back.

Not a resolution in my book - just an explanation.

Note You need to log in before you can comment on or make changes to this bug.