Richard Braun wrote:
On Mon, Jun 06, 2011 at 10:14:03PM +0100, Christopher Slater-Walker wrote:
On 6 Jun 2011, at 20:41, Chuck Swiger wrote:
You almost certainly don't want to be implementing stateful rules for NTP
traffic; you'll fill up the state table with lots of entries for no benefit, as
UDP isn't stateful.
Just pass UDP 123 and ephemeral high ports in both directions.
I don't know how ip6tables works, but most (all?) commercial firewalls I've
worked with - which means Cisco and Checkpoint - maintain a connection in the
connection table for UDP for a set period of time. Exactly how long that is, I
can't actually remember right now. This is really a necessity in a firewall,
since once a firewall rule has allowed a UDP flow to pass in one direction, the
response to that flow also has to be allowed through the firewall in the
opposite direction. It is not necessary in this context to create separate
rules for each direction where the traffic is part of the same UDP connection.
Linux does have a stateful IPv6 firewall with full connection tracking
abilities, no worries. What Chuck meant is that, even if it does, you
don't want to do that, since a NTP server can have so many clients it
would fill the connection tracking table (which is several tens of
thousands of entries, depending on tuning). The alternate solution
he suggests is to use old-style pair rules (e.g. 123/[1024 65535]) and
this seems reasonable.
Yes, but this discussion was not about a server!
On a server, of course you simply have an incoming and outgoing rule
that allows traffic to/from port 123.
But this discussion was about a monitoring system that sends NTP
requests from high-numbered ports
to port 123 on a distant server.
It certainly makes sense to use a connection tracking firewall on such a
system, because if you want
to filter using static rules, you will open up everthing running on the
local system and listening on
a high-numbered port to attackers that use source port 123.
Rob
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
