[loads and loads of lines of dribble included for context so there! |-]
<-(robot smiley!)
Paul Mc Auley wrote:
>> On Wed, 14 Jun 2000 10:56:54 +0100
> Conor Daly <conor.daly at oceanfree.net> wrote:
> | Paul Mc Auley wrote:
>> | > I'm trying to get my head around setting up a toy firewall using ipchains
> | > and I have a few questions... if I have a subnet 10.1.2.0/24 and I wish to
> | > put a box in front of a given subnet of those, but I still wish the
> | > firewalled hosts to appear to be distinct.
>> | > Does this take deep magic? One thought I had was to set up multiple aliases
> | > on the external interface and do port forwarding, but I'm not too sure...
>> | If I read you right, you want to firewall a section of a Class A private
> | network from another part of the same network? That's easy!
>> Um, no. I used the 10 net to illustrate, but assume I'm using a public
> class C (or sub-C).
>> | Just physically seperate the sections of the network and put your
> | firewall in as the router. If you're remaining only within the private
> | network, the hosts will appear as before just with the firewall rules
> | affecting how they can be accessed.
>> So that the interfaces are both in the 10.1.2 net? Would that not create
> confusion? One possible reason for the answer for this to be no, would be
> if the internal interface had a smaller subnet than the external one.
>> | It's only if you need to connect to the Internet through the firewall
> | that you'll have to think about IP Masquerading but even here, your
> | hosts will appear as before on the local net and will be masqueraded
> | only on the Internet connection.
>> Well, yes. The idea is to have access to and from the net for given
> ports/protocols etc...
>> | The usual reason I've seen for wanting a host behind a firewall to be
> | visible outside it is to run servers like http, ftp, telnet etc. You
> | can route specific ports to the relevant machine(s) using port
> | forwarding but a specific port can be routed to *only one* machine. All
> | the info is there in the Firewall-HOWTO, the IPChains-HOWTO and the
> | IP-Masq-HOWTO from the LDP at www.linuxdoc.org .
>> Which is where the fun starts. I want to be able to allow connection to
> multiple hosts on the same port (e.g. http on the standard port).
>> | It's generally considered safer to put public server machines on the
> | Internet side of a firewall and treat them as "dirty". Of course, you
> | need public IP addresses for each server in that case.
>> Bastion hosts even, the trick is that I want to have a variety of sub-DMZ
> which is protected, but still outside the "real" firewall.
>> | That help at all?
>> At least it sort of lets me define the problem more clearly....
> Paul
You mean like this?
o Masqueraded internal network (various operating systems), which we
call "GOOD".
o Exposed servers in a separate network (called "DMZ" for
Demilitarized Zone).
o PPP Connection to the Internet (called "BAD").
External Network (BAD)
|
|
ppp0|
---------------
| 192.84.219.1| Server Network (DMZ)
| |eth0
| |----------------------------------------------
| |192.84.219.250 | | |
| | | | |
|192.168.1.250| | | |
--------------- -------- -------
-------
| eth1 | SMTP | | DNS | | WWW
| | -------- -------
-------
| 192.84.219.128 192.84.219.129
192.84.218.130
|
Internal Network (GOOD)
It's all there in the IPCHAINS-HOWTO!
IIRR, even if you use the same subnet for your "good" and "DMZ"
sections, you can define which IP addresses are in which zone in the
IPchains firewall script. Something like:
IPADDR_DMZ=192.84.219.120-140
IPADDR_GOOD=192.84.219.0-119
IPADDR_BAD=0/0
PRIVPORTS=0-1023
UNPRIVPORTS=1024-65535
Then use these shell variables in writing the rules so:
# Deny access from bad to good
ipchains -A input -s $IPADDR_BAD -d $IPADDR_GOOD -j DENY
# Allow access from bad to DMZ for http and log packets
ipchains -A input -s $IPADDR_BAD $UNPRIVPORTS -d $IPADDR_DMZ 80 -l -j
ACCEPT
# Allow access from good to DMZ for all operations and log packets
ipchains -A input -s $IPADDR_GOOD -d $IPADDR_DMZ -l -j ACCEPT
You just add a NIC to your main firewall, split the network and work out
your DMZ rules for both Internet and internal zones and you're off. No
port forwarding ar anything required. The only situation where you need
port forwarding is when you *don't* have a public IP address range
available for your DMZ machines.
AFAIK you don't need masquerading for a Private internal network range
(even with machines in the DMZ). So long as the router knows about the
Private network, it will only need to masq packets going out to the
Internet so for example,
You have a www server in your DMZ which uses CGI scripts to extract data
from a database located on a server in your Private network at IP
192.168.25.25 The www server can send out a request to 192.168.25.25
which the router/firewall will forward to the relevant machine. This
will return the info requested which will be passed back out on the
Internet by the www server.
The only difficulty I can see in such a setup, using the same subnet for
both sections of your network, is in the routing tables on the
firewall/gateway. I don't know quite how you set up a routing table for
sections of a subnet but I think there's some detail on that in the
IPCHAINS-HOWTO or else in some of the networking HOWTOs. It would be
nice if you could use something like
route add 192.84.219.120-140 -gw eth1
route add 192.84.219.0-119 -gw eth0
However, if the two subnets are on different sized netmasks, I think the
problem is easier to solve but I'm not sure how.
--
Conor Daly
ph +353 1 8326146
conor.daly at oceanfree.net
------------------------
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
