Re: NTP and Firewall help needed.

From: Llanzlan Klazmon The 15th (Llanzlan_at_Llurdiaxorb.net)
Date: 04/30/04 

Date: 30 Apr 2004 13:44:45 +1200

Juha Laiho <Juha.Laiho@iki.fi> wrote in
news:c6rhnj$si7$1@ichaos.ichaos-int:

> 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

I would have thought that it is better to never REJECT - use DROP. By
using a REJECT, the firewall is telling the scanner 'here I am'.

LK.

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: 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: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • 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)