Forward to DMZ addresses

Jonathan Villa jonathan at innovativesource.net
Fri Aug 19 20:57:32 CEST 2005


First, grrr.... I just wrote a nice lengthy reply but my webmail session
timed out and I lost it...let's see if I can remember everything I wrote

>>   router
>>     |
>>   VLAN Switch
>>     |
>>  firewall
>>   |    |
>>  LAN  DMZ
>
> Ok, if I am reading you correctly now, your router's internal interface
>that is connected to the VLAN switch has an IP that is on the same subnet
> as the servers that will be in the DMZ.

Yes.  You're correct

>I.e. the router in question will
> be the router for the DMZ servers.  I was thinking that your firewall
>was going to be a firewalling router that would handle your LAN and DMZ
networks.  However now I do not think that this is the case.

Actually, it is the case :(.  I _do_want_ a firewalling router to handle
my LAN and DMZ networks.  I want it to protect both LAN and DMZ so that I
can manage rules from one location rather than several of the boxen.

>
> Ok, I have a feeling that when you were typeing xx.xx.xx.182 you were
>really meaning to type xx.xx.xx.192.  Key shift, that's fine.  But that
does go to explain the interesting IPs.  No harm no foul.  :)  I think we
are on the same page of the same book now.

regarding IP's, yes

>
>>>Are the IPs in question in a subnet or just a scattering of them?
>> subnet...
>
> This is becoming more and more apparent all the time.  This is part of
>the
> problem which leads to what I think will be the ultimate solution.  (See
>below)
>
>> my firewall has 3 NIC's.  one connected to the router (well the VLAN
>>switch) which has an IP of 194.  the router is 193.  the dmz nic
(eth2) is
>> 195, the LAN is, well the LAN.  On my DMZ, I plan to provide static
>>address which are globally routable and from my subnet.
>
> *nod*  I think I see where you are going with this and I'm going to
>propose a wild change to accommodate what you are wanting to do.  (See
below)  (I know I keep saying that but it is a doosey.)
>
>> Sorry if I'm not making any sense... haven't had much sleep...
>
> Actually you are making more sense now than you have been all along.  No
>offense intended.  You have just explained that what you are wanting to
do
> can not be done with routing.

no offense taken, but I hope I continue to make sense.

>
>> I've been trying a few rules here and there trying to get something to
>>work... but to no avail.
>
> *nod*  I think I know why.  Let me try to explain.
>
> (this is below) (yes we finally made it)
>
> I think what you are wanting to do can not be done with traditional OSI
>Layer 3 routing but rather needs to be done with OSI Layer 2 bridging /
switching.  If I understand what you are wanting correctly to be the
following:

Ok, last night, after I slapped myself, I decided to check the logs, and
actually start logging... I should have been logging since the beginning,
perhaps it would have helped me explain my problem better.  I added the
following rules at the very top

iptables -A INPUT -i $WAN_ETH -j LOG
iptables -A OUTPUT -o $WAN_ETH -j LOG
iptables -A FORWARD -i $WAN_ETH -j LOG

Anyway, back to the point, I started to realize that perhaps my issue is
not with how I wrote my tables/rules, but with routing (you're mention of
OSI Layer 2 perhaps).  Last night it made more sense to me when I realized
that nothing was being logged on the interface connected to the
router/VLAN switch when attempting to connect to 196 (which is connected
to a switch "behind" the firewall).  I realized, hey, this seems to be a
routing issue...I now see I need to find a way to have 194 (or the
firewall's $WAN_ETH) route traffic for the rest of the subnet (except for
193 which is the router itself from the inside).

Now this is a wild guess, but I'm starting to think that I need to change
the router's routing rules.  But then again, I don't want to be someone
who remodels a bedroom just to add a new light switch.

>
> 1)  You want your router to be the router for all your systems behind it
(LAN is the exception) no matter where they are physically connected to.

I think I want my firewall to be the one to route for what is protected by
it, namely the LAN and DMZ because I want everything to be checked by the
rules of the firewall (which I see can be done using bridging now, but
still not sure if that's what I want).  I'm starting to think that I have
just opened up a can of gusanos

2)  You want the same subnet xx.xx.xx.192/28 to be on both sides of your
firewall (eth1 and eth2).

With the exception of the firewall's internal address, 193, I would like
to have the xx.xx.xx.192/28 subnet reachable behind my firewall only

> 3)  You want your LAN to appear to come from one of the IPs in your DMZ.

