Re: Gui for configuring NTP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Howdy jdow,

On Fri, 2005-12-09 at 21:22 -0800, jdow wrote:
> From: "taharka" <res00vl8@xxxxxxxxxx>
> 
> > 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@xxxxxxxxx>
> >> > > 
> >> > >     
> >> > 
> >> >   
> >> > > > > > 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.

ipfstat -nio

@1 pass out quick on lo0 from any to any
@2 pass out quick on rl0 proto udp from 192.168.1.1/32 port = 67 to any
port = 68
@3 pass out quick on ng0 proto udp from any port = 68 to any port = 67
@4 pass out quick on rl0 from any to any keep state
@5 pass out quick on ng0 from any to any keep state
@6 block out log quick from any to any
@1 pass in quick on lo0 from any to any
@2 block in log quick from any to any with short
@3 block in log quick from any to any with ipopt
@4 pass in quick on rl0 proto udp from any port = 68 to
255.255.255.255/32 port = 67
@5 pass in quick on rl0 proto udp from any port = 68 to 192.168.1.1/32
port = 67
@6 block in log quick on ng0 from 192.168.1.0/24 to any
@7 block in log quick on ng0 proto udp from any port = 67 to
192.168.1.0/24 port = 68
@8 pass in quick on ng0 proto udp from any port = 67 to any port = 68
@9 block in log quick on rl0 from !192.168.1.0/24 to any
@10 block in log quick on ng0 from 10.0.0.0/8 to any
@11 block in log quick on ng0 from 127.0.0.0/8 to any
@12 block in log quick on ng0 from 172.16.0.0/12 to any
@13 block in log quick on ng0 from 192.168.0.0/16 to any
@14 skip 1 in proto tcp from any to any flags S/FSRA
@15 block in log quick proto tcp from any to any
@16 block in log quick on rl0 from any to any head 100
@1 pass in quick from 192.168.1.0/24 to 192.168.1.1/32 keep state group
100
@2 pass in quick from 192.168.1.0/24 to any keep state group 100
@17 block in log quick on ng0 from any to any head 200
@18 block in log quick from any to any

unparsed ipnat rules

map ng0 192.168.1.0/24  -> 0/32 proxy port ftp ftp/tcp
map ng0 192.168.1.0/24  -> 0/32 portmap tcp/udp auto
map ng0 192.168.1.0/24  -> 0/32

unparsed ipfilter rules

# loopback
pass in quick on lo0 all
pass out quick on lo0 all

# block short packets
block in log quick all with short

# block IP options
block in log quick all with ipopts

# allow access to DHCP server on LAN
pass in quick on rl0 proto udp from any port = 68 to 255.255.255.255
port = 67
pass in quick on rl0 proto udp from any port = 68 to 192.168.1.1 port =
67
pass out quick on rl0 proto udp from 192.168.1.1 port = 67 to any port =
68

# WAN spoof check
block in log quick on ng0 from 192.168.1.0/24 to any

# allow our DHCP client out to the WAN
# XXX - should be more restrictive
# (not possible at the moment - need 'me' like in ipfw)
pass out quick on ng0 proto udp from any port = 68 to any port = 67
block in log quick on ng0 proto udp from any port = 67 to 192.168.1.0/24
port = 68
pass in quick on ng0 proto udp from any port = 67 to any port = 68

# LAN/OPT spoof check (needs to be after DHCP because of broadcast
addresses)
block in log quick on rl0 from ! 192.168.1.0/24 to any

# block anything from private networks on WAN interface
block in log quick on ng0 from 10.0.0.0/8 to any
block in log quick on ng0 from 127.0.0.0/8 to any
block in log quick on ng0 from 172.16.0.0/12 to any
block in log quick on ng0 from 192.168.0.0/16 to any

# Block TCP packets that do not mark the start of a connection
skip 1 in proto tcp all flags S/SAFR
block in log quick proto tcp all

#---------------------------------------------------------------------------
# group head 100 - LAN interface
#---------------------------------------------------------------------------
block in log quick on rl0 all head 100

# let out anything from the firewall host itself and decrypted IPsec
traffic
pass out quick on rl0 all keep state

#---------------------------------------------------------------------------
# group head 200 - WAN interface
#---------------------------------------------------------------------------
block in log quick on ng0 all head 200

# let out anything from the firewall host itself and decrypted IPsec
traffic
pass out quick on ng0 all keep state

# make sure the user cannot lock himself out of the webGUI
pass in quick from 192.168.1.0/24 to 192.168.1.1 keep state group 100

# User-defined rules follow
pass in quick from 192.168.1.0/24 to any keep state group 100 
	
#---------------------------------------------------------------------------
# default rules (just to be sure)
#---------------------------------------------------------------------------
block in log quick all
block out log quick all

unparsed ipfw rules

add 50000 set 4 pass all from 192.168.1.1 to any
add 50001 set 4 pass all from any to 192.168.1.1

> BUT, I had to EXPLICITLY tell the firewall I wanted connections
> tracked before a packet could make it through the firewall. The basic
> rule is to simply drop incoming packets I do not ask for or are rogue
> on the floor.

Maybe because the firewall was built from scratch with no standard
ruleset to start with?

> {^_^}

taharka

Lexington, Kentucky U.S.A.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux