Re: NTP and Firewall help needed.

From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: 04/29/04 

Date: Thu, 29 Apr 2004 18:37:02 GMT

Ian Laurie <iml@no-spam.zip.com.au> said:
>> I've been reluctant to manually fiddle with iptables for fear of seriously
>> compromising my PC's security.
>
>Firestarter builds a shell script from memory, while I use the file
>/etc/sysconfig/iptables. For me the following entries punch ntp
>through. I'm showing you the top of the file, the bottom, and
>the lines in the middle that let ntp through. Basically you open up
>port 123 for udp and tcp.

Ian,

unless you've accidentally cut some significant lines off your rule
listings, I see some potential problems. Also, for NTP you only need
UDP.

>*filter
>:INPUT ACCEPT [0:0]
>:FORWARD ACCEPT [0:0]
>:OUTPUT ACCEPT [0:0]

I would rather have these as "DROP" instead of "ACCEPT" -- it's a safer
default. The action here is applied for packets that fall off the end of
the chains.

>:INPUT_FORWARD - [0:0]
>-A INPUT -j INPUT_FORWARD
>-A FORWARD -j INPUT_FORWARD

Also the idea of combining rules for packets arriving at the local machine
and packets just being routed through the local machine is a bit curious.
When a machine is intended to be used as a router, it's good practice to
separately think what traffic is desired to route through, and even more
important to think what to accept into the local machine. On the other
hand, when a machine is not intended to be a router, I'd have the default
action in the FORWARD hain as DROP (as just one more safety belt -- one
of the most embarrassing situations is to have your own machine secured,
but still able to forward malicious traffic).

>#
># Allow anything for local loopback.
>#
>-A INPUT_FORWARD -i lo -j ACCEPT

This is definitely needed in the INPUT chain.

>#
># Allow Continuation traffic.
>#
>-A INPUT_FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

This also is needed -- and with the previous one, these should be
pretty much the first rules in the INPUT chain.

>#
># Open up ntp port 123 for both tcp and udp.
>#
>-A INPUT_FORWARD -i eth0 -p tcp -m tcp -s 0/0 --dport 123 --syn -j ACCEPT
>-A INPUT_FORWARD -i eth0 -p udp -m udp -s 0/0 --dport 123 -j ACCEPT

As said, only the udp rule is needed here. Because of the retransmit
functionality built into the TCP protocol (thus making it possible
for a packet to be significantly delayed in transit), ntp can only
run over UDP (no retransmits; packet either arrives to the destination
with relatively short delay, or is dropped and never arrives). Further,
this is only needed if the machine is a NTP server; for machines that
do not provide time service to other machines, no rules specific to NTP
are needed (as the RELATED,ESTABLISHED rule above is sufficient).

>#
># Now block absolutely everything for both tcp and udp not
># explicitly enabled
>#
>-A INPUT_FORWARD -i eth0 -p tcp -m tcp -s 0/0 --sport 0:65535 --dport
>0:65535 --syn -j REJECT
>-A INPUT_FORWARD -i eth0 -p udp -m udp -s 0/0 --sport 0:65535 --dport
>0:65535 -j REJECT

And here comes the nasty point. With this set-up, f.ex. all ICMP traffic
is let through unfiltered (unless it was prohibited in one of the big
snips). Also other IP subprotocols (other than TCP and UDP) will go
through unrestricted. Ok, it's very rare to see anything beyond TCP,
UDP and ICMP, but still it's a possibility. Further, these rulesets
at least look like they might allow f.ex. TCP FIN scans (as only TCP SYN
packets are prohibited by the above rule -- and other TCP control
packets will drop off the tail of the INPUT_FORWARD chain, and thus
the processing will return to the calling chain (INPUT or FORWARD in
this case), and apparently will also drop off the end of those chains
(which both have ACCEPT as the policy). As a final comment agains these
two lines, the --sport/--dport -declarations are redundant, as they cover
the full range of ports (which would be the default even without these
rules).

With iptables, I'd consider my strategy to be:
- start with having a "DROP" policy on INPUT and FORWARD rulesets,
  and "ACCEPT" policy on OUTPUT ruleset
- ACCEPT any and all traffic coming from the localhost interface
  -A INPUT -i lo -j ACCEPT
- DROP invalid input (on INPUT ruleset, and on FORWARD, if appropriate)
  -A INPUT -m state --state INVALID -j DROP
- ACCEPT established and related traffic (again, INPUT and possibly FORWARD)
  -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- ACCEPT other incoming (or passing) traffic as needed (for a very
  basic workstation, no additional rules would be needed; for a server
  openings are needed for services provided by the server)
  - when handling TCP, only ACCEPT with --syn -option (as other TCP
    packets would not be valid at this point)
- some networks may require by policy or by implementation that incoming
  ICMP echo request ("ping") packets are responded to; if desired, add
  -A INPUT -m icmp -p icmp --icmp-type echo-request -j ACCEPT
- if desired, add logging rules to log some/all of the dropped packets
  (in some cases I've also done this so that I have a "log-all" rule
   after a set of protocol- or address-specific DROP rules)
- as a design choice, think if you wish to actively reject all traffic
  that was not accepted, and if so, add appropriate rules:
  -A INPUT -m tcp -p tcp -j REJECT --reject-with tcp-reset
  -A INPUT -m udp -p udp -j REJECT --reject-with icmp-port-unreachable

So, there is a form, but still enough variance to be able to use this in
hopefully any situation. Still some side notes:
- matching is done with minimum amount of parameters, so f.ex. only
  few of the rules have interface specified, thus the rules apply
  for packets arriving on any interface
- specifying interfaces makes sense in
  - determining allowed traffic direction in FORWARD ruleset on firewalls
    (f.ex. "-A FORWARD -p tcp -m tcp --syn --dport 80 -j ACCEPT" alone would
     allow a web browser on any machine in the internal network to connect
     to any web server in the external network AND VICE VERSA; adding
     "-i name_of_internal_interface" would limit the rule so that only
     outbound connections are allowed)
  - providing services only through specified interfaces on a machine
    having multiple interfaces
- note what all is matched by the ESTABLISHED,RELATED rule: it also covers
  some ICMP subtypes, but only when they concern an already established
  session -- so there's no need to specifically allow for any ICMP
  (except for "ping", in those networks where it is required)
- some servers (mainly some SMTP mail servers, also occasional WWW servers)
  may attempt to perform an ident query to any connecting machine, and
  will delay the connection until some response is received; it might
  be appropriate to always actively REJECT all tcp SYN packets destined
  to port 113 to avoid the delay caused by this:
  -A INPUT -m tcp -p tcp --dport 113 -j REJECT --reject-with tcp-reset 

-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Old SUN NFS performance papers.
    ... > also just generally a good idea, since UDP frags act as a fixed ... > you may be copying all your packets over again ), ... With TCP, you ... >> FreeBSD NFS servers, and therefore always looking for tweaks and nobs ...
    (freebsd-performance)
  • Re: UDP vs TCP
    ... I understand that UDP doesn't guarantee proper delivery of the message, that's why we have to add the CRC to the message to check if the message received is correct. ... TCP for instance will break up a large packet into smaller ... > into the packets and then the receiving app would have to read ...
    (microsoft.public.vb.enterprise)
  • [RFC] implement "blackhole" option for TCP and UDP
    ... The patch below is an RFC only. ... interface option for IPv4 TCP and UDP protocols, ... ICMP port unreach (for UDP) or RST (for TCP) packet is generated. ...
    (Linux-Kernel)