--- /dev/null
+\documentclass[article, a4paper, 10pt, notitlepage, numbering]{strayman}
+\usepackage[palatino, helvetica, maths=cmr]{mdwfonts}
+\usepackage[T1]{fontenc}
+\usepackage{at}
+\usepackage[mdwmargin]{mdwthm}
+\usepackage{mdwtab}
+\usepackage[all, dvips]{xy}
+
+\atdef l#1{{\normalfont\sffamily #1}}
+\atdef c#1{\textbf{#1}}
+
+\newtheorem*{observation}{Observation}
+
+\def\cbox#1{%
+ \vbox{%
+ \let\\\cr%
+ \halign{%
+ \hfil\strut\ignorespaces##\unskip\hfil\cr%
+ #1%
+ \crcr%
+ }%
+ }%
+}
+
+\errorcontextlines=999
+
+\begin{document}
+\title{@l{distorted.org.uk} network design}
+\author{Mark Wooding}
+\maketitle
+
+\thispagestyle{empty}
+\pagestyle{empty}
+
+\tableofcontents
+\listoffigures
+\listoftables
+
+\clearpage
+\pagestyle{fancy}
+
+%%%--------------------------------------------------------------------------
+\section{Concepts}
+
+We begin by defining our basic concepts.
+\begin{description}
+\item[@c{Safe}] A @c{safe} network is one whose hosts are protected from
+ potentially dangerous network traffic. Hosts on a @c{safe} network may
+ communicate only (a) using trusted protocols (e.g., SSH) or (b) with
+ @c{trusted} hosts.
+\item[@c{Trusted}] A @c{trusted} network is one whose hosts are permitted to
+ communicate with @c{safe} networks.
+\end{description}
+
+\begin{observation}
+ It is impossible to protect hosts on a @c{safe} network from each other.
+ Therefore, a @c{safe} network must be @c{trusted}. As an immediate
+ corollary, an @c{untrusted} network cannot be @c{safe}.
+\end{observation}
+
+We therefore distinguish three types of networks:
+\begin{enumerate}
+\item @c{Safe}, and therefore @c{trusted}.
+\item @c{Trusted} but @c{unsafe}.
+\item @c{Untrusted}, and therefore @c{unsafe}.
+\end{enumerate}
+
+
+%%%--------------------------------------------------------------------------
+\section{Existing hosts}
+
+We have the following hosts. All of them should be @c{trusted}.
+\begin{description}
+\item[@l{metalzone}] A Linux server and desktop machine. It is capable of
+ providing most services to the network, including mail, news, web proxying,
+ etc., and of providing services to the Internet at large. It can also
+ provide a powerful and versatile firewall. It should not be kept @c{safe}.
+\item[@l{tubescreamer}] A dual-boot Linux desktop and Windows desktop. It
+ spends most of its time running Windows. It must be kept @c{safe}.
+\item[@l{fuzzface}] A small Linux laptop. It doesn't have enough disk
+ capacity for running services, and wouldn't be around or turned on
+ regularly enough anyway, but it is capable of firewalling itself. We'd
+ like to attach this to a wireless network. It need not be kept @c{safe}
+ and we'd like it to be @c{trusted}.
+\item[@l{guvnor}] An ADSL router. It is capable of providing minimal
+ services, and it has a fairly powerful firewall built-in. It must not be
+ kept @c{safe}.
+\item[@l{evolution}] (Not yet commissioned.) A wireless access point. It is
+ capable of running Linux, but due to limited memory capacity cannot provide
+ many services. It has a powerful and versatile firewall. It cannot be
+ kept @c{safe}.
+\end{description}
+
+We may also have guest machines. We suspect that keeping these @c{safe}
+would be onerous to our guests, requiring configuration of web proxies and
+suchlike. Guest machines can probably be @c{trusted}: violations of this
+trust can be rectified using a cluebat.
+
+%%%--------------------------------------------------------------------------
+\section{Structure}
+
+We require the following physical networks.
+\begin{itemize}
+\item A (wired) Ethernet, for the permanent desktop machines and servers, and
+ for any guest hosts which need physical wiring.
+\item A wireless Ethernet, for laptops.
+\end{itemize}
+
+
+\subsection{The wired network}
+
+Some hosts on our wired network (particularly @l{tubescreamer}) must be
+@c{safe}; others (e.g., @l{metalzone}) must not in order for them to do their
+jobs. It is tempting to split the wired network into two parts: @c{unsafe}
+and @c{safe}. But this introduces a new potential point of failure, and
+anyway fails to acknowledge the fact that both sides are already @c{trusted}.
+
+
+\subsection{The wireless network}
+
+It is important to note that the security provided by wireless networks is
+minimal, and cannot be relied upon. Therefore a wireless network must be
+both @c{untrusted} and @c{unsafe}. We may allow unrestricted communication
+with the global Internet, and to other @c{unsafe} networks, though hosts on
+the wireless network must not be allowed to communicate with @c{safe}
+networks.
+
+This restriction is annoying, and motivates us to introduce a @/virtual
+private network/, providing authentication and encryption; hosts on the VPN
+can be @c{trusted}, since we know who they are and (ideally) how they're
+configured.
+
+
+\subsection{Virtual private networks}
+
+As discussed earlier, we want a VPN so that hosts attached to the wireless
+network can communicate with @c{safe} hosts. Also, we wish to participate in
+the Sinister Green VPN. This introduces two kinds of VPN: our own can be
+@c{trusted}, but the SGVPN should not be.
+
+The question arises: should our VPN be @c{safe}? We can see no particular
+reasons why it shouldn't be: after all, a host on the VPN already has a route
+to the global Internet (either it's communicating with us over the Internet
+already, or it's on some @c{unsafe} network).
+
+Finally, we wish to provide some @/emulated hosts/, running old operating
+systems; for example, a machine running ITS.%
+ \footnote{The Incompatible Timesharing System -- an old PDP--10 operating
+ system, which hosted MACLISP and the original EMACS implementation.}
+Such old operating systems are likely to have major security problems, and
+should be kept @c{safe} from outside attack. It seems reasonable to place
+these emulated hosts in the @l{virtual} network, since (a)~we've just
+determined that @l{virtual} hosts should be @c{safe}, and (b)~emulated hosts
+are `virtual' in a sense anyway.
+
+
+%%%--------------------------------------------------------------------------
+\section{Networks and numbering}
+
+We therefore have the following networks.
+\begin{description}
+\item[@l{fretwank} (wired, @c{safe}/@c{unsafe} mix)] Contains @l{guvnor}
+ (router to the Internet and main firewall), @l{metalzone} (main server),
+ @l{evolution} (wireless router), and @l{tubescreamer}. Also contains guest
+ machines allocated addresses by DHCP.
+\item[@l{wireless} (wireless, @c{untrusted})] Contains @l{fuzzface}, at least
+ sometimes, and a number of guest machines allocated addresses by DHCP;
+ @l{evolution} is its router.
+\item[@l{virtual} (virtual, @c{safe})] Contains @l{fuzzface} again, and
+ possibly various other hosts. Not really a proper network: more a random
+ collection of point-to-point associations. No dynamic allocation required.
+\end{description}
+See figure~\ref{fig:network} for a diagrammatic representation of the
+network, and how the various hosts fit into it.
+
+\begin{figure}
+ \[\begin{xy}
+ 0; <1cm, 0cm>:
+ (0, 0) ="fwA"; (11, 0) ="fwB" **[butt][|3pt][=NET]@{-},
+ ?(.5) ="fwM" ?(.18) ="fwX" ?(.82) ="fwY",
+ "fwM" *+!U\cbox{@l{fretwank} (172.29.199.0/25)},
+ "fwM" + (0, 2) *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>]
+ \cbox{@l{guvnor} \\ 83.105.60.35 \\ 172.29.199.1} ="guvnor",
+ "guvnor"; "fwM" **@{-},
+ "guvnor"; + (0, 4)
+ *+=(4, 3)[o][F][F*:red] \cbox{Global \\ Internet}
+ **@{-} ?<>(.5) *@{//} *+!L{A},
+ "fwY"; p + (0, 2)
+ *+=(3, 1.5)[F:<12pt>]\cbox{(DHCP guests)}
+ **@{-},
+ "fwY"; p - (0, 2)
+ *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>]
+ \cbox{@l{evolution} \\ 172.29.198.1 \\ 172.29.199.3} ="evolution"
+ **@{-},
+ "fwX"; p + (0, 2)
+ *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>]
+ \cbox{@l{tubescreamer} \\ 172.29.199.65}
+ **@{-},
+ "fwX"; p - (0, 2)
+ *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>]
+ \cbox{@l{metalzone} \\ 172.29.199.2} ="metalzone"
+ **@{-},
+ "metalzone" + (-3, 1) ="sgvpnA"; p - (0, 10) ="sgvpnB" **[NET]@{-},
+ ?(.5) ="sgvpnM",
+ "sgvpnM" *[left]+!R\cbox{SGO VPN (various RFC1918 addresses)},
+ "metalzone"; p - (3, 0) **@{-} ?<>(.5) *@{//} *+!U{B},
+ "metalzone" + (3, 1) ="vpnA"; p - (0, 8) ="vpnB" **[NET]@{-},
+ ?(.5) ="vpnM",
+ "vpnM" *[left]+!L\cbox{@l{virtual} (172.29.199.128/28)},
+ "metalzone"; p + (3, 0) **@{-} ?<>(.5) *@{//} *+!U{C},
+ "metalzone" - (0, 2)
+ *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>]
+ \cbox{@l{fuzzface} \\ 172.29.199.129} ="fuzzface";
+ p + (3, 0) **@{-},
+ "fuzzface" - (0, 2)
+ *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>]
+ \cbox{@l{mz} \\ 172.29.199.130} ="mz";
+ p + (3, 0) **@{-},
+ "mz" - (0, 2)
+ *+=(3, 1.5)[F:<12pt>]\cbox{(VPN hosts)} ="x";
+ p + (3, 0) **@{-},
+ "x" - (0, 2)
+ *+=(3, 1.5)[F:<12pt>]\cbox{(SGO hosts)} ="x";
+ p - (3, 0) **@{-},
+ "evolution" + (3, 1) ="wlanA"; p - (0, 4) ="wlanB" **[NET]@{-},
+ ?(.5) ="wlanM",
+ "wlanM" *[left]+!L\cbox{@l{wireless} (172.29.198.0/26)},
+ "evolution"; p + (3, 0) **@{-} ?<>(.5) *@{//} *+!U{D},
+ "evolution" - (0, 2)
+ *+=(3, 1.5)[F:<12pt>]\cbox{(DHCP guests)};
+ p + (3, 0) **@{-},
+ \end{xy}\]
+
+ \caption{Diagram of @l{distorted.org.uk} networks}
+ \label{fig:network}
+\end{figure}
+
+We must assign address ranges to these networks. The @l{distorted.org.uk}
+domain has a block of 512 addresses allocated from the Cambridge G-RIN:
+172.29.198.0/23. The low 256 addresses, 172.29.198.0/24, are used for
+@c{untrusted} hosts; the upper addresses, 172.29.199.0/24, are used for
+@c{trusted} and @c{safe} hosts.
+
+The @c{untrusted} address range is currently only used for the @l{wireless}
+network. It is allocated 64 addresses. This seems relatively generous:
+however, there is no small practical limit (such as the number of available
+ports on switches or hubs) on the number of hosts which can join the network.
+Since hosts on the network are granted temporary addresses via DHCP, the
+network can be resized relatively easily by reconfiguring @l{evolution}: a
+major flag day is not necessary.
+
+The @c{trusted} network is more difficult. We start with the wired Ethernet
+@l{fretwank}. The number of hosts which can join the Ethernet is limited by
+the number of available ports on the various switches and hubs. Currently we
+have
+\begin{itemize}
+\item 4 ports on @l{guvnor}'s built-in switch,
+\item 8 ports on a Netgear fast Ethernet switch, and
+\item 16 ports on an old 10baseT hub,
+\end{itemize}
+for a total of 28 ports. (In fact, the total is only 24, since four of the
+ports would be used up joining the hub and switches together.) Hence, a
+single block of 32 addresses would suffice. However, this makes
+administration difficult. Instead, we allocate @/four/ groups of 32
+addresses:
+\begin{itemize}
+\item a group for @c{trusted} but @c{unsafe} hosts with fixed addresses, used
+ for servers and routers;
+\item a group for @c{safe} hosts with fixed addresses, used for our
+ vulnerable workstations;
+\item a group for @c{trusted} but @c{unsafe} hosts with addresses dynamically
+ allocated by DHCP, for guests; and
+\item a group of addresses reserved for some currently unforeseen purpose.
+\end{itemize}
+
+The VPN is at this stage allocated 32 addresses. This can be increased
+easily should the need arise; but we envisage that the various VPN hosts will
+each need individual treatment in the firewall rules.
+
+The network address allocations are shown in detail in
+table~\ref{tab:addresses}.
+
+\begin{table}
+ \begin{tabular}[C]{|lll|} \hlx{hv}
+ @*Network* & @*Status* & @*Address range* \\ \hlx{vhv}
+ @l{wireless} & @c{Untrusted} & 172.29.198.0/26 (64) \\ \hlx{v}
+ @l{fretwank} & Mixture & 172.29.199.0/25 (128) \\
+ \quad Unsafe, fixed & @c{Trusted} & 172.29.199.0/27 (32) \\
+ \quad Unsafe, DHCP & @c{Trusted} & 172.29.199.32/27 (32) \\
+ \quad Safe & @c{Safe} & 172.29.199.64/27 (32) \\
+ \quad Reserved & --- & 172.29.199.96/27 (32) \\ \hlx{v}
+ @l{virtual} & @c{Safe} & 172.29.199.128/27 (32) \\ \hlx{v}
+ Reserved & --- & $\vcenter{
+ \hbox{172.29.199.160/27 (32)}
+ \hbox{172.29.199.192/26 (64)}
+ } \Bigr\}$ (96) \\ \hlx{vh}
+ \end{tabular}
+
+ \caption{Network address allocations}
+ \label{tab:addresses}
+\end{table}
+
+
+%%%--------------------------------------------------------------------------
+\section{Firewall considerations}
+
+We filter network traffic at four points, shown as
+`$\begin{xy}*+@{//}\end{xy}$' in figure~\ref{fig:network}:
+\begin{itemize}
+\item at the boundary with the global Internet, at @l{guvnor} ($A$);
+\item at the join between the @l{wireless} network and our @c{trusted}
+ networks, at @l{evolution} ($D$); and
+\item at the join between the VPNs and our @c{trusted} networks, ($B$ and
+ $C$).
+\end{itemize}
+(Technically, since we trust hosts on @l{virtual}, we needn't introduce
+filtering between it and @l{fretwank}, but doing so is cheap and relatively
+easy, and it does little harm.)
+
+The main purpose of the firewalls is to protect the hosts which are supposed
+to be @c{safe}. Their secondary purposes are to act as an additional
+protection for @c{trusted} hosts providing services, and to limit access to
+some services to @c{trusted} hosts only.
+
+
+\subsection{Externally visible services}
+
+The server @l{metalzone} provides a number of services which need to be
+externally available: these are shown in table~\ref{tab:services}.
+
+\begin{table}
+ \centering
+ \begin{minipage}{0.8\textwidth}
+ \begin{tabular}[C]{|*{3}{ll|}} \hlx{hv}
+ @*Service* & @*Port(s)* &
+ @*Service* & @*Port(s)* &
+ @*Service* & @*Port(s)* \\ \hlx{vhv}
+ FTP & TCP 20, 21 & SSH & TCP 22 & SMTP & TCP 25 \\
+ DNS & TCP/UDP 53 & Finger & TCP 79 & HTTP & TCP 80 \\
+ Ident & TCP 113 & NTP & UDP 123%
+ %%\footnote{Only to upstream ISP's time servers.}
+ & HTTPS & TCP 443 \\
+ TrIPE & UDP 22\,003
+ & \multicolumn{2}{c|}{---}
+ & \multicolumn{2}{c|}{---} \\ \hlx{vh}
+ \end{tabular}
+ \end{minipage}
+
+ \caption{Externally visible services}
+ \label{tab:services}
+\end{table}
+
+Additionally, @l{metalzone} provides a web proxy on port 3128 which should be
+available to all hosts, including @c{untrusted} hosts, whose connection to
+the global Internet is via @l{guvnor}. (Allowing external users to use the
+proxy is bad, because they can eat up our 'net connection bandwidth very
+easily. Disallowing @c{untrusted} hosts from using the proxy is silly,
+though, since they can @/already/ gobble the 'net connection, and using the
+proxy may help reduce the impact of many users.)
+
+Finally, @l{metalzone} supports active FTP, and occasionally other temporary
+services, on high-numbered ports. TCP and UDP ports with numbers in the
+range 32\,000--65\,535 should be left unfiltered.
+
+
+\subsection{Trusted protocols}
+
+All hosts, including @c{safe} hosts, are permitted to contact any address on
+TCP port~22, for the purpose of setting up an SSH connection. (Messing about
+with proxies for SSH is too tedious.) So that this can stand a chance of
+working properly, we also allow ICMP. This isn't, perhaps, ideal, but all
+manner of things go wrong if ICMP is blocked. Besides, it means that @/ping/
+is likely to work, which is also useful.
+
+
+
+
+%%% A
+%%% 1. Packets from WAN
+%%% if src-addr in rfc1918-addresses: DROP
+%%% if src-addr in localnet: DROP
+%%% if src-addr == guvnor.demon: DROP
+%%% if dest-addr not in distorted-net: DROP
+%%% if protocol == icmp: ACCEPT
+%%% if protocol == tcp and src-port == 22 and ack: ACCEPT
+%%% if dest-addr in fretwank-safe: DROP
+%%% if dest-addr in vpn: DROP
+%%% if protocol == tcp and ack: ACCEPT
+%%% if dest-addr == metalzone.fretwank and
+%%% protocol/dest-port in external-services:
+%%% ACCEPT
+%%% DENY
+%%%
+%%% 2. Packets from LAN
+%%% if src-addr not in distorted-net: DROP
+%%% ACCEPT
+
+%%% D
+%%% 1. Packets from WLAN
+%%% if src-addr not in wireless: DROP
+%%% if dest-addr not in distorted-net: DROP
+%%% if protocol == icmp: ACCEPT
+%%% if protocol == tcp and src-port == 22 and ack: ACCEPT
+%%% if dest-addr in fretwank-safe: DROP
+%%% if dest-addr in vpn: DROP
+%%% if protocol == tcp and ack: ACCEPT
+%%% if dest-addr == metalzone.fretwank and
+%%% (protocol/dest-port in external-services or
+%%% protocol == tcp and dest-port == 3128):
+%%% ACCEPT
+%%% DENY
+%%%
+
+
+\end{document}
~mdw / zones / commitdiff