Re: Firewall in an internet-caffe
Hmmmm ... it looks to me like you have some potential problems you are
unaware of at the routing (not the firewalling) level.
You say you have 32 IP addresses, presumably ranging from a.b.c.0 to
a.b.c.31. You lose two as the network address (.0) and the broadcast address
(.31), giving you 30 addresses to work with.
Now as described, the 30 available addresses are all on the same network.
>From your diageam, I'm not sure if you intend to use 2 or 3 NICs -- that
is, will the FTP/MAIL/WWW server be on the same LAN as the Windows
workstations or will it be on a separate LAN (commonly called a DMZ in the
world of firewalls)? Either answer gives you problems.
If you put it on the same LAN as your workstations, then your firewalling of
that LAN will necessarily be open to some security risks that are usually
considered unsuitable for a protected LAN.
If you put it on a different LAN, then you have to subnet your address
space. This gets messy, because you can't subnet arbitrarily -- you have to
do it on a power-of-two boundary. So you can subnet into two ranges 0-15,
16-31, or 4 ranges 0-7, 8-15, 16-23, 24-31, or eight ranges 0-3, 4-7 ... and
so on. Each subnet "wastes" an address as the netrwork address and another
as broadcast, so by the time you've subnetted into 8 ranges, you only have
16 of your 32 addresses available for actual assignment to hosts.
While there are many solutions to your problem, I *think* the one I would
try is what is called in some circles "static NAT". With this approach, you
use 3 NICs in the router/firewall, as follows:
eth0 is the external connection to the Internet. It is (I'll
guess; your description isn't actually complete enough
for me to be sure) IP address a.b.c.1 .
eth1 is the internal connection to the DMZ. It uses some
private-address range (e.g., 192.168.1.0/24), and
your FTP/MAIL/WWW server gets an address on that
network. eth1 gets (for example) IP address
192.168.1.1 and that address is the gateway address
for DMZ servers.
eth2 is the internal connection to your "cafe" LAN. It uses
a different private-address range (e.g., 192.168.2.0/24),
and each Windows client cets an address in that range.
eth2 gets (for example) IP address 192.168.2.1 and
that address is te gateway address for the Windows
workstations.
Now, using the "policy routing" features of the 2.2.x kernel (I haven't
checked into what 2.4.x does here), you have the firewall do one-to-one
Network Address Translation for addresses a.b.c.2 to a.b.c.30 (excluding
whatever address is the gateway that the router/firewall itself uses on
eth0), linking each with the appopriate private address on the DMZ or the
"cafe" LAN. If you do it correctly, the router/firewall will then proxy-arp
all the addresses on eth0 and get enveything to and from where it is needed.
This is only one of several ways to do what you want, and since I've had to
guess at some undescribed features of your setup, I may have it wrong. Even
if it is right, there are other approaches, and others here may suggest
them. Whatever the solution, you need to make sure that you can construct a
working routing table that will let both incoming and outgoing connections
work as you want them to.
Now, that's just the routing part of your problem. There is still the
firewalling part. Yes, firewalling (in this context) is just a matter of
setting a bunch of ACCEPTs and DENYs (and REJECTs, possibly). But that isn't
much help; it's like saying that computer programming is just getting the 1s
and 0s in the right order -- true but unintructive. You should look at the
Firewalling HowTo and some standard references on firewalling (a good place
to start is at lrp.c0wz.com, a directory site for Linux Router Project
documents) to get a better feel for the kinds of tradeoffs you need to consider.
As to shell accounts ... the principle behind a DMZ is that ALL connections
initiated offsite go to servers on it ... the workstation LAN only accepts
traffic that comes in reply to connections its host initiate. So shell
accounts would naturally be on a (probably separate) shell server located in
the DMZ.
At 08:39 PM 5/26/01 +0200, IronHand wrote:
>Hello!
>
>I have a little problem here. After reading of 'Security: port-fw vs.
>ip-aliasing' I started to think about network structure in InetCaffe I'm
>going to take care of.
>
>There is a young and lazy administrator now, and everything he does is
>sitting on IRC and taking over channels. So what I need is to change
>network geometry competly. There is no firewall now (!) so I need to
>make one. I'll be using Potato. I can use two computers, and I need to
>divide virtual ftp/mail/www servers, dns server and firewall between
>them. I was thinking of:
>
><INTERNET> ---- |FIREWALL + DNS| ---- |FTP/MAIL/WWW|
> |
> |
> (COMPUTERS with WINDOWS in CAFFE)
>
>Is this a good choice? I have 32 IP's, so I'm going to use x.x.x.1 for
>FIREWALL & DNS, x.x.x.2 for FTP/MAIL/WWW, and x.x.x.3- for Win's.
>
>So for windows x.x.x.1 is DNS server and Gateway, am I right? Is it
>enough to ACCEPT some connections from/to computer to/form internet via
>ipchains and DENY others? Maybe You know there's a better net structure
>for this situation. Oh! My boss want's to sell Shell accounts also.
>Where do You think I should placate them: on firewall or behind it?
--
------------------------------------"Never tell me the odds!"---
Ray Olszewski -- Han Solo
Palo Alto, CA ray@comarre.com
----------------------------------------------------------------
Reply to: