2:41 p.m.
I have noticed an anomaly with iptables and ntpd. During boot ntpd
opens up some ports in the firewall.
If you stop and start iptables these ports are no longer open. I
believe this would mean that ntp would stop working as expected.
I have not noticed any issues with the clock not tracking but it could
be a problem particularly for sites running certain authentication
packages which require time on the systems to be synchronized closely.
It also seems that if ntp requires ports to be open then they should be
configured in the normal /etc/sysconfig/iptables file.
Should this be reported in bugzilla or is there a logical reason things
are setup this way?
--
Scot L. Harris
webid(a)cfl.rr.com
Q: What do Winnie the Pooh and John the Baptist have in common?
A: The same middle name.
3:04 p.m.
On Tue, 31 Aug 2004 15:41:35 -0400, Scot L. Harris <webid(a)cfl.rr.com> wrote:
I have noticed an anomaly with iptables and ntpd. During boot ntpd
opens up some ports in the firewall.
If you stop and start iptables these ports are no longer open. I
believe this would mean that ntp would stop working as expected.
I have not noticed any issues with the clock not tracking but it could
be a problem particularly for sites running certain authentication
packages which require time on the systems to be synchronized closely.
It also seems that if ntp requires ports to be open then they should be
configured in the normal /etc/sysconfig/iptables file.
Should this be reported in bugzilla or is there a logical reason things
are setup this way?
--
Scot L. Harris
webid(a)cfl.rr.com
Q: What do Winnie the Pooh and John the Baptist have in common?
A: The same middle name.
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
The port is opened by the /etc/init.d/ntp script, this means you need
to restart ntp after you restart iptables.
Yang
3:22 p.m.
On Tue, 2004-08-31 at 16:04, Yang Xiao wrote:
The port is opened by the /etc/init.d/ntp script, this means you
need
to restart ntp after you restart iptables.
Yang
I understand where ntp opens the ports. But if you don't realize that
this is happening and you restart iptables for some reason without
restarting ntp then the ports are closed.
This seems like a poor way to do things. What happens when another
application is configured like ntp and you now have to remember to
restart several applications just because the ports were closed when you
did some testing or modified your iptables rules? Plus it could become
difficult to track down all the scripts that modify your iptables rule
set.
I think ntp is the only one that does this currently. Should this not
be moved to the /etc/sysconfig/iptables file and taken out of the ntp
startup scripts?
--
Scot L. Harris
webid(a)cfl.rr.com
We are all so much together and yet we are all dying of loneliness.
-- A. Schweitzer
3:29 p.m.
On Tue, 31 Aug 2004 16:22:32 -0400, Scot L. Harris <webid(a)cfl.rr.com> wrote:
On Tue, 2004-08-31 at 16:04, Yang Xiao wrote:
> The port is opened by the /etc/init.d/ntp script, this means you need
> to restart ntp after you restart iptables.
>
> Yang
I understand where ntp opens the ports. But if you don't realize that
this is happening and you restart iptables for some reason without
restarting ntp then the ports are closed.
This seems like a poor way to do things. What happens when another
application is configured like ntp and you now have to remember to
restart several applications just because the ports were closed when you
did some testing or modified your iptables rules? Plus it could become
difficult to track down all the scripts that modify your iptables rule
set.
I think ntp is the only one that does this currently. Should this not
be moved to the /etc/sysconfig/iptables file and taken out of the ntp
startup scripts?
--
Scot L. Harris
webid(a)cfl.rr.com
We are all so much together and yet we are all dying of loneliness.
-- A. Schweitzer
Well, I guess you can call it a bug, but it's
not difficult to do a
iptables-save > /etc/sysconfig/iptables or even manually add the ntp
rules to the iptables file
to permenantly store the ntp rules before you start to make changes so
that it won't get lost when you restart iptables?
Yang
4:16 p.m.
On Tue, 2004-08-31 at 21:29, Yang Xiao wrote:
Well, I guess you can call it a bug, but it's not difficult to do
a
iptables-save > /etc/sysconfig/iptables or even manually add the ntp
rules to the iptables file
to permenantly store the ntp rules before you start to make changes so
that it won't get lost when you restart iptables?
Yang, I think you're missing Scot's point. It's not about difficulty,
it's about discoverability. Someone who has FC on a server that has
quite long uptimes might be mystified as to why the clock is completely
inaccurate despite their running ntpd because they didn't realise that
restarting iptables had firewalled it off.
I myself am happy for services to "punch holes" through the firewall
when they start up as long as iptables is somehow made aware of this
fact, so that if it has to be restarted it doesn't suddenly firewall all
those services off.
Best, Darren
--
=====================================================================
D. D. Brierton darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
4:28 p.m.
On Tue, 31 Aug 2004 22:16:05 +0100, D. D. Brierton <darren(a)dzr-web.com> wrote:
On Tue, 2004-08-31 at 21:29, Yang Xiao wrote:
> Well, I guess you can call it a bug, but it's not difficult to do a
> iptables-save > /etc/sysconfig/iptables or even manually add the ntp
> rules to the iptables file
> to permenantly store the ntp rules before you start to make changes so
> that it won't get lost when you restart iptables?
Yang, I think you're missing Scot's point. It's not about difficulty,
it's about discoverability. Someone who has FC on a server that has
quite long uptimes might be mystified as to why the clock is completely
inaccurate despite their running ntpd because they didn't realise that
restarting iptables had firewalled it off.
I myself am happy for services to "punch holes" through the firewall
when they start up as long as iptables is somehow made aware of this
fact, so that if it has to be restarted it doesn't suddenly firewall all
those services off.
Best, Darren
as far as I'm aware of, this problem existed in RH9 or maybe even
earlier versions. I guess the ntp service start scripts was designed
to make life easier but created a situation where the user can lose
control when trying to customize.
As to the original post by Scott, I agree, It is a bug that there
isn't a hook in IPTABLES to check for what services needs to punch
holes when restarted. Mainly because they scripted in the service
startup scripts to do so. Otherwise, this is just a preference issue.
Yang
4:44 p.m.
Yang Xiao kirjoitti viestissään (lähetysaika keskiviikko, 1.
syyskuuta 2004 00:28):
as far as I'm aware of, this problem existed in RH9 or maybe
even earlier versions.
More accurately, it's a left-over from the days when RHL used
stateless firewalling. It's not a problem anymore with current
iptables scripts.
--
Markku Kolkka
markku.kolkka(a)iki.fi
7:56 p.m.
On Tue, 2004-08-31 at 17:28, Yang Xiao wrote:
On Tue, 31 Aug 2004 22:16:05 +0100, D. D. Brierton
<darren(a)dzr-web.com> wrote:
> On Tue, 2004-08-31 at 21:29, Yang Xiao wrote:
>
> > Well, I guess you can call it a bug, but it's not difficult to do a
> > iptables-save > /etc/sysconfig/iptables or even manually add the ntp
> > rules to the iptables file
> > to permenantly store the ntp rules before you start to make changes so
> > that it won't get lost when you restart iptables?
>
> Yang, I think you're missing Scot's point. It's not about difficulty,
> it's about discoverability. Someone who has FC on a server that has
> quite long uptimes might be mystified as to why the clock is completely
> inaccurate despite their running ntpd because they didn't realise that
> restarting iptables had firewalled it off.
>
> I myself am happy for services to "punch holes" through the firewall
> when they start up as long as iptables is somehow made aware of this
> fact, so that if it has to be restarted it doesn't suddenly firewall all
> those services off.
>
> Best, Darren
>
as far as I'm aware of, this problem existed in RH9 or maybe even
earlier versions. I guess the ntp service start scripts was designed
to make life easier but created a situation where the user can lose
control when trying to customize.
As to the original post by Scott, I agree, It is a bug that there
isn't a hook in IPTABLES to check for what services needs to punch
holes when restarted. Mainly because they scripted in the service
startup scripts to do so. Otherwise, this is just a preference issue.
Yang
Personally I think it is wrong to have another services startup script
make changes to iptables. If a service needs a hole in the firewall
then that should be documented so the admin can apply the change to
iptables. Short term this is the best solution. Longer term something
that lets iptables identify such requirements and control them when you
start and stop iptables would be good.
--
Scot L. Harris
webid(a)cfl.rr.com
You've been Berkeley'ed!
6:36 p.m.
On Tue, 2004-08-31 at 16:29, Yang Xiao wrote:
Well, I guess you can call it a bug, but it's not difficult to do
a
iptables-save > /etc/sysconfig/iptables or even manually add the ntp
rules to the iptables file
to permenantly store the ntp rules before you start to make changes so
that it won't get lost when you restart iptables?
Yang
But if you put those rules in /etc/sysconfig/iptables when ntpd starts
it inserts duplicate rules again.
Does not work very smoothly.
--
Scot L. Harris
webid(a)cfl.rr.com
How many NASA managers does it take to screw in a lightbulb?
"That's a known problem... don't worry about it."
11:46 p.m.
On Tue, 31 Aug 2004, Scot L. Harris wrote:
On Tue, 2004-08-31 at 16:29, Yang Xiao wrote:
> Well, I guess you can call it a bug, but it's not difficult to do a
> iptables-save > /etc/sysconfig/iptables or even manually add the ntp
> rules to the iptables file
> to permenantly store the ntp rules before you start to make changes so
> that it won't get lost when you restart iptables?
>
> Yang
But if you put those rules in /etc/sysconfig/iptables when ntpd starts
it inserts duplicate rules again.
Does not work very smoothly.
Really? I seem to recall iptables ignoring duplicated rules.
--
Mike Burger
http://www.bubbanfriends.org
Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org
To be notified of updates to the web site, visit
http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a
message to:
site-update-request(a)bubbanfriends.org
with a message of:
subscribe
8:54 a.m.
On Wed, 2004-09-01 at 00:46, Mike Burger wrote:
On Tue, 31 Aug 2004, Scot L. Harris wrote:
> On Tue, 2004-08-31 at 16:29, Yang Xiao wrote:
>
> > Well, I guess you can call it a bug, but it's not difficult to do a
> > iptables-save > /etc/sysconfig/iptables or even manually add the ntp
> > rules to the iptables file
> > to permenantly store the ntp rules before you start to make changes so
> > that it won't get lost when you restart iptables?
> >
> > Yang
>
> But if you put those rules in /etc/sysconfig/iptables when ntpd starts
> it inserts duplicate rules again.
>
> Does not work very smoothly.
Really? I seem to recall iptables ignoring duplicated rules.
Well the test I ran was:
start system
start iptables
start ntpd
save iptables manually
stop iptables
start iptables with saved info including ntp ports
restart ntpd (second set of entries for ntp inserted in iptables)
Would need to do more testing but unless the ntpd script parses the
rules for similar settings there is nothing keeping you from inserting
dozens of similar rules for the same service/port. Would it make
sense? No. The first rule would be applied and the others would not be
hit.
I guess the point I am making is that this method of modifying iptables
in other startup scripts is wrong and can lead to systems having
problems, either services stop working because a change was made to
iptables or a hole is created in the firewall without the knowledge of
the admin creating a potential security issue. Most likely problem is a
service such as ntp stops working correctly which results in clock drift
which then affects some time based security/authentication applications
(like RSA).
The reason I raised the issue here was to make sure I was not missing
anything and to issue a bug report on this potential problem.
--
Scot L. Harris
webid(a)cfl.rr.com
The only two things that motivate me and that matter to me are revenge
and guilt.
-- Elvis Costello
5:58 p.m.
On Tue, 2004-08-31 at 15:22, Scot L. Harris wrote:
On Tue, 2004-08-31 at 16:04, Yang Xiao wrote:
> The port is opened by the /etc/init.d/ntp script, this means you need
> to restart ntp after you restart iptables.
>
> Yang
I understand where ntp opens the ports. But if you don't realize that
this is happening and you restart iptables for some reason without
restarting ntp then the ports are closed.
This seems like a poor way to do things. What happens when another
application is configured like ntp and you now have to remember to
restart several applications just because the ports were closed when you
did some testing or modified your iptables rules? Plus it could become
difficult to track down all the scripts that modify your iptables rule
set.
I think ntp is the only one that does this currently. Should this not
be moved to the /etc/sysconfig/iptables file and taken out of the ntp
startup scripts?
On mine I have no special port open for ntp, and it works thru the
firewall.
IIRC iptables has rules for established & related connections. Mine
also allows any outgoing connections to be started without hindrance.
If you mean ntpd and running a time server, then you need a rule in
iptables to allow other hosts to connect to your server on that port.
1:06 a.m.
On Tue, Aug 31, 2004 at 04:04:07PM -0400, Yang Xiao wrote:
On Tue, 31 Aug 2004 15:41:35 -0400, Scot L. Harris
<webid(a)cfl.rr.com> wrote:
> I have noticed an anomaly with iptables and ntpd. During boot ntpd
> opens up some ports in the firewall.
>
> If you stop and start iptables these ports are no longer open. I
....
> Should this be reported in bugzilla or is there a logical reason
things
> are setup this way?
....
The port is opened by the /etc/init.d/ntp script, this means you
need
to restart ntp after you restart iptables.
IMO it should be reported in bugzilla if only to
make it possible to Google the topic.
It makes sense to me that /etc/init.d/iptables should have some
awareness of applications that depend or are impacted on it and ntpd
seems to be just such a case. The list could be long expect the keepers
of iptables to not want to open the door to a flood.
Pseudo code might sound like: if iptables restart and if "chkconfig
ntpd" then /etc/init.d/ntpd restart.
Quick test...
# if chkconfig ntpd; then echo yea; fi
# if chkconfig ntp ; then echo yea; fi
Perhaps a config line in "/etc/sysconfig/${IPTABLES}-config"
Something like a default 'No' flag so the universe of users are not
confused.
#IPTABLES_RESTARTS_NTPD="No"
to manage this feature.
Anyhow think of the ways this could help and hurt get them in
the bug so it is clear what the value, risks and controls are.
Today, I only see firestarter, iptables, and ntpd as players in this today.
Do not ignore SELinux.... where the chain of necessary roles could prove
to be a problem.
--
T o m M i t c h e l l
Just say no to 74LS73 in 2004
2:37 p.m.
--On Tuesday, August 31, 2004 11:06 PM -0700 Nifty Hat Mitch
<mitch48(a)sbcglobal.net> wrote:
It makes sense to me that /etc/init.d/iptables should have some
awareness of applications that depend or are impacted on it and ntpd
seems to be just such a case. The list could be long expect the keepers
of iptables to not want to open the door to a flood.
This looks like a layer problem to me. iptables is really a low-level tool
for implementing firewalls, yet it's treated like high-level service by the
initscripts. There are also a lot of high-level firewall systems like
shorewall and fwbuilder that replace the low-level service provided by the
iptables initscript. None of these would be aware of the "manual"
hole-punching that the ntpd script does.
If we need network services to have the ability to request holes, we need
some common scheme to communicate this among all the many possible
participants. For instance, we could have a directory
/etc/sysconfig/firewall-requests where packages like ntpd can drop their
requirements in a neutral specification language. Any firewall package can
parse this directory and modify its rules accordingly.
(BTW, the DHCP client has a similar issue: DHCP can supply many
configuration values, and currently the client only runs a single script to
manage them all. A better solution is a directory of scripts supplied from
different packages.)
3:39 p.m.
On Thu, Sep 02, 2004 at 12:37:15PM -0700, Kenneth Porter wrote:
--On Tuesday, August 31, 2004 11:06 PM -0700 Nifty Hat Mitch
>It makes sense to me that /etc/init.d/iptables should have some
>awareness of applications that depend or are impacted on it and ntpd
>seems to be just such a case. The list could be long expect the keepers
>of iptables to not want to open the door to a flood.
This looks like a layer problem to me. iptables is really a
low-level tool for implementing firewalls, yet it's treated like
high-level service by the initscripts. There are also a lot of
high-level firewall systems like shorewall and fwbuilder that
replace the low-level service provided by the
Exactly so, this is a layer problem.
Some thought and discussion is needed to get this right.
--
T o m M i t c h e l l
Just say no to 74LS73 in 2004
4:41 p.m.
Scot L. Harris kirjoitti viestissään (lähetysaika tiistai, 31.
elokuuta 2004 22:41):
If you stop and start iptables these ports are no longer open.
I believe this would mean that ntp would stop working as
expected.
No, the rule that accepts ESTABLISHED and RELATED packets lets
ntp work correctly in the usual client/server mode. Punching
holes in the firewall seems redundant, but in a previous
discussion somebody claimed that it is required if broadcast NTP
is used.
--
Markku Kolkka
markku.kolkka(a)iki.fi
7170
days inactive
7175
days old
15 comments
8 participants
participants (8)
-
D. D. Brierton -
Jeff Vian -
Kenneth Porter -
Markku Kolkka -
Mike Burger -
Scot L. Harris -
Tom Mitchell -
Yang Xiao