Gui for configuring NTP

[jdow]

From: "taharka" <res00vl8 at alltel.net>

> Howdy jdow,
> 
> On Fri, 2005-12-09 at 21:22 -0800, jdow wrote:
>> From: "taharka" <res00vl8 at alltel.net>
>> 
>> > Howdy,
>> > 
>> > On Fri, 2005-12-09 at 18:40 -0600, Nathaniel Hall wrote:
>> >> Scot L. Harris wrote: 
>> >> > On Fri, 2005-12-09 at 19:12, jdow wrote:
>> >> >   
>> >> > > From: "Paul Smith" <phhs80 at gmail.com>
>> >> > > 
>> >> > >     
>> >> > 
>> >> >   
>> >> > > > > > Is your iptables open for NTP?
>> >> > > > > > I have this:
>> >> > > > > > -A INPUT -s 66.187.233.4 -p udp -m udp --sport 123 --dport 123 -j ACCEPT
>> >> > > > > > -A INPUT -s 66.187.224.4 -p udp -m udp --sport 123 --dport 123 -j ACCEPT
>> >> > > > > >           
>> >> > > 
>> >> > > NOTE: that is only good if you have "clock1.redhat.com" as your clock
>> >> > > server. Make it correct for the clock server you select. You may have to
>> >> > > make it a range of addresses.
>> >> > > 
>> >> > >     
>> >> > 
>> >> > Why would you need to open these ports to have your system update it's
>> >> > time using NTP?  My systems seem to get NTP updates just fine sitting
>> >> > behind a firewall that does not have these ports opened.
>> >> > 
>> >> > 
>> >> >   
>> >> Then it isn't a firewall.  Well, I guess it could be, but it is a very
>> >> poor firewall.  I'll almost guarantee that the ports are open, you
>> >> just don't know it.
>> > That simply isn't so. All my systems are sitting behind a hardware
>> > firewall & I can guarantee that the ports are not open. The thing is,
>> > the firewall will cheerfully pass a request to the outside from a client
>> > system & return whatever is requested. Unless, some sort of rule is set
>> > explicitly telling it not to do so. This is the way a firewall is
>> > supposed to work.
>> 
>> <voice, Gildersleeve>Oh reeeeaaally!</voice>
>> 
>> I always set firewalls to drop packets unless told by some other rule
>> to do something with them. The old "ipfwd" did not do a good job with
>> regards to UDP "connections" such as "ntp" uses. So I generally had to
>> explicitly open the firewall holes needed to pass the external DNS
>> servers and NTP servers I used. The initial (more or less direct
>> translation) I used with iptables suffered the same problem. As I 
>> became more proficient with iptables and trimmed cruft (and used
>> ip_connect_track) the UDP issue subsided.
> 
> m0n0wall/Netboz/pfsense are all FreeBSD based & use ipfw. At the moment,
> I'm running m0n0wall with the stock ruleset listed below. No problems
> what-so-ever with UDP/ntp connections.

I had the impression the old OLD ipfwd on Linux was quite different
from the ipfw on FreeBSD. For the old ipfwd setup I started with the
firewall from the Trinity OS Project and progressively tweaked it
into doing what I needed in a slow stepwise manner. When it came time
to change to iptables I made an initial somewhat ham-handed
transformation and had some problems with "over-security". I was closed
down too tightly. Over time iptables seems to have matured (greatly)
and the rule sets are slimming down nicely. I still do some strange
things with it from time to time. So it's not setup by a standard
firewall tool. I'd be lost trying to tell it what I am doing. {^_-}
(The easy part is opening a nice vertical (all ports) hole to a
specific trusted system "out there." The medium hard part is opening
a specific second hole to a single address "out there" using the
trusted machine acccess to get in so I can perform the tweak. The
hard part is opening a hole that directs packets to and from a
specific port on my XP machine for streaming video. I don't do that
very often. The uplink I have is WAY too slow to make it practical.)
So I simply have a file I use to setup the firewalls my way. It's a
fairly simple bash shell file that accepts some variables on its
input, optionally. With that I can change the structure of the
firewall in literally seconds. It's handy.

{^_^}