chiark / gitweb /
distorted.lisp: Include nameservers in dhcp subzone.
[zones] / distorted.tex
CommitLineData
e80b4c2d
MW
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
45We 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
61We 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
72We 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
94We may also have guest machines. We suspect that keeping these @c{safe}
95would be onerous to our guests, requiring configuration of web proxies and
96suchlike. Guest machines can probably be @c{trusted}: violations of this
97trust can be rectified using a cluebat.
98
99%%%--------------------------------------------------------------------------
100\section{Structure}
101
102We 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
112Some 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
114jobs. It is tempting to split the wired network into two parts: @c{unsafe}
115and @c{safe}. But this introduces a new potential point of failure, and
116anyway fails to acknowledge the fact that both sides are already @c{trusted}.
117
118
119\subsection{The wireless network}
120
121It is important to note that the security provided by wireless networks is
122minimal, and cannot be relied upon. Therefore a wireless network must be
123both @c{untrusted} and @c{unsafe}. We may allow unrestricted communication
124with the global Internet, and to other @c{unsafe} networks, though hosts on
125the wireless network must not be allowed to communicate with @c{safe}
126networks.
127
128This restriction is annoying, and motivates us to introduce a @/virtual
129private network/, providing authentication and encryption; hosts on the VPN
130can be @c{trusted}, since we know who they are and (ideally) how they're
131configured.
132
133
134\subsection{Virtual private networks}
135
136As discussed earlier, we want a VPN so that hosts attached to the wireless
137network can communicate with @c{safe} hosts. Also, we wish to participate in
138the Sinister Green VPN. This introduces two kinds of VPN: our own can be
139@c{trusted}, but the SGVPN should not be.
140
141The question arises: should our VPN be @c{safe}? We can see no particular
142reasons why it shouldn't be: after all, a host on the VPN already has a route
143to the global Internet (either it's communicating with us over the Internet
144already, or it's on some @c{unsafe} network).
145
146Finally, we wish to provide some @/emulated hosts/, running old operating
147systems; 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.}
150Such old operating systems are likely to have major security problems, and
151should be kept @c{safe} from outside attack. It seems reasonable to place
152these emulated hosts in the @l{virtual} network, since (a)~we've just
153determined that @l{virtual} hosts should be @c{safe}, and (b)~emulated hosts
154are `virtual' in a sense anyway.
155
156
157%%%--------------------------------------------------------------------------
158\section{Networks and numbering}
159
160We 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}
173See figure~\ref{fig:network} for a diagrammatic representation of the
174network, 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
238We must assign address ranges to these networks. The @l{distorted.org.uk}
239domain has a block of 512 addresses allocated from the Cambridge G-RIN:
240172.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
244The @c{untrusted} address range is currently only used for the @l{wireless}
245network. It is allocated 64 addresses. This seems relatively generous:
246however, there is no small practical limit (such as the number of available
247ports on switches or hubs) on the number of hosts which can join the network.
248Since hosts on the network are granted temporary addresses via DHCP, the
249network can be resized relatively easily by reconfiguring @l{evolution}: a
250major flag day is not necessary.
251
252The @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
254the number of available ports on the various switches and hubs. Currently we
255have
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}
261for a total of 28 ports. (In fact, the total is only 24, since four of the
262ports would be used up joining the hub and switches together.) Hence, a
263single block of 32 addresses would suffice. However, this makes
264administration difficult. Instead, we allocate @/four/ groups of 32
265addresses:
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
276The VPN is at this stage allocated 32 addresses. This can be increased
277easily should the need arise; but we envisage that the various VPN hosts will
278each need individual treatment in the firewall rules.
279
280The network address allocations are shown in detail in
281table~\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
307We 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
317filtering between it and @l{fretwank}, but doing so is cheap and relatively
318easy, and it does little harm.)
319
320The main purpose of the firewalls is to protect the hosts which are supposed
321to be @c{safe}. Their secondary purposes are to act as an additional
322protection for @c{trusted} hosts providing services, and to limit access to
323some services to @c{trusted} hosts only.
324
325
326\subsection{Externally visible services}
327
328The server @l{metalzone} provides a number of services which need to be
329externally 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 \\
4acd4890 343 rsync & TCP 873 & GIT & TCP 9418 & TrIPE & UDP 22\,003 \\ \hlx{vh}
e80b4c2d
MW
344 \end{tabular}
345 \end{minipage}
346
347 \caption{Externally visible services}
348 \label{tab:services}
349\end{table}
350
351Additionally, @l{metalzone} provides a web proxy on port 3128 which should be
352available to all hosts, including @c{untrusted} hosts, whose connection to
353the global Internet is via @l{guvnor}. (Allowing external users to use the
354proxy is bad, because they can eat up our 'net connection bandwidth very
355easily. Disallowing @c{untrusted} hosts from using the proxy is silly,
356though, since they can @/already/ gobble the 'net connection, and using the
357proxy may help reduce the impact of many users.)
358
359Finally, @l{metalzone} supports active FTP, and occasionally other temporary
360services, on high-numbered ports. TCP and UDP ports with numbers in the
361range 32\,000--65\,535 should be left unfiltered.
362
363
364\subsection{Trusted protocols}
365
366All hosts, including @c{safe} hosts, are permitted to contact any address on
367TCP port~22, for the purpose of setting up an SSH connection. (Messing about
368with proxies for SSH is too tedious.) So that this can stand a chance of
369working properly, we also allow ICMP. This isn't, perhaps, ideal, but all
370manner of things go wrong if ICMP is blocked. Besides, it means that @/ping/
371is 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}