==============
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
PURPOSE:
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.
OVERALL DESIGN:
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
SYSTEM SPECIFICATIONS:
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.
FILTER RULES:
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).
REASON FOR AN EXTERNAL/INTERNAL DNS SERVERS:
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.
DRAWBACKS OF THIS SETUP:
If a proxy server was used the filtering would be even easier, and
more secure. Securing against servers runing on ports above 1023 is
difficult.
NOTE ON THE DNS SETUP:
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.
NOTES ON THE SMTP/POP 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).
ANOTHER IDEA:
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.
SOME LAST NOTES:
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.
Posts
No comments:
Post a Comment