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