Sunday, July 24, 2011

A post for posterities sake: My 1998 mailing list debate over secure network design

When reading this please bear in mind this was '98 during original .com boom when it looked like money would be abundant to anyone with a modicum of computer knowledge and I was still in college.  I actually received a job offer from the State Department as a result of this posting, but, stupidly, turned it down.  C'est la vie.

Some new ideas came to mind and I added them to my proposal.  As usual any
comments are appreciated.  Here's the latest proposal:

Secure Network Initiative for Small Networks
Revision 1.0
January 15, 1998
by Geoffrey J. Gowey

This is a proposed setup for a securing a network for administrators on a
low budget (those that don't want to by a firewall and other security
devices) and that want one up fast.  The strength of this setup relies on 
two filters and the rules used for filtering (it's not perfect, but it's 
better than nothing).  The other advantage is that it puts some of the old 
junkboxes that many instutions have to use. 

IMPORTANT: This setup is aimed for small setups (100-150 nodes) using a
single T-1.


         Internet Connection
    External Filter
    | DMZ
   | Web Server   |
   | SMTP/POP server  |
   | Primary external DNS server |
   | Secondary external DNS server |
   | Anonymous FTP server (optional)|
   Internal Filter
     Log host (optional)
   Internal Network
      Primary internal DNS server
     everything else

 External Filter:
  Either a filter router (CISCO, HP, etc.) or a system with
  the following specs:
  P-75 64MB RAM (maybe more RAM and a faster CPU
   depending on the network load)
  Any filtering setup (NetBSD w/ ipf rules, FreeBSD,
   Karlbridge/Karlbrouter, etc.)
  Two ethernet cards that work with the filtering software.
  A printer to log rejected packets (preferably dot matrix or 
   daisy wheel) and A LOT of paper.
 Internal Filter:
  same setup.
 Web server:
  Get a package and meet the requirements.
  My preference is NetBSD w/ Apache.
  With NetBSD a 486 with 8 or 16 MB RAM should be adequate.
 SMTP/POP server:
  Get an 486 that meets NetBSD's or FreeBSD's installation
  requirements, and a POP server.
 The DNS servers:
  Nearly same config as the SMTP/POP server, but a 386 can be 
  used instead of a 486, and a POP server is not needed.
 FTP server:
  Same config as the SMTP/POP server, but no POP needed.
 Log host:
  Old 386 running NetBSD, FreeBSD, etc. (just about anything
  that can catch syslog UDP packets).  Although a 486 might be 
  better since a large HDD will be needed.  

 External Filter:
  From Practical UNIX & Internet Security[Garfinkel&Spafford]:
  Block packets for services that you do not wish to cross
your firewall.
  Block packets that have IP source routing or that have
other "unusual" options set.
  (my idea on this) Just about all TCP services except WWW
and FTP.  Just about all UDP services except DNS.
  (modified) Block inbound packets with a source address of 
any systems in the DMZ, internal network, or routers (anti-spoofing).
  (my idea) Block inbound packets with a destination of the
internal DNS server.

 Internal Filter:
   From Practical UNIX & Internet Security[Garfinkel&Spafford]:
   Block packets for services that you do not wish to cross
your firewall.
   (my idea) almost the same rules as above, except allow UDP
for syslog (port 514) destined for the loghost (and only for the loghost) in
   and ONLY from systems in the DMZ. 
   Block packets that have IP source routing or that have
other "unusual" options set.
   (modified) Block packets addressed to your filters.
   (my idea) block outbound DNS packets destined for the
external dns primary/secondary servers from everything except the internal
primary DNS server.
   (my idea) block inbound packets lower than port 1023
without the ACK bit set (this will cause the remaining packets to be
ignored).  Thanks to Chapman and Zwicky for this idea.  Reason: doesn't
allow people on the outside to access FTP, HTTP, and anything else using TCP
on the inside using ports less than 1023.  Only problem: X-Windows Servers, 
and any server sitting higher than port 1023 (such as IRC, DOOM Servers, 
QUAKE Servers, Netscape's Admin for its web server (I believe, could be wrong),
and some other things).  However, with things like DOOM and QUAKE I think
the majority of the traffic is UDP so they should be blocked by virtue of
the UDP filtering rules (but I'm not sure).

 My reason for such separation is that it only allows people have
immediate access to systems in the DMZ (hackers would have to sniff packets
to figure out the remainder of the setup).  The external/internal setup also
allows some added flexibility and security.

 If a proxy server was used the filtering would be even easier, and
more secure.  Securing against servers runing on ports above 1023 is

 The way to have the DNS working is to have internal traffic ask the
internal DNS server and if the internal DNS server doesn't know the (the
internal DNS server) should ask the external primary DNS server.

 For security reasons I think it might be a good idea to have e-mail
addresses and passwords different than the login name and login passwords
(this'll leave a cracker out of luck if the server is sniffed or cracked). 
Also, if possible, use APOP (authenticated POP) since normal POP transmits
passwords in the clear (APOP sends them encrypted).

 If the systems in the DMZ have packet filtering support native to
them (e.g. NetBSD, FreeBSD, Linux, whatever) or if it's availiable then set
it so it can't accept inbound packets with a source of address of its own.
If one of the systems is cracked (e.g. the webserver) it'll prevent that
system from being used to easially hijack another.

 As is noted in many books all of these systems should be in a
secured area.  PHYSICAL SECURITY IS VERY IMPORTANT!  Using programs like
COPS or Tripwire is advise for the Web and SMTP/POP servers (and check
regularly).  This will assist in making sure that your system has not been
tampered with.

No comments:

Post a Comment