chiark / gitweb /
Merge branch 'master' of git+ssh://metalzone.distorted.org.uk/~mdw/public-git/zones/
[zones] / distorted.tex
CommitLineData
35f3af25
MW
1%&distorted
2
3\ifx\dumped\xxundefined
4
e80b4c2d
MW
5\documentclass[article, a4paper, 10pt, notitlepage, numbering]{strayman}
6\usepackage[palatino, helvetica, maths=cmr]{mdwfonts}
7\usepackage[T1]{fontenc}
8\usepackage{at}
9\usepackage[mdwmargin]{mdwthm}
10\usepackage{mdwtab}
11\usepackage[all, dvips]{xy}
12
13\atdef l#1{{\normalfont\sffamily #1}}
14\atdef c#1{\textbf{#1}}
15
16\newtheorem*{observation}{Observation}
17
18\def\cbox#1{%
19 \vbox{%
20 \let\\\cr%
21 \halign{%
22 \hfil\strut\ignorespaces##\unskip\hfil\cr%
23 #1%
24 \crcr%
25 }%
26 }%
27}
28
29\errorcontextlines=999
30
35f3af25
MW
31\let\dumped\relax\expandafter\dump\fi
32
e80b4c2d
MW
33\begin{document}
34\title{@l{distorted.org.uk} network design}
35\author{Mark Wooding}
36\maketitle
37
38\thispagestyle{empty}
39\pagestyle{empty}
40
41\tableofcontents
42\listoffigures
43\listoftables
44
45\clearpage
46\pagestyle{fancy}
47
48%%%--------------------------------------------------------------------------
49\section{Concepts}
50
51We begin by defining our basic concepts.
52\begin{description}
53\item[@c{Safe}] A @c{safe} network is one whose hosts are protected from
54 potentially dangerous network traffic. Hosts on a @c{safe} network may
55 communicate only (a) using trusted protocols (e.g., SSH) or (b) with
56 @c{trusted} hosts.
57\item[@c{Trusted}] A @c{trusted} network is one whose hosts are permitted to
58 communicate with @c{safe} networks.
59\end{description}
60
61\begin{observation}
62 It is impossible to protect hosts on a @c{safe} network from each other.
63 Therefore, a @c{safe} network must be @c{trusted}. As an immediate
64 corollary, an @c{untrusted} network cannot be @c{safe}.
65\end{observation}
66
67We therefore distinguish three types of networks:
68\begin{enumerate}
69\item @c{Safe}, and therefore @c{trusted}.
70\item @c{Trusted} but @c{unsafe}.
71\item @c{Untrusted}, and therefore @c{unsafe}.
72\end{enumerate}
73
74
75%%%--------------------------------------------------------------------------
76\section{Existing hosts}
77
78We have the following hosts. All of them should be @c{trusted}.
79\begin{description}
80\item[@l{metalzone}] A Linux server and desktop machine. It is capable of
81 providing most services to the network, including mail, news, web proxying,
82 etc., and of providing services to the Internet at large. It can also
83 provide a powerful and versatile firewall. It should not be kept @c{safe}.
84\item[@l{tubescreamer}] A dual-boot Linux desktop and Windows desktop. It
85 spends most of its time running Windows. It must be kept @c{safe}.
86\item[@l{fuzzface}] A small Linux laptop. It doesn't have enough disk
87 capacity for running services, and wouldn't be around or turned on
88 regularly enough anyway, but it is capable of firewalling itself. We'd
89 like to attach this to a wireless network. It need not be kept @c{safe}
90 and we'd like it to be @c{trusted}.
91\item[@l{guvnor}] An ADSL router. It is capable of providing minimal
92 services, and it has a fairly powerful firewall built-in. It must not be
93 kept @c{safe}.
94\item[@l{evolution}] (Not yet commissioned.) A wireless access point. It is
95 capable of running Linux, but due to limited memory capacity cannot provide
96 many services. It has a powerful and versatile firewall. It cannot be
97 kept @c{safe}.
98\end{description}
99
100We may also have guest machines. We suspect that keeping these @c{safe}
101would be onerous to our guests, requiring configuration of web proxies and
102suchlike. Guest machines can probably be @c{trusted}: violations of this
103trust can be rectified using a cluebat.
104
105%%%--------------------------------------------------------------------------
106\section{Structure}
107
108We require the following physical networks.
109\begin{itemize}
110\item A (wired) Ethernet, for the permanent desktop machines and servers, and
111 for any guest hosts which need physical wiring.
112\item A wireless Ethernet, for laptops.
113\end{itemize}
114
115
116\subsection{The wired network}
117
118Some hosts on our wired network (particularly @l{tubescreamer}) must be
119@c{safe}; others (e.g., @l{metalzone}) must not in order for them to do their
120jobs. It is tempting to split the wired network into two parts: @c{unsafe}
121and @c{safe}. But this introduces a new potential point of failure, and
122anyway fails to acknowledge the fact that both sides are already @c{trusted}.
123
124
125\subsection{The wireless network}
126
127It is important to note that the security provided by wireless networks is
128minimal, and cannot be relied upon. Therefore a wireless network must be
129both @c{untrusted} and @c{unsafe}. We may allow unrestricted communication
130with the global Internet, and to other @c{unsafe} networks, though hosts on
131the wireless network must not be allowed to communicate with @c{safe}
132networks.
133
134This restriction is annoying, and motivates us to introduce a @/virtual
135private network/, providing authentication and encryption; hosts on the VPN
136can be @c{trusted}, since we know who they are and (ideally) how they're
137configured.
138
139
140\subsection{Virtual private networks}
141
142As discussed earlier, we want a VPN so that hosts attached to the wireless
143network can communicate with @c{safe} hosts. Also, we wish to participate in
144the Sinister Green VPN. This introduces two kinds of VPN: our own can be
145@c{trusted}, but the SGVPN should not be.
146
147The question arises: should our VPN be @c{safe}? We can see no particular
148reasons why it shouldn't be: after all, a host on the VPN already has a route
149to the global Internet (either it's communicating with us over the Internet
150already, or it's on some @c{unsafe} network).
151
152Finally, we wish to provide some @/emulated hosts/, running old operating
153systems; for example, a machine running ITS.%
154 \footnote{The Incompatible Timesharing System -- an old PDP--10 operating
155 system, which hosted MACLISP and the original EMACS implementation.}
156Such old operating systems are likely to have major security problems, and
157should be kept @c{safe} from outside attack. It seems reasonable to place
158these emulated hosts in the @l{virtual} network, since (a)~we've just
159determined that @l{virtual} hosts should be @c{safe}, and (b)~emulated hosts
160are `virtual' in a sense anyway.
161
162
163%%%--------------------------------------------------------------------------
164\section{Networks and numbering}
165
166We therefore have the following networks.
167\begin{description}
168\item[@l{fretwank} (wired, @c{safe}/@c{unsafe} mix)] Contains @l{guvnor}
169 (router to the Internet and main firewall), @l{metalzone} (main server),
170 @l{evolution} (wireless router), and @l{tubescreamer}. Also contains guest
171 machines allocated addresses by DHCP.
172\item[@l{wireless} (wireless, @c{untrusted})] Contains @l{fuzzface}, at least
173 sometimes, and a number of guest machines allocated addresses by DHCP;
174 @l{evolution} is its router.
175\item[@l{virtual} (virtual, @c{safe})] Contains @l{fuzzface} again, and
176 possibly various other hosts. Not really a proper network: more a random
177 collection of point-to-point associations. No dynamic allocation required.
178\end{description}
179See figure~\ref{fig:network} for a diagrammatic representation of the
180network, and how the various hosts fit into it.
181
182\begin{figure}
183 \[\begin{xy}
184 0; <1cm, 0cm>:
185 (0, 0) ="fwA"; (11, 0) ="fwB" **[butt][|3pt][=NET]@{-},
186 ?(.5) ="fwM" ?(.18) ="fwX" ?(.82) ="fwY",
187 "fwM" *+!U\cbox{@l{fretwank} (172.29.199.0/25)},
188 "fwM" + (0, 2) *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>]
189 \cbox{@l{guvnor} \\ 83.105.60.35 \\ 172.29.199.1} ="guvnor",
190 "guvnor"; "fwM" **@{-},
191 "guvnor"; + (0, 4)
192 *+=(4, 3)[o][F][F*:red] \cbox{Global \\ Internet}
193 **@{-} ?<>(.5) *@{//} *+!L{A},
194 "fwY"; p + (0, 2)
195 *+=(3, 1.5)[F:<12pt>]\cbox{(DHCP guests)}
196 **@{-},
197 "fwY"; p - (0, 2)
198 *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>]
199 \cbox{@l{evolution} \\ 172.29.198.1 \\ 172.29.199.3} ="evolution"
200 **@{-},
201 "fwX"; p + (0, 2)
202 *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>]
203 \cbox{@l{tubescreamer} \\ 172.29.199.65}
204 **@{-},
205 "fwX"; p - (0, 2)
206 *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>]
207 \cbox{@l{metalzone} \\ 172.29.199.2} ="metalzone"
208 **@{-},
209 "metalzone" + (-3, 1) ="sgvpnA"; p - (0, 10) ="sgvpnB" **[NET]@{-},
210 ?(.5) ="sgvpnM",
211 "sgvpnM" *[left]+!R\cbox{SGO VPN (various RFC1918 addresses)},
212 "metalzone"; p - (3, 0) **@{-} ?<>(.5) *@{//} *+!U{B},
213 "metalzone" + (3, 1) ="vpnA"; p - (0, 8) ="vpnB" **[NET]@{-},
214 ?(.5) ="vpnM",
215 "vpnM" *[left]+!L\cbox{@l{virtual} (172.29.199.128/28)},
216 "metalzone"; p + (3, 0) **@{-} ?<>(.5) *@{//} *+!U{C},
217 "metalzone" - (0, 2)
218 *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>]
219 \cbox{@l{fuzzface} \\ 172.29.199.129} ="fuzzface";
220 p + (3, 0) **@{-},
221 "fuzzface" - (0, 2)
222 *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>]
223 \cbox{@l{mz} \\ 172.29.199.130} ="mz";
224 p + (3, 0) **@{-},
225 "mz" - (0, 2)
226 *+=(3, 1.5)[F:<12pt>]\cbox{(VPN hosts)} ="x";
227 p + (3, 0) **@{-},
228 "x" - (0, 2)
229 *+=(3, 1.5)[F:<12pt>]\cbox{(SGO hosts)} ="x";
230 p - (3, 0) **@{-},
231 "evolution" + (3, 1) ="wlanA"; p - (0, 4) ="wlanB" **[NET]@{-},
232 ?(.5) ="wlanM",
233 "wlanM" *[left]+!L\cbox{@l{wireless} (172.29.198.0/26)},
234 "evolution"; p + (3, 0) **@{-} ?<>(.5) *@{//} *+!U{D},
235 "evolution" - (0, 2)
236 *+=(3, 1.5)[F:<12pt>]\cbox{(DHCP guests)};
237 p + (3, 0) **@{-},
238 \end{xy}\]
239
240 \caption{Diagram of @l{distorted.org.uk} networks}
241 \label{fig:network}
242\end{figure}
243
244We must assign address ranges to these networks. The @l{distorted.org.uk}
245domain has a block of 512 addresses allocated from the Cambridge G-RIN:
246172.29.198.0/23. The low 256 addresses, 172.29.198.0/24, are used for
247@c{untrusted} hosts; the upper addresses, 172.29.199.0/24, are used for
248@c{trusted} and @c{safe} hosts.
249
250The @c{untrusted} address range is currently only used for the @l{wireless}
251network. It is allocated 64 addresses. This seems relatively generous:
252however, there is no small practical limit (such as the number of available
253ports on switches or hubs) on the number of hosts which can join the network.
254Since hosts on the network are granted temporary addresses via DHCP, the
255network can be resized relatively easily by reconfiguring @l{evolution}: a
256major flag day is not necessary.
257
258The @c{trusted} network is more difficult. We start with the wired Ethernet
259@l{fretwank}. The number of hosts which can join the Ethernet is limited by
260the number of available ports on the various switches and hubs. Currently we
261have
262\begin{itemize}
263\item 4 ports on @l{guvnor}'s built-in switch,
264\item 8 ports on a Netgear fast Ethernet switch, and
265\item 16 ports on an old 10baseT hub,
266\end{itemize}
267for a total of 28 ports. (In fact, the total is only 24, since four of the
268ports would be used up joining the hub and switches together.) Hence, a
269single block of 32 addresses would suffice. However, this makes
270administration difficult. Instead, we allocate @/four/ groups of 32
271addresses:
272\begin{itemize}
273\item a group for @c{trusted} but @c{unsafe} hosts with fixed addresses, used
274 for servers and routers;
275\item a group for @c{safe} hosts with fixed addresses, used for our
276 vulnerable workstations;
277\item a group for @c{trusted} but @c{unsafe} hosts with addresses dynamically
278 allocated by DHCP, for guests; and
279\item a group of addresses reserved for some currently unforeseen purpose.
280\end{itemize}
281
282The VPN is at this stage allocated 32 addresses. This can be increased
283easily should the need arise; but we envisage that the various VPN hosts will
284each need individual treatment in the firewall rules.
285
286The network address allocations are shown in detail in
287table~\ref{tab:addresses}.
288
289\begin{table}
290 \begin{tabular}[C]{|lll|} \hlx{hv}
291 @*Network* & @*Status* & @*Address range* \\ \hlx{vhv}
292 @l{wireless} & @c{Untrusted} & 172.29.198.0/26 (64) \\ \hlx{v}
293 @l{fretwank} & Mixture & 172.29.199.0/25 (128) \\
294 \quad Unsafe, fixed & @c{Trusted} & 172.29.199.0/27 (32) \\
295 \quad Unsafe, DHCP & @c{Trusted} & 172.29.199.32/27 (32) \\
296 \quad Safe & @c{Safe} & 172.29.199.64/27 (32) \\
297 \quad Reserved & --- & 172.29.199.96/27 (32) \\ \hlx{v}
298 @l{virtual} & @c{Safe} & 172.29.199.128/27 (32) \\ \hlx{v}
299 Reserved & --- & $\vcenter{
300 \hbox{172.29.199.160/27 (32)}
301 \hbox{172.29.199.192/26 (64)}
302 } \Bigr\}$ (96) \\ \hlx{vh}
303 \end{tabular}
304
305 \caption{Network address allocations}
306 \label{tab:addresses}
307\end{table}
308
309
310%%%--------------------------------------------------------------------------
311\section{Firewall considerations}
312
313We filter network traffic at four points, shown as
314`$\begin{xy}*+@{//}\end{xy}$' in figure~\ref{fig:network}:
315\begin{itemize}
316\item at the boundary with the global Internet, at @l{guvnor} ($A$);
317\item at the join between the @l{wireless} network and our @c{trusted}
318 networks, at @l{evolution} ($D$); and
319\item at the join between the VPNs and our @c{trusted} networks, ($B$ and
320 $C$).
321\end{itemize}
322(Technically, since we trust hosts on @l{virtual}, we needn't introduce
323filtering between it and @l{fretwank}, but doing so is cheap and relatively
324easy, and it does little harm.)
325
326The main purpose of the firewalls is to protect the hosts which are supposed
327to be @c{safe}. Their secondary purposes are to act as an additional
328protection for @c{trusted} hosts providing services, and to limit access to
329some services to @c{trusted} hosts only.
330
331
332\subsection{Externally visible services}
333
334The server @l{metalzone} provides a number of services which need to be
335externally available: these are shown in table~\ref{tab:services}.
336
337\begin{table}
338 \centering
339 \begin{minipage}{0.8\textwidth}
340 \begin{tabular}[C]{|*{3}{ll|}} \hlx{hv}
341 @*Service* & @*Port(s)* &
342 @*Service* & @*Port(s)* &
343 @*Service* & @*Port(s)* \\ \hlx{vhv}
344 FTP & TCP 20, 21 & SSH & TCP 22 & SMTP & TCP 25 \\
345 DNS & TCP/UDP 53 & Finger & TCP 79 & HTTP & TCP 80 \\
346 Ident & TCP 113 & NTP & UDP 123%
347 %%\footnote{Only to upstream ISP's time servers.}
348 & HTTPS & TCP 443 \\
4acd4890 349 rsync & TCP 873 & GIT & TCP 9418 & TrIPE & UDP 22\,003 \\ \hlx{vh}
e80b4c2d
MW
350 \end{tabular}
351 \end{minipage}
352
353 \caption{Externally visible services}
354 \label{tab:services}
355\end{table}
356
357Additionally, @l{metalzone} provides a web proxy on port 3128 which should be
358available to all hosts, including @c{untrusted} hosts, whose connection to
359the global Internet is via @l{guvnor}. (Allowing external users to use the
360proxy is bad, because they can eat up our 'net connection bandwidth very
361easily. Disallowing @c{untrusted} hosts from using the proxy is silly,
362though, since they can @/already/ gobble the 'net connection, and using the
363proxy may help reduce the impact of many users.)
364
365Finally, @l{metalzone} supports active FTP, and occasionally other temporary
366services, on high-numbered ports. TCP and UDP ports with numbers in the
367range 32\,000--65\,535 should be left unfiltered.
368
369
370\subsection{Trusted protocols}
371
372All hosts, including @c{safe} hosts, are permitted to contact any address on
373TCP port~22, for the purpose of setting up an SSH connection. (Messing about
374with proxies for SSH is too tedious.) So that this can stand a chance of
375working properly, we also allow ICMP. This isn't, perhaps, ideal, but all
376manner of things go wrong if ICMP is blocked. Besides, it means that @/ping/
377is likely to work, which is also useful.
378
379
380
381
382%%% A
383%%% 1. Packets from WAN
384%%% if src-addr in rfc1918-addresses: DROP
385%%% if src-addr in localnet: DROP
386%%% if src-addr == guvnor.demon: DROP
387%%% if dest-addr not in distorted-net: DROP
388%%% if protocol == icmp: ACCEPT
389%%% if protocol == tcp and src-port == 22 and ack: ACCEPT
390%%% if dest-addr in fretwank-safe: DROP
391%%% if dest-addr in vpn: DROP
392%%% if protocol == tcp and ack: ACCEPT
393%%% if dest-addr == metalzone.fretwank and
394%%% protocol/dest-port in external-services:
395%%% ACCEPT
396%%% DENY
397%%%
398%%% 2. Packets from LAN
399%%% if src-addr not in distorted-net: DROP
400%%% ACCEPT
401
402%%% D
403%%% 1. Packets from WLAN
404%%% if src-addr not in wireless: DROP
405%%% if dest-addr not in distorted-net: DROP
406%%% if protocol == icmp: ACCEPT
407%%% if protocol == tcp and src-port == 22 and ack: ACCEPT
408%%% if dest-addr in fretwank-safe: DROP
409%%% if dest-addr in vpn: DROP
410%%% if protocol == tcp and ack: ACCEPT
411%%% if dest-addr == metalzone.fretwank and
412%%% (protocol/dest-port in external-services or
413%%% protocol == tcp and dest-port == 3128):
414%%% ACCEPT
415%%% DENY
416%%%
417
418
419\end{document}