NTP and Firewall help needed. - Redhat

This is a discussion on NTP and Firewall help needed. - Redhat ; I'm trying to set up NTP to keep the clock adjusted on my PC workstation running under RedHat 9. (There's no local network involved.) I used the RH Time/Date tool to configure 'ntpd', but that apparently doesn't set up the ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: NTP and Firewall help needed.

  1. NTP and Firewall help needed.

    I'm trying to set up NTP to keep the clock adjusted on my PC workstation
    running under RedHat 9. (There's no local network involved.)

    I used the RH Time/Date tool to configure 'ntpd', but that apparently
    doesn't set up the appropriate entry in iptables, and gnome-lokkit doesn't
    seem to have the capability to do this.

    I've tried 'firestarter' to set up iptables, and that works. However I'm
    constantly hammered with portscans or other drivel from the 'net, all of
    which firestarter allows to be recorded in /var/log/messages to the extent
    of 2-3 MB per day. Although 'logrotate' keeps the size of the messages
    within reasonable bounds, this pretty much makes /var/log/messages useless.

    I've been reluctant to manually fiddle with iptables for fear of seriously
    compromising my PC's security.

    Expert advice will be appreciated.

    Regards,
    Charles Sullivan


  2. Re: NTP and Firewall help needed.

    In article , Charles Sullivan \
    wrote:
    > I'm trying to set up NTP to keep the clock adjusted on my PC workstation
    > running under RedHat 9. (There's no local network involved.)
    >
    > I used the RH Time/Date tool to configure 'ntpd', but that apparently
    > doesn't set up the appropriate entry in iptables, and gnome-lokkit doesn't
    > seem to have the capability to do this.
    >
    > I've tried 'firestarter' to set up iptables, and that works. However I'm
    > constantly hammered with portscans or other drivel from the 'net, all of
    > which firestarter allows to be recorded in /var/log/messages to the extent
    > of 2-3 MB per day. Although 'logrotate' keeps the size of the messages
    > within reasonable bounds, this pretty much makes /var/log/messages useless.
    >
    > I've been reluctant to manually fiddle with iptables for fear of seriously
    > compromising my PC's security.
    >
    > Expert advice will be appreciated.


    I'm not an expert, but I do have positive experience.

    At least with RHL 9, the init scripts for service "ntpd"
    open the firewall when it starts the service. I edited the
    following files and then started the service at boot via
    chkconfig.

    /etc/logrotate.d/ntp
    /etc/ntp.conf
    /etc/ntp/step-tickers
    /etc/ntp/keys

    Good luck.

    Robert Riches
    spamtrap42@verizon.net
    (Yes, that is one of my email addresses.)

  3. Re: NTP and Firewall help needed.

    Charles Sullivan said:
    >I've tried 'firestarter' to set up iptables, and that works. However I'm
    >constantly hammered with portscans or other drivel from the 'net, all of
    >which firestarter allows to be recorded in /var/log/messages to the extent
    >of 2-3 MB per day. Although 'logrotate' keeps the size of the messages
    >within reasonable bounds, this pretty much makes /var/log/messages useless.
    >
    >I've been reluctant to manually fiddle with iptables for fear of seriously
    >compromising my PC's security.


    The logging in iptables is done by separate rule lines that have no
    other functionality, so it should be very straightforward to just
    take the firestarter result and remove all the logging rules (or at
    least the noisiest ones). The logging lines are the ones having text
    "-j LOG".

    I'd also recommend to get at least casual familiarity with "raw"
    iptables rulesets, so that you can most of the time read through
    the rulesets and understand how and why it works like it does.
    --
    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)

  4. Re: NTP and Firewall help needed.

    > 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.


    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :INPUT_FORWARD - [0:0]
    -A INPUT -j INPUT_FORWARD
    -A FORWARD -j INPUT_FORWARD
    #
    # Allow anything for local loopback.
    #
    -A INPUT_FORWARD -i lo -j ACCEPT
    #
    # Allow Continuation traffic.
    #
    -A INPUT_FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

    [big snip]

    #
    # 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

    [big snip]

    #
    # 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
    COMMIT

    Ian


  5. Re: NTP and Firewall help needed.

    Juha Laiho wrote in message news:...
    > Charles Sullivan said:
    > >I've tried 'firestarter' to set up iptables, and that works. However I'm
    > >constantly hammered with portscans or other drivel from the 'net, all of
    > >which firestarter allows to be recorded in /var/log/messages to the extent
    > >of 2-3 MB per day. Although 'logrotate' keeps the size of the messages
    > >within reasonable bounds, this pretty much makes /var/log/messages useless.
    > >
    > >I've been reluctant to manually fiddle with iptables for fear of seriously
    > >compromising my PC's security.

    >
    > I'd also recommend to get at least casual familiarity with "raw"
    > iptables rulesets, so that you can most of the time read through
    > the rulesets and understand how and why it works like it does.


    And as interesting as that would be, you could also use Fwbuilder - a
    great "gui" iptables firewall builder!

  6. Re: NTP and Firewall help needed.

    On Tue, 27 Apr 2004 19:37:02 +0000, Juha Laiho wrote:

    > Charles Sullivan said:
    >>I've tried 'firestarter' to set up iptables, and that works. However
    >>I'm constantly hammered with portscans or other drivel from the 'net,
    >>all of which firestarter allows to be recorded in /var/log/messages to
    >>the extent of 2-3 MB per day. Although 'logrotate' keeps the size of the
    >>messages within reasonable bounds, this pretty much makes
    >>/var/log/messages useless.
    >>
    >>I've been reluctant to manually fiddle with iptables for fear of
    >>seriously compromising my PC's security.

    >
    > The logging in iptables is done by separate rule lines that have no
    > other functionality, so it should be very straightforward to just take
    > the firestarter result and remove all the logging rules (or at least the
    > noisiest ones). The logging lines are the ones having text "-j LOG".


    Firestarter doesn't seem to write a file with the final rules, but I
    commented out the one line with "-j LOG" I could find in the
    /etc/firestarter/firestarter.sh script and that seems to have done the
    job: no intruders are listed in /var/log/messages, ports are fully
    stealthed (per http://grc.com "Shields Up"), and ntpd appears to be
    keeping my clock updated. Many thanks Juha.

    > I'd also recommend to get at least casual familiarity with "raw"
    > iptables rulesets, so that you can most of the time read through the
    > rulesets and understand how and why it works like it does.


    You're right. I need to find a copy of "Iptables for Dummies". :-)

    Regards,
    Charles Sullivan



  7. Re: NTP and Firewall help needed.

    On Wed, 28 Apr 2004 09:08:41 +0000, Ian Laurie wrote:

    >> 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.
    >
    >
    > *filter
    > :INPUT ACCEPT [0:0]
    > :FORWARD ACCEPT [0:0]
    > :OUTPUT ACCEPT [0:0]
    > :INPUT_FORWARD - [0:0]
    > -A INPUT -j INPUT_FORWARD
    > -A FORWARD -j INPUT_FORWARD
    > #
    > # Allow anything for local loopback.
    > #
    > -A INPUT_FORWARD -i lo -j ACCEPT
    > #
    > # Allow Continuation traffic.
    > #
    > -A INPUT_FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    >
    > [big snip]
    >
    > #
    > # 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
    >
    > [big snip]
    >
    > #
    > # 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
    > COMMIT
    >
    > Ian


    Thanks for your detailed reply, which will definitely help
    me to learn this stuff. You open a port for both TCP and UDP;
    do some NTP servers use one and not the other, or are both
    required for all NTP servers? (You can infer the level of
    my knowledge from this question.)

    Regards,
    Charles Sullivan




  8. Re: NTP and Firewall help needed.

    Ian Laurie 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)

  9. Re: NTP and Firewall help needed.

    Juha Laiho wrote:
    ....snip...
    >
    > 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.
    >


    Just btw... if you have Windows 2000 host client using W32Time, you'll
    need TCP and the ability ping the ntp server (stupid Windows).


+ Reply to Thread