Re: Network time protocol

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "FB" == Frank BENNETT <bennett@example.com> writes:

    FB> I think we have a glimmer of understanding at this end.  This
    FB> means that in best practice, a firewall should not do routing
    FB> itself?

Not exactly.  The routers are part of the firewall.

First, the basic reason for having two routers is so that the routers
don't know anything about each other.  In particular, Outside doesn't
even know how many hosts are inside; for all it knows, Inside is the
only host in there (Inside may very well be doing NAT == masquerading,
in which case all packets are in fact addressed _to_ Inside, not merely
c/o Inside).  This would be much more complex if you had one router.

Eg, suppose Inside is doing NAT for _all_ inside hosts that need
external access.  Then you put a static route to Inside on Outside,
and DENY all RIP (router information protocol) packets on Outside's
inside interface.  It is now absolutely impossible for inside routes
to leak out.  A similar process using two DNS servers can greatly
reduce the chance of any inside DNS info leaking out (this is a little
harder, because server-level DNS is peer to peer on port 53 at both
ends, and is UDP so directionality cannot be determined from the IP or
UDP headers; you have to decode the DNS protocol and determine whether
it is a query or a reply).  And you want to DENY TCP connections
(whose directionality can be determined without knowing higher levels
of the protocol stack) to the inside DNS server, because those are
used for zone transfers.

    FB> I understand roughly why doing filtering inside the kernel is
    FB> risky (because the kernel controls the world).  What is the
    FB> problem with permitting the firewall to serve as gateway on
    FB> each of two interfaces?  Is it simply that the routers
    FB> themselves provide a second line of defense -- an attacker
    FB> must first breach the router in order to gain access to the
    FB> firewall?

Yes.  Note that the bastion host/gateway is running complex servers
(web proxies) and therefore is relatively vulnerable.

    FB> I am assuming that the physical setup looks something like
    FB> this:

<---Evil Insiders--->Router1<--->Firewall<--->Router2<---Evil Outsiders--->

Yes.

    FB> Router2 is registered on outside hosts as the access point for
    FB> the Evil Insiders' domain, but it simply delivers any inbound
    FB> packets it receives to Firewall, via a separate interface.
    FB> Firewall reads the packet headers for the type of data,
    FB> filters, and delivers everything it finds OK to the interface
    FB> connected to Router1.  Router1 reads the packet headers and
    FB> decides how to route packets to hosts within the Evil
    FB> Insiders' domain, again via a separate network interface.
    FB> Traffic running the other way operates similarly.

Yes.

    FB> So an attempt to telnet from EO to EI will succeed
    FB> transparently, if telnet packets are passed by Firewall.

No.  They can be denied by the routers.  This is an important part of
the protection.  The bastion host runs _nothing_ but its proxies; it
could do router-style forwarding (eg, for certain kinds of ICMP), or
(contrary to what I wrote before) the routers could handle them
directly.

The difference between a router and a gateway is that gateways strip
off the IP and TCP/UDP information and look at the payload, while a
router simply edits the header and retransmits.  This is one of the
main reasons why pinging a host on the other side of your nearest
router typically takes 2ms or so, while pinging the router itself
takes 5 to 10 times as long.  (Routers are also optimized to route,
not to respond to pings.  :-)  Internetwork gateways, of course,
translate addressing schemes and often the content (eg, ASCII to
EBCDIC in the bad old days).  Application gateways will analyze the
traffic for signs of evil intent.  Both need to construct a whole new
packet on retransmission in most cases.

    FB> Feel free to eject from this discussion by recommending that I
    FB> RTFM (with a suggestion of which FM I should R).

I like Cheswick and Bellovin, _Firewalls and Internet Security_.
Nowadays a bit dated, but the principles are well explained.  Venema
and Farmer have a book or two out, too, but I don't have it (them).


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."