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?
On Tue, 31 Aug 2004 15:41:35 -0400, Scot L. Harris webid@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@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@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
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 Tue, 31 Aug 2004 16:22:32 -0400, Scot L. Harris webid@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@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
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
On Tue, 31 Aug 2004 22:16:05 +0100, D. D. Brierton darren@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
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.
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.
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.
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.
On Tue, 2004-08-31 at 17:28, Yang Xiao wrote:
On Tue, 31 Aug 2004 22:16:05 +0100, D. D. Brierton darren@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.
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.
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@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.
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.
--On Tuesday, August 31, 2004 11:06 PM -0700 Nifty Hat Mitch mitch48@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.)
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.
-
D. D. Brierton -
Jeff Vian -
Kenneth Porter -
Markku Kolkka -
Mike Burger -
Scot L. Harris -
Tom Mitchell -
Yang Xiao