First off, let me say thanks to Mr. Eastep for such a solid and easy to
use package. Seawall was the only ipchains ''package'' firewall
I ever
considered using, and Shorewall has been my first venture into the world
of iptables. The deployment I have just completed (and now need to redo
due to client requirement changes) was 100% straightforward and has been
working flawlessly for over a week.
Now, on to the question. The client now has a requirement that one of
the machines previously only accessible via the ''loc'' zone
should now be
partially accessible to the outside world. I''ve managed to convince
them
that NAT is not the right way to do this. We''re pretty much decided
that
the host in question will now be multihomed, and (of course) not routing
between interfaces, and I''ve been kicking around two different options
as to how to wire this up, and I''d love some suggestions from anyone on
the list as to what might be considered ''best practices''. If
you feel
that this is OT, feel free to reply off-list, ignore this, or flame, or
whatever. ;)
The location in question is blessed with two independent connections to
the internet. For the purposes of my hypothetical questions here, the
''primary'' connection, which clients use to NAT out to the
internet, has
addresses 172.16.0.0/24 available to it. The second internet connection,
which I had in mind for the DMZ, has addresses 10.0.0.0/24 available to
it, and the LAN, 192.168.1.0/24. (Yes, I know the addresses are bogus,
and that you know too. The question is purely a matter of theory.. )
Now that I think I''ve given enough info to draw the cheezy ASCII maps,
I''ll get right down to it.
Proposition #1:
Logical Description: DMZ host physically ''outside'' the
firewall.
ISPRTR1 ISPRTR2
172.16.0.254 10.0.0.254
\ /
FW-ETH1 / \
172.16.0.1 / \
\ / \
FW-ETH0 FW-ETH2 DMZHOST
192.168.0.1 10.0.0.1 10.0.0.2
\
\
CLIENTS
Advantages, as I see it:
1. Very few, if any, changes necessary to the configuration of the
firewall.
2. True and traditional DMZ host. The only packet filtering is the stuff
on the host itself.
Disadvantages:
1. Single-point-of-failure packet filtering for DMZHOST.
2. Wiring a little more complex.*
*Due to physical considerations. The hookups for the other network are
across the room, and there are no cable channels anywhere, and it''s a
heritage building....
Now, the other configuration. We resubnet 10.0.0.0/24, and eth0 gets an
alias on, e.g. 10.0.0.0/25.
ISPRTR1 ISPRTR2
172.16.0.254 10.0.0.254
\ /
FW-ETH1 /
172.16.0.1 /
\ /
FW-ETH0 FW-ETH2
192.168.1.1 10.0.0.129/25
\ /
CLIENTS FW-ETH0:0
10.0.0.1/25
/
DMZHOST
10.0.0.2/25
Advantages:
1. Another layer of packet filtering for DMZHOST.
2. Physically, this makes the network simpler in a few ways.
Disadvantages:
1. Firewall config becomes more complex.
2. Different logical networks sharing physical layer.
(yuck).
Thoughts welcomed....
--
Greg White
Greg White wrote:> ... > Now, on to the question. The client now has a requirement that one of > the machines previously only accessible via the ''loc'' zone should now be > partially accessible to the outside world. I''ve managed to convince them > that NAT is not the right way to do this. We''re pretty much decided that > the host in question will now be multihomed, and (of course) not routing > between interfaces, and I''ve been kicking around two different options > as to how to wire this up, and I''d love some suggestions from anyone on > the list as to what might be considered ''best practices''. If you feel > that this is OT, feel free to reply off-list, ignore this, or flame, or > whatever. ;)Greg, I''m finding your description a little hard to follow. Here is what i got - please tell me if i''m not right: you have one firewall system masqing a LAN (eth0) across two different Internet connections (eth1 and eth2), and you want to add a DMZ host in the eth2 address range (10.*).> ... > Proposition #1: > Logical Description: DMZ host physically ''outside'' the firewall. > ... > Advantages, as I see it: > 1. Very few, if any, changes necessary to the configuration of the > firewall. > 2. True and traditional DMZ host. The only packet filtering is the stuff > on the host itself. > ... > Disadvantages: > 1. Single-point-of-failure packet filtering for DMZHOST.> ... > Now, the other configuration. We resubnet 10.0.0.0/24, and eth0 gets an > alias on, e.g. 10.0.0.0/25. > ... > Advantages: > 1. Another layer of packet filtering for DMZHOST. > 2. Physically, this makes the network simpler in a few ways. > > Disadvantages: > 1. Firewall config becomes more complex. > 2. Different logical networks sharing physical layer. > (yuck).My first thought is that both of your proposed solutions are non-ideal, and you should just add another LAN card to the firewall and make a DMZ LAN (which could be just a loopback cable, but who cares). This makes the firewall configs a little more familiar, and has all the benefits of having the DMZ behind the firewall. I would probably put it in the LAN address space (use the next C class) and port forward any services that need to be available on the outside, unless there were a very good technical reason to do otherwise. However, if there are other limitations (like no more slots in the firewall machine, or cabling issues, or money), then here are my thoughts: - Solution 1, Disadvantage 1: I''d be more worried about the SPOF filtering for the LAN that exists in both cases than the SPOF filtering for the DMZ server. The LAN is what you are trying to protect. It deserves the most packet filters. - Solution 2, Advantage 1: What is this really gaining you? You''re going to let external systems access the DMZ host through the firewall anyway - what good is an extra packet filter with the same allow rules? - Solution 2, Disadvantage 1: If you define the new DMZ as a zone, the configs really won''t be that much more complicated. That is the real benefit of using shorewall, IMHO - you define rules in terms of zones, which makes them much easier to understand (and cleaner to look at in config form, too!). - Solution 2, Disadvantage 2: Sharing the same physical layer for multiple subnets is not inherently yucky. It''s only a problem if you don''t trust your LAN. Overall, i think that if you have the option of having the DMZ server inside or outside the firewall, i would have it inside where it is more protected. The best way to do that is with its own LAN (because it protects the LAN from the DMZ server as well), but your solution 2 sounds workable. Paul http://paulgear.webhop.net
On Fri Feb 02/01/02, 2002 at 09:04:52PM +1000, Paul Gear wrote:> Greg, > > I''m finding your description a little hard to follow. Here is what i got - > please tell me if i''m not right: you have one firewall system masqing a LAN > (eth0) across two different Internet connections (eth1 and eth2), and you > want to add a DMZ host in the eth2 address range (10.*).No doubt others found it hard too. My horrid ASCII diagrams probably did not help either. It''s much easier with dia or Visio. ;) You appear to have the gist of the problem to be solved though. Thanks for your thoughts, you''ve helped clarify mine.> My first thought is that both of your proposed solutions are non-ideal, and > you should just add another LAN card to the firewall and make a DMZ LAN > (which could be just a loopback cable, but who cares). This makes the > firewall configs a little more familiar, and has all the benefits of having > the DMZ behind the firewall. I would probably put it in the LAN address > space (use the next C class) and port forward any services that need to be > available on the outside, unless there were a very good technical reason to > do otherwise.I agree, this is technically the superior solution by far, but (as I neglected to mention) the firewall host will not take any more cards. If I were to do the four-interface thing, for myself I would probably still subnet the eth2 provider network, given a /28 or larger, but that''s just me. I hate port-forwarding with an unreasonable passion.> However, if there are other limitations (like no more slots in the firewall > machine, or cabling issues, or money), then here are my thoughts: > > - Solution 1, Disadvantage 1: I''d be more worried about the SPOF filtering > for the LAN that exists in both cases than the SPOF filtering for the DMZ > server. The LAN is what you are trying to protect. It deserves the most > packet filters. > > - Solution 2, Advantage 1: What is this really gaining you? You''re going > to let external systems access the DMZ host through the firewall anyway - > what good is an extra packet filter with the same allow rules?When put that way, it''s quite clear. It''s not much use.> - Solution 2, Disadvantage 1: If you define the new DMZ as a zone, the > configs really won''t be that much more complicated. That is the real > benefit of using shorewall, IMHO - you define rules in terms of zones, > which makes them much easier to understand (and cleaner to look at in > config form, too!). > > - Solution 2, Disadvantage 2: Sharing the same physical layer for multiple > subnets is not inherently yucky. It''s only a problem if you don''t trust > your LAN. > > Overall, i think that if you have the option of having the DMZ server > inside or outside the firewall, i would have it inside where it is more > protected. The best way to do that is with its own LAN (because it > protects the LAN from the DMZ server as well), but your solution 2 sounds > workable.I think that''s the way I''m going to go. I''ve had to do this for other clients with similar restrictions of one sort or another (for example, where the packet filtering host is a Cisco router and noone can afford another interface), and it has not bit me.... Option two also has the slight advantage of controlling traffic at least from the DMZ interface of the dual-homed DMZ host. Thanks very much for your thoughts on this, it helped. -- Greg White
> > I agree, this is technically the superior solution by far, but (as I > neglected to mention) the firewall host will not take any more cards.Have you looked at any of the 4-port cards -- they apparently work very well under Linux. -Tom
On Fri Feb 02/01/02, 2002 at 09:10:33AM -0800, Tom Eastep wrote:> > > > I agree, this is technically the superior solution by far, but (as I > > neglected to mention) the firewall host will not take any more cards. > > Have you looked at any of the 4-port cards -- they apparently work very > well under Linux.That''s a great idea, and in all honesty I hadn''t thought of it. Sadly, there are (of course) no dollars... I''ll be sure to mention it when they have some bucks. Has anyone ever done Linux work for someone who wasn''t on a tight budget? ;) Seriously, though, thanks again for the wonderful software. Anyone can write a firewall script. Your two packages are the first that I would have confidence in handing over to bright newbies to maintain. -- Greg White