| 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} |