not the DMZ but the address of my firewall.  I have this part working as
noted by http://www.whatismyaddress.com.  I have a rule which does SNATing
on anything coming from my LAN interface and on the 192.168.0/28 network.

4)  You want to prevent any of the other systems in the DMZ from getting
to them directly.

Yes.

> If this is indeed the case what I propose you do is create a bridge on
your firewall and use EBTables to do most of your firewalling for your DMZ
> systems except for the LAN.  This would allow your systems in the DMZ to
be on the same subnet as the router's internal interface and talk as if
they were on the same physical LAN.  However as you will be passing the
traffic through a Linux bridge you will be able to do some basic
firewalling on them, namely protocol, source / destination IP, as well as
> source / destination port.  EBTables does not do much beyond that for
filtering but I think that is about all that you are wanting your
firewall
> to do.  You ultimately would use IPTables to handle the 2nd level of
firewalling (beyond EBTables) for your LAN which will allow you to do more
> advanced things like connection tracking and Stateful Packet Inspection
(SPI).
>
> Below is a (very) rough draft of the config / startup scripts that I
would
> write to make this happen.  You will not really need an IP for eth1 or
eth2 in this model of firewalling.  I think you will see why below.
>
> eth0 = LAN
> eth1 = Router
> eth2 = DMZ
>
> # We have to bring up the ether interfaces before we can set up the
bridge.
> ifconfig eth1 0.0.0.0 up
> ifconfig eth2 0.0.0.0 up
>
> # Let's establish the bridge first and then we will worry about the
IPTables firewalling.
> brctl addbr bri0
> sleep 1 # Prevent race conditions in the kernel.
> brctl addif bri0 eth1
> sleep 1
> brctl addif bri0 eth2
>
> # You will need to pick an IP to assign to your bri0 interface for the
LAN
> to use to communicate with the world.
> # Here are the IP assignments that I'm going to use for the sake of the
discussion, all of which are in the DMZ.
> #   Network = xx.xx.xx.192/28
> #    Router = xx.xx.xx.193/28
> #  LAN bri0 = xx.xx.xx.194/28
> # DMZ boxen = xx.xx.xx.195-206/28
> # Broadcast = xx.xx.xx.207/28
>
> # Let's assign an IP to the bri0 interface to be the ""external
interface
> of your pseudo LAN router.
> ifconfig bri0 xx.xx.xx.194 netmask 255.255.255.240 broadcast
xx.xx.xx.207
> up
>
> # You will need to have an IP subnet for your LAN.  I'm going to assume
aa.bb.cc.dd/24.
> #   Network = aa.bb.cc.0/24
> #    Router = aa.bb.cc.1/24
> #   Clients = aa.bb.cc.2-254/24
> # Broadcast = aa.bb.cc.255/24
>
> # Let's assing an IP to the eth0 interface
> ifconfig eth0 aa.bb.cc.1 netmask 255.255.255.0 broadcast aa.bb.cc.255 up
>
> At this point we have a logical switched (bridged) network that includes
the router (xx.xx.xx.193), your pseudo LAN router (xx.xx.xx.194) as well
as all your DMZ systems (xx.xx.xx.195-206).  The logical router is going
to use the bri0 interface to connect to the DMZ network so it can easily
communicate with the world via the router or to the other DMZ servers.
>
> So now we start setting up the various levels of firewalling.  To do
this
> on the OSI Layer 2 we will use EBTables.  We will use IPTables for the
OSI
> Layer 3 firewalling as you would expect.
>
> # First let's do some basic source / destination IP validation.  See RFC
3330 (http://www.rfc-editor.org/rfc/rfc3330.txt) for more information. #
Let's validate inbound source IPs by weeding out known bad source IPs.
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 10.0.0.0/8 -j DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 127.0.0.0/8 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 169.254.0.0/12 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 172.16.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 192.0.2.0/24 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src 192.168.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-src
255.255.255.255/32
> -j DROP
>
> # Let's make sure that the traffic is acctually to our network.
> ebtables -t filter -A FORWARD -i eth1 -p ipvr --ip-dst ! xx.xx.xx.192/28
-j DROP
>
> # Let's validate outbound destination IPs by weeding out known bad
destination IPs.
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 10.0.0.0/8 -j DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 127.0.0.0/8 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 169.254.0.0/12 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 172.16.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 192.0.2.0/24 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst 192.168.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-dst
255.255.255.255/32
> -j DROP
>
> # For paranoia sake let's make sure that we are not sending any bad
source
> IPs too.
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 0.0.0.0/8 -j DROP
ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 10.0.0.0/8 -j DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 127.0.0.0/8 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 169.254.0.0/12 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 172.16.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 192.0.2.0/24 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src 192.168.0.0/16 -j
DROP
> ebtables -t filter -A FORWARD -o eth1 -p ipv4 --ip-src
255.255.255.255/32
> -j DROP
>
> # If the traffic has made it this far we can be fairly confident that
the
> source and or destination IPs are reasonable.

thanks, in my complete script I had something similar, but did not include
127.0.0.0 or 169.0.0.0.  Thanks for the link to the RFC

> # If you want to do some additional filtering for a particular host you
would do it as such:
>
> # Host 195 is a web server only and thus will not answer DNS or SMTP
traffic.
> ebtables -t filter -N HOST195
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-dst xx.xx.xx.195 -j
HOST195
> ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
25
> -j DROP
> ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto udp --ip-dport
53
> -j DROP
> ebtables -t filter -A HOST195 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
53
> -j DROP
>
> # Host 196 could be DNS ONLY and will not have ANY other traffic AT all,
well save SSH of course.
> ebtables -t filter -N HOST196
> ebtables -t filter -A FORWARD -i eth1 -p ipv4 --ip-dst xx.xx.xx.196 -j
HOST196
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
22
> -j ACCEPT
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto udp --ip-dport
53
> -j ACCEPT
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto tcp --ip-dport
53
> -j ACCEPT
> ebtables -t filter -A HOST196 -i eth1 -p ipv4 --ip-proto icmp -j ACCEPT
ebtables -t filter -A HOST196 -i eth1 -j DROP
>
> # I think you get the idea.
>
> Now we can be fairly confident that the basic OSI Layer 2 firewalling
will
> make sure that nothing blatantly stupid is going on.  Thus we are left
with the OSI Layer 3 firewalling for the LAN.
>
> # Let's set up some sensible defaults.
> iptables -t filter -P INPUT DROP
> iptables -t filter -P FORWARD DROP
> iptables -t filter -P OUTPUT ACCEPT
>
> # Let's enable basic forwarding.
> iptables -t filter -A FORWARD -i bri0 -o eth0 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -t filter -A FORWARD -i eth0 -o bri0 -j ACCEPT
>
> # Let's set up the SNATing for our outbound LAN traffic.
> iptables -t nat -A POSTROUTING -o bri0 -j SNAT --to-source xx.xx.xx.194
>
> # I'd like to be able to RDP to the office 2k3 server (accounting has a
Windows only program!)
> iptables -t nat -A PREROUTING -i bri0 -p tcp --dport 3389 -j DNAT
--to-destination aa.bb.cc.2
> iptables -t filter -A FORWARD -i bri0 -o eth0 -p tcp -d aa.bb.cc.2
--dport
> 3389 -j ACCEPT
>
> I think this will take care of most of the firewalling on both OSI
Layers
> 2 and 3 like I think you are needing.  I know that this is a rather
>lengthy email, but what you are asking is not a simple thing to solve. 
>Fortunately Linux should be very capable of providing for you.  Once you
>realize that what (I think) you are trying to do can not be done on OSI
>Layer 3 you will see why you could not find a solution with all the
various >things you / we have tried / proposed to do.
>

Ok, hopefully I'm a little more clear now, i.e. I want a firewalling
router for the subnet xx.xx.xx.192/28.  Initially, my plan was to do this:

1. Connect eth1 to the Router directly
2. eth0 would be the LAN and network 192.168.0/24
3. eth2 would ethe DMZ and network 10.x.x.x or 192.168.1/24
4. DNAT DMZ IP to the DMZ network like so

iptables -t nat -A PREROUTING -i $WAN_ETH -d $EXT_STAGING_HTTP_IP -j DNAT
--to-routing $INT_STAGING_HTTP_IP
iptables -t filter -A FORWARD etc..etc..

(you also mentioned this earlier)

But then I thought to myself, "Why don't I just assign the actual IP to
the DMZ server?" and thus my journey began.

I'm now at the point where I really think it's a routing issue... agree of
disagree?  My other option is to give up and say, also in a loud sinister
voice, "Rat's foiled again", but then realized and said in a loud sinister
voice : Never!!!

Or... do I look into bridging.  I have come across this as a possible
scenario before, but thought that perhaps it's not "exactly" what I'm
looking for.


> Any way, chew on this and (please) let me know what you think.

Impressed and thankful.  Also, I think this will make for good reading
when someone searches the archives.





More information about the netfilter mailing list